| Previous | Table of Contents | Next |
The precondition for this scenario is the existence of a client with a reference for an object with which no servant is associated
at the time the client makes a request on the reference. It is the responsibility of the ORB, in collaboration with the POA
and the server application to find or create an appropriate servant and perform the requested operation on it. Such an object
is said to be incarnated (or incarnation) when it has an active servant. Note that the client had to obtain the reference
in question previously from some source. From the client’s perspective, the abstract object exists as long as it holds a reference,
until it receives an OBJECT_NOT_EXIST system exception in a reply from an attempted request on the object. Incarnation state
does not imply existence or non-existence of the abstract object.
Note – This specification does not address the issues of communication or server process activation, as they are immaterial
to the POA interface and operation. It is assumed that the ORB activates the server if necessary, and can deliver the request
to the appropriate POA.
To support object activation on demand, the server application must register a servant manager with the appropriate POA. Upon
receiving the request, if the POA consults the Active Object Map and discovers that there is no active servant associated
with the target Object Id, the POA invokes the incarnate operation on the servant manager.
Note – An implication that this model has for GIOP is that the object key in the request message must encapsulate the Object
Id value. In addition, it may encapsulate other values as necessitated by the ORB implementation. For example, the server
must be able to determine to which POA the request should be directed. It could assign a different communication endpoint
to each POA so that the POA identity is implicit in the request, or it could use a single endpoint for the entire server and
encapsulate POA identities in object key values. Note that this is not a concrete requirement; the object key may not actually
contain any of those values. Whatever the concrete information is, the ORB and POA must be able to use it to find the servant
manager, invoke activate if necessary (that requires the actual Object Id value), and/or find the active servant in some map.
The incarnate invocation passes the Object Id value to the servant manager. At this point, the servant manager may take any
action necessary to produce a servant that it considers to be a valid incarnation of the object in question. The operation
returns the servant to the POA, which invokes the operation on it. The incarnate operation may alternatively raise an OBJECT_NOT_EXIST
system exception that will be returned to the invoking client. In this way, the user-supplied implementation is responsible
for determining object existence and non-existence.
After activation, the POA maintains the association of the servant and the Object Id in the Active Object Map. (This example
presumes the RETAIN and USE_SERVANT_MANAGER policies.)
As an obvious example of transparent activation, the Object Id value could contain a key for a record in a database that contains
the object’s state. The servant manager would retrieve the state from the database, construct a servant of the appropriate
implementation class (assuming an object-oriented programming language), initialize it with the state from the database, and
return it to the POA.
The example servant manager in the last section (Section 11.6.6, “Servant Manager
Definition and Creation,? on page 11-57) could be used for this scenario. Recall that the
POA would have the USER_ID, USE_SERVANT_MANAGER, and RETAIN policies.
Given such a ServantActivator, all that remains is initialization code such as the following.
PortableServer::ObjectId_var oid =
PortableServer::string_to_ObjectId(“myLittleFoo?);CORBA::Object_var obj = poa->create_reference_with_id(
oid, “IDL:foo:1.0?);MyFooServantActivator* fooIM = new MyFooServantActivator;ServantActivator_var IMref = fooIM->_this();poa->set_servant_manager(IMref);poa->the_POAmanager()->activate();orb->run();