Portable Object Adapter

The POA (Portable Object Adapter ) was first specified in the CORBA specification 2.2 and is the successor to the Basic Object Adapter (BOA). The adapter checks the server invocation requests (calls ) to objects and passes them on to the implementation. So that a separation of the CORBA object is reached ( as an interface to the desired functionality ) on the actual implementation. For the implementation of the concept of ' Servant ' has been introduced. The separation between the object and implementation allows a very fine control access to the server side for the client ( caller ) is completely invisible.

Tasks

  • Instantiation of the server objects ( Servants ) as required ( about Servant Manager)
  • Connect the Servants with object references (Active Object Map )
  • Generation and interpretation of object references
  • Forwarding of requests to the appropriate Servants
  • Enabling / Disabling the Servants

Properties

POA form a tree with the " RootPOA " as root. The RootPOA is the only POA which is present after the initialization of the ORB.

Here is an example in Java for the procurement of RootPOA:

Org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init ( new String, 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 provides methods for generating new POA instances, the children then this will be POA. Each POA maintains an " Active Object Map ", in which the objects are registered with their respective Servant. Each object can be entered only once in the map ( enabled).

The Motiviation for generating new POA is the number of different policies, which can be given a POA in the production. The policies of the RootPOA not always be suitable for the specific application.

Parallel to the POA exist " POA Manager". POA managers to their assigned POA in various states 'active ', ' hold', ' discard ' and thus enable happen, save or discard allow calls to the POA. There is at least one POA manager ( that of the RootPOA ) and never more a manager than POAs. In the generation of a new POA existing POA manager can be provided, or be generated one new.

Application

  • Must weighty objects are created, the generation of these objects is handled by the Servant Manager which only creates the objects, when in fact a call is made. This makes it possible to accelerate the start of a server.
  • If very many objects are created, a single Servant offers itself (default servant ), answer all requests. This approach is known from Flyweight. There is also the possibility to use a Servant locator that generates a new Servant for each call. In both cases, an entry in the Active Object Map is not necessary.
  • Break the number of server objects the server's resources, this can enable / disable the Servants and store the necessary data in an external storage medium ( database file). The Servant manager would then create objects again if needed.
  • Must be valid object references over a longer period (months ), a POA is required, the outputs such references that survive a reboot ( Lifecycle Policy)
Common Object Request Broker Architecture
657117
de