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

Jeff wrote:
>I'd augment this with a SOAP/XMLP MIME-type that clearly identifies the
>contents of the POST as a SOAP message.  We might want two MIME-types, one
>for a request and one for a response.  As a result, I'm not sure where the

In the BS era (Before SOAP) the ebXML Message Service used a
multipart/related
media type AND a parameter, "type=application/eb+xml", to "signal" a
receiver that the
message contained an ebXML message. Now in the AS era (After SOAP), every
SOAP message carries a mime media type of text/xml, and this makes it really
difficult
to discriminate a SOAP message from any other XML message, without
scrutinizing the
XML data. The SOAPAction header serves the same purpose as the "type
parameter"
from ebXML's perspective. It allows a receiver to discern an ebXML message
from
other XML messages without having to process the XML.

IMHO, SOAPAction is needed so that generic message brokers will have enough
information
to be able to dispatch the message for processing by the appropriate
handler. There
are cases where the request-uri is a SOAP aware processor and SOAPAction may
not provide much value. Implementers are free to use a SOAPAction: "" in
these cases.

I really don't see a big issue with mandating the use of SOAPAction, so long
as there is
a simple means to ensure that it's used correctly. If WSDL is used to convey
SOAP
service definitions, including the use of SOAPAction, then there shouldn't
be a problem.

Are there people out there who aren't going to use WSDL to describe their
SOAP services?

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Jeffrey Kay [mailto:jkay@ENGENIA.COM]
> Sent: Monday, May 07, 2001 3:25 PM
> To: 'Henrik Frystyk Nielsen'; Dick Brooks
> Cc: xml-dist-app@w3.org
> Subject: RE: [i95, i22] - Proposal for clarifying use of SOAPAction
>
>
> Henrik --
>
> > Remember that SOAP is a protocol - it is not a server API which makes
> > SOAP fundamentally different from CGI-scripts, server
> > modules, servlets
> > etc. Comparing SOAP to CGI scripts makes no sense - it would be
> > perfectly legitimate to implement a SOAP processor as a CGI
> > script. This
> > has already been brought up on this thread [10].
>
> This again raises problems.  I understand that we want to think
> of SOAP as a
> wire protocol, but that still makes the SOAPAction header inconvenient.
> Essentially, the HTTP binding with the SOAPAction header further qualifies
> the nature of the content carried over HTTP, but this should be completely
> unnecessary since HTTP is already well suited for submitting requests and
> receiving responses.  Look at this from a minimalist perspective -- if the
> SOAPAction header isn't there and the semantics for a 500 error
> response are
> unloaded, how would that cause problems in SOAP? It wouldn't cause any as
> best as I can tell.
>
> > HTTP GET requests have the property that *all* parameters are
> > expressed
> > either as part of the URI (after the "?" mark) or within the
> > HTTP header
> > fields. The semantics of GET is not application based - GET is defined
> > by HTTP to mean something very specific namely "give me a
> > representation
> > of yourself".
>
> In RFC1945 [http://www.ietf.org/rfc/rfc1945.txt], GET is defined
> as follows:
>
>    The GET method means retrieve whatever information (in the form of an
>    entity) is identified by the Request-URI. If the Request-URI refers
>    to a data-producing process, it is the produced data which shall be
>    returned as the entity in the response and not the source text of the
>    process, unless that text happens to be the output of the process.
>
> If we imagined that GET could be used with SOAP, then the SOAP
> process would
> be the data-producing process that would return the produced data in the
> above definition.
>
> > The definition of POST is slightly more complex. What SOAP effectively
> > does is to provide a useful mechanism for describing parameters in XML
> > rather than in HTTP header fields but as it is still an HTTP
> > request, we
> > have to follow HTTP semantics.
> >
> > Note btw that SOAP doesn't require that SOAP requests are followed by
> > responses - the HTTP binding in SOAP says nothing like that.
>
> However, we look at SOAP as a POST process, defined as follows:
>
>
>    The POST method is used to request that the destination server accept
>    the entity enclosed in the request as a new subordinate of the
>    resource identified by the Request-URI in the Request-Line. POST is
>    designed to allow a uniform method to cover the following functions:
>
>       o Annotation of existing resources;
>       o Posting a message to a bulletin board, newsgroup, mailing list,
>         or similar group of articles;
>       o Providing a block of data, such as the result of submitting a
>         form [3], to a data-handling process;
>       o Extending a database through an append operation.
>
> [I must admit that it feels sort of funny that I'm quoting RFC1945 since
> Henrik is one of the authors -- therefore I know I'm preaching to
> the choir,
> right?]
>
> So using the POST method definition (3), SOAP would be the block
> of data to
> be submitted to a data handling process, a SOAP processor, which would
> return something appropriate.  The semantics of POST aren't violated by
> SOAP, so again I'm not sure what problem the SOAPAction header solves (or
> the use of the 500 error code for that matter).
>
> And that's really the point, right?  We have endeavored to define XMLP
> independent of HTTP (and other protocols) in our requirements
> document.  We
> presume that a protocol binding allows us to actually ship SOAP/XMLP from
> one point to another, whether that be straight TCP sockets or
> HTTP or SMTP.
> That being the case, why does SOAP/XMLP require information to be surfaced
> into a carrier protocol like HTTP?  Shouldn't we just define the HTTP
> semantics to follow when using SOAP/XMLP rather than defining new error
> codes and new headers?  We could easily state that the URL in an HTTP POST
> defines an endpoint where a SOAP message is expect to land.  The
> response is
> a 200 (message accepted, here's the response), 204 (message accepted, no
> response needed), 401 (message can't be processed), 404 (no SOAP
> processing
> here), 500 (bad SOAP message).  We could argue about 404 v. 500,
> but I think
> you get the point.
>
> I'd augment this with a SOAP/XMLP MIME-type that clearly identifies the
> contents of the POST as a SOAP message.  We might want two MIME-types, one
> for a request and one for a response.  As a result, I'm not sure where the
> SOAPAction header adds value.  In the case of the Frontier implementation,
> the SOAPAction header could be just as easily restated as a URI.  Where do
> you see the SOAPAction header adding value?
>
> 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

Received on Monday, 7 May 2001 17:12:08 UTC