Die Bestandteile von CORBA

    Die Schnittstellen von CORBA-konformen Objekten werden in einer programmiersprachenunabhängigen Notation, der sogenannten OMG Interface Definition Language, (OMG IDL) definiert . Hierdurch wird sichergestellt, daß sämtliche Objekte eines CORBA-Systems auf einheitliche Art angesprochen werden können. Clients rufen Methoden auf Server-Objekten auf, ohne beachten zu müssen, auf welcher Systemarchitektur und unter welchem Betriebssystem diese laufen; die Frage, in welcher Programmiersprache diese Objekte implementiert sind, ist für das Aufrufen von Methoden (und damit für die Kommunikation zwischen Objekten) ebenfalls irrelevant.

  

Abbildung: Die Komponenten von CORBA

Jede Objektklasse wird durch eine OMG IDL-Schnittstelle beschrieben, die sowohl die (privaten) Attribute der Klasse als auch deren (öffentliche) Methoden beschreibt; Objektklassen können Eigenschaften von einer oder mehrerer anderer Klassen erben. Neue Server-Objekte werden dem Object Request Broker (ORB) durch deren Eintragung im Interface Repository , einem ORB-weit gültigen Speicher für Schnittstellendefinitionen, bekanntgegeben. Die OMG legt über standardisierte language mappings  die Abbildung von IDL auf konkrete Programmiersprachen wie C, C++, Java, Ada oder Smalltalk fest. Anhand dieser Abbildungsvorschrift generiert ein IDL-Compiler das Server Skeleton in der jeweiligen Implementierungssprache. Der Benutzer eines Objekts erzeugt ebenfalls mit Hilfe eines IDL-Compilers den Client Stub, der ein Zugriff auf das entfernte Server-Objekt wie auf eine lokale Klasse ermöglicht.

Vom IDL-Compiler generierte Client Stubs  und Server Skeletons  bilden eine statische Schnittstelle zur Nutzung von Diensten (siehe auch Abbildung . Damit eine Anwendung auch dynamisch zur Laufzeit Dienste von Server-Objekten in Anspruch nehmen kann, deren IDL-Beschreibung zur Zeit der Übersetzung nicht vorlag, definiert CORBA das Dynamic Invocation Interface (DII) , über das Abfragen z.B. hinsichtlich der Eigenschaften von Methodenparametern zur Laufzeit oder dem Typ von Objekten gestellt werden. Zu allen im System registrierten Serverobjekten enthält das Interface Repository die IDL-Beschreibungen ihrer Schnittstellen. Mit den Typinformationen aus dieser Datenbank kann ein Client dynamisch über das DII einen Methodenaufruf an einen Server absetzen. Die höhere Flexibilität des DII im Vergleich zu den Client Stubs besteht darin, daß ein Client das Zielobjekt über das DII zur Laufzeit, d.h. dynamisch adressiert, während dies beim Client Stub zur Übersetzungszeit geschieht; der Preis für diese Flexibilität liegt in der komplizierteren Implementierung von Client-Aufrufen, da vor dem Aufruf eine oder mehrere Abfragen an das Interface Repository gestellt werden müssen. Der angesprochene Server kann DII-Aufrufe nicht von Stub-Aufrufen unterscheiden.

Auf Server-Seite ist das Dynamic Skeleton Interface (DSI)  das Äquivalent zum DII. Über diese Schnittstelle können Aufrufe an dynamisch erzeugte Objektimplementierungen übergeben werden. Diese Funktionalität wird u.a. für Gateways zu anderen Objektsystemen oder für generische Brücken zwischen ORBs benötigt.

Gewöhnlich sind Aufrufe über das statische Interface synchron : Der Client blockiert, bis er vom ORB über den Stub ein Ergebnis oder eine Fehlermeldung (Exception) erhält. Werden Operationen in IDL mit dem Schlüsselwort oneway  versehen, benutzt CORBA hierfür eine asynchrone und unzuverlässige (best effort) Aufrufsemantik, bei der keine Ergebnisse oder Ausführungsbestätigungen zurückgegeben werden. Über das DII können Methoden zusätzlich auch asynchron mit Ergebnisrückgabe ausgeführt werden ( deferred synchronous) . Der Client blockiert hierbei nicht. Über einen Polling-Mechanismus wird überprüft, ob ein Ergebnis vorliegt.

Clients identifizieren das Objekt, auf dem sie eine Methode aufrufen möchten, gegenüber dem ORB durch eine eindeutige Objektreferenz (Inter-operable Object Reference (IOR)) , ohne über den physikalischen Ort des Objekts Kenntnis besitzen zu müssen. Der ORB unterhält mit dem Implementation Repository  ein Verzeichnis, welches u.a. die Abbildung von IOR auf reale Objekte erlaubt. Damit dieser Mechanismus funktioniert, müssen sich Server-Objekte über den Basic Object Adapter (BOA)  beim ORB registrieren. Der BOA generiert für ein neues Objekt die IOR, die der ORB in seinem Verzeichnis ablegt. Auch das Aktivieren von registrierten, aber nicht gestarteten Servern bei Eintreffen einer Client-Anfrage beim ORB kann der BOA übernehmen. Clients können die Objektreferenzen zu benötigten Diensten auf verschiedene Weise ermitteln: Neben Verzeichnis- (Naming Service) und Vermittlungsdiensten (Trading Service) können auch Dateien, die IORs als Zeichenketten (stringified object references) enthalten, als Informationsquellen dienen, ebenso weitere, proprietäre Mechanismen. Hinter dem ORB Interface  verbergen sich verschiedene nützliche Funktionen sowohl für Clients als auch für Server (z.B. zur Erzeugung von stringified IORs und zur Konvertierung unterschiedlicher Datentypen).

  

Abbildung: Standardisierte Protokollstacks zur CORBA-Interoperabilität

Seit der Version 2.0 wird die Interoperabilität zwischen ORBs verschiedener Hersteller durch das General Inter-ORB Protocol (GIOP)  gewährleistet, dessen Abbildung auf unterschiedliche Protokolle standardisiert wurde. Jeder ORB muß mindestens die Kooperation auf Basis von TCP/IP über das Internet Inter-ORB-Protocol (IIOP)  unterstützen. Eventuell vorhandene proprietäre ORB-Protokolle werden mit Hilfe sogenannter Bridges  integriert, die die Konvertierung des proprietären Protokolls in IIOP vornehmen. Darüberhinaus wurde bisher unter dem Namen DCE Common Inter-ORB-Protocol (DCE-CIOP)  ein Environment-specific Inter-ORB Protocol (ESIOP)  standardisiert, das eine Abbildung von CORBA auf DCE realisiert. Weitere ESIOPs für SNA, OSI und SS.7 sind zwar angedacht, jedoch nicht in den Standardisierungsprozeß eingebracht worden. Abbildung stellt die Mechanismen zur Interoperabilität graphisch dar. Andere verteilte Objektumgebungen wie Java RMI von JavaSoft oder Microsoft DCOM/ActiveX können mit Hilfe von Gateways in CORBA integriert werden. Obwohl Mechanismen zum Interworking mit DCOM Bestandteil des CORBA-Standards ist, sind bisher nur sehr wenige Implementierungen erfolgt.