Rubenerd

It's been a long road. Several aborted starts, extenuating family circumstances, international moves, degree changes and restarts. Still, I'm less than a week away from finishing my last full time semester at uni, and I'm royally excited.

Which gets us to the issue at hand. One of the topics we have to study for tomorrow's exam is SOAP, or the misleadingly titled Simple Object Access Protocol. It's been around so long, I won't bore you with lame puns about overscrubbing you've probably all read a million times by now.

I hadn't done too much with the technology before, and certainly never attempted to implement it. My memories harken back to the mid 2000s, ironically at my first university in Adelaide, and a small web server we had to communicate with over… get this… SMTP. Turns out, SOAP is utterly application layer agnostic, so you don't even need to use HTTP.

Hey look, Wikipedia even uses SOAP over SMTP as an example. Go figure, we're not allowed to use it as a reference, but our lecturers can.

(Not that I’m suggesting anything there, of course. Other than the fact I’ve caught lecturers at UniSA and UTS using Wikipedia material in their slides. That Creative Commons licence does require attribution, guys).

But I digress, what makes SOAP?

In a fatty acid nutshell, SOAP is an XML based messaging protocol for "calling procedures on other machines". Information is transmitted in SOAP envelopes with the following components:

• A header, which outlines the features of the SOAP message
• A body, with the primary information for the message recipient
• An optional fault section to describe encountered processing errors

Of course, how do we know what services are available and the type of data we can expect to receive? For that, we turn to more XML in the form of the Web Services Description Language. These documents define:

• Services, expressed as ports/endpoints and bindings
• Ports/Endpoints, the connection point to a web service
• Bindings, which map operations to protocols, such as HTTP
• PortType/Interfaces, which defines performable operations
• Operations, or abstract descriptions of supported SOAP actions
• Messages, which define sets of parameters
• Types, which define data types used

(I’m sitting in a coffee shop while I write this, and the Hornsby Shire Council just started playing My heart will go on. I’m picturing all these people RESTing in lifeboats while this bar of SOAP slowly sinks beneath the waves under its own weight, with suds and bubbles still gurgling from its tallowy funnels).

But I digress, can we look back in time with this?

SOAP is a fascinating time capsule into how developers and designers thought web services would shake out in the late 1990s and early 2000s. Along with WSDL, the designers had bold plans for registries where web services could publish their capabilities. These were defined in yet another XML format, called the Universal Description Discovery and Integration protocol.

I asked Michael Cote of RedMonk for his opinion on about why SOAP is still used in the enterprise. "Existing applications that use it and Enterprise Architects who still want to enforce a top-down, well, architecture with it."

So that's why universities still teach it.