How does a CORBA server deal with millions of small objects? Who manages the object references? How are these references stored persistently? In theory, the answer to all these questions is the object adapter, CORBA's version of a TP monitor for objects. An object adapter registers the application's classes, instantiates new objects, gives them unique IDs, advertises their existence, invokes their methods when clients request it, and manages concurrent requests for their services (see the figure "
The Structure of a Typical Object Adapter
"). More sophisticated object adapters will also provide transaction management, load balancing, and fine-grai
ned security.
An object adapter defines whether activating an object means creating a new process, creating a thread in an existing process, or reusing an existing thread or process. Servers may support a variety of object adapters to satisfy different types of requests. For example, an object database may want to implicitly register all its fine-grained objects without issuing individual calls to the object adapter. In such a case, it doesn't make sense for an object adapter to maintain per-object state, so the object database can provide a special-purpose object adapter that interfaces with the ORB core and at the same time meets its own special requirements.
OMG prefers not to see a proliferation of object adapters. So CORBA specifies a BOA (basic object adapter) that can be used in many cases. CORBA requires that every ORB supply a BOA.
Today's object adapters aren't on par with TP monitors, but we expect this to change now that the object transaction and concurrency services have bee
n adopted. TP monitor vendors may be the first to offer massively parallel object adapters that can orchestrate millions of server objects.
illustration_link (16 Kbytes)
The object adapter:
1. Registers server classes with the implementation repository.
You can think of the implementation repository as a persistent store managed by the object adapter.
2. Instantiates new objects at run time.
The number of instances created is a function of demand for services. The adapter is responsible for balancing the supply of objects with the incoming client demands.
3. Generates and manages object references.
The object adapter assigns references (unique IDs) to the new objects it creates. It's responsible for mapping between implementatio
n-specific and ORB-specific representations of object references.
4. Broadcasts the presence of the object servers.
The object adapter may broadcast the services it provides on the ORB, or it may respond to directory queries from the ORB core. Either way, it's job is to tell the outside world about the services it manages. Eventually, we expect to see tight integration with global directory services, such as X.500.
5. Handles incoming client calls.
The object adapter interacts with the top messaging layer of the ORB communication stack, peels off the request, and hands it to the interface skeleton. The skeleton interprets the incoming parameters and presents them in a form that's acceptable to the object's method invocation.
6. Routes the up-call to the appropriate method.
The object adapter is implicitly involved in the invocation of the methods described in the skeleton stubs. It may be involved in activating the implementat
ion and can authenticate incoming requests.
Is an Object Adapter a TP Monitor?
