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

It is very important that we do not confuse programming model with a
description of message-level interoperability.

If you need a hint about how to surface something in the programming
model, you should consider defining that as something that may be
ignored by endpoints that have their own, potentially-very different
idea of programming model.


> -----Original Message-----
> From: []
> Behalf Of
> Sent: Tuesday, October 28, 2003 2:26 AM
> To:; Roberto.Chinnici@Sun.COM;
> Cc:
> Subject: RE: PROPOSAL: Drop
> Glen wote:
> > Correct.  Essentially, the only kinds of headers that are worth
> specifying
> with the mechanism that exists today are the "cookie-esque" ones -
> "please send me the value 'xq57jb' back in the header
> Oh, and send it on every single message, too."  Anything with more
> semantics than that can't really be accommodated with the current
> So I think it's a pretty simple matter to define a "sideband data"
> module which simply takes a property consisting of a set of elements,
> inserts them as SOAP headers.
> One problem we have with current tools is some generate application
> for headers defined in WSDL whist other ignore them altogether.
> I think it would useful if a toolkit could *know* if a header was
> for an application or for a lower-layer protocol ?
> - could F&P be used to describe which /role/ a header is intended for
> - or maybe headers *and* F&P would provide this distinction ?
> - or am i barking ?
> --
> Paul Sumner Downey
> Web Services Integration
> BT Exact

Received on Tuesday, 28 October 2003 20:45:14 UTC