就像瑞士军刀有很多刀和工具，企业服务总线（ESB）对于很多人就是很多东西。为什么呢？显而易见。在ESB兵工厂中有一大堆中间件工具。这些工具支持SOA或者EAI，ESB的责任就是带来性能。ESB似乎需要有人来告诉要站出来，展示他们真正的身份。

　　Ken Johnson是红帽（JBoss企业中间件）的中间件产品经理，他认为很多人把ESB简单地看做是软件的一块，尽管更好的观点是将其看做“构架一项解决方案的方法”。此外，虽然以“服务”的名义存在，ESB并不能一直按照服务来使用。ESB可以假定为大量功能。例如，FuseSource的CTO，同时也是Apache ServiceMix、 ActiveMQ和Camel联合创始人， Rob Davies说过ESB和EAI之间的区别主要在于其用例。“表象之下，ESB可以用消息层互相通信，”他说道。

　　ESB部署模式

　　Neeraj Satija是Two Degrees Mobile的软件开发经理，也是WSO2（ESB领域另一个厂商）的客户，他将ESB使用模式描述为和IT合二为一。ESB就是一种总线，“存在于前端渠道（像Portals、IVR和SMS）和后端系统（像CRM系统、网络元素和收费和充值系统）中间。”

　　Satija表示他目前的企业，以前也是用来自IBM、甲骨文和Mule这样的厂商的ESB。现在WSO2成为他们构建SOA的平台。“我们开始使用WSO2中间件技术组合中的一部分。我们的IT架构的主要部分是严重依赖SOA范式，而且，由于这个架构，我相信我们正在做一些特别的、创新工作，”他说道。此外，他补充道他的公司没有使用EAI，而是使用SOAP。

　　“我们的平台是典型的SOA平台，服务消费者（渠道）和服务提供者（后端系统）通过基于XML的协议相互通信，”他解释道。实际上，在Two Degrees Mobile公司，不同的事务使用不同的消息模式来实现，像发布与订阅或者事件监听，根绝业务需求来确定模式选择，Satija解释道。

　　Satija表示他发现很多模式和实践在部署ESB时很有用，包括：

• 服务抽象（用ESB代理解耦实际终端）
• 标准化服务契约
• 数据格式转换
• 协议转换
• 用工作流引擎进行业务逻辑编排
• 数据格式转换和数据模型转换

　　ESB高吞吐量实现

　　尽管也有人担心ESB的吞吐量，Satija说Two Degrees Mobile在一些业务事务中使用WSO2中像ESB和工作流引擎这样的组件，在高峰时段，一些组件可以每秒钟处理50个事务。他给出三个“最佳实践”来实现良好的吞吐量：

• 有效负荷大小和内容优化
• 基于业务需求将ESB和工作流管理器联合
• 在包含业务逻辑的大型应用上优先开发轻量型原子中间件组件

　　Bloor Research的首席分析师兼联合创始人Robin Bloor博士也谈了一些性能挑战，他说说道吞吐量/性能，ESB更倾向于扩展到某一确定层级，但是并不是所有的都能很好地扩展。

　　“这取决于他们的分布式流程做的好不好，”他补充道。大多是SOA实现包含了ESB，因为过量消息负载以及灾难恢复需求，他解释道。此外，没有ESB的话，很难实现应用或者服务的高度重用。

　　点对点集成的时候，在使用EAI的地方，来使用ESB并不充分。“可以在没有ESB的情况下，用硬钢丝来进行点到点的EAI，但是当复杂到要授权枢纽架构时，ESB就要用在HUB上了，” Bloor如是说道。

　　“ESB就是个管道，而且庆幸是个高性能管道，所以延迟不大可能成为问题，除非ESB使用不当，”他补充道。

　　同时，另外一个WSO2客户就目前ESB做扮演的角色提供了些许不同的观点。“我们发现基于总线EAI架构和实际的ESB/SOA解决方案之间存在细微的不同，” Simon Bilton说道，他供职于英国一家软件公司。

　　他的同事Vladimir Klevko和Alex Karimov也指出，原来企业表面上看起来是用逻辑方法来连接截然不同的应用程序或服务，通过实现集中运输总线机制进行，这个机制允许这些应用或者服务不用直接的点对点连接器就能交付或者接收数据。

　　然而，通常，这些集中总线大部分是专有的，必须为每一个应用或者服务编写集成引擎。“尽管这样可能会针对具体企业具体问题交付解决方案，却很难连接追加的服务，比如外部客户服务，因为没有编写另一个预定的集成块，” Bilton介绍。所以，他解释道，“我们认为这样的实现不符合SOA的关键性能，也就是服务解耦。”

　　另一方面，ESB使用开发标准，而且集成点通过“契约（像WSDL）”定义。尽管每一个服务或者应用仍需要开发合适的适配器，这个适配器必须符合契约中的定义，还要能够直接插入任何基于类似标准的ESB。此外，这样也能更轻松地集成追加服务，不论是内部的还是外部的，而且没有重开发成本。

　　“在我们公司中的很多例子中，企业是为EAI架构，来部署ESB的，将其看做是传输机制。因此，消除了专有总线，在终点之间代理服务，” Bilton说到。然而，Bilton和他的同时表示这就像个“小客栈”，因此服务不需要全部重用，不需要解耦，所以也就不需要交付基于核心SOA原则的实际SOA解决方案了。

　　Bilton和他的同时也为ESB消息提供了一些建议：消息结构尽可能简单，工作负载减轻，因为这是实现高吞吐量最有效的途径。

　　复杂事件处理

　　“在SOA中，消息并不期望收到一个响应，但是可能期望收到反作用，可能是作为原始小时触发事件的结果，” Bilton提醒道。每一个交换的消息异步执行而且隔离开，因此不构成会话。

　　SOA也不需要适应基于事务的流程，他宣称，但是却能很好地适应基于事件的活动。复杂事件处理器来控制这些活动更为普遍，而且允许正常的异步、无状态消息转化，更符合事务处理特点，他补充道。