What if SOAP had never happened?
by Simon St. Laurent
Related link: 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.
Could we be further along than we are today?
Interesting speculation. I remember turning some people off when I harshed SOAP on these forums several years ago. Sigh.
SOAP is enterprise
its sods law that some things stick over other things....SOAP and its associated standards should be considered a body of research, underpinning and demonstrating what is will take to turn the web into the foundation for services orientated architecture; instead of a set of accepted specifications with a capital S.