Ein objektorientierter Remote Procedure Call Corba-Technik soll Applikationen in heterogenen Netzen aufrufen

20.08.1993

*Michael Santifaller ist Geschaeftsfuehrer der Santix Software GmbH und Mitentwickler der OSF-Middleware-Technik Distributed Computing Environment (DCE).

Objektorientierte Techniken nehmen als Mittler zwischen Systemen unterschiedlicher Hersteller eine Schluesselposition ein. Die Common Object Request Broker Architecture (Corba) stellt in diesem Zusammenhang nicht nur die erste einsetzbare Technik fuer die Nachrichtenuebermittlung in heterogenen Umgebungen dar, sondern scheint sich bereits als allgemein akzeptierter Standard etabliert zu haben.

Corba ist die erste einsetzbare Technologie der Object Management Group (OMG). Die Funktion dieser Technik entspricht im wesentlichen dem Remote Procedure Call von Unix-Systemen. Dort werden damit netzweit Applikationen aufgerufen. Als Messaging- System hat der Object Request Broker (ORB) eine aehnliche Aufgabe, ist aber nicht auf eine bestimmte Systemumgebung festgelegt. Corba ist auf den Einsatz in heterogenen DV-Welten ausgerichtet.

Als eine noch sehr junge Technologie weist Corba eine Anzahl von Maengeln auf. Dazu zaehlen in erster Linie das Fehlen eines Interoperabilitaets-Standards fuer Corba-Umgebungen. Das bedeutet, dass die ersten auf dem Markt erhaeltlichen Corba- Implementierungen nicht direkt zusammenarbeiten werden.

Darueber hinaus fehlen Dienste zum Beispiel fuer die Objektverwaltung, Ereignismeldung oder Zugriffskontrolle, ohne die ein verteiltes Objektsystem unvollstaendig bleibt.

Die OMG beschaeftigt sich jedoch zur Zeit damit, im Rahmen einer Technologieausschreibung Spezifikationsvorschlaege fuer diese und andere Dienste zu evaluieren.

Die Version 1.1 von Corba wurde im Dezember 1991 veroeffentlicht. Ihre Spezifikation ist bereits in die Entwicklung einiger wichtiger zukuenftiger Technologien, darunter das Distributed Object Everywhere (DOEder Firma Sunsoft, das Distributed System Object Manager (DSOM) von IBM oder das Distributed Management Environment (DME) der Open Software Foundation (OSF), eingeflossen.

Die Corba-Spezifikation besteht aus folgenden Komponenten:

- dem Corba Object Model, basierend auf dem Objektmodell der OMG, das die Eigenschaften und das Verhalten von Corba-Objekten definiert,

- der Common Object Request Broker Architecture selbst, die im wesentlichen die Funktionen eines Object Request Broker beschreibt,

- der Interface Definition Language (IDL), einer Definitionssprache fuer Schnittstellen zu Objekten, inklusive deren

Abbildung auf die Programmiersprache C,

- dem Dynamic Invocation Interface (DII), einem Application Programming Interface (APIfuer den Zugriff auf Objekt- Schnittstellen,

- dem ORB-Interface API fuer zusaetzliche ORB-Management-Funktionen,

- dem Interface Repository in seinen IDL-Definitionen, das dazu verwendet werden kann, Aufrufe an Objekte zu ueberpruefen oder deren Eigenschaften zu ermitteln sowie

- dem Basic Object Adapter (BOA), der die Schnittstelle zwischen ORB und dem implementierten Objekt darstellt.

Fuer die Bedeutung dieser Technik spricht, dass sich die Mitglieder von Common Open System Environment (COSE), einem Konsortium zur Standardisierung von offenen Systemumgebungen, auf Corba als fuer alle verbindliche Schnittstelle festgelegt hat. Der Gruppe gehoeren IBM, HP, Novell, SCO, Sunsoft, USL und inzwischen auch DEC an.

Im Juli 1993 haben IBM, HP und Sunsoft darueber hinaus ihre Zusammenarbeit bei der Entwicklung Sourcecode-kompatibler Implementierungen der Corba-Spezifikationen angekuendigt. Sunsoft liefert inzwischen auch eine Corba-kompatible Version ihrer Tooltalk-Applikationsplattform.

Mit Hilfe der IDL werden Schnittstellen definiert, die in etwa einer Klassendefinition in

Cii gleichen. Wie diese objektorientierte Programmiersprache unterstuetzt IDL multiple Vererbung von Schnittstellen-Definitionen und Polymorphismus von Operationen.

Ein IDL-Compiler erzeugt aus der Interface Definition Language sogenannte Stubs, kleine Subroutinen, die in das aufrufende Programm eingebunden werden koennen und die die Interaktion mit dem Request Broker abwickeln.

Der Zugriff auf den Zustand eines Objekts ist vollkommen methodenbasierend. Programmierer sollten darueber hinaus wissen, dass der Typ Object implementationsspezifisch ist, da er mindestens Angaben ueber die Identitaet des Zielobjekts, der sogenannten Objektreferenz, enthaelt, die aber zwischen verschiedenen ORB- Implementierungen unterschiedlich sein koennen. Durch den opaken (nicht transparenten) Typ Object wird hier zumindest die Quellcode-Kompatibilitaet erleichtert.

Darueber hinaus unterstuetzt IDL noch den Datentyp "sequence" fuer Reihen. Er ist in etwa mit einer Reihe von Zeigern zu vergleichen. Fuer die Uebergabe von erst zur Laufzeit definierten, beliebigen Datentypen, aehnlich einem "void *", existiert der Typ "any", der den durch ihn uebergebenen Datentyp durch sogenannte Typecodes selbst beschreibt. Weitere Datentypen sind "string", "boolean" und "octet". Als zusaetzliche Operatoren gegenueber C und Cii gibt es "readonly", "oneway", "in", "out", "inout", "context", "raises", "exception" und "module".

Mit dem DII-API koennen die Methoden eines Objekts ebenfalls aufgerufen werden. DII wird in erster Linie dann verwendet, wenn erst zur Laufzeit eines Programms entschieden werden kann, auf welche Objektklassen mit ihren Operationen zugegriffen werden muss. Das API besteht aus Funktionen zur Vorbereitung einer Auftragsnachricht und deren Aussendung.

Die Dienste des DII wurden als Operationen auf Pseudoobjekte modelliert. Pseudoobjekte gelten als lokale Funktionen und sind normalerweise in der Laufzeitbibliothek implementiert. Ihnen werden - wie anderen IDL-Schnittstellen - Operationen und Attribute zugewiesen, die jedoch lokal ablaufen.

Die in Corba definierten Pseudoobjekte stehen zueinander in folgender Beziehung:

- Das ORB-Schnittstellen-Pseudoobjekt liefert Konvertierungsroutinen fuer Objektreferenzen sowie Funktionen fuer die Kreierung von Kontext- und DII-Argumentlist-Objekten.

- Die Operationen des Objekt-Schnittstellen-Pseudoobjekts koennen auf jedes Objekt eines spezifischen ORBs angewendet werden. Sie bestehen aus Operationen zur Verwaltung von Objektreferenzen, des Schnittstellen- und Implementations-Repositories und der DII- Auftragspseudoobjekte.

- Ein DII-Auftragspseudoobjekt liefert Operationen zum Hinzufuegen von Parametern zu einem Auftrag, zur Auftragsloeschung und zum synchronen oder asynchronen Versenden des Auftrags zu einem "realen" Objekt.

- Argumente und Resultate eines DII-Auftrags werden in Named- Value-Strukturen beschrieben. Ein NV-List-Schnittstellen- Pseudoobjekt, durch die bereits erwaehnte ORB-Schnittstelle kreiert, liefert Operationen, um Listen von Named Values zu manipulieren.

- Kontexte werden durch Operationen auf Kontextpseudoobjekte verwaltet, die Listen von symbolischen Namen und zugeordneten Werten enthalten, aehnlich den Unix-Umgebungsvariablen.

Der ORB ist Vermittler zwischen dem aufrufenden Programm, das selbst ein Objekt sein kann, und der adressierten Objektinstanz. Er ermittelt die Adresse des Partner-ORBs beim Zielobjekt und stellt diesem den Auftrag zu.

Das aufgerufene Objekt wird mit Hilfe des BOA aktiviert, und die angeforderte Methode kommt zur Ausfuehrung. Etwaige Resultate werden wieder an den Aufrufer zurueckgeliefert. Dieses Verfahren entspricht dem eines Remote Procedure Calls (RPCs), so wie er zum Beispiel auf Unix-Systemen fuer die Implementierung des Network File Systems (NFS) oder im Distributed Computing Environment (DCE) der OSF eingesetzt wird.

Objektklassen oder Gruppen davon sind als DCE-Server implementiert und werden daher als Object-Server bezeichnet. Der Client-Object-Server stoesst Operationen in anderen Object-Servern mittels in die IDL-Stubs oder das DII-Laufzeitsystem integrierten OSF/DCE-RPC-Aufrufen an.

Der Ziel-Object-Server wird dabei ueber den OSF/DCE-Directory- Service ermittelt, bei dem alle Objektinstanzen registriert sind. Dies ist ein wesentlicher Teil der ORB-Funktion.

Ausserdem koennen Corba-Operationen mit Hilfe der DCE-Security- Service-Funktionen authentifiziert werden. Auf der Server-Seite wird der RPC-Aufruf an den relevanten Object-Server, nach Ermittlung von dessen Transportprotokollpunkt ueber den Endpoint- Mapper, zugestellt.

Ist der in Frage kommende Object-Server noch nicht aktiviert, wird der Auftrag dem Object-Adapter-Server zugestellt, der den Object-Server aktiviert. Der dabei verwendete Nachrichtenaustausch ist in der BOA-Spezifikation definiert. Sobald ein Object-Server aktiviert ist, kann sich der Client-Object-Server direkt an ihn wenden.

Corba als Remote

Procedure Call

Die Objektorientierung von Corba und das daraus resultierende neue Anwendungsmodell fuer verteilte Anwendungen stellen eine wesentliche Weiterentwicklung des RPC-Modells dar. Durch die Ansiedlung von Zustand (Daten) und zustandsveraendernden Operationen (Methoden) in derselben Einheit (Objekt) koennen fuer verteilte Anwendungen Peer-to-peerStrukturen konfiguriert werden, die den Gegebenheiten zukuenftiger moderner Netze mit leistungsfaehigen Workstations besser entsprechen als das zur Zeit propagierte, etwas striktere Client- Server-Modell.

Die mit Corba implementierte Anwendung profitiert von allen Vorteilen der objektorientierten Programmierung: Durch die Verkapselung der Daten ist neben der formalen Definition des Datenmodells der objektorientierten Anwendung auch die Verwaltung der verteilten Datenbasis besser geregelt, da im Gegensatz zum RPC das Objekt Daten und Methoden (procedures) enthaelt und damit deren Auffinden in der verteilten Umgebung durch gemeinsame Dienste unterstuetzt wird.

Die Programmierung mit komplexen Middleware-Toolkits wie Suns Netzwerktechnik ONCi oder OSFs DCE-Umgebung fuer verteilte DV erfordern die erneute individuelle Entwicklung von Modulen fuer Datenhaltung, Object Naming und Sicherheitsfunktionen in jeder verteilten Anwendung. Ein objektorientiertes Toolkit liefert die Implementierung dieser Funktionen als Teil der Basisfunktionen und traegt damit zur Vereinfachung der Anwendungsentwicklung bei.

Neben der Vererbung von Definitionen, wie sie in der IDL spezifiziert wurde, werden zukuenftige Corba-Umgebungen auch die Vererbung von Implementationseigenschaften unterstuetzen, wodurch es unnoetig wird, ererbte Methoden jedesmal neu zu implementieren.

Trotz einiger noch vorhandener Maengel gibt die Unterstuetzung der Corba-Spezifikation durch namhafte Gremien wie COSE Anlass zur Hoffnung, dass hier zuegig ein allgemein akzeptierter Standard fuer die objektorientierte, verteilte Verarbeitung entsteht. Natuerlich steht Corba nicht ohne Konkurrenz da: Microsoft arbeitet im Rahmen des Cairo-Projekts ebenfalls an einer verteilten Objektumgebung, einer Erweiterung fuer die erfolgreiche OLE-Architektur (Object Linking and Embedding). Wie schon so oft ist der von der Unix-orientierten Welt gewaehlte Loesungsansatz jedoch maechtiger und allgemeiner, was aber einen verlaengerten Standardisierungsprozess zur Folge hat und daher die Durchsetzung von Corba als De-facto-Standard gefaehrdet.

Standards der

Object Management Group (OMG)

Die OMG ist ein Herstellerkonsortium, das sich zum Ziel gesetzt hat, eine neue Form der Anwendungsentwicklung auf objektorientierter Basis zu definieren. Die Gruppe zaehlt inzwischen fast 300 Mitglieder. Als Resultate ihrer Arbeit veroeffentlicht sie Spezifikationen von Anwendungs-Schnittstellen, die Softwarehersteller in ihre Produkte integrieren koennen. Fuer die Auswahl von Techniken legt das Gremium ein Referenzmodell mit der Bezeichung Object Management Architecture (OMA) zugrunde. Das bedeutendste Ergebnis ist bisher die Common Object Request Broker Architecture (Corba).