Monday, April 02, 2012

XML namespace versioning in web services

Defining a version number in the namespace of an XML schema is a form of hardcoding. Handling versions of schemas can also be based on the value of a defined version element or attribute.

A hardcoded version number makes sense if you want to enforce versioning at design time. On the contrary, a version value makes sense at runtime.

Design time versioning tightly couples service consumers to the service version. Upgrading the service version means all consumers must upgrade. A version number in the namespace translates to package in Java. Changing the number is changing the client code. 

Runtime versioning is much more flexible, and has less impact on client code. But runtime versioning does require an effort in governance. Who is using which service version? Who is upgrading when? 

Changing the version number in a namespace can trigger a cascade of changes in other XML schema, e.g., through schema imports. This can be so complex that I have seen several large web service providers still being at version 1.0, even after numerous non-backward compatible changes. Effectively this is a no-version strategy, where each change pushes high costs onto all consumers and governance is not stimulated.

Runtime versioning is more friendly towards consumers, and ensures that proper governance is put in place, which increases the service maturity level.

It can't be a surprise I favour the runtime versioning strategy.

1 comment:

  1. Anonymous06:11

    I agree.
    I've seen these impacts as well.
    However, you may have a hard time on getting this done because of the extra governance, which in a lot of companies is already hard enough to establish.