引入 SOA Policy Pattern 来创建可重用的策略模式和控制您的服务

一般而言,一条策略断言一种需求、一种功能或目标行为的另一个属性。在面向服务的架构中,可使用一条策略来减少风险和提高动态控制能力,因为您与任何业务逻辑独立地创作和维护它。本文介绍 “SOA Policy Pattern”,其中的策略使用 WebSphere® Service Registry and Repository、WebSphere DataPower SOA Appliances 和 IBM® Tivoli Composite Application Manager for SOA 的特定组合来创作、管理、实施和监视。

Robert Laird, 软件架构师, IBM

Bob Laird 的照片Robert Laird 是一位企业架构师,领导 IBM 的 SOA、SOA Governance 和 SOA Policy 的软件产品架构设计。他在 IBM 工作期间为各种行业和客户提供过 SOA 咨询。Robert 拥有 20 年的电信行业从业经验,在该行业担任过各种职位,包括担任开发人员和架构师,然后他在 MCI 担任过首席架构师,在那里领导 SOA 和 SOA Governance 工作。他与 Thomas Erl 一起编写了 Prentice-Hall Service-Oriented Computer Series 中的 Executing SOASOA Governance: Achieving and Sustaining Business and IT AgilitySOA Governance: Governing Shared Services On-Premise and in the Cloud 等图书。



Stephen Cocks, 资深软件工程师, IBM

Stephen Cocks 的照片Stephen Cocks 是 IBM 在英国 Hursley 的开发实验室的一位资深软件工程师。他目前的职责包括与产品团队合作,共同定义、设计和交付基于 SOA 策略的功能。Stephen 于 1989 年加入 IBM,担任过与 IBM 的许多重要 WebSphere 产品相关的各种职位,这些产品中包括 IBM Business Process Manager、IBM WebSphere Enterprise Service Bus 和 IBM WebSphere Application Server。



2012 年 12 月 11 日

简介

IBM 定义了许多 “模式”,这些模式是涉及到多个产品的软件解决方案。它们集成在一起来解决具体的客户解决方案需求。一个解决方案是 “SOA Policy Pattern”。此模式将 WebSphere Service Registry and Repository (WSRR)、WebSphere DataPower SOA Appliances (DataPower) 和 IBM Tivoli Composite Application Manager for SOA (ITCAM for SOA) 集中在一起来为策略的创作、应用和实施提供一种环境。

有关该模式和它的使用的更多详细说明,请参阅 SOA Policy Pattern 用户指南

我们首先看看与 SOA Policy、SOA Policy Domains 和 IBM SOA Policy Architecture 相关的一些背景。


什么是 SOA Policy?

使用面向服务的架构 (SOA) 可帮助业务识别和专注于优化其关键资源的价值,比如服务、流程和信息。通过将策略的概念添加到 SOA 中,可提供一种为业务和 IT 添加控制点、治理和敏捷性的方式。这使 SOA 更容易使用,提高了 SOA 解决方案的效用并加速了它们的采用。

举例而言,一个独立创作和维护的策略 “一次交易必须在 2 秒或更短时间内完成” 具有优势,因为可应用它的上下文不受限制。它的优势包括:

  • 可将该策略应用到各种交易,比如信用卡交易或价格查找交易。
  • 可一次性地集中更改该策略,一致地将它应用到多个资源,这是使用紧密绑定的策略所无法实现的。
  • 策略本身没有提供如何或在何处实施它的任何信息。在业务需求更改时,可将策略绑定到测试或生产服务。

SOA Policy Pattern 允许在一个集中位置创作、管理和治理各种策略,然后自动分发到负责处理和监视服务事务的运行时引擎。


SOA Policy Domains

IBM SOA Policy 参考架构 文档展示了如何在整个服务开发生命周期引入一条策略,以表达业务、架构和操作需求。

这里提供的 SOA Policy Pattern 为操作服务的管理和特定运行时系统对它们的执行提供了一个环境。可使用策略表达许多区域的需求,比如安全性、资源管理、服务水平协议和服务路由。我们将这些不同的区域称为策略领域。在 SOA Policy Pattern 中,我们专注于两个领域:服务中介服务监视

中介策略断言

中介策略控制 DataPower 中的 Web 服务代理对象的配置。它的主要用途是定义服务水平(例如允许的最大请求速率),以及 DataPower 如何通过该设备管理对每个服务的请求流,以满足这些服务水平。

服务水平协议 (SLA) 表明一项服务提供的服务质量必须满足一种指定的标准。在设计一项服务时,会创建功能需求来指导该服务的操作逻辑。非功能需求作为该服务的分析和设计的一部分而并行指定,以指明该服务应提供的服务质量。

例如,业务必须提供一项服务来提供信息,从而响应一个客户 Internet 查询。一项客户研究发现,如果未在 3 秒内作出响应,客户的意图就会转移,公司会丢失它本来可获得的业务。作为端到端事务的工程设计的一部分,此服务必须在 2 秒内返回它的信息,转移才能满足业务的非功能需求。

可以编写策略,在服务性能上实现运行时检查,并在 SLA 未满足时采取措施,以保证服务满足其 SLA。例如,您可能有一个服务主要端点,它正常情况下(在 95% 的时间内)能够提供 2 秒内的服务响应。SOA 架构师在另一个服务器上创建了一个辅助端点,这个服务器通常用作预防主要端点宕机的热备用服务器,但它也被授权在主要端点无法处理事务负载时用于处理溢出的流量。可以通过编写策略来检查服务响应时间,并在必要时重新路由流量,以满足 SLA。

另一个通过运行时策略维护 SLA 的示例是:在一项服务响应具有各种不同的用户的事务并且每种用户都有不同的优先级时,如何维护 SLA。一个简单的示例是:假设您可能拥有 “金级” 和 “铜级” 客户,而您只能为 “金级” 客户保证特定的服务质量。在上一段中的示例中,可以检查用户是否属于 “金级” 客户,然后重新路由到辅助端点,同时继续以较慢的响应时间处理 “铜级” 客户。业务认为 “铜级” 客户提供的增量收入不足以补偿满足 “金级” 客户的 SLA 所需的工程响应时间开支。

在第三个示例中,存在这样一种情形:某项提供商服务已提供了最高性能,但当运行时引擎确定服务未满足其响应时间 SLA 时,该策略指定运行引擎对来自低优先级客户服务的消息进行排队,或者甚至进行调节(拒绝)。一个示例是在一个批处理例程在一个意外的时刻向系统带来大量用户请求。为了保护您的服务的服务质量,可创建一条仅在营业时间内生效的运行时策略,它在此期间拒绝所有批处理请求。

具体来讲,运行时策略可确定适合限制、排队或重新路由一个事务来满足 SLA 的情形。

只能为一个特定的 "用户-提供商" 对或提供商的 “匿名” 用户的一项服务(提供商)的指定一条策略。“匿名” 实际上提供了一种定义默认策略的方式,这仅适用于没有应用其他策略的用户。举例而言,使用此功能支持为没有标识自身的反常用户指定一条策略。这些用户服务可调节(拒绝)或编写一条日志消息,以便您能够与应用程序团队一起解决它。这对预防来自黑客的拒绝服务攻击非常有用,可防止他们向系统传输大量事务和防止某项提供商服务中断。

监视策略断言

监视一条策略可控制 ITCAM for SOA 中的条件配置。

操作组的任务通常是维护适当的服务质量。为此,拥有一组自动化的监视策略是一个不错的做法。这些策略指定了需要分析一些东西或采取自动操作的条件(依据这些条件通知操作)。

例如,业务可能有一项服务提供有关用户的信用信息。预计最初只有少量的事务,但随时间的推移,事务会变得多起来。操作需要知道事务数量何时超出某个水平,以采取相应的措施,比如创建更多的端点和实现一个负载平衡器。

如果非功能需求经过这种程度的周密考虑,此类策略应在开发流程中已经考虑到。更有可能的是,操作组的任务是识别满足其 SLA 以及定义和实现必要监视策略所需的操作考虑因素。


SOA 策略架构

SOA Policy Pattern 体现了一种一般性的策略管理架构模式,如图 1 所示。这个一般架构由许多已识别的组件组成,这些组件在这里称为 “点”。

图 1. 策略使用的标准模式
策略使用的标准模式

策略管理点 (PAP)

策略管理点提供了支持创作策略,管理和治理策略和它的资源分配,以及在运行时期间管理策略结果的策略功能。

策略监视点 (PMP)

策略监视点是一个功能组件,它提供了一个详细的策略监视功能,也就是显示来自分布式环境的策略和资源结果的全景图

策略实施点 (PEP)

策略实施点 (PEP) 是一个功能点,采用一些操作来在服务事务上实施策略。

策略决策点 (PDP)

策略决策点 (PDP) 评估对相关策略或合同和属性的参与者请求,以便提供一个经过授权的、有资格的或经过验证的决策,或者提供计算的结果。

策略信息点 (PIP)

策略信息点 (PIP) 提供一个策略决策点的外部信息,比如 LDAP 属性信息,或者来自一个数据库的结果,该数据库包含必须为了制定决策策略而必须评估的信息。


SOA Policy Pattern

如上所述,模式可以将 WebSphere Service Registry and Repository (WSRR)、WebSphere DataPower SOA Appliance (DataPower) 和 IBM Tivoli Composite Application Manager for SOA (ITCAM for SOA) 集中在一起,提供一个管理策略的环境。具体来讲,您需要使用 WSRR V8.0(或更高版本)、一个运行 V5 固件且支持 Web 服务代理(比如 XS50)的 DataPower 设备,以及 ITCAM for SOA V7.1.1.3 或更高版本。

尽管可使用 WSRR V7.5.0.2 代替 V8.0 来使用大部分模式功能,但 V8.0 中对中介策略创作和附加小部件进行了重大的易用性改进。因此,本文的图片中使用了 WSRR V8.0。

初始设置

在开始使用模式之前,需要安装和配置各种产品。可在各自的信息中心中找到有关安装和配置该产品的更多信息(参阅 参考资料 一节)。

有关配置产品的必要步骤的进一步信息可在 SOA Policy Pattern 用户指南 中找到。

正常的策略操作

图 2 显示了 PAP(由 WSRR 实现)、PEP(由 WebSphere DataPower 实现)和 PMP(由 ITCAM for SOA 实现)之间的操作流,这正是 SOA Policy Pattern 的工作原理。

图 2. SOA 策略流
SOA 策略流

SOA Policy Pattern 流具有以下特征:

  1. 策略创建之后会附加到需要该策略的服务,通常如下所示(不一定按这个顺序,可能有适当的交错):
    1. 服务集加载到 WSRR 服务存储库(用作 PAP)中或在其中创建。
    2. 策略集需要使用策略生命周期在 PAP 中创建。
    3. 策略附加到需要这些策略的服务 - 通过 SLD 或 SLA 间接附加,或者根据需要在服务、操作或端点级别附加。
  2. 自动发布和订阅策略,从 PAP 到 PEP 和 PMP:
    1. 作为设置的一部分,ITCAM for SOA 从 WSRR 订阅监视策略(一次性)。
    2. 作为设置的一部分,在每个与策略实施具有服务事务的 DataPower 设备中创建代理网关(一次性、根据需要添加或更改)。
    3. 作为设置的一部分,每个设备中的每个代理网关从 WSRR 订阅它负责的服务的策略(一次性、根据需要添加或更改)。
    4. 作为设置的一部分,配置 DataPower,以便设备可由一个集群中的其他设备共享(一次性,根据需要更新)。
    5. ITCAM for SOA 在监视策略发布时成功下载它们。
    6. ITCAM for SOA 将策略转换为内部表示(条件策略)。
    7. DataPower 下载它负责处理的服务的 WSDL。
    8. DataPower 下载它在收到来自 WSRR 的通知时负责的服务的策略。
    9. DataPower 将策略转换为内部 DataPower 表示(例如 SLM 对象)。
  3. SOA 策略的监视,以及操作的报告和通知:
    1. 监视策略在 ITCAM for SOA Situation Policy 中有效。
    2. ITCAM for SOA 收到监视信息并将该信息放在工作区中。
    3. ITCAM for SOA 定期(默认为每隔 5 分钟)评估每个监视策略。如果该策略为真,它将执行指定的操作。
  4. SOA 策略的实施:
    1. 实施策略在各种 DataPower 设备中均有效。
    2. DataPower 收到服务事务,并针对该用户服务和提供商服务来评估和实施策略。
  5. PEP 将 SOA 策略实施的统计数据发送给 PMP。
  6. PMP 将监视事件发送给 PAP:
    1. 在 PAP 中设置要基于监视策略更新的目标事件。
    2. 当监视策略计算结果为 true 时,将事件从 PMP 推送到 PAP。
  7. 监视警告:
    1. 当监视策略计算结果为 true 时,将事件从 PMP 推送到 PEP。

使用 SOA Policy Pattern

接下来,我们将讨论如何创作一条策略,然后将它附加到一项服务。

使用 WSRR 8.0 创作一个策略文档

WSRR 8.0 定义了一些策略小部件,它们允许用户通过添加条件操作来快速创建中介策略。图 3 显示了创作一个策略小部件的示例,这个小部件允许作者快速且轻松地创建中介策略。

图 3. 创作一个策略断言
创作一个策略断言

WSRR 8.0 创建了策略小部件,从而允许将策略附加到上下文中的服务上。

使用 WSRR 8.0 将一个策略文档附加到一个或一组服务

对于用于将策略附加到资源的 WSRR 8.0 策略小部件,允许直接将策略附加到选定的具体项目。图 4 显示了执行策略附加的 WSRR 窗口。图 5 显示了管理一个策略的多个附件的相关信息。

图 4. 将一个策略附加到一个 WSRR SLA
将一个策略附加到一个 WSRR SLA
图 5. 管理一个策略的多个附件
管理一个策略的多个附件

此外,用户可以通过定义一个查询,将一个策略附加到多个项目。举例而言,可通过此方法将一个策略附加到特定业务组织的所有服务,或者将一个策略附加到所有服务,如图 6 所示。

图 6. 策略附加查询
策略附加查询

结束语

本文介绍了 SOA Policy Pattern,以及在一个面向服务的架构中运行时,它如何为使用策略来控制和治理服务提供方便。具体来讲,本文展示了如何使用 WSRR 创作和管理中介和监视策略,用它们分别控制 DataPower 和 ITCAM for SOA 实施和监视服务水平的方式。请参阅 SOA Policy Pattern 用户指南参考资料 部分中的其他参考资料,更具体地了解 SOA Policy Pattern。


下载

描述名字大小
PDF 文件SOA_Policy_Pattern_User_Guide.pdf9,936KB

参考资料

学习

获得产品和技术

讨论

条评论

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, Tivoli
ArticleID=851361
ArticleTitle=引入 SOA Policy Pattern 来创建可重用的策略模式和控制您的服务
publish-date=12112012