Verteilte Objekte

Internet und Intranet
Ein JAVA-Programm kann ein entferntes Objekt aufrufen, sobald es eine Referenz auf das
Objekt, entweder durch Verwendung des RMI „bootstrap“ Naming Service angefordert, oder als
Argument oder Rückgabewert erhalten hat. Dabei kann ein Server, der ein solches Objekt
veröffentlicht, auch selbst Klient sein. RMI verwendet die Methode für „Objekt Serialisierung“
des JDK V1.1, um ein lokales JAVA Objekt in einen seriellen Datenstrom („Marshalling
Stream“) zu wandeln (marshal), innerhalb einer Nachricht über das Remote Reference Layer
(vgl. Abb. 6) an einen Klienten zu übertragen und dort wieder zurück zu wandeln (unmarshal).
Der empfangende Server-Skeleton entpackt den Marshalling Stream und übergibt die Argument
an die aktuelle Implementierung der aufgerufenen Operation [MER97]. Für das eigentliche
Verbindungsmanagement ist das Transport Layer verantwortlich, welches auf JAVA-Sockets
und TCP realisiert ist. Im Unterschied zu JAVA (und C++) übergibt RMI lokale Objekte als
Wert („by-value“), weil eine Referenz auf ein lokales Objekt nur innerhalb einer einzigen VM
sinnvoll ist. Typen werden nicht gekürzt, so daß RMI echten objektorientierten Polymorphismus
unterstützt [ORF97].
Der Namensdienst von RMI ist zur Zeit noch sehr primitiv, nicht persistent und dient lediglich
zum Auffinden von aktiven Objekten (rmi://hostname:port/name). Er stellt weiter einen
Mechanismus zur Verfügung, mit dem ein Klient Stubs vom Server laden kann. Wie auch bei
anderen verteilten Objektmodellen dient im RMI ein Stub [RED96] als lokales Stellvertreterobjekt
(Proxy) für ein entferntes Objekt (vgl. Abb. 6). Dabei bietet RMI einen, gegenüber JAVA,
erweiterten Sicherheitsmechanismus, der das Wohlverhalten der Stubs überwacht. Abschließend
erweitert RMI die Fehlerbehandlung von JAVA mit der java.rmi.RemoteException
Klasse, um auch entfernte Fehler behandeln zu können.
Der Lebenszyklus entfernter Objekte wird durch einen Referenzzähler (sog „Live Reference“
[MER97]) realisiert, der die aktiven Verbindungen zwischen Objekten zählt. Aktive
Verbindungen sind im Fall von JAVA Klient/Server-Verbindungen auf TCP/IP Basis. Sobald der
Referenzzähler eines Objektes auf Null gefallen ist, wird dieses durch die verteilte „Garbage
Collection“ von RMI gelöscht. Dieser Mechanismus ist zwar einfach zu implementieren und
entwickelt zur Laufzeit kaum Overhead, Unterbrechungen aktiver Verbindungen aufgrund von
Ausfällen auf unteren Protokollebenen führen aber leicht zu Inkonsistenzen. Automatisches
Rebinding, das erneute Anbinden an entfernte Objekte nachdem eine Verbindung unterbrochen
wurde, wird von RMI nicht angeboten [ORF97].
Die folgende Abbildung verdeutlicht das RMI-Modell.
Abb. 6: RMI-Modell [MER97].
RMI erlaubt es, entfernte Objekte mit Hilfe von normalen JAVA-Schnittstellen zu erstellen. „Wie
in CORBA oder DCOM sind also Vermittlungsschichten an der Kommunikation beteiligt, die der
„RMI-Compiler“ rmic aus der Schnittstellenbeschreibung automatisch generiert [MER97].“
Dieses Umgehen einer eigenen Schnittstellenbeschreibungssprache führt automatisch dazu, daß
RMI nicht Objekte adressieren kann, die in anderen Sprachen erstellt worden sind. Da RMI auf
der Übertragungsschicht keine Unterstützung für Sicherheit und Transaktionen bietet, muß man
dieses Kommunikationsprotokoll als proprietär und „lightweight“ bezeichnen.
18