Versioning Service Data using WSDL Application Data Feature

Chris Ferris blogged about loose coupling and WSDL versioning, particularly that deploying a new and compatible version of a service at the same URI as the previous version of the service is a good thing.. I totally agree. The example that he uses is when the data type of an operation is extended. I agree, and I had blogged about ways that a service can evolve in compatible or incompatible ways.

But what can a service provider do if they haven't written in an extensibility point in their schema and they don't have a processing model for unknown extensions? They can make use of the SOAP header block extensibility and the WSDL 2.0 application data feature and soap module. Also, the HTTP Protocol makes use of Headers for application data outside of the HTTP Body, such as HTTP Cookies and Content-Location.

WSDL 2.0 Application Data Feature
It is often the case that service data can evolve in a compatible manner, but the Schema wasn't designed for extensibility. One solution is to do the extensions as a SOAP header block. BEA and Sonic convinced the WSDL 2.0 working group that there needed to be a way for WSDL 2.0 services to deal with SOAP header extensibility, which we called the Application Data Feature.

The purpose of this feature is that the operation with the unextensible schema can be augmented by additional schema information. The new operation uses the Application Data Feature to specify the schema for the extension, and then this is serialized into SOAP headers.

All we do is define the extension type (which we have to do no matter what..) use the Application Data property to refer to that type, and then turn on the Application Data SOAP Module.

WSDL 2.0 with AD

I show below Chris's example with the Application Data feature and soap module with an updated response without the wildcard, sans some of the xml grungery like namespaces, and some of the irrelevent wsdl constructs.

<description>
<types>
 <xsd:schema targetNamespace="http://example.com/tns"
                        xmlns:tns="http://example.com/tns">

<xsd:complexType name="StockQuoteResponse">

     <xsd:sequence>

          <xsd:element name="Symbol" type="xsd:string"/>

          <xsd:element name="Value" type="xsd:float"/>

     </xsd:sequence>

</xsd:complexType> 

<xsd:complexType name="ExtensionDataType">

    <xsd:sequence>

          <xsd:element ref="StockQuoteResponseExtension"/>

    </xsd:sequence>

</xsd:complexType>

<xsd:complexType name="StockQuoteResponseExtension">

   <xsd:sequence>

       <xsd:element name="Hi" type="xsd:float"/>

       <xsd:element name="Low" type="xsd:float"/>

       <xsd:element name="NetChange" type="xsd:float"/>

    </xsd:sequence>

</xsd:complexType>

 </xsd:schema>

</types>

<interface name="StockQuote">

 <operation name="GetQuote">

  <input element="StockQuoteRequest"

  <output element="StockQuoteResponse">

   <property uri="http://www.w3.org/2004/08/wsdl/feature/AD/data">

    <constraint xmlns:foo="http://example.com/">

     tns:ExtensionDataType

    </constraint>

   </property>

  </input>

 </operation>

</interface>

<soap:binding name="StockQuoteSOAP" interface="StockQuote">

   <soap:module uri="http://www.w3.org/2004/08/wsdl/module/AD" required="true"/>

</soap:binding>

<service interface="StockQuote">

  <endpoint binding="StockQuoteSOAP" address="foo"/>

</service>

HTTP Headers
HTTP Headers are another example of application extensibility outside the body. HTTP Cookies are often used by applications to contain state or state identifying information. And in RESTful systems, the HTTP Content-Location header provides a URI for where the Web resource exists. Applications that use HTTP as an application protocol make use of the content-location header, such as following an HTTP POST request. The application data feature brings the ability to examine HTTP headers to the HTTP Binding of WSDL 2.0

Potential problems
There are 2 significant potential problems with this feature. The first is that it is done with Features and Properties, which some large vendors may not implement and has a minority opinion against it. We might need to change this to a WSDL extension. The second is that it is optional. Some folks, notably IBM, believe that application data should never ever be in SOAP header blocks and couldn't live with this being mandatory. I can't figure it out, but that's the way life is. As it is optional, it is likely that not all implementations will provide this facility. I propose that customers should ask for and demand implementation of this feature in their WSDL 2.0 toolkits. That way they can get data extensibility in the likely scenario that their operations are not all perfectly designed for all time in the first version.