510 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP . 9
objects it manages .
In general , an object adapter does more than just call a method on an object . As its name suggests , an object adapter is responsible for providing a consistent image of what an object is ; it adapts a program such that clients can see that program as an object . Adapters are also called wrappers .
In CORBA , the Portable Object Adapter ( POA ) is a component that is responsible for making server-side code appear as CORBA objects to clients . The POA has been defined in such a way that server-side code can be written independently of a specific ORB .
To support portability across different ORBs , CORBA assumes that object implementations are partly provided by what are called servants . A servant is that part of an object that implements the methods that clients can invoke . Servants are necessarily programming-language dependent . For example , implementing a servant in C ++ or Java would typically be done by providing an instance of a class . On the other hand , a servant written in C or any other procedural language typically consists of a collection of functions operating on data structures that represent the state of an object .
How does a POA use a servant to build the image of a CORBA object ? In the first place , each POA offers the following operation :
ObjectId activate�object ( in Servant p�servant );
that we have specified in CORBA IDL . This operation takes a pointer to a servant as input parameter and returns a CORBA object identifier as a result . There is no universal definition of type Servant ; instead , it is mapped to a language-dependent data type . For example , in C ++, Servant is mapped to a pointer to the predefined ServantBase class . This class contains a number of method definitions that each C ++ servant should implement .
The object identifier returned by the operation activate�object is generated by the POA . It is used as an index into the POA ’ s Active Object Map , which points to servants as shown in Fig . 9-11 ( a ). In this case , the POA implements a separate servant for each object it supports . To make matters more concrete , assume an application developer has written a subclass of ServantBase , called My�Servant . A C ++ object that is created as an instance of the My�Servant class can be turned into a CORBA object as shown in Fig . 9-12 .
In the code in Fig . 9-12 , we first declare a reference to a C ++ object . To create a CORBA identifier , we make use of CORBA :: ObjectId�var , which is predefined C ++ data type for all standard C ++ implementations of CORBA . After these declarations , my�object can be instantiated as a true C ++ object . In CORBA terminology , this C ++ object corresponds to a servant . Turning the C ++ object into a CORBA object proceeds by registering it at the POA ( which we assume to be available through the variable poa ). Registration returns a CORBA identifier .
It is important to note that if a second object of type My�Servant were created , the registration of that C ++ object at the POA would lead to an almost