FW: Primer Text for "Versioning and Service Equivalency"

Below is a first attempt at text for primer section 5.5 "Versioning and 
Service Equivalency". I found this difficult to write in two major 
respects:

   - i felt ill at ease with the term "Service Equivalency",
     especially when the previous section is about "Multiple
     Logical WSDL Documents Describing the Same Service" which
     i feel could also be applied to versioning.

   - the current openness of debate on this subject
     combined with the lack of formal materials to reference,
     hence a rather wishy-washy set of moving target references
     (apart from Webarch that is).

Paul


A WSDL document describes a set of messages which a Web service may 
send and receive. However it is possible for a Web service to exchange 
other messages beyond those described in a given WSDL document. Often 
this circumstance occurs following an evolution to the service.

How best to manage the evolution (versioning) of Web based systems is 
at the time of writing the subject of a wide ranging debate. However, 
there are three activities within the W3C which are directly relevant 
to versioning of Web services description:

    *) The Technical Architecture Group (TAG) have published guidance on 
the extensibility and versioning of data formats in [Web Architecture] 
document. There is also a more wide ranging draft finding on Versioning 
and Extensibility [TAG Finding: Versioning]. Both these works build 
upon the technical note [Web Architecture: Extensible Languages].

    *) The XML Schema Working Group are collecting a series of Use-Cases 
for Schema versioning as a part of the Schema 1.1 activity [XML Schema 
Versioning Use-Cases].

    *) The Semantic Web Best Practices and Deployments Working Group are 
examining how vocabularies, may evolve [SW VocabManagementNote].

Whilst as yet incomplete, these activities all agree in one important 
respect, that versioning is difficult, however that you SHOULD 
anticipate and plan for change.

The draft finding on Versioning and Extensibility details two key 
approaches to versioning:

    *) comaptible evolution
    *) big bang

_Compatible_Evolution_
In compatible evolution, designers are expected to limit changes to 
those that are either backwards or forwards compatible, or both:

-Backwards compatibility is where a receiver is expected to behave 
correctly should it receives a message in an "older" version of a 
language and thereby enabling newer versions of a service to continue 
to work with older consumers of a service and vice versa.

-Forwards compatibility is where a receiver is expected to behave 
properly should it receive a message in a the "newer" version of a 
language. Forwards compatibility enables existing consumers of a 
service to continue working with a newer version of the service and 
vice versa.

There are three critical areas in which a service described in WSDL my 
evolve:

   *) the service now also supports additional binding.
In compatible evolution, this should be safe addition given that adding 
a new binding shouldn't impact any existing interactions using another 
transport.

   *) an interface supports new operations.
Again, in compatible evolution this is usually safe, given adding an 
additional operation to an abstract interface shouldn't impact any 
existing interactions.

   *) the messages exchanged may include additional fields
How the messages themselves may change within a description depends to 
a large extent upon the type system being used to describe the message 
contents. RelaxNG has good support for describing vocabularies which 
ignore unknown XML as does OWL/RDF. XML Schema 1.0 has limited 
support for extending the description of a message via the xs:any and 
xs:anyAttribute constructs. XML Schema 1.1 has been chartered to 
provide "changes necessary to provide better support for versioning of 
schemas", and it is anticipated that this will include improved support 
for more "open content" and therefore better support for compatible 
evolution of messages.

*_Big_Bang_
The big-bang approach to change is in many respects the simplest to 
currently represent in WSDL 2.0. Here any change to an WSDL document 
implies a change to the document namespace, a change to the interface 
implies a new interface namespace and a change to the message contents 
is communicated using a new message namespace. This approach has 
particular benefits where an agent may quickly tell if a service has 
changed by simply comparing the namespace value.

It is feasible to combine the both approaches in a variety of different 
ways, for example changing the namespace for minor changes to message 
descriptions, but not changing the interface namespace when adding new 
operations: 'CheckAvailability1', 'CheckAvailability2', etc.

Whilst the Big Bang approach is approach currently most easily 
implemented using WSDL 2.0, it can lead to a large number of cloned 
interfaces which become difficult to manage, making the compatible 
approach preferable to many for widely distributed systems, but in the 
end, the choice of a versioning strategy for Web services described in 
WSDL 2.0 is left as an exercise to the reader.


[TAG Finding: Versioning]
Versioning XML Languages, David Orchard, Norman Walsh. Proposed TAG 
Finding 16 November 2003. Available at
http://www.w3.org/2001/tag/doc/versioning-20031116

[WebArch: Extensible Languages]
Web Architecture: Extensible Languages, Tim Berners-Lee. W3C Note 10 
Feb 1998. Available at
http://www.w3.org/TR/NOTE-webarch-extlang

[XML Schema: Versioning Use-Cases]
XML Schema Versioning Use Cases, Hoylen Sue. W3C XML Schema Working 
Group Draft, 29 March 2005. Available at
http://www.w3.org/XML/2005/xsd-versioning-use-cases/

[SW VocabManagementNote]
Vocabulary Management, Thomas Baker, et al. Semantic Web Best Practices 
and Deployment Working Group Note 8 Feb 2005. Available at
http://esw.w3.org/topic/VocabManagementNote

Received on Thursday, 31 March 2005 16:23:42 UTC