Versioning Service II

In a previous blog, I started to explore the idea of how services could be versioned in a SOA. Although versioning the WSDL seemed to be an alternative for web services using SOAP the question remained on how to version services which use a queuing mechanism (e.g. with a JMS interface). If a service is invoked over a queue then the queue becomes synonymous with the service. All that has to happen is that new versions of a service are connected to new queues (appropriately named) . Old clients just stay connected to the old queues or are migrated to use the new services over the new queues. Seems easy, but I suspect that in a large system with many services it would be a nightmare to administer, especially as there is no lookup information for the queue. Indeed, this seems to depart from two of the main tenets of SOA, i.e. services are loosely coupled and that they can be discovered.

However, having previously discussed that versioning is possible in web services, can web services be combined with a queuing system and the advantages of web service versioning kept? New standards in the web services space seem to point to a possible solution (as web service management vendors - such as Systinet - are keen to point out). The basic architecture seems to look like this:



SOAP Messages are sent to a MOM gateway, which extracts the messages, finds the queue and sends the message (maybe using JMS if it’s a J2EE implemetation) to a service provider. Messages sent back from the service provider are picked up by the gateway and send as a SOAP response back to the consumer. All the issues concerned with message correlation etc. are handled by the MOM gateway.

Not shown in this diagram is how to deal with an asynchronous style of communication. To solve this comes a small, and apparently unassuming, specification called WS-Addressing. This provides a uniform way of supplying the endpoint of a web service within the SOAP message rather than just using a URL. Although it seems to add complexity, the standard ends up providing extra flexibility and may well be the answer to dealing with versioning of services, but more about that later. In the case of asynchronous messaging, WS-Addressing defines a "ReplyTo" SOAP header block and this could be the endpoint for the return message from the provider.

I have, for the time being, ignored the handling of publish/subscribe mechanisms. Within an SOA one would typically also architect an eventing mechanism, e.g. to notify that a change has happened to some data. WS-Eventing is maybe the right standard to use, but I not going into that now.


Having seen how to use web services with MOMs, lets get back to the versioning problem. In order to find the correct version of a web service an additional degree of layering is required. I’ve tried to show this in the following diagram:




Now the usual parole is to say that the namespaces of the XML messages are versioned and that the version resolution layer checks the name space and directs the message to appropriate service. However, WS-Addressing offers another possibility. Instead of specifying the endpoint of the service provider the corresponding endpoint of the version resolution system is specified plus versioning information. Based on this, the version resolution finds the correct endpoint, modifies the endpoint in the WS-Addressing part of the SOAP header and directs the message to this.

Nobody seems to be actually offering anything in this area, although application platform vendors such as BEA seem to be active in terms of XML versioning, but if they are going to use WS-Addressing in their products to implement versioning , remains open. Web services management vendors such as AmberPoint , also seem to offer support for service versioning with their products, although how far this goes and if it is based on open standards is unclear.