Indigo and Integrating

  • Article

Mey has made a great statement about why Integration should not be an after thought, I am pretty sure you are convinced by now it is not. Now let’s try to understand how Indigo the next generation distributed programming model from Microsoft enables integration between different systems. The following are the key pillars of Indigo

  • Unification: Unification is about how Indigo provides a single composable programming model for all the  existing distributed stacks.
  • Integration: Integration is about how different Microsoft technologies work together
  • Interop: Interop is about how different Microsoft technologies work with systems from other vendors such as IBM, BEA etc

Today you have different programming models to accomplish different tasks. For example if you want to do queuing you need to use System.Messaging, If you want to do transactions you need to use System.EnterpriseServices, if you need to do security you need to use WSE , it goes on and on. As a programmer you are constantly forced to context switch between these different programming models. Indigo does a great job of providing a unified programming model where in you can compose all these different functionalities into your application without having to do a lot of context switching. Going forward you have to just learn one programming model i.e. Indigo. If you want queuing you just add an attribute to your Indigo Service contract that makes it queued, if you want to secure the communication with your Indigo service you just add the appropriate security attributes for authentication and privacy, if you want transaction you just add the transaction attribute. This new programming paradigm should help you concentrate more on what you care most about; your business logic.

Ok, now that I have got you exited about Indigo I also realize that you cannot just throw away all the investments that you made on developing the applications that you have today using System.Messaging, System.EnterpriseServices, WSE , ASMX etc. If I were you I will have the following questions.

 

  • While I develop my new applications with Indigo will it work with my existing applications? For example Will my new Indigo queued application work with my existing queued application built using System.Messaging application?
  • Can I migrate my applications to Indigo “one at a time” instead of “everything at once”

 

Fortunately the answers to the both the questions above are an astounding “Yes”. Firstly we can derive great solace from the fact that Indigo team is made of the same developers who built System.Messaging, System.EnterpriseServices, WSE ASMX, .NET Remoting etc. This means integration with existing systems was on the minds of every Indigo developer from the word go. The result is a great integration story.

  • You can run any of your existing applications side-by-side with Indigo applications.
  • Existing MSMQ applications seamlessly integrate with new Indigo queued applications
  • WSE 3.0 applications are wire compatible with Indigo.
  • ASP.NET Webservice (ASMX) applications are wire compatible with Indigo.

The only caveat is .NET Remoting. If you have an application that uses .NET Remoting you are out of luck. Indigo apps are not wire compatible with your .NET remoting applications.

Now let’s move on to Interoperability. Enterpise infrastructure is comprised of systems deployed over time by various vendors; these diverse systems have to work with each other. How does Indigo help you to interop with systems built on top of non-microsoft software?

Indigo achieves interoperability through the use of different standard WebService protocols like WS-I basic profile, WS-Security, WS-AutomicTransactions, WS-ReliableMessaging etc. Microsoft is working closely with IBM, BEA and other key players in the industry to drive these protocols to standardization. The adoption of these protocol standards by different vendors mean increased interoperability between your diverse systems. This essentially boils down to this; your Indigo app that runs on Windows 2003 or Longhorn web server can do reliable messaging with a Java application running on a IBM mainframe.

I am excited about this because this will make the software world a heaven where diverse systems can co-exist peacefully. Today we are forced to build bridges that bring these systems together. We spend a lot of time, money and energy in building those huge monolithic bridges. Most of the time these bridges become a bottleneck or a single point of failure.I have great hopes that the emerging WebService standards will bring a lasting solution for interoperability.