Home > Applications > App Development

Computerworld - 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 byproduct 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.