| Previous | Table of Contents | Next |
An object implementation provides the actual state and behavior of an object. The object implementation can be structured
in a variety of ways. Besides defining the methods for the operations themselves, an implementation will usually define procedures
for activating and deactivating objects and will use other objects or non-object facilities to make the object state persistent,
to control access to the object, as well as to implement the methods.
The object implementation (see Figure 2-7) interacts with the ORB in a variety of
ways to establish its identity, to create new objects, and to obtain ORB-dependent services. It primarily does this via access
to an Object Adapter, which provides an interface to ORB services that is convenient for a particular style of object implementation.
Object Implementation
Figure 2-7 The Structure of a Typical Object Implementation
Because of the range of possible object implementations, it is difficult to be definitive about how an object implementation
is structured. See the chapters on the Portable Object Adapter.
When an invocation occurs, the ORB Core, object adapter, and skeleton arrange that a call is made to the appropriate method
of the implementation. A parameter to that method specifies the object being invoked, which the method can use to locate the
data for the object. Additional parameters are supplied according to the skeleton definition. When the method is complete,
it returns, causing output parameters or exception results to be transmitted back to the client.
When a new object is created, the ORB may be notified so that it knows where to find the implementation for that object. Usually,
the implementation also registers itself as implementing objects of a particular interface, and specifies how to start up
the implementation if it is not already running.
Most object implementations provide their behavior using facilities in addition to the ORB and object adapter. For example,
although the Portable Object Adapter provides some persistent data associated with an object (its OID or Object ID), that
relatively small amount of data is typically used as an identifier for the actual object data stored in a storage service
of the object implementation’s choosing. With this structure, it is not only possible for different object implementations
to use the same storage service, it is also possible for objects to choose the service that is most appropriate for them.