Joe Long on Indigo Technology Roadmap

Joe Long from Microsoft gave a nice talk on the technology roadmap for Indigo,
with a nice dose of prescriptive guidance for those of us who need to do
distributed application development today but want to be mindful of the
future. The talk was framed around this question: how do we support
incremental upgrades of clients and/or servers as we move to Indigo?

Joe suggested two approaches to this problem:

  • We can teach the existing infrastructure new protocols. For example, if I have a component written that gets deployed and accessed via Enterprise Services (COM+), Microsoft can shim in some new bits under the hood to teach enterprise services how to talk via Indigo.
  • We can teach the new infrastructure about the existing legacy protocols. For example, if I write a new Indigo service, it could fall back in some fashion to talk via DCOM.

Microsoft is opting for the first approach – move the underlying protocols
forward and don’t look back. This does place some constraints on what you do
today and what might or might not work in the future. Joe covered several of
the common cases, which I’ll briefly discuss here.

COM+ Binary Interoperability

Interesting stuff here – the goal is to not force a recompile of clients or
servers by utilizing a bridged service environment. There are a few
requirements for this to work though:

  • Servers must have a type library for metadata
  • Components must be COM+ / Enterprise Services. Sorry, your ATL DCOM NT Service won’t magically be accessible via Indigo.
  • You must be explicit about interface types when used as parameters, i.e., don’t pass around IUnknown references.
  • Avoid explicit use of COSERVERINFO.
  • Custom proxy/stub marshalling will not be supported.

MSMQ Binary Interoperability

I was a bit confused on this point, but it appears that Indigo will provide
Indigo compatibility by automatically exposing MSMQ servers via web services.

ASMX Web Services

No real concerns about interoperability here, since this is SOAP/XML.

.NET Remoting and WSE

Out of luck – don’t expect much help here.

Migrating Code to Indigo

I won’t go into extensive detail here – you can check out the presentation
if you would like
more details. The gist of changes revolves around instantiation of servers and
proxies – everything else can pretty much remain the same if you are writing
ASMX web services or Enterprise Services components today. .NET remoting is
mostly orphaned, though porting won’t be too difficult. The use of “new” to
create client proxies will not be supported.

Where Should We Host Server Components?

I asked this question at the end of the talk. In the Longhorn world, as in
today, there are two primary hosts for components – IIS / ASP.NET, and
Enterprise Services. Joe’s recommendation was to use ASMX web services by
default and host in IIS. If you need Enterprise Services, go ahead and use it
but opt for the library component model and still host in IIS if at all

Dinner with Old Friends

I was able to have dinner last night with two of my oldest (their not old, but
you know what I mean) friends: Mike and Becky Sattin. Becky’s new husband Bob
also joined us. Mike and I first met back in the 1978 or 1979 timeframe, and
immediately found we had a lot of common interests. At that point in our
lives, we were most interested in playing new computer games on his Apple II
computer (Wizardry, Olympic Decathlon, Castle Wolfenstein) and sports
simulation board games by APBA. And we
often spent some late nights at his house playing Dungeons and Dragons.

I moved away from Indianapolis in 1982 to Albuquerque, then Omaha. In 1985 I
moved back to Indianapolis and finished high school where I had started
(North Central HS). During the
move transition from Omaha back to Indy, I lived with Mike and his parents.
I’m forever grateful for the hospitality they showed me during that
challenging time. Becky was away at college at Washington University, and she was one of the key influences that
led me to attend there. While I was living away from Indy, Mike managed to
become a very accomplished local musician – his living room was full of
guitars, drums, keyboards, and other equipment for his band. You can listen to
some his early music with the band Avanti right here at

Mike moved to Los Angeles around 1987 to follow his muse and take a shot at
the music scene there. We’ve stayed in touch over the years, and when I lived
in LA briefly in the early 90s I was able to see him play often, I think with
the band Ptexas Pteradactyls. He has been involved in a number of bands since
then – Superfly Connection and Captain
Pants to name a few.

Mike has a number of projects going on right now – he did his own take on
White Stripes and is involved with the band
Chromosome Tea. He
also works with Little Dawnee Frinta.

Hazy Shade of Fall in LA

I flew into LA late last night from Portland for the Microsoft PDC conference. My outbound flight was
delayed due to slowdowns in the LA area from the fires, and I didn’t get into
LAX until around 1:30am. The night-time descent through the valley and into LA
was surreal – we could see the glow from the Simi Valley fires, and the smoke
permeated the cabin so much that my eyes watered. I’m glad I’ll be spending
most of my time indoors here – the outside world is hazy and the smell of
smoke and ash is pervasive.

I lived in LA for a short while back in the early 90s, and one distinct memory
of the place is a sequence of one natural disaster after another. This is a
hardluck state.

Don Box on Indigo

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

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  
    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.

Yet Another Blog About Games

Looks like this is really catching on. Great to see other people joining the
fray and sharing session reports, reviews, and other thoughts on gaming.
Tolen Dante has just started his weblog.

Update: Tolen moved his blog to a new site with RSS feeds.