本文提出一种基于SOA的中间件解决方案，通过构建一个松散耦合的异构系统集成服务平台．实现集团型企业的多个异构业务系统的集成，同时继承企业已有的IT资产，并提供丰富的管理功能。
集成需求和方案
1、引言
企业信息化进程在我国已有相当的发展和成果，大量企业软件系统得到广泛应用.也随之产生新的问题：多个系统间采用非标准的形式紧密耦合，集成困难且阻碍未来发展更新;系统难以灵活应对业务变迁：管理功能限制在多个程序域内，难以实现宏观尺度的监测和调控：等等。集团型企业往往在不同地点的多个公司/分支部署有多种类型的业务系统.上述问题反映得尤为突出;而且由于网络环境等外部条件的限制，集团型企业的系统集成还面临着安全、效率、可扩展性等诸多方面的特殊挑战。
本文试图提出一种基于面向服务的体系结构(Service Oriented Architeeture，SOA)的中间件解决方案，通过构建一个松散耦合的异构系统集成服务平台.实现集团型企业的多个异构业务系统的集成，同时继承企业已有的IT资产，并提供丰富的管理功能和未来良好的发展空间。平台着重关注利用服务封装、编排和管理等关键技术实现集团型企业的数据的数据和业务集成。
2、集成需求和总体方案
对信息集成的需求集团型企业在管理上呈现出多层次和多体系结构的特征。通常各成员企业有各自的信息系统，其应用域在各自企业范围内且彼此可能是异构的。集团总部对下属企业的管控过程要求在这些独立系统之间进行信息交?互和功能协同，这就带来了异构系统的集成问题：这一问题常成为集团型企业推进其集成战略的瓶颈。
传统的中间件集成方案早期解决异构系统集成的途径是开发两两系统之间的点对点私有接口，这种结构复杂度高，在n个系统时最多需要n(n-1)个接口;也无法灵活地调整，一个系统发生变化，与该系统关联的所有接口都需要修改。为了提高集成的效率，诞生了企业应用集成(Enterprise Application Integration，EAI)技术。EAI的主要思想是建立一个统一的底层结构连通各个业务系统，作为一个集中式的信息交换中心，有效地减小接口开发的复杂程度。EAI可以看作是数据适配器、消息代理和其他类型的中间件的一组集合，可能涉及用户界面、数据、业务流程乃至函数，方法层面的集成任务。EAI对实现的技术不做限定，它与产品相关而非基于开放标准.仍有紧密耦合、开发成本高昂等问题。EAI较适用于单个企业(单应用域)内应用集成的场合，以及实时系统等对性能要求苛刻的场合。
基于SOA的中间件集成方案在Internet环境中多应用域集成的场合，基于SOA软件架构，通过构建、操作管理标准的Web服务(Web Services)来实现异构系统的集成，有望成为集团型企业异构系统集成的理想方案。与旧有集成方案相比.本方案采用平台无关的接口标准和文档格式，保证异构系统之间的互操作性;采用松散耦合的架构.支持服务的动态绑定和针对流程的服务编排，极大地提高集成系统的敏捷性和可扩展性。
SOA在单个企业中的应用已发展得较为成熟.涌现出了一系列国际标准和商用解决方案。但在跨多个应用域的场合。仍有不少尚须解决的特殊问题，这些问题随着应用域之间的关系不同(如对等的伙伴关系、流程上的先后依赖关系、总部与企业的上下级关系等)而有不同的需求和表现。在集团型企业的应用场合，异构遗留系统(Legacv Systems)的封装，从属于多个域的服务的统一注册与管理，跨域的服务编排，以及私有系统中跨域访问的安全和授权问题.是本文主要讨论的话题。
3、基于SOA的异构系统集成服务平台
3.1平台总体结构
该平台由如下几个功能模块构成：
企业服务总线(Enterprise Service Bus, ESB)为平台上的各种Web服务提供统一的运行时((Runtime)环境。
服务封装利用组件技术将企业已有的业务系统封装成为数据服务或业务服务。
服务编排使用一个模型驱动的可视化服务编排引擎，将平台上已有的细粒度的服务组合成为粗粒度的业务服务((Business Services)。
服务管理对平台上的服务进行管理，包括服务的注册和匹配，安全和身份验证机制，事务支持和管理等。
3.2 数据集成
系统集成的初始层次是不同域间数据的集成，需要在各域的异构业务系统中创建一系列数据适配服务，相当于在已有的异构系统之上增加一个统一的、符合标准的抽象层。
以一个典型的应用场景为例:总部需要各下属企业的销售数据。一个总部的合成服务(composite service)被手工或定时启动，将输人的筛选条件分解为适合各企业数据服务的请求并调用之;数据服务从业务系统中提取相应的数据，转换成总部的数据格式，作为服务的响应;总部将传回的数据收集在缓冲区，待各服务请求都传回数据后进行最后的数据合成和适配，装人总部的业务系统，完成该次服务调用。在这样的业务模式中，有若干问题值得考虑:
企业的原子服务(atomic services)企业提供的数据服务不可再分解，可看作企业级遗留系统的封装器。这些服务接收SOAP请求，转换为遗留系统能够处理的形式，如调用正确的EJB或者将请求加人遗留系统的消息队列等。集成服务平台的服务生成器根据典型的应用场合，提供自动化地创建和部署原子服务的模板和工具。
服务的合成数据服务合成的结果实现跨域的数据集成，合成的服务仍是较细粒度的，可用于更复杂业务流程的编排。
服务层数据模型服务层的数据模型独立于企业业务系统的数据类型细节，原子服务的输出是根据总部业务领域的模式定义的。
事务处理服务通常是无状态的，但大部分应用场景中合成服务都应看作事务，需要在分布式环境下保证事务特性。这在需要分布式写的场合(例如总部向各企业分解下达预算)尤其重要。相关的原子服务应支持事务处理特性，以便将事务协调交由平台上层处理。
SOA的异构集成服务
3.3业务集成和服务编排
为了实现跨应用域的业务过程的集成，需要将业务流程逻辑从程序逻辑中显式地分离出来.利用针对业务过程的模型和工具进行管理，使平台支持的业务系统对流程变迁有最大的灵活性。主要通过以下四部分实现:
业务建模建模是对实际业务流程的抽象，业务领域专家可选用适当的流程建模工具对跨域业务流程建模，业务流程模型将作为集成平台服务编排模块的输入。
服务编排服务的编排是从流程模型到Web服务组合的映射，本平台利用BPEL(Rusiness Process Execution Ian}uage)作为编排语言，根据业务模型对已有的细粒度服务进行编排形成复杂的业务服务。平台对服务编排的支持包括服务注册库、交互式编排界面以及编排语言1编排引擎三部分:服务注册库支持Web服务发现。编排引擎通过调用平台的服务注册库获取组成业务过程的细粒度服务的相关信息，包括服务契约、访问规则和策略安全/权限属性等。交互式编排界面将BPEL中定义的任务和被调用服务表示为可视化的图形节点和连接，并定义节点间的时序、调用、分支选择等关系，业务领域专家或IT人员可以通过该界面将抽象业务模型映射到Web服务的调用关系，并将整个流程发布为复杂的业务服务。编排语言及编排引擎将来自交互界面的图元及其关系自动映射输出为BPEL文件;并生成合成服务的业务契约和访问策略。
发布和部署编排的结果是可执行的业务服务，和与之对应的流程控制脚本。将业务服务注册至平台的服务注册库，注册的信息包含服务的契约、访问策略及服务与流程控制脚本的关联。
流程的执行运行时引擎在流程服务执行期解析流程脚本，创建流程实例，根据控制流结构调用原子服务;同时在必要时调用错误处理或事务处理机制。
3.4集成平台的管理功能
集成服务平台的管理功能主要解决服务注册管理、安全/权限管理和事务处理问题。
服务注册管理服务注册和发现技术大体分为基于开放标准的(如UDDD和基于私有框架的两类。UDDI作为主要面向公共领域的服务发现规范，不甚适合本平台应用集成场合的需求，因此集成服务平台将采用一个私有注册库，通过层次模型为服务的调用者提供静态的精确服务匹配。对服务注册信息的存储既包括UDDI标准提供的业务实体、服务描述、绑定信息、调用规范，也包括UDDI难以提供的WSDL契约文件、安全角色、事务支持等。
安全/权限管理以往的Web服务安全的讨论议题，大多集中在单个应用域内的安全机制和访问控制，对穿越多个防火墙边界的服务访问，基本上不采取集中式的解决方案。鉴于集团型企业的各应用域间具有明确的层次关系和跨域流程关联，在集成服务平台建立一个全局认证和授权中心GAAC(Global Authorization and Authentication Center)，提供统一的安全和权限管理，实现基于角色的授权机制，显式地将安全逻辑和业务逻辑分离。
基于角色的访问控制一般应用在单个应用域内，在跨域访问的场合该机制的应用受限，因为每个域都不持有其他域的最终用户(End User)身份及访问规则。本平台的解决方案是:对于跨域的服务调用，通过总部集中式地进行身份验证，授予服务调用者一个抽象代理用户身份，利用该抽象身份调用另一域内的服务。其好处主要有:①对于无需跨域的服务访问，各域仍可独立地实现基于最终用户的授权，无需持有其他域的最终用户身份;②总部可全局地管理全平台的服务授权;③保待了基子角色的安全机制灵活的管理和授权功能。
服务认证授权系统的结构如上图所示，由位于总部的GAAC和多个位于企业的企业授权验证中心EAAC(EnterpriseAuthorization a司Authentication Cenler)组成，EAAC是GAAC在企业域内的代理。权限可由服务提供者声明也可由总部全局地设定。
一次典型的跨域服务调用①服务调用方EAAC1将最终用户身份卿果需要的话)转换为一个代理用户，向GAAC发起调用请求;)GA.AC根据鉴权结果，向EAACI发布一个合法性令牌或拒绝访问消息(鉴权服务响应);③EAAC1持有该令牌向服务提供方EAAC2发起调用请求;④被调用服务传回业务数据响应。
事务处理如果一个业务服务需要平台提供事务支持，在服务设计期应引入平台提供的事务服务，且组成该业务服务的子服务需满足一定的条件:提供支持回滚的方法;支持向事务服务主动报告状态;支持事务服务对其查询状态。业务服务被调用时，先向平台的服务协调器(Coordinator)注册一个事务实例，其他参与的子服务依次加人这个事务实例;每个子服务完成操作后向协调器报告状态，协调器根据全部子服务的报告确定事务执行的策略。
对于协调器而言，参与者有两种操作类型(读和写)，以及三种结果状态:准备好(prepared)，表明执行成功;失败(failed),需要回滚或补偿;未决(indoubt)，协调器失去与参与者的联系，参与者的执行结果未知。而参与者的执行结果仪有准备好和失败两种类型，而由底层业务系统保证其域内的事务支持特性。全部的参与者状态报告均为prepared时事务执行成功;如果存在其他状态，协调器采取采取以下策略:
4、总结
本文提出一种基于SOA架构实现集团型企业的多个私有应用域跨Internet集成的中间件平台。该平台提供工具对遗留系统进行服务封装;提供基于BPEL的服务编排引擎实现模型驱动、面向流程的服务编排;提供私有的层次模型用于平台服务的统一注册和发现，并着重解决分布异构环境下服务集成的授权和访问控制，事务支持等特殊问题。该平台推进了多个程序域间的深度集成和总部对业务的全局管理，具有良好的应用前景。本文作者创新点:将Web服务技术运用于集团型企业异构系统的信息集成，提出了实现数据和应用集成的一种解决方案。
网友评论