企业服务总线（ESB）是企业架构师广为熟知的工具。它也在企业构建更为复杂的应用架构的同时成为SOA中较为重要的一部分。并不是所有的ESB生来相同，而且似乎没有两个企业在实现ESB的时候会用同样的方法。

　　我们回顾了2011年有关ESB的新闻，尽管很明显ESB不仅是和SOA单独相关联的，而且EAI设计业紧密相关。下面我们一起追随ESB、EAI和SOA的脚步看看这一年有哪些内容值得回顾。

　　应用集成架构中ESB有何用武之地？

　　尽管企业服务总线（ESB）不是什么新东西，但却仍旧是一个充满困惑的交集点。经过这么多年的那么多的实施，它们是做什么的、它们是怎么做的，以及具体的产品是否有助于创建一个面向服务架构，这一切仍都是需要讨论的东西。

　　Chris Harding是开放群组（The Open Group）负责SOA及客户计算的论坛管理员，他则认为ESB的性质并不总是清晰的。他指出，互联网有TCP，这个东西是一切的标准与核心。而在ESB的企业软件栈上面则没有类似的东西。“你所拥有的不过是在对ESB是做什么事情的这方面，有一个良好的共同理解，但却又缺乏严格定义的接口。这个东西要松散得多。”他说。

　　案例：SOA和EAI踏入企业服务总线集成疆土

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

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

　　ESB和应用集成

　　IBM最初创造出WebSphere的时候，它是一个应用服务器。但是不久“WebSphere”形成了一个包含型的品牌名称，包含了IBM各种各样的中间件组合。这些工具的集成深度最初很低，就好像IBM把WebSphere的标签贴在一大盒玩具上一样。多年来集成已经改进是肯定的，但是随着IBM继续兼并性能，WebSphere中间件的某些不间断的工作仍在继续。

　　揭示EAI和ESB之间的区别

　　在我最新一篇关于成功使用ESB文章发表之后，收到了很多反馈，基于这些反馈以及LinkedIn上SOA兴趣组关于 “进行ESB还是不进行是个问题” 的论点，我认为探讨一下ESB和EAI技术是很有用的。

　　EAI或者企业应用集成在ESB被发明出来之前就存在很久了，这些技术旨在为管理点对点集成蔓延提供一种手段，这种集成蔓延经常以连接不同的系统之间出现，变得越来越重要。EAI技术允许这些集成集中管理，甚至是促成一个企业部门，像集成能力中心（ICC）或者集成卓越中心。不幸的是，很多EAI技术由于集中化兼并了所有集成逻辑而遭遇了性能问题，因为这样做十分复杂。

　　SOA环境中如何正确实现ESB？

　　自从2002年开始使用企业服务总线或者ESB这个术语，ESB就一直是一项有争议的技术。实际上争论的焦点主要在于它不是一项技术，而是一种架构方法。

　　SOA是2000年初的热门话题，厂商希望将其资本化。ESB产品成为最接近SOA的技术，导致一些人认为必须采用ESB，才能拥有SOA（当然不是），或者购买一个ESB，就会奇迹般地拥有SOA（当然也不是）。