W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2004

RE: non-outcry over eBay SOAP interace

From: Newcomer, Eric <Eric.Newcomer@iona.com>
Date: Sat, 14 Feb 2004 09:05:08 -0500
Message-ID: <009AD9C866C5DE458E7EF528604A9F9C0A43D0@amereast-ems2.boston.amer.iona.com>
To: "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>, "He, Hao" <Hao.He@thomson.com.au>, "Michael Champion" <mc@xegesis.org>, "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
Cc: <www-ws-arch@w3.org>

In the early days, when SOAP first came out, Henryk Neilsen always described it as an "extension to HTTP."

if you look at the HTTP spec, you can see that it was designed to be extended, even for things such as custom interfaces, and SOAP is in practice what the industry has settled upon as that extension.  When SOAP came out there were many, many other proposals for XML protocols, that's why the W3C WG is called XML P, not SOAP.  When the WG started the first item of business was to develop requirements against which to evaluate all the candidate XMLPs.  Some of them are listed here:


This debate reminds me a lot of the synch/asynch debate.  Once RPC was invented and became widely adopted, why would anyone want to struggle with all the additional programming overhead and complex error recovery inherent in asyhcnronous communications protocols?  And for transaction processing, why incur the overhead of three distinct transactions in order to guarantee atomicity when with synchronous protocols you could use just one?

At the X/Open (now Open Group) TP committee, best known for producing XA, the messaging guys used to argue that asynchronous messaging was the only thing you needed for the Internet.  And they had a lot of good reasons, too, such as eliminating the overhead of sessions necessary for synchronous protocols and the relative ease of bridging disparate systems (both architecturally and over time and space).

In the end I decided we were both right, and that the world is divided up in some proportion between synchronous and asynchronous communications, because some application requirements are better served by one or the other.

It's also a lot like the CORBA/Web services debate.  Lots of folks get lost in the details of technology comparisons and easily conclude that CORBA is superior.  But for what purpose?  Often in these discussions the human factor, what people want to do with the technology, is omitted and the debates become endless.

Here I think most folks have sensibly come to the conclusion that the world is big enough for both SOAP and "REST" - depending, of course, on what you want to do.  This was Amazon.com's view, which you can hear on IT Conversations:


Some applications are better served using the plain XML over HTTP; others by using the SOAP extensions.

I realize that software remains a very personal thing.  The industry is not yet standardized the way other industries are.  There's no one way of doing anything.  So of course we are going to get individuals with strong opinions, who have worked their own way through the various technologies and settled upon what they think is best.  Unfortunately, the arguments among such individuals can never be won, since by definition they are personal views and inherently differ.

For whatever it's worth ;-)


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Thompson, Bryan B.
Sent: Friday, February 13, 2004 6:38 AM
To: He, Hao; 'Michael Champion'; Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: RE: non-outcry over eBay SOAP interace

See: http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0056.html

in which Mark Baker argues in favor of SOAP for: "We *need* mandatory 
extensions, header targetting, and a better documented end-to-end model.
Right now, SOAP is the only _deployed_ means of getting all that."

However, this is in no small measure to the abortive attempt at HTTP-NG,
which did not gain a sufficient audience at the IETF.  He also recently
pointed me to a W3C Note that provides an extension mechansim for HTTP.

and ftp://ftp.isi.edu/in-notes/rfc2774.txt, which seems to be the most
current draft (RFC 2774).

In sort, we can do these things within HTTP, and the existing web, if we
build the right contracts into the protocol or into protocol extensions.
Not everyone interested in REST wants to use HTTP, but some of us are
looking to extend the current web architecture, so that means HTTP +
requirements such as those that Mark (and others) have outlined and 
agreements on how those requirements will be fulfilled.


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of He, Hao
Sent: Thursday, February 12, 2004 4:17 PM
To: 'Michael Champion'; Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: RE: non-outcry over eBay SOAP interace


Any idea why you "need the encapsulation of SOAP when performing operations
with a high level of contractual commitment."? I cannot see the correlation


-----Original Message-----
From: Michael Champion [mailto:mc@xegesis.org]
Sent: Friday, 13 February 2004 8:08
To: Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: Re: non-outcry over eBay SOAP interace

On Feb 12, 2004, at 4:01 PM, Cutler, Roger (RogerCutler) wrote:

> If you dig into the links a bit you find the following, which I like:
> So there you have it in a nutshell. The XML-over-HTTP openness of REST 
> works best when you want to reach as wide a universe as possible. On 
> the other hand, you're going to need the encapsulation of SOAP when
> performing operations with a high level of contractual commitment. Most
> applications will need to use some of each.
I like that too.. where was it?
Received on Saturday, 14 February 2004 09:05:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC