Taskboy: A Web Services Exhibition. Part 3

(Note 1: This is the third and last part of a series on the taskboy CMS. It's the least informative of the three, substituting opinion for fact in a thuggish way.)

(Note 2: I stole this picture of TV cook and personal hero Alton Brown from the Internet Wayback Machine, since he no longer blogs. He had an ugly incident with the public, it seems. Personally, I think it became too much of a time sink for him. I hardly have a life at all and I can't add content here daily.)

XML, SOAP and other windbags

This is a very long post already, but I'll chime in some recurring trash talk about XML-RPC that irks me. Before I start, I want to clarify one thing: this screed isn't directed against Mr. Harold, who is to be praised for making his manuscript available for free. That's something I'd like to see more of from all quarters. Mr. Harold has done his part to make the world a little brighter by providing a free and quality resource for java programers.

OK. Time for the shit storm.

In Processing XML with Java, Elliotte Rusty Harold asserts the following while introducing the section on SOAP:

«XML-RPC was in large part invented by a single person who really didn't know a lot about XML. Consequently he made many very questionable choices...

Whereas XML-RPC was a quick hack by one developer, SOAP has been developed by a committee of XML experts from various companies including IBM and Microsoft.

You've undoubtedly heard the old saw about a camel being a horse designed by committee... SOAP is a much more robust protocol than XML-RPC. It is much better designed from an XML standpoint as well. It takes advantage of numerous features of XML such as attributes, Unicode, and namespaces that XML-RPC either ignores or actively opposes. (my emphasis) XML-RPC is adequate for simple tasks. However, if you get serious with it you rapidly hit a wall...

The biggest conceptual difference between SOAP and XML-RPC is that XML-RPC exchanges a limited number of parameters of six fixed types, plus structs and arrays. However, SOAP allows you to send the server arbitrary XML elements. (my emphasis) This is a much more flexible approach. »

This is a very common argument made against XML-RPC and here's why it's dumb.

The beauty of web services doesn't lie in XML; it lies in the simplicity of the process. Yes, XML (sort of) helps this simplicity, but the real value of a web service in the work it faciliates. It's the platform neutral procedure calls that make web services interesting. Too many SOAP advocates are thinking in terms of only one language (*cough*java*cough*) and so expect a very close mesh between their language and an RPC mechanism. News flash: XML-RPC ain't RMI. I've used XML-RPC in at least a have dozen languages. SOAP is just painful, even in java (which I used for a cell phone application). Sometimes I expect an array of strings just be an array of strings.

XML-RPC is caveman simple and that is a colossal advantage. It's restriction of datatypes is an advantage that many OO-heads should wake up to. Not only are most things in life not Objects or Classes, many things for which there are Objects and Classes shouldn't be. Sometimes a plain old ASCII string is Good Enough, despite political posturing.

I dislike XML and barely tolerate it in XML-RPC. All of the XML features mentioned in the quote, particularly namespaces and user-defined datatypes make SOAP a digital Babel. I hardly like attributes in XML. SOAP's flexibility is a liability. How many times of Perl hackers been taken to task for their language's robust syntax? WSDL is little help to taming the complexity of web services here. It contributes to the traffic jam. I LIKE that there's no offical DTD for XML-RPC. DTD's are sooo SGML. Well formedness is all you need. Everything else is a data validation problem for the application.

That's right, I said: the app needs to validate data. Does your language make this easy? If not, get one that does.

The KISS principal of XML-RPC goes very, very far here. The features that SOAP has are for a future web of web services that may never come. XML-RPC is here today; stable with a boatload of implementations in many languages. SOAP is one document format too far and too far out.

The End: "Well, I'm back."