Next: Example of a Up: A MOP for Previous: Basic classes

Class and member identifications

Within the framework of distribution (several address spaces), the need for class and member identifications is inescapable. While the classes presented in the previous section can have simple and low-cost values in a shared address space, more sophisticated policies are needed in a distributed environment.

Another issue is the capability to automatically achieve (un)marshaling of objects between processes and address spaces (flattening and rebuilding of objects during communications).

The Class_info and Member_info classes respond to these specific issues:

          class Class_info {
          public:
             class_id id;                // system-wide valid identification
             structure s;                // information on the class structure
                                         // for (un)marshaling of objects
             ...
          };

          class Member_info {
          public:
             member_id id;               // system-wide valid identification
             Class_info* return_type;    // informations on the member
             ...
          };

These classes are Meta-classes which represent information on C++ classes; the amount of information available and manipulable has to be defined. They conform to the design principle of the standard class type_info which provides some basic information, and was designed with the intention of being extended according to specific needs.

By construction, class_id and member_id have a system wide validity (they can be passed as parameters between processes), while on each address space Class_info* and Member_info* pointers have a specific value and implementation.

Two functions:

         Class_info*  class_map (class_id c);
         Member_info* member_map (member_id m);

provide a mapping on a given address space between class and member identifications and local Class_info* and Member_info* values.

In a distributed framework, a class Request which inherits from the MOP class Call is defined with new members corresponding to the specific information which is needed.

          class Request: public Call {
          public:
             virtual void execute ();    // new definition
             request_id id;              // id of the request
             ...
          };

An object instance of this class is then sent to the remote process which will execute the call by calling the execute function on it. Such mechanism is indeed very close to the CORBA architecture [][], and we should study how we can comply to this standard, use it for a mapping or an implementation of the classes Call, Request, Class_info, and Member_info.