the corner office

Bruce Eckel, on Web Services:

Programming is all about abstraction, and the abstraction here is the remote procedure call. I want to be able to write some kind of simple function call, and get some information and maybe produce some kind of side effect on the remote computer. If the underlying mechanism happens to ship data back and forth using XML, or uses an XML-RPC, SOAP, or JSON setup to make the call, that's fine -- but I'm solving a real problem here and I don't want to have to spend my time figuring that stuff out, or even needing to think about it.

SOAP is supposed to make data exchange easy, but in reality, it just makes things even more complicated.

I have a simple theory based on how two colleagues naively (by which I mean "oblivious to SOAP") and independently approached various data interchange problems. To exchange data, you need two things: format and comms. For web services, format is XML, comms is HTTP. Do you need big monstrous libraries to serialise-deserialise and wrap method types and do fancy communication and cater for different formats and the like, though? No. Why? Your average Java developer knows how to use XML APIs. Converting a Java object to an XML representation and back is not hard. Second, Java makes comms easy. There is ample support for HTTP communication. Mastering an HTTP client library is certainly no harder than figuring out how the hell SOAP works.

I'm sure it's the same with other languages. This is why the concept of web services is popular. With two simple APIs, your average developer can fling data across a network quite easily. Yes, what they're doing isn't as abstracted as some would like, but the problem with technologies like SOAP is that something simple gets totally convoluted, until you've got an overgrown mud pie that's theoretically pleasing but has lost sight of the underlying merits that made it seem like a good idea in the first place.