“This article shows you how to implement a Web browser-based SOAP Web services client using Ajax design patterns. In the Part 1 of this series, the author introduced a simple Web browser-based JavaScript library for invoking SOAP Web services using AJAX. In the discussion that follows, the author expands on functions of that JavaScript library by implementing basic support for the Web Services.”
SOAP is great and all, but sometimes the data you are passing and even the app itself is so simple that setting up SOAP is overkill. I’d say that’s the case for simple Ajax websites. I’m currently working on a XUL app that talks to a library of functions via XMLHttpRequest. I simply wrote my own simple encoding/decoding functions for the data exchange between the server and the client. It works well, although if I had been aware of it when I was starting out, I would have used JSON.
I think you are arguing for the same things proponents of XML-RPC, or REST over WSDL/SOAP argue for. But the article wasn’t about whether SOAP was overkill for your specific needs, or wheter there were better technologies for specific jobs. It was about SOAP Web services with Ajax.
Most RPC programming does indeed suck. I think he has the same problem with SOAP a lot of people do, the complexity of RPC and marshalling some blob of binary code over the network and executing it is grievous overkill when all you really need is a wrapper around a few strings of text to increase the probability they arrived ok. No shame in taking the HTTP server object and building a pseudo-soap service instead.
That works great when you have control over both the client and server, but what about the scenarios where you don’t? SOAP is a standard, and pretty much every programming framework out there can accept a SOAP message and parse out the necessary data. I do realize it’s relatively easy to figure out where you’re sending the message (and thus use the protocol the server expects), but that ends up adding complexity to the application down the line if multiple protocols are needed. A compressed SOAP message should usually be on par with raw binary data size wise, with just a few extra clock cycles needed on the server to decompress it.
Honestly, enough with all the mystique about XML/SOAP. 99% of the time it is a solution in search of a problem. For asynchronous Javascript applications, there is absolutely no need to go through the pain of wrapping/unwrapping that information. XMLHTTPRequest is kind of a misnomer. It can request anything from the server, even simple Javascript literals, or complex combinations of literals, which is far easier to read, doesn’t require parsing, and takes much less space. For one way to approach this, see http://www.json.org .
In fact, viewing Javascript as a functional language, you can even pass functions as literals, with some nice usage of closures to boot, so the whole or parts of your business logic can be generated and modified from the backend. This is far more flexible and powerful than XML/SOAP could ever be.