RE: Header/Body Style Proposal

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
>
>

Received on Thursday, 22 January 2004 13:13:43 UTC