18.3 Die Lösung für Java ist RMI
 
Java RMI ist nun der Mechanismus, um entfernte Objekte und deren Angebote zu nutzen. Auch schon der Vorgänger in der prozeduralen Welt, RPC (Remote Procedure Call), ist eine Entwicklung von Sun. Mit RMI lässt sich somit auf hohem Abstraktionsniveau arbeiten. Damit dies funktioniert, sind drei Teile mit der Kommunikation beschäftigt:
| 1. |
Der Server stellt das entfernte Objekt mit der Funktion bereit. Die Funktion läuft im eigenen Adressraum, und der Server leitet Anfragen an diese Funktion weiter. |
| 2. |
Der Namensdienst (Registry) ist ein Anfragedienst, der Objekte und ihre Methoden mit einem eindeutigen Namen verbindet. Der Server meldet die Objekte bei diesem Namensdienst an. |
| 3. |
Der Client ist der Nutzer des Dienstes und ruft die Methode auf einem entfernten Objekt auf. Auch er hat einen eigenen Adressraum. Möchte der Client eine Funktion nutzen, so fragt er bei dem Namensdienst an, um Zugriff zu bekommen. |
18.3.1 Entfernte Objekte programmieren
Um entfernte Objekte mit ihren Methoden in Java-Programmen zu nutzen, müssen wir einige Schritte machen, die im Folgenden kurz skizziert werden. An den Schritten spiegelt sich der Programmieraufwand wider:
| 1. |
Wir geben eine entfernte Schnittstelle an, die die Methode(n) definiert. |
| 2. |
Wir implementieren eine Klasse, die die Schnittstelle implementiert und die Methode mit Leben füllt. Dies bildet das entfernte Objekt. Die Klasse muss zusätzlich einen speziellen Konstruktor besitzen. |
| 3. |
Existiert die Implementierung, benötigen wir ein Exemplar dieses Objekts. Wir melden es bei einem Namensdienst an, damit andere es finden können. Dies bildet den Server. |
| 4. |
Im letzten Schritt demonstrieren wir die entfernte Methode an einem Beispiel. |
18.3.2 Entfernte und lokale Objekte im Vergleich
Vergleichen wir entfernte Objekte und ihre Methode, so fallen Gemeinsamkeiten ins Auge. Die Referenzen auf entfernte Objekte lassen sich wie gewohnt übertragen. Sie können als Parameter oder als Rückgabewert angegeben werden. Dabei ist es egal, ob die Methode mit den Parametern oder Rückgabewerten lokal oder entfernt ist. Die Unterschiede zu lokalen Objekten sind aber deutlicher. Da ein Client immer über eine entfernte Schnittstelle das Objekt repräsentiert, hat es nichts mit der tatsächlichen Implementierung zu tun, und daher ist auch eine Typumwandlung unmöglich. Die einzige Umwandlung von einer entfernten Schnittstelle ist in Remote und in noch eventuellen Obertypen von Remote. Damit ist auch deutlich, dass instanceof auch nur testen kann, ob das Objekt entfernt ist oder nicht; die echte Vererbung auf der Server-Seite bleibt verborgen.
18.3.3 RMI und CORBA
Neben der reinen Java-Lösung RMI gibt es auf dem weiten Feld der Standards noch das komplexe CORBA. Im Gegensatz zu RMI definiert CORBA ein großes Framework für unterschiedliche Programmiersprachen. Die Definition von CORBA geht in das Jahr 1991 zurück, also vor RMI. Die OMG (Object Management Group) hat bei der reinen Java-Implementierung Sun vorgeworfen, einen zweiten Standard zu schaffen. Die Frage nach dem Sinn von RMI ist also erlaubt. Die Antwort liegt jedoch in der Einfachheit und Integration von RMI. In den letzen Jahren hat Sun jedoch RMI an den De-facto-Standard CORBA angepasst. Die Stellvertreterobjekte sprechen mittlerweile nicht nur das eigene Protokoll, sondern können sich auch mit dem Inter-ORB Protocol (IIOP) von CORBA unterhalten. Diese Lösung heißt RMI/IIOP (»RMI über IIOP«). Damit lässt sich auch über RMI eine Verbindung zwischen Java-Programmen und Nicht-Java-Programmen herstellen. Wollten wir auf IIOP verzichten, müsste die Übermittlung mit CORBA oder einem eigenen Protokoll erfolgen. Dann können wir aber nicht von der einfachen Nutzung profitieren und müssen uns mit Fragen wie Bit-Anzahl der Datentypen oder Byte-Ordnungen (Big-Endian/Litte-Endian) herumschlagen.
|
