引言

　　总而言之，ESB是SOA体系架构中的信息流动与交换的基础。ESB的参与主体是服务，总线提供了服务间消息的识别，转换与路由的载体。但是，看起来，读者可能还会有一定的疑惑，ESB首先是一种概念，实现的方案又很灵活，最终支持ESB的产品也很多，那么，ESB实施方案与具体技术各自适用的场合有什么特点?基于不同实施方案的ESB又是如何互联的呢?本文将对上述问题加以总结。

　　IBM对ESB的产品支持

　　到目前为止，IBM 专门支持ESB实施的主要有3种方式，WAS6 SIBUS，WAS ESB，和WBI Message Broker。这里按照他们出现的先后顺序简单地介绍一下他们的使用场合:

　　1) WBI Message Broker

　　最早提出Message Broker(或它的前身Event Broker)的主要目的，是针对中间件平台不同消息格式的自动转换与路由，支持Web Service(SOAP), MQ, JMS 等不同中间件平台的消息互联以及与现有系统的消息集成。因此，虽然Message Broker一开始主要是针对EAI的一种集成方案，你仍然可以从中看出Message Broker的设计初衷与我们现在的ESB的思想是基本一致的。尽管Message Broker出现的时候还没有明确的ESB概念，但是，随后IBM在SOA上投入了巨大的努力，作为SOA基础架构的ESB，也得到了非常的关注。Message Broker逐渐发展成为专门的ESB实施工具，而且依托完善的MQ消息平台，它对ESB的支持是重量级的，是目前构建ESB最强大的产品。确实，理论上大多数常见类型的消息都可以通过WBI Message Broker加入到SOA的实施场景中。而且，更重要的是Message Broker是真正适合复杂企业环境的ESB实施方式，它的成熟性与性能都是几个方案中最好的。唯一的不足是，如果应用在不很复杂的企业应用环境中，会略显笨重。而它使用的ESQL语言，由于不是基于开放标准的，也会对使用者的学习曲线有一定影响。

　　2) WAS6 SIBus

　　我们前面已经提及SOA架构与面向消息的中间件之间密不可分的关系。为了更好的支持SOA， IBM重新开发了内嵌在WAS应用服务器中的消息服务实现。因此，从WAS6 以后的内嵌消息引擎不再是原来的MQ的简版，而是一种功能更强的更稳定的消息平台- WPM(WebSphere Platform Messaging)。它是一个纯JAVA的实现，符合JMS的规范，而且提供了很多扩展。能够很好的同时支持面向服务和面向消息两种编程模式。因此，能够将服务与消息很好的整合在一起。SIBus是一种依托WAS6 应用服务器平台的ESB实现，支持Web Service, JMS 和MQ的消息互联与转换。它的应用场景应该是基于WAS的环境中，面向Web service与JMS类型的企业服务。它的问题主要是开发的难度比较大，由于没有很好的开发工具的支持，开发者需要有较丰富的J2EE/EJB的开发经验，而且还需要通晓WAS6 SIBus的相关API与配置，这无疑限制了SIBus的进一步发展。

　　3) WAS ESB

　　WebSphere ESB 是 IBM 发布的独立ESB产品。它目前所能覆盖的平台只有WAS。看起来与SIBus有些相似，但实际上它发布的目的主要是补充WBI Message Broker。我们前面讲过，WBI Message Broker实施的场景是复杂的企业IT架构，但是一般规模的企业可能对采用这种昂贵的解决方案有所顾虑。那么在这种环境下，小规模的ESB解决方案，WAS ESB是性价比更好的选择。但是，WAS ESB将更倾向于提供只涉及Web服务的总线，这与Message Broker的广泛适用性有一定差距。WAS ESB对SIBus，如果单从体系结构的角度他们都基于WAS的WPM，象一对孪生兄弟。他们最重要的区别在于WAS ESB提供了基于SCA的开发模式和完备的开发工具，并且提供了预先定义的元中介(Mediation Bean)。这样用户通过工具WID (WebSphere Integration Developer)，可以采用拖拽/配置的方式简单地开发中介的信息流, 实现ESB不再是复杂的任务。而SCAServices Component Architecture)组件对用户屏蔽了底层的实现细节，WPM或SIBus中介句柄(Mediation Handler)对用户来说是不可见的。关于WAS ESB中的SCA开发模式，笔者将另外撰文，这里不再赘述。总而言之， WAS ESB可以被视为ESB实施的简化版，适用于不需要Message Broker复杂性的相对简单的环境。它相比SIBus而言，具有开发界面友好的优势，但由于采用SCA封装底层的服务，可以想见在它的早期版本可能会带来性能上的一定损失。

　　图 1:WAS ESB与 WBI Message Broker的比较

　　这是一张关于WAS ESB与WBI Message Broker关系的预测图，希望大家能从中得到感性的认识。针对不同的场景和开发者的技术经验，采用更合理的设计方案。