In a world of interconnected networks and Web services, computing workloads are increasingly being split among clients and servers that are far apart in both distance and functionality. This means it's essential for computers to be able to talk to one another and use data generated by another machine as input. This isn't a new situation; in fact, it's the logical extension of how applications have been developed for years.

In their attempts to achieve greater interoperability and efficiency, developers have created subroutines and procedure calls, object-oriented programming and libraries of reusable software. If they can avoid it, developers rarely create applications from scratch. Instead, they try to take advantage of existing hardware infrastructure, tools and software, as well as previously created software components, all to rein in the time and cost of development and deployment. While these approaches go by many different names, we'll refer to them as "component software." Indeed, one can think of Web services as just a more widely distributed form of component software.

Because Windows has become the primary desktop operating system, and because Microsoft Corp. has tried to extend that monopoly to the server world, it's hardly surprising that the company has for years offered its own set of products and standards for component software. Among the oldest of these, and thus the most widely used and best-known, is the Component Object Model (COM) and its network-savvy offspring, distributed COM, or DCOM.

COM's Binary Essence

The real value of component software for developers was that it allowed them to use binary (i.e., machine-code) modules, not source-code libraries, as was the case with most development environments. COM defined an application programming interface that allowed diverse components to interact. As long as components used a Microsoft-specified binary structure, they could be written in different languages and still interoperate after they had been compiled. COM enabled the development of application services using compound documents, custom controls, interapplication scripting, data transfer and other types of software interactions.

What's in a Name?

The history of Microsoft component software is complex because the company tends to change its approach and structure every few years, renaming and rebranding technologies. Here's a quick rundown on how component software has changed over the years:

We begin with a technology for compound documents called Object Linking and Embedding (OLE), which was built on top of Dynamic Data Exchange and Visual Basic Extension (VBX) controls from Visual Basic 1.0. (The abundance of acronyms is an unfortunate by-product of this subject.)

In 1992, Microsoft introduced Windows 3.1, and OLE came with it onto every desktop. This was followed the next year by OLE 2, and in 1994, OCX controls were introduced to succeed VBX. At that time, Microsoft stated that OLE was the name to be used for all of its component technologies.

However, Microsoft soon renamed some parts of OLE that related to the Internet as ActiveX, a moniker that gradually subsumed all the component technologies. OLE then reoccupied its role as a compound document technology, used mainly in Microsoft Office. COM was first implemented in Windows 95.

In 1996, as networking and networkable applications grew in importance, Microsoft announced its DCOM alternative to the Common Object Request Broker Architecture, or CORBA. DCOM first appeared in Windows NT 4.0 with tools to help build client/server applications that spanned both the corporate network and the Internet. In September 1997, Microsoft once again changed the name of its entire component framework—to COM.

A couple of years later, when it introduced Windows 2000, Microsoft renamed COM to COM+, signifying substantial changes. COM+'s main attraction was that IT could run it in component farms managed by Microsoft Transaction Server. A properly made component could be reused by making new calls to its initializing routine without having to unload it from memory. Components could also be called from another machine, which was previously possible only with DCOM, so Microsoft pretty much dropped DCOM as an independent concept. But not even COM+ had much longevity. Microsoft soon launched its .Net initiative, a hasty (and often hazy) framework that almost entirely replaced the COM technology. There is limited backward compatibility—.Net can use a COM object by implementing what's called a "wrapper"—but Microsoft made it clear that for new systems, COM was to be dropped entirely in favor of .Net.

.Net includes "smart" client application software and operating systems, smart devices, Web services that can be combined with other Web services or used directly with smart client applications, a server infrastructure and an environment (Visual Studio.Net) that directly supports a number of development languages through .Net's Common Language Runtime.

Recent Changes

Despite their disavowal in favor of .Net, the technologies of COM and DCOM are still alive and well, even at Microsoft. In the forthcoming Service Pack 2 for Windows XP, for example, Microsoft will implement two big changes to DCOM. It introduces computerwide restrictions that provide an additional access check against an access-control list each time a COM server is activated, called or launched. SP2 also introduces more granular COM permissions, giving administrators greater flexibility in controlling a computer's permission policy.