[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP and the Web
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@i...] 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@m...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|