- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- Resources
Versioning in SOAP
One interesting note about SOAP is that the Envelope element doesn't expose any explicit protocol version in the style of other protocols such as HTTP (HTTP/1.0 versus HTTP/1.1) or even XML (?xml version="1.0"?). The designers of SOAP explicitly made this choice because experience had shown simple number-based versioning to be fragile. Further, across protocols, there were no consistent rules for determining what changes in major versus minor version numbers mean.
Instead of going this way, SOAP leverages the capabilities of XML namespaces and defines the protocol version to be the URI of the SOAP envelope namespace. As a result, the only meaningful statement you can make about SOAP versions is that they are the same or different. It's no longer possible to talk about compatible versus incompatible changes to the protocol.
This approach gives Web service engines a choice of how to treat SOAP messages that have a version other than the one the engine is best suited for processing. Because an engine supporting a later version of SOAP will know all previous versions of the specification, it has options based on the namespace of the incoming SOAP message:
If the message version is the same as any version the engine knows how to process, it can process the message.
If the message version is recognized as older than any version the engine knows how to process, or older than the preferred version, it should generate a VersionMismatch fault and attempt to negotiate the protocol version with the client by sending information regarding the versions it can accept. SOAP 1.1 didn't specify how such information might be encoded, but SOAP 1.2 introduces the soapenv:Upgrade header for this purpose. (We'll describe it in detail when we cover faults.)
If the message version is newer than any version the engine knows how to process (in other words, completely unrecognized), it must generate a VersionMismatch fault.
The simple versioning based on the namespace URI results in fairly flexible and accommodating behavior of Web service engines.