Skip to Content
Building web services that can easily evolve without breaking existing users is a key characteristic of a loosly coupled web services system. The issues of backward and forward compatibility and versioning strategy have been brought up now and then in various standards working groups. The discussion is still going on , and have seen some thoughtful suggestions published on the web.
To understand the current thoughts of the standard community on this issue, here are a few useful blogs and articles you don’t want to miss:

[1] Extensibility, XML Vocabularies, and XML Schema, by David Orchard
URL: http://www.xml.com/lpt/a/2004/10/27/extend.html
David did a good job defining what’s backward and forward compatibility. In addition, the article provides a few very good advise about how to use extensibility to accomodate compatible changes, and how to use various version identification strategies.

To complement this article, you should also read [1.1]Designing Extensible, Versionable XML Formats By Dare Obasanjo [1.2]2 XML.com articles on XML Extensibility and Versioning, David’s blog explaining the common points and differences between [1] and [1.1]

[2] Loose coupling and WSDL versioning, a blog by Chris Ferris
URL: http://webpages.charter.net/chrisfer/2004/11/loose-coupling-and-wsdl-versioning.html
Does any change to a WSDL has to result in a new WSDL namespace? In this blog, Chris shows two ways to avoid that

  • Use XSD extensibility for the message to be exchanged, or
  • Use WSDL extensibility for adding new operations

[3] Versioning Service Data using WSDL Application Data Feature, a blog by David Orchard
URL: http://www.pacificspirit.com/blog/2004/12/01/versioning_service_data_using_wsdl_application_data_feature
If you don’t have a chance to design your schema as suggested by [1] and [2], you may want to check out the WSDL2.0 AD feature.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. David Sonnenschein
    Kevin,

    Thanks for the pointers to David’s and Chris’ Blogs, interesting reading with good points.  I guess I am a little confused as to why people want to truely version the interface in the WSDL rather than just exposing a new service endpoint (and WSDL) with the added functionality.  If you use some sort of endpoint abstraction (WS-proxy or XI) you could accept the old version requests at that layer and then direct them to the new service leveraging the legacy interface with the new implementation when you want to sunset the old.  I guess I see versioning as an operational issue if components are really loosely coupled.  I realize this leads to a proliferation of similar service interfaces and implementations, but this seems preferable to requiring any coordination on the part of individual consumers and providers to adopt new versions.  If you do not use an operational / runtime approach to dealing with the issue, how do ever sunset any service implementations? 

    The approach I am describing also allows for indovidual services to be decorated or extended at an enterprise level to include logging and auditing services, security related elements, etc. without involving the original provider of the service – extension through composition.

    I would appreciate your thoughts.

    (0) 
    1. Kevin Liu Post author
      Hi David,

      Very interesting point. Actually there may be already many web services tools taking the operational approach as you described.

      One issue I see here: with the “operational approach”, the abstract layer can of course help direct a request to the right service, but if the new version of the service return some compatible additional content (as explained in Chris’s blog), how will the client handle that?

      What Chris and David are promoting in their articles is that with good design leverageing extensibility points and a few well-understood processing rules (such as the MustIgnore rules explained in David’s paper), we can achive a few things, for example:

      • a compatible new version of a service can safely replace an old version without affecting any existing clients (not requiring coordination b/t consumer and provider)
      • even *without* any abstraction layer, we can avoid/reduce the “sunsetting” situation which requires maintaining two *compatible* versions/instances of the same service at the same time.

      HTH.

      Regards,
      Kevin

      (0) 
      1. Sara D
        Hi Kevin,

        We couldn’t access the first two urls. Could you please tell me from where we can get the mentioned information.

        Regards
        Sara

        (0) 

Leave a Reply