技术文档

首页->技术文档->统计数据资源平台设计说明

统计数据资源平台设计说明书

来源: 作者: 日期: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号