Code Name Indigo:
The Big Blue (Le Grand Bleu)
[I am commenting Don Box's introduction to Indigo]
Indigo is part of "Longhorn," the upcoming version of Windows. I believe that the marketing message is new and is shifting slightly .NET direction from Web Services to Service Oriented Architecture and Service Oriented Programming. I have noted two points in particular that seem to prove this assertion.
First, Indigo provides a rich set of technologies for "creating, consuming, processing, and transmitting messages". This statement confirms that the concept of Web Services is still a layer too high and there is a need to start the stack at a lower level i.e. at the message level (see "my web service stack"). In an SOA, Web Services represent an important but particular class of message interchanges. This is also reinforced by the definition of "Service Oriented" published by Microsoft (see right). Note that in this definition the term "web service" is not used.
What is "service-orientation"?
Service-orientation describes a new method for architecting connected systems, and is based upon three simple concepts:
- A service is a program that other programs interact with using messages.
- A client is a program that makes services usable to people.
- A connected system is a collection of inter-connected services and clients.
(source Microsoft)
Second, Microsoft seems to introduce the notion of "highly connected systems". Indigo "offers a unified programming model and communications infrastructure for developing connected systems". This is also re-enforced by Microsoft's definition of Service Orientation. As a matter of fact, we have just reached the point where anything can be "connected" to anything on the planet with enough bandwidth. It is no surprise that a technology (architecture and programming language) is now needed to take advantage of it. In a world where functionality and infrastructure software is leveling off, the only differentiator on which companies can rely on is how efficiently their "processing entities" or "system of records" are inter-connected (i.e coupled). I recommend that you also read David Orchard's article which answers the question: How do you make two systems loosely coupled?
The goal of Indigo is to enable "the vision of service oriented programming" where functionality (i.e. process and information) is composed (I also like the word "federated") at will and at any level of granularity. In order to achieve that kind of capability, one need "technical services" that are traditionally associated to the "service fabric" or also referred as the "service grid" (e.g. choreography -WS-CDL-, coordination -ws-caf-, collaboration -BPSS-).
Of course, Indigo is not finished yet, and a lot remains to be done, but it is more than a vision, anyone who has used WSE 2.0 could attest that. From the architecture picture in Don's document, I can see that Indigo may not yet consider the full extend of the "service fabric" that is needed for a SOA (Actually the very notion of service fabric may be missing from MS's definition). It could be because Indigo's "Messaging Services" and the "System Services" are not fully described yet. In addition, Indigo does not seem to be talking about "consumer oriented" message exchange (mediated by the fabric) which are essential for scaling a SOA, it seems to be still at the level of "producer contracts" (Data and Service contracts in Indigo's terms). It may also be that this aspect of SOA could remain open and may never fully converge. Certain types of fabric will be needed to solve different problems. However, two positive points Indigo is definitely building its foundation on peer-to-peer computing and it already has the most important component of the service fabric, the registry (or at least technologies to build registries). In any case, we should expect lots of action in the "fabric" in the coming months.
Today, it seems that the core of the effort on the Indigo framework is focusing on bridging existing implementation models (see the Indigo service model section) to peer-to-peer message exchange, which resulted in quite a few shortcuts on the road to SOA, hopefully they won't remain shortcomings.
Beyond the product announcement (which is a non-event, since Indigo is today little more than WSE 2.0), Microsoft is taking a rather incredible risk in betting the house on SOA when most of the standards that define the SOA level (orchestration, composition, choreography, coordination, protocols, collaboration and interaction) are still under construction (see this article I wrote recently). Actually, there is not even the beginning of a glimpse on how all these standards need to be articulated in the SOA fabric.
From what I have read on www.dotnetguru.org, Microsoft seems so committed to Indigo and peer-to-peer computing it has announced simultaneously that any further development on .NET Remoting was halted. I think the exact statement is" .NET Remoting will continue to be part of .NET but the API will remain where it is today.".
ESB vs SOA
I also would like to add some precisions on the differences between ESB (Enterprise Service Bus) and SOA. There is a fundamental difference between EAI (and the web service enabled EAI, a.k.a. ESB) and SOA. EAI relies on a "common information model", with a central EAI manager, onto which enterprise systems are bolted via connectors (be it web services, JCA or anything else). The bus represents both the common information model and the EAI manager. In an ESB, connected systems are not in control, the EAI manager is. ESB is not SOA. SOA requires a registry onto which peers registers and find other peers. In a SOA, every peer is at the same level, there is no center of control, nothing in the middle, therefore no need for a common information model. Peers are not defined by their "contract" but rather by how they interact with each other (i.e. collaborate via a message choreography). To answer Collaxa's question, IMHO, Indigo is not an ESB, it is a true SOA framework, just like TME's GAIA or SUN's JXTA project. (Please take a look at figure 7 of the BCM introduction). ESB can be viewed as a very particular case of SOA, a special kind of fabric if you will, but it is certainly not the only fabric possible.
Another aspect that few people seem to be grasping at the moment is that for building SOAs we need the notion of "service domains" (no, this is not the same thing as Scopes, since scopes have always a context associated to them). This notion is natural as soon as we think of a company boundary (which will be its own service domain), but the concept is also useful at a lower level of granularity. It greatly simplifies problems like management, security, ... but also offer an extra level of decoupling. WS-CAF is going a bit in this direction with the concept of coordination, but it stops short of providing "domain level" logic, it rather relies on well defined composition of web services packaged in a "composite application".
Overall the message is clear (so to speak :-), SOA is the way forward. This is the architecture that will allow us to master "highly connected systems", like J2EE allowed us to master the web. Maybe it is time to rename SOAP as the "Service Oriented Architecture Protocol", this is what Don may have had in mind but could not tell/scare anyone. Indigo marks the death of the mythical Business and Distributed Objects, welcome to the world of SOP (Service Oriented Programming). We have an architecture, I think we still need a programming "language", semantic (and not syntactic) and declarative (not procedural) if you please.
References
Don Box, "A Guide to Developing and Running Connected Systems with Indigo"
Microsoft FAQ on Indigo
Mary Jo Foley Interviews Don Box
Q&A: Microsoft's Eric Rudder on Longhorn, Indigo, Web services
I also like a lot Clemens comments which are more technical than this post
WebServices.org Indigo page
J. J. Dubray "Standards for a Service Oriented Architecture", ebXMLForum.org, November 2003
James Kobielus, "Microsoft is shifting .NET, Web Service focus"
