RMI über IIOP

Was ist RMI über IIOP?

RMI über IIOP (im Folgenden RMI-IIOP), gemeinsam von IBM und Sun entwickelt, ist eine neue Version von RMI (Remote Method Invocation) für IIOP (Internet Inter-ORB Protocol), die die einfachen Programmierfunktionen von RMI mit der Interoperabilität von CORBA kombiniert. Diese neue Version von RMI wurde im Juni offiziell veröffentlicht und auf der Sun-Website frei verfügbar gemacht (Informationen dazu, wo Sie sie herunterladen können, finden Sie im Abschnitt Ressourcen unten). Die Sun-Referenzimplementierung läuft unter Windows 9x / NT und Solaris. Es ist eine Standarderweiterung, die sowohl JDK 1.1.6 als auch die Java 2-Plattform unterstützt.

RMI und CORBA haben sich unabhängig voneinander als Programmiermodelle für verteilte Objekte entwickelt. RMI, eine Grundlage der EJB- und Jini-Technologien, wurde als Java-basiertes, benutzerfreundliches Programmiermodell für verteilte Objekte eingeführt. CORBA (Common Object Request Broker Architecture), definiert von der OMG (Object Management Group), ist ein bekanntes Programmiermodell für verteilte Objekte, das eine Reihe von Sprachen unterstützt. Das IIOP-Protokoll verbindet CORBA-Produkte verschiedener Anbieter und stellt so die Interoperabilität zwischen ihnen sicher. RMI-IIOP ist gewissermaßen eine Ehe von RMI und CORBA.

Für die Zwecke dieses Artikels gehen wir davon aus, dass Sie bereits mit den Grundlagen von CORBA vertraut sind. Wenn Sie weitere Hilfe benötigen, um sich auf dem Laufenden zu halten, finden Sie im Abschnitt Ressourcen unten einen hilfreichen Link.

Vor RMI-IIOP

Schauen Sie sich Abbildung 1 unten an. Der Raum über der horizontalen Mittellinie repräsentiert die ursprüngliche Domäne von RMI; Die untere Region repräsentiert die Welt von CORBA und IIOP. Diese beiden getrennten Welten, die sich unabhängig voneinander entwickelt haben, waren historisch nicht in der Lage, miteinander zu kommunizieren. Beispielsweise kann das native RMI-Protokoll JRMP (Java Remote Method Protocol) keine Verbindung zu anderen Protokollen herstellen.

Wenn die einzige Programmiersprache, die Sie in einem neuen Projekt benötigen, Java ist, war die Verwendung von RMI und JRMP - eine Kombination, die im weiteren Verlauf dieses Artikels als RMI (JRMP) bezeichnet wird - traditionell die beste Wahl. Im Gegensatz zu CORBA, für das die ziemlich komplizierte Interface Definition Language (IDL) verwendet werden muss, bietet RMI (JRMP) eine einfache Programmierung für Java-Liebhaber. CORBA hingegen ermöglicht die Programmierung verteilter Objekte auf verschiedenen Plattformen und in verschiedenen Programmiersprachen. Entwickler benötigen die Programmierung verteilter Objekte nicht nur für neue Projekte, sondern auch für die Nutzung älterer Softwareressourcen. Natürlich ist Legacy-Software in den meisten Fällen in anderen Sprachen als Java programmiert. In solchen Situationen benötigen Entwickler CORBA, nicht RMI (JRMP).

Damit haben wir unser zentrales Dilemma: RMI (JRMP) hat den Vorteil einer einfachen Programmierung, während CORBA die Interoperabilität zwischen mehreren Programmiersprachen auf verschiedenen Plattformen bietet. Leider gab es traditionell keine Möglichkeit, diese beiden hervorragenden Technologien einzusetzen. Dies zeigt das Diagramm in Abbildung 2, in dem ein Kreis für eine Situation steht, in der ein Client einen Server aufrufen kann, und ein X für einen Fall, in dem dies nicht möglich ist

Das Beste aus beiden Welten

Früher war es schwierig, beim Start eines neuen Projekts zwischen RMI (JRMP) und CORBA zu wählen. Wenn Sie RMI (JRMP) ausgewählt haben, haben Sie eine einfache Programmierung, aber die Interoperabilität über mehrere Sprachen hinweg verloren. Wenn Sie CORBA ausgewählt haben, haben Sie Interoperabilität erhalten, standen jedoch vor einer schwierigeren Programmieraufgabe. Sowohl RMI (JRMP) als auch CORBA-Benutzer, die es satt haben, diese Entscheidung zu treffen, haben mit einer Stimme gesagt: "Bitte verbinden Sie die beiden."

In Abbildung 3 unten repräsentiert der obere Abschnitt das RMI (JRMP) -Modell, der mittlere Abschnitt das RMI-IIOP-Modell und der untere Abschnitt das CORBA-Modell. Ein Pfeil stellt eine Situation dar, in der ein Client einen Server anrufen kann. RMI-IIOP gehört in die IIOP-Welt unterhalb der horizontalen Linie. Was seltsam aussehen mag, sind die diagonalen Pfeile, die die Grenze zwischen der JRMP-Welt und der IIOP-Welt überschreiten. Dies bedeutet, dass ein RMI-Client (JRMP) einen RMI-IIOP-Server aufrufen kann und umgekehrt. Es ist für Leser selbstverständlich zu denken, dass diese diagonalen Pfeile falsch sind - schließlich können verschiedene Protokolle niemals miteinander sprechen, oder? Diese Pfeile befinden sich jedoch tatsächlich an der richtigen Stelle. RMI-IIOP unterstützt sowohl JRMP- als auch IIOP-Protokolle.

Eine mit RMI-IIOP-APIs erstellte Server-Binärdatei (dh eine Klassendatei) kann entweder als JRMP oder als IIOP exportiert werden. Sie müssen den Java-Quellcode nicht neu schreiben oder neu kompilieren, wenn Sie von JRMP zu IIOP wechseln oder umgekehrt. Sie müssen nur Parameter wie Java-Systemeigenschaften ändern, wenn Sie es ausführen. Alternativ können Sie das verwendete Protokoll bestimmen, indem Sie es im Java-Quellcode angeben. Die gleiche Flexibilität gilt für RMI-IIOP-Clientcode.

Dualer Export

Bei der Entscheidung zwischen den Protokollen JRMP und IIOP ist noch eine weitere wichtige Tatsache zu beachten. Wenn Sie ein RMI-IIOP-Objekt auf Ihren Server exportieren, müssen Sie nicht unbedingt zwischen JRMP und IIOP wählen. Wenn Sie ein einzelnes Serverobjekt benötigen, um sowohl JRMP- als auch IIOP-Clients zu unterstützen, können Sie Ihr RMI-IIOP-Objekt gleichzeitig in JRMP und IIOP exportieren. In der RMI-IIOP-Terminologie wird dies als dualer Export bezeichnet.

Die diagonalen Pfeile in Abbildung 3 sind möglich, da RMI-IIOP-APIs sowohl JRMP- als auch IIOP-Protokolle unterstützen. Dies bedeutet, dass der Quellcode eines RMI-Objekts (JRMP) ohne Umschreiben von einem neuen RMI-IIOP-Client aufgerufen werden kann. In ähnlicher Weise können Sie ohne Umschreiben des Quellcodes eines RMI (JRMP) -Clients ein RMI (JRMP) -Serverobjekt durch ein neues RMI-IIOP-Objekt ersetzen, das auch ein CORBA-Client aufrufen kann. Somit behält RMI-IIOP die vorhandenen Investitionen in RMI-Binärdateien (JRMP) bei, da RMI-IIOP ohne Änderungen des Quellcodes oder Neukompilierung mit ihnen kommunizieren kann.

Diese Interoperabilität mit RMI (JRMP) war eines der Entwurfsprinzipien von RMI-IIOP. Die RMI-IIOP-Designer vermieden die Versuchung, CORBA und RMI durch ein drittes Programmiermodell zu ersetzen, da dies nur die Programmierer verteilter Objekte verwirrt und die Migration von RMI (JRMP) umso schwieriger gemacht hätte.

Interoperabilität mit CORBA

Schauen Sie sich noch einmal Abbildung 3 an. Der Abschnitt unter der horizontalen Linie zeigt die IIOP-Welt, in der ein RMI-IIOP-Client einen CORBA-Server und ein CORBA-Client einen RMI-IIOP-Server aufruft. Mit einem RMI-IIOP-Client meinen wir ein Client-Programm, das von einem RMI-Programmierer geschrieben wurde, der nichts über CORBA oder IDL weiß. Ebenso ein CORBA-Clientist ein Client-Programm, das von einem CORBA-Programmierer geschrieben wurde, der RMI nicht kennt. Die Trennung der Schnittstelle von der Implementierung ist eine etablierte Technik, mit der Programmierer auf verschiedene Ressourcen zugreifen können, ohne wissen zu müssen, wie diese Ressourcen implementiert werden. Wenn diese Technik angewendet wird, können Benutzer von RMI-IIOP und CORBA die Dienste des anderen Protokolls verwenden, wenn sie Zugriff auf dessen Schnittstelle erhalten. Eine RMI-Java-Schnittstellendatei ist die Schnittstelle zu RMI-IIOP-Benutzern, während IDL die Schnittstelle zu CORBA-Benutzern ist. Die Interoperabilität zwischen RMI-IIOP und CORBA in Abbildung 3 wird erreicht, indem jedem Benutzer seine erwartete Schnittstelle zur Verfügung gestellt wird, während die tatsächliche Implementierung verborgen bleibt.

Das letzte Detail, das in Abbildung 3 erläutert wird, ist der gepunktete Pfeil, der einen RMI-IIOP-Client anzeigt, der einen CORBA-Server aufruft. Warum ist nur dieser Pfeil gepunktet? Ein RMI-IIOP-Client kann nicht unbedingt auf alle vorhandenen CORBA-Objekte zugreifen. Die Semantik von in IDL definierten CORBA-Objekten ist eine Obermenge derjenigen von RMI-IIOP-Objekten, weshalb die IDL eines vorhandenen CORBA-Objekts nicht immer einer RMI-IIOP-Java-Schnittstelle zugeordnet werden kann. Nur wenn die Semantik eines bestimmten CORBA-Objekts mit der von RMI-IIOP übereinstimmt, kann ein RMI-IIOP-Client ein CORBA-Objekt aufrufen. Der gepunktete Pfeil zeigt eine Verbindung an, die manchmal - aber nicht immer - möglich ist.

Die Inkompatibilität sollte hier jedoch nicht überbewertet werden. Die durch den gepunkteten Pfeil angegebenen Einschränkungen gelten nur für vorhandene CORBA-Objekte. Angenommen, Sie entwerfen ein brandneues verteiltes Objekt mit einer RMI-IIOP-Java-Schnittstelle. In diesem Fall können Sie mit dem automatisch die entsprechende IDL generierenrmicWerkzeug. Aus dieser IDL-Datei können Sie sie als CORBA-Objekt implementieren - beispielsweise in C ++. Dieses C ++ - Objekt ist ein reines CORBA-Objekt, das von einem CORBA-Client und ohne Einschränkungen auch von einem RMI-IIOP-Client aufgerufen werden kann. Für den RMI-IIOP-Client wird dieses C ++ CORBA-Objekt als reines RMI-IIOP-Objekt angezeigt, da es von einer RMI-IIOP-Java-Schnittstelle definiert wird. Kurz gesagt, der Unterschied zwischen einem CORBA-Objekt und einem RMI-IIOP-Objekt ist nur eine Implementierungssache. Wenn ein Objekt in RMI-IIOP implementiert ist, wird das Objekt einem CORBA-Client als CORBA-Objekt angezeigt, da ein CORBA-Client über seine IDL darauf zugreift.

Abbildung 4 unten zeigt die Matrix, in der die Pfeile in Abbildung 3 zusammengefasst sind. Der gepunktete Kreis bedeutet dasselbe wie der gepunktete Pfeil in Abbildung 3. Abbildung 4 zeigt, dass Sie bei der Implementierung Ihres Servers in RMI-IIOP die größte Auswahl haben Kunden. Wenn Sie Ihren Client in RMI-IIOP implementieren, können Sie ebenfalls mit der größten Anzahl von Servern kommunizieren, obwohl es bei vorhandenen CORBA-Objekten einige Einschränkungen gibt, die durch den gepunkteten Kreis angezeigt werden.

RMI-IIOP-Designrichtlinie

Es gab zwei Hauptvoraussetzungen, die das Design des RMI-IIOP-Protokolls prägten: Die RMI-Semantik musste so intakt wie möglich bleiben, und CORBA musste verbessert werden, damit die RMI-Semantik mithilfe der CORBA-Infrastruktur implementiert werden konnte. Das war leichter gesagt als getan. Wenn ein drittes Programmiermodell eingeführt würde, würde dies nur die Programmierer verwirren. Um eine glückliche Ehe zwischen RMI und CORBA herzustellen, war es notwendig, einen Kompromiss zwischen den verschiedenen Hintergründen dieser Ehepartner zu erzielen. Wenn beide Partner einen Kompromiss ablehnten, würde die Ehe nichts bringen. Glücklicherweise hat die CORBA-Community dies erkannt und bestimmte Änderungen akzeptiert, damit RMI-IIOP Realität wird.

Die beiden wichtigsten Änderungen, die CORBA akzeptierte, waren die Objects by Value- und die Java-to-IDL-Mapping- Spezifikationen. Ersteres, das RMI-Benutzern bereits in Form der Java-Objektserialisierung zur Verfügung steht, ist eine CORBA-Spezifikation, mit der andere Sprachen eine ähnliche Funktion implementieren sollen. Letzteres ist die Zuordnung, die zum Konvertieren von RMI-Java-Schnittstellen in CORBA-IDL-Definitionen verwendet wird und darf nicht mit der bereits in CORBA 2.2 definierten IDL-zu-Java-Zuordnung verwechselt werden. (Links zu diesen beiden neuen CORBA-Spezifikationen finden Sie unter Ressourcen.)

OMG hat beide Spezifikationen für CORBA 2.3 bereits offiziell akzeptiert, aber CORBA-Implementierungen müssen mit dieser neuen Version Schritt halten, bevor die hier beschriebene neue Verbindung von CORBA und RMI weit verbreitet wird. Beispielsweise ist ein IDL-zu-Java-Compiler, der CORBA 2.3 entspricht, von Sun zur Verwendung in Verbindung mit dem RMI-IIOP ORB (Object Request Broker) erhältlich. Derzeit handelt es sich jedoch um eine Version mit frühem Zugriff, die nur zur Untersuchung der Interoperabilität von geeignet ist CORBA und RMI-IIOP und nicht für Produktionszwecke. Darüber hinaus entspricht der von Sun zur Verwendung mit dem Java IDL ORB in Java 1.2 verteilte IDL-zu-Java-Compiler nicht CORBA 2.3, sodass er nicht zum Testen der Interoperabilität mit RMI-IIOP verwendet werden kann. Diese Situation wird in den nächsten Monaten behoben, wenn CORBA-Anbieter neue Versionen ihrer Produkte einführen, die CORBA 2.3 unterstützen.Beispielsweise wird die nächste Version der Java 2-Plattform, Standard Edition, sowohl RMI-IIOP als auch einen IDL-zu-Java-Compiler in Produktionsqualität enthalten, der CORBA 2.3 unterstützt.

Entwicklungsverfahren

Abbildung 5 zeigt die Entwicklungsverfahren für RMI-IIOP-Server und -Clients. Sie werden feststellen, dass sie fast mit denen von RMI (JRMP) identisch sind. Genau wie in RMI (JRMP) ist die Definition eines verteilten Objekts seine RMI-Java-Schnittstelle ( MyObject.javain Abbildung 5). Ein Unterschied ist der -iiopParameter des rmicCompilers. Diese Option wird verwendet, um rmicdie Stubs und Bindungen zu generieren, die das IIOP-Protokoll unterstützen. Generiert ohne diese -iiopOption rmiceinen Stub und ein Skelett für das JRMP-Protokoll. Obwohl das Entwicklungsverfahren für RMI-IIOP dem für RMI (JRMP) nahe kommt, unterscheidet sich die Laufzeitumgebung darin, dass die Kommunikation über einen CORBA 2.3-kompatiblen ORB erfolgt, wobei IIOP für die Kommunikation zwischen Servern und Clients verwendet wird.

Wenn Sie erwägen, RMI-Code (JRMP) in RMI-IIOP zu konvertieren, sollten Sie sich bewusst sein, dass es beim Ausführen über IIOP einige Implementierungsunterschiede gibt. Die verteilte Speicherbereinigung wird von CORBA nicht unterstützt, das explizite Zerstörung und persistente Objektreferenzen mit transparenter Passivierung und Aktivierung verwendet. Die RMI-Registrierung wird durch JNDI beim CosNamingoder LDAP-Dienstanbieter ersetzt, und die RMI-Aktivierung wird durch den Adapter für tragbare Objekte ersetzt. Remote-Objektreferenzen müssen mithilfe einer programmatischen narrow()Methode anstelle einer direkten Java-Sprachübertragung heruntergestuft werden . Andere RMI-Semantiken wie die Objektserialisierung werden über IIOP vollständig unterstützt.

CORBA-Interoperabilitätsverfahren

Abbildung 6 zeigt, wie die Interoperabilität zwischen RMI-IIOP und CORBA erreicht wird. Um unsere Diskussion zu vereinfachen, betrachten wir zwei Aspekte einer solchen Interoperabilität: einen CORBA-Client mit einem RMI-IIOP-Objekt (siehe Abbildung 6 ganz links) und einen RMI-IIOP-Client mit einem CORBA-Objekt (ganz rechts). Im Zentrum der Abbildung stehen die gemeinsamen Prozesse, mit denen beide Formen der Interoperabilität funktionieren.