| Previous | Table of Contents | Next |
To implement an object using the POA requires that the server application obtain a POA object. A distinguished POA object,
called the root POA, is managed by the ORB and provided to the application using the ORB initialization interface under the
initial object name “RootPOA.? The application developer can create objects using the root POA if those default policies are
suitable. The root POA has the following policies.
• Thread Policy: ORB_CTRL_MODEL
• Lifespan Policy: TRANSIENT
• Object Id Uniqueness Policy: UNIQUE_ID
• Id Assignment Policy: SYSTEM_ID
• Servant Retention Policy: RETAIN
• Request Processing Policy: USE_ACTIVE_OBJECT_MAP_ONLY
• Implicit Activation Policy: IMPLICIT_ACTIVATION
The developer can also create new POAs. Creating a new POA allows the application developer to declare specific policy choices
for the new POA and to provide a different adapter activator and servant manager (these are callback objects used by the POA
to activate objects and nested POAs on demand). Creating new POAs also allows the application developer to partition the name
space of objects, as Object Ids are interpreted relative to a POA. Finally, by creating new POAs, the developer can independently
control request processing for multiple sets of objects.
A POA is created as a child of an existing POA using the create_POA operation on the parent POA. When a POA is created, the
POA is given a name that must be unique with respect to all other POAs with the same parent.
POA objects are not persistent. No POA state can be assumed to be saved by the ORB. It is the responsibility of the server
application to create and initialize the appropriate POA objects during server initialization or to set an AdapterActivator
to create POA objects needed later.
Creating the appropriate POA objects is particularly important for persistent objects, objects whose existence can span multiple
server lifetimes. To support an object reference created in a previous server process, the application must recreate the POA
that created the object reference as well as all of its ancestor POAs. To ensure portability, each POA must be created with
the same name as the corresponding POA in the original server process and with the same policies. (It is the user’s responsibility
to create the POA with these conditions.)
A portable server application can presume that there is no conflict between its POA names and the POA names chosen by other
applications. It is the responsibility of the ORB implementation to provide a way to support this behavior.
Each distinct ORB created as the result of an ORB_init call in an application has its own separate root POA and POA namespace.