- From: Dick Brooks <dick@8760.com>
- Date: Mon, 7 May 2001 07:55:46 -0500
- To: "Martin Gudgin" <marting@develop.com>, "Jake Savin" <jake@userland.com>, "Painter, Philip" <Philip.Painter@compaq.com>, <frystyk@microsoft.com>, "'Daniel Barclay'" <Daniel.Barclay@digitalfocus.com>
- Cc: <xml-dist-app@w3.org>
Martin writes: >I'm tempted to build a table of SOAPAction usage vs. implementation. >Categories off the top of my head would be; dispatching ( figuring out which >piece of code to run ), routing ( figuring out where the message should >go ), filtering ( figuring out whether the message should be allowed >through ), fixed ( some fixed value, e.g. ebxml ). Anyone got any others? >Would such a table be useful? The ebXML implementations I'm aware of use the SOAPAction to "invoke" an ebXML aware handler. I think of this as dispatching, as opposed to "fixed". I think there are two distinct concepts at work here, "how SOAPAction is used" and "what SOAPAction contains". I believe the contents of SOAPAction are defined by the implementer of a SOAP server, or in the case of ebXML, by formal specification. How SOAPAction is used becomes a matter for the implementer to decide, and I believe in many cases this will be relative to the POST request-URI (in the HTTP case). In other words, if the request-URI is a message broker service then SOAPAction may be used for dispatching. If, on the other hand, the request-URI is a specific, message aware handler then SOAPAction may not serve any purpose (e.g. /servlet/stockquery). I think of it this way: Usage Contents ------------ ------------------------- Dispatching determined by implementer, or formal spec Routing dynamic value Filtering fixed value Dick Brooks (ebXML liaison) http://www.8760.com/
Received on Monday, 7 May 2001 08:46:30 UTC