SOAP Stack an Embarrassing Failure?

by Han Xu on Aug 16, 2008 |
The debate over REST vs. SOAP is really an age-old one. However it fired up again over a recent remark by Tim Bray, the XML guru in Sun technologies. Tim said in an interview at OSCON that,

The SOAP stack is generally regarded as an embarrassing failure these days ... REST does what [the SOAP stack] was trying to do in a much more viable, elegant, cheap, affordable way except that we've got no tooling around it yet.

As before, proponents on both sides spoke up to support their favorite styles. The debate has formed a long thread with over 150 replies on the Service-Oriented-Architecture Yahoo! Group, where Nick Gall gives one example of a large enterprise that moved away from SOAP:
Wal-Mart replaced its supply chain's VAN EDI infrastructure several years ago with EDIINT AS2 and is still happily using it to this day. AS2 is basically POX, with its own approach to idempotence for reliable message delivery.
I've been predicting SOAP would never see widespread use outside the firewall.
And when talking about what can be considered a successful example of using SOAP, Nick points out:
What I am really seeking are large enterprises that are truly leveraging the power of SOAP in ways that provide convincing evidence that SOAP "works for the job" in ways that other approaches would struggle. IME very few enterprises really need SOAP for what they are doing -- it was put either put in by consultants as a checklist item, or the tool used SOAP by default. The majority of SOAP use appears to be simply driven by inertia, not any belief in its superiority in doing the job.
But Eric Newcomer frowns on Nick's example:
You have given us an example of a customer using REST for B2B - as an EDI replacement.  EDI is document-oriented, as is REST, so this is not a big surprise.

We know of many examples of large enterprises using REST that designed and created their data centers based on the Web, since they are basically Web oriented businesses.  But I do not know of any examples where an enterprise whose data center predates the Web has adopted REST.
Me - I am a "right tool for the job" person, and I cannot believe that everyone will be better off using REST any more than I can believe everyone will be better off using Web services
Besides, Steve Jones doesn't agree with the view that SOAP is not adopted due to its complexity, he notes:
I never get the complexity thing, REST isn't simple its got some very "nice" bits in it that are far from simple and its got some tough challenges (security for example) that aren't addressed.  SOAP isn't complex, the complaint people make about it is that it is too easy and hides the network.  So not doing SOAP might have many reasons but it can't be both complex and too easy.
Obviously this will be another endless debate over the REST vs. WS-*/SOAP issue, although David Chappell claimed "the REST vs. WS-* war is over". People have been expecting a real end to the long debate, but it will not be a "crushing victory for one side". As John Evdemon says,
One size doesn't fit all - use what best meets your customer's needs and be done with it.
Gervas Douglas proposes a stack comparison between REST and SOAP to remove the significant mismatch of comprehension between the two camps. But there are different opinions regarding the selection of the reference model. While Steve suggests taking the SOA RM as the basis for a SOA stack and then mapping REST/SOAP onto a single model, Mark recommends using OSI. Anyway, Gervas has created a wiki entry for this stack comparison purpose, let us wait and see what will be happening there.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Tim Bray is the father of XML by Michael Neale

But sometimes you can't control what your kids do, but in some sense you are responsible ;)

XML made sense at the time, HTML was such an amazing success for authoring sites and apps (to some extend) to making the tags generic and extensible must have seemed like a great idea.

Yet I would have thought people may have known better: HTML was explicitly used by humans for authoring, yet XML was always proposed as something that could be used for many purposes, yet only one of them (human editing by very very basic text editors) was just one. And the "self describing" thing is bogus as well: lots of non verbose markup can support that without the tag names repeated.

I guess the question is would WS-* standards have evolved if it wasn't XML but was something else, or is SOAP just adding more heavyness over something that was already heavy?

Re: Tim Bray is the father of XML by Stefan Tilkov

I think it's fair to say that XML is a sound success – there's a rich ecosystem of tools and technologies around it, such as XSLT, XPath, XQuery; lots of libraries and standard APIs; lots of formats built on it … 

I agree that XML isn't a good choice for everything, but I don't see anything that's better in the general case (even though XML has its warts, such as the f*d up namespaces and the useless difference between attributes and elements).

Re: Tim Bray is the father of XML by Bill Burke

I guess the question is would WS-* standards have evolved if it wasn't XML but was something else, or is SOAP just adding more heavyness over something that was already heavy?

The already had....CORBA.

easy vs. simple by Martin Probst

People keep messing up "easy" and "simple". REST is simple, and results in comprehensible, analyzable systems. SOAP tends to be easy, but the resulting systems are highly complex (in particular with all the WS-* stuff), and thus expensive to use, maintain, and debug.

Axis 2 by Pavel Tcholakov

Speaking of SOAP and embarrassing failures, I've been banging my head against the wall that is Axis 2 and I've given up. Why are they trying to reinvent the wheel by building an app server inside the app server? Why are there a million dependencies? Why... no wonder people are moving to POX - it's simply to preserve their sanity.

I really like Spring Web Services for proper contract-first development but I also need to support wsdl2java-style code generation in order to rebuild some old RPC services. Any suggestions for alternative toolkits?

XML vs jSON by Himanshu Bafna

Did anybody try using JSON with REST?

SOAP quite successful within the enterprise - it will expand to B2B in time by Faisal Waris

Wal-Mart adopted AS2 because WS* was not ready for B2B at that time. There is nothing simple about AS2 either. Wal-Mart achieved interoperability by naming a commercial vendor for AS2 stack certification and required all partners to use compliant AS2 stacks. Wal-Mart is big enough to make that happen.

This is all well and good and kudos to Wal-Mart for making it work for them but...

With WS-I Reliable Secure Profile (RSP), SOAP is just about ready to tackle B2B. It is only natural that companies would want to use a similar model for B2B communication as they already do for internal communicaton, i.e. WS*.

I am quite sure that if we did not have SOAP, someone would have invented a SOAP-like thing anyway - i.e. some structure over POX (e.g. RosettaNet, OAGIS). There is a need that SOAP fills. SOAP is not a failure by a long shot within the enterprise.

So say we build the REST tooling that Tim Bray speaks of. Perhaps then we define some metadata to drive the tooling. But wait... is that not what we did with WS*?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.