Bionic Buffalo Tech Note #25: Quick Start Guide to Writing CORBA Server Applications
ServantLocator objects at appropriate places in the above process. Note that most language
mappings treat these the same as ordinary server objects, so they, in turn, might require other
objects to be installed first.
Often, the installation routine is combined with the startup routine, whose description follows.
Startup
Once the servants are in place, the application must create some initial objects for the clients to use. As
explained above, there are four basic operations (
create_reference(),
create_reference_with_id(), activate_servant(), and
activate_servant_with_id()) to accomplish this. References for these initial objects must
then be made available to clients, using one of the above listed mechanisms.
Servants
Servants are, for the most part, coded as are other applications, except for the servant's ability to
acquire and to use the
POACurrent object.
The
POACurrent object is of type PortableServer::Current, and is obtained from the ORB
by use of
ORB::resolve_initial_references(). The POACurrent object is available
only to servants while handling a request, and provides information about the current request to the
servant. The
POACurrent object has four operations to provide that information:
get_POA() returns the POA which called the servant (a servant might be used by more than one
POA)
get_servant() returns the servant (a method might belong to more than one servant)
get_object_id() returns the object id of the target object (that is, the object whose operation is
invoked by the request)
get_reference() returns a reference for the target object
Unless
IdUniquenessPolicy = UNIQUE_ID, the servant methods might be called for different
objects, and the
get_object_id() and get_reference() operations are the only way for the
servant to determine which object was the target of the call. The servant must maintain a mapping
between object id or reference, and the various objects supported by the servant. There are two obvious
ways to do this: either a lookup table with object id or reference as an entry, or by encoding some
distinguishing information into the object id. Encoding distinguishing information into the object id
requires that
IdAssignmentPolicy = USER_ID. Convenient information to encode includes
pointers to data structures in memory, peripheral i/o addresses, names of files, and database keys.
(Sometimes it is a good idea to encode a serial number or similar identifier into the object id, in
addition to an address or key, to distinguish among different objects which might exist at different
times but which coincidentally might have the same address or key. An object reference on a client
might persist after an object has been destroyed on the server.)
Character, wide character, string, and wide string arguments passed from client to server (or returned
from server to client) may undergo translation by the
ORB to accommodate differences in character
Page 11 of 12