OLE uses DDE (Dynamic Data Exchange) as the underlying transport mechanism for communicating between client and server applications. A set of dynamic-linked libraries manage the DDE conversations for an OLE application. These DLLs make it is possible to implement OLE with little DDE knowledge and without the need to write DDE code. There are two DLLs that allows client/server communication, one that interfaces to the client application (OLECLI.DLL) and one to the server application (OLESVR.DLL). (A third DLL, named SHELL.DLL, provides the API needed to query and maintain the registration database.)
Server applications are written using the server API included in the server DLL. Likewise, client applications are written using the client API included in the client DLL. In addition to managing the DDE conversation between client and server applications, the OLE DLLs can render objects for the client and launch and shut down server applications. While the client and server DLLs do most of the OLE work, the client and server applications must maintain specific data structures that correspond to OLE objects.
Server applications provide a set of services that the libraries will access when fulfilling requests made by the client application. Client applications must manage all user interface features and can call client DLL functions to do such things as open a server document file, show a specific object, instruct the server application to perform a specified verb on an object ( for example, edit), or instruct the server application to save an open document.
The illustration shown in Figure 7 details the basic communication paths that are established between the client and server applications via the OLE client and server DLLs. The applications communicate with their respective DLLs by using OLE-specific function calls and callbacks.
Figure 7: OLE's library-based architecture and the use of function calls
The illustration in Figure 7 also indicates the general sequence of communication events that take place when a user chooses to insert an object from within an application that supports OLE. In this situation, the client application must first recognize that the user is requesting service by a different application (such as when the user double-clicks an object) and then make the appropriate function call to the client DLL.
The following steps correspond to the numbered events in Figure 7:
1.When the user makes an OLE request from within the client application, such as choosing to insert an object, the client application passes the request via specific function calls to the client DLL.
2.The client DLL determines which server application is needed to fulfill the request and generates the appropriate message (using DDE-messaging) for passage to the server application, via the server DLL.
3.The server DLL makes the appropriate callback to the server application, such as create-a-new-object. (Callbacks are described in the next section.)
4.After the user has finished creating the object, the server application passes the object data to the server DLL with a function call.
5.The server DLL generates the appropriate message (using DDE-messaging) for passage to the client application, via the client DLL.
6.The client DLL makes the callback to the client application, passing the object data, which the application places into the container document.
Note The use of DDE for communication between client and server DLLs may not be supported in future versions of OLE. Client and server applications will continue to communicate through OLE DLLs, but the transport mechanism cannot be guaranteed.