使用 WebSphere ESB 构建企业服务总线，第 6 部分: 高级 WebSphere ESB 功能探索

引言

本系列的前五篇文章讨论了几个基本场景，说明了如何在真实的业务环境中利用企业服务总线（Enterprise Service Bus，ESB），并给出了一系列示例来说明可以如何使用 IBM WebSphere ESB 产品实现这些场景。在最后一部分中，我们将对虚构的 Posts-R-Us 公司已完成的工作进行总结，然后将指出您接下来可能会重点关注的 ESB 领域的一些内容。其中一些内容已经在其他文章中进行了讨论，其他内容将在以后的文章中进行讨论，而所有这些可能会影响产品未来的发展方向。

回页首

内容回顾

我们在本系列文章中给出的示例和场景全部基于虚构的 Posts-R-Us 公司，该公司各个业务部门拥有不同的现有异构系统和解决方案，希望能提高这些系统的可访问性、连接性和集成。该公司决定使用企业服务总线 (Enterprise Service Bus) 的体系结构模式来实现这些目标，从而开始建立面向服务的体系结构（Service Oriented Architecture，SOA）的初始步骤。

虽然 Posts-R-Us 不是真实的企业，但我们在实际项目中遇到了与此非常相近的很多情况。现有业务功能和业务流程的工作越来越多地由服务层（通过 ESB 实现）加以表示，从而保留在这些解决方案中所做的投资的价值。从最简单的层面而言，ESB 必须提供对一组网络协议的支持，并必须能够在消息通过系统时进行转换。而这正是我们在这些文章中所提到的场景类型，我们已经说明了如何方便地使用 WebSphere ESB 对其加以实现。

第 1 部分介绍了 ESB 的基本功能及新 WebSphere ESB 产品相对于其旧版本（IBM WebSphere Application Server 中的 SIBus 功能）的功能定位。WebSphere ESB 所添加的功能包括更好的工具 (WebSphere Integration Developer) 和新的面向服务的编程模型——服务组件体系结构（Service Component Architecture，SCA）。

第 2 部分介绍了一个基本的但非常强大的场景：在基于 JMS 的服务请求者和基于 JMS 的服务提供者之间插入 ESB，使用消息驱动的 Bean (MDB) 表示。请求者与提供者的这个分离带来了二者之间一定的独立性，从消息格式和网络协议的角度均是如此。也就是说，可以在消息通过 ESB 时对其进行更改，这一点对请求者和提供者都是透明的。而且，尽管在这种情况下请求者和提供者都使用 JMS 作为传输协议，但任意一方都可以在不影响另一方的情况下切换到其他协议。我们在此示例中构建的交互是“单向的”，即请求消息以异步方式发出，没有任何响应。

第 3 部分介绍了 WebSphere ESB 对 Web 服务的支持。WebSphere ESB 中的中介是遵循 SCA 标准的服务组件，因此可以作为 Web 服务进行访问。反过来，中介组件可以通过 Web 服务接口调用外部服务提供者。和第 2 部分中一样，服务请求者和服务提供者使用了相同的协议，即 SOAP/HTTP。ESB 仅仅充当二者之间的中间层，以对二者进行分离。第 3 部分还说明了如何在运行时使用 WebSphere ESB 管理控制台更改服务提供者的端点地址。不过，随着 IBM WebSphere Services Registry and Repository 产品的出现，可以采用更为成熟和可靠的方法进行动态路由。（我们稍后将再次对此进行讨论。）

最后，第 3 部分介绍了 WebSphere ESB 的一个非常重要的功能，其也可用于在运行时更改中介的行为方式：提升的属性。中介流组件中的每个中介原语都具有一组能进行“提升”的属性，以便在运行时通过管理控制台进行更改，从而向中介添加动态行为。这种情况下的交互是同步的，服务请求者发送请求消息，并阻止所有消息，直到收到相应的响应消息为止。

在前面的示例场景中使用 JMS 和 SOAP/HTTP 作为基础协议之后，第 4 部分利用了针对 WebSphere MQ 的本机 WebSphere ESB 支持（在 Version 6.0.2 中引入）。文章中的示例突出说明了 SCA 一个非常强大的功能：能够向现有中介添加其他协议支持，而不会影响组件本身，也不会影响任何已经存在的请求者或提供者。第 4 部分对第 2 部分的 JMS 示例进行了重用，仅添加了一个新的服务提供者。请求消息现在不仅通过 JMS 发送到基于 JMS 的服务提供者，而且通过 WebSphere MQ 转发到远程 MQ 队列管理器控制的队列。服务请求者和中介流组件本身根本不会发生改变，因此不涉及到编程工作。

第 5 部分讨论了在服务请求者和服务提供者支持的协议之间进行切换的场景。此部分没有向场景添加新服务提供者（如第 4 部分中所述），而添加了一个额外的服务请求者。事实上，我们进行了两次此工作：我们重用了之前部分的 JMS 场景和 SOAP/HTTP 场景，从而形成了请求者与提供者之间非常复杂的协议与交互方式。对于异步 JMS 示例，我们添加了（同步）SOAP/HTTP 服务请求者。对于（同步）SOAP/HTTP 示例，我们添加了（异步）基于 MQ 的服务请求者。同样，所有这些都是在不涉及中介流组件本身且不更改任何现有代码的情况下进行的。我们转而采用了 SCA 所提供的导入和导出支持（可以通过 WebSphere Integration Developer 中的组装编辑器开发）。

回页首

下一步

这些文章中涉及的场景主要说明 WebSphere ESB 对不同协议和交换模式的支持。其中讨论了如何设置相当简单的用于处理消息的中介流组件，然后重点讨论如何将各种类型的服务请求者和提供者连接到此组件。同样，这是我们所了解的很多客户开始时的情况：连接使用不同协议的应用程序，并使用 ESB（对其进行分离）替换现有的点对点连接。

现在让我们看看能够如何使用其他 WebSphere ESB 功能扩展 ESB。可以进一步探索的一个明显领域就是中介流组件本身中的处理能力。虽然在我们的示例中我们仅仅对通过 ESB 的消息进行日志记录，但还可以进行其他很多工作。

一个示例 这里的示例仅仅涉及 ESB 可能满足的其他额外需求的皮毛而已。我们旨在抛砖引玉，鼓励您发挥自己的创造力处理更为复杂的问题。

动态查找与路由

ESB 的核心功能之一是支持“虚拟服务”的概念，即 ESB 对请求者而言似乎是实际的服务提供者，但事实上它仅支持虚拟接口，并将消息路由到实际的服务提供者。在我们的示例场景中，这个实际提供者的位置基本上都通过将 SCA 导入与包含特定端点 URL 的 WSDL 关联来硬编码到中介中。

一个更好更可靠的解决方案是将服务提供者的位置存储在外部注册中心中，供 ESB 在运行时进行查找。通过这样，可以作为整体 SOA 治理模型的一部分集中地管理端点信息（当然还可以包含其他内容）。WebSphere Services Registry and Repository 提供了对此功能的支持，这篇 developerWorks 文章详细地说明了如何将 WebSphere ESB 与 WebSphere Services Registry and Repository 进行集成。

基于内容的路由

动态路由的一个特例就是基于内容的路由。其不同之处在于，基于能够在消息本身中找到的条件进行查找。例如，假定 WebSphere ESB 中的某个中介支持多个不同的服务提供者。而且，其接口很通用，可以供不同的服务请求者使用。在这种情况下，中介将对传入消息进行解析，并基于消息的不同内容进行正确的服务提供者查找工作。在 WebSphere ESB 中，很可能会采用自定义中介原语进行此工作，此原语中包含提取消息区别因素，并将其提供给查找原语（确定正确的提供者）的逻辑。关于基于内容的路由的这篇 developerWorks 文章给出了一个完整的示例。（顺便提一下，这篇文章是关于高级 WebSphere ESB 主题的系列文章的第 1 部分，因此请继续关注此系列的后续文章。）

IBM WebSphere Business Services Fabric 产品中包括的动态组装程序组件是此场景的一个更为完善的扩展。动态组装程序是作为独立 SCA 组件实现的，可以基于消息的内容和上下文选择服务端点。上下文信息包含在消息 Header 中，可以包括请求的发送通道或请求者的标识之类的信息。有关描述完整示例场景的示例，请参见参考资料。

消息聚合与分发

在我们介绍的所有场景中，都是一个服务请求者调用一个服务提供者。不过，在有些情况下，可能二者之间存在一对多的关系。例如，请求者可能发送一条请求消息后导致向多个服务提供者发送多条请求消息。必须将这些提供者发回的响应消息聚合为一个合并后的响应消息，然后送回请求者。WebSphere ESB 目前不支持对这种类型的中介的现成支持，因此将需要利用自定义中介原语完成此工作。一种不需要编程的方法是，使用 JMS 作为与多个服务提供者的单向交互的协议。在这种情况下，消息可以由中介发送到 JMS 主题，然后由多个订阅者从此处拾取消息。顺便说一下，在 ESB 上下文中利用发布/订阅功能这一主题可能需要专门写一篇文章加以讨论。

消息转换

我们示例中的消息全部基于 XML。要让特定的请求者消息格式适合特定的提供者消息格式，并不需要进行太多（如果有）的转换。不过，在现实中经常有此需求。转换的最简单例子就是必须将一个 XML 格式转换为另一个 XML 格式的情况。WebSphere ESB 提供了 XSLT 中介原语，会直接对通过中介的消息进行 XSLT 转换。可以使用 WebSphere Integration Developer 或任意其他 XSLT 创作环境中提供的工具构建 XSLT 转换。

可以在 XSLT 中方便地完成一些复杂转换。只要涉及极大的消息、递归和重复结构之类，就需要在转换期间调用 Java™（或其他逻辑）等，并需要更完善的转换引擎。WebSphere Transformation Extender 提供对非常复杂转换的支持，并提供能够从 WebSphere ESB 中介流组件中调用的 API。请密切关注以后的产品版本中此类型集成的改进支持。

数据绑定

讨论消息转换时，还需要首先了解数据如何传递到中介流组件。现在您可能已知道，每条消息都表示为中介流组件中的服务消息对象（Service Message Object，SMO）。这样，原语（自定义或预置）就能够以统一的方式访问消息，而不受用于发送消息的协议的影响。对于通过 SOAP/HTTP 进入中介的消息，此工作将自动进行，因为运行时了解消息的结构，因此能够将其映射到 SMO。对于 JMS 或 WebSphere MQ，并不一定是这样。消息可以包含映射到 BO 的 XML 文档，例如，可以包含序列化 Java 对象，或仅仅包含纯文本。WebSphere ESB 已内置了对常见的数据格式的支持，而且提供了对编写自己的自定义数据绑定的支持。早期 developerWorks 文章系列提供了这方面的一个示例。（参考文章中给出示例是使用 WebSphere ESB Version 6.0.1 构建的。Version 6.0.2 为显示消息格式提供现成支持。）

其他协议和格式通常通过利用适配器提供支持，最好使用 WebSphere Adapter 产品之一。例如，可通过 IBM WebSphere Adapter for Flat Files 从平面文件将数据读取到中介模块中。适配器使用 WebSphere Integration Developer 中的 Enterprise Discovery Service 工具导入并连接到中介模块。这篇 developerWorks 教程向您详细介绍了完整示例。

何时使用中介

上述情况都假定构建 WebSphere ESB 中介是解决问题的正确方法。不过，并非总是如此。最好完全不采用 ESB 的情况的一个例子是：业务逻辑。ESB 重点关注通常独立于所涉及服务尝试解决的业务问题的连接性和集成问题。因此，如果特定逻辑涉及解决方案业务特定的方面，则它通常应该位于其他位置。对于服务接口的实现包含其他服务的编排的情况，此服务应该使用 BPEL 语言作为业务流程实现。基于 BPEL 的业务流程可以在 WebSphere Process Server（其中包含 WebSphere ESB）中执行，由于任何服务编排还包括连接性方面，因此两个产品经常一起运行。使用 BPEL 建模的服务集成通常通过 ESB 进行重定向，以支持这些服务的分离和虚拟化。有关在 ESB 中运行的内容（以及不在其中运行的内容）的全面分析，请参见 developerWorks 上 Greg Flurry 撰写的优秀文章。

回页首

结束语

在最后这篇文章中，我们尽最大努力说明构建企业服务总线的本系列文章并不是一个完整的答案；其中仅仅提供对复杂而有意义的技术领域的基本介绍。在本系列中，我们通过选择一系列常用协议和消息格式，讨论了服务请求者和服务提供者之间的基本连接性。所给出的示例都考虑了可重复利用的方便性，应该能够帮助您熟悉 WebSphere ESB 产品及其工具。