作者：曾坤，吳大愚，張百達

注：此文檔爲2006年國防科大計算機學院高級軟件工程課程實習大作業。若需要交流，可以發郵件到[email protected]

Pentaho項目簡介

Pentaho BI 平臺是一個以過程爲核心，面向解決方案的，可擴展的商務智能平臺。其目的在於將一系列企業級BI產品、開源軟件、API等等組件集成起來，方便商務智能應用的開發。它的出現，使得一系列的面向商務智能的獨立產品如Jfree、Quartz等等，能夠集成在一起，構成一項項複雜的、完整的商務智能解決方案。

目前，Pentaho的主要組成元素包括報表生成、分析、數據挖掘和工作流管理等等。這些組件通過J2EE、WebService、SOAP、HTTP、Java、JavaScript、Portals等技術集成到Pentaho平臺中來。Pentaho的發行，主要以Pentaho SDK的形式進行。

Pentaho SDK共包含五個部分：Pentaho平臺、Pentaho示例數據庫、可獨立運行的Pentaho平臺、Pentaho解決方案示例和一個預先配製好的Pentaho網絡服務器。其中Pentaho平臺是Pentaho平臺最主要的部分，囊括了Pentaho平臺源代碼的主體；Pentaho數據庫爲Pentaho平臺的正常運行提供的數據服務，包括配置信息、Solution相關的信息等等，對於Pentaho平臺來說它不是必須的，通過配置是可以用其它數據庫服務取代的；可獨立運行的Pentaho平臺是Pentaho平臺的獨立運行模式的示例，它演示瞭如何使Pentaho平臺在沒有應用服務器支持的情況下獨立運行；Pentaho解決方案示例是一個Eclipse工程，用來演示如何爲Pentaho平臺開發相關的商業智能解決方案。

本文主要針對部署於應用服務器上的Pentaho平臺，介紹該平臺的設計思想、軟件架構、運行機制及相關的設計模式等等內容。

Pentaho的設計思想

Pentaho的設計思想主要體現在三個方面，一是“集成化”，二是“面向解決方案”，三是“以流程爲中心”。

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

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

圖 1 Pentaho平臺層次關係圖

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

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

Pentaho的運行系統

Pentaho運行系統的組成

Pentaho運行系統共有四部分組成： Pentaho平臺資源庫（Repository）、Pentaho平臺、應用服務器和Solution目錄樹。

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

圖 2 Pentaho平臺運行系統示意圖

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

Pentaho運行系統的配置文件

Pentaho平臺是一個複雜的軟件系統，擁有許多配置文件，這些配置文件在Pentaho系統的運行中起着至關重要的作用。總的來說共有三種配置文件：Pentaho平臺的Web應用配置文件；Solution的配置文件；Pentaho系統各個插件的私有配置文件。

Pentaho系統的Web應用配置文件主要是指WEB-INF目錄下的web.xml文件，在該文件中，有以下兩個配置項需要着重指出：

1. <listener>***<listener>屬性。該屬性配置了Pentaho系統在應用服務器內註冊的EventListener類，這些類在Pentaho系統的初始化、Session管理等方面都有很重要的作用。

2. 預定義屬性“solution-path”，這個屬性是部署於Pentaho平臺上的Solution的根目錄，如果這個屬性設置錯誤，會導致Pentaho平臺找不到Solution根目錄的嚴重錯誤，這樣該平臺將無法提供BI服務。

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

Pentaho系統各個插件的私有配置文件存放在solution-path/system/***/(***爲插件名稱)目錄下，不同插件有不同的私有配置文件，內容也千差萬別，需要使用者在用到某個插件時再做修改。

基於Pentaho平臺的BI開發

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

Pentaho平臺的軟件架構

Pentaho平臺的總體結構

Pentaho平臺是Pentaho運行系統中的核心部分，它本身是一個Web應用，部署於一個J2EE兼容的應用服務器上。它又作爲Solution的服務器存在着，是Solution中各個Action序列的解釋執行者。

圖 3 Pentaho平臺總體結構圖

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

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

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

Pentaho的界面層

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

圖 4 Pentaho界面層Servelet類圖

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

Pentaho的核心層

Pentaho核心層又可以分爲四大部分：

l 一是Pentaho的系統維護部分，這部分負責系統的初始化、清理、參數配置等等工作。

l 二是Pentaho的服務處理部分，這部分是Pentaho系統核心層和界面層的接口，負責將來自界面層的請求傳遞給運行解釋部分，驅動它執行Solution的某個Process。

l 三是Pentaho的Solution描述部分，這部分負責將描述Solution的文件翻譯成方便Pentaho系統執行的表示形式。

l 四是Pentaho的運行解釋部分，這部分負責各個Action的執行及它們之間的參數傳遞。

系統維護部分

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

圖 5 Pentaho核心層系統維護部分類圖

由於Pentaho平臺多部署於J2EE兼容的應用服務器上，這就需要一種機制與應用服務器進行互操作，在服務器啓動時初始化Pentaho平臺。SolutionContextListener類提供了這樣的功能，它使得應用服務器在運行時自動調用Pentaho平臺的啓動代碼（詳見“Pentaho平臺的啓動與終止”一節）。

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

服務處理部分

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

圖 6 Pentaho核心層服務處理部分類圖

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

Solution描述部分

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

圖 7 Pentaho核心層Solution描述部分類圖

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

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

運行解釋部分

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

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

圖 8 Pentaho 核心層運行解釋部分類圖

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

Pentaho的插件層

圖 9 Pentaho平臺插件功能映射示意圖

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

圖 10 Pentaho平臺插件類圖

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

圖 11 Pentaho平臺的Quartz插件接口類圖

Pentaho的資源庫系統

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

Solution 資源庫

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

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

圖 12 Pentaho平臺Solution資源庫類圖

Runtime資源庫

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

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

圖 13 Pentaho平臺Runtime資源庫類圖

Content資源庫

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

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

圖 14 Content資源庫類圖

Audit資源庫

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

圖 15 Pentaho平臺Audit資源庫類圖

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

Pentaho的運行機制

Pentaho平臺的啓動與終止

Pentaho本身是一個Web應用，在它部屬到應用服務器之後，其運行與終止都隨着應用服務器的啓動和終止完成。在應用服務器啓動時，Pentaho平臺需要完成自己的初始化工作，這些工作主要包括：

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

2. 讀取Pentaho平臺自身及Solution相關的配置文件，初始化全局運行環境。

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

在應用服務器終止時，Pentaho也要完成一些清理工作，這主要是依次完成所有已安裝插件的清理工作。

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

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

當servlet上下文銷燬時，pentaho的SolutionContextListener再一次激活，應用服務器調用其contextDestroyed()方法，進而調用PentahoSystem::shutdown()結束pentaho的運行。在PentahoSystem::shutdown()方法中，已安裝的各個插件將被安全的清除，具體過程詳見“Pentaho的插件管理”一節。

PentahoSession的管理

圖 16 Pentaho平臺的各種Session類

如圖 16所示，pentaho有自己的各種session類，它們都實現了IPentahoSession接口（該接口實現了ServeletSession接口），但各自的功能各不相同。其中StandAlonSession這一支是爲了實現獨立於應用服務器的Pentaho平臺而實現的；PentahoHttpSession則是用於處理應用服務器Session相關的功能。本文主要關注後者。

PentahoHttpSession的生命週期與應用服務器的Session類是緊密聯繫的，它們之間的聯繫仍然是通過EventListener機制來實現的。Pentaho平臺嚮應用服務器註冊一個PentahoHttpSessionListener類，該類繼承於HttpSessionListener類，負責在應用服務器的Session類創建/銷燬時完成相關的工作。

需要注意的是，Pentaho平臺種存在一個工廠類：PentahoSessionFactory，但沒有見到這個類的具體的調用，實際上PhentahoSession的創建並不在這裏，而是在UIUtil（它取代了那個工廠類的功能）內部，也就是說，並不是系統Session一創建就創建PentahoSession而是需要時才創建。這裏PentahoSessionFactory似乎是一個多餘的東西，不知是開發者的失誤還是另有原因。

Pentaho平臺的Publish機制

當用戶完成Solution的開發或修改時，需要讓Pentaho平臺重新掃描Solution的根目錄以反映這個修改；當用戶修改了Pentaho平臺的某些系統配置文件的時候，也需要Pentaho平臺刷新相關的設制以反映這種修改，這個過程成爲發佈（Publish）。

圖 17 Pentaho平臺的Publish機制類圖

Publish原理：每個不同的可以發佈的資源都擁有自己的Publisher類，PentahoSystem類維護一個Publisher列表，當需要發佈某個資源時，只要遍歷該列表調用列表中每個類的publish方法即可。

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

圖 18 Pentaho平臺Solution Publish機制順序圖

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

Action序列的執行機制

圖 19 Pentaho平臺Action序列執行機構類圖

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

圖 20 Pentaho平臺Action序列執行順序圖

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

SolutionEngine本身解釋執行Action序列的詳細執行過程也較複雜，如圖 21所示：

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

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

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

4. executeAction初始化相關的Component，並調用executeComponent，之後還要處理消息Listener，發送處理完畢的消息。

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

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

圖 21 SolutionEngine具體執行過程

Pentaho的插件管理

插件的加載與卸載

許多插件在使用之前需要有一個初始化的過程，在使用結束時還需要做一些清除工作，Pentaho平臺使用EventListener機制爲這些插件提供了完成這些工作的機會。

Pentaho的EventListener機制是通過PentahoSystem類來實現的。PentahoSystem維護一個IPentahoSystemListener的列表，當Pentaho系統初始化時（詳見“Pentaho平臺的啓動與終止”一節），會遍歷該列表，依次調用其中對象的startup()方法，當Pentaho平臺終止時，PentahoSystem.shutdown()方法會再次遍歷該列表，依次調用表中對象的shutdown方法。該列表中所包含的類的配置可以通過修改pentaho.xml文件來完成。

圖 22 PentahoSystem的EventListener機制

如圖 22所示，Quartz插件的初始化、清除工作就是由QuartzSystemListener類完成的。該類實現了IPentahoSystemListener接口，在startup方法中，它從文件中讀取自己的配置參數；在shutdown方法中，它釋放Scheduler所佔用的內存。

插件調用的參數傳遞

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

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

圖 23 參數傳遞機制實現類圖

插件的參數配置機制

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

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

Pentaho的Audict機制

圖 24 Pentaho的Audit機制實現類圖

Pentaho的Audit機制主要包含兩個主體：被Audit的對象和Audit執行者。一個需要Audit的對象必須繼承IAuditable接口，Audit執行者通過訪問IAuditable接口以獲得被Audit對象的Audit信息，並將其存入Audit信息庫。它們之間的關係如圖 24所示。從圖中可以看出Audit信息庫可能是一個文件（AuditFileEntry類），也可能是一個數據庫連接（AuditSQLEntry類）。

圖 25 Pentaho平臺Audit機制順序圖

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

在當前的Pentaho平臺實現中，共有兩種AuditEntry：AuditFileEntry和AuditSQLEntry，前者把記錄信息寫入文件，後者則寫入相關的數據庫。

Pentaho核心與Style分離的機制

Phentaho核心與其外部“皮膚”是分離配置的。在部署Phentaho時必須將另一個名爲pentaho-style的Web應用同時部署，這樣Phentaho頁面內的圖片圖標才能夠正常顯示。

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

Pentaho相關的設計模式

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

EventListener模式

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

圖 26 Pentaho的SystemEventListener模式

如圖 26所示，Pentaho的EventListener機制的事件發出者是PentahoSystem類，事件響應者是IPentahoSystemListener接口的實現類。PentahoSystem維護一個IPentahoSystemListener接口的列表，系統初始化時，PentahoSystem類通過SystemSettings類訪問配置文件，向列表中填入各個事件響應類，可以說它就是Gluer。圖中所示的兩個事件響應類：SharkSystemListener是第三方插件Shark註冊的響應類，globalObjectInitializer則是用來處理全局環境信息的Pentaho系統類。

圖 27 Pentaho平臺Publish機制的EventListener模式

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

抽象工廠模式

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

圖 28 Runtime資源庫的抽象工廠模式

此外，Pentaho對URL的處理部分的架構也是抽象工廠的典型應用。如圖 29所示，這裏的抽象工廠類是IPentahoUrlFactory接口，PortletUrlFactory則是一個具體的工廠，工廠類所構造的對象是IPentahoUrl接口的實現類。

圖 29 Url處理抽象工廠模式

工廠方法模式

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

圖 30 ContentRepositoy中的工廠方法

Facade模式

圖 31 Pentaho核心得Façade模式

如圖 31所使，PentahoSystem是整個Pentaho平臺核心層的對外接口，外部訪問Pentaho平臺的各種功能完全通過該接口完成，這是一個典型的Façade設計模式。

Adapter模式

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

圖 32 Pentaho集成各種插件的Adapter模式

圖 32所示爲Pentaho集成Quartz插件所使用的Adapter模式類圖。RuntimeContex所使用的接口爲IComponent，而Quartz所提供的接口與此不同於是用類JobSchedulerComponent作爲Adapter將Quartz的接口與IComponent統一起來。

複合模式

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

圖 33 Audit所用的複合模式

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

Pentaho源代碼文件結構

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

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

總結與收穫

無論是從應用創意的角度，還是軟件工程的角度來看，Pentaho都有自己的獨到之處。它綜合運用多種設計模式，使得軟件系統結構靈活，可擴展性好，可維護性強。可能是因爲版本不斷更新，Pentaho平臺內出現了一些多餘的代碼，但瑕不掩瑜，Pentaho仍舊堪稱面向對象設計的典範。

通過對Pentaho代碼的研讀，我們對設計模式的概念及其應用有了更深刻的理解，對面向對象設計思想有了更全面的把握，對J2EE平臺的軟件開發模式也有了更清晰的認識，可說是受益匪淺。

Pentaho源代碼閱讀報告