ESB也有SOA和EAI的立足之地

（中国软件网讯）企业服务总线(ESB)全称为Enterprise Service Bus。它是传统中间件技术与XML、Web服务等技术结合的产物。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也不需要适应基于事务的流程，他宣称，但是却能很好地适应基于事件的活动。复杂事件处理器来控制这些活动更为普遍，而且允许正常的异步、无状态消息转化，更符合事务处理特点，他补充道