Partager via

My initial thoughts on "Indigo" (Windows Communication Foundation)

  • Article

Recently, I took an extensive in-depth course on Indigo, Microsoft’s new platform for allowing applications to talk to each other easier. I’ve decided to write a blog on this topic, sharing what I’ve learned with others.

Indigo is an attempt to replace DCOM, MSMQ, COM+, Web Services, ASMX, Remoting and other technologies designed for inter-application communication. The Indigo team has incorporated the strengths of these older technologies into this new platform, and designed Indigo to position itself as a replacement for whatever technologies current products are using. Teams that are using Remoting will refer to Indigo as the next generation of Remoting. Teams using Web Services will look at Indigo as the next generation of web services. Indigo has also been designed to easily “Interop” with older technologies. Right now, applications that use ASMX to connect to the a business layer could be rewritten using Indigo, and the front end would not require any code changes as Indigo would be able to emulate standard SOAP 1.2 messages and XmlFormatter serialized return objects. An Indigo client application would be able to communicate with ASMX web services, or even send objects to an MSMQ based queue service. The Indigo team has gone out of their way to ensure smooth transitions between old and new technologies, and guaranteed no one will have any excuse not to upgrade due to incompatibility.

Indigo is built on “channels”, which describe how data is moved from one place to another. There are two kinds of channels, protocol channels and transport channels. This abstraction guarantees that the way an object is actually encoded (or serialized) is completely independent of the way it’s moved across the wire. A protocol channel may serialize an object using XML based on the SOAP specification. Or a protocol channel could use a binary encoder to encode data in a very tight and efficient binary form. One could write their own protocol channel to do their own custom encoding, handle encryption, etc. Unlike ASMX, we are no longer tied to using SOAP or XML based encoding to encode an object, and no longer tied to HTTP to transport that object. A transport channel takes this encoded instance of an object and transports it across the wire. Out of the box, Indigo has several transport channels. The easiest to use (and default) are the Basic bindings. An Indigo server binds itself to a Network interface, opens up a listener socket on a port of your choice. An Indigo client would connect to that port and transport data directly over TCP. Note, this has nothing at all to do with IIS, nor does it even use IIS. This is simply just socket to socket communication. Indigo also supports transports such as HTTP, HTTPS, named pipes, MSMQ, UDP, etc. Indigo can be hosted in a simple console application, it can run under a Winforms application or an NT service, or can be “hosted” in the IIS app domain and run under ASP.NET. One could write their own transport protocol to handle their own communication, such as a shared memory protocol for truly optimized data transfer, or a protocol that was intelligent and would do the right thing based on the network configuration.

Indigo works on a stack of channels, channels can be combined and stacked on top of each other. One channel can do encryption, others can authenticate data. There can be intermediaries to intercept and proxy requests. Indigo is designed to be truly flexible, any piece can be overridden using behaviors. Developers can override the raw socket code, construct their own XML messages by hand and play with any aspect of the platform down to the lowest level, or they can sit back and write 3 lines of code so Indigo will do everything for them. Indigo offers a style where you can pick and choose which components you want to use and which you want to implement yourself. Classes can be tagged with various [Attributes] to define how Indigo should handle them.

This platform also supports security out of the box based on the WS-Secure standard. Indigo provides the following security types: Anonymous, Windows Auth, Username and certificates. It also supports impersonation and passing around security credentials through a medium. Indigo can handle sessions per user, go sessionless so that each web request instantiates a new handler object, or create a Singleton handler class which the first time a request is made, the handler will be new’ed up and then saved in memory for future requests. This is a huge improvement over ASMX where session state is near impossible to do right.

Transactions are also very strongly supported via .NET 2.0’s System.Transaction.dll component. Transactions can be serialized across the wire and Indigo can manage transaction states.

Indigo also has a very dynamic way of handling errors and exceptions. Obviously, you wouldn’t want an exception object returned directly from a web service. You might not want the customer having a full stack trace and inner exceptions. So Indigo has the support to return “faults”, which will end up triggering an exception down on the client but only contain desired information from the server. Developers can build their own fault types that encapsulate any error information they want.

Indigo also provides much more advanced serialization. Serialization is now 100% WS-* compliant. Circular references in serialized objects are now supported, as well as a very flexible security mechanism. SOAP packets can be tamper-resistant: they’ll be unencrypted and human readable, but if the contents are changed the platform will catch it. SOAP packets can also be encrypted, the header contains a hash value to ensure the packet is not tampered with and the <body> will be encrypted through one of the default encryption providers or through custom code. The platform will handshake with the client to setup a secure session very similar to how SSL works: The client will ask for a certificate (or a public key) from the server. The client will then generate a random number, then encrypt that number with the public key. The server, having the private key, will be able to decrypt that number, and that number will then be used as a key to sign future messages between the client and server. Using this method, messages themselves are secure, not the actual transport. One could still use SSL to secure the transport, but encrypting the messages themselves allows for an untrusted intermediary between the client and server without the need to re-encrypt, and it’s also much more efficient. All this is out of the box, customizable, and available for free from the Indigo platform. It took about 4-8 SOAP messages (depending on the setup) echoed back and forth between the client and server to setup a secured session, and after that the overhead was minimal. Also, this security is turned on by default and you’d have to go out of your way to disable it.

Indigo also supports the new SOAP based reliable messaging standards. No longer will you send off a SOAP request to the server and have no idea if the message was actually received or not. The server can send back a SOAP message basically saying “I didn’t get the message with the following ID, can you resend it?” and the platform will take care of resending the message for you. The concept of message order can also be preserved on web methods that so indicate. I can send your server 100 messages, and if message 10 is not received properly, the server will send back a request for message 10 and suspend processing messages until message 10 is received. In the mean time, received message 11+ will be stored in a queue until 10 is received, at which time, 10 and on will then be processed. This same queue mechanism provides a large amount of scalability under heavy loads. All of this only took a few minutes to implement.

There are also some improvements that the IIS team is making for IIS7, under Longhorn. IIS7 is no longer tied to HTTP and HTTPS. IIS will be able to host services that use TCP sockets, named pipes, etc. There’s really no reason to use HTTP unless you’re calling a service over the Internet or over an HTTP proxy.

Overall, I’m quite excited by this platform and it’s given me a few ideas for using this technology in my own work. I’m impressed by what the Indigo team has done, and it takes quite a bit to impress me these days. Indigo is definitely a fantastic platform and provides the power to do exactly what you want, how you want it by writing custom behaviors, implementing certain interfaces and deriving from a whole set of carefully crafted base classes. This two day 16-hour class barely touched the basics of this new platform, and I expect to see huge books written on Indigo in the next year or two.

Mike

Comments