级别： 中级 Peter Crocker, 高级 IT 专家, IBM
Dominic Storey, 软件工程师, IBM
2009 年 3 月 03 日 本文介绍如何使用 WebSphere Message Broker V6.1 及其 WSRR 节点访问存储在 WebSphere Service Registry and Repository 中的服务信息。本文面向需要访问 WebSphere Service Registry and Repository 的 WebSphere 消息流开发人员。
引言
本文描述 IBM® WebSphere® Service Registry and Repository（以下称为 Registry and Repository）、IBM WebSphere Message Broker V6.1（以下称为 Message Broker）及其 WSRR 节点 RegistryLookup 和 EndpointLookup。然后本文将介绍如何在 Message Broker 消息流中使用这些节点，包括缓存策略和安全注意事项。最后，对于 WebSphere Message Broker V6.0 WSRR SupportPac (IA9Q) 的用户，本文将描述迁移步骤。您应该非常了解 WebSphere Message Broker 和消息流开发。
什么是 WebSphere Service Registry and Repository？
WebSphere Service Registry and Repository 提供存储、访问和管理有关服务的信息的能力，并且是成功的 SOA 实现的关键组成部分。使用 WebSphere Message Broker V6.1 中的工具，消息流可以在运行时访问此服务信息，并使用此信息来影响消息流实例的执行。
Registry and Repository 用作面向服务的信息和元数据的存储库。它并不取代任何服务代理组件，而是通过广泛的功能对那些组件形成补充，这些功能查询服务信息和元数据，然后诸如 Message Broker 等中间件组件使用该服务信息和元数据来路由服务请求和执行面向服务的策略。Registry and Repository 本身并不路由服务请求，它也不充当服务调用链中的中介。
Registry and Repository 提供用于发布和检索服务元数据的注册中心功能——包括服务功能、需求、语义，以便服务使用者能够查找服务或分析服务之间的关系。Registry and Repository 还提供对信息和元数据进行存储、管理和版本控制的存储库功能。从这方面讲，Registry and Repository 拥有部分服务信息和元数据，并通过治理和控制所管理的实体，从而在 SOA 治理中发挥重要作用。
Registry and Repository 概述
图 1. WebSphere Service Registry and Repository 的五个阶段
Registry and Repository 用于查找、发布、管理和订阅服务，并保证与这些服务的正确使用相关联的基础策略得到强制和控制。它支持以下功能：
发布——通过审批流程添加新服务，以便新服务在企业范围内可用并得到管理。服务可以是 WSDL、XML 或模式定义。
查找——基于与服务相关联的任何元数据对服务进行搜索。
充实——通过添加信息来充实服务构件，从而为 SOA 处理增添价值。此信息可以在查找阶段中使用。
管理——提供可自定义的流程来管理注册中心的服务的生命周期，从而支持访问控制、升级/退役、服务更改分析以至影响分析。
治理——在企业范围的 SOA 中提供一个集中的总体治理点。
Message Broker 允许您查找某个 Web 服务，然后使用该服务来充实您的消息。Registry and Repository 允许您发布 Web 服务，管理存储库，从而治理您的 SOA。
Message Broker 流的 Registry and Repository SOA 治理
总而言之，Registry and Repository 提供了企业中可用的所有服务的集中存储库。从 Message Broker 的角度看，不需要在消息流中预定义目标端点，因为可以在运行时动态检索这些端点。因此，您可以部署某个消息流，并通过更新 Registry and Repository 中的服务来动态控制消息流的路由和转换。
WebSphere Message Broker V6.1 WSRR 节点
WebSphere Message Broker V6.1 提供了两个与 Registry and Repository 交互的新节点：
RegistryLookup
此节点允许您从 Registry and Repository 中查询和检索任何文档或构件，包括模式、XML 和 WSDL 文档。文档在 XML 列表中返回。
|
EndpointLookup
此节点允许您从 Registry and Repository 中检索服务端点的 WSDL 文档。结果在 XML 列表中返回。使用这些结果，您可以在消息流中使用 SOAP(Async) Request 或 HTTP Request 节点动态路由消息。
|
EndpointLookup 和 RegistryLookup 使用相同的查询原理。两个节点之间的主要区别是它们返回的结果：EndpointLookup 是更专门形式的 RegistryLookup，并且仅返回 WSDL 文档。下一部分将介绍如何使用 EndPointLookup 节点检索文档。
从 Registry and Repository 检索文档
Registry and Repository 中的每个文档都是使用名称、命名空间和版本的三元组唯一地定义的。要从某个 WSRR 节点选择文档，您可以在工具的节点属性中提供这其中任意数量的属性。然后这些值将用于查询 Registry and Repository，并且取决于您的匹配策略，两个节点将单个文档或一组文档填充到本地环境中：
图 2. EndpointLookup 节点属性
图 2 显示了指定名称和版本以及两个用户属性时的示例。指定的属性将视为 WSRR Lookup 上的筛选标准。此例中显示了两种类型的用户属性：静态字符串，以及从入站消息中取得其值的 XPath 表达式。节点属性可以在本地环境中进行覆盖。下面是可用于覆盖或清除 RegistryLookup 或 EndpointLookup 节点中的设置的 ESQL 语法：
SET LocalEnvironment.ServiceRegistryLookupProperties.Name =’DomTest’
SET LocalEnvironment.ServiceRegistryLookupProperties.Namespace=’ http://www.ibm.com’
SET LocalEnvironment.ServiceRegistryLookupProperties.Version=’’
SET LocalEnvironment.ServiceRegistryLookupProperties.Template=’’
SET LocalEnvironment.ServiceRegistryLookupProperties.UserProperties=’’
SET LocalEnvironment.ServiceRegistryLookupProperties.Classification=’’
SET LocalEnvironment.ServiceRegistryLookupProperties.MatchPolicy=’’
|
检索到数据以后，将以包含查询结果的 XML 列表格式提供数据，如下所示。检索到的服务包含在 ServiceRegistry 标记之间，每个单独的服务包含在 ITService 标记之间。然后将需要处理逻辑来选择所需的特定端点或文档。下面是使用命名空间 www.ibm.com 检索到的三个端点：
<?xml version="1.0" encoding="UTF-8"?>
<LookupResults>
<WSRR_Request>
<RequiredLookup>EndpointAll</RequiredLookup>
<variableFields/>
<RuntimeOverrides>
<ServiceRegistryLookupProperties>
<Namespace>http://www.ibm.com</Namespace>
</ServiceRegistryLookupProperties>
</RuntimeOverrides>
</WSRR_Request>
<ServiceRegistry>
<ITService>
<Endpoint>
<Address>http://dom.ibm.com:61111/services/Dom</Address>
<PortType>
<name>DomTest</name>
<namespace>http://www.ibm.com</namespace>
<version></version>
</PortType>
<Property>
<name>ws-platform</name>
<value>zos-cics</value>
</Property>
</Endpoint>
</ITService>
<ITService>
<Endpoint>
<Address>http://peter.ibm.com:7080/services/Peter</Address>
<PortType>
<name>PeterTest</name>
<namespace>http://www.ibm.com</namespace>
<version>1.0</version>
</PortType>
<Property>
<name>ws-platform</name>
<value>lnx-wmb</value>
</Property>
<Property>
<name>XPathProperty</name>
<value>Dynamic1</value>
</Property>
</Endpoint>
</ITService>
</ServiceRegistry>
</LookupResults>
|
配置 Message Broker 以访问 Registry and Repository
要配置代理以访问 Registry and Repository 服务器，可以使用由代理配置的服务 ServiceRegistries 中的对象 DefaultWSRR。可配置的服务是 Message Broker V6.1 中的新概念，并允许您设置代理上的属性。要报告代理上的当前设置，可以使用以下命令：
mqsireportproperties <BrokerName> -c ServiceRegistries -o DefaultWSRR -r
|
您必须将 endpointAddress 设置为指向您的 Registry and Repository 实现。这里的限制在于，在该代理实例中运行的所有 WSSR 节点都必须使用这个相同的端点地址。要设置端点地址，可以使用以下命令：
mqsichangeproperties <BrokerName> -c ServiceRegistries –o DefaultWSRR
-n endpointAddress –v http:// <WSSR server
ip address>:9080/WSRRCoreSDO/services/WSRRCoreSDOPort
|
完成此步骤以后，WSRR 节点将在消息流中变得可操作。如果遇到问题，请检查系统日志。
使用可配置的服务来指定 Registry and Repository 位置意味着，指向不同的 Registry and Repository 实现将是非常容易的，例如当您从开发环境转移到生产环境的时候。
WSRR 节点的使用模式
WSRR 节点的使用模式包括：
- 服务位置
- 多个服务之间的选择
- 替代服务提供者
- 动态 XSLT 转换
- 动态消息充实
- 策略强制
下面是其中每种使用模式的描述以及示例消息流片段。前三种模式使用 EndpointLookup 节点，后三种模式使用 RegistryLookup 节点。有些示例发出 SOAP 请求，并且其中许多请求可以使用诸如 MQ 等其他传输。
服务位置——从 Registry and Repository 接收单个端点，并使用 SOAP Request 节点相应地路由消息。
图 3. 单端点查找流
多个服务之间的选择——从 Registry and Repository 检索多个端点，并使用一个计算节点来选择要调用哪个 SOAP 服务。此示例中存在两种不同类型的端点：
图 4. 服务选择流
还可以向 JavaCompute 节点的 alt 终端添加一个 MQOutput 节点，或者沿以下线路创建流：
Endpoint Look up => Filter => JavaCompute => SOAP Request
=> JavaCompute => MQ Output
|
替代服务提供者——从 Registry and Repository 检索多个端点，并使用其中一个端点发出 SOAP 请求。如果此请求失败，可以使用 SOAP Request Error 终端选择另一个服务。此循环可以继续，直到发出成功的请求或尝试完所有的服务为止。
图 5. 故障转移流
动态 XSLT 转换——从 Registry and Repository 检索 XSL 样式表，并将其用于转换入站消息。
图 6. 动态 XSLT 流
动态消息充实——动态地从 Registry and Repository 检索数据，并将其用于充实出站消息：
图 7. 动态消息充实流
策略强制动态地从 Registry and Repository 检索策略，并由后续的消息流加以强制。策略可以是从必需的安全凭据到确保所需服务级别得到满足的任何内容。
图 8. 策略强制
组合节点——还可以对节点进行组合。例如，可以组合服务位置和动态 XSLT 转换模式以查找某个端点，然后为该端点查找和执行适当的转换，最后向该端点发出请求：
图 9. 组合使用节点的流
性能和缓存
从消息流中对 Registry and Repository 的调用是同步的。对 Registry and Repository 发出的查询及其结果都可以在执行组级别内部地保存在缓存中。缓存可以改进经常运行的查询的性能，因为当查询及其结果保存在缓存中时，查询将从缓存得到满足，而不是每次都与 Registry and Repository 通信。与消息流中其他类型的处理相比，此类调用的开销将相对较低。
缓存可通过 needCache 和 timout 设置进行控制。needCache 缺省为 true，意味着缓存在代理启动时是起作用的。初始的 timeout 值为 100000000 毫秒，大约为 28 小时。使用下面的语法，可以使用 mqsichangeproperties 命令更改 needCache 和 timout 的值：
mqsichangeproperties <BrokerName> -c ServiceRegistries –o DefaultWSRR –n needCache –v true |
mqsichangeproperties <BrokerName> -c ServiceRegistries –o DefaultWSRR –n timeout –v 60000 |
缓存的另一个功能是预加载。使用通过本体 Web 语言（Ontology Web Language，OWL）定义的查询，您可以将代理启动时经常使用的查询预加载到缓存中。当第一条消息通过流并使用此查询时，将不存在延迟，因为节点不需要调用 Registry and Repository，并将使用缓存的结果。可以使用代理上的 predefinedCacheQueries 属性对此进行设置，同样是使用 ServiceRegistries 组件。
代理重新启动或执行组重新启动以后，内部缓存将不会保存下来。
WSRR JMS 缓存更新
可以配置 Message Broker WSRR 节点对 Registry and Repository 中由于其他活动而发生的更新做出响应。例如，您希望推送到代理的新端点可能已经变得可用。为了能够在代理中接收这些更新，您可以内部地在执行组上配置 JMS 侦听器。接收 Registry and Repository 更新时，Message Broker WSRR 节点缓存将实时更新，从而使缓存与 Registry and Repository 保持同步。
要启用缓存更新，可以将 DefaultWSRR 对象上的属性 enableCacheNotification 设置为 true，该对象在可配置的服务 ServiceRegistries 中。该属性缺省设置为 false。
mqsichangeproperties <BrokerName> -c ServiceRegistries –o DefaultWSRR
–n enableCacheNotification –v true |
您还必须将 locationJNDIBinding 属性更改为指向您的 WSSR 服务器：
mqsichangeproperties <BrokerName> -c ServiceRegistries –o DefaultWSRR
–n locationJNDIBinding –v iiop://<WSSR server ip address>:2809/ |
图 10. 缓存更新侦听器框架
JMS 缓存更新侦听器还有另外三个属性：connectionFactoryName、initialContextFactory 和 subscriptionTopic。在大多数 Registry and Repository 环境中，您可以将这些属性保留缺省设置。
安全注意事项
Registry and Repository 中的安全性依赖基础的 WebSphere Application Server 安全模型。
要从代理访问 Registry and Repository，可以使用 mqsisetdbparams 命令为代理指定用户名和密码：
mqsisetdbparms <BrokerName> -n DefaultWSRR::WSRR -u <uid> -p <pwd> |
密钥存储区和信任存储区设置直接取自代理上指定的全局安全属性。
如果在使用 WSRR JMS 缓存更新并拥有安全连接，您还需要设置用于连接到连接工厂的用户名和密码。缺省设置为 jms/SRConnectionFactory：
mqsisetdbparms <BrokerName> -n jms::jms/SRConnectionFactory -u <uid> -p <pwd> |
从 Support Pac IA9Q 迁移
WSRR 节点最初是作为 SupportPac IA9Q 于 2007 年初发布的。从那以后，节点已经过改进，如下所述：
- Support Pac 节点使用一个配置文件进行配置。现在所有配置都使用可配置的服务 ServiceRegistries 以及对象 DefaultWSRR 直接在代理上执行。
- SRRetrieveITService 节点已变为 RegistryEndpoint。
- SRRetrieveEntity 节点已变为 RegistryLookup。
- 新的 SOAP 节点可以与 WSRR 节点结合使用。
- SupportPac 中使用的缓存更新流现已内置在新的 Message Broker V6.1 节点中。
使用 SupportPac 节点的现有流将需要重新构建和重新部署，从而涉及到使用和配置新的 V6.1 WSRR 节点来替换旧的节点。您还需要重新对流进行测试，以确保仍然检索到预期的结果。
结束语
本文介绍了 WebSphere Service Registry and Repository 在 WebSphere Message Broker V6.1 中的使用。本文说明了如何使用 RegistryLookup 和 EndpointLookup 节点从 Registry and Repository 检索文档，以及如何配置 Message Broker 来实现这一点。本文还描述了许多演示如何在消息流中使用节点的使用模式。最后，本文讨论了性能和缓存、安全性，以及从以前提供了 Registry and Repository 连接的 2007 SupportPac 的迁移。
我们希望本文说明了从 WebSphere Message Broker V6.1 中的消息流访问 WebSphere Service Registry and Repository 中诸如端点、文档和模式等数据是多么容易。访问此数据将使您能够动态地控制服务调用，从而可以为您的消息代理实现添加灵活性和弹性。
参考资料
作者简介  | | |
Peter Crocker 在位于英国的 IBM Hursley 软件实验室的软件服务团队中工作。他精通 WebSphere Message Broker，负责为主要客户提供体系结构、设计和实现方面的咨询。在担当目前的角色之前，Peter 在 Message Broker Development 团队工作，这使得他能够在技术上深入了解 Message Broker 内部细节。在 V6 发布之前，他曾帮助完成其测试版程序，并帮助开发和提供了面向 Services 团队的有关 V6 中新功能的培训。 |
| | |
Dominic Storey 是位于英国的 IBM Hursley Lab 的一名软件工程师。他目前在 Message Broker Tooling 开发团队工作。他以前还曾在 Message Broker 开发团队以及 MQSeries 开发团队工作过。他于 1997 年加入 IBM。
|
对本文的评价
| 
