基于ESB的应用系统集成方法初探

蔡芳

摘要：随着企业信息化建设的不断发展，满足各类业务需求的应用系统也逐渐增加。为了消除信息孤岛、解决各应用系统之间的信息共享、流程驱动等问题，本文作者研究了基于ESB的应用系统集成方法，通过基于服务总线的SOA框架，解决单位内部的多个应用系统的集成问题，实现多系统之间的跨平台、跨技术的集成标准化，为后续的业务系统集成提供通用基础平台。

关键词：ESB；系统集成；SOA

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2018）19-0232-02

Abstract： With the continuous development of enterprise information construction，various business systems increase. In order to eliminate information islands， solve the problem of information sharing and process-driven between application systems， the author of this paper studied the application system integration method based on ESB， through the service-oriented SOA framework， solve multiple system integration problem， implement standardized integration， to provide a common platform for future business system integration.

Key words： ESB； System Integration； SOA

1 引言

企業在信息化建设进程当中，越来越多的业务系统投入使用，例如OA系统、人力资源系统、财务管理系统、项目管理系统、档案管理系统、PDM系统等。因为管理责任主体不同，这些系统初期都以各自独立的模式自主运行。随着企业对内部管理数据的唯一性、准确性要求，以及对不同业务系统之间据交互的要求，不同业务系统之间的集成问题随之出现。因不同业务系统采用的技术路线、实现的业务功能、执行开发工作的厂商都不同，实现系统之间的无缝集成即成为一个技术难题。

面向服务的软件架构SOA（Service-Oriented Architecture）是一种解决异构应用系统之间松耦合集成的框架，通过WebService分布式计算服务模式，实现不同应用系统之间的远程调用，这种服务具有平台无关性、普遍性、易于使用等优点，可以沟通不同平台、编程语言和组件模型中的不同类型系统，方便地实现异构系统之间的集成。

基于WebService的系统集成，早期实现了点到点的集成，即单个系统对单个系统的集成。这种集成缺乏伸缩性、扩展性、可重用性。因为系统的集成逻辑都直接通过编码写进应用系统中，每一个系统对应不同的需要集成的系统需要编写多个接口服务程序，这个程序混乱难于管理，如图1所示。应该说，点到点的WebService集成不是真正意义上的SOA。

基于企业服务总线ESB（Enterprise Service Bus）的SOA集成框架，是一种端到端的服务集成框架，如图2所示。这种框架通过ESB中间件作为服务管理基础，将各异构应用系统的通用服务插入到ESB总线上，支持服务的即插即用。它以标准为基础，以消息流转为沟通方式，实现跨平台、跨技术的多个应用系统和服务间的信息沟通和数据共享。

2 相关技术及产品比较

目前流行的ESB产品包括商业ESB产品和开源的ESB产品。每个ESB产品的基本特征至少应包括：

（1） 连接性：提供支持多种协议、多种服务的连接属性。

（2） 交互性：提供支持不同服务之间的交互属性。

（3） 集成性：提供对于异构系统之间的集成属性。

（4） 消息处理机制：提供统一的消息描述格式、多种通讯方式实现对异构系统的消息处理。

（5） 管理机制：提供对服务的运行、交换、资源、安全以及接入等的管理、监控功能。

（6） 安全性：提供保障服务安全的完整性校验、消息审计、服务安全（认证授权、传输加密、消息加密等）的安全机制，确保服务访问过程的安全性、可靠性、一致性。

（7） 服务质量：提供消息成功率/失败率、流量控制、故障次数、响应时间等服务质量参数，提高服务质量QoS。

目前市场上的ESB总线产品很多，作者在研究对比了相关产品资料后，在总线产品的性能及扩展性等方面总结出以下几个产品的特点。

2.1 ServiceMix

ServiceMix是Apache的ESB总线框架，具有独立的JBI（Java Business Integration）容器，完全支持JBI规范。它有独立的运行环境，以应用服务器一样的模式启动，并支持动态热部署。ServiceMix的容器运行环境采用内核架构，性能较为突出。通信方面整合了ActiveMQ，也支持多种通信协议，例如HTTP和JMS。在管理组件上采用了JMX（Java Management Extensions），能够对部署在总线上的各种组件进行动态配置和管理，通过Web方式或JMX远程均可访问。ServiceMix内核能够整合到操作系统中，因此可以作为操作系统对外提供的服务。ServiceMix还提供了独立的脚本命令控制台，通过简单命令管理应用组件以及ServiceMix内核实例。

2.2 Open ESB

OpenESB是Sun公司的开源ESB，对JBI支持程度极高。而GlassFish ESB是将OpenESB的核心运行环境与GlassFish应用服务器以及NetBean的集成开发环境整合在一起的一个ESB框架，其中包含部分OpenESB组件。OpenESB提供了支持WS-BPEL2.0（Web Service Business Process Excution Language）的引擎，该引擎要依托NetBean集成开发平台，可以使用NetBean的开发包和组件包，支持端点状态的监控、支持多线程执行、业务流程的调试、系统错误的可靠性恢复中各个业务流程实例的数据库持久化以及负载均衡等。

2.3 JBoss ESB

JBoss ESB是面向SOA的一个EAI（Enterprise Application Integration）平台。它提供了很多EAI基础功能，例如业务流程监控、集成开发环境、工作流用户接口、业务流程管理、分布式计算架构以及应用容器功能等。相对于其他ESB，它的技术架构非常最独立，仅支持J2EE标准，不支持JBI规范。JBossESB支持 Web Service、多种远程调用协议（例如：JMS），在扩展性方面功能较弱。

2.4 MuleESB

Mule是目前使用者最多的开源集成平台，是基于Java的轻量级企业服务总线和集成平台，具有基于模式的配置以及热部署的突出特点。它支持20多种传输协议（例如：file，FTP，UDP，SMTP，POP，HTTP，SOAP，JMS等），并整合了许多流行的开源项目，比如Spring，ActiveMQ，CXF， Axis，Drools等。MuleESB不是基于JBI构建的平台，但为JBI容器提供了适配器，可以与JBI容器整合在一起。 MuleESB在灵活性，高效性以及易开发性方面优势明显。MuleESB可以独立运行，也可以部署在通用的应用服务器上，通过Transports/Connectors与外部异构系统连接，提供Routing（路由）、Transaction Management（事务管理）、Transformation（转换）、Message Broker（消息代理）、Transportation Management（传输管理）、Security（安全）等核心模块。集群能力较弱是MuleESB的较突出的弱点，因为它只能配置一个主实例和一个从实例。

2.5 Oracle OSB

Oracle Service Bus 是Oracle公司的 ESB商业产品，完全基于J2EE技术、并具有内置的J2EE容器，可充分兼容开放技术标准；支持Web Service等异构技术，支持WS-RM、WS-Policy、WS-Security等相关标准。OSB提供符合J2EE JCA（JAVA Connector Architecture）规范的标准Adapter，用于连接各业务系统；提供可扩展的Transport框架，支持定制化开发扩展连接方式；提供Eclipse的IDE开发环境和基于Web浏览器控制台的消息流编排。OSB中嵌入了Oracle Coherence（企业级的内存数据网格）产品，在特定场景下为服务调用提供缓存，使总线的性能提升了80%。OSB的局限性是完全依赖于BEA Weblogic（现在是Oracle Weblogic Server）运行，对用户的运行环境要求较高。

3 集成方法规划设计

实施ESB项目是一个复杂的过程，既包括对现有业务系统的服务功能改造，又包括对后续业务系统的不断接入，实现端到端的应用集成，还包括对未来跨系统之间的流程驱动的实现规划设计。因此需要制定详细的项目实施计划，合理制定阶段目标，确保项目实施成功。图3是ESB總线集成项目的功能示意图。

为实现以上ESB集成功能，需要按照SOA的架构设计方法对服务业务需求进行设计。服务业务需求包括功能性需求、非功能性需求以及服务实施需求。其中功能性需求是要对包含的所有服务进行定义，定义出服务接口、服务实现、服务契约等完整的一个服务标准定义模式，最终形成一套整体服务架构框架图。非功能性需求即是对集成服务的可用性、扩展性、安全性、管理性以及性能等进行定义。实施需求设计包括对服务实现、服务测试以及服务部署等需求的设计。图4是 服务从定义阶段到运行阶段的开发流程示意图。

4 结束语

在单位内部实施ESB项目，实现业务系统的集成与流程驱动，首先需要选择先进成熟的ESB产品，在此基础上充分了解业务需求，描述清楚与业务系统关联的服务的要素，建立服务建设规范以及服务定义标准，由专业的ESB、SOA技术人员来完成ESB项目的技术实现，最终留下完整的开发过程文档供后续项目参考。作者所在单位尚未开展ESB的全过程开发工作，本文仅作为前期的探索研究理论支持。

参考文献：

[1] 赵海蛟，潘善亮.基于Mule ESB的电子监察系统的设计与实现[J].数据通信，2016（1）：7-10.

[2] 党怀义.基于SOA的飞行试验数据管理系统研究[J].计算机测量与控制，2014，22（7）：2135-2137.

[3] 林泳琴，黄晨晖.面向企业应用集成的ESB框架的研究[J].计算机应用，2010，30（6）：1658-1660.

[4] 汤雷，张勇，徐宇婷.基于服务总线（ESB）的应用集成（EAI）探索和研究[J].计算机技术与发展，2014.24.12：238-240.

[5] http：//www.baidu.com.