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?
soft soap
Interesting speculation. I remember turning some people off when I harshed SOAP on these forums several years ago. Sigh.
Interim techniques are a necessary evil. They are a way to get things started in the real world. The first web servers seemed to need server-side includes. Java needed AWT to get off the ground. XML needed specs to get people working with it, and web services would've had a greater initial barrier to entry without SOAP. The S was for simple, after all.
What bothered me about SOAP specifically was that it appeared to be a shortcut to thinking. It was thin wrapper compatibility, with no value-add and minimal appreciation for the true power of XML. Its popularity seemed to come exclusively from vendor backing. I'm not particularly bigoted towards multi-vendor standards, but to have such an inane one pushed out by brute force was insulting to the profession.
I've had the luxury of being choosey about what I tinker with, and my general approach to XML has been to focus on the basics and let the standards settle down over the span of years. Maturity tastes so much better.
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.
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.