distributed computing

Projektstudium SS98 - distributed computing

Java Distributed Object Modell

Definition:: Im Distributed Object Model ist ein entferntes Objekt ("Remote Object") ein Objekt, dessen Methoden sich in einer anderen virtuellen Maschine befinden können, sogar auf einem anderen Host. Von dort werden die Methoden dann aufgerufen. Ein solches Objekt wird durch ein oder mehrere Remote Interfaces beschrieben, das sind normale Java-Interfaces, worin die entfernten Methoden deklariert werden.

Remote Method Invocation ist nun das Aufrufen einer Methode des Remote Interface eines entfernten Objekts. Dabei hat dieser Methodenaufruf dieselbe Syntax wie ein Aufruf einer lokalen Methode.

Vergleich: distributed <---> nondistributed model

Gleiches:

Die Referenz auf ein entferntes Objekt kann als Argument übergeben werden, oder als Rückgabewert eines Methodenaufrufs (lokal oder entfernt) dienen.
Entfernte Objekte können in jeden implementierten Interfacetyp umgewandelt werden, dazu wird die normale Syntax der Cast-Operation benutzt.
Operator instanceof kann ebenso zum Testen mit den entfernten Interfaces benutzt werden wie mit lokalen.

Unterschiede:

Clients von entfernten Objekten arbeiten mit den Remote Interfaces und nicht mit den implementierten Klassen dieser Interfaces.
Lokale Argumente und Rückgabewerte werden an entfernte Methodenaufrufe hauptsächlich als Kopie übergeben, da Referenzen auf Objekte nur innerhalb einer virtuellen Maschine sinnvoll sind.
Ein entferntes Objekt wird als Referenz übergeben, und nicht die entfernte Implementation.
Einige Methoden der Klasse Object sind speziell für entfernte Objekte definiert.
Die Fehlerarten, die bei Aufrufen von entfernten Objekten auftreten können, sind komplizierter als bei lokalen Objekten, deshalb müssen Clients die zusätzlichen Exceptions der entfernten Methodenaufrufe abfangen.

RMI Interfaces und Klassenhierarchie

Die Interfaces und Klassen, die das Verhalten des RMI Systems spezifizieren sind in den Paketen java.rmi und java.rmi.server definiert. Die folgende Abbildung zeigt die Hierarchie der Klassen und die Abhängigkeiten voneinander:

Das Remote Interface:

Jeder Client benötigt zur Benutzung von Serverobjekten, die auf dem Server existieren, eine Beschreibung über die Fähigkeiten eines entfernten Objektes. Deshalb implementiert jedes Interface für entfernte Objekte, direkt oder indirekt, das Interface java.rmi.remote, damit wird das Objekt als ein "Remote-Objekt" gekennzeichnet. In diesem Interface sind keine Methoden definiert. Klassen, die das Interface implementieren, deren Methoden können entfernt aufgerufen werden.

Die Klasse RemoteObject und deren Subklassen:

Serverfunktionalität wird von den Klassen java.rmi.server.RemoteObject, java.rmi.server.RemoteServer, sowie der abgeleiteten Klasse java.rmi.server.UnicastRemoteObject bereitgestellt. Clients, die nicht selbst entfernte Objekte sind, benötigen diese Pakete nicht. Die RemoteObject-Klasse entspricht der Klasse Object für lokale Objekte, sie stellt zusätzlich eine allgemeine Netzwerkfähigkeit für die entfernten Objekte bereit. Die Klasse RemoteServer ist eine abstrakte Überklasse für alle Serverimplementationen, sie stellt einen Rahmen für die Arbeit mit Serverobjekten dar. Eine konkrete Ableitung dieser Klasse ist die UnicastRemoteObject-Klasse, sie definiert ein entferntes Objekt, dessen Referenzen nur solange gültig sind, solange der Serverprozeß arbeitet. Die UnicastRemoteObject Klasse bietet Punkt-zu-Punkt Unterstützung mit Hilfe von TCP-Streams.

Die RemoteException Klasse:

Die Klasse RemoteException ist eine Überklasse für alle Exceptions die zur Laufzeit von RMI auftreten können. Um die Robustheit des RMI-Systems garantieren zu können, muß nun jede Methode, die als entfernt deklariert werden soll, die RemoteException in der throws-Klausel definieren. Die Exception wird dann ausgelöst, wenn ein entfernter Methodenaufruf fehlschlägt, z.B. dann, wenn das Netzwerk ausgefallen ist, oder der Server nicht erreichbar ist.

Parameterübergabe

Zur Übertragung von Parametern, die einfachen Datentyps oder Objektinstanzen sein können, ist eine Serialisierung des Objekts nötig. Hierzu gibt es in Java einen speziellen Mechanismus, genannt Object Serialization. Dieser bietet das Interface java.io.Serializable an, welches von den Parameterklassen implementiert werden muß. Dies ist bei fast allen Standardklassen des JDK gegeben, insbesondere bei den Remoteklassen.

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

Zu unterscheiden ist die Übergabe von lokalen Objekten und von entfernten Objekten.
Für lokale Objekte existieren naturgemäß keine Stellvertreterobjekte (Stub und Skeleton) und keine Registrierung auf einem entfernten Server. Somit müssen lokale Objekte bei einer Übertragung kopiert werden, so daß auf dem entfernten System eine eigenständige Objektkopie verfügbar ist.

Für entfernte Objekte gibt es diese Stellvertreterobjekte und die Registrierung auf dem Server. Damit ist eine Referenzierung dieser Objekte möglich. Wird also ein RemoteObject als Parameter eines Methodenaufrufs angegeben, so wird sein Stellverteter-Objekt, der Stub, übergeben.

Es gibt auch Klassen deren Instanzen nicht übergeben werden sollen, z.B. aus Sicherheitsgründen, dieses wird dadurch verhindert, daß die Serialisierung nicht implementiert wird. In diesem Fall löst der entfernte Methodenaufruf eine Exception aus.

Ausnahmebehandlung

Im Bereich von verteilten Anwendungen hat die Ausnahmebehandlung eine besondere Rolle, da die verschiedensten Fehlersituationen auftreten können, z.B. Fehler bei der Ausführung entfernter Methoden, Ausfall von Server- oder Netzwerkkomponenten.
Daher muß also die Ausnahmebehandlung stets beim Umgang mit entfernten Ressourcen berücksichtigt werden. Tritt ein Fehler auf wird ein spezielles Objekt, eine Exception, ausgelöst. Diese Objekte werden im lokalen Fall von der Überklasse Exception, und im entfernten Fall von der Überklasse RemoteException abgeleitet. Die Fehlerbehandlung geschieht in beiden Fällen analog. Im entfernten Fall muß nur beachtet werden, ob der Fehler auftrat, vor während oder nachdem der entfernte Aufruf abgearbeitet wurde.

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 Problem zu lösen gibt es einen Mechanismus im RMI ("bootstrap naming 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 diesen Serverobjekten erhalten können. Dieser Nameservice läuft als Dämonprozess auf dem Serversystem und wacht an einem Port (Default 1099) auf eine Dienstanforderung.

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.