COM Clients and Servers

In COM, clients deal with objects, interfaces, and methods. They do not directly communicate with a server, nor do they (usually) need to know the location of the server. After a COM object is created, the client works with the object through its interfaces. The actual location of the server is transparent to the client.
This abstraction, or hiding, of the location of the server is called local/remote transparency. Having obtained a pointer to a COM interface, a client simply makes calls into the interface. To the client, there is no difference between calling a method in a server on the same machine or calling a machine across the network! The COM runtime subsystem handles the details involved with making the connection to the server and calls to servers in different processes.

COM provides an elegant and compact solution to client-server development by providing a uniform access mechanism between clients and objects. Other client-server development technologies have the client communicate with the server via a specific mechanism, for example, sockets and RPC. This places a heavy burden on clients. They must have specific knowledge of where a server is, how to format data, and how to call into the server over the specific technology in use. A socket client must format data into a stream and send it to the server by making socket calls. In COM, a client simply asks the COM runtime subsystem for a pointer to a COM interface contained in a COM object and makes calls. COM handles all the underlying details.

A critical aspect of COM is how clients and servers interact with each other. A COM client is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interfaces. A COM server is any object that provides services to clients and these services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object.
There are two main types of servers,

1. in-process and
2. out-of-process.

In-process servers are implemented in a dynamic linked library (DLL), and out-of-process servers are implemented in an executable file (EXE). Out-of-process servers can reside either on the local computer or on a remote computer. In addition, COM provides a mechanism that allows an in-process server (a DLL) to run in a surrogate EXE process to gain the advantage of being able to run the process on a remote computer. For more information, see DLL Surrogates.
The COM programming model and constructs have now been extended so that COM clients and servers can work together across the network, not just within a given computer. This enables existing applications to interact with new applications and with each other across networks with proper administration, and new applications can be written to take advantage of networking features.
COM client applications do not need to be aware of how server objects are packaged, whether they are packaged as

1. in-process objects (in DLLs) or
2. as local or remote objects (in EXEs).

Distributed COM further allows objects to be packaged as service applications, synchronizing COM with the rich administrative and system-integration capabilities of Windows.