Chief among the benefits of service-enabling an enterprise’s application landscape are increased organisational agility and reduced overall cost of implementing change.

Schema versioning

We can begin our investigations into the contract and coupling problems that bedevil our ProductSearch service by looking at the issue of schema versioning. The WC3 Technical Architecture Group (TAG) has described a number of versioning strategies that might help us evolve our service’s message schemas in ways that mitigate our coupling problems. These strategies range from the excessively liberal none, which mandates that services must not distinguish between different versions of a schema and must therefore tolerate all changes, to the exceedingly conservative big bang, which requires services to abort if they receive an unexpected version of a message. 

Both extremes bring with them problems that inhibit the delivery of business value and exacerbate the total cost of ownership of the system. Explicit and implicit “no versioning” strategies result in systems that are alike in being unpredictable in their interactions, fragile and costly to change downstream. Big bang strategies, on the other hand, give rise to tightly coupled service landscapes where schema changes ripple through providers and consumers, disrupting uptime, retarding evolution and reducing revenue generating opportunities.

Our example service community effectively implements a big bang strategy. Given the costs associated with enhancing the business value of the system, it is clear that the providers and consumers would benefit from a more flexible versioning strategy – what the TAG finding calls a compatible strategy – which provides for backwards- and forwards-compatible schemas.

In the context of evolving services, backwards-compatible schemas enable consumers of newer schemas to accept instances of an older schema: a service provider built to handle new versions of a backwards-compatible request, say, could nonetheless still accept a request formatted according to an old schema. Forwards-compatible schemas, on the other hand, enable consumers of older schemas to process an instance of a newer schema. This is the sticking point for the existing ProductSearch consumers: if the search result schema had been made forwards-compatible when first put into production, the consumers would be able to handle instances of the new version of the search result without breaking or requiring modification.