W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: What is SOAP?

From: Mark Baker <distobj@acm.org>
Date: Tue, 26 Mar 2002 22:32:19 -0500 (EST)
Message-Id: <200203270332.WAA21097@markbaker.ca>
To: jacek@systinet.com (Jacek Kopecky)
Cc: xml-dist-app@w3.org, skw@hplb.hpl.hp.com (Stuart Williams), noah_mendelsohn@us.ibm.com (Noah Mendelsohn)
>  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),

Hmm, well, I don't see how that follows.  An underlying protocol with
its own notion of response should be able to transfer a SOAP envelope
while still returning what it knows to be a response, no?

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

Sure, that's the tunnel view.  The chameleon view of our default binding
is that POST semantics are used.

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

There is a way.  We've done it already.

See http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#IDALNXZ

"The SOAP HTTP Binding ( see 7 SOAP HTTP Binding ) can be considered as
an extension of the HTTP application protocol."

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

Yes you could!  If SOAP is sucessful in the long run, I see it looking
exactly like this.  HTTP headers would migrate to be SOAP headers over
time, and you'd be left with HTTP Request-Line and a SOAP envelope.

(hopefully my previous suggestion for a GET binding should make more
sense given that as context)

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

Right.  Using SOAP with our default binding in a chameleon way means
only using SOAP for things that you'd normally use POST for.  If you
wanted to do GET, PUT, or DELETE, you'd have to use them the way you
normally do.

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

SOAP is not an application protocol though, and the application
semantics have to come from someplace.  In the example I mentioned,
the SOAP envelope included the application semantic "Add", and I
showed how to do the same thing by using POST.

Henrik talked about how SOAP can't "perform tasks" on www-tag;


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

Ack.  Get some sleep!

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Tuesday, 26 March 2002 22:27:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC