Wolfgang Schmidt Matr.Nr 3283267  

Inhaltsverzeichnis

1.  Einführung Motivation  3

2.  RMI Systemarchitektur  4

2.1  Der Stub Skeleton Layer  4

2.2  Der Remote Reference Layer  5

2.3  Der Transport Layer  6

2.4  Dynamic Class Loading  6

2.5  Sicherheitsaspekte  7

2.6  Verwaltung von live references  7

3.  Verteiltes Objektmodell  8

3.1  Schnittstellen und Klassen des RMI-Package  8

3.1.1  Interface Remote  8

3.1.2  Klasse RemoteObject und Subklassen  8

3.2  Parameterübergabe  9

3.3  Lokalisierung entfernter Objekte  10

3.4  Ausnahmebehandlung  10

4.  Entwicklungsmodell Vorgehen  11

5.  Praxis Szenario  12

6.  Zusammenfassung  14

7.  Literaturverzeichnis  15

  Abbildungverzeichnis  

  Abbildung 2 1: RMI Systemebenen  4

  Abbildung 2 1 1: Stub und Skeleton Objekte  5

  Abbildung 3 1 1: RMI Interfaces und Klassen  8

  Abbildung 5 1: Anwendungsszenario  12

  FeU-Seminar: 1920 SS 1997 Ausarbeitung Vortrag: Java RMI  2

Wolfgang Schmidt

1. Einführung / Motivation

Das Java Remote Method Invocation (RMI) ist ein Objektmodell und eine Menge von APIs (Application Programing Interface), zur Realisierung von verteilten Systemen in der rein objektorientierte Sprache JAVA.

Verteilte Systeme im objektorientierten Umfeld erfordern ein verteiltes Objektmodell und einen verteilten Nachrichtenfluß, welcher einem entfernten Methodenaufruf entspricht. Da der Remote Procedure Call (RPC), bekannt aus dem prozeduralen Umfeld, in objektorientierten Sprachen nicht, oder nur eingeschränkt verwendbar ist, steht mit dem RMI eine Transferierung der RPC-Konzepte zur Verfügung, welche die besonderen Belange der objektorientierten Sicht berücksichtigt.

Die neben dem RMI derzeit in Java existierenden Möglichkeiten einer Kommunikation zwischen Clients und Servern sind die Basiskommunikation über Sockets und die Datenbankschnittstelle JDBC. Beide sind in manchen Situationen sinnvoll und effizient einzusetzen. Jedoch zur Realisierung von objektorientierten verteilten Systemen sind diese nicht ausreichend. Die Kommunikation von verteilten Objekten wird vom Java RMI weitgehend automatisiert und ist damit, neben dem CORBA-Ansatz (Java IDL / IIOP) für sprachübergreifende Kommunikation heterogener Systeme, ein vernünftiger Ansatz ein Server/Client Modell in der Java-Umgebung, d.h. bei miteinander kommunizierenden Objekten in verschiedenen Java Virtual Machines (JVM), zu realisieren. Die miteinander komunizierenden JVM können, müssen aber nicht auf verschiedenen Systemen liegen.

Die beiden wichtigsten Punkte sind die Möglichkeit komplexe Objekte zwischen Client und Servern auszutauschen und transparent Nachrichten an entfernte Objekte zu senden, bzw. Methoden entfernter Objekte an-/aufzurufen. Von Vorteil für das RMI ist, daß die Behandlung der entfernten Objekte völlig analog zu den lokalen ist. Damit ist für die Entwicklung eine einheitliche SW-Plattform gegeben. Zudem kann durch den Verzicht auf die Kommunikation mit Objektinstanzen anderer Entwicklungsumgebungen, die volle Leistungsfähigkeit des Java Objektmodell für das RMI genutzt werden.

Wolfgang Schmidt

2. RMI Systemarchitektur

Die Systemarchitektur des RMI ist in drei voneinander vollständig unabhängigen, eigenständigen Ebenen aufgeteilt. Der Stub/Skeleton Layer, Remote Reference Layer und der Transport Layer.

Die Kommunikation erfolgt im RMI automatisch über fest definierte Protokolle, so daß es auch stets möglich ist eine komplette Ebene auszutauschen. Z.B kann der derzeit auf TCP basierende Transport Layer evtl. durch eine Transportschicht ersetzt werden, die ein anderes Protokoll realisiert.

Die Zuordnung von Client- und Serverfunktion gilt stets nur für eine konkrete Kommunikation zweier Objekte. Somit kann ein Objekt Client bzgl. eines Zugriffs auf ein entferntes Serverobjekt sein und darauf einen Serverdienst für ein anderes Objekt erbringen, welches evtl. auf einem anderen, entfernten Rechner existiert.

2.1 Der Stub/Skeleton Layer

Wenn von einem Objekt im Client eine Methode eines Serverobjekts aufgerufen werden soll, bzw. dem Serverobjekt eine Nachricht gesendet werden soll, wird ein lokales Stellvertreterobjekt verwendet, welches als Stub bezeichnet wird. Dieses existiert im Adressraum der JVM die das Clientobjekt ausführt und stellt somit für die restliche Applikation ein reguläres Java-Objekt dar. Die Stub-Methode fast die Parameter des Methodenaufrufs zusammen, was auch "parameter marshalling " genannt wird (siehe hierzu das Kapitel 3.2 / Parameterübergabe), und zusammen mit der eindeutigen Referenz des Remote-Objekts und der Nummer der aufgerufenen Methode wird ein Datenblock gebildet, der über den Remote Reference Layer zum Server gesendet wird.

Auf der Serverseite empfängt das entfernte Stellvertreterobjekt des eigentlichen Remote-Objektes, bezeichnet als Skeleton, über den dortigen Remote Reference Layer den Datenblock und ruft die gewünschte Methode des Serverob-

Wolfgang Schmidt

jekts auf. Rückgabewerte, wozu auch ausgelöste Ausnahme- bzw. Fehlerobjekte (Exceptions) gehören, werden auf dem analogen Weg zum Clientobjekt zurückgesendet. Die folgende Abbildung veranschaulicht den Vorgang:

Da ein generelles Designziel im RMI eine nahtlose Eingliederung des APIs in die reguläre Sprache ist, kann der Entwickler die Remote-Objekte (fast) genauso verwenden wie originäre Java-Objekte. Damit ist auch klar, daß der oben beschriebene komplexe Kommunikationsweg vollständig transparent und vom RMI automatisiert ist.

2.2 Der Remote Reference Layer

In dieser Schicht wird die Kommunikation mit der Transportschicht geregelt und im wesentlichen das Protokoll bestimmt, nach dem die entfernten Referenzen zugeordnet werden. Dies ist unabhängig von den Stub- und Skeleton-Objekten.

Jede Implementierung eines entfernten Objekts bestimmt die Art der Referenzierung. Es sind verschiedene Protokolle in dieser Schicht zu realisieren:

• Einfacher Methodenaufruf bei einer Punkt-zu-Punkt Zuordnung

• Methodenaufruf von replizierten Objekten

• Unterstützung für spezielle Replikationsstrategien

• Strategien zur Wiederverbindung bei einer unterbrochenen Verbindung zum Objekt

Zwei Komponenten bzgl. der Client- und Serverseite kooperieren bei der Methodenausführung. Die Client-Komponente enthält die relevanten Informationen über die Serverimplementierung des Objekts und kann z.B. bei einem replizierten Server-Objekt den Methodenaufruf an alle Replikate weiterleiten. Die Komponente des Remote Reference Layer auf der Serverseite dient der Weiterleitung des Aufrufs an das Skeleton-Objekt.

Wolfgang Schmidt

In dem aktuellen Release des JDK 1.1 ist das Multicasting von Serverobjekten noch nicht enthalten.

Der Remote Reference Layer überträgt die Daten über abstrakte Stream-orientierte Verbindungskanäle. Die darunterliegende Transportschicht implementiert diese transparent.

2.3 Der Transport Layer

In der Transportschicht werden die folgenden Aufgaben wahrgenommen:

• Aufbau, Verwaltung und Überwachung von Verbindungskanälen zu entfernten Adressräumen

• Verwaltung einer Refernztabelle von aktuellen entfernten Objekten, die im lokalen Adressraum verwendet werden

• Annahme von Verbindungswünschen anderer und Aufbau der Verbindungskanäle Zur Verwaltung von entfernten Objekten werden vier begriffliche Verallgemeinerungen (Abstraktionen) definiert:

• Ein endpoint ist die Abstraktionen um eine JVM bzw. einen Adressraum zuzuordnen.

• Ein channel ist die begriffliche Verallgemeinerung für eine virtuelle lei-tungsgebundene Verbindung zweier Adressräume. Der Kanal ist für die Verbindung des lokalen und entfernten Adressraumes verantwortlich.

• Eine connection ist die Abstraktion für eine bidirektionale Datenübertragung.

• Ein transport ist die Abstraktion für die Verwaltungsinstanz der Kanäle (channels). In jedem transport kann nur ein Kanal für zwei Adressräume real aufgebaut werden. Eine Zuordnung eines endpoints zu einem entfrenten Adressraum bewirkt einen Verbindungsaufbau (Kanal). Weitere Aufgaben sind die Annahme von eingehenden Aufrufen, der Einrichtung einer Verbindung und der Weiterleitung zu der höheren Systemebene. Die konkrete Repräsentierung eines entfernten Objektes, bezeichnet als live reference, besteht aus einem endpoint und einer eindeutigen Identifikation (Schlüssel) des Objektes. Mit einer solchen live reference kann in der Trans-portschicht im Client per endpoint die Verbindung zum entfernten Adressraum aufgebaut, sowie auf der Serverseite das konkrete Objekt per Schlüssel bestimmt werden.

2.4 Dynamic Class Loading

Ein Client im RPC-Umfeld benötigt kompilierten Code für Stubs, der statisch oder dynamisch (über ein Netzwerk-Filesystem) zum aktuellen Programm ge-bunden wird, bevor die Routine ausgeführt werden kann.

RMI generalisiert diese Technik dahingehend, daß

Wolfgang Schmidt

• neutraler Bytecode verwendet wird, da dies ein wesentliches Merkmal der Sprache ist. Dies ermöglicht bzw. vereinfacht den heterogenen Mix von Client- und Serverplattformen.

• wahlfreies Laden von Klassen von lokalen oder entfernten Quellen möglich ist, indem ein spezieller RMIClassLoader zur Verfügung gestellt wird. Neben den anderen Möglichkeiten in Java (AppletLoader, Classpath), ist damit eine Kontrolle und genaue Steuerung der Klassenherkunft möglich (siehe auch Kapitel 2.5 / Sicherheitsaspekte)

• automatisches Laden von fehlenden Class-Files zur Laufzeit − Von entfernten Objektklassen und Interfaces

− Von Stub und Skeletonklassen

− auch von anderen, in der RMI-Anwendung, benötigten Klassen, wie z.B. Parametern von Methoden oder Rückgabeobjekte.

2.5 Sicherheitsaspekte

Im Bereich der Netzanwendungen ist stets die Möglichkeit gegeben, daß Mißbrauch mit den Zugriffsmöglichkeiten betrieben wird. In dem konkreten Fall der verteilten Anwendungen ist eine Steuerung und Kontrolle der entfernten Methodenaufrufe notwendig. Das RMI-System bietet ein Standardsicherheitssystem an, den RMISecurityManager. Dieser muß in Applikationen als erstes gestartet werden, um die Kontrolle über die über Netz gehenden Methodenaufrufe zu erhalten und entscheiden zu können, welche Stub-Klassen von welchen Servern geladen werden dürfen. Auch kann dadurch kontroliert werden, was Stub-Objeket, die ja im Adressraum des Clients ausgeführt werden, dürfen, z.B. Zugriff auf lokale Ressourcen (Festplatte, etc.) und Zugriff auf andere Server.

Werden RemoteObjects über Applets geladen, so übernimmt standardmäßig der AppletSecurity Manager die Kontrolle.

Es ist weiterhin möglich eigene Security-Manager zu implementieren, die speziell applikationsgebundene Sicherheitsbelange unterstützen.

Zudem ist seitens des Designs und der Entwicklung steuerbar, welche (entfernte) Objekte über das Netz transportiert werden können. Dies kann nur mit Objekten geschehen, die serialisierbar sind, also das Interface Serializable implementieren. Dies kann jedoch für jedes Applikationsobjekt selbständig deklariert werden.

2.6 Verwaltung von live references

Die Verwaltung von nicht mehr benötigten Objekten ist in Java automatisiert (Garbage Collection). Dies gilt dies auch für remote Objekte. Damit ist auch im verteilten Fall der Entwickler nicht mit dieser Verwaltung belastet. Natürlich ist es im Netzzugriff immer möglich, daß eine Refernz auf ein entferntes Objekt nicht aufgelöst werden kann (z.B. Rechnerausfall). Dann wird jedoch eine RemoteExeption ausgelöst (siehe 3.4 / Ausnahmebehandlung).

Wolfgang Schmidt

3. Verteiltes Objektmodell

3.1 Schnittstellen und Klassen des RMI-Package

Die Subtyping/Vererbungshierarchie der wesentlichen Schnittstellen/Klassen im Java RMI ist in folgender Abbildung dargestellt:

3.1.1 Interface Remote

Die Basis der Applikationstypen bzw. -klassen ist das Interface Remote. Ein Client benötigt zur Benutzung von Serverobjekten, die auf dem Server existieren, eine Beschreibung über die Fähigkeiten eines entfernten Objektes. Dieser Typ definiert die Methoden, die eine konkrete Implementierung und davon abgeleitete Instanzen zur Verfügung stellen. Somit wird die Logik der Applikation über Typen (analog zu abstrakten Datentypen ADTs) definiert. Alle Interfaces für entfernte Objekte müssen daher das Remote Interface direkt oder indirekt erweitern, d.h. von diesem abgeleitet sein.

3.1.2 Klasse RemoteObject und Subklassen

Die Implementierungen der Applikationstypen erfolgt auf Basis der Klasse RemoteObject, von der die Instanzen die allgemeine Netzfähigkeit für Objekte erben, und die das Pendant für die allgemeine Oberklasse Object in Java für entfernte Objekte ist. Die Klassen der Applikation implementieren die Remote Interfaces, d.h. realisieren die konkreten Typen, mit Methoden und Datenfeldern.

Die Klasse RemoteServer dient als Superklasse für die einzelnen Referenzierungsklassen wie UnicastRemoteObject und „MulticastRemoteObject“, wobei

Wolfgang Schmidt

letztere in dem aktuellen Release des JDK 1.1 noch nicht enthalten ist. Wie im Kapitel 2.2 beschrieben wird, ist eine Zuordnung eines Stub-Objekt zu einer einzelnen Serverimplementierung oder zu Replikaten vom Design des RMI her möglich. Dies wird gesteuert über die Ableitung der Serverobjektimplementierung von der speziellen Subklasse von RemoteServer. Damit vererbt die Klasse RemoteServer die Semantik der entfernten Referenzierung und des Management von Objekten an die abgeleiteten Objektklassen.

Damit wird also eine Applikationsklasse X im Allgemeinen abgeleitet von UnicastRemoteObject und somit indirekt von RemoteServer und RemoteObject. Auch ist eine Ableitung von einer anderen Implementierung einer Remoteklasse möglich. Die Klasse X kann ein oder mehrere Remote Interfaces implementieren. Zudem können in X auch Methoden definiert werden, die in keinem Interface deklariert werden. Dies sind Methoden die dann nicht entfernt verwendet werden können, aber der lokalen Serverinstanz zur Verfügung stehen.

3.2 Parameterübergabe

Zur Übertragung von Parametern, die einfachen Datentyps oder Objektinstanzen sein können, ist eine Serialisierung des Objekts notwendig. Hierzu ist ein spezieller Mechanismus in Java zur Verfügung, genannt Java Object Serialization. Dieser bietet das Interface Serializable an, das von den Parameterklassen implementiert werden muß. Dies ist bei den Standardklassen des JDK fast stets gegeben, insbesondere bei den Remoteklassen.

Prinzipiell kann jede Art von Objekt übertragen werden, unabhängig von der Tatsache, ob es das Interface Remote implementiert. Eine Übergabe eines Objekts kann in Form eines Parameters beim Aufruf einer Methode oder als Rückgabewert einer remote Methode geschehen.

Zu unterscheiden sind die Übergabe von lokalen Objekten und entfernten Objekten (solche, die das Interface Remote implementieren).

Für lokale Objekte existieren naturgemäß keine Stellvertreterobjekte und keine Registrierung in einem entfernten Server. Somit werden Lokale Objekte bei einer Übertragung kopiert, so daß auf dem entfernten System eine eigenständige Objektkopie verfügbar ist.

Im Fall von entfernten (remote) Objekten existieren naturgemäß die Stellvertreterobjekte (Stub und Skeleton) und die Registrierung(en) in dem/den entfernten Server(n). Damit ist eine Referenzierung dieser Objekte möglich. Wird also ein RemoteObject als Parameter eines Methodenaufrufs angegeben, so wird sein Stevertreter-Objekt, der Stub, übergeben.

Die Besonderheiten des Kopieren von Objekten, wie Verweise auf andere Objekte, die ja in dem entfernten Adressraum nicht existieren, usw., wird von dem Mechanismus Java Object Serialization dem Entwickler gegenüber transparent geregelt (näheres hierzu siehe [ObjSer97]). Damit können also lokale Objekte und entfernte Objekte gleich behandelt werden.

Wolfgang Schmidt

3.3 Lokalisierung entfernter Objekte

Eine Kommunikation zwischen Client und Server erfordert eine Referenz (Stub) des entfernten Objekts. Man erhält diese im Allgemeinen als Rückgabewert eines Methodenaufrufs für ein entferntes Objekt. Dafür braucht man aber nun wieder den Stub für dieses Serverobjekt. Um dieses „Henne/Ei-Problem“ zu lösen gibt es einen Mechanismus im RMI (bootstrap registry service), um erstmalig eine Referenz (Stub) auf ein entferntes Objekt zu erhalten. Dabei handelt es sich um einen einfachen Nameserver, der für Serverobjekte Bezeichnungen/Namen verwaltet, über die Clients eine Referenz zu diese Serverobjekten erhalten können. Dieser Nameservice läuft als Dämonprozess auf dem Serversystem und wacht an einem Port (Default 1099) auf eine Dienstan-forderung.

Um diesen Nameserver anzusprechen, wird die Uniform Ressource Locator (URL) Syntax, wie z.B. rmi://java.sun.com/rmiserv, verwendet. Der Name wird vergeben durch die Implementierung auf Serverseite. Diese bindet die frei gewählte, aber eindeutige, Bezeichnung an eine Instanz eines RemoteObject. Ein Client erhält über den Namen (lookup) des entfernten Objekts eine Referenz (Stub-Objekt) und kann somit das Serverobjekt ansprechen.

3.4 Ausnahmebehandlung

Im Bereich von verteilten Anwendungen hat die Ausnahmebehandlung eine besondere Rolle, da die verschiedensten Fehlersituationen entstehen können. Z.B. :

• Fehlerhafte Ausführung von entfernten Methoden (Methodenaufrufe entfernter Objekte sind fehleranfällig)

• Ausfall einzelner Server bzw. Server-Verbindung

• Ausfall bzw. Störung der Netzverbindung

• Geringe Performance auf dem Netz und daraus evtl. resultierende Fehler

Damit muß also die Ausnahmebehandlung stets beim Umgang mit entfernten Ressourcen berücksichtigt werden. Das Exception Handling wird in Java über spezielle Objekte und Sprachkonstrukte geregelt. Tritt ein Fehler auf, so wird ein spezielles Objekt, eine Exeption, ausgelöst. Diese Objeket werden im lokalen Fall von der Superklasse Exception, und im entfernten (remote) Fall von der Superklasse RemoteException abgeleitet. Damit kann die Fehlerbehandlung in beiden Fällen analog vorgenommen werden, in dem die Exeptions abgefangen und von speziellen Programmteilen (Exeption-Handler) verarbeitet werden.

Daher ist die Exception Möglichkeit stets zu deklarieren, was in den Klassendefinition über die Angabe der möglichen Exeptionobjekte geschieht (throws).

Wolfgang Schmidt

4. Entwicklungsmodell / ~Vorgehen

Um eine verteilte Applikation zur Verfügung zu stellen müssen nachstehend beschriebene Schritte vorgenommen werden:

a) Design der Applikation auf Basis des Interface Remote

b) Realisierung der Applikation auf Basis von RemoteObject bzw. den Subklassen von RemoteServer

c) Kompilierung der Java-Sourcefiles Ð Java Klassendateien

d) Generierung der Stubs/Skeleton-Klassen vollautomatisch aus den Applikationsklassen mit Hilfe des rmic Bytecode-Compiler

e) Verteilung der Class-Files (Interfaces und Stub/Skeleton-Klassen) im Netz (Intranet/WWW)

• Im statischen Fall werden die Klassendateien auf bestimmten Rechnern, Server(n) und Client(s), verteilt

• Im dynamischen Fall können über Java-Applets auf Web-Seiten die entsprechenden Klassendateien bei der konkreten Benutzung geladen werden. Hierzu müssen auf in den HTML-Dokumenten entsprechende Informationen aufgenommen werden.

f) Starten des RMI Registry Service (Nameserver) auf dem/den Server(n)

g) Starten der Applikation auf dem/den Server(n), in deren Initialisierungsteil auch die Instanzen der Serverobjekte in der Registry eingetragen werden.

h) Starten der/des Client(s) und Lesen der ersten Referenzen von entfernten Serverobjekten vom Nameservice.

Die Punkte (a), (b) und (c) sind allgemein bei einer Entwicklung durch zuführen und damit nicht spezifisch für RMI.

Die Punkte (d) und (f) sind vollständig automatisiert und somit mit sehr geringem Aufwand auszuführen. Der rmic Bytecode-Compiler erzeugt automatische aus den angegebenen Java Klassendateien die Stellvertreter-Klassen. Der Nameserver ist mit einem Kommando gestartet.

Ebenso sind die Punkte (g) und (h) nicht besonders RMI spezifisch, da dies allgemein bei Client/Server-Anwendungen der Fall ist. Damit ist nur im Client das Objekt-Lookup (h) und auf Serverseite das registrieren der Objekte besonders zu beachten. Bleibt Punkt (e), der naturgemäß im Thema verteilte Anwendungen zu beachten ist. Die Möglichkeit der Applets läßt hier eine zentrale Verwaltung zu.

Somit ist zusammenfassend zu bemerken, daß die Realisierung einer verteilten Anwendung mit Hilfe Java RMI nicht besonders schwierig oder aufwendig ist. Die anforderung liegt eher im Analyse und Design der Applikation, was aber genereller Natur ist.

Wolfgang Schmidt

5. Praxis Szenario

Als Beispiel für ein Anwendungsszenario kann folgende Problematik genommen werden. Ein Client benötigt Informationen und Dienste, die auf einem Applikationsserver verwaltet werden, in Form von Datenobjekten und Suchdiensten. Die Daten werden persistent in einer relationalen Datenbank gehalten, aus denen die Applikation Instanzen von Anwendungsobjekten bildet. Applikationsserver und Datenbankserver sind im selben Firmennetz. Der Client verbindet sich z.B. per Internet oder Modem mit dem Firmennetz.

Die folgende Abbildung veranschaulicht die Situation:

Java Applet/Applikation

(Instanzen von Stubobjekten)

Server Applikation

(Instanzen von RemoteObject)

RDBMS

Wolfgang Schmidt

Da einerseits der Zugriff abhängig ist von der Applikationslogik und natürlich auch Suchanfragen schnell bedient werden sollen, ist ein direkter Zugriff des Clients auf die Datenbank nicht sinnvoll. Zudem existiert beim Intranet/Internet-Zugriff seitens des Client per Applet die Restriktion, daß die Rechnersysteme des DB- und HTTP-Servers identisch sein müssen, aufgrund der Sicherheitssperre des AppletSecurity-Managers.

Eine Lösung ist eine RMI Applikationkomponente (Frontend) auf dem HTTP-Server, der mit dem Rest der Applikation kommuniziert (die evtl. auf noch einem anderen Server liegt). Diese RMI Applikation kann nun mittels der Java-Standardschnittstelle zu relationalen Datenbanken (JDBC) auf den RDBMS-Server zugreifen. Da dies innerhalb des Firmennetzes geschieht gibt es einerseits keine Security-Probleme und andererseits wird dies performanter sein als der Zugriff des Clients direkt auf die DB.

Zudem sind damit die einzelnen Ebenen der Applikation (Präsentationskomponente, Applikationslogik, Datenverwaltung bzw. entfernter DB-Zugriff) über standardisierte Schnittstellen gekapselt und somit leichter zu Warten. Die Sicherheitsbelange werden durch die einzelnen Securitymanager seitens Java beachtet. Die Clients bleiben weitgehend auf die Präsentations- und Anfragekomponenten beschränkt und sind damit kostengünstig zu realisieren und auch performant online über das Netz zu laden (Applets).

Wolfgang Schmidt

6. Zusammenfassung

Das Java RMI System bietet die Möglichkeit eng gekoppelte Verteilte Systeme (Server/Client Applikationsstrukturen) innerhalb der Java Umgebung zu realisieren.

Im RMI-System ist derzeit noch nicht die Möglichkeit von Serverobjekt-Replikaten gegeben, aber bereits von der Konzeption her vorbereitet und mit dem nächsten Release des JDK ist auch die Realisierung geplant.

Das verteilte Objektmodell und die APIs des Java RMI, fügen sich nahtlos in die Java-Umgebung ein. Das Java-Objektmodell wird durch RMI nur erweitert und das Handling der Remote Objekte ist analog zu lokalen Java-Objekten. Damit ist natürlich die Einführung in einem Java-Umfeld vereinfacht möglich und mit geringeren Einführungskosten behaftet.

Das RMI stellt keine Broker-Architektur wie CORBA zur Verfügung. Dies wird derzeit von der CORBA-Schnittstellensprache Java IDL unterstützt. Im nächsten Release des JDK wird es möglich sein bei der Benutzung des RMI als Transportprotokoll nicht das Java eigene Protokoll (JRMP) sondern das Inetrnet Inter-ORB Protokoll (IIOP) zu verwenden. Damit stehen dann natürlich nur die beschränkten sprachunabhängigen Möglichkeiten des IIOP zur Verfügung. SUN arbeitet mit der Object Management Group (OMG) derzeit an einer Angleichung der Fähigkeiten von JRMP und IIOP, so daß auch im CORBA Bereich weitgehend die volle Funktionalität des Java RMI zur Verfügung steht.

Somit ist zusammenfassend zu bemerken, daß die Realisierung einer verteilten Anwendung mit Java RMI sich im Java-Umfeld anbietet. Aufgrund des besonders formulierten Ziels seitens SUN, das RMI möglichst nahtlos in die Sprache Java einzufügen, ist es für Java-Entwickler nicht besonders schwierig oder aufwendig ist eine Verteilte Anwendung zu realisieren. Die Anforderung liegt eher im Analyse und Design der Applikation, was aber genereller Natur ist. Eine Realisierung von Clientobjekten mit Java und dem RMI für heterogene verteilte Systeme, die über den CORBA-Standard kommunizieren, bietet sich noch nicht an. Damit ist das Java RMI zur Zeit noch nur für einheitlich in Java entwickelten verteilten Systemen einzusetzen.

Wolfgang Schmidt

7. Literaturverzeichnis

[RMISpec97] Java™ Remote Method Invocation Specification, SUN, JDK

[RMITut97] Java™ Remote Method Invocation Tutorial, SUN, JDK 1.1,

[ObjSer97] Java™ Object Serialisation Specification, SUN, JDK 1.1,

Cornel, G., Hostmann, C.S., „Core Java“ 2 nd Edition, Chapter [Core96]