OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
1.1 Development Overview
Most of the effort of developing a DCE application usually lies in the familiar steps of
planning, writing and compiling the necessary C code, linking the result with the DCE
library and other modules, and executing it (perhaps repeatedly). However, there is an
important preliminary task which must be performed before you write any other code.
Before you can implement the application’s client and server, you must write and
compile an interface definition file in which you define the application’s client/server
interface.
This interface, defined in the DCE Interface Definition Language (IDL), consists of a set
of prototypes for the remote procedure calls your client(s) will be requesting your
server(s) to execute. After you have written this file, you compile it with the DCE IDL
compiler. The final output of IDL compilation is a pair of object files, one for the server
module and one for the client, which you must later link with the compiled output of your
server and client implementation code. These two IDL output files contain the server
and client stub code, where all the details of remote execution, data transfer, and so on,
are managed (in conjunction with the DCE runtime).
The IDL compiler also generates a header file for inclusion in the server and client
source files. It contains all the declarations that result from the IDL file definitions.
Among these are, for example, the interface specification identifier, which will be used at
runtime to describe the interface being defined in the programs.
Once you have linked the stub files (and the DCE library) to their respective client and
server modules, the IDL-generated stubs make the client and server seem to
communicate directly through the operation signatures you defined in the original .idl
file, although in actuality client/server communications pass back and forth through
layers of stub and runtime processing, which are necessary to send and receive the data
over the network. Figure 1-1 illustrates how the combination of IDL (by means of the
stubs it generates) and the RPC runtime routines shields both client and server from the
details of network communications.
Figure 1-1. The Combined Effect of IDL and the RPC Runtime
1− 2 Tandem Computers Incorporated 124246