Der Schwerpunkt des CORBA-Standards liegt in der Beschreibung der Schnittstellen, die ein ORB zur Verfügung stellt. Es werden sowohl die Aufrufschnittstellen beschrieben, über die Clients auf Objekte zugreifen können, als auch die Schnittstellen auf den Kern des ORBs (ORB-Interface).
Jedem Objekt wird durch den ORB ein eindeutiger Identifikator in Form einer Objektreferenz zugewiesen. Anhand dieser Objektreferenz kann der ORB ein Objekt lokalisieren.
Die Beschreibung der Aufrufschnittstellen von Objekten erfolgt in einer eigens dafür definierten Sprache. Diese wird als Interface Definition Language (IDL) bezeichnet. Mit dieser C-ähnlichen Sprache wird die Vererbung von Schnittstellenbeschreibungen unterstützt. Die Definition der Syntax und Semantik der IDL sowie ihre Abbildung auf die Programmiersprache C (Language Mapping) ist einer der Schwerpunkte der CORBA1.1-Spezifikation. Inzwischen sind zusätzliche Sprachabbildungen für C++ und Smalltalk definiert worden.
Der ORB hat zwei unterschiedliche Schnittstellen für Methodenaufrufe von Clients auf Objekten:
Für ein Objekt ist transparent, über welche Schnittstelle eine Methode aufgerufen wird. Ein Aufruf wird über den Object Adapter und das IDL-Skeleton, das den Server-Stub darstellt, übergeben. Der Client muß nicht wissen, in welcher Programmiersprache ein Objekt implementiert ist, auf welchem Netzknoten es sich befindet und ob es zum Zeitpunkt des Aufrufs bereits aktiv ist, oder erst aktiviert werden muß. Dem Client muß nur die Aufrufschnittstelle des Objekts bekannt sein. Dazu dient der Client-Stub bei der statischen und das Interface Repository bei der dynamischen Aufrufschnittstelle.
Der Object Adapter agiert als Bindeglied zwischen dem ORB und den Objekten. Er erfüllt folgende Aufgaben (vgl. [OMG 93a] S. 152):
Diese Funktionalität wird vom sogenannten Basic Object Adapter (BOA) erbracht, den jedes CORBA-konforme Produkt implementieren muß. Darüber hinaus sind jedoch auch andere Object Adapter für spezielle Anforderungen möglich.
Über die ORB-Schnittstelle können Clients und Objekte direkt allgemeine Dienste vom ORB nachfragen. Zu diesen Diensten gehört z.B. die Umwandlung von Objektreferenzen in Strings und wieder zurück sowie andere allgemeine Operationen auf Objektreferenzen.
Im Implementation Repository befindet sich die Information, die der ORB braucht, um Objekte zu lokalisieren und zu aktivieren. Außerdem können dort weitere implementierungsspezifische Daten, wie z.B. Debugging-Information oder Umgebungsvoraussetzungen, abgespeichert werden. Die CORBA-Spezifikation macht hierzu keine konkreten Vorschriften.
Das Interface Repository enthält die IDL-Beschreibungen der Objekte. Über Programmierschnittstellen wird diese Information zur Laufzeit verfügbar gemacht. Die IDL-Beschreibungen werden u.a. zur Konstruktion von dynamischen Methodenaufrufen und zur Typüberwachung von Parametern benötigt.
Die CORBA-Spezifikationen 1.1 und 1.2 dienen als Grundlage für zahlreiche Produktimplementierungen wie z.B. Ionas Orbix, Suns DOE (mittlerweile NEO - Network Enabled Objects), Hewlett-Packards Distributed Smalltalk und IBMs SOM/DSOM, das in dieser Diplomarbeit verwendet wurde.
Der größte Mangel von CORBA 1.x ist, daß kein Protokoll für die Interoperabilität zwischen den ORBs verschiedener Hersteller definiert wurde. Da fast jedes CORBA-Produkt eine eigene Implementierungsstrategie verfolgt, können heutige Produkte im allgemeinen nicht zusammenarbeiten. Dieses Problem wurde mit CORBA Version 2.0 [OMG 95] gelöst. Darin wird die Interoperabilität zwischen ORBs über Gateways (sogenannte Bridges) und Interoperability-Protokolle wie das GIOP (General Inter ORB Protocol) standardisiert. Damit kann ein ORB auf Objekte zugreifen, die von einem anderen ORB verwaltet werden.
Der nächste Abschnitt beschreibt das in der Diplomarbeit verwendete Produkt SOMObjects von IBM und geht darauf ein, wie die CORBA-Spezifikation dabei implementiert wurde.
