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

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 Wednesday, 29 October 2003 23:57:27 UTC