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

Dick --

> 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.

I'd agree that text/xml would be really hard to distinguish SOAP messages
from others without processing the XML directly.  I'd be more in favor of a
text/xml-soap or application/xml-protocol or something like that to clearly
identify the kind of XML involved.  It's not a perfect solution, but it
solves the "signal" problem without having to resort to another header.
Another thought might be to use something like:

	Content-Type: text/xml; format=xml-protocol

This would have the same signal effect as SOAPAction, but without the extra
header value.  

> 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.

The concern I have is that the SOAPAction header semantics are unclear for a
given XMLP transaction.  There shouldn't need to be any additional routing
information outside the basic HTTP stream since HTTP is pretty much complete
from a point to point routing perspective.  Everything else should be in the
envelope.  URIs should be complete enough for message broker dispatching --
URIs are supposed to identify unique resources, so message brokers shouldn't
be multiplexing or overloading URIs.  Even so, with a Content-Type mechanism
specified above, a message broker should work just fine without a new HTTP
header.

My basic issue with SOAPAction is that it seems to bleed information out of
the XMLP envelope into carrier protocols.  I don't believe that we would
alter the structure of TCP packets is we used a socket to carry XMLP and
similarly it seems to me that HTTP is complete enough to transport XMLP
without additional semantic requirements.

Just my humble opinion ...

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 18:15:05 UTC