Policy Centralization

How can policies be consistently processed and enforced across multiple services?

Problem Policies that apply to multiple services can introduce redundancy and inconsistency within service logic and contracts.
Solution Global or domain-specific policy assertions can be isolated and applied to multiple services.
Application Up-front analysis effort specific to defining and establishing reusable policy assertions is recommended and an appropriate policy enforcement framework is required.	Impacts Policy frameworks can introduce performance overhead and may impose dependencies on proprietary technologies. There is also the risk of conflict between centralized and service-specific policies.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction	Architecture Inventory, Service

Table 8.8 – Profile summary for the Policy Centralization pattern.

Problem

Services may be required to process a variety of individual policies (called policy assertions). Examples of common policies include security and transaction requirements, as well as service availability.

Regulatory polices may affect a range of services, whereas other policies may be service-specific. A service built as a Web service can establish policy requirements as part of its contract via the use of WS-Policy definitions or it may apply policies within its underlying service logic.

When common policy assertions are repeated across multiple service contracts, they introduce redundancy into the service inventory (Figure 8.x). This leads to bloated policy content and increases the governance burden required to ensure that common policies are kept in synch over time.

Figure 8.27 – Each of the four displayed WSDL documents is extended with individual WS-Policy definitions. The red shaded parts indicate the extent of redundancy across policies.

Solution

Policy assertions that apply to multiple services can be abstracted into separate policy definition documents or service agents that are part of an inventory-wide policy enforcement framework. Abstracted policy assertions can be positioned to apply to multiple services, thereby reducing redundancy and providing centralized policy governance.

Figure 8.28 – A global policy definition (Corporate Policy.wsdl) is established and applies to all WSDL documents, and a further domain policy (Claims Policy.wsdl) is created and linked to two WSDL definitions. This new policy structure eliminates redundancy of policy content.

Application

A policy framework needs to be added to the inventory architecture so that policies can be separately defined and associated with services and then validated, enforced, and even audited at runtime.

The WS-Policy framework includes a separate WS-PolicyAttachments specification that explains binding mechanisms for policies. Policy definitions can be embedded within or linked to WSDL documents. To apply this pattern one or more policy assertions need to be grouped together into a policy definition that is made available so that Web service contracts to which the policies apply can add the appropriate references.

Middle-tier platforms (such as those provided by ESB products) can provide policy definition features supported by runtime agents that carry out policy compliance checking. In these environments, global and domain-level polices can also be established via service agents that act as policy enforcement points (Figure 8.x).

Figure 8.29 – Service agents part of an inventory-wide policy framework intercept incoming messages to check for policy compliance. One agent (bottom) enforces a global policy that applies to all services, while the second agent (top) enforces a domain-level policy after global policy compliance was confirmed.

Impacts

Policy definition is an additional step in the service delivery lifecycle that needs to be taken into consideration early on. Part of the analysis involved with defining policy assertions is determining what types of policies should not be made part of the technical service contract.

Some policies may be subject to unexpected change and therefore more likely to demand new contract versions. Other policies may be more suited for a service-level agreement (SLA) that exists as a document used by humans (usually the owners of potential consumer programs). Therefore, the Service Abstraction principle is a key factor in ensuring that the constraint granularity of contract capabilities remains reasonable.

Once global or domain-level policy assertions are established they need to be maintained with a great amount of care. One change or addition to a shared policy assertion will affect all services that rely upon it. This, in turn, affects all service consumers that have formed dependencies on the corresponding service contracts. A governance structure is therefore required, comprised of assigned roles (such as policy custodians) and processes that ensure that common policies are properly evolved.

Furthermore, increased up-front analysis is required prior to the delivery of WS-Policy definitions so that policy assertions are designed with the right balance of constraints and flexibility to accommodate the range of contracts that may be required to use them. A common problem when working with centralized polices is that conflicts can arise between policies at different levels. For example, a new global policy may inadvertently contradict a service-level policy for a particular service. Formal analysis and governance processes can help avoid these situations.

Additionally, the service agents and proxies that establish the policy enforcement points within the inventory architecture can add performance overhead and independent failure modes which the surrounding infrastructure needs to be able to accommodate. Each centralized policy effectively adds a layer of runtime processing and service dependency.

Finally, when implementing a policy framework based on the use of service agents (as part of an ESB product, for example), it is relatively common for WS-Policy definitions to not be fully supported. Instead, the framework may require that policies be defined via front-end tools that output a proprietary policy format. Once deployed, this can lead to undesirable vendor lock-in scenarios that may counter the goal of achieving a vendor-agnostic inventory architecture. The use of proprietary policy assertion formats further can prevent inter-organization data exchange unless both organizations happen to be using the same products.

Relationships

Because Policy Centralization essentially establishes an independent policy layer that extends service contracts, it directly relates to and benefits from Contract Centralization.

The nature of policy logic can vary, but the fact that policies are often based on security regulations can tie the application of this pattern to the Security Centralization pattern. This pattern continues the concepts established by Service Normalization in that it avoids redundancy across policy assertions via centralization, and because Policy Centralization can affect the content of a service contract, there is a further relationship with Validation Abstraction.

Figure 8.30 – The Policy Centralization pattern positions policies within a service inventory architecture and therefore affects other patterns that either relate to the service contract layer or to the nature of policy logic.

ESB products have been credited with popularizing policy enforcement and the concept of centralized assertions, which is why this pattern is one of the common extensions to the core compound Enterprise Service Bus pattern (Figure 8.x).

Figure 8.31 – When supported, the addition of Policy Centralization adds an important layer of quality assurance to the base messaging, routing, and brokerage patterns that comprise the Enterprise Service Bus compound pattern (explained in Chapter 9).

Case Study Example

Case study content is not available on this Web site.