本文介绍 “SOA Policy Pattern”，其中的策略使用 ">WebSphere® Service Registry and Repository、WebSphere DataPower SOA Appliances 和 IBM® Tivoli Composite Application Manager for SOA 的特定组合来创作、管理、实施和监视。
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、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 以及定义和实现必要监视策略所需的操作考虑因素。