Portable Object Adapter
The client side of CORBA 2.0 is very portable, but the server side isn't. Thus ORB vendors introduced their own BOA extensions to fill in the blanks. This led to implementation inconsistencies in kay areas such as:
- Object activation/deactivation
- Naming of base skeleton classes
- Object regsitration with ORB
The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object Implementation requires.
A variety of object implementations can be supported, including separate servers, libraries, a program per method, an encapsulated application, an object oriented database, etc. Through the use of additional object adapters, it is possible to support virtually any style of object implementation.
Generally Object Implementations do not depend on the ORB or how the client invokes the object. Object Implementations may select interfaces to ORB-dependent services by the choice of Object Adapter.
Services provided by the ORB through an Object Adapter include:
Since the Object Adapter interface is something that object implementations depend upon, it is desirable that they be as few as practical.
- Generation & interpretation of object references
- Method Invocations
- Security of Interactions
- Object & Implementation activation and deactivation
- Mapping object references to implementations
- Registration of implementations
Portable Object Adapter can be used for most ORB objects w/ conventional implementations.
The intent of the POA, as it's name suggests, is to provide an Object Adapter that can be used w/ multiple ORBs w/ a minimum of rewriting needed to deal w/ different vendor's implementation.
Transient Objects only live within the process that creates them; they require minimal programming effort and overhead.
Persistent Objects typically have state; their life extends beyond the process that creates them. From the perspective of a client holding an object reference, a persistent object spans multiple server lifetimes.
Servant is a running instance of a particular implmentation.
Servant Manager POA invokes operation on servant managers to create, activate and deactivate servants. ORB vendors will provide default servant managers as well as servant managers that implement different activation/deactivation policies.
On the server side, ORB, POA & servant manager cooperate to deliver the incoming request to a particular servant.
ORB Vendor provides rootPOA. Server application can then use this rootPOA to create more specialized child POAs.
A servant Manager is registered w/ a POA as a callback object, ie it is invoked by the POA when necessary. An application server that activates all its objects at server startup does not need a servant manager.