Tangled in the Threads

Jon Udell, November 8, 2000

Component software: the next generation

.NET takes language agnosticism to the next level

For Linux and open source, it's time to put aside partisanship and agree on a standard component infrastructure

One of the things that Microsoft gets right, in my opinion, is language agnosticism. The most productive programming environments I've worked in are multi-language environments in which interpreted languages (Lisp, Perl, Python, Visual Basic, JavaScript) wield compiled components (made in C or C++), in concert with declarative data-manipulation languages (SQL, more recently XSLT). The notion that there is, or should be, One True Language for software development has always seemed wrong to me. And this, I suppose, is what has always made me uncomfortable about Java. Sun's platform aspirations are inextricably bound to Java imperialism. Some argue that this is a good thing, because programmers can only become skillful in one language, so one language should do everything. I don't buy that argument. Let's give programmers more credit. Programming languages are tools; programming is a craft; every competent craftsperson has a well-stocked toolbox.

For years now, Microsoft has been de-emphasizing programming languages, and focusing on component architecture as the real engine of software development. Create an object model, they said, and support the interfaces needed so that any scripting language can manipulate that object model. Is Python your preferred glue language? Perl? JavaScript? Doesn't matter. Any of these, depending both on your inclinations and on the circumstances at hand, may be the right choice for a particular job.

Fred Cantwell:

But what is there to glue? By burying everything under APIs and remaining "agnostic", MS has not grown the kind of culture that other platforms have. Sin of omission in my opinion.

Mark Wilcox:

Microsoft is of course the saint of closed, proprietary source. But they have, as Jon pointed out, a documented, scriptable component infrastructure. I mean, IE beat Netscape by several years with an embeddable, scriptable browser. Yes, Mozilla will enable the same thing, but the key is that IE has been doing this for years.

Right. And there's a bigger story which predates IE. By focusing on a COM-based component architecture, Microsoft willed into existence a whole industry built around packaged components. One excellent example is Visio, an application but also a component that's used by all sorts of third-party apps.

Fred Cantwell:

A search on "Visio" and "embed" show almost nothing interesting on DejaNews. What are real people doing with all of this awesome stuff?

Maybe .NET will change things. But that is too new to tell. And MS has shown it can change the rules any time it suits them, so it's a wash until MS tilts the box. I just don't think the kinds of folks who need to exploit this are even paying much attention to MS any more.

Fair question and comment. It had been a while since I checked on what's been happening in this area. I looked around, and found a site called visiopartners.com. There, I found a list of about 80 "solution providers" -- companies who build line-of-business applications around Visio. Here's one I picked at random: http://www.ycinc.com/.

Apparently these folks sell a packaged app called IMAP, for managing network cabling. It leverages the Visio componentry for its diagramming, but constructs a specialized application around that componentry. At a glance, the app does things like tie the objects in the diagrams to a SQL database.

Many of the companies on that list are doing something similar, each in their own market niches. Individually, none of these is earthshaking -- unless of course you happen to inhabit one of those niches. But collectively, it adds up to a rather important phenomenon.

James Power:

Isn't this exactly the power we are trying to attain? I wonder how may of the 80 products you mentioned would have existed if they had to write the Visio underlayment as well as their niche specific behaviors?

Precisely. There is, of course, a flip side to the story. The COM-based component architecture has tended to be somewhat brittle:

Pat O'Connell:

Unfortunately, Visio lacks something in its diagramming capabilities. I'm working on an engineering program that generates hierarchy trees. The trees aren't much use unless one can put those trees in a printed report, a document, a Web page, or whatever. We found out that Visio prints its diagrams without any control over formatting at all (no margins, for instance), splits the nodes of a tree across pages, etc. Apparently the Visio people didn't think much about how someone might use the charts generated by their program.

So we're using another diagramming package for the application. Its reporting capabilities are very good--even prints numbered connectors automatically when a diagram is printed on more than one page.

When you hit the brick wall with a closed-source component, you're just stuck. And this is where the .NET common language runtime (CLR) may make this game a lot more interesting than it already has been. For starters, it blurs the historical distinction between compiled languages (fast, but brittle) and interpreted languages (slower, but more flexible). Whether you write in Perl, or Python, or C#, it all ends up running as native code. (For more details, see this excellent interview with Anders Hejlsberg, C# architect and before that, inventor of Turbo Pascal.) This approach will, I hope, help to legitimize the use of productive -- and memory-safe -- "scripting" languages to develop the kinds of components (or, synonymously, web services) that are becoming the basis of the networked economy.

There's more. Because components meet on common ground in the CLR, and because the .NET environment provides rich metadata descriptions of components, you don't need access to a component's source to extend it, and you can do this in any .NET language.

.NET from the Linux and open source perspective

The .NET initiative is, admittedly, rather theoretical at this point. There's always going to be an impedance mismatch when mapping languages into the CLR. And of course, from the open source perspective, there are huge questions about whether, and if so in what form, the CLR may appear on Unix/Linux.

At least this much is clear, though. Forget about .NET for the moment. The language neutrality that already exists in the Microsoft space is something that the Linux and open source worlds could really use. Sure, we have -- for example -- mod_perl and mod_python for Apache. But a great deal of effort was invested in making these things available. In the case of mod_perl, extraordinary and heroic measures were needed on Doug MacEachern's part to make this amazing piece of software. As a result, mod_perl is rather idiosyncratic.

Heroic measures should not have been needed. Apache really ought to have, not just a request-processing API that can be bound once per programming language, but something akin to the ActiveX scripting interface that would solve the problem once for all programming languages that want to use Apache's request-processing services. (Were this the case, integration of Zope with Apache -- to take just one example -- might be considerably less the headache than it currently is.) Likewise Perl and Python ought to plug into the other end of that same standard scripting interface on Unix/Linux, as they do on Windows thanks to the efforts of ActiveState. That would mean that not just Apache, but any scripting-interface-compliant Unix application could be used by any scripting-interface-compliant language.

The union of the Perl and Apache should seem like an ordinary, not an extraordinary, thing. There is, to be sure, movement in the right direction. In an influential essay entitled Let's Make Unix Not Suck , Helix Code's Miguel de Icaza, the principal architect of GNOME, challenged the Unix community to move beyond its 1970s component technology (pipelined processes, text filters) into the modern era of component software. As Miguel points out, major Unix applications such as Samba, Apache, ftpd, and ssh share essentially no code beyond the primitive facilities in the standard runtime library, libc.

The GNOME solution to this problem is Bonobo, built atop ORBit, a high-performance CORBA-compliant object request broker. Bonobo's programming model looks a lot like that of Microsoft COM. Of course, in true Unix fashion, there's a divergent solution: Mozilla's XPCOM, modeled even more closely on COM. I've spoken recently to users of both Bonobo and XPCOM, and everyone likes both of them.

But here's the dilemma. The open source business model is, as I understand it, based on the delivery of network services. To do that efficiently, it's going to be increasingly necessary to compose services out of other services. This is the modern incarnation of the venerable Unix pipeline. How far would Unix have gotten if there were many incompatible ways of pipelining components? Microsoft's futuristic cross-language technology may or may not succeed. If it does, it may or may not find its way into Linux in a robust and open form. But .NET should, at least, galvanize the Linux community to agree on a modern component infrastructure.

---

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

This work is licensed under a Creative Commons License.