使用 WebSphere DataPower 实施服务水平协议,第 1 部分:应用 SLA 控制文件模式

本系列文章由两部分组成,第一部分的文章将展示如何利用 IBM® WebSphere® DataPower® XI50 SOA Appliance、WebSphere Service Registry and Repository 以及 IBM® Tivoli Composite Application Manager for SOA 治理、实施和监控常用策略。本文将重点介绍使用 XML 控制文件实施服务水平协议业务和运营策略。

Mario E. De Armas, 软件架构师, IBM

Mario De Armas 的照片Mario De Armas 是 WebSphere DataPower Appliance 开发团队的一名软件架构师,参与过 DataPower 设备的多个领域、多种特性的相关工作。他目前领导着 DataPower 的 WebSphere Service Registry and Repository 集成、Web 服务、WS-Policy 和 SOA 治理功能的支持工作。他过去参与过的 DataPower 项目包括 Technical Lead for XB60、AS1 协议处理程序、B2B 网关、应用程序管理功能、数据库集成和用户界面自定义特性。



Joel Gauci, IT 专家, IBM

Joel Gauci 的照片Joel Gauci 是法国 WebSphere Software 组的一名客户技术专家。他最初参与的是一批面向欧洲移动通信业领先企业的 WebSphere DataPower SOA 项目,自 2008 年起加入软件组。Joel 目前主要从事 DataPower 销售商机方面的工作,为潜在客户提供从基本演示到复杂架构定义的协助。他编写了多份与 DataPower SOA 设备相关的 IBM Redpaper 和 IBM Redbook。



2012 年 6 月 18 日

简介

本系列文章由两部分组成,第一部分的文章将介绍可以实施用于治理、实施和监控业务服务组合的使用解决方案模式。这种解决方案的基础是使用服务水平协议 (SLA) 控制文件及 IBM WebSphere DataPower SOA 设备(例如 XI50、XI52、XB60、XB62、XG45 等),以下简称为 “设备”。

本文将演示可以使用这种解决方案的框架管理的多种类型的业务服务策略,以及您能多么轻松地将这些策略与服务消费者和服务提供商相关联,从而实施各种策略。文中还将详述一种简单的策略注册和绑定解决方案(基于 XML SLA 控制文件),以及一个能够管理一种服务的多个版本、其相关 SLA 策略、端点路由以及任何数据调节(根据需要)的策略实施点(设备)。

您可以将这种解决方案模式应用于设备必须代理和保护的任何类型的服务:XML、REST 或 Web 服务 (SOAP)。因此,本文将介绍利用得到广泛应用的 DataPower 服务网关来配置该解决方案的一种方法:多协议网关和 Web 服务代理。

图 1 展示了该解决方案模式的不同组件。

图 1. SLA 策略实施解决方案的组件
SLA 策略实施解决方案的组件

本系列的第二部分将为这种解决方案模式引入 WebSphere Service Registry and Repository (WSRR),并介绍如何使用注册库中的对象和元数据来取代 SLA 控制文件。第二种方法能够提供对 SLA 策略的更佳集成化 SOA 治理与管理,以及对企业级策略的更好采用和重用。

最后,在 下载 部分中,您可以下载一个实施了该解决方案模式的 DataPower XI50/XI52 设备、一个用于测试的样例应用程序以及其他任何相关文件。

本文中介绍的 DataPower 服务(包括 EchoService 在内)可使用 zip 存档文件 SLAEnforcement_Part1_DataPower_Config_Export.zip 导入 DataPower 设备。

本文中的其他 XML 文件可以在 SLAEnforcement_Part1_ReferenceMaterial.zip zip 存档中找到。该存档包含以下文件:

  • XSD 架构文件。此外也提供了 SLA 控制文件的 XSD 架构:ibm.devworks.GWParams.xsd.
  • DataPower 服务上发布的请求文件。
  • 在网关上使用或者用于演示本文示例的 SLA 控制文件。
  • 用于数据调节的 XSL 样式表:

    ibm.devworks.productTransform.xsl。

  • 错误参数文件 (ibm.devworks.error.xml):可以将这个文件上传到包含服务网关的 DataPower 域的本地文件。它定义了发生错误时返回给 HTTP 客户端的自定义错误代码和消息。

SLA、SLD 和 SLM 策略

首先,您必须定义构建 SOA 策略解决方案时使用的通用术语。这一节将介绍处理业务服务策略和业务服务治理时常用的一些术语。其中最重要的术语包括:

  • 服务水平协议 (SLA)
  • 服务水平定义 (SLD)
  • DataPower 配置工件(例如服务水平管理策略)

什么是服务水平协议?

服务水平协议 (SLA) 就是双方之间经过协商、正式定义的协议,其中一方是(服务)消费者,另外一方是(服务)提供商。

它记录了双方对于一份协议的以下领域的共识:

  • 服务
  • 优先级
  • 责任
  • 保证
  • 担保

SLA 管理流程包括以下活动:

  • SLA 合同定义(带有服务质量参数的基本架构)
  • SLA 协商
  • SLA 实施,以已经定义的策略和指标作为依据
  • SLA 监控

SLA 的概念对于 DataPower 极为重要,因为 SOA 设备通常用作 SOA 解决方案中的策略实施点 (PEP)。

目前尚无在 SOA 组件(例如,策略管理点和策略实施点)内表示 SLA 协议的业界标准。因此,自定义解决方案得到了普遍利用,此类解决方案不可在服务网关间迁移。

什么是服务水平定义?

服务水平定义 (SLD) 定义了一个提供商在遵从其所有者为了保护服务端点而定义的条件的前提下,交付服务的能力。.

SLD 并非双方协商得出,由服务提供商的所有者单方定义。服务提供商需负责交付满足 SLD 中定义的所有条款和条件的服务水平。DataPower 执行 SLD 策略要求的实施,并且充当后端服务端点的保护者。

SLD 管理流程包括以下活动:

  • SLD 定义(服务水平和服务定义、安全性等)
  • 根据已经定义的策略进行 SLD 实施
  • SLD 监控

什么是服务水平管理策略?

服务水平管理 (SLM) 策略是一种 DataPower 配置工件,您可以对其进行配置,以便实施 SLA 或 SLD 策略需求。这种 DataPower 配置策略仅基于 DataPower 配置属性细节,通常由负责将 SLA 和 SLD 策略需求转化为 DataPower 中的操作配置的策略开发人员制定。


提议的解决方案模式:一个服务网关 SLA 控制文件

这一节讨论了提议的解决方案模式,其中使用一个服务网关 SLA 控制文件描述服务及其相关 SLA 和 SLD 策略细节。为了简便起见,我们将这个 XML 参数化文件称为 “SLA 控制文件”,但是它的实际用途是同时实施 SLA 和 SLD 策略。

为什么要使用这样一个文件?

很多时候,服务部署者都无法使用企业策略管理产品(例如 IBM WebSphere Registry and Repository),而该产品可能集中治理服务策略(例如 SLA 和 SLD),并将其部署到策略实施产品(例如 IBM DataPower 设备)。因此,您必须采用一种更加适合局部需求、切实可行的解决方案,在实施 SLA 与 SLD 业务需求时保证在策略管理与策略敏捷性之间达到合理的平衡。

XML 控制文件方法可以作为 “易于部署的” 的解决方案,其中包含基于易更新的文件的模式和管理流程。控制文件可以快速、便捷地描述以下服务和 SLA 属性与关系:

  • 服务(用作顶级服务注册库)
  • 服务版本(用于版本调节)
  • 服务端点(用于动态路由)
  • 与一个消费者相关的 SLA(用于 SLM 策略实施)
  • 与一个提供商相关的 SLD(用于 SLM 策略实施)
  • 架构 URL(用于消息数据验证)
  • 转换(用于消息内容转译或者服务门户解决方案要求的其他任何可能出现的自定义策略实施活动)

利用这种控制文件能够做些什么?

您可以使用控制文件来执行特定服务网关解决方案需要的任何操作。在本文提供的解决方案中,我们选择了将 DataPower 作为策略实施点时最常见的操作,例如:

  • SLA Check Enforcement:这项操作包括验证消费者与提供商之间存在 SLA(合同)。
  • SLA SLM Enforcement:该文件包含在 DataPower 设备上配置、在消费者与服务提供商之间的关系中使用的 SLA SLM 策略的名称。
  • SLD SLM Enforcemen5:该文件包含在 DataPower 上配置、在一个服务版本与一个端点之间的关系中使用的 SLD SLM 策略的名称。
  • SLD Routing Enforcement:该文件包含一个服务的不同版本的端点 URL。
  • SLD Validation Enforcement:为各服务端点提供架构的 URL。

针对不同的实施活动要求,可以对所提供的解决方案控制文件和配置加以扩展,使其包含更多实施支持。

SLA 控制文件的结构和部分

SLA 控制文件是一种能够迅速实现的简单、健壮、高效的解决方案。它并非用于取代合理、正式的注册库解决方案(例如 WebSphere Service Registry and Repository),但确实可以作为采用 SOA 治理最佳实践的第一步。

SLA 控制文件中使用的 XML 语法采用 WSSR Governance Enablement Profile (GEP) 中定义的术语。选择这种语法的目的在于简化未来可能需要的从 SLA 控制文件到 WSRR GEP 运行时治理的迁移。

图 2 展示了 SLA 控制文件的语法结构。

图 2. SLA 控制文件:XML 架构
SLA 控制文件:XML 架构

SLA 控制文件包含一个服务目录 (/BusinessServices),可使用域和版本信息限定它。服务目录中包含多项服务 (/BusinessServices/BusinessService)。每一项业务服务(通过惟一的名称标识)都支持一个或多个服务版本 (ServiceVersion)。

每个服务版本都使用惟一的 URI 标识。各服务版本均包含一个 SLD 以及任意数量的 SLA。SLD 定义了服务端点 (EndPoint) 和用于保护后端服务器的特定 SLM 策略。服务端点必须包含必要的 URL,其他元素则是可选的。

表 1 展示了 SLA 控制文件各元素的具体信息。

表 1. SLA 控制文件的元素
元素描述
/BusinessServices 必须实施 SLA 和 SLD 的业务服务的目录。
/BusinessServices
/@domain
应用 SLA 控制文件的 DataPower 域。
/BusinessServices
/@version
文件的当前版本或其创建日期。
/BusinessServices
/BusinessService
一个业务服务实例。
/BusinessServices
/BusinessService
/@name
一个业务服务的名称(标识符)。
/BusinessServices
/BusinessService
/ServiceVersion
一个特定业务服务版本的实例。
/BusinessServices
/BusinessService
/ServiceVersion
/@uri
服务版本 URI。每个服务版本都必须具有惟一的 URI。
/BusinessServices
/BusinessService
/ServiceVersion
/SLAs
在业务服务被请求时必须实施的 SLA 的无限制列表。
/BusinessServices
/BusinessService
/ServiceVersion
/SLAs
/SLA
一个 SLA 实例的声明。
/BusinessServices
/BusinessService
/ServiceVersion/SLAs
/SLA
/@consumerId
与 SLA 相关的消费者的标识符。该值为必须提供的值。
/BusinessServices
/BusinessService
/ServiceVersion
/SLAs
/SLA
/@contextId
与 SLA 相关的上下文的标识符。该值是可选的。
/BusinessServices
/BusinessService
/ServiceVersion
/SLAs
/SLA
/Policy
必须对特定消费者实施的 SLA SLM 策略的名称。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
必须对服务版本实施的 SLD 实例的声明。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/Policy
在服务版本被请求时必须实施的 SLD SLM 策略的名称。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
服务版本端点的声明。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/URL
服务版本后端的端点 URL。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Request
这个可选的元素用于定义可在事务请求处理过程中应用的附加处理。附加处理活动包括验证和转换,但解决方案实现本身也可扩展为支持更多活动。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Request
/InputSchemaURL
这个可选的元素引用一个架构或 WSDL 文件(对于 SOAP 消息验证),用于在请求处理过程中验证传入的消息。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///schema.xsd)。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Request
/XForm
这个可选的元素引用一个 XSLT 样式表,用于执行转换(用于请求处理过程中的传入消息转译或其他任何应用程序)。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///xform.xsl)。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Request
/OutputSchemaURL
这个可选的元素引用一个架构或 WSDL 文件(对于 SOAP 消息验证),用于在请求处理过程中验证外发的消息。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///schema.xsd)。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Response
这个可选的元素用于定义可在响应处理过程中应用的附加活动,例如消息验证和转换。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Response
/InputSchemaURL
这个可选的元素引用一个架构或 WSDL 文件(对于 SOAP 消息验证),用于在响应处理过程中验证传入的消息。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///schema.xsd)。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Response
/XForm
这个可选的元素引用一个 XSLT 样式表,用于执行转换(用于响应处理过程中的传入消息转译或其他任何应用程序)。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///xform.xsd)。
/BusinessServices
/BusinessService
/ServiceVersion
/SLD
/EndPoint
/Response
/OutputSchemaURL
这个可选的元素引用一个架构或 WSDL 文件(对于 SOAP 消息验证),用于在响应处理过程中验证外发的消息。如果文件是 /BusinessServices/@domain 中指定的 DataPower 域中的本地文件,则使用 local:/// 前缀(例如 local:///schema.xsd)。

您可以将输入和输出架构与转换应用于请求和响应。

可以向服务版本附加一组 SLA,以便将消费者与特定的服务版本相关联。每个 SLA 实例都代表一个特定的消费者。可以为每个 SLA 实例定义一项 SLA SLM 策略,从而为特定的一对消费者和供应商实施相应的策略。

必需的 "contextId" 和可选的 "consumerId" 属性是在 SLA 级别上定义的,可以惟一地标识一个服务版本实例中的特定 SLA。可以重用相同的上下文和消费者 ID 来访问相同服务的不同版本。

SLA 控制文件及其组件是针对特定的域(使用 <BusinessServices> 元素的 @domain 属性)和特定的版本(使用 <BusinessServices> 元素的 @version 属性)而定义的。

图 3 展示了一个 SLA 控制文件的示例,图中显示了相同业务服务 (MathServer) 的两个服务版本(XML 和 SOAP),其中:

  • XML 服务 @uri 是 /xml/mathserver
  • SOAP 服务 @uri 是 /mathserver
图 3. SLA 控制文件部分
SLA 控制文件部分

SLA 控制文件的处理

可以通过自定义 XSL 样式表来使用 SLA 控制文件,并在 DataPower 服务的请求和响应处理规则中执行它。document() 函数用于访问一个 XML 文档(XML 网关控制文件)中的节点,此文档必须是格式良好且有效的。

下面的图 4 中展示的算法描述了这些自定义模板的逻辑(消费者标识符和客户端 URI 作为输入数据)。

图 4. SLA 控制文件的处理
SLA 控制文件的处理

SLA 控制文件示例应用程序

这一节展示了在不同场景中使用 SLA 控制文件的一些示例。

图 5 展示了可使用 SLA 控制文件创建的各种不同的节点。

图 5. 多个服务版本的示例
多个服务版本的示例

可选节点包括:

  • Request
  • Response
  • InputSchema
  • OutputSchema
  • XForm

示例 1. 一个业务服务,一个服务版本

在第一个示例中,可以看到如图 6 所示的 SLA 控制文件的组件,其中包含与一个业务服务 (MathServer) 相关的数据,并且仅有该服务的一个版本 (/services/MathServer/V1)。

图 6. 示例 1 - SLA 控制文件
示例 1 - SLA 控制文件

该服务的名称为 "MathServer",其服务版本 URI 是 "/services/MathServer/V1"。

有两个消费者可以使用此服务。其消费者标识符为:

  • APPLICATION1,具有通过一个特定 SLA 定义的银牌合同
  • APPLICATION2,具有通过一个特定 SLA 定义的金牌合同

服务的端点是 "http://demoserver:9080/services/MathServer/V1"。

该业务服务的端点级别上没有定义架构和转换。

这个服务控制文件对 DataPower 请求处理规则执行以下操作:

  • SLA 检查
  • SLA SLM 实施
  • SLD SLM 实施
  • SLD 路由

可以在 SLAEnforcement_Part1_ReferenceMaterial.zip 存档中找到与示例 1 有关的 SLA 控制文件:ibm.devworks.GWParams_One-Service-Version_1.0.xml

示例 2. 一个业务服务,两个服务版本

在第二个示例中,SLA 控制文件包含与一个业务服务相关的数据,并且该服务具有两个版本,如图 7 所示。

图 7. 示例 2 - SLA 控制文件
示例 2 - SLA 控制文件

版本 V1 中的服务可通过 URI "/services/MathServer/V1" 进行访问,而版本 V2 中的服务可通过 URI "/services/MathServer/V2" 进行访问。

各服务版本均有自己的端点和 SLD(版本 V1 中的服务为 SLD1、版本 V2 中的服务为 SLD2),可以使用 “MathServer” 业务服务的两个版本的消费者不尽相同:

  • APPLICATION1 使用版本 V1,且具有在 SLA 铜牌中定义的服务水平。
  • APPLICATION3 使用版本 V2,且具有在 SLA 银牌中定义的服务水平。
  • APPLICATION4 使用版本 V2,且具有在 SLA 金牌中定义的服务水平。

该业务服务的两个端点级别上均没有定义架构和转换。

这个服务控制文件对 DataPower 请求处理规则执行以下任务:

  • SLA 检查
  • SLA SLM 实施
  • SLD SLM 实施
  • SLD 路由 示例 3:一个业务服务,两个服务版本(版本控制用例,后端共享,必须调节数据格式)

可以在 SLAEnforcement_Part1_ReferenceMaterial.zip 存档中找到与示例 2 有关的 SLA 控制文件:ibm.devworks.GWParams_Two-Service-Versions_1.0.xml

可以使用 SLA 控制文件来实现一种服务策略解决方案,在有一个服务支持的不同数据版本之间进行调节,并在数据转译步骤开始之前和完成之后验证请求和响应消息。

图 8. 示例 3 - SLA 控制文件
示例 3 - SLA 控制文件

在图 8 中,版本 V1 中的服务可通过 URI "/services/MathServer/V1" 进行访问,而版本 V2 中的服务可通过 URI "/services/MathServer/V2" 进行访问。

由于两个服务版本将访问相同的服务端点,因此 SLD1 和 SLD2 必须完全相同。这就意味着 SLD1 和 SLD2 代表相同的 DataPower SLM 策略。

如果通过服务版本 “V1” 访问 MathServer 服务,网关必须在请求处理过程中执行消息内容调整,将版本 “V1” 格式的消息转为版本 “V2” 格式的消息。因此,请求级别上定义了转换 (Xform1-2),用于完成这样的调整。

在消息转换之前,将对消息版本 “V1” 进行验证。转换完成之后,也会在将消息版本 “V2” 的消息发送至后端应用程序之前验证该消息。

处理响应时也定义了相同的调整(从版本 “V2” 到版本 “V1”),并且在响应处理过程中执行转换前后验证消息。

如果通过服务版本 “V2” 访问 MathServer 服务,则在处理请求和响应时将定义并执行验证消息。

这个服务控制文件对 DataPower 请求处理规则执行以下任务:

  • SLA 检查
  • SLA SLM 实施
  • SLD SLM 实施
  • SLD 路由
  • SLD 消息验证(输入)
  • SLD 消息转换(如有必要)
  • SLD 消息验证(输出)

DataPower 响应处理规则:

  • SLD 消息验证(输入)
  • SLD 消息转换(如有必要)
  • SLD 消息验证(输出)

可以在 SLAEnforcement_Part1_ReferenceMaterial.zip 存档中找到与示例 3 有关的 SLA 控制文件:ibm.devworks.GWParams_Service-Versioning_1.0.xml

将 SLA 控制文件上传到 DataPower 设备

这一节讨论了将 SLA 控制文件上传到 DataPower 设备的各种可行方法,以及如何刷新特定域中与此文件相关的 XML 文档缓存。

这一步非常重要,因为原始 SLA 控制文件必须脱离设备进行管理。修改这个文件时,必须将其上传到各种设备。

在每次上传或者更新了 SLA 控制文件之后,必须刷新文档缓存,因为旧版本可能已被缓存,并会在下次事务处理过程中重新进入缓存。

下面给出了将 XML 文件上传到设备中并刷新 XML 文档缓存的几种方法:

  1. 手动上传、手动刷新缓存。
  2. 利用 SOAP 管理 (SOMA) API,通过 DataPower SOA 设备的 XML 管理接口上传文件并刷新缓存。
  3. 利用打包为脚本的命令行接口 (CLI) 上传文件并刷新缓存。

清单 1 和清单 2 给出了用于将文件上传到 DataPower 设备并使用相同方法刷新文档缓存的 SOMA 请求消息示例。

清单 1. 用于上传文件的示例 SOMA 调用
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Body>
		<dp:request domain="someBank-Sample" xmlns:dp="http://www.datapower.com/
          schemas/management">
			<dp:set-file name="local:///Testfile">
				Base64_encoded_File
			</dp:set-file>
		</dp:request>
	</soapenv:Body>
</soapenv:Envelope>
清单 2. 用于刷新 XML 文档缓存的示例 SOMA 调用
 <?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
	<env:Body>
		<dp:request domain="someBank-Sample"
xmlns:dp="http://www.datapower.com/schemas/management">
			<dp:do-action>
				<FlushDocumentCache>
					<XMLManager>someBankXML</XMLManager>
				</FlushDocumentCache>
			</dp:do-action>
		</dp:request>
	</env:Body>
</env:Envelope>

请注意,在本例中,我们通过设备的默认域访问的 XML 管理接口必须已经处于启用状态,并且必须支持 SOMA 格式。


创建 SLA 控制文件内引用的 SLM 策略(SLA 和 SLD)

可以同时在一个 SLA 控制文件中使用 SLA 和 SLD 策略,方法有三种:

  1. 手动创建:手动创建 SLM 策略。在这种情况下,相同域中定义的每一条 SLM 策略都必须具有惟一的名称。
  2. 脱机创建流程:SLM 策略是在 SLA 控制文件上传的过程中创建的。这要求实现特定的服务(例如 XML 防火墙),解析 SLA 控制文件,以便检索不同 SLA 和 SLD 的名称,并且配置这些策略。这些 SLA 和 SLD 策略的名称中必须包含必要的信息,这些信息将用于创建 DataPower SLM 策略。

    例如,SLA 策略 "SLA_5MessagesPer10Seconds_Throttle" 包含创建正确的 SLM 策略的信息:

    • SLA:此信息表明 SLM 策略将按消费者实施,而 SLD 策略则并非如此。
    • 5 Messages Per 10 Seconds:此信息定义了阈值(5)、时间间隔阈值(10 秒钟)和阈值类型(移动)。
    • Throttle:此信息定义了 SLM 操作(限制),此操作将在达到阈值时执行。

    图 9 和图 10 展示了 SLM 策略主要配置与语句的细节。

    图 9. SLM 策略配置
    SLM 策略配置
    图 10. SLM 语句定义
    SLM 语句定义
  3. 联机创建流程:在实施 SLA 和 SLD 之前,根据需要创建 SLM 策略。在这种情况下,有必要在创建和使用 SLM 策略之前动态测试 SLM 策略是否存在。SLA 控制文件中使用的 SLM 策略名称必须包含必要的信息,如上面的第 2 步所述。

在需要执行大量 SLM 策略实现时,为了避免配置错误,必须同时使用脱机和联机创建流程。您还可以利用这些流程来检查 SLA 控制文件中可以引用的文件存在与否(XSD 架构、XSL 样式表),

本文中采用手动创建 SLA 策略和 SLD SLM 策略的方法。SLM 策略的脱机和联机创建流程不在本文讨论范围之内。


使用 SLA 控制文件及 DataPower 托管服务

SLA 控制文件用于定义业务服务的属性,包括 SLA、SLD、验证、路由和转换方面。这一节介绍使用 SLA 控制文件执行以下操作时的服务配置最低要求:

  • SLA 检查
  • SLA 和 SLD 策略实施
  • 路由
  • 内容验证和转换

您可以使用 DataPower 上的 SLA 控制文件服务,公开和保护 RESTful、XML 和 SOAP Web 服务,这些内容均在控制文件内定义。因此,SLA 控制文件可以使用两种类型的 DataPower:

  1. 多协议网关
  2. Web 服务代理

下一节将具体介绍一种使用 XML 网关控制文件的一般配置。

在处理过程中需要两项重要数据:

  1. 消费者标识符(消费者 ID):此信息是识别消费者应用程序时必不可少的。您可以使用各种机制传输消费者 ID:
    • "X-CONSUMERID" HTTP 标头
    • 基本身份验证:在这种情况下,用户名就是消费者 ID。
    • 客户端证书:在这种情况下,从客户端证书中提取出的客户端 DN 就是消费者 ID。
  2. 服务标识符:此信息是识别所请求的服务版本时必不可少的。URI 用于标识服务版本。

本节中的示例使用基本身份验证传输消费者 ID。

在第一个多协议网关上配置 AAA 策略。这项策略从基本身份验证标头中提取身份,并使用基本身份验证的用户名作为消费者 ID。身份验证通过 AAA 信息文件执行,经过身份验证的任何消费者都将获得使用业务服务的授权。因此,SLA 策略必须引用一个凭据类,其属性如图 11 和图 12 所示。

图 11. 基于所提取的身份的 SLM 凭据类
基于所提取的身份的 SLM 凭据类

如果消费者 ID 是从 X-CONSUMERID HTTP 标头检索得到的,不需要 AAA 策略,那么 SLA 策略的凭据类属性就必须使用图 12 所示的值定义。

图 12. 基于 HTTP 请求标头的 SLM 凭据类
基于 HTTP 请求标头的 SLM 凭据类

多协议网关(Web 应用程序、RESTful 服务)

这一节介绍了由于必须公开、保护和控制 XML 服务而使用 SLA 控制文件时所需的一般 DataPower 配置。

该解决方案基于两个多协议网关:

  • 第一个网关 (mpg_xml_sla-proxy) 用于执行以下任务:
    • SLA 检查控制服务消费者与提供商之间是否存在关系。
    • 消费者请求验证
    • 请求消息转换
    • 转换后的消息验证
    • SLA 实施(按消费者)
  • 第二个网关 (mpg_sld) 用于执行以下任务:
    • SLD 实施
    • 路由
    • 服务响应验证
    • 服务响应消息转换
    • 转换后消息的验证

注意:之所以需要实现两个网关,是因为在目前的固件版本 4.0.2 中,仍然无法在同一个处理规则上配置多个 SLM 策略。这样的限制将来可能会发生变化,届时应该将解决方案配置调整为使用单独一个网关(有关详细信息,请查阅您的目标固件的文档)。

图 13 给出了这种解决方案的概述。

图 13. 使用一个 SLA 控制文件的多协议网关
使用一个 SLA 控制文件的多协议网关

mpg_xml_sla-proxy 网关的主要属性

这一节介绍了第一个多协议网关的主要属性。请求类型定义为 XML,如图 14 所示。

图 14. 请求类型
请求类型

如果必须公开和控制 REST 服务,就要使用 “非 XML” 请求类型。

为了改进两个多协议网关之间的内部通信,我们将持久连接属性设置为 “关闭”。此外,由于第一个多协议网关不会处理后端错误,因此处理后端错误属性也被设置为 “关闭”,如图 15 所示。

图 15. 高级设置
高级设置

mpg_sld 网关的更多属性

这一节介绍了第二个多协议网关的主要属性。请求类型定义为非 XML,因为 mpg_sld 网关之前可能有不同类型的 SLA 网关(REST、XML 和 SOAP),如图 16 所示。

图 16. SLD 实施
SLD 实施

请求处理规则

这一节描述了用于实施 SLA 控制文件内定义的 SLA 和 SLD 的两个多协议网关的一般请求处理规则。

图 17 展示了两个网关的请求处理操作。

图 17. 请求处理规则细节
请求处理规则细节

SLA 检查执行以下处理:

  1. 从基本身份验证标头、客户端证书 (DN) 或者 "X-CONSUMERID" HTTP 标头中检索消费者标识符。
  2. 检索 URI,它定义了 SLA 控制文件中的服务版本。
  3. 使用 SLA 控制文件执行 SLA 检查,验证消费者与服务提供商之间存在合同。如果未找到 SLA,则会拒绝该消息。
  4. 检索其他信息,例如:
    • 用于验证传入 XML 消息的验证架构。
    • 用于验证传入 XML 消息的 XSL 转换。
    • 用于验证之前的转换的输出的验证架构。
    • 必须实施的 SLA 策略。

第一个条件操作 (Validation 1) 用于测试是否必须执行传入的 XML 消息的验证。

转换操作用于调整传入的 XML 消息,或者执行任何必要的处理。如果 SLA 控制文件内未定义任何转换,则执行身份 (store:///identity.xsl) 转换。

第二个条件操作 (Validation 2) 用于测试是否必须执行转换消息验证。检索了 SLA 策略之后,将使用一条 SLM 策略来实施它(SLA 实施)。

对第二个多协议网关执行 SLD 检索。在此操作的执行过程中,也会检索端点 URL。检索 SLD 策略之后,即可进行实施(SLD 实施)。

最终执行动态路由(路由),将 XML 内容发布到 SLA 控制文件中所定义的恰当服务提供商。

SLA 检查和 SLD 检索处理操作使用 SLA 控制文件。此文件的内容是使用一个 XML 管理器及专用的文档缓存策略进行缓存的,如图 18 所示。

图 18. 用于缓存 SLA 控制文件的文档缓存策略
用于缓存 SLA 控制文件的文档缓存策略

这个 XML 管理器中使用的 URL 匹配表达式允许缓存 SLA 控制文件的内容,还支持缓存一个 AAA 信息文件。

可以在 mpg_sld 多协议网关的请求处理规则的开头处添加一个可选的 “Set Variable” 操作,如图 19 所示。

图 19. 使用 Set-Variable 操作来指定 SSL 配置文件
使用 Set-Variable 操作来指定 SSL 配置文件

这项操作用于指定必须在 mpg_sld 网关与后端服务之间建立 HTTP 连接时应该使用的 SSL 配置文件(例如 MySSLProfile)。

图 20 展示了这个可选的 "Set Variable" 操作的配置。

图 20. Set-Variable 操作的细节
Set-Variable 操作的细节

必须设置的变量名称为 var://context/wsxml/default-ssl-profile

响应处理规则

这一节描述了用于实施 SLA 控制文件内定义的 SLA 和 SLD 的两个多协议网关的一般响应处理规则。图 21 展示了两个网关的响应处理操作。

图 21. 响应处理规则细节
响应处理规则细节

mpg_sld 网关上执行的相应处理操作负责检索以下元素:

  • 用于验证服务器响应的架构。
  • 用于转译服务器响应 (XML) 的 XSL 转换。
  • 用于在消息回发给消费者应用程序之前,验证之前的转换结果的架构。

第一个条件操作 (Validation 1) 用于测试是否必须执行 XML 响应消息的验证。

转换操作用于调整 XML 响应消息,或者执行任何必要的处理。如果 SLA 控制文件内未定义任何转换,则执行身份 (store:///identity.xsl) 转换。

第二个条件操作 (Validation 2) 用于测试是否必须执行转换消息验证。

mpg_xml_sla-proxy 网关负责执行可选的任务,例如以下任务:

  • 业务或者技术信息异步日志记录
  • 使用 DataPower WS-Management 代理记录监控数据

响应处理操作使用 SLA 控制文件。

错误处理规则

这一节介绍了用于实施 SLA 和 SLD 的两个多协议网关的错误处理规则。图 22 展示了两个网关的错误处理规则和操作。

图 22. 错误处理规则细节
错误处理规则细节

两个网关上将执行相同的错误处理。mpg_sld 网关不会创建任何错误内容,只是向 mpg_xml_sla-proxy 网关发送错误消息和错误代码(分别使用 DP.ERROR 和 DP.RC HTTP 标头)。第二个网关负责创建 SOAP 错误,或者发送专用的状态代码和原因短语。如果在 mpg_xml_sla-proxy 网关的执行过程中发生了错误,处理规则会直接处理错误。

Web 服务代理(SOAP/Web 服务)

这一节介绍了由于必须公开、保护和控制 SOAP Web 服务而使用 SLA 控制文件时所需的一般 DataPower 配置。

在配置一个 Web 服务代理以便公开 Web 服务时,必须使用 mpg_sld 多协议网关。

注意:之所以需要实现两个网关,是因为在目前的固件版本 4.0.2 中,仍然无法在同一个处理规则上配置多个 SLM 策略。这样的限制将来可能会发生变化,届时应该将解决方案配置调整为使用单独一个网关(有关详细信息,请参阅您的目标固件的文档)。

解决方案基于一个 Web 服务代理和一个多协议网关,如图 23 所示:

  • Web 服务代理 (wsp_sla-proxy) 用于执行以下任务:
    • SLA 检查控制服务消费者与提供商之间是否存在关系。
    • 消费者请求验证使用 Web 服务代理的验证功能执行。
    • 请求消息转换
    • 转换后的消息验证
    • SLA 实施(按消费者)
  • 第二个网关 (mpg_sld) 用于执行以下任务:
    • SLD 实施
    • 路由
    • 服务响应验证
    • 服务响应消息转换
    • 在将转换后的消息回发给 Web 服务代理之前对其进行验证
图 23. 使用一个 SLA 控制文件的 Web 服务代理
使用一个 SLA 控制文件的 Web 服务代理

下面给出了这种解决方案的概述。wsp_sla-proxy 的高级属性(请参见图 24)与使用多协议网关公开 XML 服务时使用的属性相同:

  • Web 服务代理与多协议网关之间不存在用于改进内部通信的持久连接。
  • 无 HTTP 错误处理,错误将在 mpg_sld 多协议网关中得到处理。
    图 24. Web 服务代理的高级设置
    Web 服务代理的高级设置

    这些属性是在 Web 服务代理的高级设置中配置的,如图 24 所示。

请求、响应和错误处理规则与关于多协议网关配置的上一节内容中详细介绍的规则相同。惟一的不同之处只有:

  • 可以在 Web 服务代理的不同级别上定义请求和响应以及错误处理规则,如图 25 所示。
    图 25. 基于 Web 服务代理的解决方案的处理规则
    基于 Web 服务代理的解决方案的处理规则

可以看到,处理规则是在代理级别上定义的。

  • 请求和响应处理规则的验证操作并非基于架构 URL,而是基于 WSDL URL。图 26 给出了此类验证操作的配置示例。
    图 26. 基于 WSDL URL 的验证操作
    基于 WSDL URL 的验证操作

在处理 SLA 控制文件内的 SOAP Web 服务时,必须使用 <inputSchemaURL><outputSchemaURL> 元素引用 WSDL 文件,而非 XSD 架构。


使用多协议网关的示例应用程序 (productInfo)

这一节讨论了用于控制 XML 服务 (ProductInfo) 的多协议网关的处理。该网关实现了通过一个 SLA 控制文件定义的控件。

ProductInfo XML 服务作为 echo 服务。它将检索一个 XML 文档 (getProductInfoRequest.xml),并将其回发给消费者应用程序。

SLA 控制文件

本文下一个示例中使用的 SLA 控制文件 (ibm.devworks.GWParams_1.1.xml) 包含图 27 所示的信息。

图 27. 实施 ProductInfo 服务的 SLA 控制文件
实施 ProductInfo 服务的 SLA 控制文件

这个 SLA 控制文件中只定义了一个业务服务,即 ProductInfo,它是本文中使用的一个简单的 echo 服务。

这个业务服务仅有一个服务版本 URI: /xml/productInfo

该 XML 服务可供以下消费者访问:

  • 具有银牌 SLA,标识符为 App1 的消费者。对于每一个经过验证的消费者,每 10 秒的消息数量不超过两条。如果达到了阈值,则执行 throttle 操作。
  • 具有金牌 SLA,标识符为 App2 的消费者。对于每一个经过验证的消费者,每 10 秒的消息数量不超过五条。如果达到了阈值,则执行 throttle 操作。

标识符不同于 App1 或 App2 的消费者应用程序 (consumerId) 无法使用 ProductInfo 服务。实际上,在这种情况下,会在 SLA 检查过程中拒绝该消费者的信息。

ProductInfo 服务具有自己的 SLD 和端点 URL。SLD 指定每 60 秒不超过 10 条消息。如果达到了阈值,则执行 throttle 操作。

在请求处理过程中,XML 消息必须使用 "simpleSchema" XSD 的 1.0 版本进行验证。随后,XML 消息将使用 "simpleSchema" XSD 的 1.1 版本进行转换和验证。转换包括解码使用 base64 编码的字符串,并修改 XML 文档的 XML 结构。在响应处理过程中,必须使用 "simpleSchema" XSD 的 1.1 版本执行验证。

请求处理

这一节具体介绍了请求处理。从基本身份验证标头中提取消费者标识符。这个标志也用于在使用 AAA 策略的 DataPower 设备上对消费者进行身份验证。

该策略的身份验证步骤基于 AAA 信息文件。因此,在请求 mpg_xml_sla-proxy 多协议网关时,您需要传输基本身份验证标头。

发布到网关上的消息是 getProductInfoRequest.xml,如清单 3 所示。

清单 3. getProductInfoRequest.xml
 <?xml version="1.0" encoding="utf-8"?>
<product-info>
	<product-id>XI52</product-id>
	<brand>WebSphere DataPower</brand>
	<encoded-description>RGF0YVBvd2VyIFhJNTIgU09BIEFwcGxpYW5jZQ
     ==</encoded-description>
	<benefits>Security;Integration;Performance</benefits>
</product-info>

mpg_xml_sla-proxy 上的请求处理

这一节介绍了 mpg_xml_sla-proxy 网关上请求处理规则的细节。

在 mpg_xml_sla-proxy 网关探针中,可以看到侦听端口 9000 的第二个多协议网关 (mpg_sld) 上进行了请求的路由(参见图 28)。该网关配置为仅可通过 loopback 接口访问(dp.loopback 是 127.0.0.1 的主机别名)。

图 28. 查看服务探针中的 mpg_xml_sla-proxy 事务
查看服务探针中的 mpg_xml_sla-proxy 事务

图 29 展示了所发布的传入 XML 消息以及对请求处理规则执行的处理操作。

图 29. 探针中的请求消息
探针中的请求消息

图 30 展示了传入的 HTTP 标头。您可以看到,这里存在一个具有 base 64 编码 "App2:foobar" 值的基本身份验证标头,AAA 策略身份提取和身份验证步骤需要这个标头。

图 30. 探针中的请求标头
探针中的请求标头

在完成 SLA 检查操作之后,就可以看到此时已经创建了一个特定的 XML 内容。此内容提供了图 31 所示的条件操作的验证数据(要使用的架构)。

图 31. 请求处理的条件架构验证
请求处理的条件架构验证

完成 SLA 检查之后,就会创建指定上下文变量,如图 32 所示。

图 32. 上下文变量值
上下文变量值

这些上下文变量供各种不同的操作用于动态执行指定操作。

例如,SLM 操作使用变量 "var://context/wsxml/sla" 实施正确的 SLA 策略 (SLA_5MessagesPer10Seconds_Throttle)。必须为 XML 请求消息应用的 XSL 转换是通过 "var://context/wsxml/xform-req" 多步变量定义的。消费者标识符 App2 设置为 "var://context/wsxml/consumerId" 上下文变量。

转换后(验证前)的消息如图 33 所示。

图 33. 转换之后的请求消息
转换之后的请求消息

ibm.devworks.productTransform.xsl 模板(清单 4)专门用于两种不同的模式:

  • 遇到一个 <encoded-description> 标记时,将其更改为 <description> 标记,随后解码原始标记的值。dp:decode() 函数是一个 DataPower 扩展函数。
  • 遇到一个 <benefits> 标记时,它使用 str:tokenize() 函数对优势列表进行词法分析(使用分号分隔它们),将其划分为较小的 XML 树。
清单 4. productTransform.xsl 文件的部分清单
 <xsl:template match="encoded-description">
	<description>
		<xsl:value-of select="dp:decode(.,'base-64')"/>
	</description>
</xsl:template>

<xsl:template match="benefits">
	<xsl:variable name="benefits" select="str:tokenize(.,';')"/>
	<benefits>
		<xsl:for-each select="$benefits">
			<benefit><xsl:value-of select="."/></benefit>
		</xsl:for-each>
	</benefits>
</xsl:template>

将 XML 内容发送给 mpg_sld 网关之前将实施 SLA 策略,如图 34 所示。

图 34. 探针中的 SLA 实施
探针中的 SLA 实施

mpg_sld 上的请求处理

这一节介绍了 mpg_sld 网关上请求处理规则的细节。

在图 35 所示的 mpg_xml_sld 网关探针中可以看到,ProductInfo 服务上使用 URL http://demoserver:5080/ProductInfo 执行了请求路由。

图 35. 查看服务探针中的 mpg_sld 事务
查看服务探针中的 mpg_sld 事务

图 36 展示了对于 mpg_sld 多协议网关的请求处理规则执行的不同操作。

图 36. mpg_sld 网关的处理操作
mpg_sld 网关的处理操作

第一项处理操作完成之后,检索必须实施的 SLD 策略,如图 37 所示。

图 37. SLD 实施的上下文变量
SLD 实施的上下文变量

随后实施 SLD 策略,并使用 "SetVar" 将 XML 消息路由至 ProductInfo 服务。

mpg_sld 上的响应处理

这一节介绍了 mpg_sld 网关上响应处理规则的细节。

ProductInfo 服务将对其接收到的 XML 内容做出回应。图 38 展示了对于 mpg_sld 多协议网关的响应处理规则执行的不同操作。

图 38. mpg_sld 网关的响应处理操作
mpg_sld 网关的响应处理操作

在完成第一次响应处理操作之后,就可以看到已经创建了一个特定的 XML 内容。此内容提供了图 39 所示的条件操作的验证数据(要使用的架构)。

图 39. 响应处理规则的条件验证
响应处理规则的条件验证

在这里可以看到,我们仅对响应规则执行了一次验证。这是在显示第一次操作之后创建的上下文变量时确认的,如图 40 所示。

图 40. 在响应处理过程中使用的上下文变量
在响应处理过程中使用的上下文变量

验证使用 "var://context/wsxml/input-schema-res" 上下文变量的值执行。

由于 SLA 控制文件内未定义任何转换,因此需要执行身份转换。

随后会将消息回发给 mpg_xml_sla-proxy 网关,如图 41 所示。

图 41. mpg_sld 网关的响应消息
mpg_sld 网关的响应消息

mpg_xml_sla-proxy 上的响应处理

这一节介绍了 mpg_xml_sla-proxy 网关上响应处理规则的细节。

mpg_xml_sla-proxy 网关的相应处理规则仅包含一个自定义模板,用于使用 “类似于 HTTP 访问日志” 的格式记录信息。

这项操作是异步执行的,如图 42 所示(见 "Asynchronous = on" 属性)。

图 42. mpg_xml_sla-proxy 网关上的异步日志记录
mpg_xml_sla-proxy 网关上的异步日志记录

图 43 展示了 ibm.devworks.http-accesslog.xsl 在设备上创建的 HTTP 访问日志文件。

图 43. HTTP 访问日志
HTTP 访问日志

错误处理示例

这一节提供了在以下执行步骤中遇到的几种错误的处理示例,但在请求或响应处理过程中也可能会发生其他错误:

  • SLA 检查
  • SLA 实施
  • SLD 实施
  • 请求消息的验证

SLA 检查

为了测试 SLA 检查错误处理,您需要具备一个经过 AAA 策略验证的标识符,但此标识符应该尚未被引用为 ProductInfo 服务的消费者。“App3” 就是这样一个消费者。

图 44 展示了请求处理在 SLA 检查操作处停止的情况。

图 44. SLA 检查错误
SLA 检查错误

重点关注 AAA 策略的输出上下文,可以看到从基本身份验证标头检索到的消费者标识符是 “App3”,如图 45 所示。

图 45. 调试探针中的消费者标识符
调试探针中的消费者标识符

由于 SLA 控制文件内并未将 “App3” 定义为允许其请求 ProductInfo 服务的消费者,因此消息会被拒绝,并提供特定的 HTTP 标头(DP.RCDP.ERROR),指示错误代码 (403) 和一条错误消息 (Error:SLA Check),如图 46 所示。

图 46. SLA 检查 - 自定义错误代码和消息
SLA 检查 - 自定义错误代码和消息

SLA 实施

为了测试 SLA 实施限制,有必要使特定消费者在超过 SLA 内定义的阈值的情况下访问 ProductInfo 服务。图 47 提供了用于测试的 SLA 控制文件的概览。

图 47. ProductInfo 服务的 SLA 控制文件
ProductInfo 服务的 SLA 控制文件

这个 SLA 控制文件内定义了以下内容:

  • 消费者 App1 每 10 秒可以使用两条消息(银牌 SLA 策略)
  • 消费者 App2 每 10 秒可以使用五条消息(金牌 SLA 策略)

这里的测试是使用消费者 App1 执行的。相同的 10 秒时间间隔内发出的第三条消息会遭到拒绝,如图 48 中的探针所示。

图 48. SLD 实施(限制)
SLA 实施(限制)

图 49 展示了 SLA 策略拒绝(限制)的细节。

图 49. SLA 实施上下文变量
SLA 实施上下文变量

所实施的 SLM 策略是通过上下文变量 var://context/wsxml/sla 定义的。

该变量的值是 SLA_2MessagesPer10Seconds_Throttle,如 SLA 控制文件中所定义。

达到一个 SLA 时,消息将被拒绝,并提供特定的 HTTP 标头(DP.RCDP.ERROR),表示错误代码 (503) 和错误消息 (Error:an SLM Policy has rejected the request),如图 50 所示。

图 50. SLM 策略拒绝 - 自定义错误代码和消息
SLM 策略拒绝 - 自定义错误代码和消息

SLD 实施

在达到并超出 SLD 时,多协议网关将返回相同的错误消息和代码。

在本例中,拒绝操作是在 mpg_sld 多协议网关上执行的。图 51 展示了 SLA 控制文件内定义的 SLD 策略的概览。

图 51. 一个 SLA 控制文件的 SLD 部分
一个 SLA 控制文件的 SLD 部分

服务提供商定义的 SLD 策略指定在 60 秒的时间间隔内最多接收十条消息。

这里的测试是使用消费者 App2 执行的。在 mpg_xml_sla-proxy 网关上,第 11 条消息遭到拒绝,如图 52 所示。

图 52. mpg_xml_sla-proxy 网关上的 SLA 实施
mpg_xml_sla-proxy 网关上的 SLA 实施

图 53 展示了 mpg_xml_sla-proxy 网关的请求处理规则,表明第 11 条消息未被拒绝。

图 53. mpg_xml_sla-proxy 网关中未发生拒绝
mpg_xml_sla-proxy 网关中未发生拒绝

相同的 60 秒时间间隔内发出的第 11 条消息会遭到拒绝,如图 54 中 mpg_sld 网关的探针所示。

图 54. SLD 实施(限制)
SLD实施(限制)

图 55 展示了 SLD 策略拒绝(限制)。

图 55. SLD实施上下文变量
SLD实施上下文变量

所实施的 SLM 策略是通过上下文变量 var://context/wsxml/sld 定义的。

该变量的值是 SLD_10MessagesPer60Seconds_Throttle,如 SLA 控制文件中所定义。

请求消息的验证

为了完成这个测试,需要在网关中发布一条无效消息,

即清单 5 所示的 getInvalidProductInfoRequest.xml。这个文件在 本文附带的示例 中也称为 bad-products.xml

清单 5. getInvalidProductInfoRequest.xml
 <?xml version="1.0" encoding="utf-8"?>
<product-info>
	<product-id>XC10</product-id>
	<brand>WebSphere DataPower</brand>
	<encoded-description>RGF0YVBvd2VyIFhJNTIgU09BIEFwcGxpYW5jZQ
     ==</encoded-description>
	<benefits>Security;Integration;Performance</benefits>
</product-info>

XC10 并非 /product-info/product-id 元素的有效字符串。请求消息无效时,mpg_xml_sla-proxy 网关会拒绝该消息,如图 56 所示。

图 56. XML 验证错误
XML 验证错误

系统日志中的错误消息明确标识了验证错误,如图 57 所示。

图 57. XML 验证错误细节
XML 验证错误细节

请求消息验证失败时,消息会遭到拒绝,并提供特定的 HTTP 标头(DP.RCDP.ERROR),表示错误代码 (500) 和错误消息 (Error:XML Validation),如图 58 所示。

图 58. XML 验证错误 - 自定义错误代码和消息
XML 验证错误 - 自定义错误代码和消息

监控 SLA 控制文件指标

这一节介绍了 DataPower 配置,您可以利用这样的配置在配置为使用 SLA 控制文件的 DataPower 服务的响应和错误处理规则中添加监控功能。

为了提供流量监控 信息,可以使用实现了 WS-Management 规范的客户端应用程序检索这些信息。IBM Tivoli Composite Application Manager for SOA DataPower Data Collector 就是这样一个应用程序,如图 59 所示。

图 59. 使用 ITCAM for SOA 监控 DataPower SOA 设备
使用 ITCAM for SOA 监控 DataPower SOA 设备

这一节介绍事务流量监控。健康状况监控(通常基于 SNMP 轮询和陷阱)等其他类型的监控不在本文讨论范围之内。

Tivoli Composite Application Manager 数据收集器部署步骤

要在您的环境中部署 DataPower 数据收集器,请按以下通用步骤执行:

  1. 配置要监控的 DataPower SOA 设备。
  2. 启用 DataPower 数据收集器。
  3. 运行 startDPDC 脚本,启动数据收集器,或者将数据收集器配置为后台运行,并启动后台任务。

配置要监控的 DataPower SOA 设备

这一节介绍了配置要进行流量监控的 DataPower SOA 设备的步骤。

  1. 假设您使用的不是 XI52 设备,您首先需要将 DataPower 固件的版本升级到 3.7.1.4 或其更新版本。
  2. 使用管理员账户或者任何具有特权的账户,在 DataPower SOA 设备上配置一个用户账户。
  3. 启用 XML 管理接口。通过控制面板访问 XML 管理接口配置,选择 Objects > Device Management > XML Management Interface。对于 WS-Management 端点,选择 “on”,如图 60 所示。
    图 60. 在 XML 管理接口上启用 WS-Management
    在 XML 管理接口上启用 WS-Management
  4. 检查其他可选设置。通过控制面板访问 Web 服务代理配置,选择 Services > Miscellaneous > Web Services Agent,如图 61 所示。
    图 61. Web 服务管理代理配置
    Web 服务管理代理配置
    • 如果您希望 DataPower SOA 设备在 DataPower 数据收集器未运行的时候保存指标记录,可将 BufferMode 设置为 "buffer"。利用这样的设置,设备即可在数据收集器启动时报告已经保存的指标数据。
    • 调整 MaxRecords 和 MaxMemoryKB 的值。
    • 如果您希望数据收集器在记录汇总指标的同时也记录消息内容,请将 CaptureMode 从 "faults" 更改为 "all-messages"。

配置 DataPower 处理规则

除了升级 DataPower 固件之外,您可能还需要为各受影响的 Web 服务代理或者多协议网关代理对象的每一条处理规则中的操作规则添加 XSL 转换。

如果您正在监控无拓扑结构支持的 WS 代理,则不必添加任何转换。

如果您正在监控多协议代理,则必须创建某些转换。

为 DataPower 多协议网关配置处理规则

在每个事务的末尾处,通常是在响应规则和错误规则中,必须使用自定义 XSL 样式表调用 dp:wsm-agent-append() 函数。这个函数将有关当前事务的监控数据 “发送” 至 Tivoli Composite Application Manager for SOA data collector。

配置在 SLA 和 SLD 控制网关上配置处理规则

这一节介绍了监控 mpg_xml_sla-proxy 和 mpg_sld 多协议网关流量的配置。

为了避免数据兼容冗余,必须在将任何消息回发给消费者应用程序之前,仅在一个多协议网关 mpg_xml_sla-proxy 上记录响应和错误处理规则的流量监控信息。

图 62 展示了响应处理规则的配置。

图 62. 提交响应处理监控数据的自定义模板
提交响应处理监控数据的自定义模板

在日志操作之前添加了一个转换操作 (Xform)。

该转换使用 dp:wsm-agent-append() 函数向 Web 服务管理代理添加一个请求-响应消息序列记录。记录中包含在请求-响应消息序列中收集到的事务数据。每个应用程序域都可以包含经过配置的 Web 服务管理代理的一个实例。根据配置的不同,记录中可以包含有关请求和响应的以下处理信息:

  • IP 地址
  • 客户端标识
  • 经过验证的身份
  • 目标服务或操作
  • 消息大小
  • 处理周期
  • 错误消息
  • SOAP 标头
  • 完整消息
  • 图 63 展示了错误处理规则配置。
图 63. 提交错误处理监控数据的自定义模板
提交错误处理监控数据的自定义模板

在错误操作与记录操作之间添加了一个转换操作 (Xform)。错误操作是错误规则中要处理的第一项转换。必须将监控操作排在错误创建之后,因为具体的错误代码和消息记录在监控数据之中。

您可以在规则的错误处理操作中设置的专用上下文变量中检索错误代码和监控操作消息。


迁移到 WSRR

若要从 SLA 控制文件方法迁移到 WebSphere Service Registry and Repository (WSRR),则需要将 SLA 控制文件中当前定义的 XML 数据定义为 WSRR 对象元数据属性。

目标是不再 使用 SLA 控制文件。您可以修改该文件引用的 DataPower 配置工件(验证操作、路由、SLA/SLD 策略和转换),而不必使用 WSRR API 直接从 WSRR 中获取这些数据。本系列的下一篇文章将介绍将本文所述的模式迁移到 WSRR 的最佳实践和方法。


结束语

本文介绍了一种在 DataPower 设备上实施 SLA 和 SLD 的简单的、健壮的解决方案。利用这种解决方案,您可以执行多协议网关或 Web 服务代理服务的请求和相应处理规则的自动验证和转换。

这种解决方案模式支持多种不同类型的服务,例如 Web 服务 (SOAP)、RESTful 服务和 Web 应用程序。它还提供了一种一致的实施框架,用于部署、管理和实施由设备网关代理的服务和策略。

最后,这种方法与从业者掌握在 DataPower 设备上实施 SLA 时的最佳实践一致。这也是稍后迁移到 WSRR 等合理、正规服务注册库和策略管理点的良好起点。


下载

描述名字大小
代码样例SLAEnforcement_Part1_DataPower_Config_Export.zip532KB
代码样例SLAEnforcement_Part1_ReferenceMaterial.zip7KB

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=821475
ArticleTitle=使用 WebSphere DataPower 实施服务水平协议,第 1 部分:应用 SLA 控制文件模式
publish-date=06182012