>  -----Original Message-----
>  From: Paul Prescod [mailto:paul@[...].net]
>  Sent: Sunday, April 21, 2002 6:47 PM
>  To: Mike Champion; xml-dev@[...].org
>  Subject: Re: [xml-dev] What does SOAP really add?
>  
>  Mike Champion wrote:
>  >
>  >...
>  >
>  > 1 - The obvious analogy is an envelope for snail mail.  It keeps a
bunch
>  of stuff in a
>  > coherent package, it has an address and return address, and and
provides
>  some high-level
>  > description of the contents.
>  
>  SOAP does not, AFAIK, does not have a well-defined, interoperable
>  concept of either forward address nor a return address. The forward
>  address is expressed in the HTTP header.

WS-Routing (formerly SOAP Routing Protocol) proposes adding exactly this
information to the soap envelope. Check out
http://msdn.microsoft.com/ws/2001/10/Routing/ .

>  But how does SOAP:
>   * express the forward address
>   * express the return address
>   * express the size of the envelope
>   * help with routing
>   * help with sorting
>   * do authenticatoin/authorization
>   * do charging
>   * do encryption

Many of these can be expressed using well-known SOAP headers. Check out
WS-Security (http://msdn.microsoft.com/ws/2002/04/Security/) for
encryption and message integrity. I (and others) believe this approach
can be used to address other areas of functionality as well.


 
>  I'll buy this part of your argument when you convince me it does
>  *something in particular* in a standard way. The only thing I've seen
>  that it does reliably and interoperably is RPC over HTTP.

The RPC argument is a total red herring. For one, providing a
reliable/interoperable RPC mechanism is a huge benefit over thousands of
ad hoc solutions. Secondly, the "uniform vs. application-defined"
interface/protocol debate has been beaten to death in other threads.
 
>  Futhermore, SOAP anticipates the need to route but I don't see
anything
>  in it that specifies an interoperable way to do routing. Do you feel
>  that a SOAP message could be interoperably routed from HTTP to JMS to
>  SMTP to HTTP using only features of the SOAP specification?

1) We (at least those of us at MSFT or DM) believed that it was better
to build a solid and extensible foundation to build upon rather than
attempt to boil the ocean and submit a huge pill for the world to
swallow in one gulp.

2) I believe JMS is an API and not a wire protocol, so that scenario
doesn't make a lot of sense.

>  Do you really think it is possible for a protocol to be entirely and
>  truly transport, topology and message-architecture neutral? A
"protocol"
>  that doesn't care how it is transmitted, whether it will return a
result
>  etc. sounds more like a "file format" than a protocol to me. i.e. MIME
>  expressed in XML.

To large measure, I agree with you. SOAP primarily defines a message
format. What distinguishes SOAP from arbitrary MIME types is that SOAP
implies a particular processing model (with respect to headers) and
defines a family of well-known fault formats. 

One could make an argument that the "protocol" aspect of SOAP is pushed
up a layer to things like WSDL, WSFL, XLANG, etc. 

FWIW, I believe that this last point is exactly what drives you, Mark,
and Roy nuts about SOAP, in that every developer gets to define his own
semantics, making it hard for today's HTTP infrastructure to make blind
assumptions about what it can or cannot do with an arbitrary message.

DB


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>