ESB讲座资料1

1、ESB学习笔记 2009-08-11 adventurer 来源：adventurer的blog 开始入冬时知识储藏啦。前几年听一位高人讲过ESB这个概念，但一直没有时间去仔细了解。而近段时间。找了一本ESB in Action学习.准备好好学习ESB啦，以下主要是该书抽取内容。 · 什么是ESB？ ESB，消息服务总线，它是一个较新但又较难理解的技术。 ESB从集成供应商角度来看，它是一个产品，这个产品提供一体化的功能，开发工具，和管理环境。 另一个角度看，ESB是作为服务为导向架构（ SOA ）重要组成部分。从SOA的角度看，一个ESB可以作为一体化平台，使现

2、有的IT资产和应用暴露成为服务。 在这里，我们将关注开源的ESB的产品，目前可用的产品有：Mule和Apache ServiceMix 。 如果你问架构师，当今市场那个时髦词最热，企业服务总线（ ESB ）将是最多的答案。同时，像面向服务的架构（ SOA ）和商业流程管理（ BPM ）也将提到。这些流行语声音非常 有趣的，但那个才是最有商业价值呢？ 现在ESB产品有很多，特别是企业应用上，我们来看一下有哪些，IBM ，TIBCO ，微软和甲骨文。这些好像都是大牌，但所有ESB都有相同的特点。而这里我们只提供两个开源产品（Mule 和 ServiceMix） · ESB特点但用于区分相

3、关EAI和ESB产品，一个是星形结构的，而另一个是总线结构的ESB产品。星型结构模型是一种集中式的架构，所有的数据交流都由中心点来处理。该星型结构模型可以被看作 继承的点对点模式 。而总线模型，采用分布式体系结构，其中的ESB 功能，可以由几个其他物理产品来实现其功能。 第二个用于区别的EAI和ESB产品是使用开放标准是什么。EAI的产品，如WebSphere的消息代理，TIBCO的BusinessWorks ，和Sonic XQ使用一个专利技术来实现信息功能及传送逻辑。而ESB产品是基于开放标准，如Java消息服务（ JMS的） ， XML和J2EE连接器架构（ JCA的） ，和Web服务标

4、准。 · ESB 优点 ESB主要是解决"整合"问题。例如下图是较早系统架构。 ESB处理后 · 何时要考虑ESB：理由：Necessity to integrate applications 描述：There must be a clear business need to integrate applications. Time-to-market and real-time reports are examples of business drivers. 理由：Heterogonous environment 描述：When you have t

5、o deal with lots of different technologies and protocols, there is a clear need for a central solution that's made to deal with these challenges. 理由：Reduction of total cost of ownership 描述：IT departments are forced to cut maintenance costs to be able to satisfy demands for new products by the bu

6、siness departments. A central integration solution can help decrease the management and maintenance costs of the full application landscape. · 架构设计ESB帮助 J2EE体系 这里需要增加一个呼叫中心会如何办？我看到很多系统会这样处理。好像还取名叫嵌入式系统。 在一个多系统服务公司。系统一开始可能是这样来架构的。 ESB总线在中间加了这一层后，对异构系统的增加，提供很大的支撑。 说了这多ESB如此好。那到底ESB有那些功能呢？ESB有七大功能

7、。 · Location transparency · Transport protocol conversion · Message transformation · Message routing · Message enhancement · Security · Monitoring and management · 相关开源ESB产品有如下这些 1. Mule :   :/ mulesource 并没有完全按JBI规范产品。 2. APACHE SERVICEMIXurl :/serv

8、 /url JSR 208IBMBEA投了弃权，故他们产品也没按JBI规范 3. OPEN ESB s:/open- JBI implementation provided by  Open ESB Sun that provides great tool support with NetBeans 4. APACHE SYNAPSE url ://synapse /url 5. JBOSS ESB :/labs.jboss /jbossesb/ The JBoss implementation of an ESB base

9、d on JBoss JBoss ESB messaging 6. SPRING INTEGRATION :/ /  Spring Integration spring-integration An integration framework that is provided by the well-known Spring Framework 7. Apache Tuscany :// Implementation of the (SCA) specification 8. ChainBuilder ESB

10、:/ A JBI-based ESB that focuses on providing graphical tools to ease the development effort 9. FUSE ESB url :/open.iona /products/ fuse-esb/url IONA's open source ESB offering based on Apache ServiceMix 10. OpenAdapter s:/ / EAI-based platform that provides a number of adaptors to

11、 implement integration solutions 11. PEtALS :// Another JBI-based ESB, hosted by OW2 (formerly ObjectWeb) 12. WSO2 ESB :/wso2 /products/esb/ WSO2's open source ESB offering based on Apache Synapse 推荐书籍： <<Enterprise Integration Patterns>> <<ESB in Action>

12、> <<Enterprise Service Bus>> ESB项目需求分析和方案设计浅谈 投稿 打印 MSN推荐 博客引用   大 | 中 | 小2010-1-6导读：本文我们将针对ESB项目的设计和实施过程中各个阶段要完成的主要工作内容和一些最佳实践跟大家作一些讨论，进而希望大家在企业ESB项目实施过程中借鉴科学的方法论的指导来保证其成功。关键词：ESB ESB方案设计 ESB组件模型  正在加载数据. 如同其它IT项目一样，企业服务总线类项目的实施也要经历需求分析、方案设计、编码和测试、上线部署等阶段。下面我们将针对E

13、SB项目的设计和实施过程中各个阶段要完成的主要工作内容和一些最佳实践跟大家作一些讨论，进而希望大家在企业ESB项目实施过程中借鉴科学的方法论的指导来保证其成功。    TT SOA编辑推荐：企业服务总线ESB（更新版）ESB的需求分析需求分析阶段是梳理项目中相关功能需求和非功能需求的重要步骤，它是整个项目成败的关键。在这个阶段我们将从企业业务需求出发，梳理端到端的跨系统业务流程；基于业务流程，依据科学的方法论进行服务鉴别；由服务列表出发，梳理服务的消费和提供关系；然后根据SOA的最佳实践，定义服务的接口，包括服务的Schema描述，字段的类型，编码的规则；依据服务

14、的消费提供关系，梳理ESB中的服务映射和转换规则和策略。概括而言，我们需要从功能性和非功能性两个方面来进行ESB的需求分析。针对ESB的功能性需求，我们要侧重了解以下方面的问题：1. 梳理出要被集成的系统的名称，个数。2. 针对每个系统而言，要了解：该系统的对外接口是向外调用，被别人调用，还是二者都有； 接口的实时性要求，是实时的还是批量的，还是二者皆有？ 接口的调用方式，是同步的还是异步的，还是二者皆有？ 应用系统所运行的操作系统平台。 应用系统本身的编程语言？C/C+, Java. 这些系统现有接口的情况，是否已经可以提供对外接口，接口的方式是什么，包括接口的通讯协议是什么， /MQ/So

15、cket/ 其它？接口的数据格式是什么，XML/ 自定义格式 / 其他行业标准格式？接口的编程语言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口开发时有什么要求或限制条件？ 这些应用后台数据库的情况，数据库能否直接访问？ 每个应用跟其他应用交换数据时，源数据格式和目的数据格式，比如从文本格式转换为 XML 格式？ 交易特征：哪些处理要采用两阶段提交；是否需要多个消息组成一个交易；是否要保证消息之间的处理顺序； 适配器的情况：对于一些特殊系统，是否已经具备现成的适配器；适配器是单向的还是双向的； 消息通信的模式：是Send and Forget、Request/Reply还是Pu

16、b/Sub? 针对ESB的非功能性需求，我们要确认：1. ESB平台的扩展性和高可用性需求，包括HA和集群等；2. ESB平台的性能需求，主要包括系统间数据交换的频率，要交换的数据的大小 ( 消息大小将直接对效率造成影响 )；峰值时候对ESB数据吞吐量、响应时间的要求等；3. 哪些交易要保证数据传输的高可靠性；4. ESB平台的可管理性需求，如服务的生命周期管理，ESB 平台的维护和管理；如果企业已经设立了SOA管控方面的规范，那么要遵从规范的制约，比如要考虑是否有规定的命名规则，企业是否有企业级的数据规范和底层通讯协议的规范等；5. 安全性方面的要求：是否采用SSL传输加密，是否对消息进行加

17、密/解密处理等；6. 错误处理和日志以及平台本身的运行监控等方面的要求等。ESB的方案设计方案设计的主要内容包括：ESB涉及IT应用环境分析，定义ESB与相关应用的接口模式； ESB架构概要设计，并定义架构原则； ESB相关产品选择，包括与外围系统的适配器选择和ESB产品选择； ESB组件模型设计，分解ESB的相关模块，满足SOA的分离关注点等架构原则； ESB运作模型设计，满足平台的非功能性需求； ESB平台的服务流设计，涉及路由、转换和映射等； ESB的同步、异步或者发布/订阅模式设计； ESB平台的接入渠道和数据接口设计，包括XML/JMS、SOAP/ 、EDI/MQ 等； ESB相关的

18、适配器设计，包括技术适配器或者自开发的适配器； ESB平台的容错和重试机制设计，包括日志等的统一管理等；     图 1 是一个采用ESB整合的高层架构设计举例：图 1. ESB参考架构    如图 1 所示，ESB架构设计时主要要考虑通讯协议接入和转换、数据接入和转换、数据处理流程以及服务的注册和管理等方面的内容。其中通讯协议接入和转换是指对各种被集成的应用系统的通讯协议的支持和转换能力，例如 、JMS、Socket、FTP等；数据接入和转换是指对各种被集成的应用系统提供的数据格式的支持和转换能力，例如XML、SOAP、自定义格式以

19、及符合某些行业标准的专有格式（SWIFT、EDI、HL7 等）；数据处理流程是指路由、格式转换、数据库读写等对数据的各种处理；统一服务注册存储管理是指对服务的注册、发布、查询，以及对运营时服务的管控，并且提供服务运营状态的统计分析数据。ESB的组件模型图 2. ESB组件模型    图 2 给出了一个ESB组件模型的示例，其中包含的各主要组件及其功能如下：1. Message Broker Runtime组件提供消息路由、格式转换、消息日志等操作的运行时环境。该运行环境由IBM Message Broker提供；2. Messaging Broker Instan

20、ce组件是处理基于MQ消息业务请求的容器。它是作为一个Broker实例运行在Message Broker Runtime上的。该实例提供了MQ消息的业务请求处理器、服务日志、服务定位等功能的运行容器；3. Web Service Broker Instance组件是处理基于Web Service的业务请求的容器，它是作为一个Broker实例运行在Message Broker Runtime上的。该实例提供了Web Service的业务请求处理、服务日志、以及服务定位等功能。4. Event Broker Instance组件是平台内部处理Pub/Sub事件的容器。它是作为一个Broker实例运

21、行在Message Broker Runtime上的。该容器提供了Event Handler组件的运行环境，将基于MQ/JMS的事件分发到不同平台组件的目标队列上。5. Message Handler组件是处理基于MQ消息的业务请求，包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Message Handler组件处理MQ消息的典型流程如下：首先对MQ消息进行解析，对解析后的业务请求进行分析，之后通过Authentication 与 Authorization组件判断该请求者的业务请求是否可以进行后续处理； 通过Service Locating组件对该业务请求进行服务定位与路

22、由； 将基于MQ的业务请求消息转换成Web Service的业务请求消息； 通过Service Logging组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 6. Web Service Handler组件是处理基于Web Service的业务请求，与Message Handler组件功能类似，也包括消息解析、格式转换，服务鉴权与认证、服务路由、服务日志等功能。Web ServiceHandler组件处理Web Service请求的典型流程如下：首先对Web Service请求消息进行解析，对解析后的业务请求进行分析，之后通过Authen

23、tication与Authorization组件判断该请求者的业务请求是否可以进行后续处理； 通过Service Locating组件对该业务请求进行服务定位与路由； 通过 Service Logging 组件对整个业务请求进行日志记录； 返回业务请求处理结果给业务发起者，如果失败，返回错误消息。 7. Event Handler组件实现对Pub/Sub的处理。8. Service Locating组件负责根据业务请求定位具体的服务提供者。Service Locating通过对服务目录的查询选择适合的服务进行后续的调用，该查询工作可以通过实时的服务目录查询获得结果。9. Service Log

24、ging组件负责记录整个业务请求处理过程中的情况，该组件的实现可以通过文件或者数据库的方式。10. Authentication组件负责对业务请求者进行鉴权，判断该业务请求者是否可以访问平台服务，该鉴权的工作在企业服务总线的外部进行，Authentication组件只是调用外部功能完成。11. Authorization组件判断业务请求者是否具备访问某特定服务的权限，该验证权限的工作在企业服务总线的外部进行，Authorization 组件只是调用外部功能完成。以处理基于MQ消息输入为例，ESB的组件交互图如图 3 所示：图 3. ESB组件交互图    ESB方

25、案设计时的最佳实践根据我们以往项目设计和开发时的一些经验，我们建议进行ESB的方案设计时要遵循下述最佳实践：确定标准的使用：使用与否、使用到什么程度； 确定在ESB上实现的业务逻辑：ESB是一个服务路由和转换中心，而不是一个应用服务器，因此它并不能取代应有服务器。复杂的消息解析和转换相比简单的路由操作所需消耗的成本要高的多，因此在ESB上应该主要考虑路由、格式转换、服务调用等问题，而对于数据本身的处理应该交给相应的应用来完成； 确定消息格式：从标准化的角度而言，XML当然是首选，但是从解析 / 处理性能、行业标准以及对现有应用的最大兼容性的角度而言，可能会采用某些特定格式，例如EDI、SWIT

26、F、平文本或者自定义格式等； 区别消息头和消息体：把数据的Meta-data，例如：安全相关的信息、日志的等级、请求端的标识等放在消息头中，而不要放在消息体中。这样可以很容易地改变其内容及其对其的处理逻辑。在ESB中只处理消息头，避免对消息体的解析； 设计时参考ESB相关的成熟Patterns； 使用服务注册库：如需要服务Endpoint的查找：推荐从服务注册中心进行查找，这样的好处在于：服务提供者可以容易地发布新的服务，服务提供者和ESB之间的耦合度可以更低，通过关于服务本身的Metadata来进行服务的查找和路由； 注重性能和高可用性的考虑； 在必须的情况下考虑交易完整性； 适配器的采用：

27、应用系统通过适配器实现与 ESB 的双向交互，适配器主要分为技术适配器、应用适配器两种，适配器的物理部署可以与EIS部署在一起、或者与ESB部署在一起，也可以单独部署，在适配器设计时要考虑通信协议和消息格式两个方面； 多 ESB 的设计：ESB 也是一个逻辑的组件，在一个企业里可能需要多个ESB，例如：企业内部ESB连接企业内部各个系统，外部ESB实现企业与合作伙伴等的外部连接；再如：企业内部可能存在若干个部门级ESB和一个全企业ESB； 确定服务版本控制策略； 确定端到端的QoS准则； 注重安全性； 确定IT部门ESB平台的负责主体，长期的投入。 ESB的安全性考虑对于ESB的安全

28、性考虑，主要有两种方式，第一种方式是通过ESB内部的Mediation节点来进行服务请求者的认证 / 授权；另一种是调用一个外部服务进行服务请求者的认证 / 授权，如图4所示，图中给出了这两种方式的示意图，具体实施时可以进行选择。图 4. ESB的两种安全实现方式    运行在ESB平台上的服务的管理和监控当一个企业开始它的SOA之旅时，开始阶段通常会选取一个具体的项目进行 SOA 的尝试，然后便会逐步走向全企业采纳，这时，大多数企业都会面临一个问题，那就是服务越来越多，对这些服务目录的管理出现了很多问题，例如：所有与服务相关的信息是如何被管理的，包括存储、管理、

29、维护、存取等？服务请求者如何决定使用哪个服务？服务请求者如何定位服务的 Endpoint？当服务信息发生改变时如何得到通知？因此我们建议用户在尽可能早的情况下考虑服务注册中心的建设，所谓服务注册中心是一个企业范围内的服务信息的存储库，该存储库存储了企业中注册的服务和服务相关的信息，它的主要功能包括：采用集中的方式来管理服务相关的信息，为服务元数据同时提供“注册中心”功能，允许用户存储、管理和查询包含服务描述的服务元数据构件； 提供服务的治理功能，实现整个服务生命周期的管理； 提供服务间依赖、包容关系的管理； 提供分类和版本控制等功能； 提供服务发现和通知等能力等。 除了服务注册中心的考虑之外，

30、我们还要考虑对服务的管理。服务不仅具有特定的功能，还应该满足一些诸如性能、可用性、安全性等QoS指标。服务响应的快慢、什么时间可用、可以被谁调用、在某个时间段里能被调用多少次、哪些事件要记录日志，这些都是服务管理要考虑的问题。通过服务注册中心和服务监控平台的有机配合，我们可以根据服务的响应时间、服务可用与否等策略来实现对服务的动态访问。让我们来看一个例子：图 5. 使用服务监控平台之前ESB的服务请求和响应图 6. 使用服务监控平台之后ESB的服务请求和响应    如图 5 和图 6 所示，我们可以利用服务监控平台对服务进行监控和统计分析，从而使ESB平台可以根据

31、服务提供者的性能优劣来动态地绑定和调用高性能的服务，其过程如下：服务请求者请求“PurchaseOrder”服务 服务注册库查找到服务提供者 服务注册管理平台第一次调用了Proder1提供的服务 Provider1的性能被监控工具监控到 随着时间的推移，Provider1的性能越来越差 监控软件监控到这一现象，就会停止使用Provider1提供的服务 当下一次服务请求者再次请求此服务时，服务注册管理平台将调用Provider2，请求来自Provider2提供的服务。 ESB的开发和测试在ESB开发和测试阶段要完成的工作主要包括：基于eclipse工具的模型驱动的快速开发； ESB集成流程的开发

32、； ESB路由、消息处理逻辑的开发； ESB数据映射和转换的开发； ESB外围适配器的开发和配置； 单元测试：基于模块的测试，包括适配器的测试，路由的测试，BO的测试等； 集成测试：ESB与其他服务提供者和服务消费者的集成测试，重点关注服务接口； ESB平台的性能测试以及系统测试，即整个ESB涉及到的端到端业务场景的测试等。 进行基于WebSphere Message Broker平台进行ESB开发时，通常要考虑以下一些方面的最佳实践，例如：通用的错误 / 例外处理、通用的日志 / 管理机制、子流程设计、交易完整性和消息永久性、ESQL的使用等。通过ESB组合SOA和EDA(一)&#

33、160;投稿 打印 MSN推荐 博客引用   大 | 中 | 小2007-12-10导读：现今的业务应用程序很少完全独立运行。它们需要彼此连接，以便创建集成解决方案，从而为组织带来价值。面向服务的体系结构(Service-Oriented Architecture，SOA)和事件驱动的体系结构(Event-Driven Architecture，EDA)是处理复杂集成挑战的两个不同范例。组织如何选择更好的方法来满足其需求呢?实际上他们并不必选择:企业服务总线(Enterprise Se关键词：SOA EDA ESB  正在加载数据. 现今的业务应用程序很少完全独立

34、运行。它们需要彼此连接，以便创建集成解决方案，从而为组织带来价值。面向服务的体系结构(Service-Oriented Architecture，SOA)和事件驱动的体系结构(Event-Driven Architecture，EDA)是处理复杂集成挑战的两个不同范例。组织如何选择更好的方法来满足其需求呢?实际上他们并不必选择:企业服务总线(Enterprise Service Bus，ESB)允许同时实现 SOA 和 EDA 概念。引言为了适应市场变化，各个组织都倾向于将重点放在灵活性和响应能力上。IT 挑战实际上通常使用恰当的体系结构和技术来支持此业务远景。早期的活动是为了将独立应用程序拆

35、分为可调用的子例程，但远程对象调用和消息传递处理的发展改变了这一点。而在最近，增加对组织中现有资产的重用(可反过来提高投资回报)和集成异类应用程序以形成一致业务解决方案开始变得非常关键了。而这促进了 SOA 和 EDA 的广泛采用。这两个不同的设计范例均以最大化独立于应用程序的服务(可提供 IT 适应能力和效率)的重用为目标。但构建和部署大型集成解决方案始终是一项比较困难的任务。而这正是 ESB 的用武之地，因为它简化了任务关键型应用程序的灵活而可靠的体系结构(SOA 和 EDA)的实现。面向服务的体系结构SOA 是一个体系结构概念，其中所有的功能或服务都使用描述语言加以定义，且各自的接口均可

36、通过网络进行发现。此类接口采用独立方式定义，不受服务实现所在的硬件平台、操作系统和采用的编程语言的影响。SOA 的最重要优势之一是，它可以脱离软件开发中的孤立方式(在此方式中，每个部门构建自己的系统，而完全不考虑组织中的其他人已完成了哪些东西)。这种“竖井 (Silo)”方法将会导致低效且开销巨大的情况出现，可能会多次开发、部署和维护相同的功能。SOA 基于在整个组织范围内共享的服务组合，并提供了对现有资产的有效重用和集成，如图 1 中所示:图 1:“竖井”方法与 SOA 方法的对比SOA 基于方便的请求/应答机制，如图 2 中所示。服务使用者将通过网络调用服务提供者，且必须等待，直到提供者一

37、端的操作完成。图 2:SOA 中的请求/应答机制表 1 对 SOA 解决方案的基本特征进行了总结:功能  描述 松散耦合的交互  服务的调用独立于其技术和位置。 一对一通信  一个特定服务一次由一个用户调用。通信是双向的。 基于用户进行触发  控制流由客户机(服务使用者)发起。 同步  应答将以同步方式发回给使用者。 表 1:基本 SOA 特征事件驱动的体系结构在 2003 年，Gartner引入了一个新术语，用以描述基于事件的设计范例:事件驱动的体系结构 (EDA)。EDA 定义了一种用于进行设计和实现应用程序和系统的方法，其中的事件在各个分

38、解的软件组件和服务间进行传递。EDA 并不会替代 SOA，而只是对 SOA 形成补充。虽然 SOA 通常更适合请求/响应交换环境，但 EDA 引入了一些长时间运行的异步进程功能。而且，EDA 节点可发布事件，且并不依赖于所发布的服务的可用性。它真正地实现了同其他节点的分离。EDA 有时也称为“事件驱动的 SOA”。EDA 使用消息传递来在两个或多个应用程序进程间进行通信。此类通信是由“事件”发起的。触发器通常与某种业务情况对应。该事件的所有订阅者将随后得到通知，从而激活，如图 3 中所示:图 3. 事件驱动的体系结构中的发布/订阅机制表 2 对 EDA 的基本特征进行了总结:功能 

39、描述 分离的交互  事件发布者并不会意识到事件订阅者的存在。 多对多通信  采用发布/订阅消息传递，一个特定事件可以影响多个订阅者。 基于事件的触发器  控制流由接收者确定(基于发布的事件)。 异步  通过事件消息传递支持异步操作。 表 2:基本 EDA 特征通过ESB组合SOA和EDA(二) 投稿 打印 MSN推荐 博客引用   大 | 中 | 小2007-12-10导读：现今的业务应用程序很少完全独立运行。它们需要彼此连接，以便创建集成解决方案，从而为组织带来价值。面向服务的体系结构(Service-Orien

40、ted Architecture，SOA)和事件驱动的体系结构(Event-Driven Architecture，EDA)是处理复杂集成挑战的两个不同范例。组织如何选择更好的方法来满足其需求呢?实际上他们并不必选择:企业服务总线(Enterprise Se关键词：SOA EDA ESB  正在加载数据. 企业服务总线定义企业服务总线(Enterprise Service Bus，ESB)将事件驱动的方法和面向服务的方法结合使用，以简化业务单元的集成，从而在异类平台和环境间建立联系。ESB 充当允许不同应用程序进程之间进行通信的中间层。部署到企业服务总线的服务可以由使用者或事件触发。

41、它同时支持同步方式和异步方式，可促进一个或多个参与者之间的交互(一对一和多对多通信)。因此 ESB 可提供 SOA 和 EDA 范例的所有功能。企业服务总线是一种体系结构模式，可以采用许多不同的产品在组织内实现，并组装起来作为联合总线。现在有越来越多的供应商开始提供完整的产品来满足企业集成需求。例如 IBM WebSphere® Enterprise Service Bus就提供了集成总线功能，可以有效地连接应用程序(利用 Web 服务和 J2EE 等标准)。ESB 服务目前并没有定义 ESB 的正式标准，但通常都认为 ESB 至少必须提供传输、事件 和中介 服务，以帮助集成大型异类

42、应用程序。传输服务 必须确保通过企业总线互连的业务流程间的消息正确交付。传输还包括基于内容的路由功能。这意味着可以将消息定向到不同的目的地。作为任务关键型环境的一部分，这些服务采用事务处理方式，得到了相应的安全保证，并会对其进行监视。事件服务 提供事件检测、触发和分发功能。这些功能与事件处理概念相关，事件处理是一种用于分析和控制事件驱动的体系结构 (EDA) 中相互关联事件组成的复杂系列。事件驱动的范例并不是新概念。不过，它们促进了行业的发展，代表着复杂事件处理 (Complex Event Processing) 的核心概念。中介服务 用于满足两个目的。首先，中介可确保提供必要协议，以满足集

43、成异类系统的需求。由于两个不同的服务并不一定使用相同的传输协议，而中介服务可负责从一个协议到另一个协议的转换，因此可以进行此类通信。协议转换对于业务事务的所有参与服务是透明的。图 4:协议中介由 ESB 进行协议转换其次，中介提供了转换任何消息内容的可能性。这是业务集成的关键服务。它可确保任何进程都能理解通过总线传输的数据。而且，中介允许对内容进行扩展，以使用附加信息丰富消息内容。内容转换由总线负责进行管理:此过程对于任何参与服务都是透明的。图 5:内容中介消息内容由 ESB 进行转换和扩展让我们举个例子来说明内容中介的好处。假定有一个名为 Yummy Inc. 的公司提供在线订餐服务。为了对

44、其向客户提供的菜单进行计划，他们需要验证其供应商提供的食品的可用性和价格。为了获得此信息而发送的消息的典型结构包括:产品标识、数量和目标配送日期。图 6:可用性消息的结构当然，Yummy Inc. 及其供应商并未采用相同的方式来表示这些信息。例如，两个系统上的日期格式就不相同。而且，供应商需要使用配送位置信息，因为 Yummy Inc. 并不是其唯一的客户。ESB 中介服务可以将所传输消息的信息进行转换和扩展，以便目标服务接收到其所需的所有信息，如图 7 中所示:图 7:ESB 中介的内容转换和扩展通过利用之前定义的关键技术服务，ESB 可提供灵活的连接基础设施，用于集成松散耦合的应用程序。它

45、同时支持 SOA 和 EDA 范例。图 8:使用企业服务总线连接各个服务ESB 的好处通过利用其内部服务，ESB 解决方案可带来各种好处。就本质而言，它简化了连接各种相异应用程序的任务，从而最终提高了业务的灵活性，并提供了以下功能:基于标准的连接作为很多异类应用程序间的集成中枢，ESB 必须提供很多不同的集成技术，并对大量供选择的标准技术加以利用。消息传递集成通常支持 Java Message Service (JMS) API，而企业信息系统的连接则是由 J2EE Connector Architecture (JCA) 提供的。为了确保 Web 服务互操作性，ESB 支持 JAX-RPC

46、编程模型。不同的 ESB 组件间的集成可以通过 Java Business Integration (JBI) 规范进行标准化。渗透性集成ESB 具有渗透性本质，因为它可以跨不同的部门、业务单元甚至业务合作伙伴进行应用程序集成。而且，它的核心体系结构原则还可以促进构建于异类开发环境上的应用程序之间的通信。例如，ESB 解决方案可以在不同的编程语言(J2EE、C+ 或 .Net)之间起到桥梁作用。可靠集成ESB 体系结构模式可提供系统安全性、可伸缩性或可用性。企业服务总线使用 SOA 和 EDA，可同时提供同步和异步功能。传输服务可确保可靠交付和事务完整性。因此，ESB 的每个特征都对其稳健性进

47、行了增强，可尽可能减少集成或联合解决方案失败的风险。结束语企业服务总线是一种体系结构模式，可通过传输、事件和中介服务促进和简化业务集成。它可连接各个异类节点并作为中介传递其间的所有通信和交互，这些节点可分散在面向服务的体系结构(同步一对一方法)和事件驱动的体系结构(异步多对多方法)中。ESB 是目前处理集成挑战的最有效方法，是可提供最大业务灵活性和不同应用程序间的高效连接技术解决方案。ESB方案日臻完善 SOA如何应用？（上） 投稿 打印 MSN推荐 博客引用   大 | 中 | 小2009-10-23导读：本文确定了一组最低功能，可以满足ESB与SOA的原则保持

48、一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持SOA的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。关键词：SOA ESB 分布式基础架构  正在加载数据. 引言最新的IT集成是使用Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件。然而，有必要阐明ESB究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建

49、？本文将ESB描述为由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是ESB能够传递值的每一种情形都需要所有的功能。本文确定了一组最低功能，可以满足ESB与SOA的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持SOA的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。随着ESB解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的ESB产品的可用性和功能也日趋

50、完善。因此，在本系列的最后一篇文章中，我将考虑SOA和ESB的发展路线，以指导ESB功能和技术的最初应用，并且阐述如何选择循序渐进的方法。ESB在SOA内的工作角色虽然我不打算深入讨论SOA的定义，但是在这里概括一下大部分对SOA的描述所适用的原则是很有用的：1.利用显式的与实现无关的接口来定义服务。2.利用强调位置透明性和可互操作性的通信协议。3.封装可重用业务功能的服务的定义。图 1说明了这些原则。注意，虽然Web服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。SOA的原则图 1: SOA 的原则为了实现SOA，应用程序和基础架构都必须支持SOA原则。启用SOA应用程序涉及到创

51、建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据SOA原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是ESB的许多功能中的一部分。ESB支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB为SOA提供与企业需

52、要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。本文剩余部分将讨论ESB在SOA中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB功能模型部分中所述。ESB结构ESB有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分

53、布式方式进行部署。图 2展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。分布式图 2: 分布式ESB基础架构的集中控制 我还应该定位在SOA基础架构中ESB与其他组件之间的关系，特别是与 Service Directory、Business Service

54、Choreography、以及 Business-to-Business （B2B） Gateway 这些组件之间的关系。由于上述SOA原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件图 3展示的SOA说明了这些组件之间的关系。ESB方案日臻完善 SOA如何应用？（下） 投稿 打印 MSN推荐 博客引用   大 | 中 | 小2009-10-23导读：在本文中，讨论了大多数通用的SOA原则，以及它们与Web服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替

55、换原有的服务实现。这些功能都是通过ESB实现的。关键词：SOA ESB 分布式异构环境 SOAP WSDL  正在加载数据. SOA中的ESB角色图 3: SOA中的ESB角色ESB需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web服务远景在业务服务目录和服务路由目录的角色中都放置了一个UDDI目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的

56、一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与ESB是分离的。Business Service Choreographer的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过ESB将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术ESB分离的技术。最后，B2B Gateway组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是ESB的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway组件和ESB的功能，但是B2B Gateway组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是ESB的一部分，并且不一定受到ESB技术的支持。ESB的功能模型表 1对现有文献中确定的一些ESB功能进行了总结和分类。虽然有一些功能非常基础，但