Previous | Table of Contents | Next |
An object adapter (see Figure 2-8 on page 2-16) is the primary means for an object
implementation to access ORB services such as object reference generation. An object adapter exports a public interface to
the object implementation, and a private interface to the skeleton. It is built on a private ORB-dependent interface.
Object adapters are responsible for the following functions:
• Generation and interpretation of object references
• Method invocation
• Security of interactions
• Object and implementation activation and deactivation
• Mapping object references to the corresponding object implementations
• Registration of implementations
These functions are performed using the ORB Core and any additional components necessary. Often, an object adapter will maintain
its own state to accomplish its tasks. It may be possible for a particular object adapter to delegate one or more of its responsibilities
to the Core upon which it is constructed.
Dynamic Skeleton
Interface A Skeleton Interface B Skeleton
ObjectAdapter
Interface
ORB Core
Figure 2-8 The Structure of a Typical Object Adapter
As shown in Figure 2-8, the Object Adapter is implicitly involved in invocation of the
methods, although the direct interface is through the skeletons. For example, the Object Adapter may be involved in activating
the implementation or authenticating the request.
The Object Adapter defines most of the services from the ORB that the Object Implementation can depend on. Different ORBs
will provide different levels of service and different operating environments may provide some properties implicitly and require
others to be added by the Object Adapter. For example, it is common for Object Implementations to want to store certain values
in the object reference for easy identification of the object on an invocation. If the Object Adapter allows the implementation
to specify such values when a new object is created, it may be able to store them in the object reference for those ORBs that
permit it. If the ORB Core does not provide this feature, the Object Adapter would record the value in its own storage and
provide it to the implementation on an invocation. With Object Adapters, it is possible for an Object Implementation to have
access to a service whether or not it is implemented in the ORB Core—if the ORB Core provides it, the adapter simply provides
an interface to it; if not, the adapter must implement it on top of the ORB Core. Every instance of a particular adapter must
provide the same interface and service for all the ORBs it is implemented on.
It is also not necessary for all Object Adapters to provide the same interface or functionality. Some Object Implementations
have special requirements. For example, an object-oriented database system may wish to implicitly register its many thousands
of objects without doing individual calls to the Object Adapter. In such a case, it would be impractical and unnecessary for
the object adapter to maintain any per-object state. By using an object adapter interface that is tuned towards such object
implementations, it is possible to take advantage of particular ORB Core details to provide the most effective access to the
ORB.