介绍
如今，企业服务总线是一个有用的解决方案，这一点毋庸置疑。它和一组工具相结合一起解决了应用与服务集成领域的实际问题。但是，它们给不熟悉它们的使用者所带来的轻微不便却和工具箱一样。那些使用者知道问题的解决办法肯定在箱子内，但却不知道解决问题的工具是哪个！
从企业服务总线到路由问题
ESB涉及多个应用领域，包括实现信息系统范畴的面向服务架构（SOA）。但它们的基本目的都是为了简化应用和服务的集成——简而言之就是让一个应用或服务去调用另一个应用或服务。这种非常简单和平凡的事业有各种额外的复杂级别：
“路由”，发生在不止有一个服务、而是存在多个发出调用的源服务及多个供选的目标服务时；
“协议桥”，发生在服务被暴露于另一个协议之上、属于其他服务器、或甚至属于其他信息系统时；
“转换”，发生在服务消息没有相同数据格式的时候——这是惯例而非意外。
它们三个：路由、协议和转换都有不少近亲，虽然如此，但是它们三个仍被认为是主要的ESB概念。在本文中，我们将关注第一个，以及它如何关联到它的一个近亲：编配。在此先对它们进行一个简短介绍，我们认为路由从根本上说是低级别的，它在ESB核心之中或附近，且依赖技术配置（如服务部署描述符）来提供与消息必须被发到的目的地相关的技术决策。编配可被看成是将多个服务调用组合为高级、更有用的组合服务的过程，但它也通常被打上了“业务级”的印记，此时它代表了跨应用和信息系统实现结合了特定业务服务的业务级流程的缩写。
路由与编配的对决：既不是“一边倒”，也不是“黑白”世界
那么，在ESB中是如何处理编配需求的呢？看上去使用一个配备有中间件解决方案的编配引擎更符合逻辑。可是，这是个没法简单回答的复杂问题。让我们考虑如下例子。
显示一个项目（item）列表
“ItemManager”应用用于通过创建、更新、删除等操作对项目进行管理。一个“ItemManagementListener”服务连接到了这个应用上，它负责在项目被更新时发布通知。
另一个应用：“HammerMonitor”是一个监测工具，用于显示锤子相关项目的更新信息。这个应用暴露了一个“HammerMonitor”服务，它包含了一个接收这些通知的“显示（display）”操作。
这两个服务都暴露给了一个ESB。我们的目的是想让HammerMonitor显示ItemManagement应用知道的锤子相关的项目信息。
为了让ItemManagementService连上HammerMonitorService，我们需要配置若干ESB连接器（connectors）（所谓的“绑定组件”）。一个连接器被链接到ItemManager应用，另一个被链接到HammerMonitor应用。
此外，跟HammerMonitor链接的连接器被配置成在ESB内部暴露一个名字为“hammerMonitorService”的端点（endpoint）。于是，实现我们目标的一种简单方法就是对ItemManager所链接的连接器加以配置，使它在每次收到来自 ItemManager的消息时就在ESB内部调用端点“hammerMonitorService”。
可是，正如现实世界经常发生的那样，我们假设这两个服务拥有不同数据的格式。这对SOA并不构成障碍，因为SOA定义了一个松耦合的架构（即，服务消费者并不必须符合服务提供者定义）。
ItemManagement应用向ItemManagementListenerService提供了以下消息：
<items>
<item type="Hammer" name="hammer1"/>
</item>
而ItemMonitorService的“显示（display）”操作使用以下格式：
<hammers>
<hammer hammerName="hammer1"/>
</hammers>
这时，只是简单地进行调用并不能把两个服务链接起来。ItemManagement应用提供的数据必须首先经过转换。这实际上是一个非常简单、局部的编配需求，跟业务级没有任何关系。
解决这个问题的第一种方法是，使用一种常见、知名的编配解决方案，如成熟、外部部署、支持BPEL的编配引擎[2]。这种方法可以行得通，但是用在这个例子中就好比杀鸡用牛刀：要么所有被转换消息必须经过一个集中、远程的编配引擎，这种方式类似过时的“集线器（hub）”集成架构；要么就必须在每个节点都部署一个编配引擎——对于这个简单问题来说，这种解决方案显然过于复杂了。