W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2005

RE: Primer Text for "Versioning and Service Equivalency"

From: David Orchard <dorchard@bea.com>
Date: Fri, 1 Apr 2005 13:43:14 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0EA10BFC@ussjex01.amer.bea.com>
To: <paul.downey@bt.com>, <www-ws-desc@w3.org>

I was surprised you didn't mention:

http://www.pacificspirit.com/blog/2004/12/01/versioning_service_data_usi
ng_wsdl_application_data_feature



> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of paul.downey@bt.com
> Sent: Thursday, March 31, 2005 8:14 AM
> To: www-ws-desc@w3.org
> Subject: 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 Friday, 1 April 2005 21:43:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:35 GMT