Re: Header/Body Style Proposal

I'm +1 to Amy's strong -1 on this - we don't need an abstract header
mechanism and we went thru many months (nearly 2 years of it) trying
to simply WSDL and come up to a much better point that WSDL 1.1 was.
I am not willing to give up an approach that was worked out with
so much work at this point. What new information exists to re-open
the abstract header issue?

Sanjiva.

----- Original Message ----- 
From: "Amelia A Lewis" <alewis@tibco.com>
To: "David Orchard" <dorchard@bea.com>
Cc: <jmarsh@microsoft.com>; <www-ws-desc@w3.org>
Sent: Thursday, January 22, 2004 10:16 AM
Subject: Re: Header/Body Style Proposal


> 
> Strongly -1 to this.
> 
> And if it's a choice between properties/features and the header/body
> proposal, I'm strongly -1 on that proposal as well.
> 
> Amy!
> On Wed, 21 Jan 2004 14:57:37 -0800
> David Orchard <dorchard@bea.com> wrote:
> 
> > I haven't seen what a generic header-adding property/feature looks
> > like as it hasn't been published.  It seems that this decision is
> > dependent upon the generic header-adding property/feature being
> > acceptable to the group.  The group has a choice of: a proposal on the
> > table, or a proposal that has been due since November.  Aren't we
> > running out of road here?
> > 
> > Besides, I'm a bit negative on properties/features anyways, given that
> > I can't figure out how to version them, extend them, use them, interop
> > test them.  Seems to me like doing the published header/body proposal
> > and dropping prop/feature solves a concrete (or at least we think
> > concrete) problem and reduces complexity.
> > 
> > Cheers,
> > Dave
> > 
> > > -----Original Message-----
> > > From: www-ws-desc-request@w3.org
> > > [mailto:www-ws-desc-request@w3.org]On Behalf Of Jonathan Marsh
> > > Sent: Wednesday, January 21, 2004 12:20 PM
> > > To: ygoland@bea.com; www-ws-desc@w3.org
> > > Subject: RE: Header/Body Style Proposal
> > > 
> > > 
> > > 
> > > After only a brief read it appears this would constitute a reversal
> > > in the direction we agreed to pursue at our November FTF, which is
> > > to replace explicit structural support for headers at the abstract
> > > level with a feature/property based mechanism.  One of the main 
> > > motivators was
> > > that static headers (those that can be usefully described in WSDL)
> > > are both rare and not very interesting.
> > > 
> > > From 
> > > http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0062.html:
> > > 
> > >   Headers:
> > >     RESOLVED: Remove @headers attribute.
> > >     RESOLVED: Rename @body to @message.
> > >     RESOLVED: Rename @detail to @message
> > >     ACTION: Glen to write up rationale for removing headers (and?)
> > > proposal
> > >             for a generic header-adding property/feature.
> > > 
> > > ...which action is still open.  I don't expect it to be 
> > > completed by the
> > > FTF, but we can hope :-).
> > > 
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> > > > [mailto:www-ws-desc-request@w3.org]
> > > On
> > > > Behalf Of Yaron Goland
> > > > Sent: Tuesday, January 20, 2004 4:26 PM
> > > > To: www-ws-desc@w3.org
> > > > Subject: Header/Body Style Proposal
> > > > 
> > > > 
> > > > Arguably the most common protocol design style for application
> > > protocols
> > > > is
> > > > what this letter will refer to as the headerBody style. 
> > > Protocols such
> > > as
> > > > HTTP, SOAP, FTP, IMAP, ACAP, SMTP, etc. all use application
> > > > messages
> > > that
> > > > contain a single body and multiple headers.
> > > > 
> > > > Given the universal popularity of this design style this letter
> > > proposes
> > > > that WSDL 2.0 add direct support for this style to WSDL 2.0.
> > > > 
> > > > The headerBody style will use the message attribute to identify
> > > > the message's body. A new XML element, for use as a child of
> > > > input/output/infault/outfault in interface definitions, will be
> > > > used
> > > to
> > > > specify one or more headers. The XML element is defined as
> > > > headerDef
> > > and
> > > > has
> > > > four attributes:
> > > > 
> > > >     * name - A NCNAME that uniquely identifies a header instance
> > > within a
> > > > specific input/output/infault/outfault within a specific operation
> > > within
> > > > a
> > > > specific interface. Name is optional and is only needed if a
> > > > binding
> > > will
> > > > need to provide additional information about the header.
> > > >     * header - The QNAME of a XML element schema definition that
> > > defines
> > > > the
> > > > contents of the header.
> > > >     * max - An int which specifies the maximum number of times
> > > >     that
> > > header
> > > > instance can be repeated. Max is optional and its default 
> > > value is 1.
> > > >     * min - An int which specifies the minimum number of times
> > > >     that
> > > header
> > > > instance can be repeated. Min is optional and its default 
> > > value is 1.
> > > > 
> > > > max MUST be greater than or equal to min.
> > > > 
> > > > The headerDef XML element can be used 0 or more times.
> > > > 
> > > > For example:
> > > > 
> > > > <definitions...>
> > > >    <interface...>
> > > >       <operation...>
> > > >          <input message="My:body">
> > > >             <headerDef header="My:header"/>
> > > >             <headerDef header="My:otherHeader" min="3" max="7"/>
> > > >             <headerDef name="optheader" header="My:header"
> > > >             min="0"/>
> > > >          </input>
> > > >       </operation>
> > > >    </interface>
> > > > </definitions>
> > > > 
> > > > The headerBody style depends on the binding to define if the
> > > > header ordering
> > > > is meaningful. In the previous example the first and third 
> > > headers are
> > > of
> > > > the same type. Allowing types to repeat is useful for bindings
> > > > where
> > > the
> > > > order of headers is meaningful.
> > > > 
> > > > The headerBody style will be useful with both of the bindings that
> > > WSDL
> > > > 2.0
> > > > provides, SOAP and HTTP as both of these protocols are based on
> > > > header/body
> > > > style messages. If this style is adopted then we can remove the
> > > element
> > > > attribute from the wsoap:header XML element and replace it 
> > > with a name
> > > > attribute that would point to the name of the associated 
> > > header in the
> > > > interface definition. The mustUnderstand and role attribute would
> > > remain
> > > > the
> > > > same.
> > > > 
> > > > The SOAP binding for the headerBody style would specify that when
> > > sending
> > > > a
> > > > message the header ordering SHOULD be maintained by the WSDL
> > > processor.
> > > > 
> > > > In the case of receiving a message the WSDL processor MUST 
> > > be able to
> > > > accept
> > > > SOAP headers in any arbitrary order and MUST be able to 
> > > accept headers
> > > > that
> > > > were not defined in the SOAP message's WSDL interface/binding
> > > definition.
> > > > 
> > > > SOAP headers MAY be implicitly rather than explicitly included in
> > > > an operation definition as a consequence of a WSDL function or a
> > > > SOAP
> > > module.
> > > > In other words, rather than explicitly including a reliable 
> > > messaging
> > > or
> > > > security header one can readily imagine such headers being 
> > > added as a
> > > > consequence of a WSDL function/SOAP module that required
> > > > reliability
> > > or
> > > > security of a certain type.
> > > > 
> > > > However, in many cases support for a particular function or 
> > > module may
> > > not
> > > > be widespread amongst WSDL processors (even if the application
> > > > layer
> > > above
> > > > the WSDL processor is aware of and able to handle the header
> > > > implied
> > > by
> > > > the
> > > > function/module) and so it may be necessary to include the 
> > > SOAP header
> > > > definition explicitly, even if it is redundant to a particular
> > > > function/module, in order to allow for the widest syntactic
> > > compatibility.
> > > > 
> > > > The following is an example of a WSDL operation and SOAP 
> > > binding that
> > > uses
> > > > the headerBody style.
> > > > 
> > > > <definitions xmlns:my="http://foo/bar">
> > > >    <types>
> > > >       <xs:scheme targetName="http://foo/bar">
> > > >          <xs:element name="headerOrBody" type="xs:string">/
> > > >       </xs:scheme>
> > > >    </types>
> > > >    <interface name="sample"
> > > > styleDefault="http://www.w3.org/@@@@/@@/wsdl/style/headerBody">
> > > >       <operation name="sampleOp1"
> > > > pattern="http://www.w3.org/@@@@/@@/wsdl/in-only">
> > > >          <input message="my:headerOrBody">
> > > >             <headerDef name="sampleOp1Header" 
> > > header="my:headerOrBody"
> > > > min="0"/>
> > > >          </input>
> > > >       </operation>
> > > >    </interface>
> > > >    <binding name="soapSimplebind">
> > > >       <wsoap:binding
> > > > protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/>
> > > >       <operation name="sampleOp1Binding">
> > > >          <input messageReference="sampleOp1">
> > > >             <header name="sampleOp1Header" mustUnderstand="True"/>
> > > >          </input>
> > > >       </operation>
> > > >    </binding>
> > > > </definitions>
> > > > 
> > > > To save space I used the same element for the header and the body.
> > > What's
> > > > interesting about this example is that while sampleOp1Header is
> > > optional
> > > > (min="0"), the binding specifies that mustUnderstand = "True".
> > > > What
> > > this
> > > > means is that IF the header is used THEN the mustUnderstand 
> > > attribute
> > > MUST
> > > > be put on the header and assigned the value true.
> > > > 
> > > > Either of the following SOAP 1.2 messages would be legal using the
> > > > previous
> > > > definition and binding:
> > > > 
> > > > <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
> > > >                          xmlns:my="http://foo/bar">
> > > >    <env:Header>
> > > >       <my:headerOrBody 
> > > mustUnderstand="true">really?</my:headerOrBody>
> > > >    </env:Header>
> > > >    <env:Body>
> > > >       <my:headerOrBody>Uh huh</my:headerOrBody>
> > > >    </env:Body>
> > > > </env:Envelope>
> > > > 
> > > > Or
> > > > 
> > > > <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
> > > >                          xmlns:my="http://foo/bar">
> > > >    <env:Body>
> > > >       <my:headerOrBody>Ahhh</my:headerOrBody>
> > > >    </env:Body>
> > > > </env:Envelope>
> > > > 
> > > > The HTTP binding would work similarly to SOAP but I'm waiting
> > > > until
> > > the
> > > > HTTP
> > > > POST/PUT proposal gets a bit firmer before I try to put in 
> > > details. I
> > > > think
> > > > the most interesting issue with HTTP header support is how to
> > > translate
> > > > the
> > > > XML element name and body for the WSDL header into a HTTP 
> > > header. One
> > > can
> > > > imagine a myriad of different encoding possibilities. A minimal
> > > encoding
> > > > would require the header body to be a string. But one could also
> > > imagine
> > > > an
> > > > encoding that either strips out elements or replaces elements with
> > > > a divider
> > > > character such as a ";". Perhaps we will need to support both and
> > > specify
> > > > which one to use on a header by header basis.
> > > > 
> > > > Thanks,
> > > > 
> > > > Yaron
> > > > 
> > > 
> > > 
> > 
> 
> 
> -- 
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com

Received on Thursday, 22 January 2004 13:12:15 UTC