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. The following figure 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.
The Combined Effect of IDL and the RPC Runtime
Once the work of defining an interface has been completed, the task of implementing the interface (that is, coding the operations, along with the rest of the necessary initialization and management routines, in some programming language) begins. The rest of this topic consists of detailed explanations of the DCE application development steps from start to finish. For a practical example of the result of such a process, refer to the code for the DCE sample application, which is in A Sample Application.
Each of the DCE components (with the exception of CDS, which is accessed through the RPC NS API) is discussed in depth in separate parts of this guide. You should also refer often to the OSF DCE Application Development Reference, which contains reference pages for all of the DCE library routines mentioned in the following topics.