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 10:17:00 UTC