| Sign In/My Account | View Cart |
|
|
What if SOAP had never happened?
Simon St. Laurent URL: http://www.artima.com/weblogs/viewpost.jsp?thread=95113... A new piece by Carlos Perez suggests that SOAP is comatose, and REST (HTTP GET/POST/PUT/DELETE + XML) is waking up. Reading it left me a bit nostalgic, and wondering what might have happened if SOAP had never appeared. Yes, I know counterfactuals are ridiculous, and that the computing culture of the time definitely drove a lot of the decisions that went into making SOAP the [triumphant success | utter debacle] that it is today. Perez suggests that REST may be emerging from the train wreck as a success, but I wonder if it's at least possible to think of a world where SOAP never happened and technologies like REST and BEEP had greater opportunity to flower. From my (admittedly jaundiced, biased, etc.) perspective, SOAP and its ever-growing family of specifications emerged because vendors needed something more concrete than design services to sell their customers, and because the hype wave around XML had promised too much that couldn't be delivered immediately. XML provided one layer of data structure, and the rest was left to users. While XML was very capable, its tremendous openness troubled people used to much more constrained environments. SOAP felt like a way to provide those constraints while still offering much of the openness. SOAP has never been and still isn't necessary as a means of getting XML from one place to another. HTTP exchanges of XML were and are common and growing (even when they don't precisely follow the REST model), and you can even send XML over a socket without further fanfare if the sender and recipient share expectations. For cases where that wasn't sophisticated enough of an approach, BEEP promised an extensible protocol system to match the extensibility of XML. XML-RPC offered much less extensibility, but was perfectly adequate for a lot of simple and even many complex applications. Neither REST, BEEP, nor XML-RPC, of course, came with the corporate imprimatur of Microsoft, IBM, BEA, and more. When the time came for the W3C to address the question, it pursued the familiar tracks pushed by its largest members and many of its newest members, who'd apparently seem the lovely diagrams of magic clouds at XML conferences and decided Web Services would solve their problems. Without SOAP - say, if XML hadn't registered so high on the hype meter, and had a quieter few years to develop best practices - we might have had REST emerge four or five years ago. The parts have been around a long time, and their use isn't that difficult. BEEP might have led developers down different paths, capable of handling the multi-level processing demands of the WS-* family, but doing so in more elegant and perhaps with fewer press releases announcing new competing semi-standards. I know, I know. It's too late for all of this now. REST still has a chance, but BEEP has largely vanished to history. Customers and vendors alike spend time wondering what's going to happen in the WS-* cloud, and that disaster has happened slowly enough that people still seem to stay along for the ride, always hoping that it will finally get better. We might be in a different mire now if things had gone differently, but I can't help thinking the industry would have done better to avoid the SOAP dead end. Simon St. Laurent is an associate book editor at O'Reilly Media, Inc..
Could we be further along than we are today?
You must be logged in to the O'Reilly Network to post a comment. Showing messages 1 through 2 of 2.
Return to weblogs.oreilly.com. Weblog authors are solely responsible for the content and accuracy of their weblogs, including opinions they express, and O'Reilly Media, Inc., disclaims any and all liabililty for that content, its accuracy, and opinions it may contain.
|
|
Sponsored By: |
|||||||||||||
We consider SOAP a failure because we expect such complicated specification processes to output something useful and workable...in our lifetimes.
I have problems with the entire WS stack (the same icky feeling lingers of things like XML Schema, XLink, and various other specs) though they are more about execution rather then the underlying assumptions.
Good ideas tend to crop up again and again over the years, SOA being the latest incarnation of CORBA, etc etc...I have no doubt that something will stick eventually; be it one part SOAP, REST or SOAP-AT-REST....
Ultimately, the SOAP WS* stack IMHO was always intended towards enterprise level development; which in reality there probably are only about 500-1000 or so type projects running worldwide at any one time. To use SOAP on most projects would be analogous to expecting someone blogging or maintaining their own personal website to adhere to ISO type standards process....its not needed.