本软件和文档必须服从和遵守东方易维规章协议许可,同时在使用和复制的时候，也必须遵守此许可。如未遵守此许可擅自复制软件，将与法律抵触。未经东方易维的书面许可，本文档不得以部分或全部地以影印、翻版、翻译、或转移到其它电子媒介或可读机器上的方式复制。

使用、复制、或者被政府泄密必须符合东方易维规章协议许可的限制集，并且在商用计算机软件版权法的 (c)(1)条款(FAR 52.227-19) ； 技术数据和计算机软件版权的(c)(1)(ii)条款 (DFARS 252.227-7013), 商用计算机软件许可的 (d)条款(NASA FAR 附录 16-52.227-86); 或者其它法律条文。

本文信息如有变动，恕不另行通知，文中信息并不表示东方易维有所承诺。本软件和文档只提供“事实”，不作任何形式的保证，包括：没有局限性、可销性、适合特殊用途。另外，对于软件或文字材料使用或者使用结果的正确，准确，可靠或其他，东方易维不作任何承担、保证、或者表示。

PDF格式的本文档在电子文档网站的产品文档主页上(或在文档光盘上)。你可以通过Adobe Acrobat Reader打开这些文档并用出版格式打印整个文档(或者一部分)。要得到这些PDF格式的文档，只要打开文档主页，只要选择你所需要的文档，点击“下载”即可。

Adobe Acrobat Reader在Adobe的站点上可以找到：http://www.adobe.com。

您对文档的反馈对我们非常重要。如果您有什么问题和意见可以通过公司网站http://www.oe-way.com.cn上提供的联系方式或就以下任何方式联系我们。那些负责建立和更新文档的专业人员会直接检查您的意见。

随着计算机与网络技术的不断发展，以及近几年信息化系统建设的不断发展，很多的单位（行政事业单位以及企业）都拥有了不止一套的系统。与此同时，业务规则的不断变化，使得越来越多的单位在信息化建设的过程中，不得不加强自己业务的灵活性，同时简化其基础架构，以更好的满足其业务目标。

随着单位系统建设的越来越多 ，各个系统间数据、业务规则、业务流程的整合成为了最终用户非常关心的问题。如何能够通过整合已有系统，使各个系统的综合数据能够成为决策者的决策依据；如何通过系统整合，建设更加完整的、合理的业务流程；如何能够通过系统整合降低工作人员的工作量，提高工作效率，以达到降低成本以及提高工作效率的目的。

正式因为存在以上种种的需求，人们开始希望能有一种比较好的解决方案，以从业务和架构上满足需求。

ESB的出现令人为之一亮，其为解决以上种种问题，提供了一种完整的设计与实施规范。其以总线为基础，定义了各种功能组件以及一系列的技术规范，从业务角度和系统架构的角度上满足了大多数的需求。

ESB是一种在松散耦合的服务和应用之间进行集成的标准方式，是在SOA架构中实现服务间智能化集成与管理的中介（本文不准备在SOA上着墨过多，虽然这是当前很火的一个名词）。ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。同时，其也提供了服务的监控、统计、服务的发现等功能。

ESB系统中将集成的对象统一到服务，消息在应用服务之间传递时格式是标准的，这使得直接面向消息的处理方式成为可能。ESB能够在底层支持现有的各种通信协议，这样使得开发人员对消息的处理就可以完全不必考虑底层的传输协议，可以将所有的注意力都集中到消息内容的处理上来。使得在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。

其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。

事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)，即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件，发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。

除了上面一段中讲到的，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。

可以这样说，ESB是特定环境下（SOA架构中）实现EAI的首选方法。首先，在ESB架构中，被集成的系统被明确的定义为服务，并且这些服务都是符合一定标准的，而不是EAI系统中所集成的各种各样的组件。这就极大的简化了在集成异构系统上的可操作性。因为不管是怎样的异构实现，只要其是SOA中的服务即可以，因为SOA中的服务都是遵循一定标准的。

其次ESB强调消息处理在应用系统集成中的作用。这里的消息是指不同应用系统中，对象与对象之间的沟通。而以往传统的EAI系统，在实施的过程中，最大的问题就是各个不同的系统都有自己的消息格式（方言）。而使用ESB，可以使用一种标准的方式对系统内的所有消息进行转换。

经过几年的发展，ESB以及SOA领域出现了很多的技术规范，这些技术规范的出现以及在实际中的应用，也大大促进了ESB技术的发展，其也变的越来越成熟。

任何一种技术架构，都有其基本的功能模型，都应该详细的描述出使用该技术架构，可以完成哪些功能，会给我的产品带来哪些架构上的调整，会给我的业务带来什么样的敏捷性。关于ESB的讨论，在各大社区都讨论的很热烈，本部分将总结给出ESB功能模型。

上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。

基于以上原因，加上正在制订和已经制定的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将在接下来的章节张，集中讨论一个ESB应该满足的最低功能需求，即将讨论的这些功能，也是实施国内EAI项目所必须的功能。

和许多技术架构一样，讨论ESB也需要从系统级的角度来考虑。结合东方易维在EAI项目中的实施经验，以及一些技术规范，可以将ESB的最低功能需求描述为TRANS：其详细说明如下：

ü         Transforms 转换消息格式，针对已注册的服务提供者的需求将消息从一种格式转换到另一种格式。也就是说，服务提供着暴露给服务消费者的“接口“形式，以及服务提供者与服务消费者质监交互的数据格式，都会转换为一种标准的形式，服务消费者和服务提供者都只针对标准格式的消息进行处理即可。

ü         Routes 路由消息，将消息传输到已注册的服务，并保证传输的服务质量以及服务层的特性。不论是基于HTTP、HTTPS、SSL、TCP通信，以及与Java、C＃，C++、.NET等等系统通信，都应该能够准确无误的保证消息的路由。

ü         Augments扩展信息，在传输的内容中添加额外信息，比如关于消息请求者的元数据。在消息中添加新的通信协议内容以满足服务提供者的需求

ü         Notifies通知消息监听者的特定消息请求

ü         Secures 安全传输，对于传输的消息增加消息认证、授权、不可否认性、机密性，保证消息在传输过程中不被篡改等等。

其实讨论ESB的最低需求，项目实践是一部分，另外也可以从ESB的理角度进行分析。经过前面几节的讲解 ，相信您对ESB的基本原理应该有了大致的了解，如果您还没有了解，下面的总结或许可以帮助您：

ü         ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。

ü         SOA 原则需要使用与实现无关的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。

ü         ESB可以作为分布式的异构基础架构进行实现。

ü         ESB提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

基于这些原则，也可以将ESB的最低功能定义如下：

从上面可以看出，这些最低功能需求，并不需要特别的技术，或者可以称之为与技术无关的，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：

ü         URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。

ü         SOAP/HTTP 支持请求-响应（Request-Response）通信规范。

ü         HTTP 传输协议被广泛地使用。

ü         SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

当然，ESB的这些最低功能需求，只是完成了一些基本功能（听起来好像是真理），这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能，如： 用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。

虽然上面讲到的这中功能需求依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

ü         服务质量和服务级别功能。

ü         高级 SOA 概念，例如服务编排、目录、转换等等。

ü         按需操作环境需求，比如管理与自治功能以及基础架构智能功能。

ü         跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

ESB毕竟是一个系统级的架构，并不是短短几千字就能够可以描述的。本文仅仅用非常概括的语言，讲述了ESB产生的背景，特点、作用以及其基本的功能要求。如果想要开发ESB的产品，或者进行系统实施，这些内容肯定是不够的。如果您有什么技术或者项目实施中的问题，可以联系我们：

www.oe-way.com.cn

wxl@oe-way.com.cn

010-51292209-823

王鑫磊，现任北京东方易维软件有限公司ESB产品经理，主要研究方向为SOA相关的SCA、SDO、DAS、BPM、ESB、WS-*，曾主持开发过多个省（部）市委办局数据整合以及业务流程整合的项目。

email:wxl@oe-way.com