background image
Bionic Buffalo Tech Note #100: Identifying CORBA Objects
containing other objects, and these may persist indefinitely. On the other hand, an
object may be ephemeral, and may exist only as long as is needed to perform some
operation, and then be destroyed.
Servants communicate with ORBs by means of adapters. The common specification
for the adapter-servant interface is described in the IDL of the 
PortableServer
module. There are other models used for adapters, but the 
PortableServer
 model
has become the most common, and its architecture will be assumed in the rest of this
document.
An ORB may have more than one adapter. The adapters are organized into a tree,
whose base is the root adapter. Adapters are created by other adapters, and all trace
their ancestry back to the root adapter. All adapters, whether or not they are terminal
nodes in the tree, communicate with servants. (In other words, an adapter may have
descendent adapters, and also communicate with servants.) Each adapter has a name,
and a given adapter can be referenced from the ORB by following a path name from
the root, similar to the path name of a file in a traditional file system.
Adapters sit between the ORB and the servants, and provide services to both. Each
adapter may associate with zero or more servants, and each servant with zero or more
objects. (The association of zero objects with a servant isn't normally a permanant
condition, since connecting with objects is the reason servants exist.)
In addition to providing a namespace for child adapters, an adapter also provides a
namespace for objects. Each object managed by an adapter is associated with an
opaque sequence of bytes, the object id. An object id uniquely identifies an object
within an adapter. Typically, the servants think in terms of object ids, and the ORB
thinks in terms of object references. The adapter provides the mapping from one to
the other.
The servants may use any convenient data as object ids. For instance, a servant
representing a traditional file system (files and directories) as objects might use the
fully-qualified path name of the file as the corresponding object id.
Since an object reference refers uniquely to an object, this leads to the one-to-one
correspondence between each object reference and an <adapter, object id> pair.
Although the internal structure of an object reference is considered opaque to
applications, some ORB implementations in fact encapsulate the adapter name and
object id into the object reference, for a straightforward mapping when needed. Other
ORB implementations use lookup tables or other means to convert among object
references and <adapter, object id> pairs.
It is possible that a single object may be represented by more than one servant or
adapter. For this reason (among others), it is not in general possible to determine
always if two different object references map to the same object.
Page 2 of 7