Re: SOAPAction Proposal

I'm new to the list, so if I missed a few things (i.e. I have bad
assumptions in the following message), I apologize ahead of time.  
 
I don't think we would want to mandate the value of SOAPAction being
related to the first child element of soap:Body.  This would require
that the SOAP implementation be HTTP aware or that the HTTP
implementation would need to know about SOAP.  Part of the thought
behind the SOAPAction field was to allow Network admins to filter on the
SOAPAction HTTP header without having to peek into the actual message.
This gives us the SOAP/Transport layer independence.  Once HTTP routes
my message to the endpoint, I don't think my endpoint should be
concerned how it got there.  
 
Of course, the HTTP-->SOAP bridging mechanism would need to know about
both.  This makes me wonder if SOAPAction is even necessary.  Given that
SOAPAction is HTTP specific, I believe you can get all the benefits of
SOAPAction through use of the URL.  You can send object/method hints in
the URL-we already do that with CGI type technologies without ill effect
(think ASP, JSP, etc.).  Web admins already understand how to filter on
URL, so you don't have to teach them about the peculiarities of SOAP.  I
know the argument for the header-it tells that this is supposed to be a
SOAP message.  The problem with this is that it never mattered for CGI
stuff (I don't think a CGIAction field exists and no one I know wants
one).  Given that the item isn't even needed for SMTP based SOAP,
ditching the concept altogether might be a good idea. You would still
need some way of mapping the URL to the message.  Lots of
implementations route on the GET header and ignore the SOAPAction.
"Monolithic endpoints" are giving way to special purpose endpoints.  
 
For example, assume an object named foo has three operations: bar1,
bar2, and bar3.  Instead of having the endpoint for all of these
operations be 
            http://someurl/foo <http://someurl/foo> 
and then routing on SOAPAction, I could also do this:
            http://someurl/foo#bar1
            http://someurl/foo#bar2
            http://someurl/foo#bar3 <http://someurl/foo#bar3> 
 
Voila, I know the intent because my HTTP GET header will ask for
/foo#bar1 and I will have intent already without any new machinery.  And
no, this doesn't feel like a kludge-I already do nastier things with ASP
pages.  
 
What would this mean for the soap routers (pieces that deliver message
between web server and actual code)?  Prior to executing the intended
method or delivering the document, they would have to make sure that the
message was valid in the context of its endpoint (does the message
conform to the format accepted by the endpoint?).  Since the thing has
to be parsed anyhow, there shouldn't be any issues with handing the
ultimate recipient of the message a fully parsed DOM.  The more complex
toolsets could use WSDL to do the validation.  The simpler ones (let's
say RPC-oriented only) could reject the message if the first child of
the body did not match what it expected (<-- don't laugh, my dumb as a
brick implementation does just this-see http://scottseely.com/soap.htm
<http://scottseely.com/soap.htm> ).  
 
So, my proposal is to drop SOAPAction altogether and make the HTTP
binding information better.  This work could then be transferred to SMTP
and other protocols as well.  Just my .02.
 
 
_______________________________________________
Scott Seely
MSDN Architectural Samples
http://msdn.microsoft.com/webservices
<http://msdn.microsoft.com/webservices> 
Author of SOAP:
<http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=01309076
34>  Cross Platform Web Service Development Using XML (July, 2001)
 
>Message-ID: <003401c0d3b0$68a65550$a5fe55cb@greyarea>
From: "Martin Gudgin" < marting@develop.com
<mailto:marting@develop.com?Subject=Re:%20SOAPAction%20Proposal&In-Reply
-To=%3c003401c0d3b0$68a65550$a5fe55cb@greyarea%3e&References=%3c003401c0
d3b0$68a65550$a5fe55cb@greyarea%3e> >
To: "XML Protocol Comments" < xml-dist-app@w3.org
<mailto:xml-dist-app@w3.org?Subject=Re:%20SOAPAction%20Proposal&In-Reply
-To=%3c003401c0d3b0$68a65550$a5fe55cb@greyarea%3e&References=%3c003401c0
d3b0$68a65550$a5fe55cb@greyarea%3e> >
Date: Thu, 3 May 2001 17:06:55 +0800
Subject: SOAPAction Proposal
 
I've been reading the mails on SOAPAction, there seems to be some
sentiment
for the idea that the value of SOAPAction should reflect some
information in
the body of the message. Here is a proposal for discussion;
 
The value of SOAPAction *must* be the namespace URI and local name of
the
first element child of soap:Body separated by a #. If the value of
SOAPAction does not contain that value the server *must* generate a
fault.
 
e.g.
 
POST someuri HTTP/1.1
Content-Type: text/xml
Content-Length: nnnn
SOAPAction: myuri#myelement
 
<soap:Envelope xmlns:soap='uri for soap' >
  <soap:Body>
    <m:myelement xmlns:m='myuri' />
  </soap:Body>
</soap:Envelope>
 
Note that currently SOAPAction can be anything, it doesn't need to
reflect
any piece of information in the body of the message. This proposal is
similar ( if not identical... ) to the SOAPMethodName in SOAP 1.0[1]
 
Flames, comments etc. to the usual address,
 
Martin Gudgin
DevelopMentor

Received on Thursday, 3 May 2001 10:09:01 UTC