Re: Header/Body Style Proposal

Three of these scenarios (1, 2, and 4) are as or more easily 
implemented using the properties and features functionality.  Which 
apply to interfaces, a point that BEA may have missed (properties and 
features can be associated with both interfaces, to require or indicate 
support for a particular functionality, or with bindings, to specify 
how this information is encoded in the message).  In my opinion, the 
properties and features functionality does a better job than this 
proposal does, in these three cases, as it encourages better 
definitions, not just slap-a-header-on.

As for use case three, I can't comment.  What's a WSDL function?

On Jan 22, 2004, at 4:17 PM, Yaron Goland wrote:

> There are four scenarios that motivated my proposal. In each case 
> static
> headers are used whose definition rightfully belongs at the interface, 
> not
> the binding level. I believe that any one of these scenarios, much 
> less all
> four, justifies the inclusion of the header/body style in WSDL 2.0.
> Scenario #1 - Backwards/Forwards Compatible Evolution
> 	A system deploys a new version of Interface Alpha called Alpha1. 
> Alpha1
> consists of nothing but backwards compatible changes to Alpha. 
> Specifically,
> Alpha1 adds new optional features to the Alpha operations. Due to the
> numerous problems with XML Schema that David Orchard has pointed out 
> [1]
> it's not always possible to put the optional features directly into 
> the old
> message body. Therefore the new optional features are added as a 
> header to
> the original message. When a message arrives at Alpha1 the processor 
> checks
> to see if an extension header is present. If so then it implements the
> message with the additional options offered by the extensions. If not, 
> then
> it processes the message as the original interface Alpha would have.
> 	If a Alpha1 client is talking to a Alpha server then the Alpha1 
> client can
> send a Alpha1 message with the optional features in the header. The 
> Alpha
> server will ignore the optional header and process the message 
> normally.
> 	This is why we can refer to Alpha1 as being both backwards and 
> forwards
> compatible. Alpha clients can send messages to Alpha1 servers and 
> Alpha1
> clients can send messages to Alpha servers and everyone gets a 
> reasonable
> experience.
> 	A classic example of this design pattern is byte-range headers in 
> HTTP. If
> someone sends a GET request with a byte-range header to a server that
> doesn't support byte-ranges then the client receives back a normal GET
> response. If the client sends the GET request with a byte-range header 
> to a
> server that does support byte-ranges then the client gets back a 
> dedicated
> byte-range response. But in all cases everyone gets a reasonable 
> result.
> 	To implement this scenario in WSDL 2.0 we need a way to specify 
> headers
> directly in the interface definition so that the various features 
> added in
> the optional extensions can be directly specified.
> Scenario #2 - Inbound Intermediary Communication
> 	A system deploys interface Beta. Interface Beta handles various types 
> of
> messages but is also able to handle certain kinds of data from
> intermediaries. When intermediaries are deployed in the system Beta 
> runs in
> they need to know what kinds of application specific data can be 
> handled by
> the systems downstream. Beta is able to specify this information in 
> its WSDL
> by defining headers it understands. These headers are not 
> infrastructure
> based and do not represent functionality implemented at the WSDL level 
> so it
> is not useful to define them as WSDL functions as the WSDL engine will
> obviously not provide support for an application specific header.
> 	For example, a bank implements a web service Beta that is used to 
> evaluate
> loan requests. The quality of service used to process the loan request 
> will
> depend on how much the bank values the customer. In the absence of any
> specific customer 'value' data the loan system will use a default 
> quality
> level. Beta only knows about the customer's credit worthiness, it knows
> nothing about how much the bank 'values' the customer. Instead an
> intermediary is used that is tied to a database of customer 'value'
> information. When any request enters the system the intermediary 
> examines
> the request, determines if it is a customer oriented request, if it is 
> then
> it looks up the customer in its database and slaps a header onto the 
> request
> with customer value information. It is that header that Beta has been
> programmed to look for in setting its quality of service.
> 	The key issues in this scenario are - how did the intermediary know 
> that
> the message being sent to Beta was a customer request, how did it know 
> how
> to pull out the customer information and how did it know that Beta 
> would be
> able to handle the header?
> 	The answer to the first two questions is actually pretty easy if you 
> are
> familiar with BPEL. BPEL has a concept called message properties that 
> are
> defined using property Alias's. Both properties and property Aliases 
> are
> defined in the WSDL file. All that would be required therefore is to 
> give
> the intermediary the WSDL for Beta and the intermediary can see if the
> 'CustomerID' property (for example) is available (via a propertyAlias) 
> on
> any of the messages that Beta receives. If it is then the intermediary 
> knows
> that the message is customer related, can find the CustomerID and 
> therefore
> can do its database lookup.
> 	The third question, how did the intermediary know Beta would process 
> the
> header, is important because the intermediary doesn't want to do the 
> work of
> looking up the customer value if Beta is just going to ignore it. It is
> tempting to just say 'oh well, there was a WSDL function that says 
> that Beta
> supports the header.' But that is an evasion. If that answer is 
> acceptable
> then we should pull out message definitions from WSDL as well since 
> one can
> just as easily say 'I don't need a message definition, I can just 
> declare a
> function'. The reality is that there is a syntax and it needs to be
> declared, especially so that it can itself be versioned. E.g. Beta may
> support the customer value header with a set of extensions.
> 	This is where being able to declare headers in the interface is so
> important. By allowing Beta to specify its support for the header 
> explicitly
> in its interface the intermediary knows both that Beta supports the 
> header
> and what syntax of the header it supports.
> Scenario #3 - WSDL Function Complementary Declaration
> 	Let us assume that WSDL functions take off. Even so, there is likely 
> to be
> a fairly long lag between when a function is defined and when it is 
> widely
> supported in WSDL engines. In the case of functions that define 
> headers this
> means it will be necessary to both include the function for WSDL 
> engines
> that support it and explicitly include the header declaration for WSDL
> engines that don't support the function but whose applications do 
> support
> the associated functionality.
> 	For example, imagine a new header that is a signal that specifies 
> that a
> previously sent message has been successfully processed. A WSDL 
> function is
> defined that identifies that an interface supports receiving this type 
> of
> signal. However, it is going to take some time before all WSDL engines 
> are
> updated to provide support for this new function. In the meantime
> applications that are build on WSDL engines that don't support the 
> function
> but still want to receive the header will have no choice but to 
> explicitly
> include the header's declaration so that they can see and process the
> header. Therefore the header's definition is included in the interface 
> even
> though it is redundant with a function.
> Scenario #4 - WSDL Interface Based Languages (e.g. BPEL)
> 	BPEL is a new Web Services programming language being standardized in 
> that uses WSDL 1.1 as its 'view' of the world. In BPEL everything is a
> portType. It is universally expected within the BPEL TC that when WSDL 
> 2.0
> is released BPEL will move over to it (which, btw, is why SOAP 1.1 
> support
> in WSDL 2.0 is so crucial since BPEL programs need to work with 
> existing web
> services). In fact, there is already a tracking item in BPEL to watch 
> 2.0 and to try, as best we can given the requirement to be based on 
> 1.1, to position BPEL for an easy transition over to WSDL 2.0 when it's
> ready.
> 	In BPEL (using WSDL 2.0 terminology), if it isn't in the interface 
> then it
> can't be seen by the programmer. BPEL completely isolates the 
> programmer
> from the binding, which is a great thing as it allows programs to be 
> truly
> portable. This is, after all, the essence of the WSDL vision as I 
> understand
> it and why interfaces and bindings are kept separate.
> 	However this means that if the programmer needs access to a header, 
> see my
> previous scenarios for several examples of why a programmer would need 
> this
> access, the only way the programmer can get it is if the header is 
> defined
> in the interface. WSDL functions could be used here but only if the 
> engine supports that particular function. As scenario #3 illustrated 
> there
> is often a gap, sometimes an infinitely long one, between when a 
> function is
> introduced and when engines add support for it. In order for a BPEL
> programmer to gain access to a header described by a function that 
> isn't
> supported by their engine they must be able to express the header's
> definition in their interface definition.
> [1]
>> -----Original Message-----
>> From: []On
>> Behalf Of Sanjiva Weerawarana
>> Sent: Thursday, January 22, 2004 9:06 PM
>> To: Amelia A Lewis; David Orchard
>> Cc:;
>> 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" <>
>> To: "David Orchard" <>
>> Cc: <>; <>
>> 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 <> 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:
>>>>> []On Behalf Of Jonathan Marsh
>>>>> Sent: Wednesday, January 21, 2004 12:20 PM
>>>>> To:;
>>>>> 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
>>>>>   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:
>>>>>> []
>>>>> On
>>>>>> Behalf Of Yaron Goland
>>>>>> Sent: Tuesday, January 20, 2004 4:26 PM
>>>>>> To:
>>>>>> 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="">
>>>>>>       <operation name="sampleOp1"
>>>>>> pattern="">
>>>>>>          <input message="my:headerOrBody">
>>>>>>             <headerDef name="sampleOp1Header"
>>>>> header="my:headerOrBody"
>>>>>> min="0"/>
>>>>>>          </input>
>>>>>>       </operation>
>>>>>>    </interface>
>>>>>>    <binding name="soapSimplebind">
>>>>>>       <wsoap:binding
>>>>>> protocol=""/>
>>>>>>       <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=""
>>>>>>                          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=""
>>>>>>                          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.

Received on Thursday, 22 January 2004 17:24:45 UTC