Informationsmodell

 

CORBA bietet neben den Vorteilen objektorientierter Programmiersysteme (z.B. Kapselung, Datenabstraktion, Vererbung, Polymorphie) per Definition die Möglichkeit, verteilte (Management-) Anwendungen so zu implementieren, daß deren einzelne Module interagieren können, ohne die Spezifika der darunterliegenden Kommunikations- bzw. Systemarchitekturen beachten zu müssen, da die Modulschnittstellen in einer einheitlichen Schnittstellen-Beschreibungssprache ( Interface Definition Language, IDL)  offengelegt sind. Die in Abschnitt angesprochenen acht Ausprägungsformen von Verteilungstransparenz werden durch CORBA nahezu vollständig erfüllt: Lediglich die Bedingung der Migrationstransparenz umfaßt Festlegungen, die über den Umfang von CORBA hinausgehen (z.B. an die Programmiersprache und evtl. vorhandene virtuelle Maschinen) und kann folglich nur dann von CORBA erfüllt werden, wenn diese zusätzlich bereitgestellt werden. Dies liegt jedoch außerhalb des Umfangs der Festlegungen zu CORBA. Wir werden diesen Punkt in Kapitel eingehender behandeln. An dieser Stelle sei daher lediglich darauf hingewiesen, daß die Beschreibung der Modulschnittstellen in IDL nicht die Portabilität der Module impliziert, da diese in der Regel die besonderen Eigenschaften einer spezifischen Systemplattform nutzen und daher nicht ohne weiteres auf ein anderes Zielsystem migriert werden können.

Die kleinste Einheit der Verteilung bei CORBA ist ein einzelnes Objekt; durch das Fehlen des aus dem OSI-Management bekannten Package-Konzeptes entfällt die Möglichkeit, die Ausgestaltung eines Objekts (und damit sein Verhalten) bei seiner Instantiierung von der Erfüllung frei definierbarer Bedingungen abhängig zu machen. Eine Konsequenz davon ist, daß sämtliche Instanzen einer Objektklasse identisches Verhalten aufweisen und kein late binding möglich ist. Instanzen derselben Objektklasse werden anhand ihrer abweichenden Objektreferenzen unterschieden; umgekehrt ist es durchaus möglich, daß eine Instanz mehrere Objektreferenzen besitzt. Letzteres verdeutlicht, daß Objektreferenzen keine interne Struktur besitzen und daher nichts über die Anordnung des Objekts in Bezug zu anderen Objekten aussagen (Enthaltensein, Registrierung usw.).

Das CORBA-Analogon zu Managementoperationen besteht im Aufruf einer Methode eines anderen Objekts. Ferner werden Objekte über ihre Schnittstelle und nicht ihren Namen angesprochen. Diese Schnittstellen werden, wie bereits oben erwähnt wurde, in einer programmiersprachenunabhängigen Notation, der sogenannten OMG Interface Definition Language, (OMG IDL) beschrieben. Hierdurch wird sichergestellt, daß sämtliche Objekte eines CORBA-Systems auf einheitliche Art angesprochen werden können, ohne beachten zu müssen, auf welcher Systemarchitektur und unter welchem Betriebssystem diese laufen. Die Frage, in welcher Programmiersprache Managementobjekte implementiert sind, ist für die Kommunikation zwischen diesen ebenfalls irrelevant.

Hinsichtlich der Definition der von einem Objekt ausgesandten asynchronen Ereignismeldungen ergeben sich im Vergleich zu OSI weitere Unterschiede: In CORBA sind von einem Objekt ausgehende asynchrone Ereignismeldungen nicht Bestandteil der Objektdefinition, da hier Ereignisse wie ,,Operationen in umgekehrter Richtung`` ablaufen, d.h. als Methodenaufruf am Empfängerobjekt sichtbar sind. Asynchrone Ereignismeldungen werden somit an der Schnittstelle des empfangenden Objekts durch eine dort definierte Methode entgegengenommen.