Portable Object Adapter

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Der POA (Portable Object Adapter) wurde erstmals in der CORBA-Spezifikation 2.2 spezifiziert und ist der Nachfolger des Basic Object Adapter (BOA). Der Adapter kontrolliert im Server Aufrufanforderungen (Aufrufe) an Objekte und leitet diese an die Implementierung weiter. Damit wird eine Trennung des CORBA-Objekts (als Schnittstelle zu der gewünschten Funktionalität) von der tatsächlichen Implementierung erreicht. Für die Implementierung wurde der Begriff 'Servant' eingeführt. Die Trennung zwischen Objekt und Implementierung erlaubt eine sehr feine Steuerung des Zugriffs auf der Serverseite, die für den Client (Aufrufer) völlig unsichtbar ist.

POA im Corba Kontext

Aufgaben[Bearbeiten]

  • Instanziierung der Serverobjekte (Servants) nach Bedarf (über Servant Manager)
  • Verbinden der Servants mit Objektreferenzen (Active Object Map)
  • Generierung und Interpretation von Objektreferenzen
  • Weiterleiten von Anfragen an die passenden Servants
  • Aktivieren/Deaktivieren der Servants

Eigenschaften[Bearbeiten]

POA bilden einen Baum mit dem "RootPOA" als Wurzel. Der RootPOA ist der einzige POA, der nach der Initialisierung des ORB vorhanden ist.

Hier ein Beispiel in Java zur Beschaffung des 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);


Jeder POA bietet Methoden zur Erzeugung neuer POA-Instanzen, die dann Kinder dieses POA werden. Jeder POA pflegt eine "Active Object Map", in der die Objekte mit ihrem zugehörigen Servant eingetragen werden. Jedes Objekt kann genau einmal in der Map eingetragen (aktiviert) sein.

Die Motivation zur Erzeugung neuer POA liegt in der Vielzahl unterschiedlicher Policies, die einem POA bei der Erzeugung mitgegeben werden können. Die Policies des RootPOA passen nicht immer für den konkreten Anwendungsfall.


Parallel zu den POA existieren "POA Manager". POA-Manager können die ihnen zugeordneten POA in verschiedene Zustände 'active', 'hold', 'discard' versetzen und damit Aufrufe an die POA passieren, speichern oder verwerfen lassen. Es gibt mindestens einen POA-Manager (der des RootPOA) und nie mehr Manager als POAs. Bei der Erzeugung eines neuen POA kann ein existierender POA-Manager mitgegeben werden oder auch ein neuer erzeugt werden.

Anwendung[Bearbeiten]

  • Müssen schwergewichtige Objekte erzeugt werden, wird die Erzeugung dieser Objekte vom Servant Manager übernommen, der die Objekte erst dann erzeugt, wenn tatsächlich ein Aufruf erfolgt. Damit lässt sich der Start eines Servers beschleunigen.
  • Müssen sehr viele Objekte erzeugt werden, bietet sich ein einziger Servant (default servant) an, der alle Anfragen beantwortet. Dieser Ansatz ist aus Flyweight bekannt. Ebenso gibt es die Möglichkeit, einen Servant Locator zu verwenden, der für jeden Aufruf einen neuen Servant erzeugt. In beiden Fällen ist ein Eintrag in die Active Object Map nicht notwendig.
  • Sprengt die Anzahl der Serverobjekte die Ressourcen des Servers, kann dieser die Servants aktivieren/deaktivieren und die notwendigen Daten in einem externen Speichermedium (Datenbank, Datei) ablegen. Der Servant Manager würde dann die Objekte erneut erzeugen, falls benötigt.
  • Müssen Objektreferenzen über einen längeren Zeitraum (Monate) gültig sein, wird ein POA benötigt, der solche Referenzen ausgibt, die auch einen Neustart überleben (Lifecycle-Policy)

Weblinks[Bearbeiten]