Pentaho源代码阅读报告

导读：
　　
　　
　　
　　
　　作者：曾坤，吴大愚，张百达
　　
　　
　　注：此文档为2006年国防科大计算机学院高级软件工程课程实习大作业。若需要交流，可以发邮件到dywu_xa@sina.com
　　
　　
　　
　　
　　
　　
　　
　　
　　目录
　　Pentaho项目简介.......................................................................................................... 3
　　Pentaho的设计思想...................................................................................................... 3
　　Pentaho的运行系统...................................................................................................... 4
　　Pentaho运行系统的组成...................................................................................... 4
　　Pentaho运行系统的配置文件.............................................................................. 5
　　基于Pentaho平台的BI开发............................................................................... 5
　　Pentaho平台的软件架构.............................................................................................. 6
　　Pentaho平台的总体结构...................................................................................... 6
　　Pentaho的界面层.................................................................................................. 7
　　Pentaho的核心层.................................................................................................. 8
　　系统维护部分............................................................................................... 8
　　服务处理部分............................................................................................... 9
　　Solution描述部分........................................................................................ 10
　　运行解释部分.............................................................................................. 11
　　Pentaho的插件层................................................................................................ 12
　　Pentaho的资源库系统........................................................................................ 13
　　Solution 资源库........................................................................................... 13
　　Runtime资源库............................................................................................ 14
　　Content资源库............................................................................................ 15
　　Audit资源库................................................................................................ 16
　　Pentaho的运行机制.................................................................................................... 17
　　Pentaho平台的启动与终止................................................................................ 17
　　PentahoSession的管理......................................................................................... 18
　　Pentaho平台的Publish机制............................................................................... 19
　　Action序列的执行机制...................................................................................... 20
　　Pentaho的插件管理............................................................................................ 22
　　插件的加载与卸载..................................................................................... 22
　　插件调用的参数传递................................................................................. 23
　　插件的参数配置机制................................................................................. 24
　　Pentaho的Audict机制........................................................................................ 25
　　Pentaho核心与Style分离的机制....................................................................... 26
　　Pentaho相关的设计模式............................................................................................ 26
　　EventListener模式................................................................................................ 26
　　抽象工厂模式..................................................................................................... 28
　　工厂方法模式..................................................................................................... 29
　　Facade模式......................................................................................................... 30
　　Adapter模式........................................................................................................ 30
　　复合模式............................................................................................................. 31
　　Pentaho源代码文件结构............................................................................................ 32
　　总结与收获................................................................................................................. 32
　　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业务逻辑的开发上，而不用去关心网页的设计、服务器的部署等等细节。
　　图1Pentaho平台层次关系图
　　流程即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平台运行过程中的跟踪和审计信息。在通常情况下，资源库通常是一组数据库服务。
　　图2Pentaho平台运行系统示意图
　　如图2所示，Pentaho平台运行于应用服务器容器内，并通过应用服务器接口访问Pentaho资源库（在这里资源库实际上是一个数据库）；当有客户请求道达Pentaho平台时，它将根据客户的请求解释执行Solution目录下的某个Action序列描述文件。本文关注的焦点是Pentaho平台这一部分。
　　Pentaho运行系统的配置文件
　　Pentaho平台是一个复杂的软件系统，拥有许多配置文件，这些配置文件在Pentaho系统的运行中起着至关重要的作用。总的来说共有三种配置文件：Pentaho平台的Web应用配置文件；Solution的配置文件；Pentaho系统各个插件的私有配置文件。
　　Pentaho系统的Web应用配置文件主要是指WEB-INF目录下的web.xml文件，在该文件中，有以下两个配置项需要着重指出：
　　1. *** 属性。该属性配置了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序列的解释执行者。
　　图3Pentaho平台总体结构图
　　如图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平台界面层的静态结构。
　　图4Pentaho界面层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类。
　　图5Pentaho核心层系统维护部分类图
　　由于Pentaho平台多部署于J2EE兼容的应用服务器上，这就需要一种机制与应用服务器进行互操作，在服务器启动时初始化Pentaho平台。SolutionContextListener类提供了这样的功能，它使得应用服务器在运行时自动调用Pentaho平台的启动代码（详见“Pentaho平台的启动与终止”一节）。
　　图5中的PentahoSystem类是整个Pentaho平台的访问接口，所有对Pentaho平台的操作都通过这个类来完成。其实，这个类的所有成员都是静态成员，正是存放全局信息的理想位置。SystemSettings类则负责管理Pentaho平台的所有配置信息，它通过读取配置文件获得这些信息。
　　
　　服务处理部分
　　Pentaho平台的服务处理部分负责将来自界面层的服务请求转发给适当的类（SlutionEngine）进行处理。如图6所示，这部分的核心是IActionRequestHandler接口，该接口封装了对外提供服务的所有功能。BaseRequestHandler类实现了该接口，它实现了服务处理中的通用工作，即将请求传递给IRuntimeContext实现类。
　　图6Pentaho核心层服务处理部分类图
　　此外，为了适应不同的界面层，BaseRequestHander类还有两个派生类，HttpWebServiceRequestHandler类和HttpServeletRequestHandler类，分别处理来自Web页面的请求和来自Servelet的请求。这时，服务请求需要通过SolutionEngine类才能传递给IRuntimeContext实现类。
　　
　　Solution描述部分
　　Solution描述部分的功能主要是描述一个Solution的具体内容，如图7所示，它的核心是两个接口的实现类：IActionDifinition接口和IActionSequence接口。其中IActionDifinition接口的实现类描述一个Action的具体实现，IActionSequence则描述一个ActionSequence的具体实现。
　　图7Pentaho核心层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接口的实现类是对这一部分功能的封装（Faade设计模式）。如图8所示，它有两个实现类：SolutionEngineAgent和SolutionEngine，前者在Pentaho平台的其他部分没有找到任何的引用，似乎是废弃不用的类，SolutionEngine则是当前Pentaho平台的核心类。在SolutionEngine中有一个Eventlistener机制的实现，那就是IActionCompleteListener接口实现类，它允许某些类在某个Action执行完毕时，做一些有意义的操作。
　　
　　图8Pentaho 核心层运行解释部分类图
　　
　　IRequestHandler接口前文已经介绍过，是传递外部请求的接口。IRuntimeContext接口实现类则是解释执行Action序列的核心，它的运行细节在“Pentaho的运行机制”一章中还有详细介绍。
　　Pentaho的插件层
　　图9Pentaho平台插件功能映射示意图
　　
　　Pentaho平台中的插件是Solution中的Action的具体执行者，也是Pentaho平台能够集成众多BI产品为己用的秘密之所在。Pentaho平台中，使用Adapter设计模式构建插件层，它使用IComponent接口封装了插件的公共接口，每个集成于Pentaho平台的插件都必须提供IComponent接口的实现类。每个IComponent的实现类封装了某个插件的一项功能，对应一种Action操作。一个第三方插件可能会提供多个IComponent接口的实现类，因为单个插件往往会提供多项功能。图9所示为Action、Component和插件之间的关系。
　　
　　图10Pentaho平台插件类图
　　
　　为了实现方便，Pentaho平台还提供了另外一个类：ComponentBase，这个类实现了一些IComponent的公共操作，第三方插件往往继承ComponentBase类而不直接继承IComponent类。图10所示为Phentaho平台内部提供的一些插件的类结构。第三方插件若要集成到Phentaho平台中来，只需依据其功能编写合适的IComponent接口的实现类即可，如图11所示，Quartz插件（该插件是一个任务调度器）就提供了两个IComponent类：JobSchedulerComponent类用来完成任务调度工作；SchedularAdminComponent类则用来配置Quartz。
　　图11Pentaho平台的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的实例。
　　图12Pentaho平台Solution资源库类图
　　Runtime资源库
　　
　　Runtime资源库为RuntimeContex解释执行Action序列提供必要环境信息。这些信息主要是Action执行过程中所需要到的参数及Action之间传递的参数。该资源库只存在于内存中，有一组接口和类进行维护。
　　如图13所示，与Runtime资源库相关的类主要有四个，它们与RuntimeContex类有着密切的依赖关系。RuntimeRepository并不直接存放Runtime数据，而是通过Session类获取相关的数据。而RuntimeElement类则维护了足够一个Action运行所需的Runtime数据，它维护多个HashMap，每个HashMap维护一种数据类型的数据，这些数据都通过它们的名字进行索引。需要注意的是图中的SimpleRepository和SimpleRuntimeElement只是用作测试，没有实际的用途。
　　图13Pentaho平台Runtime资源库类图
　　Content资源库
　　Content资源库本身是一组相互关联的文件，这些文件可能存放在若干个不同的目录中。Content资源库则是以一种类似DAO方式提供对这些文件的访问。在目前的Pentaho平台中，只有一个Action序列与该资源库相关，即清除Content资源库内过时的内容，没有任何一个类直接使用了该资源库，所以该资源库的具体功能还不甚明了。但从源代码中的注释以及该资源库在软件总体结构的对照结果中可以猜想，该资源库应当是给各个具体的Action访问磁盘文件提供的统一接口。
　　如图14所示，Content资源库最主要的部分是四个接口：IContentRepository、IContentLocation、IContentItem、IContentItemFile。其中IContentRepository是外部访问Content资源库的接口，外部通过该接口得到资源库中的数据。IContentLocation则负责管理Content资源库中的一个目录，而IContentItem则对应了该目录下的某个文件（一个文件看作一项）。IContentItemFile则具体描述了一个Item所对应的文件。它本身之服务于IContentRepository的内部类，而不能被外部类访问。如果以一种“父子关系”来描述四者之间的关系的话应当是：IContentRepository IContentLocationIContentItemIContentItemFile。
　　图14Content资源库类图
　　Audit资源库
　　Audit资源库是用来存放审计信息的数据文件或数据库连接。所谓审计信息是Pentaho平台在运行过程中不断产生的有关系统运行状态的信息，类似日志信息。
　　图15Pentaho平台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的管理
　　图16Pentaho平台的各种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）。
　　图17Pentaho平台的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过程大同小异。
　　图18Pentaho平台Solution Publish机制顺序图
　　如图18所示，当用户通过在网页上点击Publish按钮时，Publish.jsp就会直接调用PhentahoSystem的publish方法进行发布；PhentahoSystem维护一个publisher列表，每次都遍历该列表，寻找符合那个类型的对象，调用那个对象的publish方法；publisher对象会调用Responsory对象的Publish方法完成publish过程；对于SolutionPublisher来讲，它调用SolutionRepository的publish()方法，最终SolutionResponsory通过调用porcessDir方法来扫描整个Solution目录，以获取该solution目录下的所有Action序列的相关信息。
　　Action序列的执行机制
　　图19Pentaho平台Action序列执行机构类图
　　Pentaho平台的Solution的内容就是一系列Action序列，Action序列的解释执行是Pentaho平台最为核心的内容。在Solution中，每个Action序列有一个.xaction文件类描述，这实际上是xml格式的文件，Pentaho平台通过解析该文件获取有关Action序列如何执行的内容，从而解释执行该Action序列。
　　图20Pentaho平台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。
　　图21SolutionEngine具体执行过程
　　Pentaho的插件管理
　　插件的加载与卸载
　　许多插件在使用之前需要有一个初始化的过程，在使用结束时还需要做一些清除工作，Pentaho平台使用EventListener机制为这些插件提供了完成这些工作的机会。
　　Pentaho的EventListener机制是通过PentahoSystem类来实现的。PentahoSystem维护一个IPentahoSystemListener的列表，当Pentaho系统初始化时（详见“Pentaho平台的启动与终止”一节），会遍历该列表，依次调用其中对象的startup()方法，当Pentaho平台终止时，PentahoSystem.shutdown()方法会再次遍历该列表，依次调用表中对象的shutdown方法。该列表中所包含的类的配置可以通过修改pentaho.xml文件来完成。
　　图22PentahoSystem的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机制
　　图24Pentaho的Audit机制实现类图
　　Pentaho的Audit机制主要包含两个主体：被Audit的对象和Audit执行者。一个需要Audit的对象必须继承IAuditable接口，Audit执行者通过访问IAuditable接口以获得被Audit对象的Audit信息，并将其存入Audit信息库。它们之间的关系如图24所示。从图中可以看出Audit信息库可能是一个文件（AuditFileEntry类），也可能是一个数据库连接（AuditSQLEntry类）。
　　图25Pentaho平台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模式、Faade模式、代理模式等等。许多部分还混合使用多种设计模式，收到了很好的效果。本文中所讲述的设计模式并不是Pentaho中所用到的全部，只是其中的几个典型。
　　EventListener模式
　　EventListener模式在Pentaho平台中的明确应用主要有三处：第一处是在系统初始化和终止时，用来加载和卸载集成的插件；第二处是实现其Publish机制时，也是用EventListener模式；第三处是在用户请求开始执行和结束执行时，给某些插件做动作的机会，这一机制在目前的Web版的Pentaho平台中尚无实际用处，应当是留给后继开发者的接口。
　　图26Pentaho的SystemEventListener模式
　　
　　如图26所示，Pentaho的EventListener机制的事件发出者是PentahoSystem类，事件响应者是IPentahoSystemListener接口的实现类。PentahoSystem维护一个IPentahoSystemListener接口的列表，系统初始化时，PentahoSystem类通过SystemSettings类访问配置文件，向列表中填入各个事件响应类，可以说它就是Gluer。图中所示的两个事件响应类：SharkSystemListener是第三方插件Shark注册的响应类，globalObjectInitializer则是用来处理全局环境信息的Pentaho系统类。
　　图27Pentaho平台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。
　　图28Runtime资源库的抽象工厂模式
　　此外，Pentaho对URL的处理部分的架构也是抽象工厂的典型应用。如图29所示，这里的抽象工厂类是IPentahoUrlFactory接口，PortletUrlFactory则是一个具体的工厂，工厂类所构造的对象是IPentahoUrl接口的实现类。
　　图29Url处理抽象工厂模式
　　工厂方法模式
　　工厂方法模式在Pentaho平台中的应用十分广泛，许多类的创建都是以这种模式进行的，这里只列举其中的一个：ContentRepository。如图30所示，ContentRepository类拥有一个静态方法用于构造自身对象。这有点像Singleton模式，但由于这个方法没有保证该类对象的个数特征，因此不应当算作Singleton模式，而应当算作工厂方法的一种特殊形式。
　　图30ContentRepositoy中的工厂方法
　　Facade模式
　　图31Pentaho核心得Faade模式
　　如图31所使，PentahoSystem是整个Pentaho平台核心层的对外接口，外部访问Pentaho平台的各种功能完全通过该接口完成，这是一个典型的Faade设计模式。
　　Adapter模式
　　能够将各种第三方BI产品以插件形式集成进来是Pentaho的特色之一，但是各种第三方产品所提供的功能接口完全不同，这就需要使用Adapter模式将它们的接口统一到Pentaho的框架之下。
　　图32Pentaho集成各种插件的Adapter模式
　　图32所示为Pentaho集成Quartz插件所使用的Adapter模式类图。RuntimeContex所使用的接口为IComponent，而Quartz所提供的接口与此不同于是用类JobSchedulerComponent作为Adapter将Quartz的接口与IComponent统一起来。
　　复合模式
　　Pentaho平台中单独使用一种设计模式的地方很少，往往是多种设计模式综合使用，集各种设计模式之所长，以达到更好的效果。其中Audit机制的实现方案就是十分典型的代表。
　　图33Audit所用的复合模式
　　如图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平台的软件开发模式也有了更清晰的认识，可说是受益匪浅。
　　
　　Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1240753

本文转自
http://blog.csdn.net/dust_bug/archive/2006/09/18/1240753.aspx