Peter Williams recently made a good proposal suggesting content-negotiation as a means to advertise and ask for version support. This is in contrast to using version identifiers in URIs as is commonly done. This is a neat idea. Peter's post prompted some debate and a rebuttal. But I find that this debate is a distraction.

It happens again. Over at ebpml.org, JJ Dubray has a couple of related posts about the dark side of REST, and a proof that REST creates strong-coupling. I am not sure what to make of his style of writing, but like good citizen, let me try to make some sense here.

Several months ago, I blogged about versioning of web services. Between then and now, I realized that versioning of web services is a very nebulous topic, and that the problem of versioning could test the motivation of even the most committed web services architect. In this post, I would like to take the next step and discuss some possible ways of versioning web services. In this process, I would like to answer two questions:

Besides the technical issues involved with versioing of XML schemas, and the processing of versioned instance documents, there are a few situations that make it hard to implement versioning solutions.

Having spoken to a few folks at work on this topic, I would like to make a few more comments on versioning. See this and this for some background.

In my previous post, I discussed two approaches that I found useful for versioning XML schemas. The second approach in that post involved redefining all types from previous versions into later versions without actually importing those types. As this involves no type reuse, if you are using schema-driven code-generation tools like XmlBeans, you will notice that, each schema version leads to a different set of interfaces/classes.

XML versioning is a much talked about problem. Despite the volume of information available on XML and schema versioning, most people agree that this problem is hard with no single "silver-bullet" solution. In this post, I would like to discuss some possible solutions that can be implemented with data binding solutions such as XmlBeans. As always, this is work-in-progress, and I welcome any comments.

Versioning is a frustrating exercise. I find that most of the versioning solutions on XML (and web services) address issues related versioning documents, or versioning UDDI entries etc, without dealing with backwards/forwards compatibility. Extensibility is complex, but less frustrating. Most of the work on extensibility rightly talks about forwards and backwards compatibility, but fails to provide meaningful solutions for versioning. My conclusion is that extensibility and versioning are two different beasts and require different solutions. More on versioning later.

Managing change and versioning of web services can be hard. Although based on loose coupling and extensibility concepts, when it comes to change, web services are not far from older supposedly not-so-loosely coupled RPC-style technologies.

Most changes have good intentions - either they fix something broken, or try to enhance the service by adding new features. However, except in the most ideal cases, changes are disruptive. As David Bau explains in his "morning after" scenario, the need for compatibility can scuttle most plans for change. It is not always easy to foresee changes and future-proof the design, but eventually, we all get tasked to make changes.