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