[
Lists Home |
Date Index |
Thread Index
]
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.
|
