As preparation for my Indigo presentation at the London .NET User Group next Monday, I thought I'd write a couple of posts about Indigo, starting with 'The Road To Indigo'.

Indigo is a new technology that represents on the unification of existing distributed application technology.  It takes Remoting, Enterprise Services, Web Services and Microsoft Message Queue and combines them into a single area of platform-level technology.  In fact, Microsoft has literally taken all of the teams responsible for these technologies and put them in the same building.  Instead of thinking of Indigo as a completely new technology, think of it as the next version of all the existing approaches where all of the best features of each are combined into a single managed-code programming model.  Here's a diagram showing the progression of these technologies:

 

Indigo takes the best features of each approach and makes them available in one location.  If you're developing ASMX and Web Services today you can't  take advantage of reliable messaging (as in MSMQ) or transactions and object pooling (as in Enterprise Services) across web services calls.  With Indigo it is possible.  If you're an Enterprise Services developer today it's difficult to take advantage of flexible versioning provided by schema or being able to describe requirements using policy files (as you can in web services with WSE).  Indigo makes it possible to take advantage of all of these features.

Indigo also lets you chose the way you want to build applications without tying you in.  Indigo supports and encourages building service-oriented applications using messages based on SOAP.  However, Indigo still supports you and provides features even if you want to create distributed applications using a distributed component approach using remote procedure calls.  Choosing one approach over the other doesn't mean giving up features such as message-level encryption or transactions.  As Ingo Rammer says, Indigo recognises that you shouldn't be locked into 'a specific programming model, a serialization model, a transport model, or even just a serialization format'.

Combining the features of these four different technology areas into a single programming model is great news for developers.  We get the best features from each previous approach while only having to learn one programming model!  There's no more complexity about which technology or programming model to use for a particular distributed application scenario. It's the same programming model whether it's a peer-to-peer application on a hand-held device, right up to a secure, reliable and transacted message queue behind a massive online retailers.  

For those times when the platform needs to be extended, Indigo also provides an excellent extensibility model.  Even in this case there's only one extensibility model to learn.

Indigo brings us closer to Microsoft's long-term aim of helping developers spend less time on the plumbing and more time on the application code.