用ESB实现SOA，同时结合事件驱动的架构、Web服务的治理、复杂事件处理、语义数据集成等技术，是应对复杂的应用集成挑战的一个有效方法。

　　从企业服务总线（Enterprise Service Bus，ESB）在2002年被正式提出以来，我们看到ESB不管是在实现方式还是部署方式上都有了不小的变化。在过去的四年多的时间里，ESB作为软件领域里的一个独立产品也被越来越多的人所接受，众多的ESB供应商正在架构、连接性、易用性以及服务质量的保证（如持续可用）等方面进行竞争。很多综合服务供应商（如IBM、BEA）、企业应用集成商（如Tibco、webMethod）以及Web服务工具供应商都纷纷给自己的产品冠以ESB的名号，英国电信甚至把ESB做进了它们的一个硬件产品中。

　　很明显，作为SOA(Service-Oriented Architecture)的核心和基础架构，ESB已经成为准备踏上和已经踏上SOA之旅的CIO们必须认真考虑和仔细研究的一个产品。因为作为一种中间件，ESB通过与它连接的各种应用的服务级接口实现各种应用之间的连接，控制它们之间的通信，这一功能正在越来越多的生产系统中发挥着作用。更为重要的是，几年来很多企业和机构已经在生产中部署了ESB，ESB的效果得到了一定程度的校验，同时人们对如何充分发挥ESB的作用以及建立SOA的环境，为此需要建设、部署管理哪些基础设施有了越来越清晰的认识。这些基础设施包括：

　　●面向流程、事件驱动的架构（Event-Driven Architecture，EDA）；

　　● Web服务的治理；

　　●高级Web服务规范（WS-*）;

　　●复杂事件处理（Complex Event Processing，CEP）;

　　●语义数据集成。

　　事件驱动的架构

　　谈到ESB就不得不谈到面向流程、事件驱动的架构，因为ESB与这种架构配合起来可谓相得益彰。

　　通常，点对点的集成是通过简单的请求/响应这种同步的方式来完成交互的。在这种环境中，ESB作为数据传输和转换的中介可以很好地完成这一任务，但是，ESB最能发挥作用、也最能体现其带来的灵活性的地方还是在面向流程、事件驱动的架构中。

　　在进行跨多个应用、大范围的集成时，成功的关键是有一个灵活的架构，面向流程、事件驱动的架构就是这样的架构。通过使用ESB，事件驱动的架构中的每个应用与其他应用之间处于一种松耦合状态。在这种架构中，每个应用独立于其他应用运行完成一项任务，或者异步地完成一组任务中的一个。即使在一个应用发出了一个请求，然后等待响应以完成接下来的流程时也是这样。这个请求被发到总线上，按照预先定义的流程，这个请求可能会经过很多应用、数据源、路由器和转换器。上述一系列的行为都是独立完成的，最后的响应也是作为一个独立的事件到达最初的这个应用。

　　事件驱动的交互模式一个主要优点就是保证应用之间的松耦合。只要接入ESB中，每个应用都不用了解如何与其他的应用进行交互这些细节，ESB负责处理所有的协议、数据格式和不同的交互模式。

　　当然，事件驱动的架构只有在一定条件下才能有效地工作。首先，ESB必须具有可靠和高可用的异步消息传递能力。在一个同步的点对点的集成项目中，如果一个应用没有收到一个请求的响应，它会发出错误的信息，同时再次尝试发出请求。但是在异步的情况下，应用向ESB发出一个请求以后就不再关心是否会有响应，直到一个新的请求到达，通知这个应用完成下一个处理。由于很多时候企业的所有交易都必须经过ESB总线完成，因此ESB必须有容错能力，支持复杂的业务逻辑，遇到错误的逻辑也能及时恢复。

　　另外一个必须满足的条件是，应用需要适应这种事件驱动的交互模式。在事件顺序非常重要的场合，应用必须能够检查事件的顺序并做出适当的处理，否则，ESB就要有能力保证在复杂的逻辑情况下（也许这些逻辑还会有错）事件的先后顺序。

　　Web服务的治理

　　每个企业的SOA之路都不同，有时甚至一个企业的各个部门也各不相同。有些企业中可能同时有几支开发队伍在使用不同的Web服务工具，有些企业或许已经能体验ERP系统或者其他应用服务环境中Web服务的作用了，在这些企业中很可能已经部署了多个ESB产品，当然，也很可能一个也没有。

　　在部署了SOA架构的这些企业中，Web服务管理平台是一个能发挥重要作用的管理工具。特别是在业务流程需要跨越多个异构的环境时，Web服务管理平台能提供端到端的业务流程的可视性，保证它的安全、进行控制和执行某些策略。除了跟踪服务级别协议外，Web服务管理平台还能提供一个业务的视角来帮助了解SOA环境中某个服务失败后给业务带来的影响。为了执行SLA和其他的业务规则，它还能动态地调整SOA环境。无论是点对点的同步模式下还是异步的事件驱动模式下，这一点都是成立的。

　　有些Web服务管理平台能把上述能力扩展到ESB、应用服务器和数据库访问上，如果服务的执行需要跨不同的平台、数据库、协议和设备时，有些甚至还可以提供一些业务级别的指标和报告。

　　高级Web服务规范

　　为了确保Web服务之间的顺利交互，一些厂商在一起共同制订了一些高级的Web服务规范（WS-*），如WS-ReliableMessaging、WS-Security, WS-Addressing、WS-Policy等，由于这些厂商的大力推动，这些规范正在逐步进入到应用阶段。过去，ESB由于采用厂商自己定义的、面向消息的中间层作为核心架构而被贴上了专有技术的标签，如今，随着ESB逐步采用了这些高级的Web服务规范，这一点不再成为问题。事实上，正是ESB让WS-*规范落到实处，因为在ESB的顶层提供了这些规范的实现之后，使得Web服务的可扩展性、可管理性和可用性都大大增加了。此外，在其他平台和应用服务供应商都实现这些规范后，ESB之间的互操作性也得到了很大改善。

　　复杂事件处理

　　复杂事件处理（Complex Event Processing，CEP），有时也称事件流处理（Event Stream Processing，ESP），是事件驱动架构领域里的一个新技术。作为一种实时事件处理并从大量事件数据流中挖掘复杂模式的技术，CEP通过分析有意义的事件从而实时地取得这些有意义的信息。该引擎可广泛应用于网络入侵探测、SLA监测、航空运输调控以及金融服务领域的算法交易（在电子市场中通过计算机程序来进来金融投资的一种交易方法）、金融风险管理、欺诈探测。

　　通常CEP引擎被嵌入ESB中，作为ESB一项服务。其中的事件流可以来自ESB，也可以有其他的来源，如外部的RFID阅读器和证券报价信息。CEP找到了复杂事件的模型，接下来可以向业务活动监控系统的控制面板发出一个警报，也可以调用一个服务或者通过ESB激活下一个流程。

　　语义数据的集成

　　如果需要，ESB可以在业务流程中插入一个数据转换引擎，这就使得不同应用之间的数据格式的转化变得非常容易。现在将一种通用的数据格式转换为某一专有的数据格式的服务，如验证（Validate）、丰富（Enrich）、转化（Transform）、执行（Operation）等，已经作为最佳实践出现在市场上。

　　在一个面向流程、异步事件驱动的计算环境中，数据转换的方式与点对点的环境是不同的。为了让应用真正实现与其他应用的松耦合，应用之间用来通信的数据必须从原来的专有数据格式转换为一种通用的或者在整个组织内相对规范的数据格式，从而使得所有接入SOA架构中的应用只需关心如何从通用的数据格式转换成自己专有的数据格式或者从专有的数据格式转换为通用的数据格式，至于目标应用究竟需要什么样的数据转换则可以通过ESB根据需要来进行。

　　这就极大地降低了把新应用加入到SOA环境时的复杂性，也降低了现存应用之间交互的复杂性。采用这种方法带来的另一个好处是，中间服务（如路由、分离、聚合等）可以按照规范的数据格式来编写，因此，也降低了程序开发的难度。

　　尽管普通的映射工具也可以完成从一种数据格式到另一种数据格式的转换，但在应用众多的场合，数据模型非常多而且复杂、同时涉及众多各种不同的应用和数据源，这时此类工具往往缺乏管理这些数据模型之间的映射和相互关系的能力。

　　作为ESB的一个补充，语义数据映射工具已经出现，它所针对的正是大规模部署SOA时迫切需要解决的各种数据格式之间的关系问题。与之相比，在进行点对点方式的集成时，人们对每一对需要通信的应用之间的数据转换关系是非常清楚的。

　　用ESB来实现SOA

　　事件驱动的架构是一种非常适合SOA的体系结构，它作为SOA的一种最佳实践备受关注，而ESB正是将二者联系起来的关键部分。而且，更为关键的是在大型SOA架构中，ESB扩大了集成应用的集成范围，降低了集成的难度，这是以前无法想象的。只是部署和管理企业数据之间不同含义的复杂语义映射还不令人满意，这还是一个需要继续进行研究和不断创新的领域。

　　到目前为止，已经有很多企业采用和部署了ESB，但除了ESB外，在规划企业的SOA战略时还有很多需要考虑的。比如，需要运行很多服务，各种平台之间的交互需要保证安全，需要进行管理。幸运的是，只要符合SOA的核心思想，它们通常可以通过Web服务接口接入ESB集成到SOA环境中。