CORBA – Object Adapters
Object Adapters
The CORBA specification defines the concept of an object adapter. An object adapter is a framework for implementing CORBA objects. It provides an API that object implementations use for various low level services. According to the CORBA specification, an object adapter is 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
The architecture supports the definition of many kinds of object adapters. The specification includes the definition of the basic object adapter (BOA). In the previous section, you saw some server code that uses the services of VisiBroker’s implementation of the BOA. The BOA has been implemented in various CORBA products. Unfortunately, since the specification of the BOA was not complete, the various BOA implementations differ in some significant ways. This has compromised server portability.
To address this shortcoming, an entirely new object adapter was added, the portable object adapter (POA). Unfortunately, the POA is not yet supported in many products. In any event, the BOA and the POA are described here.
Activation on Demand by the Basic Object Adapter (BOA)
One of the main tasks of the BOA is to support on-demand object activation. When a client issues a request, the BOA determines if the object is currently running and if so, it delivers the request to the object. If the object is not running, the BOA activates the object and then delivers the request.
The BOA defines four different models for object activation:
| Shared server | Multiple active objects share the same server. The server services requests from multiple clients. The server remains active until it is deactivated or exits. |
| Unshared server | Only one object is active in the server. The server exits when the client that caused its activation exits. |
| Server-per-method | Each request results in the creation of a server. The server exits when the method completes. |
| Persistent server | The server is started by an entity other than the BOA (you, operating services, etc.). Multiple active objects share the server. |
Portable Object Adapter (POA)
According to the specification, “The intent of the POA, as its name suggests, is to provide an object adapter that can be used with multiple ORB implementations with a minimum of rewriting needed to deal with different vendors’ implementations.” However, most CORBA products do not yet support the POA.
The POA is also intended to allow persistent objects — at least, from the client’s perspective. That is, as far as the client is concerned, these objects are always alive, and maintain data values stored in them, even though physically, the server may have been restarted many times, or the implementation may be provided by many different object implementations.
The POA allows the object implementor a lot more control. Previously, the implementation of the object was responsible only for the code that is executed in response to method requests. Now, additionally, the implementor has more control over the object’s identity, state, storage, and lifecycle.
The POA has support for many other features, including the following:
- Transparent object activation
- Multiple simultaneous object identities
- Transient objects
- Object ID namespaces
- Policies including multithreading, security, and object management
- Multiple distinct POAs in a single server with different policies and namespaces
For more detail on the POA, please see the specification.
A word on multithreading. Each POA has a threading policy that determines how that particular POA instance will deal with multiple simultaneous requests. In the single thread model, all requests are processed one at a time. The underlying object implementations can therefore be lazy and thread-unsafe. Of course, this can lead to performance problems. In the alternate ORB-controlled model, the ORB is responsible for creating and allocating threads and sending requests in to the object implementations efficiently. The programmer doesn’t need to worry about thread management issues; however, the programmer definitely has to make sure the objects are all thread-safe.
