18.11 Entfernte Objekte übergeben und laden 

In unserem bisherigen Beispiel haben wir zwei Ganzzahlwerte übergeben. Die Implementierung der Stellvertreter ist nun so, dass eine Socket-Verbindung die Daten überträgt. Da keine Objekte transportiert werden, muss keine Serialisierung die Daten in Reihe liefern. Wir wollen uns nun damit beschäftigen, was mit Objekten passiert, die übertragen werden. Wir können verschiedene Klassen unterscheiden:

Klassen, die auf beiden Seiten vorliegen, weil es zum Beispiel Klassen aus dem Standard-API sind.

Klassen, die nur auf der Server-Seite vorliegen und dem Client nicht bekannt sind.

Klassen, die selbst wieder Remote implementieren.

Liegt die Klasse auf beiden Seiten als Klassenbeschreibung vor, da sie etwa eine Standard-Klasse oder in beiden Pfaden eingetragen ist, müssen wir mit keinen Problemen rechnen. Die übertragenen Daten müssen jedoch von Klassen stammen, die serialisierbar sind.

Wann ist eine Klassenbeschreibung nötig?

Schwierig wird die Lage erst dann, wenn der Server Klassen benötigt, die beim Client liegen. Es könnte etwa eine entfernte Methode

int max( Vector v );

geben, die das Maximum der Elemente aus dem Vektor bildet. Die Elemente sind jedoch Objekte, die der Server vorher nicht gesehen hat, etwa Unterklassen von Konto im Vector, und der Server kennt nur Konto und die Methoden davon, bindet aber dynamisch an die Methode der Unterklasse.

18.11.1 Klassen vom RMI-Klassenlader nachladen 

Wir kommen also dazu, dass der Klassenlader Klassen nachladen muss, die für den verteilten Aufruf auf der Client- und Server-Seite nötig sind. Das erinnert an einen Applet-Klassenlader, der Gleiches machen muss. Für RMI-Aufrufe kommt der RMI-Klassenlader java.rmi.RMIClassLoader zum Zuge. Dieser Lader lädt jetzt die Stellvertreter (die Stubs) sowie weitere benötigten Klassen in die lokale virtuelle Maschine. Woher die Klassen kommen, ist dem Lader egal. Sie können in CLASSPATH stehen, im aktuellen Verzeichnis oder auf einem Webserver. Im letzten Fall steuert die Eigenschaft java.rmi.server.codebase den Ort.

java -Djava.rmi.codebase>http://server/classimlp

Wenn ein Client einen entfernten Aufruf startet, sucht er die Stub-Klasse. Findet er die Klasse nicht in dem eigenen Namensraum, wird die Codebase hinzugezogen. Der Client wird dann die Stub-Klasse von der angegebenen URL anfordern. Der Server überträgt anschließend die Klassendatei zum RMI-Client. Die Stub-Klasse muss also dem Server bekannt sein, da er sie ja übertragen muss.

Sollten die Klassen nur vom Server geladen werden und aus anderen, vielleicht dunklen Stellen des Dateisystems, so ist die Eigenschaft java.rmi.useCodebaseOnly auf true zu setzen.

18.11.2 Sicherheitsmanager 

Damit die Klassen nicht auf dem Client oder Server liegen müssen, können sie nachträglich über den RMI-Klassenlader geladen werden. Doch das Laden von Klassen muss erst vom Sicherheitsmanager abgesegnet werden. Die Erlaubnis, ob Klassen übertragen werden dürfen, regelt ein spezieller Sicherheitsmanager. Die Klasse RMISecurityManager definiert eine Sicherheitsrichtlinie, dass serialisierbare Klassen von einem Rechner auf den anderen übertragen werden können. Wenn wir mit primitiven Werten arbeiten, wie in unserem ersten Beispiel, oder mit Standard-Klassen, ist dieser RMISecurityManager nicht nötig. Da wir aber serialisierbare Klassen übertragen müssen, ist der Sicherheitsmanager vorgeschrieben. Da Applets schon vom Applet-Sicherheitsmanager überwacht werden, können sie keinen zusätzlichen RMISecurityManager installieren.

public class RMISecurityManager extends SecurityManager {
  public RMISecurityManager() {
  }
}

Wenn wir folgende Zeile in unseren Servercode aufnehmen, wird RMI vom Klassenlader die Klassen laden können:

System.setSecurityManager( new RMISecurityManager() );

Erst der Sicherheitsmanager gibt uns das Recht zur Übertragung. Tragen wir ihn nicht ein, so führt es zu einer Fehlermeldung der folgenden Art:

java.security.AccessControlException: access denied
(java.net.SocketPermission 127.0.0.1:1099 connect,resolve)

Die Meldung zeigt an, dass die aktuellen Sicherheitsrichtlinien die Übertragung nicht zulassen. Häufig ist es so, dass die Java-Installationen Sicherheitsrichtlinien vorgeben, die sehr eingeschränkt sind.

Policy-Dateien

Um die Richtlinien zu lockern, müssen wir eine Policy-Datei anlegen, die uns die Rechte zum Laden von Klassen gibt.

grant
{
  permission java.security.AllPermission;
};

Der Sicherheitsmanager bindet nun eine Reihe dieser Policy-Dateien ein. Wollen wir zusätzliche Policies einbinden, so geben wir sie auf der Kommandozeile für den Java-Interpreter an.

$ java -Djava.security.manager -Djava.security.policy=rmi.policy MyClass

Die Option -D setzt Systemeigenschaften. Die Anweisung -Djava.security.manager hat den gleichen Effekt wie

System.setSecurityManager( new SecurityManager() );

Dies installiert einen Sicherheitsmanager, der dann die nachfolgende Policy behandelt. Sie ist als URL angegeben und in unserem Fall eine Datei im aktuellen Verzeichnis.

String codebase = "http://server/verzeichnis/RMI/";
System.setProperty( "java.rmi.server.codebase", codebase );
System.setProperty( "java.security.policy", codebase+"rmi.policy" );
System.setSecurityManager( new RMISecurityManager() );