nn 1 | Page 18

SEC . 9.1 CORBA 511

( a ) ( b )

Figure 9-11 . Mapping of CORBA object identifiers to servants . ( a ) The POA supports multiple servants . ( b ) The POA supports a single servant .

My�Servant ∗my�object ; CORBA :: ObjectId�var oid ; my�object = new My�Servant ;

// Declare a reference to a C ++ object // Declare a CORBA identifier // Create a new C ++ object

// Now register the C ++ object as a CORBA object oid = poa→activate�object ( my�object );

Figure 9-12 . Changing a C ++ object into a CORBA object .

identical servant , although operating on a different state . In those cases that a POA has to support objects that are derived from the same class definition , it is more efficient to register only a single servant , and distinguish the various objects only by their state . This principle is shown in Fig . 9-11 ( b ), where each object identifier refers to the same servant . In this case , whenever an object is invoked , the object ’ s identifier will be passed ( implicitly ) to the servant so that it can operate on only that data that are uniquely associated with the identified object .

This example also illustrates another important issue : a CORBA object identifier is uniquely associated with a POA . Whenever a servant is registered with a POA , the POA returns an object identifier for that servant . An alternative that we have not shown is that an application developer first generates an identifier and passes that to a POA . However , in both cases , this identifier will be encapsulated into a larger data structure that functions as a systemwide object reference , and that also identifies the POA and the server where that POA is located .

Whether or not a POA supports one servant per object , or one servant for all its objects , is just one kind of policy that can be associated with a POA . There are