[
Lists Home |
Date Index |
Thread Index
]
Here is a list of payoffs for using SOAP (in no particular order). Not
all these are technical. Not all are exclusive to SOAP. Not all are a
reality today.
There may be risks that reduce the vale of some of these benefits. This
list is not an attempt to counter the payoffs of REST point by point.
The TAG, along with every interested individual, should evaluate the
tradeoffs very carefully.
It is my opinion that, taken as a *whole*, SOAP has a lot to offer.
* To build the kinds of distributed systems that businesses want (like
the over used supply chain automation example), you need layers above
the protocols used to move the data around. Things like routing,
flexible message level security, evening, etc. SOAP provides a well
defined platform that those layers can be built on.
* SOAP supports RPC *and* SOAP allows developers to move beyond RPC to
asynchronous messaging. In a way, it takes the world as it finds it and
tries to improve it.
* Every SOAP message is XML and only XML. You don't have to worry about
what should be encoded as query string parameters in an URL used with
GET and what should be encoded as XML and used with POST.
* SOAP messages can be moved over the Internet using HTTP, SMTP, FTP,
TCP/IP, etc., and moved around an enterprise using MQ Series, stored in
an (XML) data base, written to a file, etc., all without loosing ANY of
the semantics of the message. The message is the ONLY thing that counts.
* SOAP has lots of support from tool vendors. Not every programmer has
the time and/or ability to design and build a decent distributed system,
even using just HTTP GET, PUT and POST. Without a well defined platform
(SOAP), lots of documentation, books and sample code, and lots of
abstractions and simplifications handled by the tools they use, they
will simply build bad distributed systems.
* There are active communities built up around making SOAP, *and* the
layers built on top of it, interoperable. This is very important to the
corporations who want to buy systems that work out of the box. It is
also very important to corporations who want to easily and quickly build
applications that fit seamlessly into distributed systems deployed by
entities that they do not control (industry consortiums, business
partners, acquisitions). The key here is that the more abstract layers
above the transport protocols will also tend to interoperate without
extreme effort.
* WSDL. Sure it can be used to describe protocols other then SOAP, but
it was invented to support SOAP. It is the soul of SOAP. The SOAP
community has driven it forward with many interoperable implementations.
* SOAP blends an application structure focus (like DCOM and CORBA) and a
document/data focus (like the web). I think something much greater then
either one alone emerges as a result.
== Mike ==
This posting is provided "AS IS" with no warranties, and confers no
rights.
-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Can you provide a list of the payoffs for using SOAP?
Someone earlier brought up the VHS vs BETAMAX story
often used to illustrate how an inferior technology
can lead to market lock-in. I assume this fear of
lock-in by the major vendors is one reason some fear
SOAP, that SOAP and particularly, SOAP/RPC are the
inferior technology. In the article referenced here
http://www.utdallas.edu/~liebowit/paths.html
the author argues that a detailed study of the actual
history of the home recorder market reveals that this
is an urban legend of sorts promoted in the literature.
VHS had initially a technical advantage that for an
extent of market time gave it an increasing returns advantage:
a two hour, then quickly four hour, recording time.
All other aspects were roughly equal.
Roy Fielding argues for "unforeseen advantages" to
the REST architecture. If one asserts that one
should choose based on what one knows and not
imperfect information ("unforeseen"), then one
has to look at the payoffs to see if there is
indeed a market requirement that would lead to
one of these architectures being superior, that
is, realistically leads to "foreseen" payoffs.
Is it simply that "all that matters is XML" is the
source of the payoffs. Doesn't REST also use XML?
It may be that the programming model (procedural
invocation of remote procedures) is given
resistance to learning a new paradigm. So
far, the REST architecture would appear to be
superior based on the reliability of the components
for processing URIs, safe operations, scaling
of simple methods over the confusion of every
programmer rolling their own and each having
to learn essentially, a new API for every service.
What are the payoffs for using SOAP?
len
-----Original Message-----
From: Mike Deem [mailto:mikedeem@microsoft.com]
I'll stop lurking and make a technical point in favor of SOAP. Yes, I
have read the e-mail threads and the referenced articles. :-) I'm one of
the program managers at Microsoft that delivered the Microsoft SOAP
Toolkit.
My technical argument is this: all that matters when using SOAP is XML
and all the power of XML can be leveraged when building applications
that use SOAP.
I can use the same programming model for doing simple "safe" things as I
do for doing complex "unsafe" things. That programming model allows me
to leverage Schema, XSLT, XQuery, XPath, etc.
Granted, this may not be what SOAP tends to be *today*. But SOAP, at
least, enables us get there someday.
|
