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

Hi Roberto, all:

> etc. - those will be the purview of the document  > 
> specifying each feature (most likely in English or Sinhalese).
> 
> Certainly not. I'd be fine with replacing an explicit way of 
> defining headers with an implicit one (F&P) as long as it's 
> clear that all reasonable uses of explicit abstract headers 
> are covered. In other words, I'd like to see evidence that 
> the kind of headers that people would declare today using 
> @headers are good candidates for being abstracted into a 
> feature, possibly parameterized by one or more properties (if 
> I understood Glen's writeup).

Correct.  Essentially, the only kinds of headers that are worth specifying
with the mechanism that exists today are the "cookie-esque" ones - i.e.
"please send me the value 'xq57jb' back in the header 'myns:SeekritCode'.
Oh, and send it on every single message, too."  Anything with more complex
semantics than that can't really be accommodated with the current syntax.
So I think it's a pretty simple matter to define a "sideband data" SOAP
module which simply takes a property consisting of a set of elements, and
inserts them as SOAP headers.

> I know today what burden is placed on the WSDL author who 
> decides to add an abstract header to an operation. I can 
> surmise that replacing it with a feature would be n times 
> more work. Perhaps this factor of n doesn't matter because 
> features are the right way to solve this problem and @headers 
> are just a hack, but I'd like to see some proof of it.

There are two ways of thinking about the current way of dealing with
headers.  First, I can describe a given header QName and leave the value up
to the user - in this case, I am trusting the code or the user to understand
what the appropriate value is to stick in there, which is exactly the same
thing as asking them to understand a feature/property/policy identifier (the
semantics are external).  Aside from the fact that this is a really bad way
to do things (you can't easily specify extensions for which certain headers
may or may not appear depending on context, for instance), the work involved
is the same as in the F&P case.

Second, I can describe a particular value for a given header, as in the
"cookie-esque" description above.  There is arguably some use in this sort
of thing (dispatch, for instance?), and as noted we could define a normative
"sideband data" module to handle this.  It would need to be very clear in
the spec for the module that you can use it to send/receive arbitrary
headers, and it's up to the user to make sure that the receivers are capable
of correctly understanding those headers.

> BTW, I'd be interested in furthering the policy discussion a 
> bit. In particular, your argument about @headers being 
> useless without a policy would seem to extend to features and 
> properties as well. Would you then argue for removing F&P on 
> the same grounds?

Not to speak for Sanjiva here, but I would say this doesn't make sense.  F&P
is a way of expressing policies, as well as controlling their realizations
in on-the-wire messages.  The @headers syntax is simply a way to
mechanically control the structure of a SOAP message in a very blunt
fashion, which is why it's confusing and not as generally useful.

Thanks,
--Glen

Received on Monday, 27 October 2003 15:01:41 UTC