所谓策略就是服务客户通常必须要遵守的一套要求或规则，目的是请求服务并与服务互动。我们这里用“通常”这个词是因为可以有可选择策略、可忽略策略、甚至策略替代，这样作为一个策略者，在策略如何能够扩展发布服务合同方面，就被赋予了很大的灵活性。

　　策略能应用于不止一个服务，这是一个普遍现象。在这种情况下，通常不愿意额外的将这些策略与多重服务合同相应用，这是因为如果IT企业有任何形式的冗余（数据、逻辑等等），为了将这些策略的内容在以后的时间内保持同步，会给我们带来治理负担。例如，当策略变化时，我们需要升级所有包含策略的服务合同，以便能确保此变化能完全被应用。即使这样，拥有冗余策略还会有风险，因为你可能有不同的人来完成升级，而这就造成了不同的结果。

　　因此，基于相同的推理，都遵循Schema Centralization模式（我们被鼓励共享模式，描述共同的数据模型跨接多重合同），Policy Centralization（策略集中模式）提倡我们以单一定义形式保留可再利用的策略，并将策略应用的服务合同与此定义相连并共享。

　　结果，我们可以建立应用成套服务的域策略，甚至是应用所有服务的共用策略。因为一个模式主要的与服务清单架构联系，有一点需要指出，当我们应用此模式的时候，我们要在一个已知的服务清单边界范围内这样做。因此，共用策略只有与它适应的服务清单的范围相联系的时候，才能称之为共用的（特别是当适应Domain Inventory pattern（域清单模式）时候）。

　　虽然策略集中和模式集中之间有架构方面的类似性，但是也有一些显著的区别，首先就是关于策略在内容和功能方面如何能够区别于模式。例如，一个集中的模式经常提供一个标准的数据模型（根据Canonical Schema），当分享普通业务文件时，通过允许服务，避免使用转换技术，帮助确保基线兼容性。另一方面，我们倾向于更少的集中策略以便能避免在他们之间转换，但要更多的支持集中监管模型，使我们能够从一个位置做大规模的改变。

　　因为业务文档的数据模型，比如发票，在某一时刻，很有可能需要及时的改变，我们通常期望（或者希望）这种类型的改变不是经常性的，因为大多数业务文档在结构上是相对稳定的。但是策略经常关系到一个组织怎样选择或被授权执行此业务。通常策略是外部定义的，比如当一个策略关系到客户的政府法规或者法律条款。任何这些资源都可能在没有被关注的情况下造成改变，这就要求我们的服务能够为组织对这种早晚都会出现的变化做出反应，整体上保持策略的一致性。使用更多的易失策略，将策略定义集中可以非常有效的减少监管力度，但仍能维持一个全面敏捷的IT企业。

　　与模式集中有些类似，集中的策略也是集中验证。例如，一个共享的XMLSchema，使用运行时分析程序，就可以被验证，分析程序也只需遵循XML模式定义规范法则，以确保已知的XML文件与数据模型相符（由Schema来定义）。策略依赖于由中间件提供的策略执行点，根本上，在符合策略定义的基础上，也采用验证程序用以接受或拒绝一个已知的信息。对于WS-Policy的定义，这种验证通常通过一个分析程序来运行，这个分析程序执行WS-Policy和WS-Policy的附件规范规定的法则。

　　但是，当你拥有多层域和共用策略时，要比你用多重集中的模式验证数据时，这类验证和执行变的更复杂。WS-Policy 规范没有表达的一方面是策略冲突解析。这意味着如果你的域策略与共用策略有冲突，你要负责建立所需要的逻辑，用来解析这些差异，以避免所有这些运行时异常状况。

　　在一个多层策略层环境里面，要建立并保持集中的策略会带来各种监管问题。当我们要改变现有的有效策略或者引入新方案时，我们需要确保这些对现存策略架构的改变不会带来负面或不可遇见的影响，最坏的结果可能是连带效应，导致多层策略（与多重服务）每个层面都会出现异常。

　　另一个值得注意的是，虽然XML模式验证只是与工业标准的XML模式分析程序一起被执行，WS-Policy支持仍然非常不普及。一些ESB产品和消息传递中间件仍然建立在自定义策略概念和强制逻辑的基础上，提供专有的策略架构。虽然策略集中模式仍能在这些环境中应用，但它还是能够在未来的某个时刻导致传统开发商锁定方案。

　　最后，有一方面在这篇短文里面没有讨论，但又确实值得注意，那就是这种模式对于可再利用的安全策略的定义和部署很重要。当建立现代服务安全架构时，通过这些策略，能够分享、集中地监管和执行安全控制已经成为一种流行的做法。