平台中的sla组件_第5部分：在运行时和注册表查找方案中执行SLA检查

平台中的sla组件

当提供服务以在组织内重用时，服务的提供者通常会提供许多工件，服务的使用者可以使用这些工件来实现客户端应用程序或服务。 这些工件通常包括一个或多个WSDL或XML模式文档。 尽管这些工件提供了服务使用者的开发人员所需的信息，但它们并未提供有关服务使用者可以从服务中期望的非功能性或服务质量（QoS）特征的任何信息。

WSRR随附的Governance Enablement Profile（GEP）是一个完整的WSRR配置概要文件，其中包含快速建立并运行SOA治理所需的所有业务模型，生命周期，本体和治理策略。 它使服务提供商可以使用服务级别定义（SLD）捕获服务的QoS特性。 它还使服务提供商和服务使用者之间存在的协议可以使用服务级别协议（SLA）表示。

本文介绍了一个示例消息流，该消息流在运行时强制执行WSRR中定义的SLA，以确保服务使用者被授权调用目标服务。

SLA检查业务方案

本文中描述的样本流主要关注第1部分：方案和配置中描述的SLA检查方案，如下所示：

• 业务问题

  您在SOA中部署了许多服务，并且所有服务都已在WSRR中注册。 但是，您尚未在WSRR中注册这些服务的使用者。 结果，您不知道在任何给定时间点哪些服务使用者可能正在调用每个服务。 您想要确保SOA中的所有服务使用者都已在WSRR中注册，并且仅允许被授权调用目标服务的使用者进行注册。

• 解

  WSRR允许您在SOA中注册服务使用者以及服务提供商。 它还使服务提供商和服务使用者之间存在的协议或合同可以使用服务级别协议（SLA）表示。 消息流可以在运行时动态地从WSRR检索此信息，并使用它来确定服务使用者是否被授权调用目标服务。 如果服务使用者有权调用目标服务，则它可以将请求转发到约定的端点。 如果服务使用者没有被授权调用目标服务，则可以返回适当的错误。

• 好处

  这种方法使您可以控制哪些服务使用者正在调用实际的后端服务，从而使您能够在SOA中强制执行运行时治理。 另一个好处是，在服务使用者和提供者在WSRR中注册后，您可以在Service Registry Dashboard用户界面中可视化这些关系，并使用它来评估计划对服务进行的任何更改的影响。

建模服务提供商

GEP中包含的业务模型定义了代表服务提供者，服务使用者以及它们之间的协议所需的所有对象类型。 下表描述了用于对服务提供者和服务使用者进行建模的核心类型。

治理启用概要文件（GEP）中的主要对象类型

对象类型	描述
组织	在任何治理过程中，都必须拥有所有权。 组织对象体现了这种所有权。 其他所有对象都必须由组织直接或间接拥有。
业务能力	业务能力对象表示企业内所需功能的业务视图。 该对象描述了业务需求和关注点，而不是实现。 可以从通用业务角度查看该功能。 几种类型的业务能力是可能的。 例如，一个功能可以与其他功能一起使用以构建更广泛的功能。 在这种情况下，将考虑功能并将其表示为业务服务。 业务服务，业务应用程序和业务流程是业务能力的特定类型。
功能版本	功能版本是业务功能的实现。 功能版本指示如何提供业务功能，例如，它是否是Web服务，是否需要消息传递等等。 从功能版本中引用实现的各个方面，例如Web服务定义或SCA模块。 与业务功能具有特定类型的方式相同，功能版本也是如此。 例如，可以将从其他功能构建的功能或用于构建其他功能的功能视为服务版本。 服务版本，应用程序版本和流程版本都是功能版本的所有特定类型。 功能版本对象的关键方面之一是它们具有版本号。 实现相同业务功能的功能版本可能有很多版本。
服务水平定义	SLD描述了功能的非功能性或服务质量。 这些特征包括特性，例如一天中有多少小时可用，或者与该功能交互所需的安全性类型。 考虑将功能版本部署到许多不同的服务器上，为不同类型的客户或不同地区提供服务。 每个服务器可能无法提供相同的服务质量，并且需要唯一的SLD。 但是，每个使用者都以相同的方式与功能交互。
服务水平协议	如果提供了功能版本供您在企业中重用，则必须创建SLA来描述消费者与提供者之间的协议的详细信息。 SLA通常是提供功能版本的SLD提供的服务质量的子集。 例如，SLD可能声明该服务在周一至周五可用，但是SLA可能定义该服务仅在周三才需要。
服务端点	在运行时系统上部署功能版本时，它具有一个或多个可网络寻址的端点。 这些端点由服务端点表示。 服务端点对象将网络上可用的服务通知服务的使用者。
政策附件	策略指定必须满足的要求，以便客户端可以使用服务。 例如，Web服务可能要求所有消息都经过数字签名和加密，或者仅在特定时间可用。 或者它只能处理一定数量的消息。 策略对象包括策略文档，策略表达和策略附件。

中显示的示例描述了服务提供商。 它说明了WSRR对象如何相互关联。 MathService Business Service归IT部门 Organization 。 该业务服务以MathService（1.0） Service Version的形式实现了实际的实现，该Service Version已部署到三个地理位置。 每个地理位置在不同的服务器上托管服务，因此每个安装都有不同的Service Level Definition 。 每个SLD可以为Service Endpoints提供一组独特的Service Endpoints 。

建模服务提供商

服务水平定义

如前所述，服务提供商使用SLD来捕获服务的QoS特性。 更具体地说，每个SLD捕获服务的一组端点的QoS特性。 如果可以使用不同的端点来调用服务，并且这些端点展现出不同的服务质量，则应该为服务提供者定义单独的SLD，以引用相关的端点。

GEP还定义了Extended Service Level Definition类型。 扩展SLD类型定义可以为服务指定的其他QoS属性，例如“ 平均响应时间”和“ 每天最大消息数” 。 它提供了一个示例，说明如何在模型中扩展默认SLD类型以包括与您相关的QoS属性。

可用端点关系

Available Endpoints关系用于将服务的SLD与可用于调用服务的一组端点相关联。 如果有多个端点与SLD关联，则表明SLD上定义的非功能特性适用于每个端点。 以红色显示可用的端点关系。 尝试以编程方式检索可用端点关系的目标时，需要使用名称gep63_availableEndpoints引用它。

可用端点关系

建模服务消费者

在WSRR中，服务使用者的建模方式与服务提供者完全相同。 这是由于以下事实：在很多情况下，服务提供者也将成为SOA中其他服务的使用者。 但是，在设计时和运行时，一些重要的属性和关系在服务使用关系中起着核心作用。 这些将在以下各节中讨论。

消费者标识属性

功能版本属性

有关Capability Version对象的属性和关系的更多信息，请参见“ 相关主题”部分中的“ 功能版本”链接。

消费者标识符属性用于在与另一个服务提供者进行的任何交互中唯一地标识服务消费者。 服务使用者应在调用其他服务时发送的任何服务请求中包括其使用者标识符。 以下示例显示了从Calculator Application到Math Service的服务请求。 对于计算器应用程序的消费者识别符被包含在consumerID包含在SOAP头元件。

数学服务请求示例

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                     xmlns:math="http://math.pot.ibm.com">
  <soapenv:Header>
    <math:MathHeader>
      <consumerID>CalculatorApplication</consumerID>
      <contextID>CTX_1</contextID>
    </math:MathHeader>
   </soapenv:Header>
   <soapenv:Body>
      <math:add>
         <augend>1</augend>
         <addend>1</addend>
      </math:add>
   </soapenv:Body>
</soapenv:Envelope>

使用者标识符可被SOA环境中的各个组件用来确定服务使用者是否被授权调用目标服务。 前面描述的业务问题的建议解决方案是利用IBM Integration Bus中的消息流来执行此检查。 消息流需要查询WSRR以找到具有指定使用者标识的Capability Version 。 消息流将需要使用其编程属性名称gep63_consumerIdentifier引用消费者标识符。

服务水平协议关系

服务水平协议关系用于将服务使用者与其与其他服务提供者拥有的SLA相关联。 因为服务使用者可能会消费其他各种服务，所以这种关系可以有多个目标。 服务使用者也可以使用同一服务提供者拥有多个SLA。 例如，使用下图所示的方案， MathService服务的使用者可能针对目标服务在不同地理位置的每次安装都具有单独的SLA。

在本系列文章的版本1.0提供的示例数据中。 计算器应用程序的，以及每个版本的Math Service都有一个SLA，如下图所示。 服务级别协议关系以红色显示。 在处理WSRR查询结果时，消息流将需要检查服务使用者的SLA。 要找到服务水平协议关系的目标，需要使用程序名称gep63_consumes引用服务水平协议关系。

计算器应用程序SLA

服务等级协定

当服务使用者希望消费一项服务时，他们必须与服务提供商就允许他们消费多少服务的整体容量达成协议。 使用WSRR时，此信息封装在SLA中。 SLA是在形式上和数量上定义服务提供者与服务使用者之间约定的服务质量的合同。

就前面描述的核心GEP类型而言，SLA位于消费能力版本和服务提供商的SLD之间：

服务消费

当在SLA中捕获了服务提供商和服务使用者之间的协议的详细信息时，您可以在设计时和运行时使用此信息来帮助SOA中的决策过程。 在设计时如何使用此信息的一个示例是WSRR随附的Service Registry Dashboard用户界面中提供的Service Consumption Visualizer小部件。 这个小部件使您可以可视化：

1. 所有特定服务的消费者。
2. 特定服务正在使用的所有服务。
3. 服务提供商和服务使用者之间存在的协议。

当您计划对现有服务进行更改时，可以在设计时使用此信息。 它可帮助您确定可能受到计划的更改影响的所有其他服务。 下图显示了如何在“服务消耗可视化工具”小部件中显示此信息。

服务消耗可视化器

上下文标识符属性

服务水平协议属性

有关“ Service Level Agreement对象的属性和关系的更多信息，请参见“ 相关主题”部分中的“ 服务水平协议”链接。

上下文标识符属性用于在WSRR中唯一标识SLA。 在服务使用者具有多个SLA的情况下，上下文标识符可用于标识适用于给定服务请求的特定SLA。 服务使用者应在发送给特定目标服务的任何服务请求中包含相关的上下文标识符。 从计算器应用程序到Math Service的示例服务请求（如所示）在SOAP标头中包含的contextID元素中显示了相关SLA的上下文标识符。

为了找到适用于当前服务请求的SLA，消息流将需要将输入消息中指定的上下文标识符与相关服务使用者的每个SLA上的上下文标识符进行比较。 它将需要使用其程序名称gep63_contextIdentifier来引用SLA上的上下文标识符属性。

商定的端点关系

协议端点关系用于将SLA与正在使用的服务的SLD关联。 它对于服务消耗关系至关重要，因为它将代表服务使用者的对象集与代表服务提供者的对象集链接在一起。 之所以称为协议端点关系，是因为指向的SLD指定了服务使用者可以将其作为消费协议的一部分调用的一组端点。

以红色显示商定的端点关系。 为了确定将服务请求路由到的约定端点，消息流将需要找到相关SLA指向的SLD。 它将需要使用其程序名称gep63_agreedEndpoints来引用协议的端点关系。

约定的端点关系

SLA生命周期

GEP中的SLA生命周期用于管理SLA，从其最初的标识到激活直至最终不再需要时终止。 有一个活动/非活动循环，可以根据需要将其打开或关闭。 通过使其处于活动状态或非活动状态，运行时可以通过检查相关SLA是否处于正确状态来确定是否允许特定使用者调用特定端点。

SLA生命周期

为了确保相关SLA处于活动状态，消息流将需要检查其分类是否正确。 SLA生命周期中SLAActive状态的OWL URI是http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/LifecycleDefinition#SLAActive 。 下表中描述了此状态以及在SLA生命周期中定义的其他状态：

SLA生命周期

过渡	目标状态	描述
（初始状态）	已确定SLA	一旦以功能版本为代表的使用者请求依赖于提供他们所需的服务级别定义（SLD）的服务版本或其他功能版本，则将进入此状态。
要求SLA	已要求SLA	已经选择了约定的端点关系目标以及所需的SLA属性和策略的详细信息。 所选SLD的提供者必须批准，拒绝该请求或要求对其进行修改。
批准SLA请求	SLA无效	希望使用该服务的开发团队可以根据对该特定SLA的使用来继续其开发，但是他们尚未获得访问任何端点的授权。
修改SLA请求	已确定SLA	作为SLA协商的一部分，服务提供者要求服务使用者对SLA的细节进行返工。 这可以通过将SLA移回已标识的状态以准备重新提交来完成。
激活SLA	SLA有效	可以使用SLA的条款来调用与SLD相关联的所有已批准的在线端点。 在某些情况下，SLA会被停用，在这种情况下，SLA会进入SLA非活动状态，并且任何其他交互都将被阻止，直到被重新激活。
停用SLA	SLA无效	对于操作问题，可以通过将SLA移回非活动状态来暂时挂起。 消除操作问题后，可以重新激活SLA。
终止SLA	SLA已终止	不允许与此SLA进行任何交互。

消息流说明

查找消息流

本文中描述的消息流在RegistryLookup_SLACheck.msgflow文件中定义。 这包含在WSRRIntegrationDemos.zip归档文件中，该归档文件可在“可下载资源”部分中找到。

SLA检查消息流（如下图所示）使用服务请求中指定的使用者标识符来从WSRR检索服务使用者的元数据。 它使用此元数据来确定指定的服务使用者是否被授权调用目标服务。 如果服务使用者有权调用目标服务，则它将请求转发到约定的端点。 如果服务使用者无权调用目标服务，则它将返回适当的错误。 以下各节详细描述了此消息流中的每个节点，以及用于执行SLA检查的任何设置或代码。

SLA检查消息流

服务请求节点

该流程从“ Service Request SOAP输入”节点开始。 关于此节点需要注意的重要一点是，它已配置为公开Math Service的接口。 这是在节点的“ 属性”编辑器的“ 基本”选项卡上指定的，如下图所示。 您可以看到在WSDL文件名字段中指定了MathServerServiceDummyEndpoint.wsdl文件。 选择WSDL文件后，将自动填写该节点的其他基本属性。 当配置为公开特定的WSDL接口时， SOAP Input节点将验证它收到的任何服务请求，以确保它们符合WSDL中包含的服务的定义。 该节点还配置为使用HTTP传输，其URL后缀为/ MathServer / Services / MathServer / slacheck1 。 这是消费者在调用此流程公开的服务时需要使用的值。 服务请求节点使用out终端连接到SLA检查流程中的下一个节点。

公开的WSDL接口

提取SOAP Headers节点

Extract 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)
   {
        ...
}

如果服务请求中指定的标识符中的任何一个无效，则Extract SOAP Headers节点将生成SOAP错误，并将消息传递给失败终端。 该终端直接连接到SOAP Reply节点，该节点将SOAP故障传递回客户端。 此检查很重要，并且在消息流的最开始执行，因为该流需要能够识别服务使用者和适用于服务请求的相关SLA。

以编程方式覆盖节点属性

在IBM Integration Bus消息流中以编程方式覆盖WSRR节点上的属性的过程在第2部分： IBM Integration Bus中的WSRR节点中进行了描述。

通过此初始检查后，“ Extract SOAP Headers节点将相关字段插入本地环境树中，以编程方式覆盖“注册表查找”节点上的属性。 中显示的代码将注册表查找节点配置为检索具有gep63_consumerIdentifier属性的对象，该属性与SOAP标头中指定的使用者标识符匹配。 在GEP中， gep63_consumerIdentifier属性对于Capability Version抽象类型及其子类型是唯一的，因此“注册表查找”节点将仅返回该类型的对象。 然后，该节点将消息传递到out终端，该终端连接到Registry Lookup节点。

Java代码覆盖注册表查找节点变量

MbMessage environment = new MbMessage(inAssembly.getLocalEnvironment());
MbElement environmentRoot = environment.getRootElement();

environmentRoot.evaluateXPath(
    "?ServiceRegistryLookupProperties/?UserProperties/?gep63_consumerIdentifier[
    set-value('" + consumerIdElement.getValue() + "')]");

那上下文标识符呢？

“注册表查找”节点执行的查询中不需要上下文标识符，因此在此阶段无需进行任何操作。 此处执行检查的目的只是为了确保在允许将服务请求进一步传递到流程之前指定了有效的上下文标识符。 稍后将在流程的SLA Check部分中使用它。

如IBM Integration Bus中的第2部分：WSRR节点中所讨论的，要部署包含注册表查找节点的流，在定义消息流时，必须为节点上的Name ， Namespace或Version属性之一指定值。 在这种情况下，将使用Name的伪值，并且必须在使用节点之前在运行时以编程方式清除该值。 Extract SOAP Headers节点中的代码通过使用以下示例中显示的代码来完成此操作。

以编程方式清除name属性

environmentRoot.evaluateXPath("?ServiceRegistryLookupProperties/?Name[set-value('')]");

注册表查找节点

RegistryLookup节点

第2部分：IBM Integration Bus中的WSRR节点描述了IBM Integration Bus中的Registry Lookup节点。

Registry Lookup节点的行为由上一个节点在本地环境树中以编程方式创建的条目确定。 如前所述，将返回其消费者标识符与从服务请求中提取的值匹配的一个或多个Capability Version对象。 节点将所有匹配对象的表示形式插入本地环境树的ServiceRegistry条目中，然后将消息传递到out终端。

即使应该使用使用者标识符唯一标识在WSRR中注册的单个服务使用者，该节点的“ 匹配策略 ”仍设置为“ 全部” 。 指定全部 匹配策略可让SLA检查流程验证情况是否如此。

重要的是要注意，“ 深度策略”设置为“ 返回匹配项加上所有相关实体”。 （深度＝ -1） 。 指定此深度策略后 ，“ Registry Lookup节点将检索具有匹配的使用者标识符的所有Capability Version对象的表示形式，以及与下游相关的所有对象的表示形式。 这包括其SLA，这些SLA指向的任何SLD以及SLD指向的任何端点。 因为所有这些信息都是作为针对WSRR的单个查询的结果返回的，所以这允许SLA检查消息流验证服务使用者是否有权调用目标服务并将请求路由到相关端点，而无需检索其他信息。 WSRR中的元数据。

如果“ Registry Lookup节点执行的Registry Lookup返回任何结果，则该节点会将消息传递给NoMatch终端。 该端子连接到No Match Fault节点。

SLA检查节点

SLA Check节点是Java Compute节点的另一个实例，它是该消息流中大部分工作发生的节点。 该节点使用返回的元数据来检查由服务使用者和服务提供者之间是否存在有效的SLA，从而处理由先前的“ Registry Lookup节点执行的查询的结果。

如前所述，查询结果将包含具有匹配使用者标识的所有Capability Version对象的表示。 因为应该使用使用者标识符来唯一标识在WSRR中注册的单个服务使用者，所以SLA Check节点执行的第一个检查是验证仅返回了一个Capability Version 。 如果返回了多个具有匹配的使用者标识符的Capability Version ，则该节点将生成SOAP错误，并将消息传递给失败终端。 该终端直接连接到SOAP Reply节点，该节点将SOAP故障传递回客户端。 以下示例中的代码显示了正在执行的这些任务。

检查是否返回了单个服务使用者

MbElement rootElement = inAssembly.getLocalEnvironment().getRootElement();
MbElement serviceRegistry = rootElement.getFirstElementByPath("/ServiceRegistry");

List<MbElement> consumingVersions =
    (List <MbElement>)serviceRegistry.evaluateXPath("Entity");

if (consumingVersions != null && consumingVersions.size() == 1) {
    MbElement consumer = consumingVersions.get(0);
        ...
} else {        
    outAssembly = MessageUtils.createSOAPFault(inAssembly
                , "ERROR_SLA_003"
                , "Multiple CapabilityVersions found with the specified consumer id."
                , "The consumer id specified does not resolve to a unique"
                  + " CapabilityVersion in WSRR."
                );
    outputTerminal = getOutputTerminal("failure");
}

SLA Check节点需要执行的下一个任务是为服务使用者找到SLA，该使用者的上下文标识符与服务请求中指定的上下文标识符匹配。 此任务涉及几个步骤：

1. SLA Check节点需要检索服务使用者的gep63_consumes关系的所有目标。 目标将是为服务使用者定义的SLA实例，并且如中所述，可能有多个。
2. 然后，“ SLA Check节点检查SLA列表以确保其不为空。
3. 如果至少有一个SLA，则SLA Check节点将从原始服务请求中检索上下文标识符，并使用它来查找具有匹配gep63_contextIdentifer的SLA，从而验证它是否能够找到它。

检查空上下文标识符

该代码检查服务请求中的上下文标识符是否不为null。 绝对不能这样，因为已经在“ Extract SOAP Headers节点中对其进行了检查。 但是，以防万一，请再次检查。

以下示例中的代码显示了正在执行的这些任务。 每个else语句的代码块都会生成带有适当错误消息的SOAP错误，并将该消息传递给失败终端。 为简洁起见，已省略了这些块的代码。

找到指定的SLA

List<MbElement> slas = (List<MbElement>)consumer.evaluateXPath(
    "userDefinedRelationships[@name='gep63_consumes']/targetEntities/Entity"); 

if (slas != null && !slas.isEmpty()) {
    String contextId = getContextId(inMessage);
    if (contextId != null) {
        MbElement sla = getSLAByContextId(slas, contextId);
        if (sla != null) {
            ...
        } else {
            ...
        }
    } else {
        ...
    }
} else {
    ...
}

private MbElement getSLAByContextId(List<MbElement> slas, String contextId)
    throws MbException {
        
    MbElement matchingSla = null;
    for (MbElement sla : slas) {
        if ((Boolean)sla.evaluateXPath(
            "userDefinedProperties[@name='gep63_contextIdentifier']/attribute::value ='"
            + contextId + "'")) {
            
            matchingSla = sla;
            break;
        }
    }
        
    return matchingSla;
}

在为服务请求找到了相关的SLA之后， SLA Check节点执行的下一个检查将验证SLA是否处于活动状态 。 当将生命周期应用于WSRR中的对象时，WSRR将当前生命周期状态的OWL URI添加到该对象的分类列表中。 因此，要检查对象是否处于给定状态，您只需要查看该对象是否已使用该状态的相关OWL URI进行分类。 以下示例中的代码显示了正在执行的这些任务。 如果SLA不在活动状态，则会生成带有适当错误消息的SOAP错误，并将其传递给故障终端。

检查SLA是否处于活动状态

protected static final String OWL_URL_SLA_ACTIVE = 
    "http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/LifecycleDefinition#"
    + "SLAActive";

if (isActive(sla)) {
} else {
    ...
}

private boolean isActive(MbElement sla) throws MbException {
    return (Boolean)sla.evaluateXPath("classificationURIs='" + OWL_URL_SLA_ACTIVE + "'");
}

确定SLA是活动的之后 ，下一个任务是检索服务使用者在调用服务时被授权使用的端点列表。 如前所述，要从SLA导航到协议端点列​​表，您需要遍历两个关系，如下所示：

1. 将SLA与正在使用的服务的SLD关联的商定端点关系。 回想一下，此关系的程序名称为gep63_agreedEndpoints 。
2. 可用端点关系将服务提供商的SLD与可用于调用服务的一组端点相关联。 回想一下，此关系的程序名称为gep63_availableEndpoints 。

幸运的是，由于所有这些信息都是从WSRR中检索的，因此您可以使用单个XPath表达式遍历这两个关系。 以下示例显示了导航这些关系所需的代码。 如果未返回任何端点，则会生成带有适当错误消息的SOAP错误，并将其传递给失败终端。

检索可用端点

List<MbElement> availableEndpoints = (List<MbElement>)sla.evaluateXPath(
    "userDefinedRelationships[@name='gep63_agreedEndpoints']/targetEntities/Entity/"
    + "userDefinedRelationships[@name='gep63_availableEndpoints']/targetEntities/Entity");
    
if (availableEndpoints != null && !availableEndpoints.isEmpty()) {
    ...
} else {
    ...
}

下一个要执行的任务是从处于联机状态的列表中选择第一个端点。 同样，这是通过检查是否为此状态用相关的OWL URI对端点进行分类来实现的。 显示选择第一个在线端点所需的代码。 如果WSRR中当前没有任何可用端点处于联机状态，则会生成带有适当错误消息的SOAP错误，并将其传递给故障终端。

选择在线端点

protected static final String OWL_URL_ONLINE =
    "http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/LifecycleDefinition#"
    + "Online";

String addressUrl = selectEndpoint(availableEndpoints, inAssembly);
if (addressUrl != null) {
    ...
} else {
    ...
}

protected boolean isOnline(MbElement endpoint) throws MbException {
    return (Boolean)endpoint.evaluateXPath("classificationURIs='" + OWL_URL_ONLINE + "'");
}
    
public String selectEndpoint(List<MbElement> availableEndpoints, MbMessageAssembly 
inAssembly) throws MbException {
        
    String addressUrl = null;
        
    for (MbElement availableEndpoint : availableEndpoints) {
        if (isOnline(availableEndpoint)) {
            addressUrl = (String)availableEndpoint.evaluateXPath(
                "string(userDefinedRelationships[@name='sm63_soapAddress']"
                + "/targetEntities/Entity/attribute::location)");
            break;
        }
    }
        
    return addressUrl;
}

现在，SLA Check消息流已验证在服务使用者和服务提供者之间存在活动的 SLA，并且在WSRR中为目标服务注册了至少一个在线端点。 消息流现在可以将服务请求转发到目标服务。 为此，SLA检查消息流使用称为Forward Request的SOAP Request节点。 要以编程方式覆盖在“ Forward Request节点上配置的Web服务URL ，“ SLA Check节点需要将端点地址插入本地环境树的Destination.SOAP.Request.Transport.HTTP.WebServiceURL字段中。 显示执行此任务所需的代码。 然后， SLA Check节点将消息传递到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 + "')]");

转发请求和SOAP回复节点

Forward Request节点负责调用目标服务，在本例中为Math Service的 1.0版 。 定义流时，即使在运行时SLA Check节点会以编程方式覆盖该值，也必须在此节点上为Web Service URL属性指定一个值。 结果，为此属性指定了伪值http://tempuri.org/MathServer/services/MathServer 。 要注意的另一个重要点是，必须将节点的“ 操作模式 ”设置为“ 调用通用Web服务” 。 这是在节点的属性编辑器的“ 基本”选项卡上指定的。 它使流程可以代理对数学服务上定义的任何操作的请求，而不必强制代理单个操作。 Forward Request节点使用其所有终端直接连接到SOAP Reply节点。 出 ， 错和失败 。

“ SOAP请求和SOAP回复节点

SOAP Reply节点只是将SOAP响应传递回服务使用者。 在成功通过该流程时，返回的响应将是来自实际目标服务的响应。 如果发生错误，则响应将是由流中的Java Compute节点之一或目标服务本身生成的SOAP错误。

无匹配故障节点

当“ 提取SOAP头”或“ SLA检查 Java计算”节点中的任何一个发生错误时，这些节点将以编程方式生成适当的SOAP错误，并将该错误传递给其故障终端。 这些直接连接到SOAP Reply节点。 但是，当“ Registry Lookup节点执行的Registry Lookup未返回任何结果时，它不会自动生成SOAP错误。 为此，将Registry Lookup节点的NoMatch终端连接到No Match Fault Java Compute节点。 该节点以编程方式生成SOAP错误，并使用SOAP Reply节点将其返回给服务使用者。

测试消息流

基本配置

在尝试测试消息流之前，请确保已经执行了第1部分：场景和配置中描述的所有配置步骤。

这些步骤描述了如何使用计算器应用程序来验证SLA Check流程是否正常运行。

基本测试

1. 确保您的IBM Integration Bus执行组正在运行，并且已部署并启动RegistryLookup_SLACheck流。
2. 如第1部分中的运行计算器应用程序中所述， 启动计算器应用程序 。
3. 输入运行IIB的服务器的主机名和端口号值。 例如，如果您在与Calculator应用程序相同的机器上运行IBM Integration Bus，并且使用缺省端口，则这些值将为localhost和7800 。
4. 修改服务的路径，将其值设置为/ MathServer / services / MathServer / slacheck1 。 这是RegistryLookup_SLACheck流的端点。
5. 将使用者ID设置为CalculatorApplication 。 这是在代表计算器应用程序的WSRR中的“ Application Version上指定的使用者标识符。
6. 将上下文ID设置为CTX_1 。 这是在SLA上指定的上下文标识符，它表示Calculator应用程序和Math Service之间的使用协议。
7. 使用数字字段和运算符下拉菜单输入您要执行的计算。 输入所有信息后， Calculator应用程序应类似于此：

   设置计算器应用程序以使用SLA检查消息流

   
8. 单击= （等于按钮）。 计算器应用程序将向SLA检查消息流发送服务请求，该服务请求会将请求路由到实际的Math Service 。 结果最终返回到计算器应用程序，然后显示。

如果您收到来自应用程序的错误，请检查以下内容：

1. 您已经执行了第1部分：场景和配置中的所有配置步骤。
2. 您已为流指定了正确的路径（ / MathServer / services / MathServer / slacheck1 ）。
3. 您指定了正确的使用者标识符（ CalculatorApplication ）。
4. 您指定了正确的上下文标识符（ CTX_1 ）。

进阶考试

To verify that the checks performed by the message flow are working correctly, you need to modify the state of the relevant objects in WSRR and then test the effect on the behaviour of the flow. The sections that follow describe the how to perform these tests.

Deactivating and reactivating the SLA

1. Start the Calculator application and perform a calculation to check that the message flow is working correctly.
2. 在Web浏览器中，登录到WSRR实例的Service Registry Dashboard 。
3. 切换到SOA治理视图，然后选择Overview页面。
4. Select SLA - CalculatorApplication 1.0 to MathService 1.0 in the Collection widget:

   SOA治理视图

   
5. 您将被带到“ 浏览”页面，该页面将在“ 细节”小部件中显示SLA-CalculatorApplication 1.0到MathService 1.0服务级别协议的详细信息 。 这表示WSRR中Calculator应用程序和Math Service之间的使用协议。 Select Action => Deactivate SLA :

   Deactivating the SLA

   
6. When the operation has completed an Operation Successful dialog will be displayed. 单击确定 。 The governance state of the SLA has changed to SLA Inactive .
7. Go to the Calculator application, and try to perform another calculation. The message Error: Unable to invoke math service. is displayed at the bottom of the application.
8. Back in the Service Registry Dashboard , reactivate the SLA by selecting Action => Activate SLA . After the operation is completed, click OK . The SLA now has a governance state of SLA Active .
9. Go to the Calculator application, and try to perform another calculation. This time the operation succeeds.

Taking the endpoints offline

1. Start the Calculator application and perform a calculation to check that the message flow is working correctly.
2. 在Web浏览器中，登录到WSRR实例的Service Registry Dashboard 。
3. 切换到SOA治理视图，然后选择Overview页面。
4. Select the MathService in the Approved Business Capabilities collection.
5. You will taken to the Browse page, which will display the details of the MathService business service in the Detail widget. This is a business representation of the Math Service in WSRR. In this widget, under Versions , select MathService ‪(1.0) .
6. The Detail widget will be updated to display the details of the MathService (1.0) service version. This is a representation of an implementation of the Math Service in WSRR, specifically version 1.0. In the Detail widget, under Service Level Definitions select SLD - MathService v1.0 .
7. 详细信息小部件将被更新以显示SLD-MathService v1.0 SLD的详细信息。 In the Detail widget, under Available Endpoints select http://localhost:7800/MathServer1/services/MathServer ‪(1.0) . The port number for your endpoint may be different if your IBM Integration Bus instance is not using the default port to listen for HTTP requests.
8. The Detail widget will be updated to display the details of the http://localhost:7800/MathServer1/services/MathServer ‪(1.0) endpoint. Select Action => Revoke from use .
9. After the operation has completed, click OK . The endpoint now has a governance state of Offline . Both of the endpoints for the version 1.0 of the Math Service should now be Offline .
10. Go to the Calculator application, and try to perform another calculation. The message Error: Unable to invoke math service. is displayed at the bottom of the application.
11. Back in the Service Registry Dashboard , switch the http://localhost:7800/MathServer1/services/MathServer ‪(1.0) endpoint back online by selecting Action => Approve For Use . After the operation is completed, click OK . 现在，端点的治理状态为Online 。
12. Go to the Calculator application, and try to perform another calculation. This time the operation succeeds.

结论

This article described an example message flow that enforces SLAs defined in WSRR at runtime. The message flow uses the Registry Lookup node to retrieve the metadata for the service consumer. It then uses this metadata to verify that the service consumer is authorized to invoke the target service by checking that it has an active SLA with the service provider and that the target service has at least one online endpoint registered in WSRR.

An alternative solution to this business problem is presented in Part 8: SLA checking using the HTTP Request node . That solution makes use of the HTTP Request node to execute the SLAEndpointLookup named query using the WSRR REST API. This named query verifies that the service consumer is authorized to invoke the target service by checking that it has an active SLA with the service provider. It then returns any online endpoints for the target service that are registered in WSRR.

The benefits of using the Registry Lookup node are:

• It provides specific support for querying WSRR out-of-the-box in IBM Integration Bus and does not necessarily require any additional coding in a compute node before the node is invoked.
• It makes use of the WSRR Cache in IBM Integration Bus automatically without the need for further coding.
• All of the validation can be performed in the actual message flow based on the metadata that was retrieved. As a result, the message flow can be very precise about exactly why it is rejecting a request, returning a suitable error message in a SOAP fault.

Of course, using the Registry Lookup node has some drawbacks:

• You do not have much control over the XPath expression that is generated by the node. As a result, it is not possible to generate XPath expressions that traverse multiple relationships and apply predicates at various stages in the query. This forces you either to perform a query against WSRR to a greater depth than you might like, or to perform multiple queries against WSRR in a single flow.
• You are unable to control the type of query that is performed against WSRR. Both the Endpoint Lookup and Registry Lookup nodes in IBM Integration Bus perform Graph Queries against WSRR, which can potentially return a large amount of data and do not perform as well as Property Queries on the WSRR server.

致谢

The author would like to thank the following people for all of their help with the development of the sample messages flows in this series:

• 约翰·霍西
• 本汤普森
• 马特·高比·柯克
• 特雷弗·杜比（Trevor Dolby）
• 安德烈亚斯·马滕斯（Andreas Martens）
• 格雷厄姆·哈克斯比（Graham Haxby）
• 安德鲁·科尔曼
• 约翰·里夫

The author would also like to thank the following people for their help with reviewing this article:

• 戴维·西格
• 阿尔诺·德斯普雷特
• 安娜·麦克西科维奇（Anna Maciejkowicz）

---

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/1404_smithson5/1404_smithson5.html

平台中的sla组件