Power to the POA

Transient and persistent objects are two categories of objects that relate to the lifespan policies of the POA. A transient object is short-lived with a lifetime that is bounded by the POA in which it was created. A persistent object, on the other hand, is long-lived with a lifetime that is unbounded. It can consequently outlive the very server process wherein it was created. This has several advantages. A server may be shutdown whenever it is not needed to save resources. Server updates can be implemented transparantly by restarting the server. In developing a DOC environment, the command to start a server may be replaced with a remote shell invocation and the next server instance run remotely, without the client being aware. Persistent objects also maintain their identify after a server crash. Whilst the POA supports and implements persistent objects, it does not handle the administrative aspects of server activations. This is managed by the IMR which stores an activation record for each server process; it is consulted automatically whenever a (re-)launch of a server is mandated.

Figure: Server activation through the IMR

Fig.  illustrates the role of the IMR in the (re-)activation of servers. The first instance of the server is started by an administrative procedure (imr activate) and object references, pointing to the POA Mediator within the ORB daemon process, are exported to the Naming Service (step 1). The ORB daemon listens for CORBA client connection attempts and assists the client in connecting to its destined server. This is done through the POA Mediator whose task is to intercept initial client requests, to (re-)activate the server if so required, and to forward the actual server location to the client for all subsequent operations (step 2). Thus, by virtue of the capabilities of the POA, and the activation techniques of the IMR, BD applications are never starved of the servers they require.