更新时间：2024-04-16 09:46
面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。
SOA把IT架构分为组件层、Web服务层、业务流程层等。组件层包括各种应用组件，它们通常是技术相关的具体实现，各种具体的分布式组件技术(CORBA、COM/DCOM、J2EE)都可以用于实现组件层的应用组件。通常复杂的IT环境中的组件层都同时使用了多种分布式组件技术，而不同实现技术之间的互联性障碍给应用集成带来了极大的困难，进而形成了一个个信息孤岛。SOA引入了Web服务层来解决此种情况下的应用集成问题。Web服务是独立于各种分布式组件技术的，它使用标准的基于XML的服务描述语言(Web Service Description Language，WSDL)来定义和封装离散的业务功能，各种支持Web服务的分布式组件技术能够将其上的业务组件发布成Web服务并产生相应的WSDL文档，并且只需要依据WSDL描述的信息就能够调用Web服务，即WSDL所描述的业务功能。Web服务在系统集成方面得到了广泛的应用。在SOA中，需要进入系统集成环节的业务组件都被映射为Web服务，形成了Web服务层。业务流程层则处于Web服务层之上，通过对Web服务的流程编排来实现商业流程。业务流程层通过Web服务层能够调用到基于各种分布式组件技术实现的业务组件，实现了复杂IT系统环境的应用集成。
在SOA的组件层、Web服务层、业务流程层三层模型中，组件层使用具体的分布式组件技术实现业务功能，Web服务层则为组件层提供了一种技术无关的通用访问方式，屏蔽组件层具体技术之间的差异，突出业务逻辑的封装性。组件层中的业务组件和Web服务层的Web服务构成了企业IT架构的主要可重用部件，它们应该保持相对的稳定，业务流程层则通过对服务进行编排，来适应业务需求的变化。将组件层的业务组件映射为Web服务层的服务是成功实现SOA的关键步骤，目前对于特定的业务组件，业界广泛使用具体于分布式组件技术内建的支持Web服务的功能来实现组件与服务的映射。这种映射方法高度依赖于具体分布式组件技术本身，并且在使用和定制的过程中缺乏灵活性，当某个Web服务的实现需要多个分布式组件技术中的业务组件实现时，这种映射方法就会无法支持。
企业服务总线(EnterpriseServiceBus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。
作为SOA基础架构的关键部分，ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控等方面。在通信方面，ESB能够支持消息路由/寻址，支持多种通信技术、通信协议(如JMS、HTTP)，支持发布/订阅的通信模式，能够处理请求/响应、同步以及异步的消息传递方式，并且要求以可靠的方式传递消息。服务交互方面，ESB上所发布的服务是以当前标准的Web服务描述语言(WebServicesDescriptionLanguage)来定义Web服务的，并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统，必须能够支持多种接入ESB的方式(例如将ESB、WebService、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统)，将接入的系统映射成Web服务。在集成不同系统的同时，必须考虑服务质量方面的问题，如事务性和消息传递的可靠性。对于关键的Web服务，ESB需要以加密的方式进行消息传递，并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统，还必须配有相应的管理和监控功能，用于ESB软件自身的系统管理、日志记录、测量和监控等。目前国内外对企业服务总线的研究都比较积极，IBM的ISV、BEA的AquaLogicServiceBus、开源的Mule、Sun领导的JBI规范草案等，都是企业服务总线的具体实现。但是这些公司的ESB实现都更关注于对自有品牌产品的支持，对如何集成更多分布式组件技术考虑得不够。
企业连接框架是企业服务总线的一种具体实现。该框架的首要目标是使用标准的开放的协议以及经过验证的企业应用集成模式，将不同的应用程序系统集成起来。ESB连接框架定义了一系列构建，用于处理在集成不同系统时所涉及的通信、路由、服务交互等方面的任务。企业连接框架体系展示了使用该框架集成2个端对端的应用程序的连接方式。企业连接框架包含以下几个部分：适配器，前置路由器，后置路由器，应用组件等。
适配器等价于EIP中的ChannelAdapter(通道衔接器)，用于连接应用组建与外部应用程序。适配器包括连接器、消息接收器/消息发送器、消息转换器3个部分。消息接收器/消息发送器用于接收和发送消息，消息转换器用于消息与组件所识别数据类型之间的数据转换，连接器则用于维护外部应用程序与应用组件之间通信的会话。连接器是适配器的核心，用于管理消息接收器/消息发送器以及消息转换器。对于消息接收器和消息发送器，连接器可以在其上定义接收端点和发送端点，用于指定该消息从哪儿接收或者发送到何处，如JMS的队列名称、HTTP的URL地址、pop3/smtp协议的邮件地址。同时，连接器使用消息转换器将接收来的消息或者即将发送的数据进行转换。企业连接框架对不同的通信协议提供相应的适配器，如HTTP适配器、JMS适配器、邮件服务适配器、TCP/IPsocket适配器，CORBA适配器、EJB适配器、COM/DCOM适配器、HTTP/SOAP(Web服务)适配器等。种类丰富的适配器确保企业连接框架能够集成基于不同分布式组件技术的业务组件。
路由器分为前置路由器以及后置路由器2种，分别用于应用组件处理消息前的接收路由和应用组件处理消息后的发送路由。通过前置路由器，应用组件可以接收来自不同适配器或者同一适配器不同接收端点的消息；通过后置路由器，应用组件可以将其处理结果发送到不同适配器或者同一适配器的不同端点上。路由器可以实现动态的、声明性的、基于内容的以及基于规则的消息路由。通过消息路由，可以顺序、选择或者串联地调用应用组件，实现EnterpriseIntegrationPattern中的消息路由模式。
应用组件是基于某种具体分布式技术实现的业务逻辑模块。通过路由器和适配器的连接，应用组件可以与其它应用组件或者外部应用程序交互。
外部应用程序可以是任何类型的应用程序，如Web应用程序、办公自动化系统、应用程序服务器、业务流程执行引擎等。
使用企业连接框架能够轻易地实现应用系统的集成，并可以将已有应用系统的功能作为应用组件，通过消息适配器和消息路由将应用组件自由组合形成Web服务，从而实现组件与Web服务的映射。使用企业连接框架进行组件与服务的映射可以加快开发速度，更好地重用已有系统的功能，同时能够获得更好的灵活性，降低系统维护的复杂度。根据业务需要，应用组件可以通过如下方式映射成Web服务：简单映射，路由映射，复杂映射和镜像映射等。
将一个组件映射成对应的Web服务：这是实现组件与Web服务之间映射的最简单的一种方式。业务组件的接口正好与Web服务的接口相一致，直接为此组件配置HTTP/SOAP(Web服务)适配器，将其映射为Web服务(如图1所示)。
通过路由机制，将多个组件通过路由组合成一个Web服务。对于某些Web服务，其业务功能的实现可能需要多个应用组件协作完成，如图2所示。适配器使服务总线具备连接不同技术标准组件的能力，路由器则增强了这种连接的灵活性。通过路由器，各种应用组件可以灵活地组合起来，协同完成某项业务功能。路由器有前置路由器及后置路由器2类。前置路由器有：
后置路由器有：
1、总线基础服务框架：提供系统一致性、安全性、可靠性，以及性能和扩展能力保障的基础技术手段。
2、集成服务：提供基础的集成服务与用户定制的应用服务；支持多种集成服务模式；支持服务的封装、重用、服务组合、服务调度。
3、公用服务：提供内置的各种公用服务。例如，渠道认证服务，日志服务等公用服务。
4、服务管理和服务标准：提供服务配置管理的前台工具集合，并提供行业的服务规约标准。
5、系统监控：提供多角度的系统实时监控与交易报表，提供用户定制的告警。
6、安全体系：提供多种安全机制并支持和第三方安全系统的有效集成，提供有效的安全监控机制。
1、可用性和可靠性
支持群集物理部署来保证系统的高可用性，支持系统的长期稳定运行。
2、性能和可伸缩性
支持在达到系统性能指标峰值要求的同时，系统处理能力还能够留有足够的余量。
3、扩展性和灵活性
支持系统扩展部署和多个逻辑单元的分离部署。提供对系统的维护与参数配置的管理功能。
4、安全性
提供安全认证和授权机制，提供不可否认和机密性，支持安全标准。
从理论上讲，集中式 ESB 有可能标准化和大幅简化整个企业中服务的通信及集成。 硬件和软件成本可以共享，只需供应服务器一次，还可以指派单支专家团队（必要时进行培训）来开发和维护集成。
开发人员可使用单个协议与 ESB“对话”，并发出命令来指导服务间的交互，然后交给 ESB 转换这些命令、路由消息并根据需要变换数据以便顺利执行这些命令。 这样，开发人员就不需要将大量时间用于集成，而是将更多的时间用于配置和改进应用程序。 由于能够在不同项目之间复用这些集成，因此可以提高生产力并节省下游成本。
虽然有不少组织成功部署了 ESB，但在许多其他组织中，ESB 被视为 SOA 部署的瓶颈。 更改或增强某个集成通常会干扰到其他集成。 ESB 中间件更新通常会影响现有集成。 由于 ESB 是集中管理的，因此应用程序团队很快就发现需要排队等待集成。 随着集成量的增长，ESB 服务器实现高可用性和灾难恢复的成本变得更高。 作为跨企业项目，ESB 筹集资金较为困难，因而加大了相关技术难题的解决难度。
最终，维护、更新和扩展集中式 ESB 变得十分复杂且代价昂贵，以至于 ESB 经常会造成自身和 SOA 预期可得到的生产力效益迟迟无法实现，从而使期待锐意创新的业务团队感到挫败。