To reiterate our definition, 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. Since we now understand how components express their capabilities through interfaces, we can take a look at the individual technologies within the rest of OLE.
OLE as a whole (including recent and future enhancements) is made up of a number of Win32-style API functions (those with global names that are direct calls into system DLLs) as well as a large number of interfaces. Each interface expresses a certain feature through some number of member functions. OLE currently has no fewer than 120 API functions and no fewer than 80 interfaces that average 5 to 6 member functions each. A little quick math, and you end up with almost 600 individual functions. That's a tremendous amount of functionality! But all of it falls into three categories:
In other words, OLE implements a fair amount of functionality itself and, in many cases, allows direct customization of that functionality through implementations of small isolated objects that are plugged into those components. Where OLE doesn't provide a component—most of its components are very general—OLE supports the creation of custom components, making them available to all clients through the same architecture. Many of OLE's interfaces are usually implemented on the objects in these custom components, and many of OLE's API functions assist in the operations that are involved within those interfaces.
There has been some confusion in OLE's past about who or what implements this or that interface, but this is really a meaningless question. The key question is who or what implements a particular component, and once you've answered that question, you can then ask what features that component supports and what interfaces are used to supply those features. It is true that some of OLE's components exclusively control certain types of objects and thus are the only implementers of certain interfaces. This has led some people to think that only one type of object ever implements a specific interface, but the truth is that most interfaces can be implemented by any object in any component whatsoever.
So to better understand this difference between components, the objects involved, and the interfaces on those objects, let's look at all of the various technologies within OLE, discussions of which comprise the contents of the rest of this book:
A means to completely describe an object along with all of its interfaces, down to the names and types (including user-defined types) of each argument to each named function in each interface.
The ability to create outgoing interfaces for an object, such as notifications and event sets.
The ability to create an optionally licensed component that extends the available services to clients.
The ability to transparently integrate clients and components across process and machine boundaries as if they were all in the same process.
A powerful and shareable means to deal with permanent storage that offers benefits of incremental access and transactioning.
The interfaces and protocols necessary to share storage between components and clients.
The encapsulation of a name of an object or a process with the intelligence necessary to work with that name.
The ability to exchange data structures between components and receive notifications about data changes.
The ability to have an object control its visual representation on any output device and the ability of a client to cache those representations for use when the object is unavailable.
Support for the familiar operations of Cut, Copy, and Paste using the mechanisms of Uniform Data Transfer.
A mouse-oriented means of performing the same operations as the clipboard.
The ability to expose an object's methods and properties as individual entities in a late-bound manner, also enabling cross-application macro programming.
A user interface for manipulating properties, a mechanism for notifying clients about property changes, and standards for the serialization of a set of properties into persistent storage.
The basic protocols for the creation and management of compound documents, by which active content objects are manipulated in windows separate from the document itself.
An extension to embedding in which the active object is manipulated in place within the compound document. This is also called visual editing or in situ editing.
The ability to create custom controls as OLE objects and the protocols for managing controls as in-place active objects within a document or form. OLE Controls includes events, property pages, and keyboard mnemonics.
A look ahead to future enhancements and additions to OLE and what they will mean to component software.
Each OLE technology is described briefly in the following sections, and the rest of the chapters in this book deal with each of these technologies in detail.
Keep in mind that absolutely all of these technologies are built on the idea of components and objects and interfaces called the Component Object Model, or COM. Each technology has specific interfaces that apply to it, and some of the higher-level protocols such as OLE Documents and OLE Controls even involve groupings of the interfaces from other technologies. Because of these relationships, the technologies in this list build on one another, as illustrated in Figure 1-7 on the following page.
Figure 1-7.
OLE technologies build on one another, with COM as the foundation. An arrow indicates dependency; a circle indicates a possible use but not a requirement.
You can see that COM, as well as custom components and local/remote transparency, which are generally considered part of COM, form the underlying basis for everything else in OLE. The lower a technology appears on this chart, the more generic or general purpose it is and the less visible it is to an end user. The higher technologies are considered more specific; they are generally more complex, and they usually involve more user interface the higher you go. In other words, the highest technologies are the most visible to the end user, but when you set out to incorporate these technologies into a piece of software, it makes the most sense to work from the bottom up because in doing so you'll build a foundation of code that is readily usable when you work on the higher-level technologies. I most definitely encourage this sort of approach to learning OLE, as the organization of this book reflects.
Undoubtedly you will come across situations in your development efforts in which you have a problem that perhaps some of these OLE technologies can solve. The question is then whether OLE is the only solution to that problem. In all likelihood, there are many possible methods that you might use to solve the problem—OLE is in no way required as the solution unless you are dealing with an integration problem among components from multiple vendors. In that case, you want to adhere to the standards and interfaces that make up the various OLE technologies. In other words, integration among arbitrary components that were not known to each other during development requires standards, and that is what OLE provides. If your problem involves integration among only those components that you write yourself, you can design whatever solution fits your needs. Remember, however, that everything in OLE has already been through a rigorous design and open review cycle. Using OLE in even a closed system makes sense because you do not have to struggle with the same problems that OLE solves already.