![]() |
To allow IDL interfaces to be implemented in C++, server-side bindings are emitted. The resulting classes work with the client bindings. The following figure illustrates the module structure of the server-side bindings, assuming that interface T is declared in the file T.idl.
Module structure of server-side bindings. The corba.h header file is included in the T.hh file, which is then included in the T_C.cpp file. The T_C.cpp file is then included in the T_S.cpp file, which is then compiled, along with C++ server code. The C++ server code defines the class T_Impl, includes the implementation header file, T.ih (which includes the T.hh file), and defines the class T_Impl:public and the virtual T_skeleton. The final output is the server executable.
The differences between this figure and the client-side figure presented in Client C++ Bindings are:
The T_S.cpp file provides an implementation for the class T_Dispatcher. This class inherits from the dispatcher classes corresponding to T's parents. An instance of this class contains a T_ptr that addresses the T_Impl object upon which it will dispatch operation invocations. Each target object (for example, each T_Impl instance) exported by a server must have a corresponding dispatcher object, whose purpose is to receive a CORBA::Request object, determine what method is being invoked, stream the method arguments out into local variables, invoke the method on the target object, then stream the results back into the request so these can be returned to the caller.
The target object for a T_Dispatcher is an instance of the T_Impl class, which subclasses from (at least) the T_Skeleton class defined by the implementation bindings (in the file T.hh). The T_skeleton class inherits from the T interface class and the skeleton classes corresponding to T's parents. As a result, T_skeleton inherits all the methods that T_Impl must support. Furthermore, this is done in a way that forces T_Impl to indeed provide implementations for all of these methods.
Take notice of the fact that the class name T_Impl is entirely arbitrary. The implementation class may have any name. Also note that the implementation class is not nested within any of the C++ classes that might be used to provide nesting scopes corresponding to IDL modules within which the interface T is defined. Thus, naming conflicts are a concern. A simple solution is to use underscores to concatenate module names with the name of the implemented interface. For example, if the interface T is defined within module M, then the implementation class name M_T_Impl can be used.
If the programmer responsible for T_Impl desires, the implementations (and supporting instance data) for any or all of T's parents can be inherited from their implementation classes, using C++ inheritance. Alternatively, T_Impl can provide its own implementation for the operations inherited into T. The image below graphically illustrates these options from an IDL snippet, using a dotted inheritance line to show optional C++ inheritance.
interface A { ... }; interface B : A { ... };
Inherited implementation. Object_ORBProxy (a proxy implementation for CORBA::Object) is derived from objects A and B through five levels of inheritance, in a process which involves both pure (or skeleton) and proxy implementations of objects A and B at different levels.
The above figure focuses on C++ classes. The term pure is based on the use of this word in C++ to describe virtual functions that have no implementation (denoted in C++ by assigning a 0 to the name of the virtual function). Classes with pure virtual functions cannot be instantiated. Therefore, the skeleton classes require a subclass to provide complete implementations for all virtual functions in an interface. The dotted line in the previous figure indicates one way that B_Impl can provide implementations for the pure virtual functions inherited from A_Skeleton (using B_Skeleton). One way of viewing the skeleton classes is that they "turn off" proxy behavior and require subclasses to explicitly provide an alternative (non-proxy) implementation.
Related tasks... | |
Creating IDL files for an enterprise bean | |
Related concepts... | |
Parent: Interface Definition Language (IDL), usage and implementation | |
CORBA C++ client usage bindings | |
Related reference... | |
Interface Definition Language (IDL) | |
CORBA C++ bindings | |