技術文檔

首頁->技術文檔->統計數據資源平臺設計說明

統計數據資源平臺設計說明書

來源: 作者: 日期:2009-07-01 09:25:48 【字號

0. 文檔介紹

0.1 文檔目的

本文檔為保證系統開發順利,將詳細設計過程中的細節進行展示

0.2 文檔范圍

該文檔包括系統設計的關鍵技術,可參見數據庫設計說明書。

0.3 讀者對象

項目組開發人員、測試人員

0.4 參考文獻

提示:列出本文檔的所有參考文獻(可以是非正式出版物),格式如下:

[標識符] 作者,文獻名稱,出版單位(或歸屬單位),日期

例如:

[AAA] 作者,《立項建議書》,機構名稱,日期

[SPP-PROC-SD] SEPG,系統設計規范,機構名稱,日期

0.5 術語與縮寫解釋

縮寫、術語

SPP

精簡并行過程,Simplified Parallel Process

SD

系統設計,System Design

 

 

 

1.統計數據資源平臺系統設計方案

1.1設計原則

“博和利統計數據資源管理平臺”建設主要遵循以下設計原則:

? 開放性原則

系統開放性主要包括:開放的開發環境、源代碼、操作系統和服務器,系統設計要為發展留有余地。隨著用戶需求的增加,系統應能不斷擴大其功能,隨著新技術的發展,新設備的涌現,系統應能不斷提高其性能,同時,保證各系統之間的互連互通。

? 標準化原則

軟件設計嚴格執行國家有關軟件工程的標準,保證系統質量,提供完整、準確、詳細的開發文檔,為用戶二次開發提供源程序;應用設計符合國際、國家、金融行業有關標準、規范以及天津高新技術產業園區系統長遠規劃。

? 可拓展性原則

軟件設計盡可能模塊化、組件化,并提供配置模塊和客戶化工具,使應用系統可靈活配置,適應不同的情況。系統的要素、編碼、功能和數據庫結構都必須易于擴充,為以后的功能擴展保留接口,以滿足系統進一步的發展和系統建設的需要。同時系統的升級充分考慮與現有各應用系統的版本兼容問題,盡可能保證系統有更長的生命周期。

? 兼容性原則

“博和利統計數據資源管理平臺”能夠與現有的各個專業系統進行信息通信和數據共享,因此該平臺必須充分考慮系統兼容性問題,必要時提供CORBA、RMI、SOAP、和RPC等各種接口。

? 可移植性原則

系統采用Java開發體系,與系統平臺無關,確保應用系統的可移植性。

? 安全性原則

系統安全性包括兩個方面,一是防止系統外部的“黑客”,病毒對系統的攻擊;二是確保系統數據信息的安全。因此不僅要在系統設計時,充分考慮系統的安全性,更要在系統運行時,對用戶進行安全培訓,在意識、管理、制度等諸方面確保系統的安全性。

? 先進性原則

系統在設計思想、系統架構、采用技術、選用平臺上均需要具有一定的先進性、前瞻性,考慮一定時期內業務的增長。

? 易用性原則

提供友好的用戶操作界面,具備直觀易用的人機界面。對于復雜操作步驟,提供操作向導和聯機幫助。

? 穩定性原則

在系統設計、開發和應用時,從系統結構、技術措施、軟硬件平臺、技術服務和維護響應能力等方面綜合考慮,確保系統較高的性能和較少的故障率。

? 可恢復性原則

資源數據是整個系統的中心支柱,信息的有效管理與儲存、備份是這個一切的基礎。對信息資源的各種頻繁操作,將不可避免的給信息資源,甚至整個信息系統帶來損害,在災難發生時,能供體統快速恢復手段,保障整個系統連續運轉。

? 可管理性原則

為使系統的性能達到最優,減少系統維護的費用和時間,必須提供各種手段來對系統進行監控,減少故障發生率,以及災難快速恢復。系統的可管理性應該嚴格的從系統結構、技術措施、運行環境、安全控制等各方面綜合考慮。針對不同的應用和通訊環境,系統應提供不同的措施,以防止非法侵入和機密信息的泄漏,保證系統的安全性和每一個合法用戶的自身利益。

? 人性化原則

“科技以人為本”,本系統在信息準確全面、檢索快速、信息與業務關聯、使用方便、輔助及提醒等功能上體現人性化的設計思路。

1.2技術路線

在系統設計中綜合使用了多種先進的符合計算機發展趨勢的主流技術,保證系統的先進性、適用性、靈活性、穩定性、安全性。系統設計中所采用的技術詳細介紹如下。

1 J2EE技術

J2EE(即Java 2 平臺企業版)是由Sun公司主持推出的一項中間件技術。從CORBA、IDL到面向消息的系統,中間件技術已經走過了很長的一段路程,如今J2EE作為中間件技術史上的一塊具有決定意義的里程碑,正受到業界越來越廣泛的重視和采納。

簡單地說,J2EE是一個標準中間件體系結構,旨在簡化和規范多層分布式企業應用系統的開發和部署。J2EE方案的實施可顯著地提高系統的可移植性、安全性、可伸縮性、負載平衡和可重用性。

J2EE的核心是一組規范和指南,定義了一個使用Java語言開發多層分布式企業應用系統的標準平臺。開發人員在這些規范和指南的基礎上開發企業級應用,同時由J2EE供應商確保不同的J2EE平臺之間的兼容性。由于基于規范的各J2EE平臺之間具有良好的兼容性, 因此J2EE應用系統可以部署在不同的應用服務器上,無需或只需進行少量的代碼修改。

2 XML技術

XML(eXtensible Markup Language,可擴展置標語言)是由W3C于1998年2月發布的一種標準。它是SGML的一個簡化子集,它將SGML的豐富功能與HTML的易用性結合到Web的應用中,以一種開放的自我描述方式定義了數據結構,在描述數據內容的同時能突出對結構的描述,從而體現出數據之間的關系。這樣所組織的數據對于應用程序和用戶都是友好的、可操作的。可以對本系統不同平臺、不同格式的數據源進行數據集成和數據轉換。

3 Web Service技術

Web service技術是一套標準,由發布Web和XML技術標準的W3C組織(WorldWideWeb Consortium)制定,它定義了應用程序如何在Web上實現互操作性。可以用任何語言,在不同的平臺中編寫Web service ,而通過Web service的標準來對這些服務進行查詢和訪問。

4 元數據技術

元數據是關于數據的數據,即關于數據的內容、質量、狀況和其他特性的信息。元數據是使數據發揮作用的重要條件之一,它幫助數據生產單位有效地管理和維護數據;提供通過網絡對數據進行查詢檢索的方法或途徑,以及與數據交換和傳輸有關的幫助信息;幫助用戶了解數據,以便就數據是否滿足其需求作出正確判斷;提供有關信息,以便用戶處理和轉換接受外部數據;提供數據生產單位數據存貯、數據分類、數據內容、數據質量、數據交換網絡及數據銷售等方面的信息,便于用戶查詢檢索。

1.3總體設計思路

企業統計數據分析系統的總體設計思路如下圖所示,該系統從下到上分為4個層次。

 

 

1) 第一層面——分散的操作數據和外部信息向集中存儲形式的轉移,這一轉移是整個數據中心中最底層、最基礎的工作。

通過數據的集中存儲可以有效解決數據分散存儲所帶來的簡單統計和查詢的不便,可以通過統一友好的界面為授權用戶提供豐富的查詢、統計和報表打印功能。

2)第二個層面——依據中央數據庫的數據建立數據倉庫,這一過程是數據數據庫結構向數據倉庫存儲形式的轉移。在預先定義的元數據(Meta Data)模型的基礎上,通過數據的提取、清理、轉換和裝入(ETL)等過程,轉為數據倉庫的存儲和檢索形式。同時,還可以根據不同的主題,建立相應的數據集市(Data Mart),作為解決不同主題問題的數據源的依據。

3)第三個層面——在線分析過程(OLAP)。建立在數據倉庫基礎上的聯機分析處理(OLAP)技術通過對多維數據的聚合計算和聚合結果的預存儲,支持數據多角度、多側面的統計和觀察,從而達到對數據更為全面的把握和理解的目的。OLAP技術主要從對數據倉庫中的數據進行表層的聚合統計,力圖以統一的應用邏輯和數據模型,在短時間內響應非數據處理專業人員的簡單或復雜的查詢要求,從而為決策提供信息層面的支持。

4)第四個層面——數據挖掘(Data Mining)層面。數據挖掘技術(Data Mining)和數據庫中的知識發現技術(KDD—Knowledge Discovery in Database)屬于比OLAP更高層次的應用,主要是利用的數學模型和數據分析算法對數據庫中的數據進行更深層次上的發掘和理解,從而發現數據隱含的、以前未知的、新穎的、有趣的知識,其目的是對決策提供知識層面的支持。

在上述四個層次的功能中,數據的集中存儲和數據倉庫/數據集市的建立是整個系統的基礎,而OLAP和數據挖掘則可以使數據得到有效利用,兩者必須緊密結合,才能保證最終獲得理想的效果。

1.4現有的技術基礎

項目承擔方在在線分析(OLAP)、數據挖掘等方面做了大量的研究工作,并在多個企業和部門進行了成功應用,具備了完成本項目的基本條件。

1.4.1數據采集中間件平臺

數據采集中間件平臺是在衛生局應急系統和物流集成項目等一大批對異構和海量數據融合有深入需求的項目中產生,并投入研發隊伍參照國際同類產品設計開發完成。

系統主要針對各類異構的數據源及應用系統(包括遺留應用)提供數據抽取、分析、轉儲和集成服務。待處理的各類數據源及與歷史遺留應用系統可作為數據采集的使用者,系統本身作為服務的提供者與底層數據資源通信,并將去除數據的物理位置、類型和管理,將其抽象為統一的“數據采集”,“數據采集”充當與底層數據源的邏輯接口,同時包含了大量的元數據(描述數據的數據)信息供另外的服務使用者-前端行業應用查找、執行、或轉換為特定需求格式的信息。這種體系結構使服務接口(數據采集),作為與服務實現(數據集成)分離的實體存在,從而使得服務實現能夠在完全不影響服務使用者(既有數據源及遺留應用包括前端調用)的情況下進行修改,結構松散耦合并能夠輕松組合附加服務。

1.4.2定時執行Job的Quartz

Quartz是一個時下最流行的作業調度框架,它完全由Java寫成,并設計用于J2SE和J2EE應用中。它提供了巨大的靈活性而不犧牲簡單性。能夠用它來為執行一個作業而創建簡單的或復雜的調度。它有很多特征,如:數據庫支持,集群,插件,EJB作業預構建,JavaMail及其它,支持cron-like表達式等等。事實證明了Quartz能滿足企業級應用的定時調度。

1.4.3聯機分析處理OLAP

OLAP是數據倉庫系統的主要應用,支持復雜的分析操作,側重決策支持,并且提供直觀易懂的查詢結果,OLAP是使分析人員、管理人員或執行人員能夠從多角度對信息進行快速、一致、交互地存取,從而獲得對數據的更深入了解的一類軟件技術。OLAP的目標是滿足決策支持或者滿足在多維環境下特定的查詢和報表需求。

1.4.4數據挖掘技術

數據挖掘是從大量的數據中挖掘出隱含的、未知的、對決策有價值的知識和規則。這些規則蘊含了數據庫中一組對象之間的特定關系,揭示出一些有用的信息,為行政決策、政策制定及政策效果分析等方面提供依據。

通過數據挖掘,有價值的知識、規則或高層次的信息從數據庫的相關數據機和中抽取出來,并從不同角度顯示,從而使大型數據庫作為一個豐富可靠的資源,為決策服務。

1.4.5應用服務器

目前企業級的開發都集中在J2ee領域的應用架構上。而J2EE的架構離不開應用服務器(軟件),考慮采用世界上公認非常穩定的apache組織的Tomcat應用服務器,結合spring、hibernate搭建輕量級的企業級應用,通過多個項目的證實,這套技術路線非常適合中、小型的業務系統開發。

2系統設計方案

2.1總體功能構成


 

 

 

 

 

2.1系統架構

2.4數據采集方案

2.4.1數據采集對現有系統的影響

我們采取獨立的數據采集策略,不用修改現有的系統,哪怕是針對數據庫的一個觸發器或存儲過程的增加,都應該盡量避免,從而保證現用各種不同系統不受影響。

通過引入數據服務中間件,采用了主動向已有系統抽取數據的方式。而且由中間件通過配置而非編寫程序代碼完成,可以由用戶自主進行數據采集內容的擴展。

這種數據服務中間件即ETL(Extract-Transform-Load的縮寫,即數據抽取、轉換、裝載的過程)工具,能夠按照統一的規則集成并提高數據的價值,是負責完成數據從各自種數據源向目標數據倉庫轉化的過程,是實施數據倉庫的重要步驟。如果說數據倉庫的模型設計是一座大廈的設計藍圖,數據是磚瓦的話,那么ETL就是建設大廈的過程。

2.4.2采集各種數據源數據

我們采用博和利ETL工具采集各種不同的數據源數據。該工具從源系統中提取數據,轉換數據為一個標準的格式,并加載數據到目標數據存儲區,通常是數據倉庫。ETL的體系結構圖如下:

 

現存系統的主要的數據源為常用的關系數據庫如Oracle、Sql server,以及excel。即便格式比較復雜的數據,我們也可以用文本文件( 如.txt文件)將數據導入我們的目的數據源。

博和利數據采集工具完全由java實現,由此具備了跨平臺性,能夠運行在各種操作系統之上。該工具通過JDBC、ODBC、JNDI、OCI等技術支持的數據庫多達27種。同時支持txt、csv、xls、zip、xml文件作為輸入或輸出,這為我們提取多數據源數據提供了完全的保障。

博和利數據采集工具的一些控件為各種更為復雜的數據也提供了方便的支持,如計算器步驟提供了豐富的計算類型(如下圖),這為采集復雜數據提供了便捷的方法。

 


 

2.4.3數據采集增量更新

增量更新是一個比較依賴與工具和設計方法的過程,博和利數據采集工具中主要提供Insert / Update 步驟,Delete 步驟和Database Lookup 步驟來支持增量更新,增量更新的設計方法也是根據應用場景來選取的。

增量更新按照數據種類的不同大概可以分成:

1.         只增加,不更新,

2.         只更新,不增加

3.         即增加也更新

4.         有刪除,有增加,有更新

其中1 ,2, 3種大概都是相同的思路,使用的步驟可能略有不同,通用的方法是在原數據庫增加一個時間戳,然后在轉換之后的對應表保留這個時間戳,然后每次抽取數據的時候,先讀取這個目標數據庫表的時間戳的最大值,把這個值當作參數傳給原數據庫的相應表,根據這個時間戳來做限定條件來抽取數據,抽取之后同樣要保留這個時間戳,并且原數據庫的時間戳一定是指定默認值為sysdate當前時間(以原數據庫的時間為標準),抽取之后的目標數據庫的時間戳要保留原來的時間戳,而不是抽取時候的時間。第四種情況有些復雜,但博和利數據采集工具也是能完全能夠實現的。

增量更新的核心問題在與如何找出自上次更新以后的數據,其實大多數數據庫都能夠有辦法捕捉這種數據的變化,比較常見的方式是數據庫的增量備份和數據復制,利用數據庫的管理方式來處理增量更新就是需要有比較好的數據庫管理能力,大多數成熟的數據庫都提供了增量備份和數據復制的方法,雖然實現上各不一樣,不過由于ETL的增量更新對數據庫的要求是只要數據,其他的數據庫對象不關心,也不需要完全的備份和完全的stand by 數據庫,所以實現方式還是比較簡單的,只要你創建一個與原表結構類似的表結構,然后創建一個三種類型的觸發器,分別對應insert , update , delete 操作,然后維護這個新表,在你進行ETL的過程的時候,將增量備份或者數據復制停止,然后開始讀這個新表,在讀完之后將這個表里面的數據刪除掉就可以了,不過這種方式不太容易定時執行,需要一定的數據庫特定的知識。如果對數據的實時性要求比較高可以實現一個數據庫的數據復制方案,如果對實時性的要求比較低,用增量備份會比較簡單一點。

2.4.4數據采集定時執行

博和利數據采集工具在Job下的start模塊,有一個定時功能,可以每天、每周、每月以及以一定時間間隔執行數據采集。具體如下圖所示

這對原系統有周期性提交的數據源,提供了很方便的數據采集方法。

2.5聯機分析方案

OLAP(聯機分析處理)是針對特定問題的聯機數據訪問和分析。通過對信息(維數據)的多種可能的觀察形式進行快速、穩定一致和交互性的存取,允許管理決策人員對數據進行深入觀察。使分析人員、管理人員或執行人員能夠從多種角度對從原始數據中轉化出來的、能夠真正為用戶所理解的、并真實反映企業維特性的信息進行快速、一致、交互地存取,從而獲得對數據的更深入了解。OLAP的目標是滿足決策支持或多維環境特定的查詢和報表需求。它有如下幾個特性:

I、快速性

用戶對OLAP的快速反應能力有很高的要求。系統應能在5秒內對用戶的大部分分析要求做出反應。如果終端用戶在30秒內沒有得到系統響應就會變得不耐煩,因而可能失去分析主線索,影響分析質量。對于大量的數據分析要達到這個速度并不容,因此就更需要一些技術上的支持,如專門的數據存儲格式、大量的事先運算、特別的硬件設計等。

II、可分析性

OLAP系統應能處理與應用有關的任何邏輯分析和統計分析。盡管系統需要事先編程 ,但并不意味著系統已定義好了所有的應用。用戶無需編程就可以定義新的專門計算,將其作為分析的一部分,并以用戶理想的方式給出報告。用戶可以在OLAP平臺上進行數據分析,也可以連接到其他外部分析工具上,如時間序列分析工具、成本分配工具、意外報警、數據開采等。

III、多維性

多維性是OLAP的關鍵屬性。系統必須提供對數據分析的多維視圖和分析,包括對層次維和多重層次維的完全支持。事實上,多維分析是分析企業數據最有效的方法,是OLAP的靈魂。

IV、信息性

不論數據量有多大,也不管數據存儲在何處,OLAP系統應能及時獲得信息,并且管理大容量信息。這里有許多因素需要考慮,如數據的可復制性、可利用的磁盤空間、OLAP產品的性能及與數據倉庫的結合度等。人們很容易理解一個二維表(如通常的電子表格),對于三維立方體同樣也容易理解。 OLAP通常將三維立方體的數據進行切片,顯示三維的某一平面。如一個立方體有時間維、商品維、收入維,其圖形很容易在屏幕上顯示出來并進行切片。但是要加一維(如加入商店維),則圖形很難想象,也不容易在屏幕上畫出來。要突破三維的障礙,就必須理解邏輯維和物理維的差異。OLAP的多維分析視圖就是沖破了物理的三維概念,采用了旋轉、嵌套、切片、鉆取和高維可視化技術,在屏幕上展示多維視圖的結構,使用戶直觀地理解、分析數據,進行決策支持。數據在多維空間中的分布總是稀疏的、不均勻的。在事件發生的位置,數據聚合在一起,其密度很大。因此,OLAP系統的開發者要設法解決多維數據空間的數據稀疏和數據聚合問題。事實上,有許多方法可以構造多維數據。

I、超立方結構

超立方結構(Hypercube)指用三維或更多的維數來描述一個對象,每個維彼此垂直。數據的測量值發生在維的交叉點上,數據空間的各個部分都有相同的維屬性。這種結構可應用在多維數據庫和面向關系數據庫的OLAP系統中,其主要特點是簡化終端用戶的操作。 超立方結構有一種變形,即收縮超立方結構。這種結構的數據密度更大,數據的維數更少,并可加入額外的分析維。

II、多立方結構

在多立方結構(Multicube)中,將大的數據結構分成多個多維結構。這些多維結構是大數據維數的子集,面向某一特定應用對維進行分割,即將超立方結構變為子立方結構。它具有很強的靈活性,提高了數據(特別是稀疏數據)的分析效率。一般來說,多立方結構靈活性較大,但超立方結構更易于理解。終端用戶更容易接近超立方結構,它可以提供高水平的報告和多維視圖。但具有多維分析經驗的MIS專家更喜歡多立方結構,因為它具有良好的視圖翻轉性和靈活性。多立方結構是存儲稀疏矩陣的一個更有效方法,并能減少計算量。因此,復雜的系統及預先建立的通用應用傾向于使用多立方結構,以使數據結構能更好地得到調整,滿足常用的應用需求。許多產品結合了上述兩種結構,它們的數據物理結構是多立方結構,但卻利用超立方結構來進行計算,結合了超立方結構的簡化性和多立方結構的旋轉存儲特性。

在線聯機分析過程技術,為授權用戶提供一個全方位、多角度、多形式觀察和分析數據的平臺,并提供豐富的圖形分析界面,為決策提供信息層面支持。如下所示,可以從不同的角度進行分析天津高新技術產業園區內企業的經濟運行情況,當然遠遠不僅這些角度,實施的過程中會根據實際情況進行建立多個分析維度。

 


 

2.6數據挖掘方案

數據挖掘是從大量的數據中挖掘出隱含的、未知的、對決策有價值的知識和規則。這些規則蘊含了數據庫中一組對象之間的特定關系,揭示出一些有用的信息,為行政決策、政策制定及政策效果分析等方面提供依據。

通過數據挖掘,有價值的知識、規則或高層次的信息從數據庫的相關數據機和中抽取出來,并從不同角度顯示,從而使大型數據庫作為一個豐富可靠的資源,為決策服務。

數據挖掘的主要功能及預期效果包括:

(1)數據分類(Classification):數據分類是發現每一數據與既定類別間的映像函數的過程。分類對于園區管委會進行企業類別劃分、企業成長性分析等方面具有重要意義。常用的分類方法包括決策樹、神經網絡、遺傳算法、Rough集等。主要作用:根據企業的歷史數據,構建分類模型,對企業進行分類,如高成長型企業識別、潛力型企業識別等,為制定企業扶持政策提供支持;

(2)回歸分析(Regression):利用回歸分析的方法得到一個函數,將數據映射到預測變量,發現變量和屬性間的依賴關系。回歸分析是進行經濟預測、增長率預測、政策效果分析、孵化基金效果分析等方面具有重要意義。

(3)聚類分析(Clustering):根據對象之間的相似性把對象分組。聚集分析在統計、機器學習、數據挖掘等領域中已有不同側重的研究。聚類可以將企業按照多個屬性進行分群,在種子企業的選取、政策效果分析與驗證、政策制定、孵化基金的投放、服務類型的選擇等方面具有重要意義,同時還可以從眾多企業中選擇需要重點扶持的企業和成長性較差的企業,為扶持政策的制定提供依據。

(4)構造依賴模式(Dependency Pattern):構造變量間的函數依賴關系或相關關系的模型,可以用于政策效果分析、投資效果分析、績效考核等方面。

(5)偏差分析(Deviation Detection):探測數據現狀和歷史紀錄或標準之間的差別,例如結果與期望的偏離,反常實例等,可以用于對年度園區經濟增長進行分析和診斷,為未來扶持政策的制定提供支持。

除此之外,通過不同的模型,還可以回如下方面的內容進行分析:

(1)企業經營狀況分類

應用DEA方法對企業的投入產出效率進行分析,并進而對企業的經營狀況進行分類,對企業經營進行預警。

(2)財務狀況評級及預警

根據企業自身的財務狀況以及相類似的企業的狀況,對企業的財務狀況進行評級,并對存在問題的企業進行預警。

(3)企業聚類

采用K-means聚類算法,對所有的同類別企業進行聚類,以從中發現存在異常情況的企業。

(4)企業異常經營狀況異常識別

根據企業經營的歷史數據,對企業的經營狀況進行綜合分析與評估,從而識別出企業的異常經營狀況。

(5)企業經營績效預測

根據企業的經營數據,對未來的經營績效進行預測,采用的方法包括線性回歸、非線性回歸、神經網絡等。

(6)政策效果評估

根據對政策發布前后企業經營效果的差異,對園區制定的政策的效果進行評估。

(7)政策效果模擬

構建企業運營績效對特定政策的敏感性指數,并由此構建模擬模型,對政策的效果進行模擬分析,為政策的制定提供決策依據。

(8)區縣宏觀經濟預測

根據區縣的宏觀經濟統計數據,結合對重點企業經營數據的分析,對園區宏觀經濟中長期走勢進行預測,為宏觀經濟政策的制定奠定基礎。

2.7系統安全性解決方案

由于本次系統平臺建設完成后,平臺的主要使用者是天津高新技術產業園區的內部人員,因此,基本可以排除來自用戶的惡意攻擊,但為了防止少數感染病毒的客戶端對系統平臺的自動攻擊,利用天津高新技術產業園區現有防火墻對專網服務器區及內部網絡制定嚴格的防護策略還是非常必要的;同時加強用戶審核防止用戶帳戶因人為泄露所造成的對系統的威脅;使用入侵檢測設備對已知惡性攻擊進行防范;建立良好的管理制度,定時檢查系統狀態,及時安裝升級程序,避免系統本身缺陷造成的系統服務中斷。另外采用以下手段實現系統的總體安全:

? 防病毒、黑客攻擊

可以利用現在系統已有的防火墻等安全系統的功能

? 用戶與權限管理

系統在系統維護管理子系統中,通過對用戶、用戶權限的嚴格管理,控制用戶的功能權限和對系統數據的操作權限。系統的所有合法用戶,都將經由一個可視化的組織機構管理工具,安置于各自的崗位,各自擁有各自的角色。權限管理系統將把系統的功能和數據資源,以樹結構,分配到樹形結構的組織結構圖上的崗位和角色。不同的用戶,登錄進入系統中,由于各自的工作崗位和角色不同,擁有不同的用戶操作權限,對數據可能是不可見、可讀、可修改、可刪除、可新建等權力。

? 運行監控與安全審計

系統將對用戶進入系統的所有操作,進行監控,以日志的方式,記錄下來。一方面,可以對用戶的對系統的使用情況進行統計分析,以利于對系統的進一步改進。同時,依靠強大的日志監視功能,可以掌握系統的運行狀況,跟蹤用戶的使用記錄,利于安全審計。

? 安全管理制度建設

信息系統安全工程安全管理組織制定的安全管理制度主要包括:

人事安全管理制度、操作安全管理制度、場地與設施安全管理制度、設備安全管理制度、軟件平臺安全管理制度、計算機網絡安全管理制度、應用軟件安全管理制度、技術文檔安全管理制度、數據安全管理制度、密碼安全管理制度、應急管理制度等。

2.8系統管理及權限設計方案

園區企業統計數據分析系統采用事實標準的基于用戶、角色、受限資源的權限管理,采取所見即所得的展現形式,即如果沒有權限訪問的資源,干脆就不顯示出來,顯示出來的功能就是有權限操作的功能。

2.8.1用戶角色的管理

(1) 用戶/組管理

系統支持使用組來管理用戶,還使用組來管理訪問頁面資源。每個用戶都可以是一個或多個組的成員。所有用戶都是虛擬組 all-users 的成員。這是一個包含所有用戶的虛擬組,它不被維護。組和用戶均可被指定對園區企業統計數據分析系統受限資源的訪問權。

管理員將頁面的訪問權指定給用戶組和個別的用戶。當用戶是多個組的成員時,其訪問權是累加的,也就是,若任何組允許存訪問受限資源,并且該用戶是該組的成員,則也允許該用戶選擇并使用該 受限資源。

(2)訪問控制管理

系統使用“訪問控制表”(ACL) 來管理用戶授權,用于存取應用程序資源,如頁面。系統提供用戶界面,可用于管理策略和資源。

管理策略,使特定的用戶或組能管理資源。這些規則就是所謂的策略許可。這有效地表示委托訪問權給其它用戶或組。

管理資源,使特定地用戶或組能存取資源。這些規則就是所謂的資源許可。這意味著授予用戶和組對頁面的訪問權。

下列規則應用于訪問控制:

◆權限是累加的。每個條目指定一個要授予的許可權。

◆控制存取資源的許可權可授予個別的用戶和用戶組。

◆如果某個組有許可權,并且某個用戶是該組的成員,這些規則和授予組的相應許可權也應用于該用戶。

◆每個用戶可以是一個或多個組的成員。

◆所有用戶都是虛擬組 all-users 的成員,不管他們在其它組中的成員資格如何。

◆要新建包含用戶/組、操作及資源的新許可權,請求者必須有許可權來管理用戶或組和資源。

◆只有缺省管理員 admin 和管理員組的成員 admins 才能創建許可權,并可將管理用戶、組或資源的許可權授予其它用戶或組。

◆如果用戶或組有管理目標對象的許可權,它隱含該目標對象的所有其它許可權。

管理策略許可權

“訪問控制管理”應用由管理員 admin(缺省管理員)和管理員組的成員 admins 來創建策略許可權,使組/用戶能管理資源。組/用戶對相關資源、用戶和組必須有管理權限,然后才能為它們創建資源許可權條目。

2.8.2數據一致性檢查

系統中各數據表內容是緊密關聯的,保持數據一致性是至關重要的,否則將直接威脅系統運行的安全。因此,在系統設計和開發過程中,必須提供數據一致性檢查。這主要通過三個層面來解決:

數據庫平臺:使用數據庫的事務處理,保證數據一致;

數據庫設計:在數據庫設計建立表間關聯,進行一致性檢查;

應用開發:應用系統層建立數據約束,檢查數據一致性。

2.8.3數據字典管理

為保證系統的靈活性和可擴充性,系統需設計多類數據字典,通過數據字典來管理數據表定義、報表定義、功能定義、代碼定義等:

數據表字典:存儲個數據表結構信息和擴展信息,用于靈活查詢和統計;

報表字典:存儲報表模板,可進行靈活的報表設計;

功能表字典:存儲功能表定義,可擴展系統功能;

代碼表字典:存儲代碼表數據,適應業務變化。

3總體設計思想

統計數據資源平臺的設計思想主要體現在三個方面,一是“集成化”,二是“面向解決方案”,三是“以流程為中心”。

所謂集成化,是指將眾多不同的BI產品集成到一個統一的框架中來,使之可以相互協作。以往的BI產品,往往只專注于BI的某一特定領域,如Jfree主要關注表表的生成,Quartz主要關注日程的管理等等。然而一個完整的BI應用往往需要這些BI產品能夠相互協作。統計數據資源平臺通過引入“Action”的概念,提供了一個讓多種BI產品協作的機制。“Action”是統計數據資源平臺平臺提供的最基本的操作單元,它類似于一種編程語言的基本語句。所有完成具體功能的BI產品作為“插件”集成到統計數據資源平臺平臺中,每種插件為統計數據資源平臺平臺提供一種或幾種“Action”,每個Action有自己的輸入和輸出,多個Action連接起來就構成了Action序列,完成一個較復雜的功能。統計數據資源平臺平臺負責在各個Action之間傳遞參數,這樣多種不同的BI產品便能夠協同工作了。

所謂解決方案(Solution),是基于統計數據資源平臺平臺的一個具體的BI應用。Solution與統計數據資源平臺平臺的關系和Web應用與應用服務器之間的關系十分類似。如圖 1所示,統計數據資源平臺平臺本身作為一個Web應用部署在應用服務器上,而Solution又作為一個“統計數據資源平臺應用”,部屬在統計數據資源平臺平臺上。Solution本身實質上是一系列Action序列的集合,這些序列在網頁上如何顯示,如何被調用,功能如何實現完全由統計數據資源平臺平臺來管理,這使得Solution的開發者,也就是統計數據資源平臺的使用者,可以將開發工作集中于具體的BI業務邏輯的開發上,而不用去關心網頁的設計、服務器的部署等等細節。

 

 

 

流程即Action序列,是Solution的基本組成單位,它由多個以某種順序執行的Action組成。Action是統計數據資源平臺平臺所提供的最基本的BI操作,大到生成一個報表,小到打印一行字,都可以是一個Action。Action之間可以順序執行,也可以有分支或循環。統計數據資源平臺平臺的“以流程為中心”是指整個平臺的工作核心就是如何解釋執行一個個Action序列的描述文件。用戶在做具體的BI應用開發時,也應當把精力集中在描述Action序列上。

統計數據資源平臺平臺將BI業務邏輯的開發以Solution的形式與系統的其它部分獨立開來,使得用戶可以隨心所欲的綜合運用各種不同的BI產品為自己服務,其設計理念十分值得稱道。

4統計數據資源平臺技術實現

4.1統計數據資源平臺運行系統的組成

統計數據資源平臺運行系統共有四部分組成: 統計數據資源平臺平臺資源庫(Repository)、統計數據資源平臺平臺、應用服務器和Solution目錄樹。

統計數據資源平臺平臺資源庫是統計數據資源平臺平臺運行時所需的外部數據的一種抽象。它存儲了定義,執行和審計解決方案(Solution)所必需的數據資源。資源庫中保存的信息主要包含四個部分:一是統計數據資源平臺平臺的配置信息;二是運行于統計數據資源平臺平臺上的Solution的元數據,如共有多少個Action,每個Action的描述文件的存放位置等等;三是統計數據資源平臺平臺第三方插件的私有信息;四是統計數據資源平臺平臺運行過程中的跟蹤和審計信息。在通常情況下,資源庫通常是一組數據庫服務。

 

如圖 2所示,統計數據資源平臺平臺運行于應用服務器容器內,并通過應用服務器接口訪問統計數據資源平臺資源庫(在這里資源庫實際上是一個數據庫);當有客戶請求道達統計數據資源平臺平臺時,它將根據客戶的請求解釋執行Solution目錄下的某個Action序列描述文件。本文關注的焦點是統計數據資源平臺平臺這一部分。

4.2統計數據資源平臺運行系統的配置文件

統計數據資源平臺平臺是一個復雜的軟件系統,擁有許多配置文件,這些配置文件在統計數據資源平臺系統的運行中起著至關重要的作用。總的來說共有三種配置文件:統計數據資源平臺平臺的Web應用配置文件;Solution的配置文件;統計數據資源平臺系統各個插件的私有配置文件。

統計數據資源平臺系統的Web應用配置文件主要是指WEB-INF目錄下的web.xml文件,在該文件中,有以下兩個配置項需要著重指出:

***屬性。該屬性配置了統計數據資源平臺系統在應用服務器內注冊的EventListener類,這些類在統計數據資源平臺系統的初始化、Session管理等方面都有很重要的作用。

預定義屬性“solution-path”,這個屬性是部署于統計數據資源平臺平臺上的Solution的根目錄,如果這個屬性設置錯誤,會導致統計數據資源平臺平臺找不到Solution根目錄的嚴重錯誤,這樣該平臺將無法提供BI服務。

統計數據資源平臺的Solution配置文件主要是指“solution-path”目錄下的統計數據資源平臺.xml文件,該文件規定了Solution相對于統計數據資源平臺平臺的配置信息,主要包括統計數據資源平臺平臺所需的數據源訪問類,各個插件的EventListener(參見“插件的加載與卸載” 一節),以及系統預定義的一些系統Action序列的相關信息。

統計數據資源平臺系統各個插件的私有配置文件存放在solution-path\system\***\(***為插件名稱)目錄下,不同插件有不同的私有配置文件,內容也千差萬別,需要使用者在用到某個插件時再做修改。

4.3基于統計數據資源平臺平臺的BI開發

基于統計數據資源平臺平臺的BI開發十分簡便,開發者只需要進行Solution的開發即可,而開發Solution,只需給出Solution中所包含的所有Action序列的描述文件即可。為了方便基于統計數據資源平臺平臺的BI應用開發,統計數據資源平臺項目組提供了一個基于Eclipse的集成開發環境:統計數據資源平臺DesignStudio。用戶僅需要以一種圖形化的形式輸入Action序列的描述,而由該開發工具產生相應的Action序列描述文件,十分方便。

5統計數據資源平臺平臺的軟件架構

5.1統計數據資源平臺平臺的總體結構

統計數據資源平臺平臺是統計數據資源平臺運行系統中的核心部分,它本身是一個Web應用,部署于一個J2EE兼容的應用服務器上。它又作為Solution的服務器存在著,是Solution中各個Action序列的解釋執行者。

 


如圖 3所示,統計數據資源平臺平臺大致可分為三個層次:界面層、核心層和插件層。界面層是外部用戶訪問統計數據資源平臺服務的接口,主要包含三個部分:UDDI、Web頁面、和Navigation Component。UDDI為外部應用程序或Web Service訪問統計數據資源平臺服務提供接口;Web頁面則為用戶通過瀏覽器訪問統計數據資源平臺服務提供接口;Navigation Component實質上是一組Servelet,它主要用于顯示當前部署在統計數據資源平臺平臺上的Solution中所包含的各個Action序列,用戶可在其中選擇需要執行的Action序列。

核心層主要由Solution Engine和它的Runtime環境組成。Solution Engine實質上是一個解釋執行Action序列描述文件的解釋器,它接收來自用戶界面的請求,這個請求通常是要求執行Solution中的某個Action序列。Solution Engine連同其Runtime環境就負責解釋執行這些Action序列。解釋執行過程中,出于調試和性能分析的需要,引入了一個Audit機制,該機制類似一個日志記錄系統,記錄統計數據資源平臺平臺運行過程中的一些動態過程。Solution Engine和Audit機制的運行都需要訪問許多相關的數據資源,這些數據資源被稱為“資源庫”,也就是圖中的各個Repository。

插件層主要包括了集成到統計數據資源平臺平臺中的各種BI產品,如Quartz、Jfree等等。從圖3中可以看出,插件層又可分為兩類模塊,一類叫作Component模塊,這種模塊是插件層與核心層的接口模塊,它們將各種不同的插件的功能以一個統一的接口提供給上層使用,起到一個功能抽象的作用。另一類則是形形色色的BI插件的具體實現,這通常由第三方開發者提供。各種插件運行過程中可能會用到自身的私有數據,這些數據在統計數據資源平臺平臺中也被抽象成為資源庫(Responsory),這使得不同的插件可以以一種統一的方式訪問自己的數據。

5.2統計數據資源平臺的界面層

統計數據資源平臺的界面層提供了外部訪問統計數據資源平臺服務的接口。由于統計數據資源平臺平臺可能的用戶存在多種,因此,界面層提供了許多不同的方式訪問統計數據資源平臺平臺服務,包括UDDI訪問,portlet、servelet、jsp等等。這使得統計數據資源平臺平臺的界面層顯得較為繁雜。本文僅以servelet為例,介紹統計數據資源平臺平臺界面層的靜態結構。

如圖 4所示,統計數據資源平臺平臺的Servelet全部從ServeletBase類繼承而來,而ServeletBase類又實現了HttpServelet接口。圖中所示的各個Servelet并不是真正部署于應用服務器上的提供界面顯示的Servelet,界面顯示的功能往往是另一些jsp文件來完成,這里的Servelet則為那些jsp文件提供相關的功能。例如圖中的ViewAction類就為jsp文件提供執行某個Process的功能。

5.3統計數據資源平臺的核心層

統計數據資源平臺核心層又可以分為四大部分:

一是統計數據資源平臺的系統維護部分,這部分負責系統的初始化、清理、參數配置等等工作。

二是統計數據資源平臺的服務處理部分,這部分是統計數據資源平臺系統核心層和界面層的接口,負責將來自界面層的請求傳遞給運行解釋部分,驅動它執行Solution的某個Process。

三是統計數據資源平臺的Solution描述部分,這部分負責將描述Solution的文件翻譯成方便統計數據資源平臺系統執行的表示形式。

四是統計數據資源平臺的運行解釋部分,這部分負責各個Action的執行及它們之間的參數傳遞。

5.3.1系統維護部分

系統維護部分是支持整個系統運行的基本框架,它主要負責統計數據資源平臺系統啟動時的初始化,全局參數配置,終止時的清理工作。如圖 5所示,這部分最核心的類是IApplicationContex接口的實現類。這些類是維護統計數據資源平臺平臺全局運行環境的類。從其組織層次可以看出,針對不同的環境,統計數據資源平臺平臺提供了不同的IApplicationContex實現類。針對那些需要不依賴應用服務器而直接運行的場合,應當使用StandaloneAplicationContext類;針對Portlet模式的應用,應當使用PortletApplicationContext類;針對典型的Web應用模式,則應當使用WebApplicationContext類。

 

 

 

由于統計數據資源平臺平臺多部署于J2EE兼容的應用服務器上,這就需要一種機制與應用服務器進行互操作,在服務器啟動時初始化統計數據資源平臺平臺。SolutionContextListener類提供了這樣的功能,它使得應用服務器在運行時自動調用統計數據資源平臺平臺的啟動代碼(詳見“統計數據資源平臺平臺的啟動與終止”一節)。

圖 5中的統計數據資源平臺System類是整個統計數據資源平臺平臺的訪問接口,所有對統計數據資源平臺平臺的操作都通過這個類來完成。其實,這個類的所有成員都是靜態成員,正是存放全局信息的理想位置。SystemSettings類則負責管理統計數據資源平臺平臺的所有配置信息,它通過讀取配置文件獲得這些信息。

 

5.3.2服務處理部分

統計數據資源平臺平臺的服務處理部分負責將來自界面層的服務請求轉發給適當的類(SlutionEngine)進行處理。如圖 6所示,這部分的核心是IActionRequestHandler接口,該接口封裝了對外提供服務的所有功能。BaseRequestHandler類實現了該接口,它實現了服務處理中的通用工作,即將請求傳遞給IRuntimeContext實現類。

此外,為了適應不同的界面層,BaseRequestHander類還有兩個派生類,HttpWebServiceRequestHandler類和HttpServeletRequestHandler類,分別處理來自Web頁面的請求和來自Servelet的請求。這時,服務請求需要通過SolutionEngine類才能傳遞給IRuntimeContext實現類。

 

5.3.3Solution描述部分

Solution描述部分的功能主要是描述一個Solution的具體內容,如圖 7所示,它的核心是兩個接口的實現類:IActionDifinition接口和IActionSequence接口。其中IActionDifinition接口的實現類描述一個Action的具體實現,IActionSequence則描述一個ActionSequence的具體實現。

 

 

除了描述Action和ActionSequence的類以外,該部分還包括描述Action的輸入輸出信息的類,那就是ActionResource類和IOutputHandler接口的實現類。ActionResource類描述一個Action的執行所需要的數據資源,而IOutputHandler接口實現類則負責將Action的輸出結果進行適當的處理返回給客戶。

從圖 7還可以看出,所有的Solution描述類都與RuntimeContext有直接的聯系,RuntimeContext類是解釋執行Solution中的ActionSequence的核心類,Solution描述類所描述的信息為RuntimeContext的解釋執行服務。圖中還有一個ParameterManager類,該類主要是在RuntimeContext運行過程中管理參數傳遞工作。

5.3.4運行解釋部分

運行解釋部分是整個統計數據資源平臺平臺的核心,它是解釋執行Solution中的Action序列的驅動引擎。這部分主要的類及其間的關系如圖 8所示。從圖中可以看出,這部分的核心是四個接口及其實現類:ISolutionEngine接口、IActionCompleteListener接口、IActionRequestHandler接口和IRuntimeContext接口。

ISolutionEngine接口的實現類是對這一部分功能的封裝(Fa?ade設計模式)。如圖 8所示,它有兩個實現類:SolutionEngineAgent和SolutionEngine,前者在統計數據資源平臺平臺的其他部分沒有找到任何的引用,似乎是廢棄不用的類,SolutionEngine則是當前統計數據資源平臺平臺的核心類。在SolutionEngine中有一個Eventlistener機制的實現,那就是IActionCompleteListener接口實現類,它允許某些類在某個Action執行完畢時,做一些有意義的操作。

 

IRequestHandler接口前文已經介紹過,是傳遞外部請求的接口。IRuntimeContext接口實現類則是解釋執行Action序列的核心,它的運行細節在“統計數據資源平臺的運行機制”一章中還有詳細介紹。

5.4統計數據資源平臺的插件層

 

 

統計數據資源平臺平臺中的插件是Solution中的Action的具體執行者,也是統計數據資源平臺平臺能夠集成眾多BI產品為己用的秘密之所在。統計數據資源平臺平臺中,使用Adapter設計模式構建插件層,它使用IComponent接口封裝了插件的公共接口,每個集成于統計數據資源平臺平臺的插件都必須提供IComponent接口的實現類。每個IComponent的實現類封裝了某個插件的一項功能,對應一種Action操作。一個第三方插件可能會提供多個IComponent接口的實現類,因為單個插件往往會提供多項功能。圖 9所示為Action、Component和插件之間的關系。

為了實現方便,統計數據資源平臺平臺還提供了另外一個類:ComponentBase,這個類實現了一些IComponent的公共操作,第三方插件往往繼承ComponentBase類而不直接繼承IComponent類。圖 10所示為Phentaho平臺內部提供的一些插件的類結構。第三方插件若要集成到Phentaho平臺中來,只需依據其功能編寫合適的IComponent接口的實現類即可,如圖 11所示,Quartz插件(該插件是一個任務調度器)就提供了兩個IComponent類:JobSchedulerComponent類用來完成任務調度工作;SchedularAdminComponent類則用來配置Quartz。

 

5.5統計數據資源平臺的資源庫系統

統計數據資源平臺將支持系統運行的所有外部數據抽象為“資源庫”的概念。資源庫的英文名稱為Repository,它可以是一個數據庫,也可以是一個數據文件,也可以是一組數據文件,甚至可以是運行時動態生成的內存數據。統計數據資源平臺平臺共有四種資源庫:Solution資源庫、Runtime資源庫、Content資源庫和Audit資源庫。它們構成了統計數據資源平臺獨具特色的資源庫系統。

5.5.1Solution 資源庫

所謂Solution資源庫,是指存放Solution描述文件的那個目錄及其子目錄中的所有文件。這些文件主要包括Action序列描述文件、Action序列界面顯示描述文件和Action序列圖標文件。其中后兩者都是用來控制Action序列在統計數據資源平臺界面層中的顯示效果的,Action序列描述文件則定義了Solution中的所有Action序列,它們是Solution資源庫中最重要的部分。

在統計數據資源平臺平臺中,管理和維護Solution資源庫的工作有一組專門的接口和類來完成,這些類及其之間的靜態關系如圖 12所示。SolutionRepository類是這一組類對外的接口,其功能完全通過它來訪問。FileInfo類提供了構成Solution類的各種文件的相關信息,如文件的類型、作者、地址等等;當SolutionReposUtil為SolutionRepository提供訪問具體文件的服務,當它要訪問某個Solution文件時,就需要通過SolutionReposUtil來獲取文件類FileSolutionFile的實例。

5.5.2Runtime資源庫

 

Runtime資源庫為RuntimeContex解釋執行Action序列提供必要環境信息。這些信息主要是Action執行過程中所需要到的參數及Action之間傳遞的參數。該資源庫只存在于內存中,有一組接口和類進行維護。

如圖 13所示,與Runtime資源庫相關的類主要有四個,它們與RuntimeContex類有著密切的依賴關系。RuntimeRepository并不直接存放Runtime數據,而是通過Session類獲取相關的數據。而RuntimeElement類則維護了足夠一個Action運行所需的Runtime數據,它維護多個HashMap,每個HashMap維護一種數據類型的數據,這些數據都通過它們的名字進行索引。需要注意的是圖中的SimpleRepository和SimpleRuntimeElement只是用作測試,沒有實際的用途。

 

5.5.3Content資源庫

Content資源庫本身是一組相互關聯的文件,這些文件可能存放在若干個不同的目錄中。Content資源庫則是以一種類似DAO方式提供對這些文件的訪問。在目前的統計數據資源平臺平臺中,只有一個Action序列與該資源庫相關,即清除Content資源庫內過時的內容,沒有任何一個類直接使用了該資源庫,所以該資源庫的具體功能還不甚明了。但從源代碼中的注釋以及該資源庫在軟件總體結構的對照結果中可以猜想,該資源庫應當是給各個具體的Action訪問磁盤文件提供的統一接口。

如圖 14所示,Content資源庫最主要的部分是四個接口:IContentRepository、IContentLocation、IContentItem、IContentItemFile。其中IContentRepository是外部訪問Content資源庫的接口,外部通過該接口得到資源庫中的數據。IContentLocation則負責管理Content資源庫中的一個目錄,而IContentItem則對應了該目錄下的某個文件(一個文件看作一項)。IContentItemFile則具體描述了一個Item所對應的文件。它本身之服務于IContentRepository的內部類,而不能被外部類訪問。如果以一種“父子關系”來描述四者之間的關系的話應當是:IContentRepository ?IContentLocation?IContentItem?IContentItemFile。

 

5.5.4Audit資源庫

Audit資源庫是用來存放審計信息的數據文件或數據庫連接。所謂審計信息是統計數據資源平臺平臺在運行過程中不斷產生的有關系統運行狀態的信息,類似日志信息。

如圖 15所示,所示,Audit信息庫的軟件接口主要由IAuditEntry接口進行描述。繼承該接口的類有兩個,一個是AuditFileEntry,用來抽象以數據文件作為Audit信息記錄媒質的Audit信息庫;另一個是AuditSQLEntry,用來抽象以數據庫作為Audit信息記錄媒質的Audit信息庫。可以看到,AuditSQLEntry還有一個數據庫連接類AuditConnection作為其訪問數據庫的接口。

6統計數據資源平臺的運行機制

6.1統計數據資源平臺平臺的啟動與終止

統計數據資源平臺本身是一個Web應用,在它部屬到應用服務器之后,其運行與終止都隨著應用服務器的啟動和終止完成。在應用服務器啟動時,統計數據資源平臺平臺需要完成自己的初始化工作,這些工作主要包括:

讀取應用服務器的相關參數,以決定Pentao自身的行為,如系統的語言、編碼、地區等等。

讀取統計數據資源平臺平臺自身及Solution相關的配置文件,初始化全局運行環境。

為所有已安裝的插件完成初始化工作。

 

在應用服務器終止時,統計數據資源平臺也要完成一些清理工作,這主要是依次完成所有已安裝插件的清理工作。

統計數據資源平臺平臺的初始化和清理工作是通過Servelet的EventListener機制來實現的。統計數據資源平臺平臺向應用服務器注冊一個SolutionContextListener類,該類繼承于ServletContextListener,在應用服務器啟動時,會自動調用它的contextInitialized方法,該方法會獲取統計數據資源平臺平臺的全局性配置信息,進而創建統計數據資源平臺自己的系統上下文WebApplicationContext,進而調用統計數據資源平臺System.init()方法完成初始化。

統計數據資源平臺System.init()函數主要完成了三個列表的初始化:其一是統計數據資源平臺System的Listener列表,該列表對各個插件的加載和卸載有重大意義;其二是系統的Publisher列表,該列表對于更新系統配置信息和Solution資源庫起重要作用(參見“統計數據資源平臺平臺的Publish機制”一節);其三是系統Action列表,該是系統預定義的Action序列列表。

當servlet上下文銷毀時,統計數據資源平臺的SolutionContextListener再一次激活,應用服務器調用其contextDestroyed()方法,進而調用統計數據資源平臺System::shutdown()結束統計數據資源平臺的運行。在統計數據資源平臺System::shutdown()方法中,已安裝的各個插件將被安全的清除,具體過程詳見“統計數據資源平臺的插件管理”一節。

6.2統計數據資源平臺Session的管理

 

如圖 16所示,統計數據資源平臺有自己的各種session類,它們都實現了I統計數據資源平臺Session接口(該接口實現了ServeletSession接口),但各自的功能各不相同。其中StandAlonSession這一支是為了實現獨立于應用服務器的統計數據資源平臺平臺而實現的;統計數據資源平臺HttpSession則是用于處理應用服務器Session相關的功能。本文主要關注后者。

統計數據資源平臺HttpSession的生命周期與應用服務器的Session類是緊密聯系的,它們之間的聯系仍然是通過EventListener機制來實現的。統計數據資源平臺平臺向應用服務器注冊一個統計數據資源平臺HttpSessionListener類,該類繼承于HttpSessionListener類,負責在應用服務器的Session類創建/銷毀時完成相關的工作。

需要注意的是,統計數據資源平臺平臺種存在一個工廠類:統計數據資源平臺SessionFactory,但沒有見到這個類的具體的調用,實際上PhentahoSession的創建并不在這里,而是在UIUtil(它取代了那個工廠類的功能)內部,也就是說,并不是系統Session一創建就創建統計數據資源平臺Session而是需要時才創建。這里統計數據資源平臺SessionFactory似乎是一個多余的東西,不知是開發者的失誤還是另有原因。

6.3統計數據資源平臺平臺的Publish機制

當用戶完成Solution的開發或修改時,需要讓統計數據資源平臺平臺重新掃描Solution的根目錄以反映這個修改;當用戶修改了統計數據資源平臺平臺的某些系統配置文件的時候,也需要統計數據資源平臺平臺刷新相關的設制以反映這種修改,這個過程成為發布(Publish)。

Publish原理:每個不同的可以發布的資源都擁有自己的Publisher類,統計數據資源平臺System類維護一個Publisher列表,當需要發布某個資源時,只要遍歷該列表調用列表中每個類的publish方法即可。

如圖 17所示,目前的統計數據資源平臺系統共有四個Publisher類,代表了三種可發布的資源,即:全局配置參數(Settings)、全局列表(GlobalListes)、Solution和Shark。全局配置參數和全局列表都是和統計數據資源平臺平臺的全局屬性相關的內容,Solution則是關于在統計數據資源平臺系統上部屬的Soltion所包含的Action序列的內容,Shark是一個第三方插件,可以看出某些插件也需要Publish動作才能使用。下面以Solution的Publish過程為例,介紹統計數據資源平臺系統Publish機制的具體工作過程,其他資源的Publish過程大同小異。

 

如圖 18所示,當用戶通過在網頁上點擊Publish按鈕時,Publish.jsp就會直接調用PhentahoSystem的publish方法進行發布;PhentahoSystem維護一個publisher列表,每次都遍歷該列表,尋找符合那個類型的對象,調用那個對象的publish方法;publisher對象會調用Responsory對象的Publish方法完成publish過程;對于SolutionPublisher來講,它調用SolutionRepository的publish()方法,最終SolutionResponsory通過調用porcessDir方法來掃描整個Solution目錄,以獲取該solution目錄下的所有Action序列的相關信息。

6.4Action序列的執行機制

 

統計數據資源平臺平臺的Solution的內容就是一系列Action序列,Action序列的解釋執行是統計數據資源平臺平臺最為核心的內容。在Solution中,每個Action序列有一個.xaction文件類描述,這實際上是xml格式的文件,統計數據資源平臺平臺通過解析該文件獲取有關Action序列如何執行的內容,從而解釋執行該Action序列。

 

Action序列在統計數據資源平臺平臺的Web頁面中的表示是一個圖標,當用戶點擊該圖標時,統計數據資源平臺平臺就執行這個Action序列。如圖 20所示,用戶點擊Action圖標時,請求發往ViewAction.jsp,該類的DoGet方法里面調用基類ServletBase中的GetPhentahoSession獲取Session,而ServeletBase則調用了UIUtil的GetPhentahoSession以獲取PhentahoSession對象。進而,ViewAction使用PhentahoSession對象初始化HttpServletRequestHandler對象,調用該對象父類BaseRequestHander的handleActionRequest方法,該方法中初始化SolutionEngine并執行Action序列,將結果返回。UIUtil幫助將結果格式化,發回客戶端。

SolutionEngine本身解釋執行Action序列的詳細執行過程也較復雜,如圖 21所示:

SolutionEngine的執行過程主要在excute方法內完成,該方法首先創建執行所需的各種環境,然后調用executeInternal完成執行過程。

executeInternal主要使用RuntimeContext完成執行,RuntimeContext首先檢查參數是否合法,如果合法就調用executeSequence執行序列動作。

executeSequence其實也只是準備一下參數,真正的執行方法是executeLoop,該方法處理每個Action序列的參數,然后調用performActions執行動作,performActions察看這個Action序列,首先檢查執行它的條件,條件滿足才執行,然后一項一項開始執行,若遇到一個IActionSequence,就遞歸調用executeLoop,如果是IActionDefinition,就調用executeAction執行該Action。

executeAction初始化相關的Component,并調用executeComponent,之后還要處理消息Listener,發送處理完畢的消息。

executeAction通過actionDefinition.getComponent().execute()完成Component的動作。

performActions會從actionDefinition中取出Componet的執行輸出。并繼續執行下一個Action。

 

6.5統計數據資源平臺的插件管理

6.5.1插件的加載與卸載

許多插件在使用之前需要有一個初始化的過程,在使用結束時還需要做一些清除工作,統計數據資源平臺平臺使用EventListener機制為這些插件提供了完成這些工作的機會。

統計數據資源平臺的EventListener機制是通過統計數據資源平臺System類來實現的。統計數據資源平臺System維護一個I統計數據資源平臺SystemListener的列表,當統計數據資源平臺系統初始化時(詳見“統計數據資源平臺平臺的啟動與終止”一節),會遍歷該列表,依次調用其中對象的startup()方法,當統計數據資源平臺平臺終止時,統計數據資源平臺System.shutdown()方法會再次遍歷該列表,依次調用表中對象的shutdown方法。該列表中所包含的類的配置可以通過修改統計數據資源平臺.xml文件來完成。

 

如圖 22所示,Quartz插件的初始化、清除工作就是由QuartzSystemListener類完成的。該類實現了I統計數據資源平臺SystemListener接口,在startup方法中,它從文件中讀取自己的配置參數;在shutdown方法中,它釋放Scheduler所占用的內存。

6.5.2插件調用的參數傳遞

插件在完成其功能時,往往需要從外部獲取部分參數,執行完畢后又要傳遞輸出結果給調用方。按照參與參數傳遞的對象類型的不同,這一過程可劃分為兩個部分:一是參數從界面層傳遞給Action的實現Component,二是兩個Action之間傳遞輸出/輸入參數。

統計數據資源平臺平臺有一組專門的接口和類來完成這兩項工作。如圖 23所示,矩形框外部的接口和類負責將參數從界面層傳遞給Action的實現Component;矩形框內部的接口和類負責Action之間的參數傳遞。前者的核心接口是IParameterprovider,依據是用場景的不同衍生出了許多不同的Parameterprovider類:HttpRequestParameterprovider負責傳遞用戶請求“Post”過來的參數,HttpSesionParameterporvider則負責傳遞具有Session作用域的參數;JVMParameterProvider則負責傳遞Java虛擬機相關的參數。后者的核心是IActionParameter接口,ParameterManager則維護了多個參數名和參數值的Map,以便RuntimeContext執行過程中隨時使用。

 

6.5.3插件的參數配置機制

許多插件要正常工作需要配置一些參數,例如Quartz插件本身就需要配置任務調度用數據庫的JNDI地址等等參數。這些參數往往存放在一些配置文件中,統計數據資源平臺平臺為這些插件訪問自己的配置文件提供了統一的接口。

在統計數據資源平臺平臺中,所有插件的配置文件都存放在Solution-path/system/***/目錄下,其中***代表插件的名字,例如Quartz的配置文件就存放在Solution-path/system/Quartz/目錄下。插件對配置文件的訪問是通過ISystemSettings接口的實現類來完成的,GetSystemSettingProperty()方法用來獲取相關插件的配置參數,該方法會訪問正確的配置文件,讀出相應的配置信息。

.6.6統計數據資源平臺的Audict機制

 

統計數據資源平臺的Audit機制主要包含兩個主體:被Audit的對象和Audit執行者。一個需要Audit的對象必須繼承IAuditable接口,Audit執行者通過訪問IAuditable接口以獲得被Audit對象的Audit信息,并將其存入Audit信息庫。它們之間的關系如圖 24所示。從圖中可以看出Audit信息庫可能是一個文件(AuditFileEntry類),也可能是一個數據庫連接(AuditSQLEntry類)。

 

如圖 25所示,在統計數據資源平臺平臺運行過程中,一旦需要記錄信息,則調用AuditHelper的靜態方法audit來完成Audit動作;AuditHelper進一步調用 AuditEntry.auditJobDuration靜態方法;AuditEntry類是維護單一IAuditEntry接口對象,直接調用它的IAuditEntry.auditAll方法來完成Audit功能。

在當前的統計數據資源平臺平臺實現中,共有兩種AuditEntry:AuditFileEntry和AuditSQLEntry,前者把記錄信息寫入文件,后者則寫入相關的數據庫。

 

6.7統計數據資源平臺核心與Style分離的機制

Phentaho核心與其外部“皮膚”是分離配置的。在部署Phentaho時必須將另一個名為統計數據資源平臺-style的Web應用同時部署,這樣Phentaho頁面內的圖片圖標才能夠正常顯示。

這樣一來,統計數據資源平臺平臺的核心邏輯與其UI感觀分離開來,可以分別進行配置。在實現時,Phentaho只是在生成Html頁面時將其中的圖片文件鏈接的地址前加了一個統計數據資源平臺-style目錄前綴而已,沒什么特別。只是一個小小的改變,便換來了巨大的好處,這也顯示出其設計人員的匠心獨具。

7統計數據資源平臺相關的設計模式

統計數據資源平臺平臺的軟件設計綜合運用了多種設計模式,典型的包括EventListenr模式、抽象工廠模式,工廠方法模式、Singleton模式、Fa?ade模式、代理模式等等。許多部分還混合使用多種設計模式,收到了很好的效果。本文中所講述的設計模式并不是統計數據資源平臺中所用到的全部,只是其中的幾個典型。

7.1EventListener模式

EventListener模式在統計數據資源平臺平臺中的明確應用主要有三處:第一處是在系統初始化和終止時,用來加載和卸載集成的插件;第二處是實現其Publish機制時,也是用EventListener模式;第三處是在用戶請求開始執行和結束執行時,給某些插件做動作的機會,這一機制在目前的Web版的統計數據資源平臺平臺中尚無實際用處,應當是留給后繼開發者的接口。

 

如圖 26所示,統計數據資源平臺的EventListener機制的事件發出者是統計數據資源平臺System類,事件響應者是I統計數據資源平臺SystemListener接口的實現類。統計數據資源平臺System維護一個I統計數據資源平臺SystemListener接口的列表,系統初始化時,統計數據資源平臺System類通過SystemSettings類訪問配置文件,向列表中填入各個事件響應類,可以說它就是Gluer。圖中所示的兩個事件響應類:SharkSystemListener是第三方插件Shark注冊的響應類,globalObjectInitializer則是用來處理全局環境信息的統計數據資源平臺系統類。


 

如圖 27所示,統計數據資源平臺平臺的Publish機制也是通過EventListener模式來實現的。每個可發布的資源都對應一個Publish消息的相應類,與SystemEventListener一樣,統計數據資源平臺System類維護一個Publish消息相應類的列表,這個列表是在系統初始化時,由SystemSettings類從配置文件中讀出所有的Publisher類信息,并由統計數據資源平臺System類插入相關對象而得來的。當用戶啟動Publish過程時,統計數據資源平臺System類就向各個Publisher類發送Publish消息。

7.2抽象工廠模式

抽象工廠模式在統計數據資源平臺平臺中的應用很多,其中最典型的就是資源庫的實現,下面以Runtime資源庫的實現為例,講述抽象工廠模式在資源庫實現中的應用。圖 28為Runtime資源庫的抽象工廠模式類圖。其中,IRuntimeRepository所扮演的角色就是抽象工廠接口,實現它的RuntimeRepository則是一個具體的工廠類,用戶RuntimeContext要創建一個IRuntimeElement類型的實例,則需要調用RuntimeRepository的newRuntimeElement()方法。RuntimeContext不能直接實例化IRuntimeElement的實現類,因為它的構造函數被聲明為protected。

此外,統計數據資源平臺對URL的處理部分的架構也是抽象工廠的典型應用。如圖 29所示,這里的抽象工廠類是I統計數據資源平臺UrlFactory接口,PortletUrlFactory則是一個具體的工廠,工廠類所構造的對象是I統計數據資源平臺Url接口的實現類。

7.3工廠方法模式

工廠方法模式在統計數據資源平臺平臺中的應用十分廣泛,許多類的創建都是以這種模式進行的,這里只列舉其中的一個:ContentRepository。如圖 30所示,ContentRepository類擁有一個靜態方法用于構造自身對象。這有點像Singleton模式,但由于這個方法沒有保證該類對象的個數特征,因此不應當算作Singleton模式,而應當算作工廠方法的一種特殊形式。

7.4Facade模式

 

如圖 31所使,統計數據資源平臺System是整個統計數據資源平臺平臺核心層的對外接口,外部訪問統計數據資源平臺平臺的各種功能完全通過該接口完成,這是一個典型的Fa?ade設計模式。

7.5Adapter模式

能夠將各種第三方BI產品以插件形式集成進來是統計數據資源平臺的特色之一,但是各種第三方產品所提供的功能接口完全不同,這就需要使用Adapter模式將它們的接口統一到統計數據資源平臺的框架之下。

圖 32所示為統計數據資源平臺集成Quartz插件所使用的Adapter模式類圖。RuntimeContex所使用的接口為IComponent,而Quartz所提供的接口與此不同于是用類JobSchedulerComponent作為Adapter將Quartz的接口與IComponent統一起來。

7.6復合模式

統計數據資源平臺平臺中單獨使用一種設計模式的地方很少,往往是多種設計模式綜合使用,集各種設計模式之所長,以達到更好的效果。其中Audit機制的實現方案就是十分典型的代表。

 

如圖 33所示,這里混合使用了工廠方法、Facade和Singleton設計模式,整個統計數據資源平臺平臺只有一個IAuditEntry接口實現類的對象來完成整個系統信息的記錄。該對象被封裝為AuditEntry類的私有成員auditEntry;整個Audit功能,完全通過AuditHelper暴露給使用者,外部不能看到除AuditHelper以外的類,AuditHelper就是這里的Facade;同時,AuditEntry類又是通過工廠方法來創建具體的IAudit對象的,這里的工廠方法不很明顯,因為它是一段靜態代碼,在AuditEntry類初始化時執行。

8統計數據資源平臺源代碼文件結構

統計數據資源平臺的源代碼總體上分為八個包:core、data、jfree、messages、plugin、ui、何util。其中core內所含代碼為統計數據資源平臺的核心代碼,另外七個包是統計數據資源平臺平臺的外圍擴展。通常在core包內定義了統計數據資源平臺的各個接口,而在外圍的七個包中則定義這些接口的具體實現。

Core包內有包含13個子包:admin、audit、component、connection、publisher、runtime、repository、services、session、solution、system、ui、util。其中admin包內定義了統計數據資源平臺平臺的數據源的相關內容(這似乎與包的名字相左);audit、runtime、solution、system四個包則構成了統計數據資源平臺核心層的主要部分,其他幾個包大部分是與前文所述的外圍七個包對應的,定義了其中的接口。

 

 


 

英文版|員工門戶|聯系博和利|法律條款|網站地圖津ICP備05011245號
竞彩混合过关什么意思