The Artima Developer Community
Sponsored Link

Weblogs Forum
SOAP is Comatose But Not Officially Dead!

5 replies on 1 page. Most recent reply: Oct 11, 2012 5:53 AM by Phillip Coppney

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

SOAP is Comatose But Not Officially Dead! (View in Weblogs)
Posted: Feb 19, 2005 2:14 PM
Reply to this message Reply
Summary
SOAP is comatose, but hasn't declared legally dead by either IBM or Microsoft. But how did this all happen? Isn't SOAP the underpinnings of Web Services, the same technology that was billed as the silver bullet to extinguish our collective integration nightmare? Well the time of reckoning has now arrived.
Advertisement

SOAP is comatose, but hasn't declared legally dead by either IBM or Microsoft. But how did this all happen? Isn't SOAP the underpinnings of Web Services, the same technology that was billed as the silver bullet to extinguish our collective integration nightmare? Well the time of reckoning has now arrived.

The arguments for and against Web Services have been raging on since the pinnacle and eventual bursting of the Internet bubble. My first blog entry on the subject of SOAP's fundamental weakness in support of interoperability was back in 2002. Back then it was already clear that SOAP was built on tight coupling and to make progress one need to make some design choices away from the familiar. In mid 2003, it was becoming quite apparent that the Web Standards bodies were repeating the same mistakes as the CORBA standardization that came before it. Finally, by the middle of 2004, the trade press finally saw the train wreck coming.

Today, half a year since my prediction of the rise of REST and the fall of SOAP, denial has been now replaced with panic. The RESTful approach has now born fruit. Applications like BlogLines, Flickr, Mappr, Del.icio.us and 43Things are revealing that proof is in the pudding. All of these have shunned SOAP in favor of more RESTful designs. In stark contrast, the SOAP high priests have nothing to show but fancy visual tools. Their followers are at the brink of rebellion and if they don't act quickly they could find themselves swinging from a high treetop.

To witness the SOAP panic, here's a sampling from the blogsphere:

James Govenor writes in "SOAP is boring, wake up Big Vendors or get niched:

Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. It is often described as "lightweight", but its RPC roots keep showing.

Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls.

What is a web service? That’s still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and "consumer" are breaking down. REST is evidently where that convergence is being played out, not WS-I.

Stephen O'Grady writes:

Case in point is what longer term readers will recognize as one of the windmills I tilt at regularly, simple, RESTian web services. I have yet to hear any vendor - not one - talk to me about how they help developers design, implement and consume RESTian web services.

In yet another blog entry about a project for Creative Commons webservice:

At the time, we planned to develop both SOAP and REST implementations, but left the SOAP implementation incomplete due to time constraints. It’s been on my list to finish “real soon now” ever since.

The one developer who asked me about the SOAP version was a Java developer who wanted to use the WSDL definition to make life easier. That I can sympathize with. But the fact of the matter is that I don’t currently have the bandwidth to finish and maintain two separate implementations.

Over the weekend Mike pointed me to an interview with Stewart Butterfield, CEO of Flickr. In it he describes a similar phenomenon to what we’ve observed (although on a much larger scale): far more interest in REST than SOAP.

Stuart Butterfield on Flickr:

On the strictly practical side, I think we had one person inquire about using the SOAP version of the API. I don't know if any apps were actually built. There is at least one application built on XML-RPC. But all the others--I don't even know how many there are--are built on the REST API. It's just so easy to develop that way; I think it's foolish to do anything else.

Mike Champion of course is prepared to defend the faith. Where he writes:

Users of browser-based applications come to expect the quality of service one associates with the Web. Web services toolkits such as Indigo on the other hand, are oriented toward use cases that demand high-security, support for existing enterprise messaging systems, message failure is not an option, and industrial-strength transaction processing is assumed. The REST approach (as far as I can tell after years of discussion) assumes that all these features are provided at the application level rather than being provided by the infrastructure. I am convinced that developers with demanding requirements for security, reliability, transactions, etc. Generally DO want what WS-* and Indigo promise.

What Mike seems to be saying is that REST is the Yugo and if you want the features then you have to buy a Rolls Royce. It's a sales pitch used all too commonly. Unfortunately, if I wanted a Rolls Royce I would have purchased a JMS implementation, not a Web Services implementation with a yet to be defined solution for security. It appears that Web Services are stuck between a rock and a hard place (see de hOra's rebuttal). Fortunately, history does tend to repeat itself and gives us insight on this. See Tim Bray's 80/20 point and Clay Shirky's "In Praise of Evolvable Systems" for reference.

However, let's go beyond this name-calling and look at the crux of the matter. The primary rationale behind Web Services is to support interoperability. So, let's examine SOAP today to discover if it is superior to REST in supporting the primary requirement.

Simon Guest of Microsoft (masters of interoperability) has a very revealing video (unfortunately only available using IE) about the gothchas in Web Service interoperability. He enumerates 10 tips of Web Services Interoperability:

  • Avoid returning empty Arrays.
  • Services that share datatypes should be handled with care.
  • Do not test for Null, rather check if the a returned object is Nil instead.
  • Avoid null Dates. In .NET dates are a value type, in Java they are reference types
  • Don't make exact Date comparisons.
  • Always use a Trace tool.
  • Learn how to change the URL and ports.
  • Unit test.
  • Use doc/literal.
  • Always start from the XML Schema Definition.

Now take away the tips that apply to just about any software development activity (i.e debugging and unit testing) and you end up with some telling flaws in the Web Services specification.

  • The first flaw is that you should not violate Postel's Law. That is "Be liberal in what you accept and conservative in what you send". Returning empty arrays, sharing datatypes, returning null dates should never break a clients view of the world. If the spec were rigid enough returning any of these objects should never lead to a misinterpretation in the client side.
  • Always hide implementation. This should be pretty obvious, however most these gotchas point to the problem of implementation leaking through the abstractions. Why should the fact that two services that share the same datatype affect how its handled in the client? Why should client care if the server handles dates as reference types or not? Why isn't a return of a Null date abstracted away from a client?
  • XML Documents are not the same as Objects. Simon St. Laurent says this best when he said "a schema language that describes document structures, not type structures abstracted on top of document structures."
  • Finally, what's the complication with switching URLs and ports? The RESTful way is entirely obvious, while in SOAP the machinery usually requires digging deep inside WSDL to get access.

Of course, the last 2 tips are the most revealing of all. If everything is sent over the wire as a XML document that is described by an XSD then it all boils down to how easy you can work with these documents. That is working with XML api's like DOM and XPath. The enclosing envelope should be irrelevant to the concerns of the average developer; it should be treated like just any other transport protocol. All that extra machinery provided to support the SOAP envelope is precisely that, extra machinery and has never been shown to improve interoperability. Therefore, in terms of effort, interoperability via SOAP is not any easier than doing it in REST. In fact, its actually more insidious because a developer is all too easily lulled in the fallacy that an object is the same as the XML document.

So here I'm going to reiterate again that SOAP is brain dead. I sincerely hope not to write similar piece years from now when the conclusion would be entirely obvious.


Maarten Hazewinkel

Posts: 32
Nickname: terkans
Registered: Jan, 2005

Re: SOAP is Comatose But Not Officially Dead! Posted: Feb 21, 2005 2:01 AM
Reply to this message Reply
Dead on.

I recall the first web service I put together, about 2 years ago. It did use soap, but getting all the parameter types straight was such a bother that I just built a service that took a single string and returned the same.

Each string was actually an XML document containing several fields. Writing a couple of XML en/decoders was easier than finding the right set of custom screwdrivers to screw all the soapy bolts into the wall the right (or left) way.

Looking at the more recent WS specs, I usually don't even understand what they're trying to specify/solve, and I sincerely hope I can avoid having to dive into that swamp of paper.

Why does everyone want to build a nuclear reactor, just to power a pocket calculator. My calculator runs on a couple of built-in solar cells, and has been running fine for about 20 years.

I guess some people are just in love with complexity and would rather spend 5 years on a complex failure than 2 months on a simple success.

'Anybody could have built something that simple.'

'So why didn't you?'

Andy Yang

Posts: 1
Nickname: ayang
Registered: Feb, 2005

Re: SOAP is Comatose But Not Officially Dead! Posted: Feb 22, 2005 11:59 AM
Reply to this message Reply
IMHO, when people talk about web services, there's usually a disconnect based on whether they're referring to fine-grained vs. coarse-grained services.

For fine-grained a la XML-RPC, then REST seems to make a lot of sense. SOAP does seem like overkill in this situation.

I believe WS-I: Basic however, states that it applies to "Document"-based services - coarse-grained - where you pass around big gobs of XML. A lot of the time, this isn't the case (I just want the current stock price of a single ticker symbol) but maybe you really do need that much data (my service does big, crunchy calculations on every transaction performed over a month for a stock).

My admittedly sketchy understanding of REST seems to be that you tend to ship a few pieces of data, with links to additional pieces of data, permitting "drill-down" as needed.

So you end up deciding whether you want few round-trips but big data payloads vs. many round-trips and smaller data payloads - whatever your needs dictate.

As to the merits of SOAP as a specification - it's really just an envelope and a payload isn't it? What you stick into the envelope/header depends on how sophisticated your security and routing needs are.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

Re: SOAP is Comatose But Not Officially Dead! Posted: Feb 23, 2005 3:15 AM
Reply to this message Reply
I think you make an important mistake in your analysis. You mix up the inevitable problems connected to XML language bindings with the question of SOAP-header based infrastructures.

I agree that the infrastructures that would justify the additional effort of SOAP headers and WSDL are not yet fully in place. But I'm convinced that they are necessary, if XML messaging is ever to grow beyond the super simple examples that you cite as REST success stories. Think seamless supply chain automation.

Language binding problems like value/reference types, date formats, nulls, collections, etc, will not completely go away as long as you do language binding at all. This has nothing to do with SOAP vs REST. Sure, you could argue that SOAP's original emphasis on RPC made this problem worse whereas REST's emphasis on XML messaging was the better approach. I agree. But this is a thing of the past since both camps seem to converge on message formats that can be treated as XML messages as well as bound to programming languages. It's a matter of choice, not a technical difference between the two concepts.

WSDL/SOAP may be a little harder to get up and running, but if you need transparent infrasture services like security, transactions, correlation, etc, SOAP headers with broadly agreed semantics can be a huge benefit. Let's wait and see.

Jonathan Anderson

Posts: 1
Nickname: joninva
Registered: Mar, 2005

Re: SOAP is Comatose But Not Officially Dead! Posted: Mar 4, 2005 12:16 PM
Reply to this message Reply
So REST adopters achieve succes early. Good for them and their dynamic Web GUIs.

SOAP adopters, in my experience, don't have such simple use cases. They're trying to solve much higher order integration problems. Yes, they're SOA musings are abstract and fuzzy... but that's because the problems are inherently abstract and fuzzy.

Problem statements tend to sound something like: "All of these systems need to be exchanging data in order to work together."

Well, that's never been done before with any technology, though it's been tried. SOAP adopters are therefore trying to evolve (we're definitely not there yet) an entire stack of technologies above the SOAP messaging layer to do some really visionary things.

We SOAP guys are admittedly far from nirvanna, and yes, we're in WS-* hell. I'm bitter and frustrated, believe you me.

But can't both REST and SOAP coexist? Sounds like they're each being applied to fill their own niche.

Phillip Coppney

Posts: 1
Nickname: pcoppney
Registered: Oct, 2012

Re: SOAP is Comatose But Not Officially Dead! Posted: Oct 11, 2012 5:53 AM
Reply to this message Reply
I have yet to see a line of business app built using REST. Note, Facebook, linkedIn, and all the other social apps with three entities and 4 relationships are not line of business apps. Whether or not we like it there are systems out there with lots of tables and lots of many to many relationships that have to be enforced. And, yes you can do that with REST, but you better increase you test time 5 fold and come up with some really cool message inspection (likely using a schema) tool so the testers don't try to shoot you.

Flat View: This topic has 5 replies on 1 page
Topic: Style is Substance Previous Topic   Next Topic Topic: Gentle Introduction to Scala: The Seminar

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use