Re: What is SOAP?

 Mark,
 I believe that (a) is not a special case of (c) because:

 1) SOAP as a messaging protocol is one-way, therefore HTTP
response again transfers just a one-way message, in which case it
should always be 200 OK (even for faults),
 2) "sending a message to a SOAP Node identified by a URI"  
contains nothing indicating what HTTP method should be used, 
in other words SOAP as a messaging protocol means that semantics 
are defined by the SOAP message and the endpoint application.

 If we want SOAP to be transport independent, it must be layered 
above HTTP. If we want HTTP methods to affect SOAP, they must be 
layered above or equally to SOAP. No way to consolidate.

 It seems that SOAP is on the same level as MIME, for example,
(or RFC 822, whichever is used for HTTP after the leading method
line), so you could probably have HTTP/SOAP (HTTP with SOAP data
instead of MIME/822 data), but not SOAP non-tunneled over HTTP.

 I understand that you can use SOAP as a data encapsulation
format, but how does this play with idempotent request/response
queries? (HTTP says GET, SOAP says Envelope, AFAIK you can't have
a GET with a request body - for the good reason of
addressability.)

 Oh, and an HTTP application using SOAP as its data format is 
just that, it's not a SOAP application with an HTTP binding. This 
application uses SOAP *without* any transport binding because 
it's the application and not SOAP who defines the transport.

 (Hope I'm clear, it's almost 4am here. 8-) )

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 26 Mar 2002, Mark Baker wrote:

 > Hey Jacek,
 > 
 > >  a) an extension of the web (or HTTP), or
 > >  b) an RPC request/response protocol on top of *a transport 
 > > layer*, or
 > >  c) simply a messaging protocol with basically every message
 > > being one-way (again, on top of a transport layer).
 > > 
 > >  I think the original Abstract Model [1] assumed (c), I think
 > > that many of our audience still (unfortunately) assume (b), and I
 > > think Mark Baker assumes (a) (at least I haven't noticed another
 > > strong proponent of (a)). I believe that the majority expectation
 > > is also (c).
 > 
 > I believe SOAP is c), but that a) is a special case of c) where
 > the meaning of the message transfer is inherited from HTTP (just to
 > compare apples-to-apples with your a).
 > 
 > [snip]
 > 
 > >  AFAIK, the history of SOAP is the transition from (b) to (c).  
 > > I don't think there is a possible transition from (c) to (a)
 > > other than starting from scratch. And I don't think (a) and (c)  
 > > can be combined simply and nicely.
 > 
 > IMO, there is definitely a transition.  The chameleon view is about
 > making this transition, but assigning meaning to the sending of a SOAP
 > message, where that meaning comes from the method used in the underlying
 > protocol.  In fact, c) by itself is insufficient with which to get any
 > work done, because no meaning has yet been assigned to the sending of
 > the SOAP message.  What most people currently do is put the meaning
 > within the envelope, such as is done here (not to pick on Gudge, but
 > this is a simple and illustrative example);
 > 
 > http://www.xml.com/pub/a/2002/02/20/endpoints.html
 > 
 > The example I had in mind is this one;
 > 
 > <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
 >   <soap:Body>
 >     <pre:Add xmlns:pre="http://example.org/lists"
 >      soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" >
 >       <person>
 >         <name>Hayley</name>
 >         <age>30</age>
 >       </person>
 >     </pre:Add>
 >   </soap:Body>
 > </soap:Envelope>
 > 
 > Here, we see the meaning of the message "Add" in the message itself.
 > A chameleon version of this with SOAP/HTTP would be;
 > 
 > <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
 >   <soap:Body>
 >       <person>
 >         <name>Hayley</name>
 >         <age>30</age>
 >       </person>
 >   </soap:Body>
 > </soap:Envelope>
 > 
 > What happened to "Add" and the URI?  Well, HTTP POST roughly means
 > "Add", and the URI, "http://example.org/lists" is what you POST to.
 > 
 > Any clearer?
 > 
 > MB
 >

Received on Tuesday, 26 March 2002 21:47:54 UTC