There’s been a bunch of information on Indigo coming out this week. Out of all the new technology that is coming down the pike post Whidbey, Indigo seems to me the most exciting. What Indigo promises to do is consolidate the various mechanism we have today to pass data between disconnected systems into a single common interface that makes it relatively straight forward to swap the transport mechanism.

There’s a pretty good overview document here:

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnlong/html/introindigov1-0.asp

A few days ago Clemens Vasters, and then a couple of days later Bruce Williams show some Indigo 101 server examples that although as simple as it gets actually demonstrate the power of this approach:

http://galactic-patrol.blogspot.com/2005/02/indigo-is-re-released-into-wild.html

As you can see it’s pretty straight forward to create a service, but it is a little more explicit than say a plain Web Service which is a good thing. Indigo gives you a lot more control and more importantly lets you choose how to publish the service. Along the same lines you can dynamically create clients (ie. no pregen a proxy) as an option. Proxy pregeneration is still available just as it was for Web Services but now for a more generic Service.

It looks like this approach will address a number of shortcomings we currently have in V1.1 – namely much lack of control over services created because the current versions are based purely on classes. Indigo goes for a more formal Contract approach which provides many more options to customize the server pieces. On the client side things look more like .NET remoting if you use the ‘manual’ approach, or like WSE 2.0 manual access, but proxy generation is also supported so the 'Web Reference' type approach will still be supported but not just for Web Services.

I haven’t played with Indigo yet but I plan to once new bits are released. The beauty of this model is the promise of writing your service once and then being able to publish it in different ways. Along the same lines clients will be able to switch protocols just by specifying different end points and protocols. Supported communication bindings include (quoted):

·         BasicProfileHttpBinding: conforms to the Web services Interoperability Organization (WS-I) Basic Profile 1.0, which specifies SOAP over HTTP. This is an endpoint's default binding if none is explicitly specified.

·         BasicProfileHttpsBinding: conforms to the WS-I Basic Security Profile 1.0, which specifies SOAP over HTTPS.

·         WsHttpBinding: supports reliable message transfer with WS-ReliableMessaging, security with WS-Security, and transactions with WS-AtomicTransaction. This binding allows interoperability with other Web services implementations that also support these specifications.

·         WsDualHttpBinding: like WsHttpBinding, but also supports interaction using duplex contracts. Using this binding, both services and clients can receive and send messages.

·         NetTcpBinding: sends binary-encoded SOAP, including support for reliable message transfer, security, and transactions, directly over TCP. This binding can only be used for Indigo-to-Indigo communication.

·         NetNamedPipeBinding: sends binary-encoded SOAP over named pipes. This binding is only usable for Indigo-to-Indigo communication between processes on the same Windows machine.

·         NetMsmqBinding: sends binary-encoded SOAP over MSMQ, as described later. This binding can only be used for Indigo-to-Indigo communication.

That’s a lot of options of varying degree of performance and standards compliance!

The current way things work in .NET is acceptable, with Web Services and Remoting being plenty powerful, Queing available but each following completely different programming models with each having some significant limitations. One thing I really look forward to is more dynamic control over Web Services clients rather than the pre-gen’d classes .NET gives you now.

I've spent a little time searching around for information on Indigo and COM+ and DCOM replacements. I couldn't really find much information there, so it looks like DCOM is not going to be used/supported in this architecture, but I'm not sure. Although there is a lot of mention of COM+ in the articles I've seen I haven't seen anything specific on how COM+ usage will be affected and whether there will be better integration for it in Indigo.

This all looks very exciting...