RE: Primer Text for "Versioning and Service Equivalency"

Grr, some weird keystroke caused early message delivery.  I meant to
say:

I'm surprised you didn't mention or use:

http://www.pacificspirit.com/blog/2004/06/29/interface_compatibility_v2

http://www.pacificspirit.com/blog/2004/06/29/scenarios_for_interface_com
patibility

http://www.pacificspirit.com/blog/2004/06/29/using_wsdl_schema_for_compa
tible_evolution

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

I think that a couple of scenarios showing versioning would be great.
For example, service is versioned in a compatible way, say new operation
added.  What can the a receiver of the new WSDL do with it?  Another
variation is using the header nee application data feature.  Another
example, service is versioned incompatibly, what happens..

Cheers,
Dave


> -----Original Message-----
> From: David Orchard
> Sent: Friday, April 01, 2005 1:43 PM
> To: 'paul.downey@bt.com'; www-ws-desc@w3.org
> Subject: RE: Primer Text for "Versioning and Service Equivalency"
> 
> 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:48:10 UTC