Ok, let’s assume for the moment that everyone buys Microsoft’s vision of the future: software systems as compositions of services provided by multiple vendors who integrate spontaneously and seamlessly by utilizing the common communications framework of XML and SOAP messages. We have the rudimentary toolset in place, but those tools are distributed across many different API’s in the current version of the CLR. What’s needed is a strong set of framework technologies to make dealing with these XML messages more consistent across transport layers and messaging patterns.

There’s an overabundance of messaging API’s in the .NET framework right now. We’ve got:

• System.Messaging: The foundation for sending messages (which are first-class citizens) reliably across a persistent, reliable transport mechanism. Putting SOAP inside of these messages and sending them across an MSMQ transport might be a viable way to achieve reliable messaging within the enterprise – if you can figure out how to get this transport mechanism to interact properly with the other messaging stacks.
• System.Remoting: The remoting stack offers the most flexibility when it comes to messaging patterns and transport options, but it does so at the expense of interoperability. RPC is a walk in the park with remoting, and it’s relatively easy to roll a pub/sub framework for asynchronous communication because it’s very easy to have a remoting host act as both a message consumer and a message originator. However, because remoting assumes strong type fidelity on both sides of the remoting boundary, interop is the Achilles heel of remoting.
• The ASMX Stack: Great for building interoperable web services using SOAP and XML. The extensible architecture allows the pre- and post-processing of messages, but the stack is really geared toward synchronous RPC-style messaging. While it’s possible to communicate with an ASMX web service asynchronously, there’s almost no support for a pub/sub messaging style. Also, there’s no support non-HTTP transports.
• WSE 2.0: ASMX for the real world. Extensibility is made easier via the pipeline architecture. Lots of good WS-* support for solving tough problems like security, but still tied to the problems of the ASMX stack in the general case. However, if people are willing to abandon the ASMX stack and use the native messaging classes (SoapReceiver and SoapSender), the possibilities for doing non-RPC messaging over alternative transports are exciting.

There’s room here for something that combines the best features of all of these messaging API’s:

·         The messages-are-first-class-entities idea from System.Messaging.

·         The configurability and transport-agnosticism of the Remoting stack.

·         The extensibility and declarative nature of the ASMX stack.

·         The pipeline model, interoperability, WS-* support, and support for multiple messaging patterns offered by WSE.

It’s entirely possible that Indigo will realize some of these goals. While no one can say for sure, my guess is that WSE 2.0 is going to be positioned as “proto-Indigo” post-PDC. I do think it’s interesting that Omri Gazitt is a PM on the Indigo team and also owns WSE. Clearly, the two technologies are at least in some way related.

Like everything at this point, this is all speculation – can’t wait to learn what Indigo really is at the PDC!