Bionic Buffalo Tech Note #25: Quick Start Guide to Writing CORBA Server Applications
When an
POA is created from another POA (using the POA::create operation), the only arguments
(that is, configuration options) are the name, the manager, and a set of policies. These are the only
things that distinguish one
POA from another. The only purpose of the manager is to select the state of
the
POA, and there are only seven policies. (Each policy may have more than one value, but not all
combinations are permissible.)
POAs are not so complicated as they might appear at first glance.
The Seven Adapter Policies: What They Do, and How To Use Them
IdAssignmentPolicy
Every request from a client to the
ORB specifies an object reference, which must be
unique to, and within, the
ORB. The ORB must maintain a mapping of object references to
POAs, so it will know to which POA an object reference belongs. Object references are
opaque to the
POAs, however. When the ORB communicates with a POA, it uses an
opaque sequence of octets, the object id (
PortableServer::ObjectId). Each
object id must be unique within the
POA. Who assigns the object id is defined by the one
of the seven
POA policies, the IdAssignmentPolicy. If the POA itself assigns the
object id, then the
IdAssignmentPolicy is SYSTEM_ID. If the servant assigns the
object id, then the
IdAssignmentPolicy is USER_ID. An object id can be any
sequence of octets, so it can be very useful to assign those octets systematically.
When you are designing a server application, if you want to keep track of your
servant's objects in some systematic fashion, consider the
USER_ID policy. If you
don't want to be bothered (maybe you only have one object per servant, or maybe
you just have a simple lookup table), then consider the
SYSTEM_ID policy.
For example, with the
USER_ID IdAssignmentPolicy, you can use as the object id
a memory address, file name, or database key to allow easy lookup of an object's state
variable or value.
RequestProcessingPolicy and ServantRetentionPolicy
When a request is given to the
POA by the ORB, the POA must decide which of its
servants to use to handle the request. There are three different tools which may be used by
the
POA to make its decision:
The
POA may keep a table of object ids, associating each object id with a specific
servant. This table is known as the Active Object Map. Whether or not the
POA keeps
an Active Object Map is determined by the
ServantRetentionPolicy: if the
policy value is
RETAIN, then it keeps one; if the policy value is NON_RETAIN, then
no Active Object Map is maintained.
A default servant may be registered with the
POA, for use in case there is no Active
Object Map, or if the object is not found in the Active Object Map.
Page 3 of 12