2 minute read

I'm sitting in a great talk by Don Box on Indigo, the new model and
implementation for distributed computing from Microsoft. Don refers back to
the software integrated circuit (IC) analogy for object oriented computing,
which has its roots in Brad Cox's work on
Objective-C back in the 80s. Great metaphor, but even in the world of hardware
that model never worked - ICs tend to be too coupled to other components and
are actually soldered on the board to build a subsystem like a video card or
motherboard. It hasn't worked all that well in the software world either -
DCOM, CORBA, RMI, etc. are much harder to use than they should be. And
according to Don it is about boundaries - distributed object computing is not
respectful of boundaries and results in tightly coupled, difficult to evolve
applications.

Don summarized his position with these tenets:

  1. Distributed Objects won't work. We've tried to make it work, boundaries need to be explicit.
  2. Services are autonomous. Independent versioning, deployment, and security.
  3. Share schema, not class. Integration is based on message formats and exchange patterns, not classes and objects. As soon as we start stretching the wire, and allowing services to become autonomous, we have no idea what runtime, what runtime version, etc. Its all about boundaries.
  4. Policy-based compatibility. We make explicit assertions about capabilities.

What is Indigo? A collection of .NET assemblies (DLLs). The Indigo
architecture consists of a Service Model, Messaging Services, System Services,
Connectors, and Hosting Environments. Indigo makes service orientation more
explicit, makes boundaries more obvious.

using System.ServiceModel;  

 [Service] class MyService  
 {  
    [ServiceMethod]  
    void f() {}  

    public void g() {}  
 }

If I'm talking to the class from within the same app (CLR), I can call g() on
this class. If I'm talking to my class in a service-oriented way, the only way
to access is through f(), and Indigo will sit in the middle as an interception
point. I can't even call f() directly - it is implicitly private.

Indigo is also about unification of remoting models between ASMX, .NET
remoting, and Enterprise Services. Indigo is also about interoperability, and
WSE is an intermediate step along the way. Once Indigo is out the door, WSE
will evolve to track the protocol evolution for Indigo users, just as it does
the same for ASMX users today.

The penalty for using Indigo and service-oriented computing in general should
be low. They are working extremely hard on performance and, to quote Don,
"miniaturization" of this general concept.

Preparing for Indigo:

  • Use ASMX today - the closest thing to the TRUTH today.
  • Use .NET Enterprise Services within your service if you need ES functionality or if you need fast/secure intra-farm ORPC. FYI, this is where Corillian is today, and right where we should be.
  • Use .NET remoting within your service.

Updated: