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 jetzt 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 Standardklasse ist oder in beiden Pfaden eingetragen ist, müssen wir nicht mit 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ötigte 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 Web-Server. Im letzten Fall steuert die Eigenschaft java.rmi.server.codebase den Ort.

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, führt das 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() );