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

RE: non-outcry over eBay SOAP interace

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Sat, 14 Feb 2004 12:00:04 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E026F02CD@bocnte2k3.boc.chevrontexaco.net>
To: "Newcomer, Eric" <Eric.Newcomer@iona.com>, "Thompson, Bryan B." <BRYAN.B.THOMPSON@saic.com>, "He, Hao" <Hao.He@thomson.com.au>, "Michael Champion" <mc@xegesis.org>
Cc: www-ws-arch@w3.org

Wow!  That was great, Eric.

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: Saturday, February 14, 2004 8:05 AM
To: Thompson, Bryan B.; He, Hao; Michael Champion; Cutler, Roger
Cc: www-ws-arch@w3.org
Subject: RE: non-outcry over eBay SOAP interace

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 here?


-----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.
> applications will need to use some of each.
I like that too.. where was it?
Received on Saturday, 14 February 2004 13:00:24 UTC

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