基于SOA的异构系统集成构架的研究

王静蕾

(郑州旅游职业学院招生就业办，郑州450009)

1.引言

随着社会信息化的发展，异构应用系统集成问题日趋明显，人们从各个角度尝试解决相关异构系统之间的互操作问题，使用面向服务的架构(SOA)是其一种方法，它对于解决集成问题，有着明显的优势，但业界一直以来对SOA看法却并不统一。我国的SOA应用，也正经历着由点到面的发展过程。因此，本文主要是提出通过基于SOA的思想，以ESB为核心、以SDO+BPEL为组件编程开发模型，来解决集成问题。力求使集成以极小的投资短期内达到预期成效。

2.关键技术分析

2.1 SOA

面向服务的架构SOA(Service-Oriented architecture)是一个以服务为组件的模型，一种面向服务的架构，一种服务驱动的主流信息系统设计方法。它促使各系统中相关联的服务按需求进行重组，从而变成新的服务，同时实现服务的创新。这样的系统能够快速、便捷地满足不断变化的服务需求，而且系统中的服务流程具备高度的灵活性，系统资源也得以重用。利用SOA实现系统和数据的集成即是为系统、企业乃至行业进行功能和数据整合时提供一个框架，使这个框架中的组件更灵活地适应千变万化的服务需求。

2.2 ESB

在实现SOA参考构架时，许多研究提到了一种“企业服务总线(Enterprise Service Bus，ESB)”的概念。它是从面向服务的架构发展而来的，是实现SOA的基础设施，它采用一条“总线”的模式来管理和简化应用集成之间的拓扑结构，是传统中间件技术与XML、Web服务等技术结合的产物。ESB的基本原理:基于SOA架构，通过标准的整合技术将Web Services和XML等技术融入到统一的分布式架构中，实现统一并易于部署、可管理的整合基础设施。ESB能够提供连接，达到业务之间的互操作、数据映射和路由的作用，以及其他一些如安全和监测等附加功能。ESB被誉为SOA参考架构的中心构件，ESB更是起到了网络中最基本的连接中枢作用，是当下SOA系统的必要元素。

2.3 SDO

服务数据对象SDO(Service Data Object)是一种针对在不同的数据源之间使用统一的数据编程模型的一种规范说明。它是以对象为中心的层次树型数据模型，不仅可以解决异构数据的兼容性问题，还提出了一个简单并且统一的模式供服务处理相关的数据。SDO将各种各样的数据访问模型用统一的抽象数据实体来代替，用以创建、更新、搜索或者删除服务实现所使用的业务数据。它致力于为不同来源和格式的服务数据提供统一处理的方式。它的工作原理是用一种单一的、统一的方式来访问和操作异构数据源中的数据，这些异构数据源可以是关系型数据库、XML数据源、Web服务、企业遗留系统中的数据，在处理的同时提供相应的机制将数据同其来源分离。SDO被视为SOA解决方案中典型的数据信息集成技术。

2.4 BPEL

业务流程执行语言BPEL(Business Process Execution Language)是一种使用XML编写的编程语言，它以XML、Web服务等众多规范为基础，定义了用于业务流程建模的、以业务流程和其参与者交互为基础的业务流程描述语法。其作用是把一系列具有不同功能但之间却有着相互关系的服务关联在一起，然后依照某种逻辑方式来共同完成某项任务的这个过程。简言之，即对系统中的业务流程进行编排，实现自动化。BPEL与Web服务标准相融合，可以轻松的与各种环境进行跨系统、跨企业的互操作，在SOA系统中，它可以提供一种理想方式把服务编排入整个商业流程，这是当前最为成熟且已被各大公司热衷的业务流程建模的标准。

3.系统的框架设计

本文以“高校迎新系统”为例，旨在建立一个通用的框架将各异构系统进行集成。集成系统囊括新生报到过程的各个环节，它是一个面向学校所有院系、招办、财务室等相关行政管理部门和所有应届新生的综合性信息管理系统。它起着将参与新生报到的相关部门子系统中的服务实现统一的调用以及数据的统一、共享和查询。基于这种设计理念，以下就郑州旅游职业学院实际情况，重点说明对于整个集成系统的框架分析。

首先说明在迎新过程中所涉及部门的职能。

招办注册处:主要提供新生入学注册功能，并对入学状态进行统计。

财务处:收费、补交费用、日常退费和各种收费统计汇总等。

教务处:制定和分配班级、学号规则;新生专业调整申请及处理、新生信息管理等。

学生处:新生绿色通道申请及处理、分配宿舍资源，明确学生的宿舍区，汇总学生宿舍床位信息等。

目前的研究成果中框架设计主要有针对Web Services的，也有针对ESB或者是针对SCA的，但大多数只是侧重于其一，本文将这些技术有机的进行结合，在实现异构系统集成时，主要采用了自顶向下的分析方法和这种框架相结合，首先根据客户端的业务需求进行分析，对业务流程采取端到端的形式进行逐层分解，直到分解为原子构件为止。其次和六层构架结合起来分析:①在业务流程层针对客户端所需工作流程，反向分解出所需的服务。②在服务层明确需要调用哪些Web服务。③ESB层对哪些服务进行部署。④业务组件层需要有什么样的组件和构件。⑤最终将这些原子构件和组件对应到资源层不同的子系统中。综上所述，将系统的框架分为六层进行设计如图1所示。

图1 系统框架图

3.1 客户应用层

该层是一个门户，也是终端用户直接面对的程序操作界面，是访问集成系统的入口，它作为用户接口和外界进行数据交互。它以开放的形式使业务流程和服务暴露给用户，能够对权限进行验证，保证用户的安全，并且依据用户的需求提供个性化的服务。服务消费者通过该层提供的访问接口调用企业的应用服务。该层在多层架构中起到的作用是屏蔽了服务与访问系统客户端的所有表现逻辑，用户使用单一的访问入口，输入业务需求到下一层，该层则构造会话管理，控制业务服务访问。

3.2 业务流程层

该层是对服务请求进行流程管理，通过使用BPEL定义业务服务流程以达到某种业务目的。关键步骤是业务逻辑从服务注册中心查找并调用相关的服务，然后进行业务流程编排，形成一个满足调用需求的业务流程。这一层主要是根据用户的业务需求来组装服务层已经封装好的服务，此层实现的最大障碍不是技术，关键在于分析与理解系统领域业务。业务流程层的目的是随着企业的业务需求变化，只需调整服务间的组装方式就可快速响应。目前实现业务流程控制的业界标准是BPEL，它能够指出用什么样的顺序调用封装好的服务。它是基于XML的，通过包装Web服务。

简言之，在此层用BPEL实现流程的控制，流程层的任务是利用已经封装好的各种服务，通过配合、编排服务，构建集成系统的业务流程，服务的不同组合方式代表了不同的业务流程，服务可共同协作成为一个单独的应用程序。

3.3 服务层

这一层中主要元素是已确定公开且被发现的服务。主要是提供相应的数据接口和企业应用接口服务，对企业内部各种EIS(主管信息系统)进行Web服务封装，将封装好的服务暴露给其他模块或者其他系统。该层主要由四种服务组成，即原子服务、组合服务、流程服务和外部服务。其中原子服务是细粒度服务，它以实体为核心;由原子服务组合而成的是组合服务，它根据某种需求和简单合成原子服务而来。第三种服务流程是把原子服务或是组合服务进行流程编排而来的粗料度服务。最后，来自于企业系统外部的服务，它也是一种粗粒度的服务，并且封装了服务的具体实现，通过对外提供的描述服务接口调用。将最基本的原子服务装配为组合服务，将组合服务装配为更大粒度的具有业务语义的流程服务即是该层的核心思想。通过这种组合和装配由总线调用满足某个特定业务功能的一系列服务组件。

框架中服务层的作用是，将放在ESB上的由组件层实现的构件，装配成服务，通过ESB总线暴露给其他模块或其他系统。这一层的思想核心:将服务发现或者静态绑定，之后被调用或组合成复合服务，它们的接口均是以WDSL形式对外发布的，通过ESB总线调用满足业务的相关原子服务或者组合服务。

3.4 ESB 层

该层主要对用户请求消息以及回执消息的整个过程进行处理，包括消息监听器、消息处理器、注册中心以及安全组件等。ESB是整个集成应用系统的核心，起着桥梁作用。它集成了诸如日志、安全、审计等服务和消息机制，提供了服务注册和服务网的存储，把服务网中的服务关系通过利用BPEL对其业务进行描述并进行实现，最后以总线型的结构实现底层服务组件的调用。服务交互的参与方并不直接交互，而是通过总线交互，它在架构中工作原理:对业务组件层封装好的组件建立监听和入站服务，一但监听站收到服务请求，便将调用入站服务，根据它描述的信息将服务请求放置服务总线寻找服务提供者，一但找到后根据服务组件的WSDL路径地址创建出站服务，出站服务将所调用的服务提供给服务请求者。这样，降低了服务提供者和使用者服务的耦合度，整合调用过程相对于客户端是透明的，因此具有该体系结构的业务应用可以适应客户端各种业务与技术的变化。

3.5 业务组件层

该层由各个组件组成，用于实现领域相关的业务逻辑，支持业务建模，良好的业务建模是系统成功的基础。该层利用SDO技术来实现标准的封装和映射，封装业务建模的数据结构。业务组件层支持数据访问，包括了对数据查询和保存、更新以及删除等操作，它同时提供了三种类型的组件实现方式:Java构件、逻辑构件、工作流。通过对这三种构件组装、调用运算逻辑，或者相互调用来实现业务操作。一个逻辑构件定义了一套业务操作的接口，用WSDL对专有的API做出描述，以中立的方式发送至ESB总线，以HTTP/SOAP消息传输方式与外层进行交互。其它模块调用时，不必关心这个业务属于哪种构件，只需调用相应的接口便可。

3.6 资源层

最底层资源层主要功能是对原始系统的数据资源进行整合，通过在原有系统中采用的Java平台和J2EE，可以提供丰富的数据编程模型和API，可它们都是分散的，不能满足对于整体框架的服务。不仅如此，原来系统中的一些技术功能已不够丰富，无法满足集成系统的需求，而且采用的技术也是难以实现的。因此，在这里使用SDO数据模型，用统一的处理方式将不同来源和格式的服务数据进行访问和操作，创建一个统一的数据访问层，这样，就可向组件层提供SDO数据，使得应用程序不再依赖于数据库，而是独立于整个持久化技术。实现了为异构数据源提供数据访问的方案

在集成系统实现时，每一层都对应有相关的技术。资源层主要是完成SDO数据建模;业务组件层完成构件的组装并且调用运算逻辑实现业务操作，将业务操作以中立的方式发送至ESB总线;ESB总线主要完成消息的路由、服务管理和动态转换;在服务层将原子服务进行组装且通过端口调用ESB上的其它服务继而在业务流程层实现服务的BPEL流程编排，将满足要求的服务提供给客户应用层。由此完成了对遗留系统的服务集成。在对集成系统进行整体规划和逐步实施过程中，始终遵循着信息开放性和标准性，理念和技术的先进性及成熟性，结构的可扩展性和可维护性，系统的实用性、创新性，操作的安全性及保密性，软硬件的集约性和易操作性等原则。

4.结束语

由于各高校的信息化建设的程度不尽相同，本文主要是对于原先已存在大量的异构信息系统的情况，从架构上寻找出一个通用的方案。SOA是一种比较新型的软件体系结构，能较好地克服传统集成方法，将面向服务的架构思想应用于集成系统当中。它能够混搭不同的执行环境、服务接口并与执行技术明确分离，这种架构中服务之间的通讯是和底层编程接口及通讯模型无关，仅是通过简单但是精确定义的接口来进行通讯的，因此以这种方式完成的集成设计，不但可以组合现有的服务，同时也可以灵活的开发和拓展新的业务来完善整个系统。另外，它也能够快速、便捷地满足不断变化的服务需求，具备高度的灵活性。

［1］张庆福，万麟瑞.基于SOA的异构数据集成软件架构研究［J］.计算机技术与发展，2011(5):17-21.

［2］马俊.基于SOA的异构系统集成研究［D］.西南大学，2010.

［3］Tom Bellwood.理解 UDDI［EB/OL］.2002-07-1［2007-06-19］.http://www-900.ibm.com/developerworks/cn/webservices/ws-featuddi/.

［4］Matthew Adams.ServiceDataObjects For JavaSpecification［EB/OL］.http://xml.coverpages.org/SDO-Java-Spec-v210.pdf.