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

All this sounds very SOAPish. Doesn't soap:header satisfy these
needs?

Sanjiva.

----- Original Message -----
From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
To: "Glen Daniels" <gdaniels@sonicsoftware.com>
Cc: "Amelia A. Lewis" <alewis@tibco.com>; <paul.downey@bt.com>;
<sanjiva@watson.ibm.com>; <umit.yalcinalp@oracle.com>; <www-ws-desc@w3.org>;
<youenn.fablet@crf.canon.fr>
Sent: Friday, October 31, 2003 5:08 PM
Subject: 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 08:16:36 UTC