Management by objects

Last month I wrote about MSH ("monad"), Microsoft’s new command shell, and demonstrated the software on my blog. The column-plus-demo drew favorable reactions not only from the Windows crowd, but also from Unix/Linux folk who saw the MSH object pipeline as a genuine innovation. They’re right.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

Although MSH retains the venerable Unix pipeline, which is an indisputably excellent framework for integration, it abolishes what Monad architect Jeffrey Snover has called “faith-based parsing.” Those who have worshipped in that church for decades know just what he means.

In Unix shells we must simply believe that programs will output the data structures we expect. There’s no way to interrogate those outputs, verify or falsify our beliefs, and adapt intelligently to change.

The value of a pipeline based on self-describing objects is immediately obvious. The source of those magical objects, however, has not been so widely appreciated. MSH relies on, and will also help to accelerate, the wrapping of Windows system services in .Net Framework classes. A couple of years ago, at a briefing on the then-named .Net Server, Microsoft hinted that large swaths of its server suite were being rewritten in managed code. Of course that wasn’t practical then, isn’t practical now, and may not be so for years to come. But managed-code interfaces wrapped around the existing systems are feasible and really useful. That message wasn’t powerful enough to stop the rebranding of .Net Server as Windows Server 2003, but it’s a big deal nonetheless.

As Windows steadily evolves into a family of products that integrates by means of managed objects, all sorts of benefits accrue. Interfaces are easier to discover. Composite applications come together more quickly and, thanks to modern exception handling, behave more reliably. The chasm that separates command-line oriented applications from graphical applications becomes easier to cross.

All this adds up to an imminent challenge to Unix/Linux. In that ecosystem, Java is the logical counterpart to .Net in the Windows world.

Despite its huge head start, though, Java has done surprisingly little to rationalize basic system management and integration in the Unix/Linux realm. It’s understandable, if regrettable, that Linux and Java have never intertwined as intimately as they might have done. For all its potential value, the union would have had to overcome deep divisions. On the technical front, Java’s object-oriented purity can seem to float above the gritty realities of the C and C++ trenches. And on the cultural front, Sun’s ownership of Java conflicts with Linux’s open source purity.

Why, though, hasn’t Sun done more to bring these worlds together? With its strategic stake in Java on the one hand and both Solaris and Linux on the other, you’d think it would make sense to combine these technologies in more than just a rhetorical way.

The wild card here, by the way, is Novell. With Suse and Ximian under one roof, it’s at least conceivable that Microsoft’s Windows strategy could play out on Linux in terms of Mono, the open source implementation of .Net. That’s an incredible long shot, of course, but the synergies are worth pondering.