Service Versioning in a SOA

By James Pasley

Even the smallest Service Oriented Architecture (SOA) deployment requires that a strategy be in place for the deployment of new versions of its services. This paper describes a strategy for the versioning of services within a SOA. Support for service versioning within a Service Oriented Architecture (SOA) is addressed by allowing multiple versions of a service to co-exist on the Enterprise Service Bus (ESB). This turns a versioning problem into a routing problem. Messaging flowing through the ESB must be routed to the appropriate version of the service. This approach to versioning involves a number of related concepts:

• Compatibility: which versions of a service a message can be routed to is dictated by the level of compatibility between versions.
• Migration: the migration of clients to the latest version of each service is necessary in order to provide clients with new feature or fixes. It is also a means of limiting the number of versions which remain in production. The level of compatibility between versions dictates which migration strategies are possible.
• Responsibility: once a new version of a service is deployed, the question of who takes responsibility for the migration will be an important factor in deciding which of the possible migration strategies is chosen.

The routing of messages to the appropriate version of a service combined with the three concepts of compatibility, migration and responsibility form the foundation of the versioning strategy for services within a SOA. This paper looks at each of these areas and explains how they can be approached.

Service Co-existence

The reuse of services is one of the main goals when deploying a SOA. The fact that an individual service may be reused as part of a number of different applications or business processes requires a well thought out approach to versioning. It must be possible to make improvements to the service without requiring simultaneous changes to all applications that use it. Deploying new versions of the service which co-exist with old ones provides the most flexibility when solving this distributed versioning problem. New services can be deployed as separate independent services to new end-points on the ESB. These services can run in parallel for a period of time until the old version falls into disuse and can be removed. An application which continues to use an old version of a service must not become a drag on new development. A versioning policy should be publicized outlining the technical details of the versioning strategy and the responsibilities of both clients and service providers. Such a policy will include rules relating to the lifecycle of a service. For example, a statement in relation to service lifecycle could be as simple as the following:

An existing version of a service will continue to be available for six months after a new version is deployed. After this time is may be removed. Clients are expected to complete migration to the new service within four months of it becoming available.

Message Routing

One of the advantages of using an ESB as part of a SOA is the ability to hide the actual service location from the client and instead publish a virtual endpoint. Clients send requests to this virtual endpoint hosted on the ESB allowing the ESB to route the message to the appropriate version of the service. This approach requires that there is sufficient information in each message to perform the routing. At the very least this should take the form of a version number identifying the version of the service interface that the client was originally developed for. This could be included in the body of the message or as part of a SOAP header. For example, a WS-Addressing End Point Reference could be used to contain this information. Messages will be routed independently, so the version information needs to be included in each and every message. Routing decisions will often need to be based on more than just a version number. For example, when a new version of a service becomes available you might choose to move customers to the new version one at a time. This will require that a customer identifier is present in each message in order to perform the appropriate routing. The fact that routing decisions will be made based on the contents of messages highlights the need to define the versioning strategy before the web services are designed and implemented so that this information is included in the service interfaces. This approach to versioning which is based on the co-existence of services can be extended to dealing with new versions of the ESB itself. Services can be deployed into a new version of the ESB and messages routed to them in exactly the same way. Eventually, all services on the old version of the ESB will fall into disuse and that version of the ESB can be decommissioned.

Compatibility

The ability to route a message originally intended for one version of a service to another version depends on the level of compatibility between versions. When compatibility is discussed in relation to Web services, two varieties are often mentioned. These are defined in the WSDL 2.0 Primer as [1]:

• Backward compatible: The receiver behaves correctly if it receives a message in an older version of the interaction language.
• Forward compatible: The receiver behaves correctly if it receives a message in a newer version of the interaction language.

Ideally, changes to a service should be backwards compatible. This reduces the effort involved in the migration of clients. Compatibility must start with the interface to the service. There are a number of strategies which allow a service interface to be modified without breaking backwards compatibility. The general rule here is to add optional data to the interface, but do not modify for remove data. You can add an operation, or you can add an optional element to an existing data type. Adding additional data to a response message will affect existing clients. The service should not return data to a client which it might not be able to handle. This means that a backwards compatible service will need to be aware of the version of the interface the client was developed against and act accordingly. This is most easily achieved by passing a version number in each request message. It may not always be possible to make all services backwards compatible in which case the client application will need to be modified in order to make use of the new version. The coexistence of multiple versions of the service on the ESB provides clients with the opportunity to make these changes in their own time. Forwards compatibility is much harder to achieve. There are a number of strategies which exist at the syntax level which can allow this to be supported. This will allow a message to contain new data without causing a validating parser to reject the message. However, achieving the correct behavior within the application itself is much harder and can only be applied to particular tasks where a default semantic can be applied to new data. A pragmatic approach to compatibility will aim to make services backwards compatible, but will not attempt to make message formats forwards compatible. For a more complete discussion on achieving compatibility of within Web service interfaces see Avoid XML Schema Wildcards For Web Service Interfaces [2].

Migration Strategy

Having compatible versions of services coexist on the ESB provides you with great flexibility in choosing a migration strategy. The goal is to move all clients to the latest version of the service in a controlled and timely fashion. The possibilities range from a big bang approach where you switch all traffic to the latest version to one where you inform clients that a new version exists and leave them to choose when to move. You may even choose to move customers individually based on criteria such as the volume of traffic they produce or the value of the transactions they typically send. A significant factor in choosing a migration strategy is the question of who is taking responsibility for the migration. If you choose to start routing clients’ requests to the new version without their knowledge and agreement, you are taking responsibly to ensure that everything will go smoothly. By sharing this information with the client and agreeing a timeframe for the move you are sharing some of this responsibly. You may choose to run a new version of the service in beta as part of the migration strategy. You may also need to expose test versions of the service to allow clients to test interoperability with the new service. This is particularly true in situations where the new service is incompatible with the old version. Where services store state or have a process lifecycle (as is the case for BPEL services) the migration strategy will need to take account of this. In this case new transactions can be routed to the new version of the service while requests associated with existing transactions will be routed to the existing service. Eventually all processes on the old version will run to completion at which point all traffic will be targeted at the new service. Where services are reused by multiple applications care needs to be taken that a system of interlocking dependences does not occur. This could make it difficult to upgrade services independently of each other. Applying good SOA design principals will limit the possibility of this occurring. In particular, design services to perform a specific business function and be self contained. In other words, services should not have hidden inter-dependencies. The successful invocation of an operation on one service should not depend on the invocation of an operation on another service either before or after.

Conclusion

The versioning of services within a SOA requires that new versions be deployed in parallel with existing ones. Wherever possible these services should be backwards compatible. Clients can then be migrated to these new versions based on message routing rules or by updating the client applications themselves. References

1. David Booth, Canyang Kevin Liu, Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, World Wide Web Consortium (W3C) Candidate Recommendation, 27 March 2006, http://www.w3.org/TR/wsdl20-primer/.
2. James Pasley, Avoid XML Schema Wildcards for Web Service Interfaces, 2 Oct. 2006; http://developer.capeclear.com/?q=compatibility.