[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
Web Services to Service Oriented Architecture and Service Oriented
Programming. I have noted two points in particular that seem to prove this
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.
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
- A client is a program that makes services usable to people.
- A connected system is a collection of inter-connected services and
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
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-,
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
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
peer-to-peer message exchange, which resulted in quite a few shortcuts on the road to
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
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
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.
Don Box, "A
Guide to Developing and Running Connected Systems with Indigo"
FAQ on Indigo
Jo Foley Interviews Don Box
Microsoft's Eric Rudder on Longhorn, Indigo, Web services
I also like a lot Clemens
comments which are more technical than this post
J. J. Dubray
"Standards for a Service Oriented Architecture", ebXMLForum.org,
James Kobielus, "Microsoft
is shifting .NET, Web Service focus"