RE: [i95, i22] - Proposal for clarifying use of SOAPAction

So this is one of the more fascinating issues to me in SOAP.  I'm in the
"anti" category for the SOAPAction.  I consider it at best a duplication of
what the URI should be.  Based on the message posted by Jake, it seems that
the SOAP Action header basically replaces the called URI (Jake's words --
"URI specified in the HTTP headers is ignored by our SOAP responder") which
seems to me to be counter to the way the web works.  The basic nature of the
web is that we GET or POST items to URIs and that the URI is the
dispatching/routing mechanism in this case, identifying the resource for
dispatching SOAP calls.  Otherwise, in the case of Frontier, the URI for
SOAP services is basically always the root of the server, meaning that the
server is expected to understand the semantics of the SOAPAction header as
opposed to the URI dispatcher that a web server is expected to be.  

So that means that the SOAPAction header must be processed by the web server
itself, as opposed to using a URI-routed mechanism (CGI/ISAPI/NSAPI/etc.).
I have no problem with the URI being a pointer to a routing table if that's
how the web service provider chooses to implement it, but it seems
counter-intuitive to me that it would be acceptable to just ignore the
called URI in favor of processing a message header.  

Overall, I'd like to see the SOAPAction header just go away.  I've heard
arguments that it's necessary for SOAP intermediaries, but I'm not certain I
buy that either.  If an XMLP intermediary must understand the SOAPAction
header, then it's next stop is to process some amount of the XML encoded
within the message.  If that's the case, then again the SOAPAction header is
redundant since it doesn't really add any value to the XMLP message -- the
XMLP message should contain any of the information that the SOAPAction
header would have.  If the problem is that a SOAP intermediary must be able
to identify the message as a XMLP message, then I'd suggest we go back and
look at MIME-types, which would be typical from the web's perspective,
rather than add headers.  Remember that there is an entire set of
infrastructure out there that we should be sure that we don't disrupt with
the addition of XMLP.  My follow-on to Gudge's question is the following --
"what circumstances exist where a SOAPAction header must be used instead of
any of the other mechanisms that the web already provides (URIs, direct
processing of the XMLP message, etc.)?"

Regards --

jeffrey kay <jkay@engenia.com>
chief technology officer, engenia software, inc. 
"first get your facts, then you can distort them at your leisure" -- mark
twain 
"golf is an endless series of tragedies obscured by the occasional miracle"
-- sports illustrated 
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein  

> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Monday, May 07, 2001 8:56 AM
> To: Martin Gudgin; Jake Savin; Painter, Philip; frystyk@microsoft.com;
> 'Daniel Barclay'
> Cc: xml-dist-app@w3.org
> Subject: RE: [i95, i22] - Proposal for clarifying use of SOAPAction
> 
> 
> 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 09:58:41 UTC