In Chapter 2, we introduced the service contract, which is an explicit representation of the relationship between a consumer and a provider. The contract initially focused on providing a functional interface, along with a delivery schedule, if the service did not exist yet. However, there is much more to the service contract. The contract needs to also specify the policies that govern the run-time behavior of the service. In the example in this chapter, two run-time policies are required to enable the behavior that was described. The first is that the request needed to contain appropriate credentials to identify the source of the request. The second is that the request needs to be routed to a specific version of the service. While this may not seem important with the initial service implementation and its consumers, as soon as the next consumer comes along and requires a modification, as was the case in our example, this policy becomes very important.

Policy-Driven Infrastructure

One reason for the formalization of the service contract is to allow the infrastructure to easily enforce the policies. First made popular in the context of web access management solutions, policy-driven infrastructure has four primary components as shown in the following figure:

The first component is the policy management point, also known as the policy administration point. This is where the administrator would enter the policies associated with the service contract. The policy management point would also be the place where management services would be exposed for data center automation opportunities.

The second component is the policy information point. This is the backing repository where policies entered via the policy management point are stored. When applied to SOA, the Service Registry/Repository can play the role of the policy information point.

Moving into the actual run-time path of requests, the third component is the policy enforcement point. This is where requests are intercepted and any applicable policies are enforced.

The final component, which is frequently co-located with the policy enforcement point, is the policy decision point. This is where the decision is taken on what to do when enforcing each policy.

To understand the relationship between a policy enforcement point and a policy decision point, consider a real world example. If you are driving a car and reach an intersection with traffic signals, you are at the policy enforcement point. All cars must pay attention to the state of the traffic signal to determine whether they can proceed in their desired direction or not. The traffic signal itself is the policy decision point. B ased upon embedded sensors in the street or timers, the light is either red, amber, or green, which represents the decision on how to handle traffic from each direction. In this example, the policy enforcement point and the policy decision point are co-located.

Now, suppose you have driven your car to the entrance of a gated community. The gate, however, is unmanned. Instead, there is either a video camera or an intercom at the gate. The gate represents the policy enforcement point. The policy decision point, however, is not at the gate. The policy decision point is wherever the security personnel is sitting watching the feed from the camera or listening to the audio from the intercom.

Next Page: SOA Development - Extending the Service Contract - Page 2