As is the case with most significant technologies, COM+ was not invented overnight by a lone caffeine-crazed developer. It is the result of multiple paths of technological evolution, as shown in Figure 1-2. To better understand the underpinnings of COM+, let's examine the technologies from which it evolved.
Figure 1-2. The evolution of COM+.
Microsoft's MS-DOS operating system was developed for a very limited computer (by today's standards). As Intel advanced with more powerful CPUs, such as the 80286 and 80386, Microsoft began to envision the possibilities of running multiple applications concurrently. Then, with the advent of the cooperatively multitasking Windows environment, Microsoft realized that users wanted to exchange data among various applications. The clipboard and Dynamic Data Exchange (DDE) initiatives were two of the first interprocess communication facilities that Microsoft incorporated into Windows. DDE was a message-passing service designed for use by developers to incorporate data exchange facilities into their applications. However, DDE was a rather complex protocol to follow, and consequently few applications aside from Microsoft Excel implemented it successfully.
The clipboard provided users with a primitive but easily understood paradigm of cut, copy, and paste operations. You could use it to create compound documents—documents containing different types of content. (For example, a word processing document could contain text, bitmaps, charts, and sound clips.) Suppose that you wanted to create the 1992 annual report for your company using one of the first versions of Microsoft Word for Windows. First you probably would have written the text describing the state of the company and the progress made over the prior year. Then you might have loaded Excel to create a spreadsheet with figures on the company's performance. Finally, you might have selected some cells in the spreadsheet, copied them to the clipboard, and pasted them into your Word document. Without the clipboard, you might have had to print your Word document and Excel spreadsheet separately and then literally cut and paste them using scissors and glue.
The fact that the clipboard service was both easy to implement from the developer's perspective and easy for the user to control made it an immediate hit. The clipboard continues to be popular in today's Windows applications. Nevertheless, the shortcomings of the clipboard quickly became apparent. The basic problem with the clipboard as a means of creating compound documents was the lack of intelligence involved in the data transfer. For example, after you created your company's annual report using the clipboard, you might have discovered a need to update some of the figures in the Excel spreadsheet. This required that you once more select, copy, and paste new figures into your Word document.
The original concept of object linking and embedding (OLE) grew out of Microsoft's effort to address this problem. OLE was first released with Microsoft Windows 3.1 in 1992. The original idea of OLE was to provide an improved mechanism for dealing with compound documents. For example, a smart compound document could either embed the Excel spreadsheet data in or link it with the Word document. Whenever linked figures were updated in the spreadsheet, the new data automatically found its way to the Word document. Also, you could open and edit the linked or embedded figure in Excel by double-clicking it in Word. This capability was a great boon to users, although few understood how it operated. In fact, DDE was used internally by the first release of OLE as the interprocess communication protocol. OLE contained some very interesting ideas, foremost of which was the concept that compound document objects supported by different applications could work together in the creation of a "super-document." The OLE designers continued to broaden and refine their ideas until they began to view compound document objects as software components—small, self-contained software objects that could be plugged into an application, thereby extending its functionality.
OLE 2, released in 1993, further refined the linking and embedding capabilities and extended them with in-place activation. In-place activation, sometimes called visual editing, allows one application to take on the appearance of another, enabling the user to edit all of the data contained in a compound document without leaving the context of a single window. Although most developers did not realize it at that time, or for a long while after, the architecture of OLE 2 was built around the revolutionary idea of component-based software. In the long run, this has proved to be by far the most important contribution of OLE 2. Over the years, OLE has faded into the background while COM has taken center stage.
Most software projects are still designed around the idea of producing a behemoth that encompasses every feature any user might conceivably desire. The trouble with this model of software development is that applications become more fragile as they grow. If it is difficult to have a complete understanding of an application containing 100,000 lines of code, it is all but impossible with 1,000,000 lines. Even a small modification in an application of that size requires extensive retesting of the entire system. Often what appears to be an innocuous modification in one section of code does damage in many other locations.
COM acts as the "glue" between components, enabling unrelated software objects to connect and interact in meaningful ways. These components can then be reused in many environments on both the client and the server. For example, a particular business component can be used in a desktop application as well as by a Web application running in Microsoft Internet Information Server (IIS). COM lets you group objects into distinct components so that your applications consist of replaceable pieces that provide specific functionality.
Building a system based on interoperable components doesn't mean that the user can't have an icon on the desktop to launch the application. Even applications built from components must give the user the illusion that the application is a single unit. For example, let's examine the architecture of Microsoft Internet Explorer. The shell is a simple ActiveX document host, and the actual parsing and rendering of HTML is done by an ActiveX document component that is loaded whenever the user navigates to a Web site. If the Web site contains an ActiveX control, the control is downloaded and installed. This component-based architecture keeps every part of the application focused on a specific job. COM enables different teams of developers, perhaps using different programming languages, to develop components for one application. The components work together seamlessly so long as everyone plays by the rules of COM.
Let's review some of the challenges faced by the software industry that led Microsoft to develop COM. The continuous evolution of computer hardware and software has brought an increasing number of sophisticated applications to users' desktops and to networks. Such complex software has created a commensurate number of problems for developers:
Does COM fix all of these problems? As the nature of the difficulties described here suggests, no one idea can single-handedly address all of these issues. But as you'll see in the following sections, software that follows the COM architecture can better meet these challenges. COM+ itself has evolved from a combination of classic COM and Microsoft Transaction Server (MTS), which is described later in this chapter1. For the time being, COM+ embodies the glorious culmination of a long evolution of ideas that began with OLE.
Back in the 1980s, simply connecting several computers together over a LAN was a major achievement. For the PC to be accepted in mission-critical applications there needed to be a distributed support system analogous to that of a centralized operating system. This approach, however, would not go anywhere unless industry groups cooperated on the creation of standards. In the world of mainframe computers, standards were a nonissue; software was written for specific hardware. (In those days, IBM's computers were not expected to talk to other companies' computers.)
In the late 1980s, various industry groups tried to get enough companies to define standards and then agree to abide by them. One of the groups, the Open Software Foundation (OSF), became an industrywide consortium with a mandate for defining standards in a broad spectrum of areas. The OSF members decided to address the issue of distributed computing. Out of this effort grew the specifications for the Distributed Computing Environment (DCE), an environment for creating distributed systems. To this end, DCE began designing a comprehensive and integrated set of tools and services to support the creation of distributed applications, in a manner analogous to the support offered by the operating system in a centralized environment.
One outcome of the DCE effort was a specification for communicating between computers. This specification, known as Remote Procedure Calls (RPCs), allows applications on different computers to communicate. COM+ uses RPCs for its intercomputer communication.