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.
Principles Standardized Service Contract, Service Abstraction, Service Discoverability	Architecture Inventory, Composition, Service
Status Suspended	Contributor Mark Little, Thomas Rischbeck, Arnaud Simon, Thomas Erl

Problem

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 because of overlap with the Policy Centralization design pattern that had already been part of the pattern catalog for some time. Inventory-wide “enforcement” of polices alone was not enough to justify a design pattern, and the support for establishing global and domain-level policies was already covered by Policy Centralization.

- Thomas Erl