Bis zur Version 2.1 spezifizierte CORBA lediglich einen Basic Object Adapter (BOA), der allerdings vor allem bei komplexeren CORBA-Servern einigen Interpretationsspielraum bot bzw viele notwendige Funktionen nicht unterstützte. Seit CORBA 2.2 ist nun der Portable Object Adapter (POA) spezifiziert, der wesentlich umfangreicher und genauer spezifiziert ist als sein Vorgänger.
Für die Einführung des POA war keine Protokolländerung erforderlich, sodass auch ältere Clients mit einem Server mit POA-Unterstützung uneingeschränkt kommunizieren können. Alle POA-spezifischen Informationen werden im Object Key kodiert. Diese Informationen müssen vom Client nicht ausgewerten werden können, sondern nur bei einem Methodenaufruf an den Server übergeben werden, der diese auswertet, um den passenden Servant zu finden bzw zu erzeugen.
Im Gegensatz zum BOA ist es nun beim POA auch möglich, mehrere POAs innerhalb eines Servers zu haben, die hierarchisch strukturiert sind. So können für verschiedene Objekte auch verschiedene Policies definiert werden, um den unterschiedlichen Anforderungen gerecht zu werden. Die POA-Spezifikation definiert die folgenden Policies, über die das Verhalten des Object Adapters konfiguriert werden kann:
Thread (siehe CORBA und Threads)
Lifespan
transient: die Lebenszeit des Objektes ist durch die Lebenszeit des Servers, in dem es läuft, beschränkt.
persistent: das Objekt kann länger exisitieren als der Server, in dem es ursprüunglich gestartet wird.
Id Uniqueness
unique id: ein Servant ist für genau eine Object-Id zuständig.
multiple id: ein Servant ist für mehrere Object-Ids zuständig.
Id Assignment
user: Object Ids werden vom Programmierer vergeben
system: Object Ids werden von der CORBA-Implementierung vergeben
Implicit Acitivation
implicit activation: implizite Aktivierung von Servants, wenn auch SYSTEM_ID und RETAIN gesetzt sind.
no implicit activation: keine implizite Aktivierung von Servants.
Servant Retention
retain: die Lebensdauer des Servants ist länger als ein Methodenaufruf
non retain: die Lebensdauer des Servants ist auf einen Methodenaufruf beschränkt
Request Processing
use active object map only: der POA schaut nur in der active object map nach bereits laufenden Servants.
use default servant: wird die Objekt-Id nicht in der active object map gefunden, wird ein default servant verwendet.
use servant manager: wird die Objekt-Id nicht in der active object map gefunden, wird ein servant manager herangezogen, um den Servant zu finden/erzeugen.
Der POA aktiviert Objekte nicht automatisch, sondern alle Objekte müssen vom Server explizit mit activate_object oder activate_object_with_id aktiviert werden.
Hier sucht der POA zuerst in der active object map, verwendet aber anschließend einen ServantActivator, wenn das Objekt nicht gefunden wurde.
Wird ein Objekt in der active object map nicht gefunden, wird ein default servant verwendet.
Der POA verwendet einen ServantLocator, um das Objekt zu finden.
Alle Objekte werden von einem default servant bedient.
Vor allem bei Verwendung eines default servant ist es meist notwendig, dass dieser Servant in irgendeiner Art und Weise an Objekt-spezifische Daten gelangt. Dadurch, dass einem CORBA-Objekt kein Objekt direkt im Server zugeordnet ist, hat der Servant vorerst einmal keine Informationen über das spezifische Objekt. In manchen Fällen, wenn sich die Daten des Objektes auf wenige Byte beschränken, können die Daten jedoch im Object Key gespeichert werden. Bei größeren Datenmengen kann im Object Key ein Schlüssel in einer Datenbank (das kann eine Hash-Table im Speicher sein oder auch eine richtige Datenbank) abgelegt werden. Der Servant braucht nun also nur mehr Zugriff auf den Object Key zu haben. Um dies zu ermöglichen, wurde in der CORBA-Spezifikation das Current-Objekt spezifiziert, das während eines Methoden-Aufrufs im Server thread-spezifisch Zugriff auf die Object Id erlaubt. An die Referenz des Current-Objekts gelangt man CORBA-typisch durch resolve_initial_references mit POACurrent als Parameter.