3.6 Die Common Object Request Broker Architecture (CORBA)

  Common Object Request Broker Architecture (CORBA) ist ein offener Standard für verteilte Objekte. Er entstand aus der 1989 gegründeten, herstellerunabhängigen Object Management Group (OMG), die heute das weltweit größte Software-Konsortium ist. Der Trend zu objektorientierten und verteilten Anwendungen, der auf der zunehmenden Vernetzung von Computern und gleichzeitiger Etablierung objektorientierter Programmiersprachen basiert, erforderte ein Kommunikationsparadigma, welches die Interoperabilität von Software-Komponenten (Objekten) innerhalb einer heterogenen, vernetzten Systemlandschaft erlaubt. CORBA stellt eine Infrastruktur bereit, mit deren Hilfe verteilte Objekte unabhängig von der zugrundeliegenden Netztechnologie, unabhängig vom Betriebssystem und unabhängig von der Programmiersprache, in der sie realisiert sind, Interaktionen in Form von Methodenaufrufen eingehen können. Diese drei Ebenen der Heterogenität werden vor dem Software-Entwickler verschattet.

Es ist unmöglich im Rahmen dieser Arbeit eine ausführliche Einführung in CORBA zu bieten. Diese Aufgabe ist der Sekundärliteratur zu CORBA (z.B. [OHE96,Sie96]) überlassen. Technische Details sind in der CORBA-Spezifikation [Obj95] zu finden. Gute Tutorials ([Sch96b,Sch96c,Sch96a]) bietet Douglas C. Schmidt kostenlos über das Web an. Zur Programmierung von CORBA-Objekten in Java (siehe auch Kapitel 6) können [OH97] und [VD97,Vog97] empfohlen werden. Der folgende kurze Überblick über die wichtigsten Aspekte von CORBA ist an [Sta97] angelehnt.

 

Abbildung 3.16:  Die Object Management Architecture (OMA)

23#23

CORBA ist eigentlich nur der Standard für die wichtigste Komponente der Object Management Architecture (Abbildung 3.16), nämlich des Object Request Broker (ORB). Der Broker stellt einen Vermittlungsmechanismus zum Aufruf von Methoden auf entfernten Objekten bereit, indem er den Aufruf eines Clients einschließlich Parameter an ein Server-Objekt weiterleitet und umgekehrt Ergebnisse bzw. Fehler zurückgibt. Ebenso übernimmt er die Lokalisierung der Server-Objekte. Auf dem ORB bauen die übrigen Komponenten der Referenzarchitektur OMA auf. Die Object Services sind standardisierte, fundamentale Dienste, die für die Entwicklung von verteilten, objektorientierten Anwendungen erforderlich sind. Diese decken immer wieder benötigte Funktionen wie das Auffinden von Objekten (Naming-Service), das Kreieren, Kopieren, Verschieben oder Löschen von Objekten (Lifecycle-Service), der Versand von asynchronen Ereignismeldungen (Event-Service) oder die persistente Speicherung von Objekten (Persistent-Object-Service) ab. Auf einer höheren Ebene standardisieren die Common Facilities infrastrukturelle Dienste wie Komponententechnologien (z.B. JavaBeans) für Verbunddokumente oder Administrationsfunktionen. Die Common Facilities sind dabei unabhängig von einem bestimmten Anwendungsbereich (Domäne). Für spezielle Domänen wie Gesundheitswesen, Finanzdienstleistungen, Transport oder Telekommunikation bilden die Domain Interfaces standardisierte Rahmenwerke. Nicht standardisiert sind natürlich die von den Software-Entwicklern erstellten Anwendungen in Form von Application Objects. In dieser Arbeit dienen die Anwendungsobjekte zur Realisierung eines Agenten und zugehöriger Managementanwendung.

Zur Verschattung der Heterogenität zieht die Broker-Architektur mehrere Abstraktionsschichten zwischen der Plattform, bestehend aus Netztechnologie und Betriebssystem, und der Anwendung ein. Der ORB vermittelt Nachrichten zum Transport von Methodenaufrufen eines Clients an ein Server-Objekt sowie umgekehrt zur Übermittlung von Ergebnissen oder Ausnahmen. Der Client muß nicht wissen, wo sich das Server-Objekt physikalisch befindet. Er benötigt lediglich eine Referenz auf den Server, anhand derer der ORB das Objekt über ein Verzeichnis lokalisiert. Hierzu ist es erforderlich, daß die Server-Objekte ihre Verfügbarkeit beim ORB anmelden. Eine weitere Abstraktionsschicht stellen Proxy-Objekte dar. Der Aufruf einer Methode auf einem entfernten Objekt soll sich nicht von einem auf einem lokalen Objekt unterscheiden. Hierzu dienen Stellvertreterobjekte (Proxies), die auf dem ORB aufsetzen. Auf Client-Seite verfügt ein Proxy über die gleiche Schnittstelle wie das entfernte Server-Objekt. Der Client ruft eine Methode auf dem Proxy auf. Dies führt - für den Client unsichtbar - zum Generieren einer plattformunabhängigen Nachricht, die der ORB weitertransportiert. Das Proxy wartet auf das Ergebnis, welches es dem Aufrufer im lokalen Format zurückgibt. Auf Server-Seite gibt es analog dazu ein Server-Proxy, welches gegenüber dem Server als lokaler Client auftritt. In einem großen Netz können mehrere ORBs (unterschiedlicher Hersteller und auf verschiedenen Betriebssystemen) an der Nachrichtenvermittlung beteiligt sein. Zur reibungslosen Kooperation der ORBs untereinander bedarf es eines gemeinsamen, standardisierten Kommunikationsprotokolls.

 

Abbildung 3.17:  Die Struktur des CORBA 2.0 Object Request Broker

24#24

CORBA realisiert die beschriebene Architektur. Die Struktur des ORB ist in Abbildung 3.17 dargestellt. Die Proxy-Objekte, sog. Stubs auf Client-Seite und Skeletons auf Server-Seite, setzen auf dem Kern des ORB auf. CORBA definiert mit der Interface Definition Language (IDL) eine eigene Sprache, um die Unabhängigkeit von einer bestimmten Programmiersprache für Client und Server zu ermöglichen. IDL ist eine an C++ angelehnte Sprache zur Definition von Schnittstellen für Dienste, die ausschließlich Konstrukte zur Beschreibung von Attributen, Methoden und Datentypen eines Objekts enthält. Ein Server-Objekt beschreibt die Zugriffsmöglichkeiten auf seine Dienstschnittstelle für einen Client in Form einer IDL-Spezifikation. Die OMG legt über standardisierte language mappings die Abbildung von IDL auf konkrete Programmiersprachen wie C++, Java 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 Stubs und Skeletons bilden eine statische Schnittstelle zur Nutzung von Diensten. 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). Zu allen im System registrierten Serverobjekten enthält das Interface Repository (IR) die IDL-Beschreibungen ihrer Schnittstellen. Mit den Typinformationen aus dieser Datenbank kann ein Client dynamisch über das DII einen Methodenaufruf an einen Server absetzen. Der Server kann DII-Aufrufe nicht von Stub-Aufrufen unterscheiden. Auf Server-Seite ist das Dynamic Skeleton Interface 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 Ausnahme 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 (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 physikalische Objektposition 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 ermitteln die Objektreferenzen zu benötigten Diensten über Verzeichnisdienste (Naming-Service), Trader, aus Dateien, die IORs als Zeichenketten (stringified object references) enthalten, oder durch proprietäre Mechanismen. Hinter dem ORB interface verbergen sich verschiedene nützliche Funktionen sowohl für Clients als auch für Server.

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 vorhandene Protokollwelten wie TCP/IP oder OSI standardisiert wurde. Jeder ORB muß zumindestens die Kooperation auf Basis von TCP/IP über das Internet Inter-ORB-Protocol (IIOP) unterstützen. Brücken dienen zur Konvertierung zwischen proprietären ORB-Protokollen und IIOP bzw. GIOP-Implementierungen für andere Basisprotokolle. Damit können auch Anschlüsse von CORBA an andere verteilte Objektumgebungen wie Java RMI von JavaSoft oder Microsoft DCOM geschaffen werden.