Microsoft's Distributed systems. A potted history.

I began to wonder how many technologies for distributed system that we have moved through since the 90's when I first started using DCOM. COM in VB was my first foray. Happy days.

DCOM and COM+

In the 90's, when programming with Microsoft, we had Distributed COM, DCOM and COM+ to play with if we wanted to get computers to communicate and work together as a system. These technologies were RPC based, worked only with Windows and required the DCOM to be infrastructure available on each node. The COM acronym, Component Object Model, gives us a clue that these were component based technologies.

ES

With .NET came a wrapper for DCOM and Com+ and that was Enterprise Services. This therefore had the same paradigm attributes as pre-.NET, it was RPC and worked only on Windows machines.

Remoting

.NET Remoting came along and was very simple and useful. It was ideal for new developments on new contained systems but it required each node to have the .NET CLR installed. This therefore reduced the effectiveness to only managed code systems running on Windows. It too was RPC in style.

MSMQ

Running alongside these technologies has been Microsoft Message Queue, MSMQ. It has been around since NT 4 and Windows 95. This differed from the other technologies in that rather than the RPC model it concentrated on Messages. It was not component based. But it did still require the nodes to have the MSMQ infrastructure on each node.   

So we have:

DCOM/COM+ and ES

.NET Remoting

MSMQ

In the late 90's web-services became prevalent and this enables any platform to communicate to another. Linux to Mac to Windows to whatever. Utilising the ubiquitous HTTP protocol we can use XML for the message formats and they can be in a variety of types - SOAP or RSS etc. 

SOAP & REST

SOAP (Simple Object Access Protocol) was the most common protocol specification used and is still very popular.  http://en.wikipedia.org/wiki/SOAP

• SOAP is simple.
• It is an XML file.
• The message contains a SOAP ENVELOPE  element as the root.
• The Envelope contains a Body element and a Head element.
• Your payload goes in the Body and the some controlling specifications can go into the Header. The controlling specifications are for Security, Reliable Messaging and Transaction features.

The main differing feature between SOAP and RESTful services is tat SOAP is specified to be used on any transport mechanism. REST however is tends only to be used on HTTP.

The SOAP stack

SOAP can therefore be used on any platform and requires the service contract to be coded in a similar way to RPC

REST (Representation State Transfer) http://en.wikipedia.org/wiki/REST 

With REST we treat services as Resources with unique identifies and we use the  HTTP defined interface of 

• GET, 
• POST, 
• PUT, 
• DELETE and 
• HEAD.

ASP.NET Web Services 

Microsoft provided ASP.NET Web Services (ASMX) which provided early basic support for SOAP.

Web Services Enhancements

Soon after the ASMX came WSE. This provided some support for the Security, RM and Tx protocols. Also supported were some TCP support. There were however no support for REST. 

Microsoft started to create a single model for all their communication frameworks. This became the Windows Communication Framework.

WCF

Now we can use use WCF to write the communication logic and then we can use whatever features we need. 

This is a huge step forward. The developer can now write against one single framework even if the requirement is for binary communication over TCP, or SOAP or REST.