Die Vorteile von Java Remote Method Invocation (RMI)

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Verteilte Programmierung mit Remote Method Invocation
1.1 Anforderungen an RMI
1.2 Aufruf von entfernten Methoden
1.3 Abstraktion
1.4 System-Architektur

2 Konzept
2.1 Der Stub
2.2 Der Skeleton
2.3 Die Registry

3 Anwendungsbeispiel „SayHelloNetzwerke“
3.1 Klassenstruktur des Anwendungsbeispiels
3.2 Das RMI-Interface
3.2.1 Aufruf der Schnittstelle
3.2.2 Implementierung der Schnittstelle
3.3 Die RMI-Clientklasse
3.4 RMI-Serverklasse
3.5 Ablaufreihenfolge beim Start Client/Server verteilt

4 Sicherheitsmechanismen
4.1 Der Securitymanager
4.2 Verteiltes Garbage Collection
4.3 Passing Behaviour

5 Callbacks

6 Probleme mit entfernten Methoden

7 Bewertung RMI

Literaturverzeichnis

Quellenverzeichnis

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

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 Funktion RMI

1.1 Anforderungen an RMI

Integration des verteilten Objektmodells in Java:

- weitestgehend die Beibehaltung der Java-Objektsemantik
- Identität der Aufrufsyntax lokaler und verteilter Objekte
- Kompatibilität mit der Java VM, Securitymanager und Klassenlader
- 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.

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.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 Bytestream vom Client zum Server

Anschließend wird in der Remote Reference Schicht das Server-Objekt adressiert und über die Transportschicht über das Netz geleitet. Die Remote Reference Schicht ist für die Semantik von Aufruf und Referenz verantwortlich. Die Transportschicht verbindet die JVMs und die Kommunikation erfolgt, auch wenn die JVMs sich auf denselben physikalischen Rechner befinden, über TCP/IP. Auf der Serverseite wird der ankommende Methodenaufruf über die Transport- und Remote Reference Schicht an den ebenso automatisch generierten Skeleton geleitet. Dieser Skeleton, der wie der Stub als Stellvertreterobjekt agiert, ruft dann die eigentliche Methode im Server-Objekt auf. Der Server merkt nicht, daß er nicht mit lokalen Daten versorgt wird. Die Methode wird abgearbeitet, und falls ein Rückgabewert vorhanden ist, wird dieser über denselben Weg zum Client zurückgeschickt und übergeben.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 Architektur von RMI

2 Konzept

Um mit RMI arbeiten zu können, sind 3 Teile mit der Kommunikation beschäftigt:

2.1 Der Stub

Der Stub (Client-seitiger Proxy) als Stellvertreterobjekt für den Server im Client wird in Java durch den Aufruf des RMI-Compilers (rmic) automatisch erzeugt, da eine Implementierung per Hand zu aufwändig und unflexibel wäre. Der RMI-Compiler generiert selbstständig aus der Methodenbeschreibung die Stellvertreter Stub und Skeleton. Der Aufruf der entfernten Methode erfolgt über eine entfernte Referenz zum Server-Objekt. Dabei wird der Methodenname sowie die Parameter mittels Datenstrom über das Netzwerk übertragen. Da der Stub serverseitig generiert wurde, ist zu beachten, daß die ServerKlasse_stub.class in die JVM des Clients nachgeladen werden muß. Dies erfolgt entweder lokal über das Setzen des Classpathes oder über das Netzwerk durch die Angabe einer Basis-URL(den Codebase).

2.2 Der Skeleton

Der Skeleton (Server-seitig) als Stellvertreterobjekt für den Client im Server wird in Java ebenfalls durch den Aufruf des RMI-Compilers (rmic) automatisch erzeugt. Dieser dient als Vermittlungsobjekt zwischen dem Stub und dem Server-Objekt. Der Skeleton hat die Aufgabe die aufzurufende Methode zu ermitteln und aufzurufen. Dabei überträgt er die erhaltenden Rückgabewerte des Server-Objektes mittels Datenstrom über das Netzwerk zurück zum Client. In der folgenden Abbildung 4 ist eine bildliche Darstellung, wie rmic – der Compiler für Verbindungsstücke, eine Generierung des Stubs und des Skeleton realisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4 Stub und Skeleton

[...]