使用JMS和ESB构建强大而可靠的SOA之一

　　面向服务的体系结构 (SOA) 永远不能建立在真空中。在任何实际的环境中，都必须考虑现有的 IT 环境，功能(和数据)的提供并不能简单地通过提供一组新服务来实现。因此，构建 SOA 的一个关键方面就是将现有应用程序分解为更小的块(即“服务”)，这些块通过标准协议进行通信，并具有定义良好的接口。这样做的优势在于，此类环境更为灵 活，整个系统的各个部分之间并不存在紧密耦合。

　　松散耦合且具有平台独立性的服务的概念通过使用企业服务总线(Enterprise Service Bus，ESB)得到了进一步发展。其中，ESB 充当使用不同数据和消息格式、网络协议和编程语言的服务之间的“粘合剂”。ESB 充当服务使用者和服务提供者之间的中间层，允许部署中介，以执行各种操作，如向交互应用服务质量或执行所需的数据转换。

　　在本系列的文章中， 我们将了解一个 ESB 充当此类中间层的具体例子。我们将利用 IBM WebSphere Enterprise Service Bus (WebSphere ESB) V6.0.1 产品来链接服务使用者和服务提供者，同时使用 JMS 作为消息传递机制。在第一篇文章中，我们将简单了解一下 WebSphere ESB 产品及其工具环境，即 WebSphere Integration Developer V6.0.1。第 2 部分将描述实际的 ESB 场景，并说明如何构建服务使用者和服务提供者，而在第 3 部分，我们将演示如何构建运行于 WebSphere ESB 中的使用者和提供者之间的中介。您将学习如何部署和运行解决方案，我们将提供进行此操作所需的所有代码构件。

　　企业服务总线和 Java Message Service

　　SOA 由彼此进行通信的服务使用者和服务提供者组成。它们通常通过企业服务总线进行通信。每个服务具有服务定义，在其中描述如何从使用者接受消息和如何向其使用 者返回消息(“单向”服务时例外)以及其他一些事项。因此，构建 ESB 与消息传递有很大关系。一直以来，以稳健、快速而可靠的方式发送和接收消息是 IT 系统的一项关键要求，ESB 的到来并未改变这一点;它恰恰给解决方案带来了额外的要求——例如，支持描述消息格式的标准、服务间的事务交换等等。

　　同时，基于 Java J2EE 平台的系统通常会利用 Java Message Service (JMS) API 来满足其消息传递需求。简单说来，JMS 描述如何将消息从一个应用程序发送到另一个应用程序，对服务的事务质量进行了潜在的利用。

　　充 分考虑到很多应用程序已经在使用 JMS 了，而 SOA 内的服务又需要一种进行消息传递的方式，这样就能很好地理解 JMS 在 ESB 上下文中所扮演的角色。每个 ESB 都必须能够通过 JMS 从服务使用者接收消息，并将其转发到相应的服务提供者(通过 JMS 或其他协议，如 HTTP)，反之亦然。而且，JMS 还定义了可发送的若干不同类型的消息。例如，Text 消息包含消息的字符串表示形式;Object 消息包含序列化的 Java 对象;Map 消息包含键/值对的映射，等等。Web 服务通常使用 SOAP 作为其消息格式，但很多应用程序都使用纯 XML。因此，ESB 必须支持各种网络和消息协议。图 1 显示了服务使用者和服务提供者可能支持的一系列协议组合。请注意，ESB 充当了这两者间的中间层，允许在不受协议限制的前提下连接任何使用者和提供者。

　　图 1. SOA 中的消息和网络协议示例

　　如果设置 WebSphere ESB，以支持不同的组合，这正是我们将在本系列中讨论的内容。不过，首先让我们看一下该产品本身以及其主要组件。

　　WebSphere ESB V6.0.1

　　WebSphere ESB 产品是 IBM SOA Foundation 的一部分。尽管其版本号可能会让人觉得此产品已经存在很长时间，但该产品却是在 2005 年末首次发布，与其他已经存在的 WebSphere 产品系列成员共享很多组件。例如，它使用基于 J2EE 的 IBM WebSphere Application Server 作为其核心运行时。WebSphere Application Server 提供了一个 JMS 实现，该实现由 WebSphere ESB 进行了重用。它还使用了服务组件体系结构(Service Component Architecture，SCA)作为其基础编程模型，并与 WebSphere Process Server 共享 SCA 运行时。

　　图 2 显示了 WebSphere ESB 及其基本组件的概况。

　　图 2. WebSphere ESB 概况

　　WebSphere ESB 支持通过 JMS 的基本消息传递，可以通过 WebSphere Application Server 中的 MQLink 与 WebSphere MQ 进行通信。使用 SOAP over HTTP 和 SOAP over JMS 的 Web 服务是插入到 ESB 中的，支持很多 Web 服务标准和通过应用服务器提供的 UDDI 注册表。WebSphere ESB 不仅可以从标准 J2EE 客户端使用，也提供 C/C++ 和 .Net® 的客户端支持。而且，它还通过 WebSphere Adapter 提供了到各种遗留环境的连接。

　　WebSphere ESB 和服务组件体系结构

　　我 们在前面提到 WebSphere ESB 所使用的编程模型基于 SCA。SCA 描述了一个完整的服务编程模型，涉及到大量可采用相同的方式描述和访问的组件(即服务)。此类组件可以为 BPEL 流程、业务规则或传统 Java 组件等等。WebSphere ESB 向 SCA 模型引入了一个新的组件类型，即中介流组件。从 SCA 的角度而言，中介流组件与任何其他服务组件没有任何区别，因为中介组件具有以下特征：

• 存在于模块中(更准确地说，存在于中介模块中，它采用这种方式部署到服务器运行时中)。
• 具有接口，采用 Java 或 WSDL 描述。
• 通过导出向客户端公开，导出可以有多个不同协议的绑定(我们将在以后对此进行讨论)。
• 具有对其他服务的依赖关系(通过导入，导入也具有描述协议详细信息的绑定)。

　　就某种程度而言，中介流编程模型是独一无二的;它支持访问和操作关于正在处理的服务消息的绑定特定信息(通常为 Header 类型的信息)。有关 SCA 及其编程模型的详细信息以及如何通过其构建和部署组件，请参阅 Building SOA solutions with the Service Component Architecture 系列文章。(在本系列的剩下部分中，我们将假定您已具有 SCA 的基本知识，因此我们将不会对已在其他地方得到详细阐述的内容进行复述。)

　　中介流组件提供了一种服务组件的新实现，即中介流的实现。中介流通常使用可视流编辑器进行构建，用于通过一系列中介原语描述请求和响应消息流。这些原语可以读取和更改消息，或将其路由(“筛选”)到不同的目标位置。虽然您可以构建自己的自定义中介原语，该产品仍然提供了一系列用于以下用途的预定义原语：

• XSLT 转换
• 消息日志记录
• 消息筛选
• 数据库访问。

　　图 3 显示了一个使用若干中介原语实现响应流的中介流组件实现。

　　图 3. 中介流示例

　　顺便说明一下，我们将在第 2 部分详细讲解创建此类流所需的各个步骤。