Re: Header/Body Style Proposal

All correct, except for the effort involved.

On Jan 23, 2004, at 6:57 PM, Yaron Goland wrote:

> Let me see if I can correctly describe the scenario you envision.
>
> Step 1 - The WSDL 2.0 WG ships WSDL 2.0. The spec says nothing about 
> the
> header/body design style and provides no standard for how to define a 
> header
> in the interface and then bind that header in a binding.
>
> Step 2 - WSDL 2.0 engines are shipped.
>
> Step 3 - The Foo Bar corporation, which wants to create a backwards
> compatible version of an existing WSDL 2.0 interface.
> 	In order to enable their new interface to be backwards compatible 
> with the
> old interface they want their users to be able to send in an extra 
> header
> with the old message body that contains optional data that identifies 
> the
> sender as supporting the new features.
> 	So the Foo Bar corporation publishes a specification that defines a 
> new
> WSDL feature with a unique URI. In the spec for that feature they 
> specify
> that if the feature is defined on an input then this means that the 
> input
> MAY contain an extra header whose definition is given in the 
> specification
> the Foo Bar corporation published. Similarly, if the feature is used 
> on an
> outgoing message then it means that the header MAY be included in the
> outgoing message if the sender so chooses.
> 	Although the feature is defined at the interface level, so it will be
> binding independent, the Foo Bar corporation specification does 
> provide some
> guidance on how to use the header with popular message formats like 
> SOAP.
>
> Step 4 - The Biz Wack corporation, which uses the Foo Bar corporation's
> services, gets a copy of the new Foo Bar WSDL using the new Foo Bar 
> WSDL
> feature. Of course the Biz Wack WSDL processor knows absolutely nothing
> about the new Foo Bar feature and thus will ignore it. In order for 
> the Biz
> Wack corporation to be able to utilize the new Foo Bar corporation 
> feature
> the Biz Wack corporation will have to hire a programmer to write new 
> code
> that plugs into their existing WSDL processor to support the Foo Bar
> corporation's feature.
>
> Step 4 is then repeated for each and every company that the Foo Bar
> corporation works with. That is, before a new company can support the 
> Foo
> Bar corporation's new feature and thus gain access to the optional 
> header it
> will be necessary for it to find an existing extension or a programmer 
> to
> write an extension to their WSDL engine that will implement the 
> behaviors
> defined by the Foo Bar corporation's specification.

Highly unlikely.  There are a limited number of WSDL processors/SOAP 
stacks in existence; most already have well-defined extension 
semantics, and WSDL 2.0 processors are even more likely to do so.

Along with their feature description, the Foo Bar corporation has 
presumably tested with their own WSDL processor and SOAP stack.  They 
can make the plugin available.  Say they're using .NET.  They can also 
solicit plugins from partners that implement the same functionality for 
other stacks (Axis, for instance).

Note that, as the spec currently stands, authors of WSDL processors are 
already required to "support" features.  As I mentioned previously, 
they could do so by building in the ones they know about, with no 
provision for extension, but I think this unlikely.

And note that the features functionality provides the ability to 
provide processing functionality more sophisticated than processing a 
single header, as well.

Amy!

Received on Monday, 26 January 2004 08:19:58 UTC