As mentioned in the previous section, a service or a component is provided through one or more objects, each object consisting of a logical grouping (or isolation) of particular features of the component. These objects make up the communication channels between the user of those objects (some piece of code) and the provider of the objects.
In this book, I use the term client to refer to the user of objects—the piece of code that is accessing the functionality and the content of those objects. Client literally means "one who uses the services of another," which is exactly what we're talking about. In some cases, I might use the term user or object user synonymously with client.2 In addition, when a client also maintains the persistent states of object instances, that client is called a container because it contains those object instances that are entirely described by the state data. Container is most frequently used in the context of compound documents and custom controls.
The provider of a component and its constituent objects is known as a server, literally, "one who furnishes services." There is hardly a better term to describe a service provider, for in a programmatic sense a server is the demand-loaded code module—such as a DLL or an EXE—that makes a component and its objects available to the outside world. Without a server, the objects remain hidden from external view. The server holds them out on a silver platter and invites clients to partake of them.
The relationship between a client, a server, and the objects that make up a component or a server is illustrated in Figure 1-1. This is similar to the more general definition of any client-server relationship that might use any number of mechanisms to communicate. In the OLE relationship shown here, however, communication happens through OLE objects.
Figure 1-1.
The OLE client-server relationship. A client uses a component or a service as provided by a server, and the communication between client and server happens through OLE objects.
2 In Inside OLE 2 I used the term user much more frequently than I do in this edition. That was because the term client was poorly understood from the compound document definition that was used with OLE 1 and so in the transition from OLE 1 to OLE 2 client was ambiguous. Now that OLE 2 has established itself it is once again safe to use client in the real meaning of the word. |