Xen and the art of plumbing maintenance
“Quality is a direct experience independent of and prior to intellectual abstractions.” (Robert Persig, Zen and the Art of Motorcycle Maintenance)
A few months ago I read a paper by Erik Meijer (et al.) that proposed marrying native support for XML and relational data to the object-oriented programming features of a language such as C#. The paper vets a prototypical programming language called Xen (in earlier rumors, “X#”) which is essentially C# with angle-bracket and SQL extensions. At the time, I thought it was nothing more than another interesting idea to come out of Microsoft Research. But now I see a symbolic connection to Microsoft’s forthcoming distributed applications programming model, codenamed Indigo.
By way of justifying Indigo, Don Box aptly draws attention to the shortcomings of earlier distributed computing technologies. DCOM and the late-baroque period of CORBA are examples of models that encouraged developers to ignore the wire. That is to say, you could build components as if they were all running in the same process space, or perhaps in separate processes on the same machine, even though they were destined to be deployed to different nodes on a network. This approach is an example of what Joel Spolsky has called a leaky abstraction, and what Germans term verschlimmerschrung (a “solution” that only makes things worse).
Leaky abstractions promise to make programming easier, but they fail to keep annoying details of the underlying problem from dribbling through; they don’t deliver on their promise of simplicity because they demand that the programmer understand the arcana that the abstraction is supposed to obscure. CORBA and DCOM were flawed in that they applied leaky object abstractions to the distributed computing problem. Letting a developer program against a remote object as though it were local is a leaky abstraction because the difficulties of design for performance and forward-compatibility (among others) leak through the abstraction and make a mess.
Indigo and Xen have one obvious commonality: a linchpin of each is XML. Indigo’s wire format for messages between distributed programs is XML. Xen makes XML a first-class citizen within the language’s type system. But aside from the obvious buzzword overlap, what do these two Microsoft efforts have to do with each other?
Perhaps the most important thing is this: both Xen and Indigo dispense with shopworn and leaky abstractions. With Indigo, programs can no longer treat remote code as though it were local; the developer explicitly acknowledges the boundaries of components by connecting to the outside world, sending and receiving XML messages (instead of proxied method invocations), and disconnecting. Xen addresses the impedance mismatch of relational data persistence, object-oriented programming, and XML data representation and manipulation—currently bandaged by mapping technologies and code generation—by supporting these orthogonal concepts at the level of the programming language. (See Dare Obasanjo’s remarks on the troika of “ROX.”)
I just googled these ideas, and it looks like Harry Pierson, for one, beat me to it. I’ll take that as a compliment.
Helpful links for dealing with alphabet soup indigestion: CORBA, C#, DCOM, SQL, XML 
