在分布式应用程序中正确的管理、发布引用及配置数据总是具有挑战性。面向服务的体系结构 (SOA)、实时及事件驱动处理 (7x24) 的使用使得这项任务成为主要的问题。在接下来的部分当中，Richard Whyte 将向您解释如何从您自己的策略管理解决方案的实现的关键设计点中受益。他也从提炼为最终建议的简单设计开始，为策略管理服务的一个版本勾勒了框架，并使其成为可能的解决方案。
引言
各公司也正在寻找他们使用及控制技术的方式的改进。业务流程管理（BPM）及面向服务的体系结构 (SOA) 是使得业务灵活、增强业务控制及风险管理的关键，并在业务完成主要功能的方式上创建新的机会。
端对端或直接处理 (straight-through-processing，STP) 体系结构在其边界接收工作条目并在不影响控制的情况下控制其完成流程。这样的体系结构可以跨越单一部门、多业务线 (LOB) 或商业组的成员。新的挑战迫使业务及技术优势被部分的偏移。
关键的挑战是在大型的、高可用性的 SOA 实现中有效的引用及配置数据发布。可以通过调查工作量的性质来突出这一点。例如，SOA 需要供给多业务流程。SOA 为不同阶段（秒、日、周或年）控制每个流程实例（工作条目），并需要各种资源来完成。条目流由必需使用通用规则及参考数据处理的组工作条目来创建。
本文讨论配置、引用及业务规则发布的解决方案。策略管理是确保策略的服务能被正确、及时及准确通知的动作。它是一种系统开销，所以必需要操作简单、高效和经济的。
术语策略数据 (policy data)指做业务或技术决定的所有数据类型。在某些情况下错误的、过时的或不完全的数据是可以接受的但在其他情况下则不可以接受。策略设置的可见性是严格的。例如，没有时区的时间戳在单一地区的情况下可以接受，但在多地区环境中却不能。
为达到本文的目的，策略是由单一单元管理及检索的一套指定的数据条目（设置）。设置名在策略中是唯一的但可能存在于多个策略中。
策略是确定的路线或从选择物中选择动作的方法，并在给定条件的指引下指导及确定决策。例如，业务策略规定报酬低于 5,000 USD 不作为舞弊检查的对象。这里的规则及值（5,000 USD）就是策略数据。例如，如果 USD(<Item.Value>) 大于 <Policy.Value>，那么 Do-Fraud-Check。
策略管理显示
策略管理解决方案（PMS）显示为 SOA 提供中央管理策略数据服务。该解决方案负责 SOA 中所有元数据。它提供：
- 单点控制
- 相容接口
- 检测及保护数据恶化
- 准确的、完全的及同步的（及时的）为需要它的任何服务发布策略数据
解决方案的主要原则是：
- 服务保留响应性和对其策略的控制，但是将管理和保留的职责委托给了专用的 PMS。这将可以确保不用复杂的配置改变而向 SOA 中添加或从其中移除服务。由于服务总可以从策略服务中恢复策略，所以他们可以存在于非错误容忍的硬件设备上。元件失效并不导致需要恢复配置信息，以及个性化服务组建可以安全的聚焦于业务及当前工作上而不是策略上。
- 工作条目“请求”使用策略的版本而不是服务拥有版本。这确保服务可以确信他们使用正确的策略，而不需要进行远程版本检查。 可以在任何给定时间激活策略的新老版本，并可以保证任何服务分别为工作条目选择正确的策略。这也支持服务使用不同的策略需求同时处理不同工作流中的工作条目（隔离工作流）。
- 不变策略版本及检查策略数据完整性的能力支持分布及响应环境的优化。它也允许服务的所有实例应用策略版本，而不用考虑其周围环境。
- 通过实现责任的明确划分及清除的、明确的所有权保存，解决方案陈列出一致的策略语法及语义、查看跨多服务策略的能力、简化的实现及保管成本。
- PMS 负责管理及分发策略信息，但并不拥有所有策略数据，它只保留个别（客户端）服务的属性信息。集中管理允许对策略进行测试、控制改变及将其作为单独单元移植到产品中。IT 简化了启动新服务实例的配置步骤并保证那个服务使用一致的名字及类型管理模式。结果是使用专一的、简单的管理接口。
- PMS 应当将它本身及客户端应用程序间的代码或操作连接最小化且不能损害独立性或封装性（如，Java™ 对象版本）。它也不能创建操作依赖性，如争用或单独点故障。
- PMS 提供了可调用的管理接口。这创建了分层的解决方案，它可以权衡 SOA 用户交互解决方案（浏览器、门户及 Eclipse）。这个方法让 SOA 为所有服务提供一致的用户接口。要简化最初的开发及部署，可能要提供简单的控制台，在公布的管理应用程序编程接口（API）中使用服务。此方法不向服务中添加任何限制。
开发解决方案
解决方案开发开始于数据结构及创建操作、维护及分发策略数据的软件。这个解决方案从一个简单的解决方案发展而来，调整以适合新的问题并根据需要添加功能。结果是该解决方案在不损害 SOA 或导致额外操作成本的情况下满足需求。
图 1. 策略管理开始于软件的编码
以结构及灵活性为代价换来了最佳性能。由于环境变得很复杂，识别及改变策略的工作也变得费力甚至是冒险。在没有改变软件的情况下不能改变策略，并且没有源代码时也策略也不可见。嵌入式策略不能被共享，不支持引用数据，不适合封装解决方案。
图 2. 配置库中的策略设置
将策略设置放置在软件本地的配置库中使得他们更加可见并更容易更改及共享。本地存储很可能会提供合理的性能且不创建复杂的访问性及所有权问题。这解决了嵌入式策略的许多限制。本地库方法当应用程序想通过网络并彼此依赖来提供及时并准确的服务时会失败。在无权使用运行时环境或不了解特定主机上是如何存储及管理策略时，本地配置是不可见的。一般的问题是使用深奥的语法及语义表示配置，需要专门的控制台或简单的文本编辑器进行管理，或者是本地配置文件或数据库不是很容易的能支持企业级范围的引用数据。
图 3. 多实例服务及互关联分布系统
多实例服务及互关联分布式系统创建过多的所有本地配置的同步。共享库通常是发布的模式数据库。引用及配置数据使用复制技术存储于数据库中。应用程序使用 SQL 查询访问数据。
这个解决方案在策略库与使用它的应用程序之间有很强的依赖性。在没有改变的情况下，模式不能改变且数据库不能移植到所有的应用程序中。用户名及密码经常存储于各自的应用程序中，但不能在常规基础上进行改变并且也不安全。
数据所有权、性能问题及单点故障还有更多普遍的问题都存在于这个解决方案中。性能及可用性方面可以通过创建多的、同步的库映像来解决。然后需要通过负载均衡避免争用。
复制从一个库将数据操作（插入、更新、删除）复制到另一个仓库。使用从数据库日志文件或数据库触发器触发的存储并发送 (store-and-forward) 技术将操作发送给复制。标准的复制模型是可升级的且提供使用异步传输的“某时”仓库的同步。它不保证“时间点 (point-in-time)”同步。
这个 PMS 版本需要所有服务在任意时刻都使用正确的策略，作为解决方案放弃复制其自身。
同步复制使用分布式事务处理管理复制数据操作，（几乎）同时的作为工作单点，将操作应用到所有复件。一个的失败导致所有的失败。不幸的是，这项技术操作费事且不可划分。错误修正、添加、移除及初始化同步复制都是费事的，且相关操作创建实例间的紧耦合。
轻量级目录访问协议 (LDAP)是正式的目录访问协议。实现一般地提供内建的分布式系统，它可以通过跨企业及网络来实现。LDAP 提供基于标准的层次数据结构，它允许非安全认证应用程序访问，或通过提供存储于他们自己目标记录中的认证访问。这个基本的模型对 PMS 发布显示很有用处。它没有依赖于简单数据库方法的用户名及密码的依赖，而是提供可扩充的文档模式。LDAP 使用复制将数据入栈到它的复件中，它不支持服务选择特定的记录的修正。
事件驱动发布是一种解决方案，它依赖于更新记录的组件登记。这个解决方案不适合那些需要旧策略并将责任推给应用程序的工作条目。入栈技术本身可能不提供显示需要的准确度。
数据发布检查点
没有从最终容器返回有意义反馈的数据入栈的复制不能保证每个服务应用正确给定工作条目的策略版本。服务依赖他们本地库的更新速度，分布式库及高性能 SOA 增强同步延迟及错误策略应用程序的水平。仍留有问题：解决方案如何保证每个服务每次都使用正确的策略修正？解决方案如何保证它包括所有新的及以前的策略版本，并且它能在发布及响应环境中进行操作么？
PMS 需要工作条目请求特定的版本以允许服务检查其是否有正确的版本。这个方法可以为旧的及非常新的策略工作。
现在服务可以显式请求正确的版本。可以使用复制将其重新移入分布缓存中，策略修正请求保证服务使用正确的版本。
第一个结构原则是：将每个工作条目标记上正确的策略修正。
标记工作条目
图 4. 标记工作条目
原则没有说明如何完成正确策略修正每个标记工作条目。操作是使用需要运算法则来确定正确版本的一般标签来标记，或使用显式的策略修正信息来标记。
常规标签是从信息的固有数据或从为策略管理的单独目的而添加的专用的标签中创建的。
固有标签使用现有数据（例如，日期及时间）并向属性添加含意。添加的含意对维护工程师及操作人员不会立即变得明确。使用这个方法，就会限制额外内容的灵活性，操作（如，改变已应用的策略版本）也会受到损害。
专用（非固有）标签经常从生成器容易获得的信息中生成。这简化标签的生成，但需要查找算法来找出正确的修正或版本。查找可能确定最新的修正，在这之前一天的，两天之间的或后一天的。这些算法实现起来复杂，当需要的实际修正不在库中或不符合应用的算法时，查找就会失败。算法会脱节于从任何特定修正的显式请求，他们销毁需要的及不适合的反馈。
显式标签描述对单一显式策略修正的直接连接。添加他们只是为策略管理的目的。
SOA 包含许多服务，每个服务中都定义有一个或多个策略且以不同的级别修正。如果解决方案列出工作条目需要的所有策略修正对，那么该解决方案就会变得臃肿且易于出错和变得混淆。这个方法强制这个标记类型假设每个工作条目需要每个服务及策略。
通过创建及存储指定的共同工作的策略修正列表，您可以在 SOA 中创建所有策略的一套相应的特定的修正。然后就有可能用这套策略修正的名字作为显式标签而不是作为列表本身。第一个实现原则是：使用策略集合在结构的入口处分别标记每个工作条目。。
策略集合
图 5. 映射到策略的策略集合
将每个策略的一个版本放置在指定的集合中创建策略集合。标记为策略集合的工作条目与那些策略修正有直接的关系。没有必要将每个修正都列入工作条目中，需要的标签的数目减少到一个。标记为相同策略集合的工作条目（工作流）组以一致的及可预测的方式使用相同的策略及流程。
服务可以使用策略集合及策略名显式的请求他们需要处理的这个工作条目的策略版本。
策略的一个版本可以存在于许多策略集合中，但一旦它被部署在一个集合中就不能再对其进行修改。对策略的“更新”导致生成及更新了一个新的策略版本。.
通过使用检查或数字签名，易于区分 key-not-found（缓存不完全）与 invalid-key（不进行远程请求，他们就不会知道彼此）之间的不同，您可以检查改变及策略的完整性。例如，使用排序代码和银行账户号码访问客户的简介。如果没有找到，使用排序代码取得该客户的默认信息。
成功的策略及策略集合部署确保取得的使用策略名及策略集合的策略总是正确的，没有过多的开销或当缓存时没有缓存合法性问题。
策略所有权及域
策略是特定服务的独有职责及属性，但可能被那个服务的所有实例所使用。这个限制保护执行的独立性及简化变更管理。要保护这个清楚的划分，PMS 需要提供防止其他小组对策略更新的控制。属于重实现或不赞成的服务的策略可以被废弃以保护解决方案的长期合法性。
一个服务需要用其他服务注册的情况确实存在（例如，使用报告执行服务注册报告）。有利的方面是，所有权限制澄清了事件的状态。首先，报告清楚的保留第一个服务的属性及职责并被放置在服务的策略当中。PMS 需要报告执行服务访问那个策略设置的机制。
域是类或类型并表示数据的规则、语法及语义（例如，它必需是整型、浮点型、图片类型等等）。域是分配给规则及格式的名字。
将域添加进策略设置使得策略管理员依据值并识别那个值属于已知的特定的域来增强那些域规则及格式。策略管理员可以使域允许服务定义新的域。名字及合法性规则是策略设置，域是，例如，PMS$DOMAIN。
取得策略设置的通常的方式是从特定的策略集合中请求策略，并从特定的策略修正中产生所有的设置。PMS 可以通过允许客户端服务通过域名访问策略集合中的多个策略取得策略设置来实现一个服务通知另一个策略的能力。例如，Name = My Report，Value = "Report file + instructions."，Domain= REPORT
由域来获取可以保留正确的所有权规则并可以防止不同服务策略间的交叉。它为服务提供简单的机制使用其他服务在保留所有权情况下注册构件。
实现意见
对已部署策略的更改会导致在新的策略集合中创建新的策略修正。新策略集合需要被显式的部署以供产品服务所使用。显式部署允许更改进行测试、控制及授权。部署检查所有策略及策略集合，标记他们为不可变。
服务连接 SOA 在接收工作前取得他们的技术策略，但从工作条目中取得策略集合。新服务不需要显式策略同步。
工作条目使用正确的策略集合单独标记。服务可以支持多并发策略且可以为每个工作条目准确的应用正确的策略。
当策略集合进入体系结构中，它就被分配给每个工作条目。策略集合是最新的集合、名字集或策略集合分配给特定的工作流。如果策略管理员支持策略集合请求，例如，允许 PolicySet = "" 或 PolicySet = "WS$<Name>" 或 PolicySet = "PolicySetName"，处理相同工作流的不同网关不需要相互同步。
空白策略集合的工作条目被分配给指定的策略集合，通过第一个服务请求该信息。使用最新策略集合的名字，工作条目也被从那一点向前被标记。
以一个工作流标识符标记的工作条目，使用与命名策略集合相同的方式用工作流 ID 分解。如果工作流 ID 别名已经分配给了策略集合，请求可能会得到本地缓存的回绝。否则，请求救会被送到策略管理服务。服务为策略集合分配别名，以集合及影射作为回应。
如果不可变约束不合适，必需允许在任意时刻改变策略。如果由数据过期来管理刷新，就像 Web 页面情况一样，那么可以使用策略或策略集合内部的关键字，来通知任意的缓存，告诉他们数据可以保持多长时间的方式来实现。例如，PolicyCacheDirty 被设置为 "REALTIME"，显示如果策略过期每次都使用 DateTime / DeltaTime 检查策略的改变。
当使用过期机制时，可以告知 PMS 使用另外一个关键字。例如 PolicyVersionChange 设置为“On Change”显示改变或新值的增加都会导致策略新版本的产生。
结束语
策略被组织为策略集合而发布。策略集合由许多属于单独服务的策略组成。每个策略都被命名并归属到版本控制中。不能改变已部署的策略，而且都使用了数字签以允许任何服务检查它的可靠性和完整性。工作条目通过指定策略集合指示活动策略。三个重要的方面包括：
- 可以使用不同的策略处理不同线程处理的多条目。
- 策略数据可以被复制或缓存，而且没有使用过期数据的风险。
- 工作条目为其自身请求正确的策略。
这确保工作条目取得他们需要的策略，并去除对同步服务策略缓存复杂模式的需要。
策略通过其单独的、专用服务、强制唯一的、一致的语法及域控制语义来构造、维护及部署。应用到工作条目的策略的预测为企业提供了强大的诊断及管理工具。
解决方案为业务提供了以受控及可追踪方式改变策略的能力，及在工业及联邦法律的约束下实现其公司的管理需要（Sarbanes-Oxley Act 2002）。