近期，除了普元软件的“SOA中国关键任务”在上海、北京火热召开之外，中国的另一中间件巨头厂商金蝶也在全国巡演其Apusic ESB。虽然其口号是“让SOA真正落地”，但是，ESB问题真的是解决当前SOA发展的关键所在？

我不敢苟同。

早在多年以前，Burton Group（伯顿集团）的资深分析师Anne Thomas Manes就曾表示：“如果让我推荐启动SOA的“基本组件”，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。SOA是用于拆卸应用竖井(application silos)，而集成系统则是修补这些竖井。”

其实从概念中不难看出，Enterprise Service Bus，即企业服务总线，是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。在SOA项目的后期，你还可能需要一个编制(orchestration)引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。

相比较普元与金蝶的作法，虽然在推广方面两者都是从自身产品出发去进行推广，但至少“服务构造”的理念要大大优于ESB的解决方案。在SOA真正落地这一期间，迈出的步子是否应该更坚决的落在最小粒度的服务环节上还是ESB应用方面？希望听到大家的意见。

ESB的应用可以更确切的关注在“修补”方面，但是服务构造也并非是指要拆掉重来啊？不过，显而易见，这个理由很在理~~~