The DCE Interface Definition Language (IDL) compiler includes support for C++ language syntax features that provide a distributed object framework. This topic describes some terms and techniques for developing object-oriented DCE applications. Before you start developing your applications, read this topic and then see the OSF DCE Application Development Guide - Core Components for more information.
In general, using C++ for your DCE applications should be easier than using C because the DCE mechanisms can be better hidden from the developer. The following are some examples:
· The C++ compiler forces the server implementation of all interface operations. Although all DCE applications must do this to work properly, there is nothing to prevent you from writing an incomplete server in C. An added benefit of C++ is that the IDL compiler automatically generates the manager class with all the function signatures defined.
· The DCE function table known as an entry point vector (EPV) is generated automatically in object code by a C++ compiler, rather than in C code by the IDL compiler. In addition, you never have to construct a manager EPV as you might in your C code.
· + automatically provides a mechanism for grouping objects into types with its class data structure. This means it is unnecessary to use the DCE rpc_object_set_type( ) routine and associated routines.
· For DCE servers, interfaces are automatically registered with the DCE runtime.
These and other features make for easier and faster development.
DCE supplies exception-handling macros to use in distributed applications. You should use the DCE macros in your applications, instead of the standard C++ macros, to be sure exceptions are propagated correctly from servers to clients.
Distributed applications traditionally use the client/server model, in which a client applications binds to a server and makes a request, to which the server responds. In this model, the distinction between a client and server is strong from both a development and runtime perspective. The client/server model is still convenient when developing and describing distributed, object-oriented applications, but an application is not distinctly a client or server. Whether an application is a client or server is more a condition of its execution than a characteristic of its development. It is convenient to say that a client requests the use of a distributed object and that objects are maintained by servers. However, clients also create and maintain their own objects that may be used by other applications, and servers may need to use objects maintained by other applications.