SOA Pattern (#7): Policy Centralization
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A policy expresses a set of requirements or rules that service consumers usually must adhere to in order to invoke and interact with a service. We use the term “usually” here because you can have optional policies, ignorable policies, and even policy alternatives that give you, as the policy author, a great deal of flexibility as to how policies can extend published service contracts.
It is common to run into policies that apply to more than one service. In this situation, it is generally not desirable to redundantly implement these policies across multiple service contracts because, as with any form of redundancy (data, logic, etc.) within the IT enterprise, it places a governance burden upon us to keep the content of those policies in synch over time. For example, when the policy changes, we need to update all of the service contracts that contain the policy in order to ensure that the change is fully applied. Even then, having redundant policies can be risky because you may have different people performing the update, resulting in different results.
Therefore, following the same reasoning that underlies the Schema Centralization pattern (where we are encouraged to share schemas representing common data models across multiple contracts), the Policy Centralization pattern advocates that we keep a reusable policy in a single definition and have service contracts to which the policy applies, link to and share this definition.
As a result, we are able to establish domain policies that apply to sets of services and even global policies that apply to all services. As a pattern that is primarily associated with service inventory architecture, it is important to point out that when we apply this pattern, we are doing so within the boundaries of a given service inventory. Therefore, a global policy is global only in relation to the scope of the service inventory it’s applied within (a distinction especially relevant when applying the Domain Inventory pattern).
Although there are architectural similarities between Policy Centralization and Schema Centralization, there are also some notable differences that primarily relate to how policies, in content and function, can vary from schemas. For example, a centralized schema often provides a standardized data model (as per Canonical Schema) that helps ensure baseline interoperability by allowing services to avoid having to resort to transformation technologies when sharing common business documents. On the other hand, we tend to centralize policies less so to avoid having to convert between them, but more to support a centralized governance model that enables us to make wholesale changes from one location.
While the data model of a business document, such as an invoice, certainly may need to change at some point in time, we usually expect (or hope) that this type of change is not frequent because most business documents are structurally relatively stable. However, policies are often tied to how an organization chooses to or is mandated to carry out its business. Often policies are externally defined, such as when a policy is tied to a government regulation or perhaps to legal terms with clients. Any of these sources can impose change without much notice, requiring that our services respond to such change sooner than later for the organization as a whole to remain policy-compliant. With more volatile policies, having the policy definitions centralized can be extremely effective to minimize governance effort, while maintaining an overall agile and responsive IT enterprise.
A similarity with Schema Centralization is also that centralized policies are centrally validated. A shared XML Schema, for instance, will be validated with a runtime parser that simply follows the rules of the XML Schema Definition specification to ensure that a given XML document is compliant with the data model (as defined by the schema). Policies rely on policy enforcement points commonly provided by middleware, which basically also follow a validation process to accept or reject a given message based on its compliance to the policy definition. For WS-Policy definitions, this validation is generally processed by a parser that enforces the rules defined in the WS-Policy and WS-PolicyAttachment specifications.
However, when you have multiple layers of domain and global policies, this type of validation and enforcement can become significantly more complex than when validating data with multiple centralized schemas. One area that the WS-Policy specification does not address is policy conflict resolution. This means that if you have a domain policy that contradicts a global policy, it is up to you to build the logic required to resolve these differences in order to avoid all kinds of unpleasant runtime exception conditions.
The responsibility to build and maintain centralized policies in an environment with multiple policy layers can introduce various governance headaches. When we need to change currently active policies or introduce new ones we need to ensure that these changes to the existing policy architecture do not have negative or unforeseen impacts, the worst of which can be a cascading effect that causes exceptions that compound across multiple policies (and multiple services).
It’s also worth noting that while XML Schema validation is just about always carried out with industry standard XML Schema parsers, WS-Policy support is not yet nearly as common. Some ESB products and messaging middleware continue to provide proprietary policy frameworks based on custom policy definition and enforcement logic. Although the Policy Centralization pattern can still be applied in these environments, it can lead to classic vendor lock-in scenarios down the road.
Finally, one area not discussed in this brief article but certainly worth acknowledging is the importance of this pattern to the definition and deployment of reusable security policies. Being able to share and centrally govern and enforce security controls expressed via policies has become a popular practice when building modern-day service security architectures.
For more about authoring and versioning WS-Policy definitions, see the book Web Service Contract Design and Versioning for SOA, ISBN: 013613517X, Prentice Hall, (www.soabooks.com).
The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).