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

Hi Paul!

For some reason (maybe just because Outlook sucks :( ) my mail client isn't
indenting correctly on certain messages, so I'll just reply up here:

I understand the desire for what you suggest, but the problem is that any
ability to identify which part of the system a particular header is destined
for implies some particular layering architecture in the software, which is
something we specifically wanted to avoid in SOAP at least.

I think that there are certainly some extensions that have a clear effect on
the application, and others that don't, but that might change depending on
the particular system using them - for instance, a security extension with a
required username/password might cause a setCredentials() API to appear on a
stub in one system, and in another might have no visible effect because the
username/password are sent based on the credentials which already exist due
to some "single-sign-on" context.

So the best we can really do is provide identifiers (feature/module URIs)
which we can mark as required, and trust the software to know which ones it
can really handle and which ones it can't.  This really isn't any different
than what we do with operation names and schema types... we trust that
someone will know how to fill out a <myco:expenseReport> element with
semantically meaningful data in exactly the same we we trust that someone
will correctly implement the WS-ReliableMessaging state machine if that
extension is engaged... it's just that in the latter case we expect a lot
more cases where middleware code will help us out.

--Glen

----- Original Message ----- 
From: <paul.downey@bt.com>
To: <gdaniels@sonicsoftware.com>; <Roberto.Chinnici@Sun.COM>;
<sanjiva@watson.ibm.com>
Cc: <www-ws-desc@w3.org>
Sent: Tuesday, October 28, 2003 5:25 AM
Subject: RE: PROPOSAL: Drop interface/operation/(input|output)/@headers


Glen wote:
> 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.

One problem we have with current tools is some generate application code for
headers defined in WSDL whist other ignore them altogether.

I think it would useful if a toolkit could *know* if a header was intended
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 07:55:17 UTC