Component Versioning

Inter-object Communication

COM allows clients to communicate transparently with objects, regardless of where those objects are running. They can run in the same process, on the same machine, or on a different machine. This provides a single programming model for both object clients and object servers.

Figure 5.7 Cross-process communication

Marshaling

Marshaling is the packaging of all parameters and return values and distributing them back and forth across process boundaries. COM provides an implementation of marshaling referred to as standard marshaling . Standard Marshaling works very well for most objects and greatly reduces programming requirements, making the marshaling process effectively transparent.

Custom Marshaling

Standard Marshaling is an instance of custom marshaling . You can implement custom marshaling to allow an object to take one set of actions when used from across a network, and a different set of actions under local access; this difference is completely transparent to the client. This architecture makes it possible to design client/object interfaces without regard to network performance issues. You can address network performance issues later without disrupting the established design.

Communication with a Client

At some point, all calls from the client and all calls to the server are in-process calls. Because the VTBL structure allows an agent, such as COM, to intercept all function calls and all returns from functions, that agent can redirect those calls to a Remote Procedure Call (RPC) as necessary. Although in-process calls are faster than out-of-process calls, the process differences are completely transparent to the client and server.

In-Process Components

An in-process component is usually implemented as a DLL. It runs in the same process space as its client application. This enables the most efficient communication between client and component because you only need to call the function to obtain the required functionality.

Out-of Process Components

If the object is out-of-process, the call first reaches what is called a "proxy" object provided either by COM or by the object (if the implementor wishes). The proxy packages call parameters (including any interface pointers) and generates the appropriate remote procedure call (or other communication mechanism in the case of custom generated proxies) to the other process or the machine where the object implementation is located.

Communication with a Server

On the server, all calls to an object's interface functions are made through a pointer to that interface. A pointer only has context in a single process. Therefore, the caller must always be some piece of in-process code. If the object is in-process, the caller is the client itself. Otherwise, the caller is a "stub" object provided either by COM or by the object itself. The stub receives the RPC (or other communication mechanism in the case of custom generated proxies) from the "proxy" in the client process, unmarshals the parameters, and calls the appropriate interface on the server object. From both the client and server's point of view, they always communicate directly with some other in-process code.

Remote Procedure Calls

Remote Procedure Calls (RPCs) are platform-independent because they are based on the Distributed Computing Environment's Remote Procedure Call (DCE-RPC) specification. Calls between COM-compliant components can be made between Windows 95, Windows NT, Unix, and Macintosh environments, as well as other environments that support DCE-RPC.

Lesson Summary

COM allows clients to communicate transparently with objects, regardless of where those objects are running. They can run within the same process, in separate processes, on the same machine, or on a different machine.

The COM Library is the key to providing transparent cross-process interoperability. It encapsulates all the work associated with launching components and establishing connections between components, and insulates them from location differences.

A fundamental strength of COM is its support for versioning and component evolution. COM objects can easily continue to support interfaces used with older clients, while providing additional interfaces to communicate with newer clients.