Horus Doc || Corba Reference || Corba   Client Server   Stubs C++   Stubs Java   Servant Generator  

Servant Generator

The ServantGenerator tool generates the source code of the servant for the HxCorba::GlobalOps CORBA Object. It should generate member functions that look like:

(1) #include "HxAbs.h"

(2) HxCorba::ImageRep_ptr 
(3) HxGlobalOpsGenSvt::HxAbs(HxCorba::ImageRep_ptr im)
    {
(4)     HxImageRep _im_arg = HxGetTiedObject<HxImageRepTiedSvt>(_server, im);
(5)     HxImageRep _result = ::HxAbs(_im_arg);
(6)     return HxRegisterTiedServant<HxImageRepTiedSvt>(_server, _result);
    }

It also generates the declaration of this function in the class declaration, that is almost the same as lines 2 and 3.

The ServantGenerator (SG for short) obtains from the InterfaceRepository (IR for short) a list of the operations it has to generate. It also obtains the description of the operation (return type, params, etc...).

SG has to be able to generate code like the shown above from the information it gets from the IR. Let's describe a little the code shown and how SG has to generate it:

(1) #include directive:
For each operation of the GlobalOps interface, SG generates a member for the servant. This member funcion calls a global HORUS function that performs the operation. The IDL operation and the HORUS global function should have the same name.

For each member function, the first thing the SG generates is an include directive of a file with the same name as the member function. This file should contain the declaration of a HORUS global function, with the same name, that implements the operation.

Then, the name of the operation obtained from the IR is enough to generate that line.

(2) Return type:
Next, SG has to generate the result type of the operation. SG knows (from the IR) the result type of the operation, but the IDL one. IDL types and C++ types are not equal, but there is a mapping between them. For each type we want SG to handle, we have to tell to SG the C++ type that has to be used as result type.

(3) Type of arguments:
Now its time to generate the rest of the function header. The class name and function name is easy to generate from the information obtained from IR. But the type of the function arguments is not easy to generate. As for the result type, we have to tell to SG the C++ type that has to be used as argument type. In the example (ImageRep) the type of the argument is the same type as the result type, but this is not true for all types.

(4) Conversion lines:
The body of the function has three parts: first, all arguments are converted from CORBA values to their HORUS related values. Next the global HORUS function is called and finally the HORUS result is converted to a CORBA result and it's returned.

To generate the conversion lines, SG has to know, for each argument, the related HORUS type and the procedure to use for the conversion. These are other information we will have to tell to SG for each type.

Not all types require this conversion. Some types (basic types) can be used both for CORBA and HORUS.

(5) Calling HORUS function:
To generate the line that calls the HORUS global function, SG has to know the type to use to retrieve the function result. This is related to the type that the IDL operation returns. We will have to tell SG which HORUS type to use to get the result.

(6) Return line:
The return line is like the conversion line but the other way around: a HORUS value if converted to a CORBA value. We will also have to tell SG how to make that conversion.

As we can see, for each type (IDL type) we want SG to support we have to tell him:

Example: how to support HxCorba.ImageRep interface:

This information is given to the SG as a GenType object.

To extend SG to a new type, implement a GenType for that type and update the getType function in ServantGenerator.c to include this new GenType.


Go to the next section or return to the index.


Generated on Mon Jan 27 15:20:57 2003 for CorbaReference by doxygen1.2.12 written by Dimitri van Heesch, © 1997-2001