I've been told that Bruce Eckel said SOAP sucks. Harumpf. Well, that's not very gentlemanly of him, is it now?
In any case, I'm up to the challenge... if Bruce has an open mind, I'm willing to 'splain a thing or two to him. And if he wants some light reading to bring him up to speed, I have a few essays on the left over there...
And while I'm at it also looks like he needs a lesson or two in permalinks and RSS feeds.
I was thinking the same thing this morning while working on the CommentAPI implementation. I completely understand why using XML is important and valuable but when it comes to SOAP, WSDL and the umpteen WS-* specs it is much harder for me to see how they should matter to me.
I've read enough intro to SOAP articles to understand what it is but fail to see why one should use it instead of just shipping application specific XML around. Your CommentAPI implementation is a prime example of this. Why should I choose to send an RSS item wrapped up in a SOAP envelope when I can just send an RSS item?
Hopefully one of Tim, Don or Aaron Skonnard will write some MSDN article that makes stuff like this clear to grunts like me.
Some poeple are misquoting or puytting words in Bruce's mouth
http://www.mindview.net/WebLog
Lets be blunt SOAP is just another version of XML-RPC with some more functins or features..
To paraphrase Bruce: he is asking if xml-rpc works why we need SOAP..
Whic is a very different question
Oh, cool. Gang tackle. I was hoping to deal with people one at a time (starting with Bruce), but here goes... with brief answers due to the number of simultaneous issues.
James: agreed, if you control both ends of the wire and your abstractions don't leak.
Dare: did you follow why preview should be a SOAP header?
Fred: exhibit A: Metaweblog API.
Fred,
Interesting that you talk about putting words in Bruce's mouth then go ahead and do the same thing. I don't see any mention of XML-RPC in comparison to SOAP on his weblog.
As on why one needs SOAP when XML-RPC exists, better people than I have discussed the significant limitations of XML-RPC outside of simple use cases.
My question and that which Bruce seems to be asking is if you can just send XML around why bother wrapping it up in SOAP and picking up all the other XML Web Services baggage.
PS: Sam, you need to add RPC to the list of words your spell checker should accept.
Iain: it still is a valid question.
Dare: it's my weblog and RPC should get underlined in red. ;-)
As for XML-RPC vs. SOAP, check out http://www.xml.com/pub/a/ws/2001/04/04/soap.html for the history from someone who was there.
I have the 1998 SOAP spec on my laptop - it looks astonishingly like XML-RPC. We moved away from that encoding style because it was unnatural for a lot of applications. See http://www.intertwingly.net/stories/2003/01/26/evolve.html for a great analysis of this.
Also, Bruce forgot to mention that iterators were also in the ICON programming language (that's where I first encountered them) - alas, not everything good was invented by Guido :-)
Re controlling both ends of the wire - most usage of SOAP I'm seeing is intra-company. I simply don't see the value over CORBA in that arena.
Inter-company, you are probably right
I have the following written in my notes from the keynote at the Web Services DevCon in Boston:
If you control both ends of the wire
SOAP is probably not for you.
Note: The keynote was titled "Interop Is All" and given by Sam.
Hi Matt!
And that slide is still online.
if you know CORBA, or & Apollo DCE Sunos RPC for that matter, SOAP does seem to have hints of the suck nature, though not as much XML-RPC.
However, if you'e ever worked on a big CORBA app, with >1 team involved, and throw in a bit of maintenance/integration with legacy cruft, you'll soon discover you can't control both ends of the wire, even in an organisation. Even if you control them now, five years from now your decision to use COM+, RMI, EJB whatever will be ridiculed by your successors.
A well designed service is not an RPC interface, it is a service that is robust, scaleable (you can steal a lot of the HTTP scaling infrastructure) and (esp if you doc/lit), flexible.
Now, where does SOAP suck?
-there is too much bias to SOAP-as-RPC,
blocking calls, & tight coupling; JAX-RPC is an example of this.
This means people are writing brittle code, that just isn;t going to work over long haul links, or against intermittent network failures, let alone work into the future.
-Interop is in its infancy. One issue is that real(tm) remote object infrastructures have set people's expectations in a way that doesn't map to
loose coupled systems. The other is the new spec stack will lead to divergence; we haven't even got consistency of binary data, let alone signatures, routing, transactions...
-The computing industry in pushing people into writing web services, and now people who can't write a VB or Java app to save its window position to a persistent store are now trying to write web services.
You can see the latter on the axis user mail list, where users complain that they are getting a 'connection refused' error, AxisFault 'HttpResponse:404' or 'ClassNotFoundException'and can somebody please help them. These people should not be helped. There is an informal mountaineering rule that you never help incompetents up a mountain to killed higher up, only down, to get out alive. Wannabe SOAP developers should be told to work through Bruce's TIJ book, TCP Illustrated, RFC2516, Hunter's Servlets, Box and Skonnard on XML and then maybe write a first web service.
I think we should make the download for Axis1.1 dependent on passing a competency test on a web form. I volunteer to write it. I wrote the new install instructions for Axis to scare people off after all.
Steve, it's good to see youhear buddy! I'm stil recalling our mad dash to Starbucks in your rental at Chris's last Web Services DevCon _ will never drive with you again-)
Anyhow, where is your RSS feed on your blog? -)
As to Bruce, all I'll say without getting nasty is that it doesn't suprise me in the least he doesn't get it.
Sam, Steve, Dare, Don - good going on the helpful facts and information
XML is bloated...if you have a website (amazon perhaps) taking many requests for orders then soap messages are going to take much longer to process than something that is more specific with a smaller foot print!
Lets put it another way...a user goes to amazon to order a DVD but it takes to long for a response so he/she goes somewhere else...sale lost!
Performance is a key issue...The big players know this but still say that SOAP is the next big thing...why? because they invented it of coarse and it will make them money...especially on hardware upgrade in order to handle the extra bandwidth!!
SOAP is the worst messaging exchange format I have ever seen and I am amazed that so many professionals can make such a hash on a new protocol?!?
I invented a new character encoding, it only uses 5 bits per >character. The math is a little tricky to extract it but I wrote a >C# wrapper class that does all the work for you, and it's 28% more >efficient than ASCII.