18.8 Der Server: entfernte Objekte beim Namensdienst anmelden

An dieser Stelle haben wir schon fast alles zusammen. Der Namensdienst läuft und wartet auf den Server und den Client. Beginnen wir mit dem Server. Er ist ein normales Java-Programm ohne Einschränkungen. Er muss weder etwas mit Remote noch mit Serializable zu schaffen haben. Seine einzige Aufgabe ist es, ein entferntes Objekt anzulegen und beim Namensdienst einzutragen. Dazu wird die Methode rebind() oder bind() benutzt.

Listing 18.4 AdderServer.java

import java.rmi.*;
import java.rmi.server.*;
public class AdderServer
{
  public static void main( String args[] ) throws Exception
  {
    Naming.rebind( "rmi://localhost/adder", new AdderImpl() );
    System.out.println( "Adder bound" );
  }
}

An diesem Programm ist abzulesen, dass das Eintragen sehr einfach ist. Es ist als assoziative Datenstruktur zu verstehen, die einen Objektnamen mit einem entfernten Objekt assoziiert. Die Notation beim Anmelden für das Objekt ist wie bei einer URL:

rmi://Host:Port/Objektname

Wenn ein alternativer Port für den Namensdienst gewählt wurde, stellen wir diesen mit Doppelpunkt wie üblich hinten an - sonst läuft der Namensdienst standardmäßig unter 1099. Der vorangestellte Protokollname rmi ist optional, so dass er auch weggelassen werden kann. Ist kein Rechnername angegeben, so wird localhost angenommen. Im oberen Beispiel lässt sich damit auch einfach schreiben: rebind("adder", new AdderImpl()).

Was hat das Binden damit zu tun?

Zum Binden der Informationen bietet der Namensdienst zwei unterschiedliche Funktionen an. bind() trägt den Dienst im Namensdienst ein, aber wenn schon ein anderer Dienst unter dem gleichen Namen läuft, wird eine AlreadyBoundException ausgelöst. rebind() dagegen fügt, abhängig vom Namensdienst, einen neuen Eintrag mit dem gleichen Namen hinzu oder überschreibt den alten.

Meldet der Server das Remote-Objekt an (AdderImpl), so wird es serialisiert und zur Registry übertragen. Der Client wird später dieses serialisierte Objekt bekommen und wichtige Informationen entnehmen können.

Und abmelden

Ist der Dienst nicht mehr gewünscht, so lässt er sich mit unbind() wieder abmelden, solange der Namensdienst läuft. Aus Sicherheitsgründen lässt der Namensdienst Objekte nur von dem Server entbinden, der auch das Objekt angemeldet hat. Einen zusätzlichen Namen müssen wir daher nicht angeben.

final class java.rmi.Naming

E static void bind( String name, Remote obj ) throws AlreadyBoundException, MalformedURLException, RemoteException Bindet das Objekt ref, welches in der Regel der Stub ist, an den Namen name und trägt es so in der Registrierung ein. Eine AlreadyBoundException zeigt an, dass der Name schon vergeben ist. Die MalformedURLException informiert, wenn der Name ungültig gebunden ist. Eine RemoteException wird ausgelöst, wenn der Namensdienst nicht erreicht werden konnte. Fehlende Rechte führen zu einer AccessException.

static void rebind( String name, Remote obj ) Verhält sich wie bind(), mit dem Unterschied, dass Objekte ersetzt werden, falls sie schon angemeldet sind.

static void unbind( String name ) Entfernt das Objekt aus der Registrierung. Ist das Objekt nicht gebunden, so folgt eine NotBoundException. Die anderen Fehler sind wie bei bind().

18.8.1 Automatisches Anmelden bei Bedarf

Bisher haben wir ein entferntes Objekt erzeugt und angemeldet, so dass später das Objekt schon da ist, wenn es angesprochen wird. Wir haben das durch UnicastRemoteObject realisiert, dessen Arbeitsweise darin besteht, das Objekt einmal anzumelden. Sollten auf einem Objekt-Server mehrere Dienste vor sich hin dämmern, ist das natürlich nicht sonderlich effektiv und kostet unnötig Ressourcen. Daher unterstützt die Bibliothek neben UnicastRemoteObject eine weitere Klasse, die das automatische Hochstarten eines Dienstes erlaubt. Wir leiten unser Objekt dann von der Klasse Activatable ab, und daraufhin werden die Objekte bis zu ihrer Aktivierung in einem Dämmerzustand gehalten. Kommt dann der erste Zustand, entfaltet das System dieses Objekt, so dass es Anfragen entgegennehmen kann. Wird das Objekt nach seiner Tat wiederum nicht verwendet, kann es wieder eingefroren werden. Die Daten bleiben dabei stabil. Activatable¹ ist eine abstrakte Klasse, die von RemoteServer abgeleitet ist. Die unterschiedlichen Klassen zum Aktivieren bei Bedarf liegen alle im Paket java.rmi. activation.

¹ Wieder etwas, was auf -able endet, aber keine Schnittstelle ist.