| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### MIDL Compiler

After the interface has been defined using the MIDL, it is run through the MIDL compiler. The purpose of the compiler is to produce language-dependent files which can be incorporated or read by the client and server programs. There are two ways in which a client can access classes in a server—“statically” from stubs in the client or “dynamically” at runtime using Type Libraries.

In the former “static” case the IDL is used to generate blocks of code called stubs and proxies, which are actually compiled with the client and server programs.

Figure 5.3 The Interface Definition is used by the MIDL compiler to produce stubs and proxies

The details of the interface in this case have been “embedded” in these blocks of code, and the interface has thus been used to generate code that will specifically handle that interface and its contents, for example, the data being passed and the GUID. This code performs operations such as data format conversion and packing of the data into buffers automatically (we will see this in more detail later in the MS RPC chapter).

In the latter case, the IDL is used to generate entries that go into a Type Library, which is accessed at runtime dynamically whenever a client requests an interface by name. In this case, the details of the interface have effectively been stored in a sort of “database” containing the details of the interface rather than being embedded in the client and server code.

The code in the client and server is thus not interface specific but instead does runtime handling of the information it obtains when it looks at the Type Library, such as the extract of the GUID and packing of the data and data format conversion. As its name suggests, the Type Library contains type information about the interface as a whole in compiled (binary) form.

Clearly, the “static” way of using interfaces is potentially faster, but it has the disadvantage that if you want to change the interface, you have to recompile all the programs that use it. The dynamic approach has the advantage that it can be used with interpreted languages, and it is easier to change the interface. But the dynamic interface is slower because you have the overhead of a look-up to a Type Library and you have runtime type checking. You also have the additional administrative overhead of having to ensure that copies of the Type Library get distributed to the clients that need it, something you don’t have to worry about if everything has been compiled into one executable as it is in the static case.

In some cases the use of the Type Library isn’t an option; it is the only way the programmer can achieve certain things. We will be looking at this a little later in the chapter on Cedar.

If the command to compile the MIDL contains the “library” statement, then a Type Library will be generated together with an entry in the Registry (the Directory services) indicating where it is. Otherwise, if no library command is included, the compiler will generate:

  • A header file in C, C++, Java, and Visual Basic that contains declarations of the interface defined
  • A file in C that defines the GUIDs used
  • A file in C that implements the proxy and stub

### Proxies and Stubs

A Proxy Object is an in-process object which acts on behalf of the object being called. In effect, the proxy object acts as a “front-end” to the remote server’s interface. Proxy objects are generated when the interface (IDL) is processed.

The proxy object resides in the client address space and packages (marshals) the parameters in the call ready for transmitting. One proxy object exists for each object called, and the proxies are invisible to the client. The proxy object makes an RPC to the remote (or local) object. The RPC library (of which more later) then handles the transmission of the data across the network.

Figure 5.4 Communication across the network is handled by the RPC libraries

The same interface/IDL is also used to generate the stub—a small object residing in the same process address space as the server. The stub picks up the RPC calls from the proxies, unmarshals the parameters, and turns them into function calls to the real objects. After the object has completed processing, the stub passes the return values back to the proxy via an RPC call and the proxy then returns them to the client.

The main difference between the proxies and stubs used in DCOM and the stubs used in RPC calls is that proxies and stubs need to be able to handle multiple function calls on an object—RPCs only handle one function call. It is also worth noting that the approach is somewhat similar to the approach used in CORBA, but the terminology is different—CORBA uses the terms Stub and skeleton.

Previous | Table of Contents | Next