Embrace and Extend

Dot-NET is Microsoft's next generation framework for developing Internet-centric distributed applications. Why should this matter to Linux developers?

.Net Opener

In his influential manifesto, “Let’s Make Unix Not Suck,” GNOME’s Miguel de Icaza explains why Linux needs a standard component model that allows for richer inter-application communication than what is provided for by the command line-based 1970s-vintage pipeline. He goes on to describe how GNOME’s new Bonobo component architecture attacks this problem, using a CORBA object request broker (ORBit) to implement a modern component system that functions similarly to Microsoft’s COM. Meanwhile, the Mozilla project has converged on a similar solution in the form of XPCOM, their own open source cross-platform component system, also patterned closely on COM.

Why is it that so many open source projects are developing similar solutions to the same set of problems? The answer is simple — as software systems grow larger and more complex, programmers require more modular ways of developing software. Component systems allow programmers to work on pieces of manageable size, but still enable those pieces to be joined together to form much larger and more complex structures that would otherwise be impossible to create or maintain.

This same problem faced Microsoft in the early 1990s, and it led them to create their own component architecture, which they named COM (Component Object Model). Over the past decade, Microsoft has continued to evolve their component system, and this evolutionary path has led them to their next-generation component architecture, which is called .NET.

Reusable component software, of course, is everyone’s future. The Net economy will be based on componentized services — both on the desktop, and out in the cloud, where new services will be made by combining and specializing existing ones. The name of the game is to build and deliver such services in the most flexible and efficient way.

From a Linux perspective, it’s easy to dismiss .NET as yet more Microsoft imperialism. However, turning a blind eye to Microsoft’s initiatives puts us on thin ice. The fact is, we’re all in the same boat now. The Internet economy will run on interoperable network services. Open source software, to its everlasting credit, laid the foundation: sockets, text-based protocols such as HTTP. But as de Icaza argues, component construction and reuse on Unix/Linux lags behind what is now routinely achieved in the Microsoft space. Now, with .NET, Microsoft aims to raise the bar higher still.


.Net Piece1

Six years ago, in a BYTE Magazine cover story (“Componentware,” May 1994), I argued that object-oriented programming hadn’t produced much in the way of software reuse. Meanwhile, Microsoft’s then-primitive component architecture (first VBX, then OLE and OCX, later ActiveX) had unexpectedly jump-started a thriving component software industry. There were two key reasons for its success.

The first was the development of a language-agnostic interface. With Bonobo and XPCOM, Linux is finally moving in this direction. In fact, Eazel Co-founder and Software Wizard Andy Hertzfeld has bet the future of Eazel’s GNOME-based Nautilus shell on Bonobo. According to him, “[Bonobo] is now crossing the threshold from theory to practice.” But as yet, neither Bonobo nor XPCOM has changed the grim fact that, as de Icaza notes in his essay, the canonical Linux applications share little more than the primitive facilities of libc.

When applications are bound to languages, in order for those applications to be reused as components such bindings must occur on a per-language, per-application basis. One open source project binds Perl to Apache. Another binds Python to Apache. Yet more projects are spawned when it’s time to bind another language to Apache, or to bind Perl or Python to another application. It’s worth pointing out that this is the exact problem that the GNOME project has tried to address by using GTK as their underlying toolkit. Because GTK has multiple language bindings, it is possible to write GTK applications using many languages. Still, GTK is a GUI toolkit, not a component architecture.

The second reason for Microsoft’s success with components was their articulation of single, clear strategy. The COM-based standard evolved over the years, to be sure, but Microsoft’s message — “Write to COM” — was always recognizably the same. Many heeded the call. As a result, Windows applications now routinely package themselves as “object models” made available to scripting languages by way of a standard interface. This meant, for example, that when SoftQuad shipped XMetaL (an XML editor) last year, the application was customizable by any script-interface-compliant language — including VBScript, JavaScript, Perl, and Python. There didn’t need to be a Python-XMetaL project, and a Perl-XMetaL project, and so on.

It’s ironic that Unix culture, which invented the component methodology and still understands it far more deeply than Windows culture does, never took it to the next level. Pipes and sockets are great stuff, I hasten to add, and I use them every day. But to call methods and pass complex data structures across process and language boundaries, you need something like a COM (or CORBA, or SOAP) wrapper.

.Net Piece2

The beauty of this approach is that it equalizes languages. A Windows programmer can call a COM object as easily from Perl as from Python, with no special fanfare, and can even implement a COM component in Perl or Python. For all of its advantages, however, this scheme can be awkward and brittle. It’s awkward because the component implementer has to create and maintain the COM wrapper. It’s brittle because the component user can’t extend it: there’s no implementation inheritance, no easy way to override the component’s methods.

The result is significant, even revolutionary, levels of software reuse, but at the expense of object orientation. That’s a reasonable tradeoff for Bonobo and other CORBA-based schemes, for XPCOM, and for SOAP — the XML-based Simple Object Access Protocol which, as we’ll see, plays a crucial role in the emerging architecture of network services.

But, at the core of .NET is a CLR (Common Language Runtime) which, in the broadest terms, marries the programming convenience of OOP (Object Oriented Programming) with the deployment advantages of COM. Whatever you think of Microsoft, this is an historic convergence.


Because the .NET campaign is advancing on so many fronts — user-interface, data management, Web-page templating, middleware — it’s easy to lose sight of the forest for the trees. From a Linux perspective, a lot of the initiatives that comprise the .NET whole look like more of the same. If you haven’t needed to care about Microsoft’s evolving data access strategy, for example — a confusing litany of acronyms that goes ODBC, DAO, OLEDB, ADO — then there’s no need to get lathered up about ADO.NET. If MySQL or JDBC are meeting your needs, then fine.

It’s the same with the rest of this stuff. Microsoft developers will suck it up, but open source developers — who have different and arguably superior options — generally won’t. However, as the Bonobo and XPCOM projects get further along the path of implementing their own component systems, it is worth taking the time to learn from Microsoft’s mistakes. Microsoft is also moving towards a number of fundamental objectives that we should examine carefully if we want to improve the state of component technology on Linux.

Take the ideas in com to the next level

One of the reflexive reactions to the .NET announcement was: “Excuse me? I’m supposed to care about something that requires Windoze and its proprietary COM subsystem?” In fact, the .NET framework (though not yet ported from Windows) doesn’t require, or use, COM. It recreates the packaging and deployment aspects of COM in a new, and smoother way.

A method, written in any .NET language (C++, Perl, Python, C#, Cobol, etc.), simply is a component. The method signature defines the component interface, which is available to other methods packaged into the same .NET “assembly” (unit of deployment), and indeed to methods outside that assembly by way of SOAP.

So what lesson did Microsoft learn that it is trying to apply in this case? KISS — Keep It Simple, Stupid. While this aspect of .NET will definitely make life significantly easier for Windows programmers, this particular initiative only recaptures a level of simplicity that Linux developers have always enjoyed.

Separate domain knowledge from language skill

Lots of blood has been spilled in the open source community over the “my programming language can beat up your programming language” issue. But If you’re spending your time debating the merits of Perl vs. Python, you’re missing the point. Both are productive languages, with unique strengths. A software project shouldn’t have to recruit a Perl hacker, or a Python hacker. It should recruit people who know how to build e-commerce systems, or manage content, or create user interfaces. Their knowledge and skills, though expressed through the medium of programming languages, are really more general qualities.

Separating domain knowledge from language expertise is a long-term goal. Success is far from certain. Still, it’s hard to argue against the notion that software’s primary goal should be to encapsulate domain knowledge (and supporting services) independent of specific language skills.

Promote “scripting” languages to the first rank

When people first saw that the Web was about software as much as publishing, they reached for tools to create Web-based applications. Perl came most easily to hand, and to this day the phrases “CGI programming” and “Perl scripting” are synonymous for many people. Since then, the notion of scripting has warped almost beyond recognition. Is CMP’s TechWeb, which delivers tens of millions of dynamic pageviews monthly, using Apache, mod_perl, and HTML: :Mason, really “just” script? What about Zope, a full-blown Web application server and object database written almost entirely in Python? Scripting is no longer the handmaiden of C programming. Increasingly, it’s how we build serious and highly-engineered Web services. And why not, given the dramatic productivity of scripting languages?

One reason for scripting’s second-class status has been the overhead of bytecode interpreters. In .NET, as in Java (or Perl, for that matter), source code is compiled to a stream of instructions (the intermediate language, or IL). But the big difference with .NET is that the instructions are never interpreted. They’re always further transformed to native code for execution. That can happen when an assembly is first developed, or when it is deployed, or “just in time” on a per-method basis when it is run.

Beyond the raw performance of native code, there are subtler ways to make things go faster. Dick Hardt, CEO of ActiveState (a Vancouver based company that is porting Perl and Python to Microsoft’s .NET platform) points out that with access to the IL for a whole assembly, new kinds of global optimization become possible. The IL compiler can regard a Perl-based service with an embedded C++ module as a single compilation unit, and optimize it accordingly.

There is, not surprisingly, some impedance mismatch when mapping dynamic languages into the .NET runtime and its common type system. Hardt regards his company’s prototype implementations of Perl.NET and Python. NET as research projects that will help to clarify how dynamic languages and .NET can better cooperate. “Perl and Python are being rewritten anyway, partly to be better at creating components,” says Hardt, so it’s a good time to factor .NET into the equation.

How well all this will play out in practice remains to be seen. The distinction between scripting and compiled languages has already been eroding, though, and this is a trend that the advent of .NET will accelerate.

Make web services safe, reliable, and automatic

Hardly a week goes by without another CERT advisory warning of a security hole in a major network application. Often, the cause is a buffer overflow. Memory-safety is one of the reasons that Java has found increasing favor as the implementation language of choice for network services. Java’s robust exception-handling is another. The .NET runtime promises to extend these same benefits — safe memory, exception handling — to every .NET language, and to assemblies made from multiple .NET languages. This is an idea that helps everyone. Why should you be forced to use Java to enjoy these benefits? Why not use your language (or languages) of choice? Note, too, that source-level debugging of a multi-language assembly is possible. That’s tantalizing, given that most real-world Web services today are already, in effect, multi-language assemblies (e.g., a binary module used from a Perl script which is in turn called from Apache).

So what do we mean when we say that Web services should be automatic? Most of today’s Web services target the browser directly — that is, they receive CGI-style form-encoded data, and emit HTML. With HTML screen-scraping it’s possible to use Web services as components, but it’s been clear for some time now that there’s a better way.

Web services should, primarily, receive and emit XML, so they’re guaranteed to work effectively as components. Mapping form-encoded data to XML inputs, and XML out-puts to HTML, is secondary — and thanks to XSLT, straightforward. Separating business logic (what the service does) from display logic (how it talks to the browser) is just a good practice that every Web site should follow. Hardly any do, though. An Amazon book page, for example, should offer an XML interface that delivers its information in a regular and self-describing way. That would enable other sites to compose Amazon-aware services that won’t break with every Amazon redesign.

How you express interfaces in XML matters not so much. That you do so, in one way or another, matters enormously. Dave Winer’s XML-RPC was an early technique, and remains incredibly useful. SOAP, XML-RPC’s “big brother,” is another, and it’s woven right into the fabric of .NET. Every .NET method is a Web-callable SOAP method. We’ve had a glimpse of the power of this approach in Zope, where every interactive URL has an alternate identity as an XML-RPC method. But only the Web-facing parts of a Zope application are callable in this way. In .NET, everything can be. It’s automatic. The act of programming is indistinguishable from the act of building Web-callable components.


We’ve already said that the Internet economy will run on interoperable network services powered by component technology. However, in order to build scalable Web services, developers require robust middleware solutions as well. Microsoft understands this, and so the bundle of technologies that is .NET also includes the middleware that is required to build, deploy and manage network-centric applications and services.

Though Linux has so far succeeded mainly as a server, it is currently weak in the area of major-league middleware. However, that situation is changing, in large degree because of Java and XML. Key Java/ Apache projects such as Tomcat (servlets, Java Server Pages) and Cocoon (XML content management and publishing) are strategic weapons in Linux’s quest to match Microsoft’s soup-to-nuts menu of server-side development tools. Even more so is Enhydra, an open source Java application server.

When developers need to make Web services scale to the stratosphere, they look for load-balanced transaction processing, resource pooling, message queuing, and service replication/failover. There are basically three ways to get this stuff:

  • Companies like IBM and BEA Systems sell really expensive middleware

  • Java application servers are a bit less expensive:

Because they now mainly agree on the J2EE (Java Enterprise Edition) standards, you don’t need to do so much proprietary coding to reap the benefits. In many corporate IT departments, scale-up of Web services is regarded as a solved problem thanks to Java app servers.

  • Microsoft bundles the middleware for the cost of Windows 2000

Given these options, you can see why Enhydra is such a big deal for Linux. And yet, Sun’s language imperialism rankles. Sun, in tying its platform ambitions so closely to one programming language, has “muddied the waters,” says Andy Hertzfeld. “The obvious technical response to Java,” he notes, “was a language-independent runtime, the only surprise being that it took so long.”

Linux and Java have made for somewhat uneasy allies, to say the least. The major reason for that, of course, is Sun’s proprietary hold on Java-the-platform. Still, there’s a flurry of Java activity in the open source world, albeit related more closely to Apache than to Linux. But if there’s so much philosophical angst over Java, why is it becoming so widely deployed on Linux? Well, aside from the previously mentioned middleware option situation, in the eyes of many open source developers, the enemy (Sun) of my enemy (Microsoft) is my friend.


Oddly, although Sun has never stressed the fact, the JVM (Java Virtual Machine) actually is in some sense a language-independent runtime. Sun beat Microsoft to the punch by about five years. As a result, there are quite a few open-source language projects that target the JVM, perhaps
the most notable being JPython. (See http://grunge.cs.tu-berlin.de/vmlanguages.html for a long list of languages that can compile to Java source, or directly to JVM bytecodes.)

The .NET initiative will likely prompt a reconsideration of the relationship between Java-the-language and Java-the-platform. Each of these facets of Java is, in its own right, impressively versatile. Their conjunction was partly an accident of history. To the extent that the combined entity impedes productivity and openness, people will find ways to route around these problems.

What’s at stake is much, much bigger than Microsoft vs. Sun parochialism. Software developers care about performance, language integration, and components. At the end of the day, they’ll find ways to bend Java and .NET to serve these needs.

Open source language pioneers, without any official support from Sun, have turned the JVM into a veritable language laboratory. So Java could become the vehicle for the working-out of a next-generation object/component solution. For Linux, progress along this path will require two things: better open-source JVMs, and agreement on a component model that’s as standard and universal as pipes and sockets.


It’s impossible to miss the tremendous amount of irony in this situation. Clearly .NET aims to out-Java Java. But the funny thing is that under the right circumstances, many Linux developers would welcome such a development. But just what would constitute “the right circumstances”?

Suppose, for the sake of argument, that a robust open-source implementation of .NET’s core technology were to emerge. How might that happen? One possibility is Corel, into which Microsoft recently injected $125 million to support what Corel CEO Derek Burney will only describe as “.NET-related development.” Another is IBM, which has repeatedly flexed its R&D muscle to advance various open-source efforts — including Linux, Apache, a myriad of Java projects, and SOAP. Or it might be a from-scratch project.

Microsoft is in the process of releasing the core .NET specs to ECMA (European Computer Manufacturers Association). ECMA is the standards body that specified ECMAScript, which sounds like a skin disease but is, in fact, the open-standards version of JavaScript. When C# and .NET were presented at a recent meeting of ECMA’s TC39 (technical committee 39, on scripting languages), the question arose: how much effort to implement a .NET compiler and runtime system? Answer (from Microsoft): two to four man-years, from specs.

Note, by the way, that Sun decided to pull Java back from ECMA’s standardization process even as Microsoft began submitting C# and .NET for consideration. This may seem an odd maneuver on Microsoft’s part, since it’s an article of faith in the open source community that Redmond doesn’t “get” the Internet standards process. At one point, that was probably true, but times change. Check out http://www.linux-mag.com/2000-09/trench_01.html for an analysis of Microsoft’s growing participation in the IETF process. Microsoft not only “gets” standards but is a leading implementer of some of the key ingredients of the Web-services recipe: XSL, SOAP and WebDAV.


Even before the US government weighed in against the Windows monopoly, it was becoming clear in Redmond that “ubiquitous infrastructure” can’t only mean Windows. Microsoft has huge businesses in tools and applications, and those businesses will inevitably refocus away from desktop applications and towards Web services.

Linux’s great strength is as a server, and specifically as a Web-services platform. Yet, as we’ve seen, Linux lacks the middleware it needs to reach the next level. Today, it compensates by leaning on Java. Advancing the state-of-the-art for JVM-targeted programming languages is one way forward. An open-source implementation of .NET could be another. In either case, the goal is to marry the two greatest themes in the history of software development: object-oriented programming, and components.

Linux and open-source developers should consider both approaches. It makes sense to continue to exploit Java in ways Sun never intended. And you know what? It may just also make sense to embrace and extend .NET.

Jon Udell, an independent author and consultant, runs the Linux Magazine Web site. He can be reached at udell@monad.net.

Comments are closed.