DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
|
DCOM is entirely reliant on MS RPC to provide its distributed capability. In fact, it is MS RPC which turns COM into DCOM. Understanding what this key service does is thus essential even if much of what is achieved is done under the covers.
A Remote Procedure Call (RPC) is a procedure that, when called, executes a function on a remote machine and returns with results from that function when completed. Remote Procedure Calls mimic the structure of a simple C function call, with the functions name, its arguments when called, and its returned value or structure, giving the programmer the impression that he or she is making calls to routines on the same processor.
From the programmers perspective, calls to routines on other systems seem no different to calls to, for example, local C functions. If processes communicate using RPCs, one process calls another process as though it were a part of the original processs code.
Figure 7.1 MS RPC
Distributed processes pass control and data between application processes just as they do for local procedure calls. But there is an obvious difference between the way distributed applications pass data when compared to single processor systems.
Single processor systems can pass data between procedures by passing only the address or the name of the data item. Because they run in the same execution environment, the data is effectively shared because storage format and data structures are usually the same. The data in this case may be in shared memory. If an application is distributed, data must actually be packaged and moved across the network with the call, in order for it to be usable by the called process.
MS RPC is Microsofts software to support Remote Procedure Calls. Thus, MS RPC is a set of runtime libraries and development tools which enable the developer to build distributed applications using RPCs.
MS RPC can thus be regarded as middleware in its own right. It can be used without any of the rest of DCOM to support distributed processing. In other words, the developer could use MS RPC right now to build distributed applications. But in the DCOM context, Microsoft uses it to support their own remote function calls across the network, and MS RPC becomes invisible to the application developer. Thus, in the context of DCOM, MS RPC is enabling middleware used by Microsoft.
MS RPCs prime function is to ensure that the request for a function with its parameters and the resulting reply are transmitted across the network. The MS RPC runtime environment reduces the data structures to be passed into a buffer for transmission, converts the individual data elements to a format used during transmission, and then makes calls to the network interface using the appropriate network protocol, to coordinate the sending of the packaged data to the called process.
The middleware software at the called end receives the inbound request containing the packaged data and then unpacks the received buffer, recreating the data structures. It then converts the individual data from the format used for transmission into the local format and starts the processing. Once processing is complete, the middleware then reverses the process to return control and results back to the calling process.
The network software acts as the transport agent between machines, but it is the MS RPC which handles transport between the processes. MS RPC also provides a number of functions which save the developer effortin this case the Microsoft developer. The RPC software, for example, hides the network commands that remain as an invisible layer, saving the programmer from having to write tedious low-level network code.
Without the MS RPC service, the work associated with packing and unpacking the data structures, data format conversion, error handling, network software communication, session handling, and so on has to be coded by the programmer. Once MS RPC middleware is used, all this is handled by the middleware on behalf of the programmer. We will be looking at the specific services provided by the middleware later in this chapter.
When a developer wants to build an application based on remote procedure calls, he or she first defines the interface to the function. The interface has an almost identical meaning to that used in COMit is a contract between any client and the function which defines the function itself together with the parameters to that function. The interface to MS RPC might describe:
This interface is described in an IDLInterface Definition Language. Now where have we seen this before? It should be obvious that many of the concepts used in COM and DCOM were borrowed from RPC technology (a technology, incidentally, that actually goes back to the 1970s).
An IDL generator or compiler then reads the IDL and generates code. The MS RPC IDL compiler generates a standard language such as C. When the C source code is generated, it is effectively machine independent and can then be compiled for the target environments. The compiler may also generate header files and make files.
In addition to the header files and make files the other main code generated by the IDL compiler are client and server stubs. Again, where have we seen this before? Of course DCOM supports the notion of client and server stubs and proxies, although the proxy has an extended role in DCOM to the stub we see in the MS RPC stub. On the whole, however, DCOM produces client and server stubs because MS RPC does.
The generated stubs are usually compiled and linked with both the client and server programs. It may be possible to use DLLs (Dynamic Link Libraries) to store the code, or the code may be directly compiled and linked to provide a single executable client or server program.
The client and server then communicate at runtime with an RPC library, which is provided as part of the MS RPC middleware.
Previous | Table of Contents | Next |