PreviousNext

Using Interface Definitions to Design Classes

Since RPC is the mechanism DCE clients and servers use to become distributed applications, this mechanism must be introduced into C++ applications in an object-oriented way. When IDL compiles an interface definition, it generates a class hierarchy for clients and one for servers that provide the transition from RPCs to object-oriented applications. This is show in the following figure.


The RPC Class Hierarchy

At the top of each RPC hierarchy is a DCE-supplied class call rpc_object_reference. This DCE base class encapsulates the RPC mechanisms and provides a framework for identifying, distributing, and tracking objects. It is used by the generated stubs and not directly by your application code.

The IDL compiler also generates an interface class derived from the DCE base class. The interface class contains the public member functions specified in the interface definition. The interface class provides the link between the RPC mechanisms of the DCE base class and your application.

Although the interface class is the same for both the client and server hierarchy, the client and server must implement these functions quite differently. The server implements application-specific functions that operate on the actual object, while the client uses idl-generated functions that provide the distributed mechanisms. Polymorphism provides the capability to hide the implementation details of the interface class. In C++, this flexibility is easily provided by creating the interface class as an abstract class with all pure virtual functions. This means that none of the functions of an interface class are implemented directly, so no objects of the interface class can be created directly. This apparent restriction simply means that to implement the member functions, another class must be derived from the interface class.

At this point, the client and server RPC hierarchies diverge. In the client, the IDL compiler automatically derives a proxy class from the interface class. The proxy class implements in the client stub all the pure virtual member functions of the interface class. These functions handle all the underlying RPC code necessary for you client to access distributed objects. Thus, when a client calls the interface class's member functions, the polymorphic behavior of the C++ class hierarchy causes automatic invocation of the appropriate proxy class function in the stub. In the server, the IDL compiler automatically generates a manager class with empty function bodies.

You can choose to implement the server's interface operations in two ways:

· Implement the functions in the generated header file. However, be aware that under normal circumstances, a new IDL compilation of the interface will overwrite the header file with empty functions. (You can override this IDL-compiler behavior with the -no_cxxmgr option.)

· Derive a new implementation class from the automatically generated manager class.

More:

Using Static Functions in Interface Design

Adding an Interface Rather than Changing One