Versioning scenarios and compatibility assurances

Here's a first cut at a # of scenarios and compatibility assurances.
Interested in the groups feedback on this.

Extension/Versioning of WSDL Components
This summarizes a variety of changes to WSDL components and the resulting
compatibility assertions that can be made. In general, an incompatible
change is neither forwards nor backwards compatible, and requires a new
namespace name or element names. I haven't yet thought throw whether one of
forwards or backwards compatibility always requires a ns change.

Body Extension/Versioning
The body of a message is extended/versioned in either compatible or
incompatible manner

Optional element is added to body: Probably compatible change if unknown
content is ignored and semantics remain the same.
Required element is added to body: incompatible change
Required element made optional: Backwards compatible but not forwards
compatible. An old receiver will break if it doesn't get the required
component, but a new receiver will do fine with or without it
Required element removed. Incompatible change
Header Extension/Versioning
The header(s) of a message is extended/versioned in either compatible or
incompatible manner

Optional header added. Probably compatible change if unknown content is
ignored and semantics remain the same.
Required header added. Incompatible change
Required header made optional: Backwards compatible but not forwards
compatible. An old receiver will break if it doesn't get the required
component, but a new receiver will do fine with or without it
Required header removed. Incompatible change
Interface Operation Extension/Versioning
The operations of an interface are extended/versioned in either compatible
or incompatible manner.

An interface now supports an additional operation. This is backwards
compatible and forwards incompatible for input operations - a client can
talk to older web services. This is forwards compatible and backwards
incompatible for output operations.
An interface does not support a previous operation. This is backwards
compatible and forwards incompatible for output operations - a newer client
can talk to older web services. This is forwards compatible and backwards
incompatible for input operations
Endpoint (binding) Extension/Versioning
The bindings of a service is extended/versioned in either compatible or
incompatible manner.

An endpoint now supports an additional binding. This is an incompatible
change.
Body/Header Extension/Versioning
An operation is compatibly evolved by adding an optional header, which if
present changes the response message type.

Adding a range header changes the response message to be a range response.
HTTP range header is an example in another protocol. This is a compatible
change

Fault Extension/Versioning
... More work

Feature/Property Extension/Versioning
.. More work.

MEP Extension/Versioning
Support new MEPs... More work.

Received on Saturday, 14 February 2004 02:04:36 UTC