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

Jeff wrote:

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

This is how the original ebXML spec was written. The multipart/related
media type has a "type" parameter that contains the MIME media type of the
root
body part, which in ebXML's case contained the ebXML header document with
a "Content-type: application/eb+xml". When a message broker received a
message containing
"Content-type: multipart/related; type=application/eb+xml" it dispatched
processing to
an ebXML aware handler. When ebXML incorporated SOAP we had to follow
the rules in SOAP/1.1, which defines the content-type of a SOAP message as
"text/xml".
There is no way for a message broker to distinguish an ebXML message from
any other
SOAP message, using the Content-type, given this requirement. This is where
SOAPAction
fills-in the "missing" data needed by the message broker in order to
dispatch
processing to an ebXML aware handler.

>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

This is where WSDL fits in. If we can assume that SOAP services will be
defined
using WSDL then SOAPAction semantics are perfectly clear. The WSDL
file that was created by the service implementer "tells" the "caller" the
value to use for SOAPAction within the soapAction attribute of the
binding section of the WSDL file. A client simply sets the SOAPAction based
on
the WSDL defined value whenever the service is called.


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

I agree, however that's not possible without changing the SOAP spec to allow
implementers to specify their own Content-types. All SOAP messages carried
via
HTTP are Content-type: text/xml according to section 6 of the SOAP spec,
which
states:

"HTTP applications MUST use the media type "text/xml" according to RFC
2376 [3] when including SOAP entity bodies in HTTP messages."

Dick Brooks (ebXML liaison)
http://www.8760.com/

Received on Tuesday, 8 May 2001 09:15:14 UTC