SOA Pattern (#1): Service Façade > Thomas Erl brings you the first SOA Pattern of the Week, a series 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.”
One of the fundamental goals when designing service-oriented solutions is to attain a reduced degree of coupling between services, thereby increasing the freedom and flexibility with which services can be individually evolved. Achieving the right level of coupling “looseness” is most often considered a design issue that revolves around the service contract and the consumer programs that form dependencies upon it. However, for the service architect there are opportunities to establish intermediate layers of abstraction within the service implementation that further foster reduced levels of coupling between its internal moving parts so as to accommodate the evolution and governance of the service itself. SOA Pattern (#7): Policy Centralization >
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.
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.
SOA Articles.