Service Versioning and Schema Evolution

This is a topic that comes up quite often when talking to clients. Based on some of the successful implementations that I have been lucky to be involved in, the one demoninator is how important XML Schema is in that success. In addition the existence of a Schema Custodian (Thomas Erl term) or a individual who guards the Schema with his/her life. The more difficult a Schema is to change, the more likely that it will succeed in an enterprise SOA. Sounds kind of strange but the foundational aspect of XML Schema in its use in WSDL, BPEL, XSLT, XPath/XQuery, auto-generated skeletons/stubs.... means that minor changes could seriously impact a deployment.

One of the clients I work with has successfully employed a XML Schema definition for 3+ years now. The schemas have been allowed to evolve via the use of optional elements but those evolutions have been through a small group of Schema Owners and it is not modifyable via the developer community. Because of the inherent difficulty in changing the schema, it has prevented Schema creep and the potential interoperability damage quick changes could cause. The benefit of this has been interoperability across a wide range of technologies starting with four different app containers and two different JMS providers.

One other area of discussion is on versioning of Schemas/Services. One approach that I have seen is the use of the namespace and ESB technology to route based on unique namespaces. Namespace versioning can be something like:

http://www.mycompany.com/2007/12/ProvisioningService

This service would then have been developed in December 2007. People are familiar with this approach with some of the WS-* standards like WS-RM. The good part of this is that for me to invoke a service using this as the target namespace, requires that my SOAP Request call it out. The bad news is that changing this will break any clients that were developed against it. A quick solution is to support several services if the namespace changes by infrastructure like an ESB and XPath Routing. A simple XPath statement focusing on the SOAP Envelope could route this request to the correct destination. There are several other versioning solutions, check out developer.capeclear.com for a whitepaper on Service Versioning.