Koz Speaks

Joining the Opposition

Back in the dark history of the internet (the ‘90s) the world needed a way to let systems to talk to one another. CORBA, DCOM and RMI were too platform specific, and were too brittle for the reach we were looking for. We wanted to let people build web pages that could connect to other people’s ecommerce systems. To let you embed bits of other peoples ‘stuff’ in your own ‘stuff’. Just as it is today, XML was popular back then so the new solution would have to use it.

First came XML-RPC, people built apps with it, but it was a little simplistic. We needed something a little richer than arrays and hashes, why not send actual XML documents that lets us extend APIs using namespaces and the like. That was definitely a step in the right direction, but something went horribly, horribly wrong.

The vendors figured they’d solve it for us, and along came SOAP, WSDL, BPEL, WS-. Each spec layered on top of the previous one leaving us with more WS specs proliferating like RFCs, but without the ‘3 implementations rule’ we have no way of knowing how many people actually use this stuff.

Shortly after SOAP went 1.0, I stopped working with web services, I no longer needed this stuff for my day job, and it had become way to hard for me to keep up for the sake of interest. My current project involves some web services work (SOA man, it’s buzz-tastic), and I’m more than a little disturbed by what I’m facing.

I’m pretty familiar with XML & HTTP, I’ve actually read the RFC which tells you how to handle it. I’ve also read enough to know that xml is tough. But this SOAP stuff is even tougher, documents on the wire seem to have 30 different namespaces. It’s getting really hard to use the view source approach to learning it.

However most of the people using SOAP appear to follow an RPC approach:

  1. Take a class
  2. Generate WSDL from the source
  3. Provide the WSDL to your clients
  4. Who then generate their stubs

So if the server changes the code, the WSDL gets regenerated and the client needs to be recompiled. It seems to me, that the reason the industry abandoned RMI/DCOM/IIOP was the fact that altering the server code shouldn’t require client upgrades. We seem to have all the costs of those systems, with an additional performance hit.

The document literal approach to SOAP seems a step in the right direction. But if you step back for a second, why are we taking SOAP with us. By making the endpoints less concerned with the contents of the message, you’re just dealing with a nice big DOM tree. New elements can be added to the schema, namespaces can be inserted, your code only breaks something disappears. The Alpine guys seem to have the right idea, but I’m still having trouble seeing why SOAP is required.

But removing the method from the payload means you now have to use one URL per method, it’s starting to look an awful lot like REST/POX, with a bunch of crap around the xml. I’m curious, what exactly does SOAP, WS- and the rest of the layers of complexity buy me here?

Most of the responses I’ve heard to that question are typically:

  • You get service descriptions with WSDL
  • You can force validation to a schema
  • You can support transports other than HTTP

Well, WSDL and Schemas are no substitute for documentation. The Backpack API has everything I need, it’s well documented and easy to use. Everyone who’s using it did so without a description language, and without a schema to validate against. Other transports? I don’t need them.

To this end, I’m declaring myself a member of Tim Bray’s Loyal Opposition. We have plenty of specs, the tools will not save us (remember EJBs?) and layering further complexity on top of a failing standard isn’t going to help matters. Developers have voted with their feet, amazon.com’s REST api accounts for 85% of their usage, their SOAP API is used by the tiny minority of developers.

The percentages may be different in ‘the enterprise’ where there are Architecture Astronauts involved, but it seems complexity loses where developers are free to make their own choices. That’s seals it for me really, out in public people witness your failures, but ehind the firewall, nobody can hear you scream and nobody can see your wallet bleed.