SOA Pattern of the Week (#7): Policy Centralization

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.

In this series

• SOA Pattern of the Week (#1): Service Façade
• SOA Pattern of the Week (#2): Non-Agnostic Context
• SOA Pattern of the Week (#3): Domain Inventory
• SOA Pattern of the Week (#4): Service Normalization
• SOA Pattern of the Week (#5): Service Decomposition
• SOA Pattern of the Week (#6): Canonical Schema

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine