Web Service Evolution (a brief history)

With all the media attention to Web Services and now SOA it is an interesting exercise to look back at the steps we took to get here. Hind site is 20-20 and the dead ends that we followed are just memories so the evolution is pretty clear.

DEC VMS
Digital Equipment Corp, maker of the MicroVAX, boasted the first common language programming environment. Meaning that any of the languages, FORTRAN, COBOL, Bliss, etc., could call procedures from the other languages and the VMS runtime and system services libraries. This of course was not across the network, but it did begin the journey toward loosely coupled systems by allowing systems written in different languages to call each other, which was a huge step in code/library reuse. Perhaps the biggest hurdle was mapping datatypes from one language to another.

RPC
The Remote Procedure Call (RPC) allowed a program to call a function/procedure across machine boundaries. The programmer used Interface Definition Language (IDL) to "design" an API and generate a stub and skeleton code. The skeleton code had to be filled in with the remote side code and the stub code was used locally to call the remote procedure. Again, datatype mapping issues where the biggest issue here.

CORBA
Common Object Request Broker Architecture. Besides being a mouthful, CORBA extended RPC calls into a the object oriented world. While CORBA is still viable, Web Services have all but replaced the need for it.

CGI
Right around the time the HTML became popular the Common Gateway Interface (CGI) became the way to deliver dynamic HTML. This was pretty clumbsy because the entire payload had to be generated every time. So, this gave way to just delivering the data from a CGI and parsing the bits (typically CSV) in a hidden frame using JavaScript allowed two things. The UI could be separated from the Web Tier allowing the Web programmer to focus on the user experience instead of interfacing with the backend system. It also opened up the possibility of having more than one client use the same backend. CGI gave way to Java Servlets with better performance.

XML/HTTP
With Servlets dishing up CSV and text blobs to clients, along came XML. At first XML was more of a pain than a help. That is, dealing with it with Javascript, C, or even Java was not easy, reliable, or efficient, until it was widely supported. Soon every language had very good XML parsers and some even saved code. Eventually, the parsers, like SAX and now StAX, made performance only a minor consideration.

XSD
Since XML representations of data can vary greatly the correctness of XML, and so the usefulness of it, varies too. For instance, repeating elements with different meanings, missing or badly named elements are often used. Adding a schema definition XSD or previously DTD provides structure and common datatype definition to XML. Basically, it evolves to better XML. XSD also allows for a message definition and client side message validation. Without XSD, message definition was left to user documentation and server side message validation required a round trip to the server to verify simple things like required elements.

SOAP
Simple Object Access Protocol is really just a combination of the RPC mechanism and XML/XSD. SOAP defines the service operations (functions) and XSD defines the operation payloads (request and response). Typical clients generate stubs and proxy classes to use when calling a SOAP service. The details of the call are handled by the generated code, like the Axis2 client from Apache, wsdl2java or a Web Reference in Visual Studio. The classes acts much like a local object call.

The REST
RESTful services are in interesting evolution or de-evolution. They offer a simpler call interface yet still provide XSD/XML output. Because of the simple use, REST could gain significant popularity.

WS-*
The need for increased functionality from Web Services has pushed for Security, ReliableMessaging, etc. As the standards evolve, so does the usablility.