使用 WebSphere ESB 构建企业服务总线第 5 部分.docx

使用 WebSphere ESB 构建企业服务总线第 5 部分.docx

《使用 WebSphere ESB 构建企业服务总线第 5 部分.docx》由会员分享，可在线阅读，更多相关《使用 WebSphere ESB 构建企业服务总线第 5 部分.docx（17页珍藏版）》请在冰豆网上搜索。

使用WebSphereESB构建企业服务总线第5部分

引言

企业服务总线（ESB）支持许多传输协议和消息协议之间的交互。

就这个意义而言，IBM®WebSphere®ESB也是如此。

在本系列文章的以前文章中，我们介绍并举出了在WebSphereMQ、JMS和SOAPoverHTTP之间进行消息交换的一些示例。

这里，我们将做进一步的阐述，并介绍WebSphereESB如何支持企业服务总线模式的关键原则，即“虚拟”服务。

提供虚拟服务意味着对服务请求程序隐藏服务提供程序的实际位置、协议甚至它们的精确接口。

本文通过一些示例说明，如何使用与服务提供程序预期不同的协议向请求程序提供服务。

事实上，我们将通过两个协议同时提供相同的服务，从而将其公开给各种使用者。

您将了解到，在使用WebSphereESB时，这实际上并不需要额外的工作，原因是它具有基础服务组件体系结构（SCA）。

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

回页首

增强的场景

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

在第一个场景中，我们描述了如何在每次接收包时将消息发送到后端应用程序，以便相应地更新订单状态。

在第2部分中，我们介绍了如何通过JMS队列将消息发送到ESB，然后转发（仍使用JMS）到后端应用程序，后者通过消息驱动Bean接收消息。

我们然后在第4部分中增强了此设置，添加了一个新的出站WebSphereMQ通道。

现在，我们将通过Web服务使用SOAP/HTTP添加客户端访问权限，从而进一步增强此场景，如图1所示。

图1.添加新通道以便发送“packagereceived”事件（场景1）

通过此增强，可以从两种不同类型的客户端发送指示客户收到包的事件：

一种客户端使用异步协议，另一种客户端使用同步协议。

后端应用程序完全不受此影响，因为ESB可以为客户端提供虚拟服务接口。

在第3部分中讨论了第二种场景，该场景提供了一种服务，通过该服务客户和雇员能够跟踪各个包的状态。

通过SOAP/HTTP将该服务实现为常规Web服务。

示例中的请求程序还使用了SOAP/HTTP作为协议（事实上是利用了IBMWebSphereIntegrationDeveloper中的WebServicesExplorer工具运行场景的）。

这里，将通过一对WebSphereMQ队列向此服务添加访问权限，通过此服务可以从应用程序方便地与WebSphereMQ通信，而不需要对Web服务提供任何支持。

图2.添加新通道以便接收包状态（场景2）

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

回页首

场景1：

将SOAP/HTTP使用者添加到JMS服务

如果不希望按照此处介绍的步骤操作，可以在本文提供的下载文件中获得完整的解决方案（位于名为PackageReceivedModulePart5Completed.zip的ProjectInterchange文件中）。

1.首先将PackageReceivedPart4.ear文件导入到WebSphereIntegrationDeveloper。

下载部分提供的part5downloads.zip文件中包含此EAR文件（和其他所需文件）。

EAR文件还可以在第4部分中的下载资料中找到；您不要对应用程序进行任何更改。

请记住，这是一个带有消息驱动Bean的应用程序，它通过JMS队列接收消息，并将其内容打印到屏幕。

创建第2部分中的示例后，将带有MQ绑定的另一个导入添加到第4部分中的示例中。

不要把结果项目添加到运行时环境中。

2.导入包括要使用的中介模块的项目互换文件。

其名称为PackageReceivedModuleWithMQ.zip，另外，您可以从本文的下载部分检索它，也可以在第4部分中找到它。

3.打开BusinessIntegration透视图，并将模块加载到AssemblyEditor，如图3所示。

图3.未更改的中介模块组装图

要使中介通过SOAPoverHTTP访问Web服务客户端，只需添加另一个导出，并向其提供适当的绑定。

SCA组装模型的好处是：

不必对实际中介流组件进行任何更改；您可以将其他导出与之“连接”。

4.在AssemblyEditor中，从面板中拖动Export，将其放在画布上，并重命名为SOAPClientExport，然后将其连接到中介流组件。

此操作还将适当的接口添加到导出。

右键单击导出，并选择GenerateBinding...=>WebServiceBinding，如图4所示。

图4.生成Web服务绑定

5.在下一个对话框中，选择soap/http作为传输。

6.保存更改。

工作完成！

7.在部署和测试更新模块之前，您需要将激活规范添加到服务器，因为接收消息驱动Bean要使用该规范来连接适当的JMS队列。

所有这些在第2部分中都进行了详细描述（按照本系列文章中的步骤操作，还可以配置它），但下面给出了一个简要的总结：

a.启动WebSphereESB测试服务器。

b.启动后，通过右键单击服务器，并选择Runadministrativeconsole运行服务器的管理控制台。

c.在控制台中，导航到Resources=>JMSProviders=>Defaultmessaging。

d.选择JMSactivationspecification。

e.使用以下这些值创建新的激活规范：

▪名称：

PackageReceivedActivationSpec

▪JNDI名称：

eis/PackageReceivedActivationSpec

▪目的地JNDI名称：

PackageReceivedModule/MDBImport_SEND_D

▪总线名称：

SCA.APPLICATION.esbCell.bus

f.保存更改，并重新启动服务器。

8.要运行JMS测试客户端，您必须创建另外一些构件；这里我们不再创建，因为我们将重点讨论Web服务导出通道。

有关如何部署并运行JMS测试客户端的详细信息，请参见第2部分；在更新的场景中，没有对此信息进行任何更改。

另外，正如前面提到的，我们使用的模块包括WebSphereMQ导入。

这将导致接收的消息被转发到名为PackageReceivedQueue的MQ队列。

我们在第4部分中创建了导入和相关的队列。

9.再次启动服务器后，您可以将PackageReceivedModuleApp和PackageReceivedPart4项目添加到该服务器。

请确保先选择模块，因为该模块的部署将生成由消息驱动Bean使用的队列和其他定义。

在J2EE透视图中，只需右键单击SOAPClientExport_PackageReceivedIFHttp_Service.wsdl并选择WebServices=>TestwithWebServicesExplorer就可以测试新的Web服务导出。

运行测试后，所得结果应与图5所示类似。

图5.测试场景1

回页首

场景2：

将WebSphereMQ使用者添加到SOAP/HTTPWeb服务

让我们切换到第二个场景，此场景介绍服务的请求-响应类型。

服务提供程序通过SOAPoverHTTP提供此服务，中介模块（在第3部分中创建）还通过此协议公开它。

您现在可以将WebSphereMQ的访问权限添加此服务，实质上是向异步协议打开此服务，尽管服务操作本身是以同步方式实现的。

图2显示了解决方案的更新体系结构情况。

构建此解决方案：

1.首先导入后端服务提供程序应用程序，您可以在下载的PackageStatusNewEAR.ear文件中找到它。

此应用程序没有什么特殊之处，它只是输出收到的消息，并返回缺省响应消息。

稍后，您会将此应用程序部署在测试服务器上。

2.导入与该服务关联的中介模块，您可以在PackageStatusModulePart5.zip项目互换文件中找到此模块。

（和前面一样，您也可以在下载的PackageStatusModulePart5Completed.zip文件中找到完整的解决方案。

）

3.导入PackageStatusModule模块后，请在BusinessIntegration透视图中的AssemblyEditor中打开它。

组装应类似于图6。

图6.PackageStatusModule组装

4.为WebSphereMQ访问添加其他导出之前，请看一下模块服务接口中的详细信息，更确切地说，看一下它包含的模式。

通过右键单击文件，并选择OpenWith=>WSDLEditor菜单选项，使用WSDL编辑器（而不是缺省的接口编辑器）打开PackageTrackingService接口（图7）。

图7.使用WSDL编辑器打开服务接口

5.双击Types部分中的http:

//service.postrus名称空间（假定您选择了编辑器窗口中的Graph选项卡）。

这时将显示为此接口定义的元素和类型（图8）。

图8.服务接口中的全局元素

其中的两个全局元素（即PackageIdentifier和PackageStatus）在普通Web服务场景中通常不是必需的。

通过查看源，这两个元素是按以下方式定义的：

PackageIdentifier"/>

PackageStatus"/>

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

6.现在可以添加新的导出。

在AssemblyEditor中打开模块组装，向画布添加新的导出。

将其重新命名为PackageStatusExportMQ，并将其连接到中介模块，该模块还会将适当的接口添加到导出。

7.右键单击新的导出，并选择GenerateBinding...=>MessageBinding...=>MQBinding。

图9.将MQ绑定添加到导出

8.在结果对话框中，您需要指定要用于交换的WebSphereMQ参数。

此处的值将依赖于您的本地MQ安装，但是基本上与以下值类似（此处没有列出的字段可以保留其缺省值）：

o请求队列管理器：

[这是缺省队列管理器]

o接收目标队列：

PackageStatusRequestQueue

o发送目标队列：

PackageStatusResponseQueue

o主机名称：

localhost

o请求序列化类型：

SerializedasXML

o响应序列化类型：

SerializedasXML

图10.定义MQ绑定属性

稍后，在Properties视图中还可以更改所有这些值。

单击OK并保存更改。

9.在本示例中，不会对中介流组件实现进行任何更改，但是可以随时在MediationFlowEditor中打开组件，查看中介的实际执行情况。

注意，它同时记录请求消息和响应消息。

此外，响应流包含输出响应消息的自定义中介。

此自定义中介中的代码与以下类似：

com.ibm.websphere.bo.BOXMLSerializerserializer=

（com.ibm.websphere.bo.BOXMLSerializer）com.ibm.websphere.sca.ServiceManager.

INSTANCE.locateService（"com/ibm/websphere/bo/BOXMLSerializer"）;

java.io.ByteArrayOutputStreambaos=newjava.io.ByteArrayOutputStream（）;

try{

serializer.writeDataObject（input1,"http:

//service.postrus",

"getPackageStatus",baos）;

}catch（java.io.IOExceptionx）{}

System.out.println（newString（baos.toByteArray（）））;

returninput1;

10.

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

12.在部署此更新模块之前，需要创建我们在图9中指定的队列，请打开WebSphereMQExplorer，在已定义的队列管理器下创建两个新的本地队列。

将其命名为PackageStatusRequestQueue和PackageStatusReponseQueue。

这些队列没有任何特殊的要求，所以您可以使用它们的所有缺省值。

13.切换回WebSphereIntegrationDeveloper，但保持MQExplorer窗口处于打开状态，因为稍后需要用它进行测试。

现在可以将模块和服务提供程序部署到测试服务器。

启动服务器，然后在启动后添加PackageStatusServiceNewEAR和PackageStatusModuleApp项目。

（这些说明假定您使用的测试服务器运行的端口为9081，它是WebSphereESB测试服务器的缺省端口。

如果使用其他端口，则必须更新PackageStatusModule项目和PackagesStatusServiceImport属性中的模块和实际服务的端口定义。

）

14.现在可以将测试MQ消息发送到中介，了解如何记录该消息并通过SOAP/HTTP将其转发到服务提供程序，并了解如何将响应路由回响应MQ队列。

使用MQExplorer发送测试消息。

右键单击PackageStatusRequestQueue，并选择PutTestMessage...选项。

图11.将测试消息放入MQ请求队列

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

PackageIdentifierxmlns:

p="http:

//service.postrus">

123

PackageIdentifier>

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

图12.测试消息

如果测试成功运行，则输出会在服务器控制台中显示，响应消息会在PackageStatusResponseQueue中显示。

您可以再次使用MQExplorer工具在此处查看它。

图13.浏览响应消息

图14.响应消息

图14显示了响应消息的条目样式。

预期的响应消息类似于：

xmlversion="1.0"encoding="UTF-8"?

>

PackageStatusxmlns:

service="http:

//service.postrus">

2007-04-11T22:

02:

16.578Z

unknown

2007-07-30T05:

00:

00.0Z

lost

PackageStatus>

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

要将此场景和消息输出与Web服务导出进行比较，只需使用WebSphereIntegrationDeveloper中的WebServicesExplorer工具将测试SOAP消息发送到中介。

尽管请求和响应在各自的导出中表现的消息格式不同，但是在找到中介流组件时它们是一致的。

可以用同一方法添加具有不同绑定的其他导出。

回页首

结束语

本文介绍了如何使用WebSphereESB及其基础服务组件体系结构中的导入/导出连接方法非常简单地启动其他协议，以便服务提供程序和使用者使用。

您可以向仅支持SOAPoverHTTP的使用者公开现有服务提供程序，此程序是为与JMS一起使用而开发的。

类似地，您可以向基于SOAP/HTTP的服务提供程序添加基于WebSphereMQ使用者的支持。

最大的优点在于，这些更改都不需要服务逻辑或中介流逻辑的任何更新！

所有消息可以与WebSphereESB中的ServiceMessageObject格式进行相互转换，这样能够操作和处理这些消息，无论接收或发送消息所使用的协议如何。

与以前系列文章中有关使用WebSphereApplicationServer的EnterpriseServiceBus实现一样，这是WebSphereESB中基本ESB功能的描述总结。

还有许多更详细的信息和更重要的场景需要介绍，但是我们将这些内容留在以后的文章中讲述。

在下一部分（也是最后一部分）中，我们将向您提供所介绍的摘要信息。

并展望对未来的预期、两篇文章的内容和产品今后如何发展。