Should I Stay or Should I Indigo?

By Larry O'Brien

March 1, 2005 —

The big news coming out of February’s VSLive conference in San Francisco was that Indigo, the service-oriented infrastructure that Microsoft hopes will unify interprocess communication, will be available in a Community Technology Preview by late March (“Even if it’s March 38th or March 43rd, we will deliver it in March,” promised senior VP Eric Rudder).

This was really the first time since Microsoft’s 2003 Professional Developers Conference that the community has had the coding model laid out for them. The programming model has evolved considerably since, and even in some of the presentations there were moments when presenters used outdated idioms.

There’s an old chestnut that any programming problem can be solved by adding another layer of indirection. I’ve long thought this to be true of Microsoft’s approach to modular systems. There’s been one approach for in-memory, in-process reuse of components, another approach for in-memory, but out-of-process daemons, another approach for external servers on the local network segment, a different approach for message-oriented middleware, and several different approaches for integrating with enterprise systems and trading partners.

While the simple description of Indigo is that it’s the evolution of the infrastructure for supporting Web services, it’s really quite a bit more ambitious than that—it’s an attempt to create a unified programming model for all systems that rely on out-of-process services.

Whether you think of this as “components,” “Web services,” “service-oriented architecture,” “connected systems” or other similar buzzwords, it gets back to the classic goals of reuse and integration: How do I elevate the power of my internally developed code? How do I manage systems that are made from cooperating webs of independently deployed, independently evolving components?

It would be massively na?ve to think that the soon-to-be-released Indigo bits represent anything like the final answer to these questions. Reuse and integration, like productivity and innovation, are existential issues of software development, not technical ones. The technical question is whether a programming model provides reasonable and flexible scaffolding that facilitates the currently known best practices. Also, I’m one of those who believe that the learning curve and teachability of a programming practice drives acceptance to a very large extent.

Indigo has a great pedagogical device, divvying up the challenges of service-orientation into “Address, Binding, and Contract.” Let the academics roll their eyes, but as far as I’m concerned, Indigo’s “A-B-C” mantra is crucial to the technology’s success. At VSLive, after the very first technical presentation on Indigo, people seemed excited and confident about trying it, a reaction markedly different from what one sees at Web services conferences, where people stumble through the halls, muttering acronyms to themselves in an attempt to put it all in perspective.

I’d sworn to myself that I wouldn’t mention type systems in this column for three months, but once again, the favorite bar-time topic in software development is impossible to ignore. Microsoftian Don Box described Indigo as “extruding a type system that we can think about independently of our CLR types.”

In a presentation at VSLive, he said a key design feature in Indigo “is to get away from the authoritative type definition model” and “there is no centralized definition” of a particular type. This is important for versioning and evolvability. Meanwhile, the CLR guys accelerated the expansion of the Common Type System to include generics (see “Getting Specific About Generics,” Feb. 1, page 28). This is important for versioning and evolvability.

Sigh. I don’t expect an industry consensus on type systems, but are there such fundamental differences between in-process and out-of-process that they support near-opposite approaches? I’m not convinced.

While I can feel myself being swayed on the type systems question, I’m firmer in my dislike for another decision in Indigo. The visibility of an Indigo service is fully separable from a method’s CLR visibility. Want to make a private method an Indigo service? No problem. According to Box, the CLR visibility defines an “in-memory facade” while Indigo’s attributes define a “service facade.”

Of course we don’t want all public methods to be exposed as services, but exposing my private methods? If you’re going to create a multiyear, paradigm-shifting, unified coding model, wouldn’t a new CLR visibility modifier for service (or, perhaps, “really really public”) have made more sense? I feel like suing this design decision on constitutional grounds (yeah, yeah, the word “privacy” doesn’t appear in the Constitution).

A new type system, a new visibility system, attribute-based control of object life cycle…the great success of .NET compared to J2EE was that J2EE promoted a model that was different from and more complex than “Plain Old Java Objects” while .NET promoted a model that was simple yet not simplistic and that proved sufficient.

Even as Indigo comes into public view, the Java community has resurrected POJO as the preferred approach to the majority of corporate development. The question with Indigo is whether its higher abstraction and easier learning-curve will sufficiently hide the complexity of connected systems or whether it will, like the earlier releases of J2EE, require a level of technical skill not just extending, but orthogonal to, the programming model of the underlying platform. If they can keep it to “A-B-C,” Indigo will be a success. If they start talking about “D-E-F,” it’s going to be Indigone.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.

Share this link: http://www.sdtimes.com/link/28454

News Briefs: June 15, 2008 Ingres creates a group of programs to help break in developers to the open-source concept, Xenocode launches its flagship virtualization program and Indigo Rose updates its MSI Factory program.

From the Editors: Election should shake up JCP Rod Johnson has the right ideas for opening up the Java Community Process, and he may be able to prevent the language from being overtaken, assuming the JCP cooperates. Also, Microsoft's cloud computing efforts are more open and flexible than Google's, and that's the way cloud services should be.

From the Editors: Microsoft Should Walk Its Interoperability Talk Both Microsoft and consumers in general would benefit from greater interoperability, so it should follow through on its pledge to release API documentation and work more closely with open-source developers.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST