一项政策要明确说明服务消费者通常必须遵守的一套要求或者规则，以便调用一项服务和与那个服务互动。政策集中化模式主张我们把一个可重复使用的政策保持在一个定义中。
　　政策集中化模式主张我们把一个可重复使用的政策保持在一个定义中，并且让这个政策适用于服务合同、与服务合同相关联以及共享这个政策。

　　一项政策要明确说明服务消费者通常必须遵守的一套要求或者规则，以便调用一项服务和与那个服务互动。我们在这里使用“通常”这个词汇是因为你可以有一些可选择的政策、可忽略的政策、甚至为你提供的替代的政策。这些替代的政策将在如何让政策扩展发表的服务合同方面向你提供一些灵活性。

　　人们经常会遇到适用于多项服务的政策。在这种情况下，过多地在多个服务合同上使用这些政策通常是不理想的，因为在IT企业中的任何冗余(数据、逻辑、等等)都会给我们保持这些政策内容的同步增加治理负担。例如，当政策发生变化时，我们需要更新包含这个政策的所有的服务合同以保证全面执行这些变化。甚至在这个时候，拥有冗余的政策也是有风险的，因为你也许会让不同的人实施这个更新，从而导致不同的结果。

　　因此，这些理由是模式集中化方式的基础。根据同样的理由，这个政策集中化方法要求我们把一个再利用政策保持在一个定义中，并且让这个政策适用于服务合同、与服务合同相关联和共享这个政策。

　　因此，我们能够建立适用于一套服务的区域政策、甚至建立适用于所有的服务的全球政策。作为主要与服务目录架构相关的一种模式，重要的是指出当我们使用这种模式的时候，我们是在指定的服务目录范围内做这个事情。所以，一项全球政策只是相对于它适用的服务目录范围而言的。

　　虽然政策集中化与模式集中化在结构上有许多相似之处，但是，它们之间还有一些明显的区别，主要是这种政策在内容和功能方面与模式政策有很大区别。例如，一个集中的模式政策通常提供一种标准化的数据模型(如典型示意图)，通过允许服务在共享通用的业务文件的时候避免依靠转换技术来保证基线的相互兼容。另一方面，我们倾向于较少地集中化政策，从而避免在政策之间进行转换，而是更多地支持集中的治理模式，使我们在一个地方进行大量的修改。

　　虽然业务文件的数据模式(例如一个发票)肯定需要在某些时候进行修改，我们通常指望(或者希望)不要频繁地进行这种类型的修改，因为大多数企业文件在结构上是相对稳定的。然而，政策通常与一个机构如何选择或者按规定执行其业务有关。政策通常是在外部定义的，例如，当一个政策涉及到政府法规或者客户的法律条款的时候。任何这些原因都会在人们没有关注的情况下强制对政策进行修改，要求我们的服务尽快对这些修改做出反应，保证整个机构遵守政策。由于政策是多变的，集中定义政策对于最大限度地减少治理的负担是非常有效的，同时，保持IT的总体灵活性和反应性。

　　政策集中化与模式集中化的一个相似之处还包括集中化的政策是集中验证的。例如，一个共享的XML方案将使用一个运行时间分析器进行验证。这个运行时间分析器遵循XML Schema Definition(XML模式定义)技术规范中的规则保证指定的XML文件符合这个模式定义的数据模式。政策依赖于由中间件软件提供的政策强制执行点。这个中间件软件根据其遵守政策定义的情况执行一个验证过程以接受或者拒绝一个指定的信息。对于WS(Web服务)政策定义来说，这个验证过程通常是由一个分析器处理的。这个分析器强制执行在WS政策和WS政策附件技术规范中定义的规则。

　　然而，当你有多层的区域政策和全球政策时，这种类型的验证和强制执行要比使用多个集中的模式进行验证更复杂。WS政策没有解决的一个方面的问题是政策冲突的解决方案。这意味着如果你有一个与全球政策冲突的区域政策，你要建立一个解决这些冲突所需要的逻辑，以避免发生各种不愉快的运行时间意外情况。

　　在一个拥有多个政策层的环境中建立和维护集中的政策的责任能够引起各种治理的难题。在我们需要改变当前的积极的政策或者引进新的政策的时候，我们需要保证对现有的政策架构做出的改变没有负面的或者看不到的影响。其中最严重的影响是连级效应，造成多个政策(和多个服务)出现意外情况。

　　还值得指出的是，虽然 XML Schema验证只是采用行业标准的XML Schema分析器执行的，但是，支持WS政策还不普遍。一些企业服务总线产品和消息中间件软件继续提供基于客户政策定义的和强制执行逻辑的专有的政策框架。虽然政策集中化模式仍然适用于这些环境，但是，它在以后的过程中能够导致典型的厂商锁定状况。

　　最后，本文没有讨论的但是肯定值得了解的一个方面是这种SOA模式对于定义和部署可重复使用的安全政策是非常重要的。在建立现代服务安全架构的时候，能够共享和集中地治理以及强制执行政策规定的安全控制已经成为一种流行的做法。