Tangled in the Threads

Jon Udell, November 17, 1999

Microcomponents, Macrocomponents, and Microsoft

Microsoft does a great job with microcomponents. The Net lives and breathes macrocomponents. It's the intersection of these two component strategies that will determine the future of software development and the Internet.

There's a chorus of voices proclaiming Microsoft to be an anti-innovator. In reaction, I mentioned in the BYTE.com newsgroups some examples of what I considered to be rather innovative things that Microsoft has done over the years, including:

Were these new ideas? Hardly. In both cases I would say that Apple was well ahead of Microsoft. Hypercard, which was both a hypertext system and a GUI-driven scriptable programming environment, may be one of the biggest blown opportunities in the history of software. Its notion of pluggable XCMDs and XFCNs -- binary components that could be assembled in the Hypercard scripting environment -- predated VBXs by at least five years. Apple's Open Scripting Architecture likewise predated ActiveX scripting by a considerable margin.

But it was Microsoft that made these technologies relevant to significant numbers of developers. This was a major achievement although, arguably, "innovation" is the wrong word to describe it. So I asked:

What is the word for:

"identifying a strategic technical priority, and executing the plan using an effective mix of technical and marketing resources"

Whatever that word is, that's what Microsoft is good at. They throw a lot of things at the wall, to be sure, but some of them stick, and some of the things that stick are worth having been stuck there.

Franck Arnaud suggests the term "process innovation":

Software companies hardly ever innovate. Desktop PCs use a handful of interesting fundamental algorithms, almost all coming from fundamental research in universities.

So it seems to me that the relationship between MS and innovation is hardly relevant. The point of a (product) monopoly is that it allows the monopolist to make more profits than if there was product competition, even with zero innovation products.

Most of the value of Windows is not in the implementation but in the fact that there are lots of applications, that is it is the majority platform (the network effect). So the Windows license fee is more like a club membership fee (the right to be a Windows user) than paying for an actual product (the OS).

Network effects

The hegemony of the basic Windows API created one kind of network effect. Developers who were willing to target that API, and forget about MacOS or NextStep or Presentation Manager or X-Windows, were rewarded with lower development costs and a lucrative market.

But there was another strategy at work too. Microsoft saw clearly that conventional software development -- that is, employing C and C++ programmers to write directly to the Windows API -- was never going to meet the demand for applications. It articulated what I have always believed to be the correct response to this problem: a two-tiered approach in which a relatively small number of component builders, working in C or C++, produce components. These are used by a relatively large number of component assemblers, working in script languages, to produce customized applications.

These microcomponents, as I'll call them, create another kind of network effect. Here the relevant standard is not the Windows API, but the COM interfaces which ensure that your component will plug into my container.

Partly because it was -- rightly -- focused on this strategy, Microsoft at first failed to notice the emergence of a very different network effect. I noticed it myself, for the first time, when I connected the BYTE web site to a partner site where readers would punch in "bingo card" information in order to request information about products mentioned in the magazine. Initially, the HTML form was hosted on the partner site. This was inconvenient, since I sometimes needed to change the look of the form. Then I realized something which, though we today take it for granted, is still quite remarkable. I could host the form on my site, and point its ACTION statement at the partner site. The partner site was, in fact, a macrocomponent which presented an HTTP interface.

I've written elsewhere about the general notion of the Web as a library of macrocomponents, and about XML-RPC as a way to elevate this game from HTML screen-scraping to a more rigorous level.

The relevant macrocomponent standards are neither OS-level APIs, such as Win32, nor microcomponent-level APIs, such as COM. Rather, they are an emerging class of standards -- such as XML-RPC, SOAP, and WebDAV -- which layer XML on top of HTTP. In this model it doesn't matter if the caller is Windows, or Mac, or Linux, or any other kind of HTTP-aware device, and it doesn't matter what OS the callee runs either.

Where microcomponents and macrocomponents intersect: the browser

In macrocomponent terms, component builders don't produce packages of bits that you download and plug in. Rather, they produce services that you access through the Internet. But the two-tiered model remains in effect. Component assemblers still patch together applications using scripting languages -- sometimes, though not necessarily, the same scripting language (Visual Basic) that's typically used to assemble microcomponents.

The macrocomponent model works remarkably well for the class of applications that can be delivered into an HTML or HTML/JavaScript browser. This is a large and important class of applications! The vanilla browser remains the workhorse of the Web. It's our user interface to the network services that matter -- ordering books, reserving airline tickets, tracking packages.

Still, there's no getting around the fact that the impoverished HTML widget set is due for an overhaul. The browser needs pluggable microcomponents that can interact in richer and more flexible ways with remote macrocomponents. Web culture has, so far, proved surprisingly resistant to the two dominant solutions proposed thus far: Java, and ActiveX.

This situation cannot, and will not, continue for much longer. But the non-Windows camps don't seem to have convincing solutions yet. Netscape's browser share is rapidly eroding. Mozilla is desperately late precisely because it has heroically tackled the microcomponent problem, while refusing to sacrifice OS-independence. At this point the future of Mozilla, and its XPCOM technology, is unclear. Linux, on another front, is pursuing a CORBA-oriented microcomponent strategy -- but the KDE and GNOME desktop environments mean different things by this. And whether Linux in any form will capture significant desktop share is, also, unclear. Finally, Java has its own version of microcomponents (beans) and macrocomponents (enterprise beans), the relevance of which -- on the desktop machines where the vast majority of computing actually occurs -- is again unclear.

So what's in store? Are we headed for a one-browser world, in which the MSIE microcomponent architecture dominates the desktop just as Win32 and COM did? Will Mozilla reassert itself as a contervailing influence? Will client-side Java emerge from its long gestation and play a larger role on the desktop? I'd give a lot, right now, to know the answers to these crucial questions.

The macrocomponent model seems, at this moment, unassailable. I can build network services using COM and ASP, or Java servlets, or mod_perl, or Cold Fusion, or Zope. These can all talk seamlessly to one another, and to browsers, because the underlying TCP/IP and HTTP infrastructure is an open, multiply-implemented commodity.

But the browser has to evolve a richer microcomponent architecture. That, in turn, will begin to influence what macrocomponents are and can do. Consider one crucial piece: data-bound widgets. Today there is no standard data-bound grid in HTML. There ought to be. When there is, it won't exist in isolation on the client. It will require intricate client/server coordination.

Some other microcomponents that ought to be standard, DOM-aware, scriptable features of browsers: XML-oriented forms and rich text editors, and tree controls. Will these things be open, multiply-implemented commodities, or will they be only available in MSIE? In the infamous Halloween memo, the damning phrase was "de-commoditization." To the extent that macrocomponents marginalize the OS substrate, I worry less nowadays about the effects of a Windows API hegemony. But since the sweet spot is the intersection between browser-based microcomponents and Web-based macrocomponents, I do worry -- a lot -- about the "de-commoditization" of the browser and its microcomponent 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 from O'Reilly and Associates.

Creative Commons License
This work is licensed under a Creative Commons License.