The evolution of web service protocols pt 2

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.

SOAP

Microsoft began talking to other technology firms about the promising new standard it had been working on, IBM in particular. They agreed that it was a indeed a good idea, but had some concerns about trusting Microsoft, as their contemporary reputation among their competitors was along the lines of that of Atila The Hun’s to the Romans. Eventually, after seeing the potential of “Digital Marketplaces” - directories of paid services accessible over the internet as well as tactical interoperation between each other’s products; Microsoft, Oracle, Sun, IBM, HP and others backed the new standard.

By 2000, armed with a metadata format - WSDL, a discovery protocol that enabled “Digital Marketplaces” - UDDI and a viable type system in Xml schema Bill Gates coined the phrase “Web Service” at a conference announcement in 2000. Vendor tooling began to mature - developers could drag and drop a WSDL definition onto your IDE and easily POST to their heart’s content. The standard took off like a rocket in enterprise circles, though there were other nascent companies native to the web that were more skeptical.

Planted in this fertile ground SOAP began to accumulate ..features. Additional standards for authentication, encryption, guaranteed delivery and others began to arise and the initial simplicity of the vanished under a pile of vendor specific extensions. Notably, the vast majority of people working on web applications that actually worked in a browser felt that even this:

  POST /Order HTTP/1.1
  Host: www.landfill.com
  Content-Type: text/xml
  Content-Length: nnnn
  SOAPAction: "urn:landfill.com:PO#UpdatePO"
  <SOAP-ENV:Envelope
  xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
     xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
     xsi:schemaLocation=
        "http://www.landfill.com/schemas/NPOSchema.xsd">
     <SOAP-ENV:Body xsi:type="LandfillBody">
        <UpdatePO>
           <orderID>0</orderID>
           <customerNumber>999</customerNumber>
           <item>89</item>
           <quantity>3000</quantity>
           <return>0</return>
        </UpdatePO>
     </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

Unfortunately in a browser, this needed to be processed using Javascript - a language originally designed for changing the colour of a box when you hovered over it that was now just beginning to be used to create more complicated user interfaces. Javascript was as slow, memory hungry and bug ridden as any language created during a 2 week crunch by performing a forbidden breeding experiment between Java and Scheme could be expected to be. A small group of brave programmers, immune to the sneering of their peers were beginning to make it almost useful. Unwieldy as the language was the last thing these brave pioneers wanted to do was implement a compliant Xml DOM, XSD schema validator or any of the increasingly more baroque contributions to the standard coming from the Enterprise Elves of Redmond.

Even running such a beast on the computing environment equivalent of a modern electric toothbrush made little sense, particularly after Douglas Crockford came up with a rather more simple and efficient way of serialising javascript objects - JSON. Compared to the even the relatively simple SOAP example above, this is as lean as a weasel on the wire and could be turned into JavaScript objects with a tiny fraction of the computation:

   POST /Order HTTP/1.1
   Host: www.landfill.com
   Content-Type: application/json
   Content-Length: nnnn
   {
      "orderId" : 0,
      "customerNumber" : 999,
      "item" : 89,
      "quantity" : 3000
   }

We may have lost any semblance of type information here, and a simple spelling mistake could blow your server or your clients browser or possibly both, but it was fast and it was simple. The nimble young dotcom companies fuelled by Jolt Cola and share options were mostly using development ecosystems independent of SOAP’s vendors went down their own path. SOAP would eventually be relegated to updating a resource application incident request record at decidedly unfashionable corporations, the actual web in webservice went elsewhere.