Portable Object Adapter

from Wikipedia, the free encyclopedia

The POA ( P ortable O bject A dapter ) was first in the CORBA specified specification 2.2 and is the successor to the Basic Object Adapter (BOA). The adapter controls call requests (calls) to objects in the server and forwards them to the implementation. This separates the CORBA object (as an interface to the desired functionality) from the actual implementation. The term 'servant' was introduced for implementation. The separation between object and implementation allows very fine control of access on the server side, which is completely invisible to the client (caller).

POA in the Corba context

tasks

  • Instantiation of server objects (servants) as required (via Servant Manager)
  • Connect the servants with object references (Active Object Map)
  • Generation and interpretation of object references
  • Forwarding inquiries to the appropriate servants
  • Activate / deactivate the servants

properties

POAs form a tree with the "RootPOA" as the root. The RootPOA is the only POA that exists after the ORB has been initialized.

Here is an example in Java for obtaining the RootPOA: 

 org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(new String[0], new Properties());
 org.omg.CORBA.Object obj = orb.resolve_initial_references("RootPOA");
 org.omg.PortableServer.POA poa = org.omg.PortableServer.POAHelper.narrow(obj);

Each POA offers methods for creating new POA instances, which then become children of this POA. Each POA maintains an "Active Object Map" in which the objects are entered with their associated servant. Each object can be entered (activated) exactly once in the map.

The motivation for creating new POAs lies in the large number of different policies that can be assigned to a POA when it is created. The policies of the RootPOA do not always fit the specific application.

"POA managers" exist parallel to the POAs. POA managers can set the POA assigned to them to various states 'active', 'hold', 'discard' and thus allow calls to the POA to pass, save or discard. There is at least one POA manager (that of the RootPOA) and never more managers than POAs. When creating a new POA, an existing POA manager can be given or a new one can be created.

application

  • If heavy objects have to be created, these objects are created by the Servant Manager, which only creates the objects when they are actually called. This speeds up the start of a server.
  • If a large number of objects have to be created, a single servant (default servant) can be used to answer all queries. This approach is known from Flyweight . There is also the option of using a servant locator that creates a new servant for each call. In both cases, an entry in the Active Object Map is not necessary.
  • If the number of server objects exceeds the server's resources, it can activate / deactivate the servants and store the necessary data in an external storage medium (database, file). The Servant Manager would then regenerate the objects if needed.
  • If object references have to be valid for a longer period of time (months), a POA is required that outputs references that survive a restart (lifecycle policy)

Web links