第 8 部分将介绍如何使用 HTTP Request 节点动态地从 WSRR 检索服务元数据，并使用数据数据来检查服务使用者是否有权调用目标服务。在提供一个服务以便在组织中重用该服务时，服务提供者通常会提供许多工件，服务使用者可以使用这些工件来实现客户应用程序或服务。这些工件通常包含一个或多个 WSDL 或 XML 模式文档。尽管这些工件提供了服务使用者开发人员所需的信息，但它们未提供与服务使用者期望从该服务获得的非功能性或服务质量 (QoS) 特征的任何信息。
IBM WebSphere Service Registry and Repository（下文简称 WSRR）中提供的 Governance Enablement Profile (GEP) 是一个完整的 WSRR 配置文件，该文件包含所有业务模型、生命周期、本体和治理策略信息，您需要使用它们才能快速掌握面向服务的架构 (SOA) 的治理。它使得服务提供者可以使用服务水平定义 (SLD) 捕获服务的 QoS 特征。它还使得服务提供者与服务使用者之间存在的协议可以使用服务水平协议 (SLA) 来表示。
本文将介绍一个示例消息流，它在运行时执行 WSRR 中定义的 SLA，以确保服务使用者有权调用目标服务。尽管它实现了与本系列第 5 部分 “在运行时执行 SLA 检查” 中描述的消息流相同的结果，但本文中描述的消息流的实现方式完全不同。它使用了一个 HTTP Request 节点来调用 WSRR REST API，以获取所需的元数据。
SLA 检查业务场景
本文中描述的示例流将重点关注本系列第一部分 “场景和配置” 中描述的 SLA 检查场景，如下所示：
业务问题
您的 SOA 中部署了许多服务，而且它们都已经在 WSRR 中注册。但是，您无法在 WSRR 中注册这些服务的使用者。结果，您不知道哪些服务使用者可能在任何给定时间点调用每个服务。您希望确保 SOA 中的所有服务使用者都已在 WSRR 中注册，而且只有有权调用目标服务的使用者被允许这么做。
解决方案
WSRR 允许您在 SOA 中注册服务使用者，以及服务提供者。它还支持使用服务水平协议 (SLA) 表示服务提供者和服务使用者之间的协议或契约。消息流可以在运行时动态地从 WSRR 检索此信息，使用它确定服务使用者是否有权调用目标服务。如果服务使用者有权调用目标服务，那么它可以将请求转发给协商一致的端点。如果服务使用者无权调用目标服务，则会返回一个适当的错误。
好处
此方法允许您控制哪些服务使用者可以调用实际的后端服务，使您能够在 SOA 中执行一定水平的运行时治理。此方法的一个附加好处是，服务使用者和提供者在 WSRR 中注册后，就可以在 Service Registry Dashboard 用户界面直观地表示这些关系，并使用它来评估您计划对服务所做的任何更改的影响。
建模服务提供者和使用者
GEP 中包含的业务模型定义了所有必要的对象类型，您需要使用它们来表示服务提供者、服务使用者和它们之间的协议。有关如何建模这些概念的更多信息，请参阅 建模服务提供者 和 建模服务使用者，这两小节都包含在第 5 部分中。您应该熟悉这些概念，以便能够完全理解此消息流的实现。
HTTP Request 节点概述
IBM Integration Toolkit 提供了 HTTP Request 节点来支持与 HTTP 服务交互。此节点允许您使用所有或部分输入消息作为发送给服务的请求。您还可以使用它来根据输入消息创建一个输出消息，在通过服务响应的内容增强之后，将该消息传播给流中的后续节点。
还可以将该节点配置为从输入消息的指定部分构造 HTTP 或 HTTPS 请求，并将此请求发送给目标服务。然后，它可以解析来自服务的响应，将该内容注入到输出树中，以便将它传播给流中的其他节点。
节点终端
HTTP Request 节点的终端如 中所示。这些终端将在 中描述。
HTTP Request 节点终端
HTTP Request 节点上的终端
终端 描述 In 输入终端，接受一条消息供节点处理。 Failure 输出终端，如果在节点中处理期间检测到失败，消息将路由到该终端。 Out 输出终端，如果消息表示服务请求成功完成，如果需要在此消息流中执行进一步处理，那么消息将被路由到该终端。 Error 输出终端，如果未设置 Follow HTTP(s) redirection 属性，包含 200 到 299 范围之外的 HTTP 状态代码（包括重定向代码 (3xx)）的消息将被路由到该终端。
节点属性
HTTP Request 节点提供了丰富的属性，可以使用 IBM Integration Toolkit 中的 Properties 编辑器配置它们。许多属性尚未由本文中介绍的消息流修改。为了简便起见， 中仅描述已由该消息流修改的 HTTP Request 节点的属性。
HTTP Request 节点属性
属性 编辑器选项卡 描述 Web Service URL Basic 目标服务的 URL。必须以 http://hostname[:port]/[path] 格式指定，其中：必须指定 http://hostname。 port 的默认值为 80。如果指定一个值，必须在端口号之前包含冒号。 path 的默认值为 /。如果指定某个值，则必须在路径之前包含 /。
Web Service URL 属性的值可以使用消息流中早期的某个计算节点通过编程方式进行指定，将元素插入到输入消息或本地环境树中。以编程方式指定的值会覆盖节点上指定的值。可以用来覆盖节点上指定的值的位置包括：
输入消息中的 HTTP Request 标头中的 X-Original-HTTP-URL。 本地环境树中的 Destination.HTTP.RequestURL。
显示的位置是按优先级顺序列出的。也就是说，如果为 X-Original-HTTP-URL 字段指定了一个值，那么该值会覆盖 Destination.HTTP.RequestURL 字段中指定的任何值。
如果指定的 URL 以 http:// 开头，那么请求节点会向指定的 URL 发出一个 HTTP 请求。如果指定的 URL 以 https:// 开头，那么请求节点会使用节点的 SSL 选项卡上指定的参数，向指定的 URL 发出一个 HTTP over SSL (HTTPS) 请求。
HTTP method HTTP Settings 该结点在发出请求时将使用的 HTTP 方法。有效值包括 POST、GET、PUT、DELETE 和 HEAD。默认情况下，在连接到远程 Web 服务器时，HTTP Request 节点会使用 HTTP POST 方法。 HTTP Version HTTP Settings 指定该节点在发出请求时将使用的 HTTP 版本。有效值包括 1.0 和 1.1。 Use Compression HTTP Settings 此属性控制是否压缩 HTTP 请求的内容。有效值包括 none、gzip、zlib (deflate) 和 deflate。如果请求是压缩的，则会设置 Content-Encoding 标头来指示内容是压缩的。 Protocol SSL
此属性指定了在发出 HTTPS 请求时要使用的协议。SSL 连接的两端必须对要使用的协议达成一致意见。因此，选择的协议必须是远程服务器可以接受的协议。有以下选项可供选择：
SSL。此选项是默认选项。此选项尝试先使用 SSLv3 协议连接，但在基础 JSSE 提供者支持 SSLv2 协议时，支持握手回退到 SSLv2 协议。 SSLv3此选项仅尝试连接 SSLv3 协议，不能回退到 SSLv2。 TLS。此选项仅尝试连接 TLS 协议。不能回退到 SSLv3 或 SSLv2。 Message Domain Response Message Parsing
指定将用于解析响应的解析器。如果该字段是空的，那么默认值为 BLOB。有以下选项可供选择：
DFDL XMLNSC JSON BLOB MIME MRM XMLNS Replace input message with web-service response Advanced 如果选择此复选框，那么 Web 服务响应消息会被用作节点的输出消息，取代原始的输入消息。如果清除此复选框，必须为 Response message location in tree 属性指定一个值。 Response message location in tree Advanced 指定了存储来自 Web 服务响应比特流的已解析的元素的位置。此属性采用了 ESQL 字段引用的格式。 Accept compressed responses by default Advanced 此属性指示了请求节点默认是否处理压缩的响应。如果请求标头未包含 Accept-Encoding 标头并选择了此选项，那么该节点会将 Accept-Encoding 标头设置为 “gzip, deflate”，收到的任何压缩响应都会被该节点解压。
访问安全的服务
如果 HTTP Request 节点访问的服务要求客户端进行身份验证，则必须将安全配置文件与某个允许将凭据传播给目标服务的节点相关联。IIB 提供了一个配置文件，它已预先配置为允许凭据传播并专供请求节点使用。该配置文件就是 Default Propagation 安全配置文件。要在消息流中的一个节点上配置此安全配置文件，必须使用 IBM Integration Toolkit 中的 Broker Archive Editor。在本系列文章提供的示例流中包含的所有 HTTP Request 节点上，都已配置此安全配置文件。要验证这一点，可以执行以下步骤：
打开 IBM Integration Toolkit。 打开 Integration Development 透视图。 在 Application Development 视图中，展开 BARs 并双击 WSRRIntegrationDemos.bar，如下所示：
打开 BAR 文件
该文件将在 Broker Archive Editor 中打开。选择编辑器底部的 Manage 选项卡。 展开 WSRRIntegrationDemos => HTTPNode_SLACheck_GlobalCache.msgflow -> HTTPNode_SLACheck_GlobalCache。 从流中的节点列表中选择 WSRR REST Query，如下所示：
选择节点
节点的属性将显示在 Properties 编辑器中。在 Configure 选项卡上，Security Profile 属性靠近属性列表底部，如下所示：
Security Profile 属性
IIB 全局缓存
使用 Endpoint Lookup 和 Registry Lookup 节点与 WSRR 交互的一个好处是，IIB 为这些节点提供了一个缓存，可使用它在可配置的时间段内存储获取的元数据存储。此缓存已在 第 7 部分：在 IIB 中配置 WSRR 缓存 中详细介绍。但是，因为本文中描述的消息流未使用 WSRR 节点，所以我们必须使用另一种缓存机制，以确保对于处理的每个请求，该消息流的性能不会受对 WSRR 的查询影响。
幸运的是，IIB 提供了另一种缓存机制，消息流可以使用它来存储从 WSRR 获取的元数据。全局缓存最初被引入到 WMB V8.0.0.1 中，并在 IIB V9 中得到了增强。全局缓存是使用嵌入式 WebSphere eXtreme Scale (WebSphere XS) 技术实现的。通过托管 WebSphere XS 组件，嵌入在 IBM 执行组中的 JVM 可以协作提供一个缓存。
默认情况下，全局缓存是关闭的，而且缓存策略被设置为禁用。要使用全局缓存，必须在代理级别上指定一个合适的缓存策略。全局缓存具有默认的单代理拓扑结构，该拓扑结构无需任何配置即可立即使用。
与全局缓存交互
IIB 提供了 MbGlobalMap 对象来支持消息流访问全局缓存。这是一个 Java 对象，所以必须在您消息流中的一个 Java Compute 节点中使用。此对象处理客户端与全局缓存进行连接，这为处理缓存中的映射提供了许多方法。可用的方法类似于您可以在常规 Java 映射上找到的方法。各个 MbGlobalMap 对象都是使用 MbGlobalMap 类上的一个静态 getter 来创建的，此 getter 可充当着一种工厂机制。您可以匿名地创建 MbGlobalMap 对象（在幕后使用 WebSphere XS 中预定义的默认映射名称），或者使用您选择的映射名称来创建它。 中的代码显示了一个使用名称WSRREndpointCache 创建的 MbGlobalMap 对象。
启用全局缓存
MbGlobalMap endpointCache = MbGlobalMap.getGlobalMap("WSRREndpointCache");
从全局缓存中删除数据
获得 MbGlobalMap 对象后，还可以指定数据在自动删除之前在全局缓存中保留多长时间。这个时间称为存活时间 (time to live)，从映射条目上次更新时开始计算。该值应当用于使用该 MbGlobalMap 对象在该消息流实例中创建的所有缓存条目。默认情况下，存活时间被设置为 0，以便不会删除数据。要设置特定的存活时间，需要创建一个会话策略，可以从 MbGlobalMap 对象应用该策略。 中的代码展示了如何创建一个 MbGlobalMap 对象，并将存活时间会话策略设置为 30 秒。
启用全局缓存
MbGlobalMapSessionPolicy sessionPolicy = new MbGlobalMapSessionPolicy(30);MbGlobalMap endpointCache = MbGlobalMap.getGlobalMap("WSRREndpointCache", sessionPolicy);
WSRR 命名查询
WSRR 中的命名查询提供了一种强大的机制，允许创建可以使用任何 WSRR API 调用的预定义的查询。它们是在配置文件中定义的，这些配置文件是作为一个 WSRR 配置文件的一部分来维护的。因此，WSRR 管理员可以使用 WSRR 所提供的 WSRR Studio、Web UI 或管理脚本来创建、修改和删除这些配置文件。
定义命名查询时，您为配置文件指定的名称可用于识别该查询。WSRR 客户端使用此名称指定它们想要调用的命名查询。命名查询配置文件的内容定义：
查询的类型：propertyQuery 或 graphQuery。 在调用查询时对 WSRR 执行的 XPath 表达式。此 XPath 表达式可以包含一些参数的定义，客户端在调用命名查询时必须传递这些参数。在执行查询之前，这些参数会在运行时在服务器上被替换。 查询的深度，如果指定的类型为 graphQuery。那么此深度必须为 0、1 或 -1。 要返回的属性列表，如果指定的类型为 property
命名查询的真正强大之处在于，它将所需的所有信息都封装在配置文件中。WSRR 客户端仅需要知道它们想要调用的命名查询的名称，以及它们需要传递的参数。底层模型的复杂性（以及用于对模型执行查询的 XPath 表达式）已对 WSRR 客户端隐藏。命名查询还对模型更改提供了一定的保护水平，它允许修改配置文件中的 XPath 表达式来反映更改，而不会影响客户端。
SLAEndpointLookup 命名查询
SLAEndpointLookup 命名查询是在 WSRR 7.5 版中的 GEP 中引入的。它定义了一个 XPath 表达式，用以执行所有需要的检查，以确保服务使用者有权调用目标服务。回想一下以前介绍的内容，在第 5 部分中的 SLA Check 节点 一节中，需要在一个 Java Compute 节点中以编程方式执行所有这些检查。SLAEndpointLookup 命名查询可以在一个 XPath 表达式中捕获所有这些检查，因为它可以自由地定义一个复杂表达式，以遍历多个对象并在查询的各种阶段应用断言。IIB 中的 Endpoint Lookup 或 Registry Lookup 节点不允许您控制生成的 XPath 表达式。
前面已经提到过，SLAEndpointLookup 命名查询的 XPath 表达式很复杂，这里没有详细介绍它。但是这同样的，在 WSRR 中使用命名查询有一些好处。WSRR 客户端不需要理解命名查询配置的复杂性。它只需理解需要传递的参数，以及应返回的结果。对于 SLAEndpointLookup，需要的参数包括：
服务使用者的使用者标识符 SLA 的上下文标识符 端点的环境分类的 OWL URI
返回的对象是在目标服务提供者的 SLD 上定义的服务端点。
WSRR REST API
WSRR 提供了许多 API，它们可用于与向该产品注册的服务元数据工件进行交互，如下所示：
Enterprise JavaBean (EJB) API Web Service API REST API
所有这些 API 都支持发布（创建和更新）服务工件和与这些工件有关联的元数据，获取服务元数据工件，删除工件和它们的元数据，以及查询 WSRR 的内容。基本的创建、获取、更新和删除操作，以及治理操作和基于 XPath 的灵活的查询工具，都是通过这些 API 提供的。
WSRR REST API 允许不支持 EJB 和 Web 服务的轻量型客户端使用 HTTP 请求在内容和元数据上执行操作。WSRR 客户端还能够使用 REST API 调用在 WSRR 中配置的命名查询。例如， 中所示的 URL 可以粘贴到一个 Web 浏览器中，以便调用 SLAEndpointLookup 命名查询，传递 3 个需要的参数作为 URL 查询参数。请注意，为了方便阅读，这些参数被拆分到多行上，而且 p3 参数的 OWL URI 需要编码为 URL。
示例命名查询 URL
https://localhost:9443/WSRR/8.0/Metadata/XML/Query/SLAEndpointLookup? p1=CalculatorApplication& p2=CTX_1& p3=http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staging
消息流描述
SLA 检查消息流（比如 中所示）使用了服务请求中指定的使用者标识符和上下文标识符，确定服务使用者是否有权调用目标服务。为此，它调用 SLAEndpointLookup 命名查询来获取服务使用者有权使用来调用该服务的端点列表。如果返回了一个或多个端点，它会选择第一个端点并将请求转发给它。如果未返回端点，它会使用一个合适的错误来响应客户。以下各节详细将会介绍此消息流中的每个节点，以及每个节点用来执行 SLA 检查的所有设置或代码。
SLA 检查消息流
Service Request 节点
该消息流始于 Service Request SOAP Input 节点。关于此节点，一定要注意的是，它被配置为公开 Math Service 的接口。这在节点的Properties 编辑器的 Basic 选项卡上指定，比如 中所示。可以看到，MathServerServiceDummyEndpoint.wsdl 已在 WSDL file name 字段中指定。该节点的其他基本属性会在选择 WSDL 文件后自动填入。通过配置 SOAP Input 节点来公开一个特定的 WSDL 接口时，该节点将验证它收到的所有服务请求，确保它们符合 WSDL 中包含的服务的定义。还可以配置此节点来使用带 URL 后缀/MathServer/Services/MathServer/slacheck5 的 HTTP 传输。在调用此消息流公开的服务时，使用者需要使用这个值。Service Request 节点使用 out 终端连接到 SLA 检查消息流中的下一个节点。
公开的 WSDL 接口
Check SOAP Headers 节点
Check SOAP Headers 节点是 Java Compute 节点的一个实例。此节点将会处理 Service Request 节点传递给它的服务请求，从 SOAP 标头提取使用者标识和上下文标识属性。然后，该节点将会检查提取的值是否有效。 中的代码显示了执行的任务。
提取使用者标识和上下文标识
MbMessage inMessage = inAssembly.getMessage();MbElement rootElement = inMessage.getRootElement();MbElement consumerIdElement = rootElement.getFirstElementByPath("/SOAP/Header/MathHeader/consumerID");MbElement contextIdElement = rootElement.getFirstElementByPath("/SOAP/Header/MathHeader/contextID"); if ( consumerIdElement != null && consumerIdElement.getValue() != null && contextIdElement != null &&contextIdElement.getValue() != null) { ...}
如果未在服务请求中为一个标识符指定有效值，那么 Check SOAP Headers 节点会生成一个 SOAP 故障，并将该消息传递给 failure 终端。这个终端与 SOAP Reply 节点直接相连，后者将 SOAP 错误传回给客户端。此检查很重要，而且在消息流的最初极端执行，因为消息流需要能够识别服务使用者和应用到服务请求上的相关的 SLA。
通过这个初始检查后，Check SOAP Headers 节点会将该消息传递给 out 终端，后者连接到 Check WSRR Cache 节点。
Check WSRR Cache 节点
Check WSRR Cache 节点是 Java Compute 节点的另一个实例。从名称可以看出，此节点将会检查在 IIB 全局缓存中维护的端点缓存，查看之前是否已获取过这个使用者标识符和上下文标识符组合的任何端点。因为使用者标识符和上下文标识符应是惟一的，所以只需串联这两个值就可以生成进入缓存的密钥。 中的代码显示了执行的任务。
检查 IIB 全局缓存
WSRRCache wsrrCache = WSRRCache.getInstance(); String consumerId = getConsumerId(inAssembly);String contextId = getContextId(inAssembly);String cacheId = consumerId + contextId;String addressUrl = wsrrCache.getEndpoint(cacheId);if (addressUrl != null && !addressUrl.isEmpty()) { ...} else { ...}
使用一个实用程序类 WSRRCache 来维护 IIB 全局缓存中的端点缓存。 显示了如何访问缓存来尝试获取端点。同样需要注意的是，缓存中的条目的存活时间策略为 30 秒。
检查 IIB 全局缓存
MbGlobalMapSessionPolicy sessionPolicy = new MbGlobalMapSessionPolicy(30);endpointCache = MbGlobalMap.getGlobalMap("WSRREndpointCache", sessionPolicy);...public String getEndpoint(String cacheId) { String endpoint = null; try { endpoint = (String)endpointCache.get(cacheId); } catch (MbException e) { e.printStackTrace(); } return endpoint;}
如果在缓存中找到了具有指定 ID 的端点，那么消息流会将服务请求转发到目标服务上，而不对 WSRR 执行任何查询。为此，SLA 检查消息流会使用一个名为 Forward Request 的 SOAP Request 节点。为了以编程方式覆盖已在 Forward Request 节点上配置的 Web Service URL，Check WSRR Cache 节点需要将端点地址插入本地环境树的 Destination.SOAP.Request.Transport.HTTP.WebServiceURL 字段中。 给出了执行此任务所需的代码。然后，Check WSRR Cache 节点将消息传递给 out 终端，后者连接到 Forward Request 节点。
以编程方式指定 Web 服务 URL
MbMessage environment = new MbMessage(inAssembly.getLocalEnvironment());MbElement environmentRoot = environment.getRootElement();environmentRoot.evaluateXPath( "?Destination/?SOAP/?Request/?Transport/?HTTP/?WebServiceURL[set-value('" + addressUrl + "')]");outAssembly = new MbMessageAssembly( inAssembly , environment , inAssembly.getExceptionList() , inAssembly.getMessage() );outTerminal = getOutputTerminal("out");
如果未在缓存中找到具有指定 ID 的端点，消息流需要在 WSRR 中调用 SLAEndpointLookup 命名查询，并将使用者标识符和上下文标识符作为参数，与目标端点的环境的 OWL URI 一起传递。为此，它必须构造用于调用命名查询的 URL，并将其插入到本地环境树的Destination.HTTP.RequestURL 字段中。通过以编程方式查询 IIB 的 DefaultWSRR 可配置服务对象中的 endpointAddress 属性，并提取相应的值，它可以确定 URL 的模式、主机和端口。此任务由 WSRRConfigurationUtils 实用程序类执行。它必须将针对 SLAEndpointLookup 命名查询的参数插入到本地环境树的相关字段中。 给出了执行这些任务所需的代码。
以编程方式指定 REST URL
private static final String NAMED_QUERY_SLAENDPOINTLOOKUP = "/WSRR/8.0/Metadata/XML/Query/SLAEndpointLookup";private static final String OWL_URL_STAGING = "http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staging"; WSRRConfigurationUtils wsrrConfig = WSRRConfigurationUtils.getInstance(); URI wsrrUrl = new URI( wsrrConfig.getScheme() , null , wsrrConfig.getWsrrHost() , wsrrConfig.getWsrrPort() , NAMED_QUERY_SLAENDPOINTLOOKUP , null , null);environmentRoot.evaluateXPath("?Destination/?HTTP/?RequestURL[set-value('" + wsrrUrl.toString() + "')]"); environmentRoot.evaluateXPath("?Destination/?HTTP/?QueryString/?p1[set-value('" + getConsumerId(inAssembly) + "')]");environmentRoot.evaluateXPath("?Destination/?HTTP/?QueryString/?p2[set-value('" + getContextId(inAssembly) + "')]");environmentRoot.evaluateXPath("?Destination/?HTTP/?QueryString/?p3[set-value('" + OWL_URL_STAGING + "')]");
Check WSRR Cache 节点可以将请求转发到 HTTP Request 节点上之前，它需要执行多个其他的任务。
下游 HTTP Request 节点已配置为将响应消息放在本地环境树中的一个特定位置中。Check WSRR Cache 节点需要在本地环境树中创建父条目。 HTTP Request 节点未使用 BrokerRegistry 对象上的配置来确定在发送 HTTP 请求时使用哪个密钥库和信任库。密钥库的位置、信任库的位置和它们的密码必须在本地环境中以编程方式配置，然后才能在流中调用 HTTP Request 节点。WSRRConfigurationUtils 实用程序类用于从一个名为 WSRRREST 的用户定义的可配置服务获取此信息。 在调用 REST API 时，需要由 HTTP Request 节点将凭据传播给 WSRR，该凭据需要在输出消息上以编程方式定义。同样地，也可以使用WSRRConfigurationUtils 实用程序类获取此信息。
给出了执行这些任务所需的代码。然后，Check WSRR Cache 节点将消息传递给 alternate 终端，后者连接到 WSRR REST Query 节点。
配置其他属性
// Create a folder in the local environment to hold the response from the REST queryenvironmentRoot.createElementAsLastChild(MbXMLNSC.PARSER_NAME);// Specify the location of the keystore and truststore used by the HTTP Request nodeenvironmentRoot.evaluateXPath("?Destination/?HTTP/?KeystoreFile[set-value('" + wsrrConfig.getKeystoreFile() + "')]");environmentRoot.evaluateXPath("?Destination/?HTTP/?KeystorePassword[set-value('" + wsrrConfig.getKeystorePassword() + "')]");environmentRoot.evaluateXPath("?Destination/?HTTP/?TruststoreFile[set-value('" + wsrrConfig.getTruststoreFile() + "')]");environmentRoot.evaluateXPath("?Destination/?HTTP/?TruststorePassword[set-value('" + wsrrConfig.getKeystorePassword() + "')]");// Create the message assembly to returnMbMessage outMessage = new MbMessage(inMessage);MbElement rootElement = outMessage.getRootElement();rootElement.evaluateXPath("?Properties/?IdentitySourceType[set-value(" + "'usernameAndPassword')]");rootElement.evaluateXPath("?Properties/?IdentitySourceToken[set-value('" + wsrrConfig.getUserId() + "')]");rootElement.evaluateXPath("?Properties/?IdentitySourcePassword[set-value('" + wsrrConfig.getPassword() + "')]");outAssembly = new MbMessageAssembly( inAssembly , environment , inAssembly.getExceptionList() , outMessage );outTerminal = getOutputTerminal("alternate");
WSRR REST Query 节点
WSRR REST Query 节点是一个 HTTP Request 节点实例。它的行为由前一个节点以编程方式创建的条目和节点本身上定义的属性共同决定。 显示了在 WSRR REST Query 节点上指定的属性的值。
WSRR REST Query 节点属性
属性 值 HTTP method GET HTTP Version 1.1 Use Compression gzip Protocol SSL Message Domain XMLNSC Replace input message with web-service response Unchecked Response message location in tree InputLocalEnvironment.XMLNSC.WSRR.REST.Response Accept compressed responses by default Checked
WSRR REST Query 节点将在 WSRR 中调用 SLAEndpointLookup 命名查询，并将结果写入在该节点上配置的位置上。out 终端连接到 Cache REST Results 节点。
Cache REST Results 节点
Cache REST Results 节点处理 WSRR REST Query 节点返回的结果。它尝试从本地环境树中提取查询所返回的端点列表，检查是否返回了任何端点。 给出了执行此任务所需的代码。如果未返回任何端点，那么该节点将会生成一个 SOAP 故障，并将此故障消息传递给 failure 终端。这个终端与 SOAP Reply 节点直接相连，后者将 SOAP 错误传回给客户端。
检查 REST 结果
MbElement rootElement = inAssembly.getLocalEnvironment().getRootElement();MbElement wsrrElement = rootElement.getFirstElementByPath("XMLNSC/WSRR");List<MbElement> availableEndpoints = (List <MbElement>)wsrrElement.evaluateXPath("REST/Response/resources/resource");if (availableEndpoints != null && !availableEndpoints.isEmpty()) { ...} else { ...}
如果针对 WSRR 的 REST 查询返回了一些端点，那么 Cache REST Results 节点会选择第一个端点，并将它缓存在 IIB 全局缓存中，通过串联使用者标识符和上下文标识符来生成密钥。该端点存储在缓存中后，通过在本地环境树中设置相关值并将消息传递给 Forward Request 节点，Cache REST Results 节点将服务请求转发到目标服务上。 给出了执行此任务所需的代码。
缓存端点
MbElement endpoint = availableEndpoints.get(0);String addressUrl = (String)endpoint.evaluateXPath( "string(properties/property[@name='name']/attribute::value)"); if (addressUrl != null) { // Cache the results String consumerId = getConsumerId(inAssembly); String contextId = getContextId(inAssembly); String cacheId = consumerId + contextId; wsrrCache.addEndpoint(cacheId, addressUrl); MbMessage environment = new MbMessage(inAssembly.getLocalEnvironment()); MbElement environmentRoot = environment.getRootElement(); environmentRoot.evaluateXPath( "?Destination/?SOAP/?Request/?Transport/?HTTP/?WebServiceURL[set-value('" + addressUrl + "')]"); // Create the message assembly to return outAssembly = new MbMessageAssembly( inAssembly , environment , inAssembly.getExceptionList() , inAssembly.getMessage() ); outputTerminal = getOutputTerminal("out");}
Forward Request 和 SOAP Reply 节点
Forward Request 节点负责调用目标服务，在本例中为 Math Service 的版本 1.0。在定义消息流时，必须为此节点上的 Web Service URL 属性指定一个值，即使该值将在运行时会被流中的 Java Compute 节点以编程方式覆盖。因此，为此属性指定了一个虚拟值http://tempuri.org/MathServer/services/MathServer。需要注意的另一点是，节点的 Operation mode 必须设置为 Invoke a generic web service。该接口在节点的 Properties 编辑器的 Basic 选项卡上指定。它使得消息流能够代理 Math Service 上定义的任何操作的请求，而不是被迫代理单个操作。Forward Request 节点使用它的所有终端直接连接到 SOAP Reply 节点：out、fault 和 failure。
从名称可以看出，SOAP Reply 节点将一个 SOAP 请求传递回服务使用者。成功经过该消息流后，返回的响应将是来自实际目标服务的响应。如果发生错误，响应将是由消息流中的一个 Java Compute 节点或目标服务本身生成的 SOAP 错误。
其他配置
在测试 SLA 检查消息流之前，需要执行一些额外的配置步骤。以下各节将会介绍这些步骤：
启用 IIB 全局缓存
本节中描述的消息流需要启用全局缓存才能正常工作。要在该消息流部署到的代理实例上启用全局缓存，则需要使用 mqsichangeproperties命令，如 中所示。您需要重新启动代理，更改才会生效。
启用全局缓存
mqsichangeproperties <BROKER_NAME> -b cachemanager -o CacheManager -n policy -v default
其中：
<BROKER_NAME> 是代理的名称 (Integration Node)。
创建 WSRRREST 可配置服务
需要以编程方式为 HTTP Request 指定各种属性。这些属性的值可能已经硬编码到消息流中。一个更好的解决方案是在 IIB 中创建一个用户定义的可配置服务，在运行时动态获取属性。本消息流中采用的就是这种方法。要创建这个可配置服务，需要使用mqsicreateconfigurableservice 命令，如下所示：
创建 WSRRREST 可配置服务
mqsicreateconfigurableservice<BROKER_NAME> -c UserDefined -o WSRRREST
其中：
<BROKER_NAME> 是代理的名称 (Integration Node)。
要在 WSRRREST 可配置服务上创建所需的属性，需要使用 mqsichangeproperties 命令，如下所示：
创建需要的属性
mqsichangeproperties <BROKER_NAME> -c UserDefined -o WSRRREST -n keystoreFile -v <KEY_STORE_FILE>
其中：
<BROKER_NAME> 是代理的名称 (Integration Node)。 <KEY_STORE_FILE> 是密钥库文件的完整路径。出于配置此消息流的用途，在实际中可以使用 第 1 部分：场景和配置 中创建的信任库作为密钥库和信任库。
重复此过程，在 WSRRREST 可配置服务上创建以下属性：
WSRRREST 可配置服务的属性
属性名称 值 keystorePassword 密钥库的密码。 truststoreFile 信任库文件的完整路径。 truststorePassword 信任库的密码。 userId 有权访问 WSRR 中需要的工件的用户的 ID。 userPassword 此用户的密码。
此刻应重新启动代理 (Integration Node)，确保所有更改都已生效。
测试消息流
下一节将会介绍如何使用 Calculator 应用程序验证 SLA 检查消息流在正常工作。
基本测试
确保您的 IIB 执行组正在运行，已部署并启动 HTTPNode_SLACheck_GlobalCache流。 启动 Calculator 应用程序，如第 1 部分中的 运行 Calculator 应用程序 中所述。 为运行 IIB 的服务器输入主机名和端口号。例如，如果在与 Calculator 应用程序相同的机器上运行 IIB，而且使用了默认端口，那么这些值将为 localhost 和 7800。 修改服务路径，将它的值设置为 /MathServer/services/MathServer/slacheck5。这是 HTTPNode_SLACheck_GlobalCache 流的端点。 将 Consumer ID 设置为 CalculatorApplication。这是在 WSRR 中的 Application Version 上指定的使用者标识，表示 Calculator 应用程序。 将 Context ID 设置为 CTX_1。这是在 SLA 上指定的上下文标识，表示 Calculator 应用程序与 Math Service 之间的使用协议。 使用数字字段和运算符下拉菜单输入您希望执行的计算。输入所有信息后，Calculator 应用程序看起来应类似于：
Calculator 应用程序被设置为使用 SLA 检查消息流
单击 =（等号）。Calculator应用程序将一个服务请求发送到 SLA 检查消息流，后者将该请求路由到实际的 Math Service。结果最终将返回到 Calculator 应用程序，然后会显示该结果。
如果从应用程序收到一个错误，请检查以下方面：
您已经执行了 第 1 部分：场景和配置 中的所有配置步骤。 已为消息流指定了正确的路径 (/MathServer/services/MathServer/slacheck5)。 已经指定了正确的使用者标识 (CalculatorApplication)。 已经指定了正确的上下文标识 (CTX_1)。
高级测试
为了验证消息流执行的检查是否在正常运行，需要在 WSRR 中修改相关对象的状态，然后测试对消息流行为的影响。以下各节将会介绍如何执行这些测试。
取消激活并再次激活 SLA
启动 Calculator 应用程序并执行一次计算，检查消息流是否正常工作。 在 Web 浏览器中，登录到您 WSRR 实例的 Service Registry Dashboard。 更改到 SOA Governance 视图，然后选择 Overview 页面。 在 Collection 小部件中选择 SLA - CalculatorApplication 1.0 to MathService 1.0，如下所示：
SOA Governance 视图
您将被带到 Browse 页面上，其中将在 Detail 小部件中显示 SLA - CalculatorApplication 1.0 to MathService 1.0 服务水平协议的详细信息。这是 Calculator 应用程序与 WSRR 中的 Math Service 之间的使用协议的一种表示。选择 Action => Deactivate SLA，如下所示：
取消激活 SLA
该操作完成后，将显示一个 Operation Successful
对话框。单击 OK。SLA 的治理状态已被更改为 SLA Inactive。 转到 Calculator 应用程序，尝试执行另一次计算。此时会在应用程序底部显示消息 Error:Unable to invoke math service.。 返回到 Service Registry Dashboard，选择 Action => Activate SLA 来重新激活 SLA。操作完成后单击 OK。SLA 现在的治理状态为 SLA Active。 转到 Calculator 应用程序，尝试执行另一次计算。这一次操作会成功完成。
让端点处于离线状态
启动 Calculator 应用程序并执行一次计算，检查消息流是否正常工作。 在 Web 浏览器中，登录到您 WSRR 实例的 Service Registry Dashboard。 更改到 SOA Governance 视图，然后选择 Overview 页面。 选择 Approved Business Capabilities 集合中的 MathService。 您将被带到 Browse 页面，在该页面中，将会在 Detail 小部件中显示 MathService 业务服务的详细信息。这是 WSRR 中的 Math Service的一种业务表示。在此小部件中的 Versions 下，选择 MathService (1.0)。 Detail 小部件将更新来显示 MathService (1.0) 服务版本的详细信息。这是 Math Service 在 WSRR 中的实现的一种表示形式，具体来讲就是 1.0 版。在 Detail 小部件中的 Service Level Definitions 下，选择 SLD - MathService v1.0。 更新 Detail 小部件来显示 SLD - MathService v1.0 SLD 的详细信息。在 Detail 小部件中的 Available Endpoints 下，选择http://localhost:7800/MathServer1/services/MathServer (1.0)。请注意，如果您的 IIB 实例未使用默认端口来监听 HTTP 请求，您端点的端口号可能有所不同。 更新 Detail 小部件来显示 http://localhost:7800/MathServer1/services/MathServer (1.0) 端点的详细信息。选择 Action => Revoke from use。 操作完成后单击 OK。该端点现在的治理状态为 Offline。1.0 版 Math Service 的两个端点现在都应为 Offline 状态。 转到 Calculator 应用程序，尝试执行另一次计算。此时会在应用程序底部显示消息 Error:Unable to invoke math service.。 返回到 Service Registry Dashboard 中，选择 Action => Approve For Use 将 http://localhost:7800/MathServer1/services/MathServer (1.0) 端点切换为在线状态。操作完成后单击 OK。该端点现在的治理状态为 Online。 转到 Calculator 应用程序，尝试执行另一次计算。这一次操作会成功完成。
结束语
本文介绍了一个在运行时执行 WSRR 中定义的 SLA 的示例消息流。该消息流使用了 HTTP Request 节点，使用 WSRR REST API 来执行 SLAEndpointLookup 命名的查询。这个命名查询验证服务使用者是否有权调用目标服务，通过检查来确认服务使用者拥有一个有效 SLA。然后，它返回适用于已在 WSRR 中注册的目标服务的所有在线端点。
第 5 部分：在运行时执行 SLA 检查 中提供了此业务问题的一个替代解决方案。该解决方案使用 Registry Lookup 节点从 WSRR 获取服务使用者的元数据。以下是使用 HTTP Request 节点的好处：
您能狗全面控制用于查询 WSRR 的 XPath 表达式。这使得您能够定义复杂的 XPath 表达式，用于遍历多种关系并在查询的各个阶段应用断言。因此，您通常只需在消息流中实现较少的代码来处理结果。IIB 中的 Endpoint Lookup 和 Registry Lookup 节点都不允许您控制生成的 XPath 表达式。 您能够全面控制对 WSRR 执行的查询类型。IIB 中的 Endpoint Lookup 和 Registry Lookup 节点都对 WSRR 执行图形查询，这可能会返回
大量数据，而不会在 WSRR 服务器上执行属性查询。使用 Property Query，可以仅获取执行客户端处理所需的属性，而且具有更高的性能。 可以使用 WSRR REST API 在 WSRR 中调用命名查询。这消除了客户端理解在 WSRR 中查询的数据结构的需求。客户端只需知道命名查询的名称，传递了哪些参数，以及返回了何种类型的对象。
当然，使用 HTTP Request 节点也有一些缺点：
HTTP Request 节点未在 IIB 中使用 WSRR 缓存，所以您需要实现代码来手动处理所需的任何缓存。 因为大部分验证工作都是在命名查询中定义的实际的 XPath 表达式中执行的，所以消息流无法准确知道为什么它拒绝一个请求。它仅知道命名查询未返回任何结果，不知道准确的原因。