Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

Service-oriented architectures offer many important advantages to the enterprise in terms of agility, flexibility, consistency, reuse, integration and others. But of course, there’s no free lunch. And one of the costs of these advantages is the increase complexity of service lifecycle management and versioning.

Once a service has its first consumer, we have bought off on having to maintain and support that service for an agreed upon period of time. As we evolve the service to enhance functionality or support additional consumers, we introduce new versions of the service, but we still need to support the earlier versions. Like it or not, this is the way SOA works.

Typically, version numbers will have a structure such as: MM.mm.pp consisting of three parts where:

M = Major version
m = Minor version
p = Patch version

Versions are governed by policies which described the rules for:

• Updating major version
• Updating minor version
• Updating patch version
• Backward compatibility
• Support and expiry time for past major versions

Typically, minor changes that are backward compatible require changing the minor version number. Any non-compatible change requires changing the major version number. Bug fixes that do not affect the interface or version require changes in the patch version number. So for, so good? But service versioning can quickly become complicated when we examine the different aspects of a service that can (or should) be versioned. These include:

• The overall service, including all aspects of interface and implementation
• The service interface
• Interface documents or messages
• Schema forming the basis for documents
• The service implementation

One goal of versioning is to keep the consumer of a service from being affected by changes to a service’s contract or behavior. In other words, any change that is incompatible with the existing version of a service requires that a new version number be created and the old version supported. But, although compatible changes do not necessarily require a new version number for the sake of the consumer, they do require a different version number for other purposes. Some different concerns for versioning policies are:

• Change management – How we track and manage the overall deployment of IT resources, and specifically services. Any change to any aspect of the service requires an update to the overall version number of a service. The version number of the service is essentially a combination of the version number of all the individual aspects of the service.
  
• Consumer compatibility – How we decouple the lifecycle of the service consumer from the lifecycle of the consumer provider. Any change to interface, interface document, or behavior of the service will require an update to the interface version. The customer is not be concerned with the overall service version, but only the interface version number. The interface version number is a combination of the interface signature, and the documents that are passed through the interface.
  
• Information management – How we manage shared semantics across services. Any change to an interface document will require an update to both the document version number and the interface version number. Backward compatible changes will be a minor update whereas incompatible changes will require a major update. Remember that documents are based on an underlying semantic schema (information model). Although there are scenarios where the underlying schema can change without affecting the document, for simplicity, we usually require that any change to the schema requires an update to the version number, and a corresponding update to the document version numbers.

 The table below illustrates how changes in internal versions affect the overall service version. Normal text indicates that the explicit change (italicized) in another version number (in the same row) has a ripple effect on that version number. For example, notice that a change in any of the internal versions (interface, document or implementation) will cause a change in overall service version. 

Unfortunately, despite the fundamental importance of versioning to real SOA implementations, few of the SOA infrastructures (ESB, etc.) provide adequate support for versioning. This is an area that consumers should be pushing vendors to support. Until then though, you’ll have to do it yourself. But don’t worry, the benefits of SOA are worth the effort.

Mike Rosen is an independent consultant providing advice and assistance on the design and implementation of SOA, business, application and enterprise architecture. Mr. Rosen is also Co-chair of the BrainStorm SOA Conference Series and Editorial Director of SOA Institute. He has years of experience in the architecture and design of applications for global corporations and 20+ years of product development experience for distributed technologies.

Back to Articles, including SOA, BPM & BA