Versioning SOA services

Rik de Groot wrote a blog entry about a year ago about versioning services as part of the Top 10 SOA Pitfalls. He touched the subject on different versions in deployment and basically offered us the option of rerouting services using an ESB.
It is a common knowledge that consumers will keep on using a service hoping to only upgrade if *they* need additional or changed functionality. Services however are not meant for a single consumer but for a lot of consumers. Even if they want to upgrade they won’t do it simultaneously. So you will have multiple versions of services running.
I see several options to address versions of services:
1. Minimize by using rerouting within the ESB.
2. Keep all versions running while in use.
3. Have a contractual agreement with expiry date.
4. Use content based routing.
5. Construct adapters for conversion
First I would like to look at which versions might appear. A major version increment of a service means we are no longer backward compatible. A consumer wanting to use the next major release therefore needs to start coding to make use of this service. When a minor increment occurs there is backward compatibility and additional functionality offered. This means a consumer can make use of it without much effort (changing the binding would suffice). A patch increment of a service indicates a change without breaking specifications. A new patch release can – and should – therefore replace the older version.
Clearly in all options we should limit the number of versions of a service created. This means services should not be created within projects but (re-)created in a separate track in order to have generic services and optimal reuse. This track should collect all requirements of (potential) customers, take the common denominator and bring a new version into existence. More than often a new version is created because a single customer wants certain functionality not yet offered and without looking around the new version is tailor-made.

Back to the options, I state that the first one (ESB rerouting) is a logical choice. However addressing major increments is complicated and should be avoided, since you will start building too much logic into a router mechanism. Minor increments should pose no problem (most conversions encountered are straightforward). It therefore only offers the limitation of minor versions of a single major version. A side effect is the WSDL needs to be deployed in both the ESB (as consumer entry point) as in the implementing application. For testing purposes this option is interesting, since upon migration both versions can be addressed and be checked for differences.
Option five is an alternative to the previous option in which the routing is externalized from the ESB, but still located around the services core as wrapper.
The second option is a lot easier. In time however it will fill up your SOA like a pile of yet to read magazines. Results from older versions might contradict results from newer versions. Secondly any service needs to be closely monitored for usage before phasing out. In the slipstream an infrequent consumer might suffer the unavailability though. Not a very healthy way of maintaining services in large SOA environments. However if there is a stable situation and the costs for maintenance are acceptable in respect to the impact on consumers needing to migrate, the situation can be contained by freezing functionality of old services.
The fourth option to use content based routing is inadvisable for most of the situations. Routing based on (a version string as part of) the content of a message leads to non-strict contracts, leaving the routing control in hands of the consumer. How should the consumer construct its message for a certain version?
That leaves us with the last option to describe, namely using contracts. Not a very strange model since it is used by many software vendors for functional support. Upon use the consumer signs a (bi-)yearly contract. Upon expiry of the contract the consumer can no longer use this specific version and needs to migrate, allowing the cleanup of older versions. Upgrading during this period to a newer minor version may extend the expiry date. Of course this means contract management and access control on services, but consumers can reserve budget for upgrading and contract management is not strange in large enterprises. In such cases the client can decide to accept a more expensive contract (due to higher maintenance costs) or a migration to the new platform.
Clearly it depends on the situation which option to choose. If you have a lot of (external) consumers it might be wiser to offer the contract option. If you’re faced with only limited internal consumers the second option is certainly not a bad way to go. However in most cases the first option is the most preferable option.