Putting this in the context of our versioning example, a request from a service consumer would be intercepted by the policy enforcement point. The policy enforcement point would extract the message content, and hand it off to a policy decision point. The policy decision point would examine all applicable policies for the service requested from the policy information point. There will be some policies that are universally applied, such as requiring that some form of identity be on all service requests. From that point, the identity can be authenticated and authorized, according to the policies in the service contract. Once identity is established, policies that may be specific to the service contract between the specific consumer associated with the identity provided and the service being requested can be enforced, such as what version of the service should receive the request, and whether any of the transformations will be applied. All of these policies should already be in the policy information point as a result of previous actions by an administrator via the policy management point.

Mapping this conceptual approach to the actual infrastructure associated with your SOA efforts typically takes one of the following two forms, or a combination of the two.

This model is a gateway-based approach (or brokered gateway pattern). A service consumer never interacts directly with a service provider; rather the request is first directed through a gateway that is responsible for policy enforcement and policy decisions. More often than not, the gateway also maintains a cache of policies locally to avoid having to establish a connection with the policy management point for every service request. The management console for the service gateway is the policy management point. This will include some form of backing stores for the policies.

In this agent-based model, an agent is deployed on the service provider platform. This agent is typically configured as part of the platform configuration and not as part of the actual service. The agent plays the exact same role as a service gateway, with the only difference being that it performs its logic in the same execution thread as the actual service, should the policies allow the request to be processed.

While these two diagrams represent two common approaches, individual vendor products in this space can take different architectural approaches. Some may externalize the policy decision point, changing the role of the cache to be a decision cache, rather than a policy cache. Some may utilize a service registry/repository for the policy store; others may require the use of a dedicated database. Some products may include both gateways and agents, and some may even include consumer-side agents in addition to the more typical provider-side agents.

First Page: SOA Development - Extending the Service Contract