Re: Header/Body Style Proposal

I believe that Glenn has the action item for the feature specifying
generic headers.  He is not, as I understand it, currently available.

If BEA would care to recast their proposal as such a generic feature,
using the properties & features functionality, I suspect Glenn would not
object (although he might offer amendments, perhaps even major ones). 
TIBCO would also be much more sympathetic to the proposal, so recast.

Amy!
On Thu, 22 Jan 2004 10:14:54 -0800
David Orchard <dorchard@bea.com> wrote:

> Where can I look to see the syntax for specifying headers in WSDL? 
> Could you provide me with a URI?  I'd like to be able to compare the
> current approach in WSDL that my company would have to implement
> compared to our proposal.
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> > Sent: Thursday, January 22, 2004 9:06 PM
> > To: Amelia A Lewis; David Orchard
> > Cc: jmarsh@microsoft.com; www-ws-desc@w3.org
> > Subject: 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
> >
> >
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 22 January 2004 13:49:26 UTC