Left Up Right CORBA

Was ist ein ORB ?

Der Object-Request-Broker ermöglicht transparent Objekt-Aufrufe (Anforderungen und Antworten) in einer verteilten Umgebung zu machen und zu empfangen. (Vorwort von CORBA2.3 Spec)

Nach Kapitel 2.1 der CORBA 2.3: ORB ist verantwortlich für alle Mechanismen, die:

betreffen.

(S.2-6:) Der Orb braucht nicht eine einzelne Komponente zu sein, muß aber das Interface definieren.

Objektadapter

Ein Objektadapter ist der normale Weg für eine Objektimplementierung, die ORB-Dienste anzusprechen. Meist werden folgende Dienstleistungen geboten: Da die verschiedensten Anforderungen gegeben sind, kann es verschiedene Schnittstellen geben.
Es gibt den BOA, und den POA, wobei der Portable Objektadapter sehr vieles andekt und besser Spezifiziert ist und bei Neientwicklungen genommen werden sollte.

ORB Interface

Es ist das selbe für alle ORBS und unabhängig vom Objektadapter. Die meiste Funktionalität wird durch die Objektadapter, Stubs, Skeletons und Dynamic-Incokation-Interfaces unterstützt.
Die wenigen Operationen sind gemeinsam für alle Objekte, sowohl für Clients und Objektimplementierungen.

Implementierungsrepository

(S. 2.1.14) Das Implementation Repository enthält Information, die es dem ORB erlaubt, Implementierungen der Objekte zu finden und zu aktivieren.

Es ist spezifisch für einen ORB oder für eine Betriebsumgebung.

Gewöhnlich wird folgendes durch Operationen des ImplemantationRepositories vollzogen:

Letzeres sind z.B. shared,... Politik vom BOA.

Zusätzlich wird im Implementation Repository haäufig noch zusätzliche mit den Implementierungen der OB-Objekte verbundene Information plaziert, beispielsweise

Eine IDL eines Implementationreposity scheint es nicht in der CORBA 2 Spezifikation zu geben, dies meint auch die MICO-Dokumentation.

Frank Pilhofer weist in seiner Diplomarbeit darauf hin, das dem POA kein Implementation Repository mehr verbunden ist. Wie die persistenten Server realisiert werden, läßt die POA Spezifikation offen, um sich nicht in das schwierige Gebiet der Service/Prozeßmanagement begeben zu müssen.

Beispiele wie ein ORB aussehen kann

Resistent in den Clients und Implementierungen
Stubs nutzen entweder einen transparente IPC-Mechanismen oder einen Lokalisierungsdienst um mit den Implementierungen eine Verbindung aufzubauen.
Dazu wird Code zur Implementierung hinzugebunden, die die passende Datenbasis zur Benutzung mit den Clients auszusetzen.
Dies ist die übliche Implementierung.
Serverbasierter ORB
Clients und Implementierungen können alle mit einem oder mehreren Servern kommunizieren. Die Server routen die Anforderungen zu dem Implementierungen.
So kann der ORB ein normales Programm sein, bis auf die Sachen, wo das betriebssystem betroffen ist. Normale IPC-Mechanismen können zur Kommunikation mit dem ORB benutzt werden.
Systembasierter ORB
Der ORB wird als grundlegender Dienst des darunterliegenden Betriebssystem angeboten. Objektreferenzen können unfälschbar gemacht werden, und so dier umfang der Autentifikation bei jedem Aufruf reduziert werden.
Da das Betriebssyetem den ORB und die Struktur der Clients und der Implementationen kannt, können diverse Optimierungen gemacht werdenn, z.B. die Vermeidung des Marshalling, wenn beide auf dem selben Rechner sind.
Library basierter ORB
Für leichtgewichtige Objekte, deren Implementierungen geteilt werden können, kann die Implementierung auch in einer Bibliothek sein. In diesem Fall sind dann die Stubs einfach die tatsächlichnen Metheoden.
Dies setzt vorraus, daß es sem Clientprogramm möglich ist,auf die Daten der Objekte zuzugreifen und die Implementierung der Anwendung vertraut, daß es die daten nicht beschädigt.
Arbeitsgruppe Komponenten/CORBA Informatik- und Netzwerkverein Ravensburg e.V Rudolf Weber