Making Calls Across Processes

Let's now take a closer look at how the DCOM magic works. When a client creates an object instance supported by a local

.EXE

1. The client calls

   CoCreateInstance()

   on a CLSID supported by a local server.
   
   
2. The DCOM runtime working together with the SCM (Service Control Manager), determines if the requested local server is already running and can be connected to. The SCM is a part of the OS on Windows NT.



3. If the local server is already running and can be connected to, the client is provided with a pointer to an interface proxy (more on this later).



4. If no connectable instance of the class requested exists, a new instance of the object is created by launching the local server if necessary.



5. An interface proxy representing the requested interface from the newly created object is returned to the client.

The SCM is a process whose sole purpose in life is to locate implementations or specific instances of requested COM classes. Because of this, it's a close friend of the system registry where all the CLSIDs to implementation mappings are kept persistently. This SCM is typically named

Rpcss.exe

Once a client is connected to an instance of a COM class, it holds an interface pointer to an interface proxy. With this interface proxy, the client may obtain other interface pointers (using

QueryInterface()—

IUnknown::QueryInterface()

• It works in the same way across processes on the same machine or across machines on a network.
  
  
• It handles procedure calls and parameter passing across two machines with dissimilar hardware architectures and operating systems.
  
  
• It provides security support that allows the identity of the client process to be passed over to the server.
  
  
• It's basically network transport protocol independent, being currently able to work over TCP, UDP, IPX/SPX or Named Pipes.
  
  
• It's a time-tested mechanism widely deployed in both Windows NT system design and UNIX based network programming.

COM and DCOM leverage heavily on these capabilities.

Note: COM actually will attempt to use lightweight RPC (LRPC) whenever possible when the two communicating objects/components are residing on the same machine and OS. LRPC is a Microsoft proprietary variant of RPC which has the exact same calling syntax as the DCE RPC runtime (thus the seamless interchangeability) but is optimized to reduce data copying and eliminate access to the networking code altogether.

When we put the RPC layer into the picture during a method invocation, the situation becomes a bit more complex. Namely, the call is now 'cross-process' or 'cross-machine'. The actual call is delivered to an object within the current process called an Interface Proxy. The following diagram shows the activities that will occur:

1. The client invokes the interface through the interface proxy.
   
   
2. The interface proxy marshals the parameters into a buffer provided by a channel. The channel is supplied by the RPC runtime system and is an abstraction above the different transports. The channel can be operating on shared memory spanning two processes on the same machine, or could be operating over a network protocol stack across two machines. It can be viewed as a virtual tunnel connecting the two communicating processes (regardless of their location). Data going into the tunnel (marshaled) on Process A will come out the same way (unmarshaled) from the other end of the tunnel on Process B. Loosely speaking, marshaling means packing the data into the channel's buffer in a well-defined format (for DCE RPC, this well defined format is called the Network Data Representation or NDR). NDR is an agreed format to transmit different data types between dissimilar machines so that the same data can be reconstructed exactly at the destination machine).
   
   
3. The channel forwards the data to the server.
   
   
4. An interface stub on the server receives the buffer from the channel and unmarshals the data from the buffer .
   
   
5. The interface stub calls the associated interface on the server object.
   
   
6. The interface stub sends return values back to the interface proxy.
   
   
7. The interface proxy returns the values to the client.

Note that there are many more subtleties associated with the marshaling action than the simple description implies. For example, if a pointer to a data item is marshaled across two processes, just sending the value of the pointer itself is useless since the receiver lives in a totally separate process/addressing space. Instead, the actual data item itself must be sent across the wire and a pointer to it reconstructed within the receiver process in order for the marshaling to work.

Now is a good time to find out what the interface proxies and stubs are. Under the COM model, they are actually small COM objects. The code for these objects was created automatically when we ran our original IDL (interface description language) through the MIDL compiler. Based on the data type of the method arguments and return values, the MIDL compiler creates these marshalling proxy/stub pairs for communicating between processes. One pair of proxy/stub classes is created for each interface. If you look back in Chapter 7 where we created a local server called

ATLFinder.EXE

ATLFINDERPS.MK.

NMAKE –F ATLFINDERPS.MK

in a DOS box to create and register the proxy/stub for marshalling of the interfaces supported by the

ATLFinder.EXE

ATLFinder.EXE

ATLFinder_p.c

So far we've focused on the conceptual view of providing proxy and stub code for interface method invocation across processes, and indeed it was the way that it was done for a period of time. With DCOM, though, Microsoft has introduced automatic type-library based marshaling. Automatic type-library marshaling actually builds these proxy and stub objects on the fly from type library information obtained on an interface. What we see here is actually a reuse of the marshaling technology Microsoft had been using for OLE Automation. As long as the data type that needs to be marshaled is compatible with OLE Automation (which essentially means all the data types that a

VARIANT

© 1997 by Wrox Press. All rights reserved.