集团型企业异构系统的中间件集成方案

互联网 | 编辑: 何毅 2011-04-03 00:00:00转载 一键看全文

本文提出一种基于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或者将请求加人遗留系统的消息队列等。集成服务平台的服务生成器根据典型的应用场合,提供自动化地创建和部署原子服务的模板和工具。

服务的合成数据服务合成的结果实现跨域的数据集成,合成的服务仍是较细粒度的,可用于更复杂业务流程的编排。

服务层数据模型服务层的数据模型独立于企业业务系统的数据类型细节,原子服务的输出是根据总部业务领域的模式定义的。

事务处理服务通常是无状态的,但大部分应用场景中合成服务都应看作事务,需要在分布式环境下保证事务特性。这在需要分布式写的场合(例如总部向各企业分解下达预算)尤其重要。相关的原子服务应支持事务处理特性,以便将事务协调交由平台上层处理。

提示:试试键盘 “← →” 可以实现快速翻页 

总共 2 页12
一键看全文

本文导航

相关阅读

每日精选

点击查看更多

首页 手机 数码相机 笔记本 游戏 DIY硬件 硬件外设 办公中心 数字家电 平板电脑