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 10:09:15 UTC