WebSphere Service Registry and Repository 的运行时支持——WebSphere Message Broker V6 Client 介绍

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

Xiao Qiang Hou (houxq@cn.ibm.com), 软件工程师, IBM 中国软件开发实验室 SOA设计中心
王 越, 软件工程师, IBM 中国软件开发实验室 SOA设计中心

2007 年 4 月 26 日

本文介绍了WebSphere Message Broker V6 Client for WebSphere Service Registry and Repository的组成结构与工作原理，并结合案例场景分析了WebSphere Message Broker V6 Client for WebSphere Service Registry and Repository的使用方法。

1. WebSphere Service Registry and Repository简介

Service-oriented architecture (SOA)为实现重用、灵活、松耦合、服务管理的企业解决方案提供了保证，其中很重要的一种实现方法是把服务的描述信息和服务的实现分离，例如Web服务描述语言(Web Service Definition Language)，XML Schema，Policy都属于这种描述性的元数据。在整个SOA开发应用的生命周期内，企业的分析员、架构师以及开发人员都要使用这些服务元数据，对于一个应用了SOA的企业来讲，有一个保存这些服务元数据的仓库尤为重要。

WebSphere Service Registry and Repository（以下简称为WSRR）是一个服务交互端点描述的元数据仓库，它建立了一个查找和管理服务元数据的中心点。它可用于保存Web服务、XML模式、Policy和服务组件模型（Service Component Architecture）等的元数据。当服务元数据注册在WSRR中后，用户就可对服务元数据进行可视化的操作、版本的管理及使用监控。图1为WSRR在整个SOA生命周期中的位置。

WSRR提供以下几个大的功能：

• 注册（registry）：WSRR支持服务的元数据、能力、必备条件、语义的发布，通过这些，服务消费者可以查找服务和分析它们之间的关系。
• 储存（repository）：WSRR提供存储、管理服务元数据的功能。
• 管理（governance）：WSRR支持服务管理的定义，即对服务元数据进行访问控制和生命周期的管理。

回页首

2. WebSphere Message Broker V6 Client for WebSphere Service Registry and Repository

WebSphere Message Broker v6 Client for WebSphere Service Registry and Repoistory(以下简称为WMB Client)提供了Message Broker和WSRR之间交互的功能。其中Message Broker是作为企业服务总线（Enterprise Service Bus）的一种实现来提供SOA应用运行时支持，WSRR作为一个注册处和仓库保存服务的元数据，SOA 应用在运行时访问WSRR提取服务的元数据，然后根据元数据来调用服务。这些元数据可以包括服务端点地址，服务策略，服务之间的关系等。这样作的好处时可以实现动态的调用，比如我们把服务端点地址保存在WSRR中，当服务地址发生变化时，只需更改WSRR中的元数据，而Message Broker中的SOA应用不需任何变化。

WMB Client是通过提供一组Message Broker自定义的节点来实现Message Broker和WSRR的交互的。这些节点封装了WSRR的接口调用，同时还提供额外的缓存机制来提高交互的效率。工作流的开发人员可以使用这些节点在他们的工作流中来使用特定的流程。

2.1 WMB Client的安装和配置

下载WMB Client for WSRR

WMB Client for WSRR 是以Message Broker的SupportPac提供的，用户需要从IBM的官方网站上下载，其下载链接是： http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24013639&loc=en_US&cs=utf-8&lang=en。

下载文件是一个压缩文件IA9L.zip，解压这个压缩包到一个目录（本文以C：\IA9L为例）。

在压缩包的根目录下有一个WMBv6Client4WSRR_SupportPac_Contents.txt文件，它包含了WMB Client for WSRR的目录结构和文件说明。下面简单介绍几个比较重要的文件和目录。

安装Message Broker Toolkit插件

将C:\ClientTooling\MBToolkitPlugin目录下的ServiceRegistryMessageBrokerNodesPlugin_1.0.1.zip文件解压到Message Broker 目录C:\Program Files\IBM\MessageBrokersToolkit\6.0\evtoolkit\eclipse下，然后使用"-clean"选项重新启动Message Broker Toolkit以保证插件正确的安装。

重新启动Message Broker Toolkit后，切换到消息流开发视图，打开一个消息流（如果当前工作区中没见消息流，新建一个消息流文件），这时会发现WMB Client for WSRR的5个节点将显示在编辑器中左边的面板中，如图2所示：

安装节点运行程序和部署样例

1）在节点运行程序和部署样例前，需要安装需要的jar文件：

• sdo-int.jar
• ServiceRegistryClient.jar
• ibm-jaxrpc-client.jar

关于这些文件的路径和如何安装，参考SupportPac文档。

2）更改C:\SupportPac_Shared-classes目录下的wsrr.properties属性文件。这个文件包含了WSRR的访问信息和缓存的配置信息，在安装过程会把他拷贝到Message Broker的工作目录下（C:\Documents and Settings\All Users\Application Data\IBM\MQSI\shared-classes），参考SupportPac文档第5.7.3.1节配置这个文件。

3）运行脚本开始安装和部署

使用文本编辑器打开文件C:\Tests\WSRRTestEntities\Deployment\setEnv.bat,按照说明文档配置其中的环境变量。

因为本文不会涉及缓存更新流程的安装和配置，所有我们需要把相应的命令注释掉，打开文件C:\Tests\WSRRTestEntities\Deployment\deploy_local.bat注释以下行：

mqsideploy -b %BROKER_NAME% -e %EXECUTION_GROUP% -i %HOST_NAME% -p %PORT% 
-q %QUEUE_MANAGER% -a "%CACHE_UPDATE_BAR%"

运行C:\Tests\WSRRTestEntities\Deployment\deploy_local.bat，它将：

• 拷贝相应的文件到Message Broker工作路径
• 安装节点运行程序
• 创建样例工作流用到的队列
• 部署样例工作流

4）打开事件查看器检查有无错误发生，同时可以使用Message Broker Toolkit查看样例工作流是否成功部署到Message Broker上。

运行测试程序

通过运行测试程序可以验证WMB Client节点是否正确工作。在运行测试程序之前需要确认：

1）示例Web服务程序正确的安装到WebSphere Application Server上，如果没有，用户可以运行C:\IA9L\Tests\WASTestWebServices目录下脚本来进行安装；

2）样例服务的元数据已经成功的在WSRR中创建，如果没有，用户需要运行C:\IA9L\Tests\WSRRTestEntities\SampleVirtualServices目录下的脚本来创建元数据，关于如何运行WSRR命令行脚步，参考WSRR官方文档和SupportPac中的README文件；

3）系统host 文件中加入了正确的机器名引用，因为样例流程中使用的预定义的机器名，所以需要在host文件中加入这些机器名：

• appserver:指向部署示例Web服务的机器
• serviceregistry：指向运行WSRR的机器

运行测试脚本C：\IA9L\Tests\ClientForTestExecution\run_testCustomer.bat，如果一切工作正常的话，会看到返回的信息中包含"DemoCustomer.updateCustomer(A customer description)",运行结果如图3所示：

2.2 WMB Client的组成与工作原理

WMB Client for WSRR包括两部分：WSRR节点和WMB Client代理。使用WSRR节点可以访问WSRR中存储的服务的元数据，这些节点的使用方法与Message Broker的其他节点类似，通过添加节点创建工作流，然后部署到Message Broker的运行环境中执行。WMB Client代理负责访问WSRR中存储的服务元数据，同时还提供了缓存的机制为访问WSRR中的数据提供了高效与便捷的方式。

WMB Client的结构如图4所示：

WMB Client for WSRR的工作过程如图5所示：

1）当工作流开始执行的时候，节点就开始根据用户定义的属性和从输入得到的数据通过代理去WSRR中查找服务的元数据。

2）代理首先查找缓存中是否有需要查找的数据，如果有，则直接将数据返回给请求节点，如果没有，则从WSRR中取回服务的元数据并将其存储到缓存中。

3）当有请求者要求从WSRR中查找数据的时候，WSRR就从后端的数据库中获得服务数据并将其返回给请求者。

4）如果用户通过WSRR的控制台改变了服务的元数据信息，WSRR将会发出一个通知事件来说明服务的改变。

5）当服务改变的通知事件被WMB Client的代理收到后，它会更新缓存中存储的服务数据以保证缓存中数据的正确性。

2.3 WMB Client for WSRR节点

WMB Client for WSRR共包含5个自定义的节点，他们分别是SRGetVirtualService节点， SRProcessVirtualService 节点，SRDispatchVirtualService 节点，SRRetrieveITService 节点和SRRetrieveEntity 节点，工作流的开发人员可以在工作流中通过这些节点访问WSRR中的服务的元数据。

1）SRGetVirtualService 节点

SRGetVirtualService 节点用于从WSRR中取出服务数据。SRGetVirtualService节点有三种端点，分别是In，Out，Failure。In表示节点的输入端点，当节点正确取回结果后会从Out端点输出结果，否则从 Failure端点输出结果。Name，Namespace，Version三种属性可以唯一表示流中的虚拟服务。Relationship Type和 Relationship Type XPath用来描述虚拟服务的关系类型及其属性。当MB的工作流运行时，SRGetVirtualService 节点可以根据属性页面的设置从WSRR中取回期望的结果。下图为SRGetVirtualService 节点的属性设置页面。

２）　SRProcessVirtualService 节点

SRProcessVirtualService 节点用于处理从SRGetVirtualService 节点取回的服务的内容。SRProcessVirtualService 节点有四种端点，分别是In，Retry，Out，Failure。In表示节点的输入端点，当节点正确取回结果后会从Out端点输出结果，否则从 Failure端点输出结果。

３）　SRDispatchVirtualService 节点

SRDispatchVirtualService 节点用于将执行请求发送给IT service。SRDispatchVirtualService 节点有四种端点，分别是In，Out，Failure。In表示节点的输入端点，当节点正确取回结果后会从Out端点输出结果，否则从 Failure端点输出结果。

４）SRRetrieveITService 节点

SRRetrieveITService 节点用于获得WSRR定义的服务的endpoint信息（现阶段只支持通过WSDL定义的Web Service）。它不对取回的信息做过滤和选择，但是会根据匹配原则不同给出不同的结果。SRRetrieveITService 节点有四种端点，分别是In，Out，Failure，NoMatch。In表示节点的输入端点，当节点正确取回结果后会从Out端点输出结果，如果找不到结果则从NoMatch输出结果，否则从 Failure端点输出结果。Name，Namespace，Version三种属性可以唯一表示WSDL service portType，User properties表示用户订制的属性，Classification表示WSDL service portType的分类，Match Policy表示匹配原则，可以选择匹配单个（One）或多个（All）。下图为SRRetrieveITService 节点的属性设置页面：

５）　SRRetrieveEntity 节点

SRRetrieveEntity 节点用于获取WSRR中定义的entity的信息。它不对取回的信息做过滤和选择，也不处理endpoint，也不进行基于内容的路由或是为目标服务的执行设置领域上下文，但是会根据匹配原则不同给出不同的结果。SRRetrieveITService 节点有四种端点，分别是In，Out，Failure，NoMatch。In表示节点的输入端点，当节点正确取回结果后会从Out端点输出结果，如果找不到结果则从NoMatch输出结果，否则从 Failure端点输出结果。Name，Namespace，Version三种属性可以唯一表示WSDL service portType，User properties表示用户订制的属性，Classification表示WSDL service portType的分类，Match Policy表示匹配原则，可以选择匹配单个（One）或多个（All）。下图为SRRetrieveEntity 节点的属性设置页面：

回页首

3．节点应用场景分析

3.1使用VirtualService节点构建动态工作流

WMB Client提供了3个节点（SRGetVirtualService，SRProcessVirtualService和SRDispatchVirtualService）操作WSRR中的概念（Concept），我们称这些节点为VirtualService节点。组合使用这3个节点可以实现动态的路由和切换服务实现的解决方案。 考虑以下如图9的场景。

当客户端的请求到来时，首先要根据请求的数据决定路由调用到那个服务，每个服务的定义和实现是分离的，每个服务可以有多个实现。这样当服务更改实现的时候（比如要添加添加基于不同协议的服务或要升级某一个服务），不会影响到客户端的程序。

上述例子运用了SOA中的ESB的两种模式：

• 路由模式（Router Patten）
• 转换模式（Transcoder Patten）

源服务（Source Service）通过请求信息（request）和与目标服务（Target Service）的关系（Relationship）定位要路由的目标服务，实现了路由模式。而对服务信息进行必要的格式转换以适应不同的服务实现实现了转换模式。

以下是WMB Client样例中使用WMB Client结合WSRR实现以上场景的示意图：

在Message Broker中我们用工作流来实现以上场景，以下是使用WMB Client中的VirtualService节点来实现以上场景的工作流TestFlow.msgflow。这个工作流包含在样例工作流中。

上图为一个典型的SRGetVirtualService节点， SRProcessVirtualService 节点和SRDispatchVirtualService 节点应用的一个场景。其运行流程如下：

1）SRGetVirtualService节点在收到HTTP请求后，开始根据属性页面的属性设置构造的查询语句从WSRR查询服务数据，并根据请求数据和relationship type及relationshup type value决定target service。

2）在Message Broker中， RootToLabel节点用来说明一个工作流的执行将会从一个部分转移到另外一个部分。Root to mapping节点根据SRGetVirtualService节点找到的服务的上下文决定在哪里执行路由。

3）SRGetVirtualService节点根据中介服务和目标服务之间的关系来决定路由的目标。"Label-"后服务表示目标服务，即"Label-Customer"表示"Customer"服务，"Label-Vehicle"表示"Vechicle"服务，"Label-ALL"表示其他服务。

4）在定位目标服务之后，mapping节点根据需要对消息格式进行了转换，在调用Customer 、Vehicle服务时将数据转换为SOAP格式，在调用MQ时没有进行转换

5）SRProcessVirtualService节点根据目标服务的协议添加上下文信息和设置路由目标。例如，当目标服务为基于MQ的时候，SRProcessVirtualService节点将会添加合适的MB头信息和消息格式信息，并选择"Label-MQEndpoint"。当目标服务是Customer服务时，SRProcessVirtualService节点将会添加合适的MB头信息和消息格式信息，并根据中介服务(MBService)与目标服务(CustomerService)的关系决定要路由的路径，即选择"Label-URLEndpoint"、"Label-MQEndpoint"、"Label-JMSEndpoint"。

6）"Label-URLEndpoint"表示URL类型的Endpoint、"Label-MQEndpoint"表示MQ类型的Endpoint、"Label-JMSEndpoint" 表示JMS类型的Endpoint。

7）SRDispatchVirtualService节点根据Endpoint调用真正的服务。

8）对于MQ 、JMS类型的Endpoint还要做进一步的提交操作

下面演示一下如何通过更改WSRR中的数据来实现动态的路由和协议转换。

注意：因为本文没有安装和配置缓存更新流程，所以在运行测试脚本前，必须将wsrr.properies中的needCatch属性设为false，否则在WMB Client中的缓存将得不到更新。

1）运行run_testCustomer.bat，他使用C:\IA9L\Tests\SampleMessages\message_customer.xml文件作为输入数据，服务调用被路由到CustomerService,其执行结果如下图所示：

2) 运行run_addVehicle.bat, 他使用C:\IA9L\Tests\SampleMessages\message_vehicle.xml文件作为输入数据，服务调用被路由到VehicleService，其执行结果如下图所示：

3）打开WSRR Web控制台，确定MBService_CustomerService_Relationship的networkLoc属性值为PrimaryPath，如图14所示。PrimaryPath对应于CustomerService的Web服务实现。

运行run_testCustomer.bat，消息会被转换并调用CustomerService的Web服务实现，其执行结果如图15所示：

4）在WSRR Web控制台中更改MBService_CustomerService_Relationship的networkLoc属性值为SecondaryPath。如图16所示。SecondaryPath对应于CustomerService的MQ服务实现。

运行run_testCustomer.bat，消息会被转换并调用CustomerService的MQ服务实现，其执行结果如图17所示：

3.2使用ITServcie节点动态的选择Web服务的调用

ITService节点是用来查询web服务的元数据（服务端点地址）并把它保存在Message Broker的LocalEnvironment中，这样后面的节点就可以动态的调用这个Web服务了。

以下是使用RetrieveITServcie节点的典型场景图：

当客户端的请求到来时，首先要根据请求的数据和SRRetrieveITService节点中预定义的条件从WSRR中查询要调用的服务的端点地址，然后根据WSRR中返回的实际地址调用服务，这样可以实现动态的服务路由，比如，根据区域选择要调用的服务，并且当服务地址更改时，只要更改WSRR中的服务的元数据，不会影响到客户端的程序。

下图是使用SRRetrieveITService节点在Message Broker中的工作流实现以上场景的工作流ITServiceTestFlow.msgflow，您可以在WMB Client的样例中找到这个工作流。

当工作流在收到Http请求后，开始通过设置属性页面生成的查询语句从WSRR中获取IT Service endpoint信息。如果没有找到，则通过NoMatch端点将结果发送至Post NoMatch节点。如果在查找过程中发生了异常，则通过Failure端点将结果发送至Failure节点。如果找到的结果大于等于一，则根据MatchPolicy属性的设置情况返回不同的结果。如果MatchPolicy属性为"One"，则将单个endpoint添加到domain中供其他节点使用；如果MatchPolicy属性为"All"，则将所有匹配的endpoint添加到domain中供其他节点使用。

运行run_testITService.bat，它会从WSRR中查询到需要的Web服务为DemoCustomer，然后工作流在后续的节点中调用了这个Web服务，其执行结果如图8所示。

回页首

4．总结

本文介绍了WebSphere Message Broker v6 Client for WebSphere Service Registry and Repository的工作原理以及各个节点的功能，并结合使用WebSphere Service Registry and Repository介绍了节点应用的场景。

使用WebSphere Message Broker v6 Client for WebSphere Service Registry and Repository 结合WebSphere Service Registry and Repository可以最大幅度的提高SOA应用的灵活性，使实现真正的松耦合、位置无关，协议无关的可重用的服务成为可能。

参考资料

• Introducing IBM WebSphere Service Registry and Repository, Part 1: A day in the life of WebSphere Service Registry and Repository in the SOA life cycle
  
  
• Build flexible ESB mediations with WebSphere Message Broker and WebSphere Service Registry and Repository
  

作者简介

		侯晓强：IBM中国软件开发中心软件工程师，2003年加入IBM，拥有丰富的WebSphere Business Integration相关的产品经验，包括WebSphere Process Server, WebSphere Message Broker,WebSphere Adapters等，目前从事WebSphere Service Registry and Repository相关的开发工作。

		王越：IBM中国软件开发实验室SOA设计中心软件开发工程师，主要从事SOA 相关技术的研究和相关项目的实施。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首