SOA Development - Summary

In this chapter, Advasco was faced with the challenge of service versioning. A new consumer had requested some changes to the Customer Information Service, but the existing consumers could not accommodate the changes necessary in the timeframe required. Led by the SOA Center of Excellence, a decision-making process was used to determine the best course of action, which was to support both the old interface and the new interface, either by deploying two versions of the service, or leveraging transformations in the middle to ensure backward compatibility.

While this solved the situation for the Customer Information Service, the CIO was concerned that this would not be the end of the versioning debate. The Center of Excellence debated this and introduced a policy that balanced the needs of the service consumers with the needs of the team providing the service. The policy was to support up to three versions of a service in production.

Service versioning is a very important issue for an enterprise to deal with in order to achieve the agility goals desired. If policies are not established, contention will arise. It can be between individual consumers of the same service, or between consumers and the service provider.

The need to support multiple versions also introduces the role of policy-driven infrastructure in a run-time environment. If multiple versions of the service are deployed simultaneously, there must be a mechanism for routing requests from specific consumers to specific versions of the service. The version desired could be explicitly specified as part of the request, or the service contract can be used to define a policy that can be implicitly enforced by the run-time infrastructure.

Policy-driven infrastructure has four key components. First, a policy management point allows policies to be administered. Second, a policy information point allows policies to be stored and retrieved. Third, a policy enforcement point exists in the run-time path of the request, intercepting it to allow policies to be enforced. Finally, a policy decision point is where decisions are made based upon the message content and the policies that are applicable to the interchange at hand.

Examples of policy-driven infrastructure include the ESB, XML appliances, service management platforms, and service frameworks.

However, policies and infrastructure alone may not allow versions to be easily managed. By changing the culture of the organization from one that deals with change on an ad hoc basis to one that anticipates change, versioning can be managed much easier.

Organizations today typically provide technology capabilities through the use of projects. A project lifecycle has a clear beginning and end, but the solutions produced by those projects do not. This creates a mismatch when a solution needs to change, because a new project with potentially new staff must be justified, funded, and completed.

An alternative to the typical project-based thinking is to embrace service lifecycle management. Service lifecycle management encourages service teams to view their service as a continual sequence of refinements, with the lifecycle rooted not in the project timeline, but the service's timeline. It begins when version 1 is approved and funded, and ends when the last remaining version of the service is decommissioned from production. The key difference in this approach is between the time a service is deployed into production and the time the next release begins, the service team must focus on monitoring, management, and marketing. Monitoring records the behavior of the system, beyond simple up/down monitoring, management utilizes the data collected by the monitors to increase the understanding of the system behavior by both the service provider and the service consumers. Marketing is focused on finding new consumers in a proactive manner, rather than relying solely on the staff of new projects to properly search the service registry and repository.

By practicing good service lifecycle management, a service team can determine the appropriate timeframe for its releases. Just as enterprises prefer when their major technology vendors provide updates on a regular basis, so should an enterprise's internal service providers schedule their updates. By providing new versions on a regular basis, there will be no surprises for the existing consumers when changes are announced.