Versioning and Web Service Description

The ability to safely make incremental changes to a service is a
key ingredient of "loose coupling". Loose coupling has been a major
selling point of Web services and offers the promise of being able
to make backwards compatible changes to a service without impacting
existing users. Backwards compatibility reduces the number of different
copies of the same service required to support different versions:
it reduces the proliferation of 'stove-pipes'.

Unfortunately it is not currently clear how a publisher may safely
make backwards compatible changes to a Web service, or a consumer
may move to a newer version of a service ahead of it being deployed.

Whilst this may be considered by some to be an architectural issue
best solved elsewhere, we believe this working group has been
chartered to address versioning, or at least inheritance which may
be used as an interface versioning tool [1]. We strongly believe that
versioning and describing the relationships between versions is
something that firmly belongs in WSDL. Versioning above and beyond the
namespace of a service is commonly provided by other interface

There are two specific areas of versioning which we would like the
Working Group to consider:

1) The description of a Web Service (WSDL).
2) The content of messages exchanged (SOAP/XML).

The first area overlaps with another discussion "Two logical WSDL
documents describing the same service" [2]. This discussion led to my
understanding that the interface behind a namespace should be immutable:
the interface shouldn't be changed without issuing a new namespace or
'version'. I now (possibly wrongly) understand that an interface may be
extended by newer versions an the interface using WSDL imports. In the
new combined interface specific versions of each operation, fault, etc
are all available and uniquely addressed by the qname.

David Orchard has submitted a series of use-cases for versioning a 
service [6] which do seem to cover most of our concerns, in particular
the ability to add a fault, an operation and a binding.

Beyond the unique namespacing of a service, we need to be able to 
describe the relationship between separate versions of the same service:
 an association between namespaces - is this message,operation, 
interface, etc WSDL backwards compatible with a previous version of the 

SOAP provides the mustUnderstand attribute which provides feature
negotiation. Other protocols offer the ability to specify a
message must be /at least/ version '5.8' - assuming that messages
are backwards compatible from a given version. We need a similar
mechanism to describe the relationship between different versions
of the same service. This could be as simple as the model used by an
SCCS/RCS/CVS system in which a version of a file references a previous
version and is annotated with comments describing the reason for the

The second area is by far the most important to us for reducing
the need for stove-pipes. We need to be able to understand how we
can reliably change an interface without breaking existing

In particular we need to be able to:

- send additional values (which may be ignored by a receiver)
- expect additional values (which may be defaulted by a receiver)

The TAG has considered this very issue [3], and in particular David
Orchard has written several very useful articles discussing methods
for achieving backwards compatibility in W3C schema [4]. These
techniques do, however, require a level of support in schema
implementation (in particular wildcards) missing from many of the
current toolkits.

We would  like to reference the TAG's findings on versioning XML
languages to ensure vendor support for the techniques described.
It is frustrating that using schema to describe the messages means 
we have to think ahead and add placeholders for future extensibility 
when first publishing a service. I'm not sure if this WG is the place 
to solve that problem, though! 

We realise that some of these are large issues and could demand
a lot of time from the Working Group which might not be available.
It maybe therefore acceptable to at least document a versioning
technique and expected levels of support - there is a placeholder
in the primer for "Versioning and services equivalency" [5].

Ultimately we do require an interoperable mechanism for Web service
versioning and that may imply normative text, possibly changes to
WSDL itself.

[1] "Extending the functionality of an existing Web Service":

[2] "Two logical WSDL documents describing the same service":

[3] TAG finding on Versioning XML Languages:

[4] David Orchard's compatibility articles index:

[5] Primer "Versioning and services equivalency":

[6] "Versioning Use Cases":


Paul Sumner Downey
Web Services Integration
BT Exact

Received on Wednesday, 21 January 2004 08:52:25 UTC