我们在第 4 部分中已经说过，现在我们将了解企业服务总线 (ESB) 如何帮助在服务请求程序和服务提供程序的不同协议之间建立中介的场景。本文内容以本系列文章的以前文章中提供的示例为基础，主要添加一些支持各种协议的新“虚拟”服务，它们都是围绕使用企业服务总线为任何请求程序和提供程序提供连接这一概念而添加的。

引言

企业服务总线 (ESB) 支持许多传输协议和消息协议之间的交互。就这个意义而言，IBM® WebSphere® ESB 也是如此。在本系列文章的以前文章中，我们介绍并举出了在 WebSphere MQ、JMS 和 SOAP over HTTP 之间进行消息交换的一些示例。这里，我们将做进一步的阐述，并介绍 WebSphere ESB 如何支持企业服务总线模式的关键原则，即“虚拟”服务。

提供虚拟服务意味着对服务请求程序隐藏服务提供程序的实际位置、协议甚至它们的精确接口。本文通过一些示例说明，如何使用与服务提供程序预期不同的协议向请求程序提供服务。事实上，我们将通过两个协议同时提供相同的服务，从而将其公开给各种使用者。您将了解到，在使用 WebSphere ESB 时，这实际上并不需要额外的工作，原因是它具有基础服务组件体系结构 (SCA)。

本文将遵循以前文件的布局模式，先从业务场景开始，然后介绍解决方案的体系结构，最后阐述如何让它们全部在 WebSphere ESB 中运行（包括测试）。

增强的场景

我们将重新使用虚构的 Posts-R-Us 公司的两个以前场景。

在第一个场景中，我们描述了如何在每次接收包时将消息发送到后端应用程序，以便相应地更新订单状态。在第 2 部分中，我们介绍了如何通过 JMS 队列将消息发送到 ESB，然后转发（仍使用 JMS）到后端应用程序，后者通过消息驱动 Bean 接收消息。我们然后在第 4 部分中增强了此设置，添加了一个新的出站 WebSphere MQ 通道。现在，我们将通过 Web 服务使用 SOAP/HTTP 添加客户端访问权限，从而进一步增强此场景，如图 1 所示。

通过此增强，可以从两种不同类型的客户端发送指示客户收到包的事件：一种客户端使用异步协议，另一种客户端使用同步协议。后端应用程序完全不受此影响，因为 ESB 可以为客户端提供虚拟服务接口。

在第 3 部分中讨论了第二种场景，该场景提供了一种服务，通过该服务客户和雇员能够跟踪各个包的状态。通过 SOAP/HTTP 将该服务实现为常规 Web 服务。示例中的请求程序还使用了 SOAP/HTTP 作为协议（事实上是利用了 IBM WebSphere Integration Developer 中的 Web Services Explorer 工具运行场景的）。这里，将通过一对 WebSphere MQ 队列向此服务添加访问权限，通过此服务可以从应用程序方便地与 WebSphere MQ 通信，而不需要对 Web 服务提供任何支持。

另外，现有服务不受此附加使用者的影响；新协议的详细信息完全由企业服务总线处理。

场景 1：将 SOAP/HTTP 使用者添加到 JMS 服务

1. 首先将 PackageReceivedPart4.ear 文件导入到 WebSphere Integration Developer。下载部分提供的 part5downloads.zip 文件中包含此 EAR 文件（和其他所需文件）。EAR 文件还可以在第 4 部分中的下载资料中找到；您不要对应用程序进行任何更改。请记住，这是一个带有消息驱动 Bean 的应用程序，它通过 JMS 队列接收消息，并将其内容打印到屏幕。创建第 2 部分中的示例后，将带有 MQ 绑定的另一个导入添加到第 4 部分中的示例中。不要把结果项目添加到运行时环境中。
2. 导入包括要使用的中介模块的项目互换文件。其名称为 PackageReceivedModuleWithMQ.zip，另外，您可以从本文的下载部分检索它，也可以在第 4 部分中找到它。
3. 打开 Business Integration 透视图，并将模块加载到 Assembly Editor，如图 3 所示。
   图 3. 未更改的中介模块组装图
   

   要使中介通过 SOAP over HTTP 访问 Web 服务客户端，只需添加另一个导出，并向其提供适当的绑定。SCA 组装模型的好处是：不必对实际中介流组件进行任何更改；您可以将其他导出与之“连接”。

4. 在 Assembly Editor 中，从面板中拖动 Export，将其放在画布上，并重命名为 SOAPClientExport，然后将其连接到中介流组件。此操作还将适当的接口添加到导出。右键单击导出，并选择 Generate Binding...=> Web Service Binding，如图 4 所示。
   图 4. 生成 Web 服务绑定
   
5. 在下一个对话框中，选择 soap/http 作为传输。
6. 保存更改。工作完成！
7. 在部署和测试更新模块之前，您需要将激活规范添加到服务器，因为接收消息驱动 Bean 要使用该规范来连接适当的 JMS 队列。所有这些在第 2 部分中都进行了详细描述（按照本系列文章中的步骤操作，还可以配置它），但下面给出了一个简要的总结：
   1. 启动 WebSphere ESB 测试服务器。
   2. 启动后，通过右键单击服务器，并选择 Run administrative console 运行服务器的管理控制台。
   3. 在控制台中，导航到 Resources => JMS Providers => Default messaging。
   4. 选择 JMS activation specification。
   5. 使用以下这些值创建新的激活规范：
      • 名称： PackageReceivedActivationSpec
      • JNDI 名称： eis/PackageReceivedActivationSpec
      • 目的地 JNDI 名称： PackageReceivedModule/MDBImport_SEND_D
      • 总线名称： SCA.APPLICATION.esbCell.bus
   6. 保存更改，并重新启动服务器。
8. 要运行 JMS 测试客户端，您必须创建另外一些构件；这里我们不再创建，因为我们将重点讨论 Web 服务导出通道。有关如何部署并运行 JMS 测试客户端的详细信息，请参见第 2 部分；在更新的场景中，没有对此信息进行任何更改。另外，正如前面提到的，我们使用的模块包括 WebSphere MQ 导入。这将导致接收的消息被转发到名为PackageReceivedQueue 的 MQ 队列。我们在第 4 部分中创建了导入和相关的队列。
9. 再次启动服务器后，您可以将 PackageReceivedModuleApp 和 PackageReceivedPart4 项目添加到该服务器。请确保先选择模块，因为该模块的部署将生成由消息驱动 Bean 使用的队列和其他定义。

   在 J2EE 透视图中，只需右键单击 SOAPClientExport_PackageReceivedIFHttp_Service.wsdl 并选择 Web Services => Test with Web Services Explorer 就可以测试新的 Web 服务导出。运行测试后，所得结果应与图 5 所示类似。
   图 5. 测试场景 1
   

场景 2：将 WebSphere MQ 使用者添加到 SOAP/HTTP Web 服务

让我们切换到第二个场景，此场景介绍服务的请求-响应类型。服务提供程序通过 SOAP over HTTP 提供此服务，中介模块（在第 3 部分中创建）还通过此协议公开它。您现在可以将 WebSphere MQ 的访问权限添加此服务，实质上是向异步协议打开此服务，尽管服务操作本身是以同步方式实现的。图 2 显示了解决方案的更新体系结构情况。

构建此解决方案：

1. 首先导入后端服务提供程序应用程序，您可以在下载的 PackageStatusNewEAR.ear 文件中找到它。此应用程序没有什么特殊之处，它只是输出收到的消息，并返回缺省响应消息。稍后，您会将此应用程序部署在测试服务器上。
2. 导入与该服务关联的中介模块，您可以在 PackageStatusModulePart5.zip 项目互换文件中找到此模块。（和前面一样，您也可以在下载的 PackageStatusModulePart5Completed.zip 文件中找到完整的解决方案。）
3. 导入 PackageStatusModule 模块后，请在 Business Integration 透视图中的 Assembly Editor 中打开它。组装应类似于图 6。
   
   图 6. PackageStatusModule 组装
   
   　
4. 为 WebSphere MQ 访问添加其他导出之前，请看一下模块服务接口中的详细信息，更确切地说，看一下它包含的模式。通过右键单击文件，并选择 Open With => WSDL Editor 菜单选项，使用 WSDL 编辑器（而不是缺省的接口编辑器）打开 PackageTrackingService 接口（图 7）。
   图 7. 使用 WSDL 编辑器打开服务接口
   
5. 双击 Types 部分中的 http://service.postrus 名称空间（假定您选择了编辑器窗口中的 Graph 选项卡）。这时将显示为此接口定义的元素和类型（图 8）。
   图 8. 服务接口中的全局元素
   

   其中的两个全局元素（即 PackageIdentifier 和 PackageStatus）在普通 Web 服务场景中通常不是必需的。通过查看源，这两个元素是按以下方式定义的：

   <element name="PackageIdentifier" type="impl:PackageIdentifier"/> <element name="PackageStatus" type="impl:PackageStatus"/>

   对于 WebSphere MQ 绑定，您需要使用这两个全局元素（按它们的“打包”类型命名），而不是在 SOAP/HTTP 场景中使用的其他两个全局元素。

6. 现在可以添加新的导出。在 Assembly Editor 中打开模块组装，向画布添加新的导出。将其重新命名为 PackageStatusExportMQ，并将其连接到中介模块，该模块还会将适当的接口添加到导出。
7. 右键单击新的导出，并选择 Generate Binding...=> Message Binding...=> MQ Binding。
   图 9. 将 MQ 绑定添加到导出
   
   　
8. 在结果对话框中，您需要指定要用于交换的 WebSphere MQ 参数。此处的值将依赖于您的本地 MQ 安装，但是基本上与以下值类似（此处没有列出的字段可以保留其缺省值）：
   • 请求队列管理器：[这是缺省队列管理器]
   • 接收目标队列： PackageStatusRequestQueue
   • 发送目标队列： PackageStatusResponseQueue
   • 主机名称： localhost
   • 请求序列化类型：Serialized as XML
   • 响应序列化类型：Serialized as XML
   
   图 10. 定义 MQ 绑定属性
   

   稍后，在 Properties 视图中还可以更改所有这些值。单击 OK 并保存更改。

9. 在本示例中，不会对中介流组件实现进行任何更改，但是可以随时在 Mediation Flow Editor 中打开组件，查看中介的实际执行情况。注意，它同时记录请求消息和响应消息。此外，响应流包含输出响应消息的自定义中介。此自定义中介中的代码与以下类似：

   com.ibm.websphere.bo.BOXMLSerializer serializer = (com.ibm.websphere.bo.BOXMLSerializer)com.ibm.websphere.sca.ServiceManager. INSTANCE.locateService("com/ibm/websphere/bo/BOXMLSerializer"); java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream(); try { serializer.writeDataObject(input1, "http://service.postrus", "getPackageStatus", baos); } catch (java.io.IOException x) {} System.out.println(new String(baos.toByteArray())); return input1;

   这是非常通用的代码，如果分别更改名称空间和根消息值，则还可以在其他类型的中介中重新使用。

10. 在部署此更新模块之前，需要创建我们在图 9 中指定的队列，请打开 WebSphere MQ Explorer，在已定义的队列管理器下创建两个新的本地队列。将其命名为 PackageStatusRequestQueue 和 PackageStatusReponseQueue。这些队列没有任何特殊的要求，所以您可以使用它们的所有缺省值。
11. 切换回 WebSphere Integration Developer，但保持 MQ Explorer 窗口处于打开状态，因为稍后需要用它进行测试。现在可以将模块和服务提供程序部署到测试服务器。启动服务器，然后在启动后添加 PackageStatusServiceNewEAR 和 PackageStatusModuleApp 项目。

    （这些说明假定您使用的测试服务器运行的端口为 9081，它是 WebSphere ESB 测试服务器的缺省端口。如果使用其他端口，则必须更新 PackageStatusModule 项目和 PackagesStatusServiceImport 属性中的模块和实际服务的端口定义。）

12. 现在可以将测试 MQ 消息发送到中介，了解如何记录该消息并通过 SOAP/HTTP 将其转发到服务提供程序，并了解如何将响应路由回响应 MQ 队列。使用 MQ Explorer 发送测试消息。右键单击 PackageStatusRequestQueue，并选择 Put Test Message... 选项。
    
    图 11. 将测试消息放入 MQ 请求队列
    

    您要发送到中介的消息与以下所示类似：

    <p:PackageIdentifier xmlns:p="http://service.postrus"> <trackingNumber>123</trackingNumber> </p:PackageIdentifier>

    注意，此消息的根元素相当于我们先前在服务接口文件中看到的全局元素定义。
    
    图 12. 测试消息
    

    如果测试成功运行，则输出会在服务器控制台中显示，响应消息会在 PackageStatusResponseQueue 中显示。您可以再次使用 MQ Explorer 工具在此处查看它。
    图 13. 浏览响应消息
    
    
    图 14. 响应消息
    

    图 14 显示了响应消息的条目样式。预期的响应消息类似于：

    <?xml version="1.0" encoding="UTF-8"?> <service:PackageStatus xmlns:service="http://service.postrus"> <actualDeliveryDate>2007-04-11T22:02:16.578Z</actualDeliveryDate> <location>unknown</location> <projectedDeliveryDate>2007-07-30T05:00:00.0Z</projectedDeliveryDate> <status>lost</status> </service:PackageStatus>

    还需要注意的是，响应消息的根元素就是按照包括的复杂类型命名的全局元素。

要将此场景和消息输出与 Web 服务导出进行比较，只需使用 WebSphere Integration Developer 中的 Web Services Explorer 工具将测试 SOAP 消息发送到中介。尽管请求和响应在各自的导出中表现的消息格式不同，但是在找到中介流组件时它们是一致的。可以用同一方法添加具有不同绑定的其他导出。

结束语

本文介绍了如何使用 WebSphere ESB 及其基础服务组件体系结构中的导入/导出连接方法非常简单地启动其他协议，以便服务提供程序和使用者使用。您可以向仅支持 SOAP over HTTP 的使用者公开现有服务提供程序，此程序是为与 JMS 一起使用而开发的。类似地，您可以向基于 SOAP/HTTP 的服务提供程序添加基于 WebSphere MQ 使用者的支持。最大的优点在于，这些更改都不需要服务逻辑或中介流逻辑的任何更新！所有消息可以与 WebSphere ESB 中的 Service Message Object 格式进行相互转换，这样能够操作和处理这些消息，无论接收或发送消息所使用的协议如何。

与以前系列文章中有关使用 WebSphere Application Server 的 Enterprise Service Bus 实现一样，这是 WebSphere ESB 中基本 ESB 功能的描述总结。还有许多更详细的信息和更重要的场景需要介绍，但是我们将这些内容留在以后的文章中讲述。在下一部分（也是最后一部分）中，我们将向您提供所介绍的摘要信息。并展望对未来的预期、两篇文章的内容和产品今后如何发展。

下载

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
• IBM 企业服务总线介绍
• WebSphere Enterprise Service Bus 产品页
• WebSphere Enterprise Service Bus 与 WebSphere Integration Developer 入门
• 为 WebSphere Enterprise Service Bus 开发自定义中介
• 使用 JMS 和 WebSphere ESB 构建强大而可靠的 SOA
• WebSphere Enterprise Service Bus V6.0.2
• 教程：使用 Java Message Service (JMS) 客户机调用 Web 服务
• 红皮书：Enabling SOA Using WebSphere Messaging