基于 SOA的多参与方项目协同管理系统的架构机制研究

舒志强 文俊浩 王 静

(1.重庆大学计算机学院,重庆 400030;2.中国建筑科学研究院,北京 100013)

1 引言

在 21世纪这个信息时代,各个企业在激烈的市场竞争环境中,对变化的市场和客户化的产品和服务做出快速而准确的反应已经成为企业赖以生存和发展的前提[1]。具有不同资源与优势的项目参与方为了共同的目标,必然会越来越多地需要密切的合作,通过组成多参与方的项目协同合作模式而实现“共赢”。在这种多方参与的项目管理模式下:一是需要对资源、数据进行集中管理,实现多个应用系统的集成和整合;二是各参与方自身业务的快速变化,需要不断更新原有业务流程和应用模式、快速搭建并实施新的应用系统[2]。

当前实现多参与方的项目管理的信息化技术主要是基于传统企业集成技术(EAI),如基于 CORBA、DCOM、RMI。其不足之处主要有以下几点:首先,传统企业集成技术依赖于特定的厂商,不利于来自不同厂商软件应用程序之间相互操作,无法扩展到安全与事务管理这样的更高级别的服务;其次,传统企业集成技术存在紧耦合,使得各个应用程序的服务器端与客户端的类型是唯一对应的关系,接口的任何更改都将影响服务器与客户端之间的通讯,极大的约束了程序的可维护性与灵活性;第三,传统企业集成技术与平台绑定,如 DCOM不适用于非 Windows平台,RMI也只能在 JVM(Java虚拟机)平台上工作。

SOA(Service Oriented Architecture)是一种基于网络、松耦合、多应用集成的技术解决方案,是目前信息系统技术发展的主流方向。按照“软件就是服务”的观点,SOA将分布在网络中的各种软件资源看作是不同的服务内容,而不需要考虑每个应用是用什么编程语言开发或在什么操作系统下运行,在这种模式下,一个应用或软件的一部分就是一种服务。通过将注意力放在服务上,应用程序能够集中起来提供更加丰富、目的性更强的商业流程。因此,基于 SOA的多参与方的项目协同管理系统将会更加真实地反映与实际业务模型的结合、更加贴切地满足多方参与的项目管理现实业务需求。

2 基于 SOA的多参与方项目协同管理系统的整体架构设计

图1 基于 SOA的多参与方项目协同管理系统的整体架构示意图

基于 SOA的多参与方项目协同管理系统的整体架构代表了系统的高层次抽象,着眼于多方参与项目管理业务应用的实际需求,采用松耦合架构特点,将业务应用划分为独立的业务功能或流程,分为协同层、流程层、服务层、服务组件层、应用服务层、数据服务层等,不同层次的服务主要通过企业服务总线 ESB进行调用,见图1。

2.1 协同层

协同层为多参与方提供了一个统一的信息门户平台,使得参与方之间能够更容易地进行协作,例如即时通讯、查看任务列表、查看发布信息、单点登录等,也能够把已有数据、服务或界面快速组合到新应用中。通过协同层,用户不再与多个孤立的系统进行交互,而是面对一个有机的整体。

协同层由与参与方交互的服务所组成,主要实现流程、服务、应用和参与方之间的协同。与所有的服务一样,这些服务接口应基于某种标准,如 HTTP、SOAP、JMS、WSRP Portlet等,提供对 Ajax、Web Service、Java Client等多种客户端接入方式的支持,使得这些服务可以作为共享服务的一种来进行应用,比如:业务服务、表示服务可以是一些简单的操作(天气预报,计算器等),也可以是一些复杂的流程(合同管理、项目审批等)。

2.2 流程层

流程层主要实现跨系统之间业务状态的维护,主要实现项目系统中分散在 ERP或各个参与方信息系统之中流程的自动化,以达到多参与方不同信息系统之间的集成。例如,定义三个业务服务:投标服务、合同服务以及项目服务,这三个服务可能来自不同参与方(如投标服务、合同服务分别来自经营部门不同科室系统、项目服务一些功能服务可能是第三方提供的专业化服务),是相互独立的,不存在服务的调用关系,流程层则按照业务需求以一定的顺序(投标、合同、项目)调用这三个服务,实现一个完整的业务流程逻辑。

基于 XML的 Web服务业务流程执行语言(WSBPEL,Web Services Business Process Execution Language)定义了一种标准的流程集成语言,以业务流程及其参与者的交互为基础提供了一种快速复合和协调服务的方法。WSBPEL可以表示用于在多参与方之间交换交互模式的流程(抽象流程)和意在转换内部逻辑的流程(具体可执行流程)。当所需的应用程序或复合以流程为中心,并且涉及到调用服务并用流程逻辑和简单的映射将其连在一起时,WSBPEL是实现此层应用程序比较好的方法[3]。

2.3 服务层

服务层主要提供支持、公开业务的服务,这些服务将应用系统提供的逻辑以标准化的方式暴露出来,从而屏蔽了业务逻辑的不同实现方式,使调用者不需要关心逻辑的具体实现技术与细节。处于服务层的服务可以获取各个参与方企业的业务功能组件或业务单元特定组件,以及第三方提供的专业服务组件,以服务描述的形式具体化他们的接口子集[4]。

服务层将组件层实现的各个组件按照统一的组件模型装配成服务的方式暴露给其他模块或系统。服务组件架构(Service Component Architecture,SCA)是 IBM和 BEA等公司提出的一种面向服务的SOA编程模型,用来实现组件接口与传输协议解耦的问题,从而极大简化业务组件的开发、组装和部署流程,提高了系统的可移植性。SCA包括的元素主要有:对应实现层的服务组件(Component)、对应架构层的服务模块组件(Composite)及对应业务层的服务域组件 (Domain)。服务 (Service)、参考(Reference)、连线(Wire)等辅助性元素是以上三个组件的组成部分。SCA体系结构如图2所示。

图2 SCA体系结构图[5]

2.4 服务组件层

服务组件层由负责实现具体业务功能和保持公开服务的服务质量(QoS,Quality of Service)的参与方企业组件组成。这些组件通过架构最佳实践应用程序来负责确保服务等级协议(SLA,Service-Level Agreement)的一致[4],为某项服务提供了实现、认识、或者操作。

服务层的各种服务通过调用这些组件完成相应的工作。按照服务层中基于 SOA的SCA标准,对于服务组件的实现可以有多种不同方式,如基于Web Service、Java、EJB、RMI、JMS。一般情况下,采用 Web Service的实现方式。Web Service属于分布式组件的一种,是可互操作的分布式应用程序,以一种标准的形式完成企业内部和外部的集成和互调,主要用来支持网络上异构系统之间的互操作。其体系结构基于三种角色的协作(服务提供者、服务注册中心或服务目录、服务消费者),主要有服务的发布、查找及绑定操作。Web Service体系结构如图3所示。

2.5 应用服务层

应用服务层向服务组件层提供与数据库、操作系统、网络资源等交互的所有自定义的或者打包的应用程序服务,以供服务组件层进行调用。这些应用服务可以支持热插拔的方式部署,也可以使用AOP、依赖注入的方式编程实现。

应用服务层主要包含各参与方企业遗留系统应用服务(如 CRM和 ERP打包应用程序等)、第三方提供的专业化应用服务(如邮件服务、短信服务、视频服务等),以及用户自定义的应用服务(如公文审批、合同会签、图纸设校审程序服务等)。该层的实现技术主要基于 J2EE或.net平台,结合 REST、AOP、MVC等编程模式,及针对第三方专业化服务的 Web服务封装等方式进行应用服务实现。

2.6 数据服务层

数据服务层主要实现系统的数据整合,需要通过一个数据编程模式统一对不同数据源(比如数据库、Web服务、轻量级目录访问协议、遗留应用程序等)的访问,特别是针对不同参与方系统遗留数据的统一访问,完成不同参与方系统数据源的数据标准化(数据标准化就是通过实现统一的数据接口,以统一的数据视图展示数据;提供统一的数据模型机制,实现数据的持久化、查找等功能,屏蔽不同的数据源[5])。

服务数据对象(SDO,Service Data Objects)是一种针对在不同的数据源之间使用统一的数据编程模型的规范标准,统一了不同类型数据源的数据编程,提供了数据编程架构和 API。SDO使得开发人员可以对不同的数据源以统一的方式访问和操纵数据,从而大大简化了开发过程。SDO基本结构如图4所示。

3 基于 SOA的多参与方项目协同管理系统的架构机制实现

多参与方项目协同管理主要目的是实现各个参与方之间的高效协作,因此多参与方项目协同管理系统的架构机制实现要点在于多参与方项目信息门户的实现,以及多参与方项目权限管理的实现。

3.1 基于 SOA的多参与方项目信息门户架构机制实现

传统意义上的项目信息门户采用紧耦合的方式,门户中的所有功能都紧密集成到一个门户系统中,门户功能模块与其他系统相互隔裂,并且当需要在门户中增加或者删除个别功能时,需要对门户系统作较大幅度的调整。基于 SOA的多参与方项目信息门户具有良好的用户体验,通过用户可定制的内容展现方式,提供参与方企业员工间、参与方企业和客户、参与方企业之间良好的连通性,使得项目信息门户在数据共享、应用系统间通信、及第三方的专业服务融入等方面具有较好的聚合效应,实现丰富、高效、一致的应用界面。

基于 SOA架构的多参与方的项目信息门户实现展现逻辑和业务逻辑的分离,使得用户界面中的应用符合 SOA的可重用性和松散耦合原则。通过采用这种方式,当新服务和复合应用程序不断产生时,门户能够继续为终端用户提供所需的用户界面并保持概念一致性[7]。其架构框图如图5所示。

图5 基于SOA的多参与方项目信息门户实现机制示意图

该架构主要结合了当前主流的 Web2.0实现技术,其中:

(1)展现逻辑层

主要作用是实现门户与用户进行交互并展示独立 IT服务视图的功能。使用的主要技术如FLEX、Ajax、JavaFX、Mash-up(网站采用混合技术搭建)等可以提供良好的用户体验,用户可以按照个人偏好自行定义表现层;使得门户能支持同步/异步的通讯机制及访问蓝牙通讯、相机和 GPS等近似桌面系统的功能。

(2)访问通讯机制层

主要作用是实现展现逻辑层与业务逻辑相分离。传统的项目信息门户由于基于紧耦合模式,其访问通讯机制层概念相对模糊。结合 SOA架构理念,该层主要实现多参与方应用系统之间接口通讯,提供展现逻辑层与业务逻辑进行通讯的相关协议支持。如针对 Portlet、Web服务、WSBPEL业务流程服务通讯的 SOAP协议,基于 REST思想的面向服务 UI通讯的 HTTP协议,及传统企业集成技术(EAI)通讯机制 CORBA、DCOM、RMI等。

(3)业务逻辑层

主要作用是实现展现逻辑层所需求的具体业务功能并提供独立 IT服务,如第三方提供的专业化服务、互联网公共服务等。

3.2 基于 SOA的多参与方项目权限管理架构机制实现

多参与方项目权限管理的关键是建立有效的安全访问控制机制,结合多参与方项目业务特点与实际需求,本文采用基于角色的面向服务架构的访问控制机制。

基于角色的访问控制模型(RBAC)目前是国际上流行的先进的访问控制方法[8],是一种灵活、高效的访问控制方法。RBAC通过在用户和权限之间引入角色的概念,使系统管理员可以按着实际需要将各个用户定义为不同的角色,并设置和角色相对应的访问权限,这样访问权限和角色相关联,角色再与用户关联,从而实现了用户与访问权限的逻辑分离,RBAC基本模型见图6。

图6 RBAC基本模型示意图

图7 基于 SOA的多参与方项目权限管理实现机制示意图

多参与方参与的项目协同管理系统需要协调处理多个不同参与方及众多系统资源,设计并实现基于 SOA的多参与方参与项目的项目权限管理功能,可以使得用户在异构的、跨域的环境中能够“一次登录,处处通行”,能有效避免各参与方在系统之间重复的登录和冗余的用户权限验证。多参与方项目权限管理采用面向服务架构的理念,将公共的业务“权限管理模块”包装成独立的 Web服务,并集成到企业服务总线中。异构的系统可以通过企业服务总线代理访问“权限管理服务”。在服务接口不变的情况下,权限管理服务与调用它的业务系统可以独立演化。因此整个架构中的系统是平台无关的,松耦合的,并且“权限管理服务”可重用,如图7所示。

4 结束语

本文主要研究了基于 SOA的多参与方项目协同管理系统的架构机制,分析了基于 SOA的多参与方项目协同管理系统的实现技术,详细阐述了多参与方项目协同管理系统中信息门户及权限管理基于 SOA的实现机制及相关技术。

结合国家“十一五”科技支撑计划子课题“勘察设计企业多参与方参与的项目协同管理系统”的研究成果,当前勘察设计企业正逐步在向总承包模式过渡,越来越多企业为了整合优势资源,需要将自身某个专业外包给其他企业,或者凭借优势专业服务而加入另一个多方参与的项目。工程总承包模式已是当前工程建设项目的一种生产模式,而多方参与的项目管理是传统项目过渡到工程总承包项目的前提。研究多参与方的项目管理系统架构机制,对于实施工程总承包模式的项目管理有一定的参考与借鉴意义。

[1]高孟.虚拟企业业务流程构建技术研究[D].济南:山东大学硕士学位论文,2009.4

[2]林光炎.基于 SOA的集成架构研究及在浙江移动CRM的应用[D].杭州:浙江工商大学硕士学位论文,2009.2

[3]余浩,朱成,丁鹏.SOA实践——构建基于 Jave Web服务和BPEL的企业级应用[M].北京:电子工业出版社,2009

[4]佟伟.基于 SCA的轻量级 BPEL引擎的设计与实现[D].北京:北京工业大学硕士学位论文,2008.4

[5]焦烈焱,冯兴智,杨洪波.SOA中国路线图(实施版)[M].北京:清华大学出版社,2009

[6]郑冀之.面向服务架构的企业集成设计与研究[D].华东师范大学,2008.12

[7]费圣英,马苏龙,鲁庭瑞,等.电力企业信息化 SOA实践[D].南京:南京大学出版社,2007

[8]孙群.多组织多用户条件下基于角色的访问控制[D].济南:山东大学硕士学位论文,2005.4

[9]马智亮,罗小春,李志新.基于万维网的工程项目管理系统综述[J].土木工程学报,2006,39(10):117-126..

[10]王静,陈岱林,梁晓.勘察设计企业信息化实施方案探讨[J].施工技术,2005,34(2):16-18.

[11]文俊浩,宋鹏飞,田清.基于 SOA的勘察设计企业业务架构与信息集成平台的研究与应用[J].北京:土木建筑工程信息技术.2009,1(1):24-28.

[12]Tiejun Gu,Bingyong Tang,YiLi.Study on Virtual Work flow of Collaborative Commerce Oriented Web Services Composition Path Optimization Algorithm[C].2009 International Conference on In formation Technology and Computer Science.Wuxi,China:[s.n.],2009:142-145.

[13]童晓阳.基于Web服务的分布式广域服务协作框架及原型的初步研究[J].计算机集成制造系统,2007,13(6):1184-1190.

[14]Ali Arsanjani.基于服务的建模和架构.[EB/OL].(2004-12-18)[2010-05-17]http://www.um l.org.cn/zjjs/200608044.htm