Through its history, there have been many descriptions of OLE, ranging from the sublime to the ridiculous. At some time or another, OLE has been identified with many of its constituent technologies, such as Compound Documents, visual editing, OLE Automation, the Component Object Model, and OLE Controls. You might have seen such narrow identifications in magazines, newsletters, and books.
Each of these definitions is partially true because OLE includes all of them, but each identity misses any conception of a unified whole. A complete definition of OLE must include not only these large and visible technologies but also the minutiae that fill the gaps between them. Furthermore, the definition cannot be rigidly based on the composition of OLE at the time this book was written because Microsoft and other industry groups are continually creating new OLE technologies that are not covered in the pages of this book. Further still, OLE allows software developers to arbitrarily extend the architecture. Therefore, our definition—our framework for understanding OLE—must be flexible to accommodate new additions.
With these characteristics in mind, I define OLE as follows: OLE is a unified environment of object-based services with the capability of both customizing those services and arbitrarily extending the architecture through custom services, with the overall purpose of enabling rich integration between components.
Stated another way, OLE offers an extensible service architecture, and in addition to the architecture, OLE itself provides a number of key customizable services, one of which in turn provides for the creation of custom services of any complexity that extend the environment within the same architectural framework. All services, regardless of their complexity, point of storage, point of execution, and implementation, are globally usable by all applications, by the system, and by all other services.
Note that OLE is not a technology for writing every part of an application as the Win32 API is. Where you use the Win32 API to write code and use system resources, you use OLE to share those components with everyone else as well as to access the shared components from the rest of the world.
The collective term used to refer to all services is component. To be completely precise, a service is really made of one or more components, but most often a component is a service in itself. In any case, a component is itself made of one or more objects, where each object then provides its functionality and content through one or more interfaces. These interfaces, in turn, each contain one or more feature-specific member functions. It is through these member functions that one accesses everything a component can do. So while there may be simple memory-allocation services that have one component, one object, and one interface on that object (with a handful of member functions), other components might have several objects that each have several interfaces through which they expose a great number of features.
Component software is the practical and consumer-oriented realization of the developer-oriented principles of object-oriented programming. Component software is the vision of a computing environment in which developers and end users can incrementally add features to their applications simply by purchasing additional components, rather than by writing such components themselves or by finding more feature-laden monolithic applications.
OLE's life purpose, if you will, is to enable and facilitate component integration and component software. This makes it possible for pieces of applications to talk to one another and makes it possible to create software that involves many pieces of different applications, which is otherwise impossible to do inside a single monolithic program. As a concrete example, consider the creation of a compound document whose contents come from a variety of sources (text, graphics, charts, tables, sound, video, database queries, controls, and so forth). Providing this capability in a nonextensible monolithic application restricts the types of information that one can put into a document to only those types that were known to the application at build time. If a new type of content becomes available, as frequently happens, this application would have to be redeveloped, recompiled, and redeployed—a very slow and costly venture—in order to incorporate new content. In contrast, in the component software environment, the application that manages the compound document can allow the user to use content from any available component. If the component environment is designed to be extensible, as OLE is, newly installed components become available immediately to all existing components and applications. Thus, without modification of the document application, a new type of content is usable as soon as the component is installed.
OLE version 1 was created back in 1991, under the now obsolete title "Object Linking and Embedding," for the express purpose of enabling exactly this sort of compound document integration. OLE version 2 was planned originally as performance improvements and enhancements to the functionality of OLE 1, but it grew beyond the boundaries of compound documents into a much more generic service architecture. As we'll see in this chapter and throughout this book, there are many other meaningful and interesting ways to integrate components other than compound documents, such as performing a drag-and-drop operation or controlling an application programmatically. Certainly compound document technology is still part of OLE and makes a sizable topic for this book, but it no longer enjoys exclusive use of the OLE name. OLE is thus no longer an acronym for Object Linking and Embedding but is rather the name of Microsoft's component integration technology.
You may also notice that OLE is no longer given a version number. The first edition of this book was called Inside OLE 2, but this edition is just Inside OLE. The reason for this is that OLE 2 implies that there will be an OLE 3. There will not be any such product. As an extensible service architecture, new features and technologies can be added to OLE within the existing framework without having to change the existing framework! For example, OLE Controls, a major addition to the architecture, was released more than a year after the original release of OLE 2, but it required no changes to that original technology. Instead, OLE Controls simply builds on and enhances what existed before. This will continue to be true as Microsoft and others add technologies in the future—what exists today will retain its vitality.