Follow up on versioning and ADD feature

As I said at last F2F, I am not a huge fan of splitting application data 
at the interface level in two sets (body and header).
I do not remember any clear expressed semantic difference between the 
two sets.
IIRC, on reason for that proposal was to enable versioning (is there any 
other usecase ?)
One proposed solution to versioning was to build a wrapper element 
around a well-known type to add some more data.
The other proposed solution was the use of the ADD feature.
The assumptions I am making is that it would be better to:
     - keep the simple "one bag of application data" design at the 
interface level
     - have the same interface description no matter what versioning 
solution is used.
Here is an iteration on the ADD idea that may fullfill these assumptions:
    1) At the abstract layer, always define a wrapper element. This 
wrapper element has restrictions in its definition (this may be a new 
type style that allows only one sequence with global element referenced 
inside the sequence), something like:
<element name="tns:myNewTravelRequest">
    <complexType>
       <sequence>
          <element ref="tns:myTravelRequest"/>
          <element ref="tns:isGoldCardMember" minOcurrs="0"/> <!-- a new 
data item -->
          ...
       </sequence>
    </complexType>
</element>
    2) Refer to this wrapper element within an abstract operation 
description
    3) Declare whether to use the ADD module at the binding level
    4) Set somewhere in the WSDL description between the wrapper element 
declaration and the binding declaration, a property that will set which 
pieces of the wrapper element go into the body section and which pieces 
go into the header section. A shortcut syntax can be provided to set 
this property, for instance within the wrapper element description.
Here is an example of such a description:
/***************************/
 ...
<element name="tns:myNewTravelRequest" *add:body*="tns:myTravelRequest">
    <!-- *The add:body attribute directly sets the property *that tells 
what goes into the body in the refering operation property bucket-->
    <complexType>
       <sequence>
          <element ref="tns:myTravelRequest"/> <!-- the base type -->
          <element ref="tns:isGoldCardMember"/> <!-- a new data item -->
          ...
       </sequence>
    </complexType>
</element>
..
<interface>
    <operation ...> <input 
element="tns:*myNewTravelRequest*">...</operation>
</interface>
<binding... > *<!-- a binding that uses the add module -->*
    <operation ...><input ...>*<wsoap:module uri="add module uri" 
required="true"/>*...</input> </operation>
</binding>

<binding... > *<!-- a binding that uses the wrapper element alternative -->*
    <!-- no ADD module declaration-->
</binding>
/***************************/

The nice point of this example is that we keep the simple interface 
description system with only one bag of data per abstract message.
It also enables keeping the same interface description with both 
versioning approaches.
The decision to split data into two sections (or to keep it as it is) is 
let to the binding level which seems sensible to me.
Also, any new WSDL binding specification will not need to support some 
sort of ADD module in order to serve existing interfaces already 
implemented by ADD-enabled services. For instance, we may not need to 
define an "ADD module" for the HTTP binding.
This approach has also its drawbacks: It is going away from the simple 
rule: put this unbreakable @element application data into the body. It 
is also more difficult to test the unique GED best practice on an 
ADD-enabled service.
Comments?
    Youenn

Received on Wednesday, 16 February 2005 08:51:59 UTC