介绍

　　如今，企业服务总线是一个有用的解决方案，这一点毋庸置疑。它和一组工具相结合一起解决了应用与服务集成领域的实际问题。但是，它们给不熟悉它们的使用者所带来的轻微不便却和工具箱一样。那些使用者知道问题的解决办法肯定在箱子内，但却不知道解决问题的工具是哪个！

　　本文的目标是帮助ESB使用者在面对复杂多样的ESB概念——路由和编配——时，根据他们的需要选择合适的工具。我们并不打算宣讲抽象的理论，相反我们将把我们的努力和论证植根于一些简单的、现实世界的例子（它们使用了一个JBI兼容的ESB——OW2 PEtALS[1]）中，并尝试填补低级别路由和全局的业务服务编配之间的空白。换句话说：我们将尽力揭示路由和编配的不同层级是如何形成的。

　　从企业服务总线到路由问题

　　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提供了以下消息：

　　而ItemMonitorService的“显示（display）”操作使用以下格式：

　　这时，只是简单地进行调用并不能把两个服务链接起来。ItemManagement应用提供的数据必须首先经过转换。这实际上是一个非常简单、局部的编配需求，跟业务级没有任何关系。

　　解决这个问题的第一种方法是，使用一种常见、知名的编配解决方案，如成熟、外部部署、支持BPEL的编配引擎[2]。这种方法可以行得通，但是用在这个例子中就好比杀鸡用牛刀：要么所有被转换消息必须经过一个集中、远程的编配引擎，这种方式类似过时的“集线器（hub）”集成架构；要么就必须在每个节点都部署一个编配引擎——对于这个简单问题来说，这种解决方案显然过于复杂了。

　　那么，似乎单一、全局、业务级的方法不足以解决编配需求：当总线提供的通用路由能力不够且主要问题还不是通过操纵受SOA管理的业务服务来实现业务规则或流程，而仅仅是结合技术性、“幕后”服务，这样它们就能“把事情搞定”的时候，路由层和业务层之间必须做的“脏”活怎么办？

　　总线级、开发相关的方法：拦截器

　　解决路由和编配需求的最基本方法是增强ESB的内置特性。

　　在我们上面的例子中，一种直接规避发送消息应用和接收消息应用之间数据一致性问题的方法就是：在连接器（即，ESB的绑定组件）内部增加一些逻辑。

　　例如，PEtALS ESB提供的绑定组件就能使用“拦截器”进行扩展。拦截器是一段Java代码，它在一条消息被发送到总线之前在“发送者”绑定组件内部执行，或在一条消息被交付后在“接收者”组件内部执行。

　　在我们的例子中，这个代码可以调用一个XSL转换将ItemManagement的消息格式改编成HammerMonitor的格式。

　　不过，这种方法有很大的限制且不够彻底。如果XSL转换发生在“接收者”连接器（HammerMonitor链接的那个连接器）中，它将假定所有接收的消息都具有ItemMangement的XML结构。假如有条消息来自另一个应用，它具有不同的结构，这种情况下XSL转换就会失败。

　　拦截器可以检查传入消息结构，根据检查结果选择不同的XSL转换，但是这将和发送者耦合非常紧密。这种方式不符合SOA的松耦合概念。而且，除了转换之外的任何其他需求也意味着要在ESB引擎内开发另一组相关的特性，这不是ESB使用者所期望的，也不应该是ESB所期望的。

　　面向组件（“构造单元”）的方式：EIP工具集

　　ESB通过供应集成组件提供了集成设施。这些组件可以完成一组消费者和服务提供者之间细小、有用、灵活的操作。它们一般都实现了几个企业集成模式（它的知名，Gregor Hohpe功不可没[3]），是ESB使用者的瑞士军刀。

　　这些EIP组件不依赖服务描述（WSDL等），它们仅仅执行一些细小的任务。最知名的是：

　　·“管道（pipe）”模式：单个事件触发一系列的处理步骤，每个步骤执行特定的功能。EIP组件负责安排调用的次序。
　　·“基于内容的路由器”模式：EIP组件检查消息内容，并根据消息中包含的数据将消息路由到不同频道。
　　·“消息分发器”模式：EIP组件向一组服务提供者发送消息（多点）。
　　·“分散收集器”模式：EIP组件将一条消息路由到一组服务提供者，然后将所有响应聚集成一条响应消息。

　　具备所有EIP组件操作的知识将使得开发者可以把业务应用（消费者和服务提供者）和一些“集成模式单元”结合起来。最终结果是一个组合集成。每个集成单元是一个服务。

　　当然，要想设计这种组合集成，一种专用的图像IDE非常重要。因为，除了简化使用，它还带来了所有单元配置的集中视图。例如，以下几个例子就是使用PEtALS ESB集成工具设计的。

　　管线（pipeline）

　　管线（pipeline）模式被用来将一条传入消息“输送”给几个服务。这条消息被发送给第一个服务，第一个服务的响应被发送给第二个服务，第二个服务的响应发送给第三个，依此类推。

　　消费者和服务提供者之间的适配

　　我们刚刚描述的ItemManagement用例可以设计成这种结构：一个转换组件和一个“管道”单元。

　　管理服务版本演变

　　按以下方式，相同的行为也可被用来管理服务版本的演变。消费者总是向“管道”单元发送相同的消息结构，“管道”单元是真实服务的代理。一旦服务签名改变，“管道”单元首先将消费者消息发给XSL转换（将消费者的消息改编成新服务格式），然后再将其发送给服务的新版本。消费者不需进行任何改变。

　　基于内容的路由

　　我们已经了解了如何将几个服务组装成一个服务。但是动态流程方面的问题还没有得到解决。这里再次遇到了路由挑战：如何调用多个服务中的一个？

　　如何在多个服务之中将调用切换到某个服务？嗯，路由器单元可能可以执行一些测试来将请求切换到某个版本或其他版本的服务上。

　　例如，ItemManagementListener可以向一个“基于内容路由”的组件发送关于锤子和锯子的通知。这个组件测试消息中的项目名，然后将它发送给正确的监测服务（HammerMonitorService或SawMonitorService）。由于每个服务定义了不同的格式，在发送消息给正确的服务之前必须完成两种不同的转换。这样，我们就将“路由”单元和“管道”单元与“转换”单元组装在了一起。

　　分发器

　　另一种集成需求可能是将一个请求发送给不同的服务（多点通信）。例如，在一个项目订单从前端应用发送给订单系统的时候，一封要求确认的电子邮件也可能同时被发送给客户。例如，消息被发送给了订单服务和SMTP服务。

　　我们可以这样设想，ItemManangementListener服务（它负责发送来自ItemManagement应用的通知）必须将通知发布给HammerMonitor、SawMonitor和一个全局监测工具（它接收所有通知）。

　　可以给上面的组合集成增加一个“分发器”集成单元，它负责给“路由”单元和全局监测服务发送消息。