Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Policy Enforcement (candidate)
|
Home > Candidate Patterns List > Policy Enforcement
|
|
How can policy assertions be consistently processed and enforced across a service inventory?
|
|
|
|
Problem
When building services as Web services, the use of WS-Policy assertions may not be supported by all parts of the service inventory, especially when policy assertions are added to service contracts subsequent to service implementation.
|
|
|
Solution
The inventory architecture is equipped with policy processing and enforcement features.
|
|
|
Application
A standard policy framework is implemented within the inventory architecture.
|
|
|
|
Impacts
The runtime interpretation, processing, and validation of policy assertions can add performance overhead, especially when larger policy vocabularies are used.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributor
Mark Little, Thomas Rischbeck, Arnaud Simon, Thomas Erl
|
|
|
|
| |
Services built as Web service can have technical contracts that can be extended to include non-functional interface requirements, such as security, transaction, reliability, or business rules-based characteristics. These can be expressed through the use of WS-Policy definitions that are comprised of one or more policy assertions.
Because policy assertions are an optional part of a service contract, a service inventory architecture may not have been outfitted with the necessary infrastructure to process policy information across all services. This can limit the applicability of policies to specific consumers and services that have been individually extended with policy features. As a result, services may be required to employ the Concurrent Contracts pattern to provide other consumers with a contract that is not policy-enabled.
Furthermore, because policies are often used to express QoS-related requirements, service owners may not recognize the need for policies until the service has been in use for some time. In this case, policy assertions are added subsequent to service implementation, which can effectively introduce a new version of the service contract. This can lead to governance issues and further limit access to the service to only those consumers that can be customized to support the new policy requirements.
An inventory-wide policy processing framework is implemented so that policy assertions are naturally supported and enforced whenever required.
Contributor Notes
This design pattern description was based on one of the original contributions from Mark, Arnaud, and Thomas R. (all of whom are authors for the upcoming "ESB Architecture for SOA" book for the Prentice Hall Service-Oriented Computing Series from Thomas Erl). After much discussion it was decided to not include this pattern at the time because of overlap with Policy Centralization, a pattern that had already been part of the pattern catalog for some time.
- Thomas Erl
|
|
|
