RE: XML Protocol: Proposals to address SOAPAction header

Hi all:

May I suggest the following interpretation?

SOAP is essentially a point-to-point protocol, and the binding information
that you use to talk to the guy on the other side of the wire is also
therefore point-to-point.

You need SOME level of "magical" data from outside the SOAP world to be able
to find and talk to someone - a simple example of this is the endpoint URI,
or the fact that you're using SOAP-over-HTTP, or perhaps
SOAP-with-attachments-over-HTTP.  I would purport that SOAPAction is just
like target URI - it's a piece of transport-specific binding information
which you may need to get the right thing to happen.  I think it's precisely
equivalent to saying "to talk to me, use HTTP POST to this URL" - it's all
just metadata.

If client C talks to intermediary I and then to server S, the contracts to
get the message there are from C->I, and then from I->S.  Either of these
links might run over any particular transport binding, and might require any
sort of transport-specific information such as SOAPAction values,
authentication credentials, multiplexing IDs, what have you.

If I is a "fixed path" intermediary, it will have a priori knowledge of S,
and any appropriate information it needs to contact it successfully.  In
this case, C must know the same type of contact information about I, but
nothing more.  In other words, it can appear to C that he's talking to I
with no knowledge that I talks to S behind the scenes.

On the other hand, if I is a "generic" intermediary which can potentially
talk to anywhere, we need some way of expressing to I that it's supposed to
talk to S in particular, and again, what specific info it needs to make that
connection.  As it stands, this is "out of band" to SOAP itself - C might
explicitly pass URLs, SOAPAction values, etc. in the message, or you might
rely on some registry to get the information for you based on something else
(C's address, authentication info, the QName of the body element, etc).

The main point here is that I believe SOAPAction to be a useful bit of
transport-level optimization information, but in a similar way that almost
anything could be specified by a particular transport binding.  As I
mentioned at the F2F, I would like to see the group discuss two issues
before I personally feel like we can make any really well-informed decisions
about SOAPAction.

First, what is a transport binding?  What information can be carried there,
which bits can the SOAP processor itself (or applications built on top)
utilize to access extra functionality or optimize things (for example, the
implicit correlation provided by an HTTP binding), etc.  The tension here is
between simple bindings that everyone can use without any "extra" knowledge,
and more full-featured bindings that provide a lot of value-add for the
users.

Second, what do we want to say, if anything, about metadata?

Argh - I have to head to a meeting, so I can't expound further at the
moment, but I want to get this basic thought out there and see what you all
think.

--Glen

Received on Monday, 11 June 2001 15:03:55 UTC