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