Die CORBA-Architektur

Das Kernstück der CORBA-Architektur (siehe Abbildung 4.1^4.3) ist der ORB (Object Request Broker), der als Verbindungsglied alle Mechanismen für das Auffinden und Vorbereiten der (Server-)Objektinstanz für die entsprechende Klientanfrage bietet. Auch Transfer der Parameter, Resultate und Ausnahmen ist Aufgabe des ORBs. Durch die Festlegung des ORB-Interfaces in der CORBA-Spezifikation bietet jede Implementierung verschiedener Hersteller die gleiche Standardfunktionalität.

Figure 4.1: CORBA-Architektur

Eine Objektanfrage eines Klients kann entweder an den zugehörigen IDL-Stub oder dynamisch mit zusätzlichen Informationen an das DII gerichtet werden. Ebenfalls empfängt die Objektimplementierung die Anfrage entweder durch den aus der IDL generierten Skeleton oder durch das DSI. Anzumerken ist noch, dass im dynamischen Fall die Funktionalität des Stubs und/oder Skeletons komplex nachgebildet werden muss.

Der auf dem ORB aufsetzende OA (Object Adapter) stellt die Verbindung zwischen der Objektimplementierung und dem ORB her und bietet Zugang zu ORB-Diensten für Objekte. Als essentielle Dienste des Object Adapters sind zu nennen:

• Instanzierung, Aktivierung und Deaktivierung von Objektimplementierungen
• Bekanntgabe neuer Objekte
• Entgegennehmen von Anfragen und Weiterleitung
• Überprüfung von Zugriffsberechtigungen
• Verwaltung von Referenzen

Als standardisierter OA für alle ORBs war lange Zeit der BOA (Basic Object Adapter) eingesetzt, der aber zu unflexibel für unterschiedliche Verlange verschiedener CORBA-Implementierungen war. Der sogenannte POA (Portable Object Adapter) seit CORBA 2.2 bietet die Möglichkeit der Anpassung des OA an ORB als auch an Objekte mit unterschiedlichen Policies oder Rahmenbedingungen. Dies impliziert die Erlaubnis von mehreren POAs in der Architektur, aber auch eine Hierarchiebildung von POAs ist möglich.