Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger

 << zurück
Java ist auch eine Insel von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 5
Java ist auch eine Insel

Java ist auch eine Insel
5., akt. und erw. Auflage
1454 S., mit CD, 49,90 Euro
Galileo Computing
ISBN 3-89842-747-1
gp Kapitel 18 Verteilte Programmierung mit RMI und SOAP
  gp 18.1 Entfernte Methoden
    gp 18.1.1 Wie entfernte Methoden arbeiten
    gp 18.1.2 Stellvertreter (Proxy)
    gp 18.1.3 RMI
    gp 18.1.4 Wie die Stellvertreter die Daten übertragen
    gp 18.1.5 Probleme mit entfernten Methoden
  gp 18.2 Nutzen von RMI bei Middleware-Lösungen
  gp 18.3 Die Lösung für Java ist RMI
    gp 18.3.1 Entfernte Objekte programmieren
    gp 18.3.2 Entfernte und lokale Objekte im Vergleich
  gp 18.4 Definition einer entfernten Schnittstelle
  gp 18.5 Implementierung der Remote-Schnittstelle
  gp 18.6 Stellvertreterobjekte erzeugen
  gp 18.7 Der Namensdienst (Registry)
    gp 18.7.1 Der Port
  gp 18.8 Der Server
    gp 18.8.1 Entfernte Objekte beim Namensdienst anmelden
    gp 18.8.2 Automatisches Anmelden bei Bedarf
  gp 18.9 Einen Client programmieren
    gp 18.9.1 Einfaches Logging
  gp 18.10 Aufräumen mit dem DGC
  gp 18.11 Entfernte Objekte übergeben und laden
    gp 18.11.1 Klassen vom RMI-Klassenlader nachladen
  gp 18.12 Registry wird vom Server gestartet
  gp 18.13 RMI über die Firewall
    gp 18.13.1 RMI über HTTP getunnelt
  gp 18.14 RMI und CORBA
  gp 18.15 Daily Soap
    gp 18.15.1 SOAP-Implementierungen
    gp 18.15.2 Einen Client mit der Apache-Bibliothek implementieren
    gp 18.15.3 Der Seifen-Server
  gp 18.16 Java Message Service (JMS)


Galileo Computing

18.11 Entfernte Objekte übergeben und ladedowntop

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:

gp  Klassen, die auf beiden Seiten vorliegen, weil es zum Beispiel Klassen aus dem Standard-API sind;
gp  Klassen, die nur auf der Server-Seite vorliegen und dem Client nicht bekannt sind;
gp  Klassen, die selbst wieder Remote implementieren.

Liegt die Klasse auf beiden Seiten als Klassenbeschreibung vor, weil es sich etwa um eine Standardklasse handelt, oder ist sie in beiden Pfaden eingetragen, sind keine Probleme zu erwarten. Die übertragenen Daten müssen jedoch von Klassen stammen, die serialisierbar sind.

Wann ist eine Klassenbeschreibung nötig?

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

int max( List v );

geben, die das Maximum der Elemente aus dem Sammlung bildet. Die Elemente sind jedoch Objekte, die der Server vorher nicht gesehen hat, etwa Objekte vom Typ Schutzpatron.


Galileo Computing

18.11.1 Klassen vom RMI-Klassenlader nachladetoptop

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.


Beispiel   Setzen der Codebase auf einen Web-Server, damit das RMI-Programm die benötigten Klassen aus http://server/classimlp laden kann.