Sonja  Adler  

JAVA   RMI

Inhaltsverzeichnis   

Inhaltsverzeichnis......................................................................................   III

Abbildungsverzeichnis.   IV

Abk  ürzungsverzeichnis  V

1  Verteilte Programmierung mit Remote Method Invocation.  1

1.1  Anforderungen an RMI.  1

1.2  Aufruf von entfernten Methoden  2

1.3  Abstraktion  2

1.4  System-Architektur  3

2  Konzept  5

2.1  Der Stub  5

2.2  Der Skeleton  5

2.3  Die Registry  6

3  Anwendungsbeispiel „SayHelloNetzwerke“  9

3.1  Klassenstruktur des Anwendungsbeispiels.  9

3.2  Das RMI-Interface  10

3.2.1  Aufruf der Schnittstelle  10

3.2.2  Implementierung der Schnittstelle  11

3.3  Die RMI-Clientklasse  12

3.4  RMI-Serverklasse.  13

3.5  Ablaufreihenfolge beim Start Client/Server verteilt.  13

4  Sicherheitsmechanismen  15

4.1  Der Securitymanager  15

4.2  Verteiltes Garbage Collection  15

4.3  Passing Behaviour  15

5  Callbacks  16

6  Probleme mit entfernten Methoden  17

7  Bewertung RMI  19

Literaturverzeichnis   20

Quellenverzeichnis.   21

III

Sonja  Adler  

JAVA   

Abbildungsverzeichnis   

Abb.  1 Funktion RMI  

Abb.  2 Bytestream vom Client zum Server  

Abb.  3 Architektur von RMI.  

Abb.  4 Stub und Skeleton  

Abb.  5 RMI Registry mit Methodenaufruf  

Abb.  6 Aufbau des Anwendungsbeispiels  

Abb.  7 Klassenstruktur  

Abb.  8 Schnittstellenaufruf  

Abb.  9 myRMIInterface  

Abb.  10 Schnittstellenimplementierung.  

Abb.  11 myRMIImpl  

Abb.  12 myRMIClient.  

Abb.  13 wideopen.policy  

Abb.  14 myRMIServer.  

IV

Sonja Adler

JAVA RMI

Abkürzungsverzeichnis

JVM Virtual Machine GC Garbage Collector RPC Remote Procedure Call JDK Java Development Kit JRMP Java Remote Method Protocol IIOP Internet Inter Object Request Broker Protocol TCP/IP Transmission Control Protocol / Internet Protocol

V

Sonja Adler

JAVA RMI

1 Verteilte Programmierung mit Remote Method Invocation

RMI steht für Java Remote Method Invocation, eine Technologie von Sun, die für die einfache Realisierung von verteilten Objekten in Java konzipiert wurde. RMI ist ein Mechanismus der eine Kommunikation zwischen Client- und Serverprogramm über das Netzwerk ermöglicht. Vorgänger ist der RPC (Remote Procedure Call) ebenfalls von Sun entwickelt, der in der prozeduralen Welt Anwendung fand. RMI kann im Gegensatz dazu ganze Objekte als Argumente verschicken und als Rückgabewert empfangen. Dies gilt ebenso für primitive wie auch für komplexe Datentypen. Ein Java Programm arbeitet mit einer virtuellen Maschine (JVM), die auf unterschiedlichen Rechnern laufen können. Zwischen diesen JVMs kann mit Remote Method Invocation ein entfernter Methodenaufruf eines Objektes in einer anderen virtuellen Maschine, die sich auf dem eigenen Rechner genauso wie auf einem anderen Rechner befinden kann, erfolgen(siehe Abbildung 1).

Abb. 1 Funktion RMI

1.1 Anforderungen an RMI

Integration des verteilten Objektmodells in Java:

1

Sonja Adler

JAVA RMI

o weitestgehend die Beibehaltung der Java-Objektsemantik

o Identität der Aufrufsyntax lokaler und verteilter Objekte

o Kompatibilität mit der Java VM, Securitymanager und Klassenlader

o Realisierung der Distributed-Garbage-Collection

1.2 Aufruf von entfernten Methoden

Der lokale Methodenaufruf über die eigene JVM hinaus wird mit RMI ermöglicht. Dabei werden die RMI Methoden von einem Client (Aufrufer der Methoden) an einem Server-Objekt bzw. Remote-Objekt (den Aufgerufenen) ausgeführt, der als Dienstleister fungiert. Im Gegensatz zum lokalen Objektaufruf erfolgt kein Aufruf an Objekten, sondern ein Aufruf über Interfaces. Die Übergabe an das Remote-Objekt erfolgt ausschließlich „Call by Value“, d.h. Parameter und Ergebnisse werden nicht als Referenzen, sondern als Kopien übergeben. Als Transport Protokoll kommen dabei JRMP und IIOP zum Einsatz. Im Vergleich zu einem lokalen Aufruf eines Objektes bedingt bei RMI der Aufruf eines entfernen Objektes eine komplizierte Fehlersemantik bezüglich der Referenzintegrität, Netzfehler, Sicherheit, etc. RMI ist zudem Mutithreading- fähig, d. h. mehrere zeitgleich eintreffende RMI Aufrufe (lokal oder verteilt) können in Threads abgearbeitet werden, was einen erheblichen Performance-gewinn mit sich bringt. Bezüglich der erforderlichen Synchronisation um mögliche Schreibkonflikte zu verhindern, ist davon auszugehen, daß Methoden immer nebenläufig aufgerufen werden.

1.3 Abstraktion

Einer der Vorteile von RMI ist die Abstraktion, bei der Schnittstellen- und Implementierungsunterscheidung. Das verteilte System ist daher einfach zu konstruieren und die Implementierung kann leicht verändert werden. Demnach ist das Definieren von Vorgaben und deren separate Implementierung ein wichtiges Prinzip bei RMI. Die Anforderung eines verteilten Systems ist erfüllt, da sich ein Client nur auf der Definition eines Services konzentrieren kann und der Server sich nur um die Bereitstellung des Services kümmern muss.

2

Sonja Adler

JAVA RMI

1.4 System-Architektur

Die Architektur von RMI ist in einem Schichtenmodell aufgebaut, das aus mehreren Ebenen besteht. In der folgenden Abbildung 1 kann man erkennen, wie beim Aufruf einer Methode des Remote-Objektes die Schichten durchlaufen werden. Dabei wird ersichtlich, daß der Client der die Methode aufrufen möchte, die im Server-Objekt ausgeführt werden soll, nicht direkt darauf zugreifen kann. Ein Stellvertreterobjekt nimmt die Daten entgegen und überträgt sie zum Server. Nach der Antwort präsentiert das Stellvertreterobjekt das Ergebnis. Die Verbindung zwischen Client und Server wird über die Stellvertreterobjekte (Proxies) Stub und Skeleton realisiert. Sie setzen die Transportschicht um, indem sie es realisieren, daß die Parameter von einem Ort zum anderen gebracht werden. Auf der Clientseite wird zuerst der mit einem Hilfsprogramm automatisch generierte Server-Stub durchlaufen, wo die Methode ausgeführt wird. Es wird demnach nicht mit dem Server gesprochen, sondern nur mit einer Funktion, die so aussieht wie die Serverfunktion. Der Client merkt nicht das der Stellvertreter die Parameter entgegennimmt, sie in eine Server-Anfrage verpackt und als Bytestream wegschickt (siehe Abbildung 2). Diese Serialisierung/Deserialisierung ist notwendig, um Objekte versenden und speichern zu können, denn Parameter und Ergebnisse müssen übertragen werden können. Die Serialisierungsroutinen erfolgen automatisch, wenn die Klassen die Schnittstelle java.io.Serializable implementieren. Daraufhin kann der rmic-Compiler durch die Analyse der Klassendefinitionen den Code für die Serialisierung/ Deserialisierung erzeugen.

Abb. 2 Bytestream vom Client zum Server

3