- From: <paul.downey@bt.com>
- Date: Wed, 21 Jan 2004 13:52:08 -0000
- To: <www-ws-desc@w3.org>
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 descriptions. 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 service. 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 change. 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 interactions. 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": http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html [2] "Two logical WSDL documents describing the same service": http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0045.html [3] TAG finding on Versioning XML Languages: http://www.w3.org/2001/tag/doc/versioning.html [4] David Orchard's compatibility articles index: http://www.pacificspirit.com/Authoring/Compatibility/ [5] Primer "Versioning and services equivalency": http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#N10381 http://tinyurl.com/2h42v [6] "Versioning Use Cases": http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0070.html Paul -- Paul Sumner Downey Web Services Integration BT Exact
Received on Wednesday, 21 January 2004 08:52:25 UTC