Re: PROPOSAL: Drop interface/operation/(input|output)/@headers

I'm really talking about application data, not utility data. I see 
several scenarios of use. One is to use a processor's underlying (header 
block) streaming machinery, without having to implement this by hand 
with the body, for each application.

Another is polymorphism and indexing. You get this for free at the 
header block level (depending on your SOAP processor).

Yet another is being able to restructure and distribute the 
service/ultimate receiver at run time (as compared to design time). For 
example, a SOAP message may contain a document to print. The document 
may need to be rasterized first. This is likely to be done by the 
ultimate receiver; but in some settings it may be rasterized instead by 
an intermediary. It will help if the document is targeted to a role that 
may be played by the ultimate receiver or an intermediary.

Cheers,

Jean-Jacques.

Glen Daniels wrote:

> What can I say, Amy, but (unsurprisingly) +1.
> 
> And Jean-Jacques, can I ask *why* you would want to do this splitting
> of application data into headers/body?  If it's really application
> data, it seems like you'd just put it in your input/output and let it
> ride in the body.  And if it's really some kind of QoS / sideband /
> utility data that isn't directly relevant to the main purpose of your
> application, it seems like you'd express that in a different way (as
> extensions)....
> 
> --G
> 
> ----- Original Message ----- From: "Amelia A. Lewis"
> <alewis@tibco.com> To: <paul.downey@bt.com> Cc:
> <jean-jacques.moreau@crf.canon.fr>; <sanjiva@watson.ibm.com>; 
> <umit.yalcinalp@oracle.com>; <www-ws-desc@w3.org>; 
> <youenn.fablet@crf.canon.fr> Sent: Wednesday, October 29, 2003 10:08
> AM Subject: Re: PROPOSAL: Drop
> interface/operation/(input|output)/@headers
> 
> 
> 
>> A number of specifications currently going forward use headers to
>> supply metainformation to the ultimate receiver.  See, for
>> instance, WS-Addressing, WS-Security (in some use cases; can also
>> be intermediary), WS-RM.
>> 
>> What's interesting about these cases (as I've experienced them) is
>> that they map *very* nicely to features and properties, but very
>> *badly* to "stick-in-this-header".  As a result, they are mostly
>> *not* modelled in WSDL 1.1, because they can't be modelled
>> usefully.  F&P provides that capability.  (Actually, Glen and I
>> were both at an interop dealie for WS-RM recently; the lack of
>> reference to the headers in the WSDL intrigued me ... there was no
>> way in a 1.1 WSDL to specify the requirements of the service)
>> 
>> I've seen much less necessity for slap-on-a-header style.  One
>> customer that I know of has implemented a database access service
>> in WSDL, and attaches a standardized (multipart) header to every
>> message (transaction id, authentication information, various other
>> bits).  Looking at that, my reaction was "that would be *so* much
>> easier to do if a feature were defined", because it would carry
>> information about what is required in the abstract portion, and
>> information on binding details in the binding. And the feature
>> itself allows much greater flexibility, which the current design
>> *cannot*.
>> 
>> Amy! On Wed, 29 Oct 2003 13:38:18 +0000 paul.downey@bt.com wrote:
>> 
>> 
>>> I've formed the view that the body is for the application,
>>> headers are for intermediaries - but i have to admit that it's a
>>> 'lowest common denominator' decision i've hit on following
>>> practical difficulties exchanging headers with some of the
>>> current toolkits ..
>>> 
>>> Paul
>>> 
>>> -----Original Message----- From: Jean-Jacques Moreau
>>> [mailto:jean-jacques.moreau@crf.canon.fr] Sent: 29 October 2003
>>> 13:31 To: Sanjiva Weerawarana Cc: 'Umit Yalcinalp';
>>> www-ws-desc@w3.org; FABLET Youenn Subject: Re: PROPOSAL: Drop 
>>> interface/operation/(input|output)/@headers
>>> 
>>> 
>>> 
>>> Let's try the following analogy: would you always put all of your
>>>  program into a single main() function? Probably not. I contend
>>> the same is true for the body.
>>> 
>>> My concern is that we broke (part of) our model when we removed 
>>> message parts (sic). At the abstract/interface layer, as you
>>> suggest, I should indeed be able to describe my application data
>>> as a single, large complex type. However, I am currently unable
>>> to say, later in the binding, that part of this complex type is
>>> serialized as a header and the rest as the body.
>>> 
>>> Instead, currently, I have to model my application data as two, 
>>> independent complex types, and refer to the first for the header
>>> and to the second for the body. However, this seems to break the
>>> layering you are suggesting.
>>> 
>>> Am I missing something obvious?
>>> 
>>> JJ.
>>> 
>>> Sanjiva Weerawarana wrote:
>>> 
>>> 
>>>> "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
>>>> writes:
>>>> 
>>>> 
>>>>> It may be a matter of taste if the corresponding WSDL should
>>>>> mirror
>>>> 
>>>> that >  separation of concerns, i.e. headers only in the
>>>> binding, not in the >interface.
>>>> 
>>>> 
>>>> Its not a matter of taste to me but rather a matter of
>>>> principle; the abstraction should support thinking about the
>>>> data involved and if there's a need for headers just insert
>>>> them using soap:header.
>>>> 
>>>> 
>>>> 
>>>>> To make things more concrete, let's suppose my application
>>>>> deals
>>>> 
>>>> with >two complex types, one of which I want to serialize as a
>>>> SOAP body, the >other as a SOAP header block.
>>>> 
>>>> 
>>>> See that's the wrong place to start IMO- applications don't
>>>> start by thinking about two pieces of data and where they come
>>>> from the SOAP envelope. If the app has two pieces of data, then
>>>> the solution is to send both as payload. If in sending that it
>>>> needs to indicate some additional headers to be sent, then use
>>>> soap:header to do it.
>>>> 
>>>> 
>>>> 
>>>>> With your proposal, how would I do this?
>>>> 
>>>> 
>>>> If the 2nd piece of data is indeed a SOAP header, then put a 
>>>> soap:header element in the binding to insert that header and
>>>> put only the first guy as the payload.
>>>> 
>>>> Sanjiva.
>>>> 
>>>> 
>>> 
>> 
>> -- Amelia A. Lewis Architect, TIBCO/Extensibility, Inc. 
>> alewis@tibco.com
>> 
>> 
> 
>

Received on Friday, 31 October 2003 06:09:42 UTC