Java Remote Method Invocation

Inhaltsverzeichnis

1. Einführung / Motivation

2. RMI Systemarchitektur
2.1 Der Stub/Skeleton Layer
2.2 Der Remote Reference Layer
2.3 Der Transport Layer
2.4 Dynamic Class Loading
2.5 Sicherheitsaspekte
2.6 Verwaltung von live references

3. Verteiltes Objektmodell
3.1 Schnittstellen und Klassen des RMI-Package
3.1.1 Interface Remote
3.1.2 Klasse RemoteObject und Subklassen
3.2 Parameterübergabe
3.3 Lokalisierung entfernter Objekte
3.4 Ausnahmebehandlung

4. Entwicklungsmodell / ~Vorgehen

5. Praxis Szenario

6. Zusammenfassung

7. Literaturverzeichnis

Abbildungverzeichnis

Abbildung 2-1: RMI Systemebenen

Abbildung 2.1-1: Stub und Skeleton Objekte

Abbildung 3.1-1: RMI Interfaces und Klassen

Abbildung 5-1: Anwendungsszenario

1. Einführung / Motivation

Das Java Remote Method Invocation (RMI) ist ein Objektmodell und eine Menge von APIs (Application Programing Interface), zur Realisierung von verteilten Systemen in der rein objektorientierte Sprache JAVA.

Verteilte Systeme im objektorientierten Umfeld erfordern ein verteiltes Ob- jektmodell und einen verteilten Nachrichtenfluß, welcher einem entfernten Methodenaufruf entspricht. Da der Remote Procedure Call (RPC), bekannt aus dem prozeduralen Umfeld, in objektorientierten Sprachen nicht, oder nur ein- geschränkt verwendbar ist, steht mit dem RMI eine Transferierung der RPC- Konzepte zur Verfügung, welche die besonderen Belange der objektorientier- ten Sicht berücksichtigt.

Die neben dem RMI derzeit in Java existierenden Möglichkeiten einer Kom- munikation zwischen Clients und Servern sind die Basiskommunikation über Sockets und die Datenbankschnittstelle JDBC. Beide sind in manchen Situatio- nen sinnvoll und effizient einzusetzen. Jedoch zur Realisierung von objektori- entierten verteilten Systemen sind diese nicht ausreichend. Die Kommunikati- on von verteilten Objekten wird vom Java RMI weitgehend automatisiert und ist damit, neben dem CORBA-Ansatz (Java IDL / IIOP) für sprachübergreifen- de Kommunikation heterogener Systeme, ein vernünftiger Ansatz ein Ser- ver/Client Modell in der Java-Umgebung, d.h. bei miteinander kommunizierenden Objekten in verschiedenen Java Virtual Machines (JVM), zu realisieren. Die miteinander komunizierenden JVM können, müssen aber nicht auf verschiedenen Systemen liegen.

Die beiden wichtigsten Punkte sind die Möglichkeit komplexe Objekte zwi- schen Client und Servern auszutauschen und transparent Nachrichten an ent- fernte Objekte zu senden, bzw. Methoden entfernter Objekte an-/aufzurufen.

Von Vorteil für das RMI ist, daß die Behandlung der entfernten Objekte völlig analog zu den lokalen ist. Damit ist für die Entwicklung eine einheitliche SWPlattform gegeben. Zudem kann durch den Verzicht auf die Kommunikation mit Objektinstanzen anderer Entwicklungsumgebungen, die volle Leistungsfähigkeit des Java Objektmodell für das RMI genutzt werden.

2. RMI Systemarchitektur

Die Systemarchitektur des RMI ist in drei voneinander vollständig unabhängigen, eigenständigen Ebenen aufgeteilt. Der Stub/Skeleton Layer, Remote Reference Layer und der Transport Layer.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: RMI Systemebenen

Die Kommunikation erfolgt im RMI automatisch über fest definierte Protokolle, so daß es auch stets möglich ist eine komplette Ebene auszutauschen. Z.B kann der derzeit auf TCP basierende Transport Layer evtl. durch eine Transportschicht ersetzt werden, die ein anderes Protokoll realisiert.

Die Zuordnung von Client- und Serverfunktion gilt stets nur für eine konkrete Kommunikation zweier Objekte. Somit kann ein Objekt Client bzgl. eines Zugriffs auf ein entferntes Serverobjekt sein und darauf einen Serverdienst für ein anderes Objekt erbringen, welches evtl. auf einem anderen, entfernten Rechner existiert.

2.1 Der Stub/Skeleton Layer

Wenn von einem Objekt im Client eine Methode eines Serverobjekts aufgeru- fen werden soll, bzw. dem Serverobjekt eine Nachricht gesendet werden soll, wird ein lokales Stellvertreterobjekt verwendet, welches als Stub bezeichnet wird. Dieses existiert im Adressraum der JVM die das Clientobjekt ausführt und stellt somit für die restliche Applikation ein reguläres Java-Objekt dar. Die Stub-Methode fast die Parameter des Methodenaufrufs zusammen, was auch "parameter marshalling " genannt wird (siehe hierzu das Kapitel 3.2 /

Parameterübergabe), und zusammen mit der eindeutigen Referenz des Remote- Objekts und der Nummer der aufgerufenen Methode wird ein Datenblock ge- bildet, der über den Remote Reference Layer zum Server gesendet wird.

Auf der Serverseite empfängt das entfernte Stellvertreterobjekt des eigentlichen Remote-Objektes, bezeichnet als Skeleton, über den dortigen Remote Refe- rence Layer den Datenblock und ruft die gewünschte Methode des Serverob- jekts auf. Rückgabewerte, wozu auch ausgelöste Ausnahme- bzw. Fehlerob- jekte (Exceptions) gehören, werden auf dem analogen Weg zum Clientobjekt zurückgesendet. Die folgende Abbildung veranschaulicht den Vorgang:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1-1: Stub und Skeleton Objekte

Da ein generelles Designziel im RMI eine nahtlose Eingliederung des APIs in die reguläre Sprache ist, kann der Entwickler die Remote-Objekte (fast) genau- so verwenden wie originäre Java-Objekte. Damit ist auch klar, daß der oben beschriebene komplexe Kommunikationsweg vollständig transparent und vom RMI automatisiert ist.

2.2 Der Remote Reference Layer

In dieser Schicht wird die Kommunikation mit der Transportschicht geregelt und im wesentlichen das Protokoll bestimmt, nach dem die entfernten Referen- zen zugeordnet werden. Dies ist unabhängig von den Stub- und Skeleton- Objekten.

Jede Implementierung eines entfernten Objekts bestimmt die Art der Referen- zierung. Es sind verschiedene Protokolle in dieser Schicht zu realisieren:

- Einfacher Methodenaufruf bei einer Punkt-zu-Punkt Zuordnung
- Methodenaufruf von replizierten Objekten
- Unterstützung für spezielle Replikationsstrategien
- Strategien zur Wiederverbindung bei einer unterbrochenen Verbindung zum Objekt

Zwei Komponenten bzgl. der Client- und Serverseite kooperieren bei der Methodenausführung. Die Client-Komponente enthält die relevanten Informationen über die Serverimplementierung des Objekts und kann z.B. bei einem replizierten Server-Objekt den Methodenaufruf an alle Replikate weiterleiten. Die Komponente des Remote Reference Layer auf der Serverseite dient der Weiterleitung des Aufrufs an das Skeleton-Objekt.

In dem aktuellen Release des JDK 1.1 ist das Multicasting von Serverobjekten noch nicht enthalten.

Der Remote Reference Layer überträgt die Daten über abstrakte Stream- orientierte Verbindungskanäle. Die darunterliegende Transportschicht implementiert diese transparent.

2.3 Der Transport Layer

In der Transportschicht werden die folgenden Aufgaben wahrgenommen:

- Aufbau, Verwaltung und Überwachung von Verbindungskanälen zu ent- fernten Adressräumen
- Verwaltung einer Refernztabelle von aktuellen entfernten Objekten, die im lokalen Adressraum verwendet werden
- Annahme von Verbindungswünschen anderer und Aufbau der Verbin- dungskanäle

Zur Verwaltung von entfernten Objekten werden vier begriffliche Verallgemeinerungen (Abstraktionen) definiert:

- Ein endpoint ist die Abstraktionen um eine JVM bzw. einen Adressraum zuzuordnen.
- Ein channel ist die begriffliche Verallgemeinerung für eine virtuelle lei- tungsgebundene Verbindung zweier Adressräume. Der Kanal ist für die Verbindung des lokalen und entfernten Adressraumes verantwortlich.
- Eine connection ist die Abstraktion für eine bidirektionale Datenübertra- gung.
- Ein transport ist die Abstraktion für die Verwaltungsinstanz der Kanäle (channels). In jedem transport kann nur ein Kanal für zwei Adressräume real aufgebaut werden. Eine Zuordnung eines endpoints zu einem entfren- ten Adressraum bewirkt einen Verbindungsaufbau (Kanal). Weitere Aufga- ben sind die Annahme von eingehenden Aufrufen, der Einrichtung einer Verbindung und der Weiterleitung zu der höheren Systemebene.

Die konkrete Repräsentierung eines entfernten Objektes, bezeichnet als live reference, besteht aus einem endpoint und einer eindeutigen Identifikation (Schlüssel) des Objektes. Mit einer solchen live reference kann in der Trans- portschicht im Client per endpoint die Verbindung zum entfernten Adressraum aufgebaut, sowie auf der Serverseite das konkrete Objekt per Schlüssel be- stimmt werden.

2.4 Dynamic Class Loading

Ein Client im RPC-Umfeld benötigt kompilierten Code für Stubs, der statisch oder dynamisch (über ein Netzwerk-Filesystem) zum aktuellen Programm gebunden wird, bevor die Routine ausgeführt werden kann.

RMI generalisiert diese Technik dahingehend, daß

- neutraler Bytecode verwendet wird, da dies ein wesentliches Merkmal der Sprache ist. Dies ermöglicht bzw. vereinfacht den heterogenen Mix von Client- und Serverplattformen.
- wahlfreies Laden von Klassen von lokalen oder entfernten Quellen möglich ist, indem ein spezieller RMIClassLoader zur Verfügung gestellt wird. Ne- ben den anderen Möglichkeiten in Java (AppletLoader, Classpath), ist da- mit eine Kontrolle und genaue Steuerung der Klassenherkunft möglich (siehe auch Kapitel 2.5 / Sicherheitsaspekte)
- automatisches Laden von fehlenden Class-Files zur Laufzeit − Von entfernten Objektklassen und Interfaces − Von Stub und Skeletonklassen
− auch von anderen, in der RMI-Anwendung, benötigten Klassen, wie z.B. Parametern von Methoden oder Rückgabeobjekte.

2.5 Sicherheitsaspekte

Im Bereich der Netzanwendungen ist stets die Möglichkeit gegeben, daß Miß- brauch mit den Zugriffsmöglichkeiten betrieben wird. In dem konkreten Fall der verteilten Anwendungen ist eine Steuerung und Kontrolle der entfernten Methodenaufrufe notwendig. Das RMI-System bietet ein Standardsicherheits- system an, den RMISecurityManager. Dieser muß in Applikationen als erstes gestartet werden, um die Kontrolle über die über Netz gehenden Methodenauf- rufe zu erhalten und entscheiden zu können, welche Stub-Klassen von welchen Servern geladen werden dürfen. Auch kann dadurch kontroliert werden, was Stub-Objeket, die ja im Adressraum des Clients ausgeführt werden, dürfen, z.B. Zugriff auf lokale Ressourcen (Festplatte, etc.) und Zugriff auf andere Server.

Werden RemoteObjects über Applets geladen, so übernimmt standardmäßig der AppletSecurity Manager die Kontrolle.

Es ist weiterhin möglich eigene Security-Manager zu implementieren, die speziell applikationsgebundene Sicherheitsbelange unterstützen.

Zudem ist seitens des Designs und der Entwicklung steuerbar, welche (ent- fernte) Objekte über das Netz transportiert werden können. Dies kann nur mit Objekten geschehen, die serialisierbar sind, also das Interface Serializable im- plementieren. Dies kann jedoch für jedes Applikationsobjekt selbständig dekla- riert werden.

2.6 Verwaltung von live references

Die Verwaltung von nicht mehr benötigten Objekten ist in Java automatisiert

(Garbage Collection). Dies gilt dies auch für remote Objekte. Damit ist auch im verteilten Fall der Entwickler nicht mit dieser Verwaltung belastet. Natürlich ist es im Netzzugriff immer möglich, daß eine Refernz auf ein entferntes Objekt nicht aufgelöst werden kann (z.B. Rechnerausfall). Dann wird jedoch eine RemoteExeption ausgelöst (siehe 3.4 / Ausnahmebehandlung).

3. Verteiltes Objektmodell

3.1 Schnittstellen und Klassen des RMI-Package

Die Subtyping/Vererbungshierarchie der wesentlichen Schnittstellen/Klassen im Java RMI ist in folgender Abbildung dargestellt:

Abbildung 3.1-1: RMI Interfaces und Klassen

Abbildung in dieser Leseprobe nicht enthalten

3.1.1 Interface Remote

Die Basis der Applikationstypen bzw. -klassen ist das Interface Remote. Ein Client benötigt zur Benutzung von Serverobjekten, die auf dem Server existieren, eine Beschreibung über die Fähigkeiten eines entfernten Objektes. Dieser Typ definiert die Methoden, die eine konkrete Implementierung und davon abgeleitete Instanzen zur Verfügung stellen. Somit wird die Logik der Applikation über Typen (analog zu abstrakten Datentypen ADTs) definiert. Alle Interfaces für entfernte Objekte müssen daher das Remote Interface direkt oder indirekt erweitern, d.h. von diesem abgeleitet sein.

3.1.2 KlasseRemoteObject und Subklassen

Die Implementierungen der Applikationstypen erfolgt auf Basis der Klasse

RemoteObject, von der die Instanzen die allgemeine Netzfähigkeit für Objekte erben, und die das Pendant für die allgemeine Oberklasse Object in Java für entfernte Objekte ist. Die Klassen der Applikation implementieren die Remote Interfaces, d.h. realisieren die konkreten Typen, mit Methoden und Datenfel- dern.

Die Klasse RemoteServer dient als Superklasse für die einzelnen Referenzie- rungsklassen wie UnicastRemoteObject und „ MulticastRemoteObject “, wobei letztere in dem aktuellen Release des JDK 1.1 noch nicht enthalten ist. Wie im Kapitel 2.2 beschrieben wird, ist eine Zuordnung eines Stub-Objekt zu einer einzelnen Serverimplementierung oder zu Replikaten vom Design des RMI her möglich. Dies wird gesteuert über die Ableitung der Serverobjektimplementierung von der speziellen Subklasse von RemoteServer. Damit vererbt die Klasse RemoteServer die Semantik der entfernten Referenzierung und des Management von Objekten an die abgeleiteten Objektklassen.

Damit wird also eine Applikationsklasse X im Allgemeinen abgeleitet von Uni- castRemoteObject und somit indirekt von RemoteServer und RemoteObject. Auch ist eine Ableitung von einer anderen Implementierung einer Remoteklas- se möglich. Die Klasse X kann ein oder mehrere Remote Interfaces imple- mentieren. Zudem können in X auch Methoden definiert werden, die in keinem Interface deklariert werden. Dies sind Methoden die dann nicht entfernt ver- wendet werden können, aber der lokalen Serverinstanz zur Verfügung stehen.

3.2 Parameterübergabe

Zur Übertragung von Parametern, die einfachen Datentyps oder Objektinstanzen sein können, ist eine Serialisierung des Objekts notwendig. Hierzu ist ein spezieller Mechanismus in Java zur Verfügung, genannt Java Object Serialization. Dieser bietet das Interface Serializable an, das von den Parameterklassen implementiert werden muß. Dies ist bei den Standardklassen des JDK fast stets gegeben, insbesondere bei den Remoteklassen.

Prinzipiell kann jede Art von Objekt übertragen werden, unabhängig von der Tatsache, ob es das Interface Remote implementiert. Eine Übergabe eines Objekts kann in Form eines Parameters beim Aufruf einer Methode oder als Rückgabewert einer remote Methode geschehen.

Zu unterscheiden sind die Übergabe von lokalen Objekten und entfernten Objekten (solche, die das Interface Remote implementieren).

Für lokale Objekte existieren naturgemäß keine Stellvertreterobjekte und keine Registrierung in einem entfernten Server. Somit werden Lokale Objekte bei einer Übertragung kopiert, so daß auf dem entfernten System eine eigenständige Objektkopie verfügbar ist.

Im Fall von entfernten (remote) Objekten existieren naturgemäß die Stellvertreterobjekte (Stub und Skeleton) und die Registrierung(en) in dem/den entfernten Server(n). Damit ist eine Referenzierung dieser Objekte möglich. Wird also ein RemoteObject als Parameter eines Methodenaufrufs angegeben, so wird sein Stevertreter-Objekt, der Stub, übergeben.

Die Besonderheiten des Kopieren von Objekten, wie Verweise auf andere Objekte, die ja in dem entfernten Adressraum nicht existieren, usw., wird von dem Mechanismus Java Object Serialization dem Entwickler gegenüber transparent geregelt (näheres hierzu siehe [ObjSer97]). Damit können also lokale Objekte und entfernte Objekte gleich behandelt werden.

3.3 Lokalisierung entfernter Objekte

Eine Kommunikation zwischen Client und Server erfordert eine Referenz (Stub) des entfernten Objekts. Man erhält diese im Allgemeinen als Rückga- bewert eines Methodenaufrufs für ein entferntes Objekt. Dafür braucht man aber nun wieder den Stub für dieses Serverobjekt. Um dieses „Henne/Ei- Problem“ zu lösen gibt es einen Mechanismus im RMI (bootstrap registry ser- vice), um erstmalig eine Referenz (Stub) auf ein entferntes Objekt zu erhalten. Dabei handelt es sich um einen einfachen Nameserver , der für Serverobjekte Bezeichnungen/Namen verwaltet, über die Clients eine Referenz zu diese Ser- verobjekten erhalten können. Dieser Nameservice läuft als Dämonprozess auf dem Serversystem und wacht an einem Port (Default 1099) auf eine Dienstan- forderung.

Um diesen Nameserver anzusprechen, wird die Uniform Ressource Locator (URL) Syntax, wie z.B. rmi://java.sun.com/rmiserv, verwendet. Der Name wird vergeben durch die Implementierung auf Serverseite. Diese bindet die frei gewählte, aber eindeutige, Bezeichnung an eine Instanz eines RemoteObject. Ein Client erhält über den Namen (lookup) des entfernten Ob- jekts eine Referenz (Stub-Objekt) und kann somit das Serverobjekt anspre- chen.

3.4 Ausnahmebehandlung

Im Bereich von verteilten Anwendungen hat die Ausnahmebehandlung eine besondere Rolle, da die verschiedensten Fehlersituationen entstehen können. Z.B. :

- Fehlerhafte Ausführung von entfernten Methoden (Methodenaufrufe ent- fernter Objekte sind fehleranfällig)
- Ausfall einzelner Server bzw. Server-Verbindung
- Ausfall bzw. Störung der Netzverbindung
- Geringe Performance auf dem Netz und daraus evtl. resultierende Fehler

Damit muß also die Ausnahmebehandlung stets beim Umgang mit entfernten Ressourcen berücksichtigt werden. Das Exception Handling wird in Java über spezielle Objekte und Sprachkonstrukte geregelt. Tritt ein Fehler auf, so wird ein spezielles Objekt, eine Exeption, ausgelöst. Diese Objeket werden im lo- kalen Fall von der Superklasse Exception, und im entfernten (remote) Fall von der Superklasse RemoteException abgeleitet. Damit kann die Fehlerbehandlung in beiden Fällen analog vorgenommen werden, in dem die Exeptions abgefan- gen und von speziellen Programmteilen (Exeption-Handler) verarbeitet wer- den.

Daher ist die Exception Möglichkeit stets zu deklarieren, was in den Klassen- definition über die Angabe der möglichen Exeptionobjekte geschieht (throws).

4. Entwicklungsmodell / ~Vorgehen

Um eine verteilte Applikation zur Verfügung zu stellen müssen nachstehend beschriebene Schritte vorgenommen werden:

a) Design der Applikation auf Basis des Interface Remote
b) Realisierung der Applikation auf Basis von RemoteObject bzw. den Sub- klassen von RemoteServer
c) Kompilierung der Java-Sourcefiles Java Klassendateien
d) Generierung der Stubs/Skeleton-Klassen vollautomatisch aus den Applika- tionsklassen mit Hilfe des rmic Bytecode-Compiler
e) Verteilung der Class-Files (Interfaces und Stub/Skeleton-Klassen) im Netz (Intranet/WWW)

- Im statischen Fall werden die Klassendateien auf bestimmten Rechnern, Server(n) und Client(s), verteilt
- Im dynamischen Fall können über Java-Applets auf Web-Seiten die entsprechenden Klassendateien bei der konkreten Benutzung geladen werden. Hierzu müssen auf in den HTML-Dokumenten entsprechende Informationen aufgenommen werden.

f) Starten des RMI Registry Service (Nameserver) auf dem/den Server(n) g) Starten der Applikation auf dem/den Server(n), in deren Initialisierungsteil auch die Instanzen der Serverobjekte in der Registry eingetragen werden. h) Starten der/des Client(s) und Lesen der ersten Referenzen von entfernten Serverobjekten vom Nameservice.

Die Punkte (a), (b) und (c) sind allgemein bei einer Entwicklung durch zuführen und damit nicht spezifisch für RMI.

Die Punkte (d) und (f) sind vollständig automatisiert und somit mit sehr geringem Aufwand auszuführen. Der rmic Bytecode-Compiler erzeugt automatische aus den angegebenen Java Klassendateien die Stellvertreter-Klassen. Der Nameserver ist mit einem Kommando gestartet.

Ebenso sind die Punkte (g) und (h) nicht besonders RMI spezifisch, da dies allgemein bei Client/Server-Anwendungen der Fall ist. Damit ist nur im Client das Objekt-Lookup (h) und auf Serverseite das registrieren der Objekte beson- ders zu beachten. Bleibt Punkt (e), der naturgemäß im Thema verteilte Anwen- dungen zu beachten ist. Die Möglichkeit der Applets läßt hier eine zentrale Verwaltung zu.

Somit ist zusammenfassend zu bemerken, daß die Realisierung einer verteilten Anwendung mit Hilfe Java RMI nicht besonders schwierig oder aufwendig ist. Die anforderung liegt eher im Analyse und Design der Applikation, was aber genereller Natur ist.

5. Praxis Szenario

Als Beispiel für ein Anwendungsszenario kann folgende Problematik genom- men werden. Ein Client benötigt Informationen und Dienste, die auf einem Applikationsserver verwaltet werden, in Form von Datenobjekten und Such- diensten. Die Daten werden persistent in einer relationalen Datenbank gehal- ten, aus denen die Applikation Instanzen von Anwendungsobjekten bildet. Ap- plikationsserver und Datenbankserver sind im selben Firmennetz. Der Client verbindet sich z.B. per Internet oder Modem mit dem Firmennetz.

Die folgende Abbildung veranschaulicht die Situation:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5-1: Anwendungsszenario

Da einerseits der Zugriff abhängig ist von der Applikationslogik und natürlich auch Suchanfragen schnell bedient werden sollen, ist ein direkter Zugriff des Clients auf die Datenbank nicht sinnvoll. Zudem existiert beim Intra- net/Internet-Zugriff seitens des Client per Applet die Restriktion, daß die Rechnersysteme des DB- und HTTP-Servers identisch sein müssen, aufgrund der Sicherheitssperre des AppletSecurity-Managers.

Eine Lösung ist eine RMI Applikationkomponente (Frontend) auf dem HTTP- Server, der mit dem Rest der Applikation kommuniziert (die evtl. auf noch einem anderen Server liegt). Diese RMI Applikation kann nun mittels der JavaStandardschnittstelle zu relationalen Datenbanken (JDBC) auf den RDBMSServer zugreifen. Da dies innerhalb des Firmennetzes geschieht gibt es einerseits keine Security-Probleme und andererseits wird dies performanter sein als der Zugriff des Clients direkt auf die DB.

Zudem sind damit die einzelnen Ebenen der Applikation (Präsentationskomponente, Applikationslogik, Datenverwaltung bzw. entfernter DB-Zugriff) über standardisierte Schnittstellen gekapselt und somit leichter zu Warten. Die Sicherheitsbelange werden durch die einzelnen Securitymanager seitens Java beachtet. Die Clients bleiben weitgehend auf die Präsentations- und Anfragekomponenten beschränkt und sind damit kostengünstig zu realisieren und auch performant online über das Netz zu laden (Applets).

6. Zusammenfassung

Das Java RMI System bietet die Möglichkeit eng gekoppelte Verteilte Systeme (Server/Client Applikationsstrukturen) innerhalb der Java Umgebung zu reali- sieren.

Im RMI-System ist derzeit noch nicht die Möglichkeit von Serverobjekt- Replikaten gegeben, aber bereits von der Konzeption her vorbereitet und mit dem nächsten Release des JDK ist auch die Realisierung geplant.

Das verteilte Objektmodell und die APIs des Java RMI, fügen sich nahtlos in die Java-Umgebung ein. Das Java-Objektmodell wird durch RMI nur erweitert und das Handling der Remote Objekte ist analog zu lokalen Java-Objekten. Damit ist natürlich die Einführung in einem Java-Umfeld vereinfacht möglich und mit geringeren Einführungskosten behaftet.

Das RMI stellt keine Broker-Architektur wie CORBA zur Verfügung. Dies wird derzeit von der CORBA-Schnittstellensprache Java IDL unterstützt. Im nächsten Release des JDK wird es möglich sein bei der Benutzung des RMI als Transportprotokoll nicht das Java eigene Protokoll (JRMP) sondern das Inetrnet Inter-ORB Protokoll (IIOP) zu verwenden. Damit stehen dann natür- lich nur die beschränkten sprachunabhängigen Möglichkeiten des IIOP zur Verfügung. SUN arbeitet mit der Object Management Group (OMG) derzeit an einer Angleichung der Fähigkeiten von JRMP und IIOP, so daß auch im CORBA Bereich weitgehend die volle Funktionalität des Java RMI zur Verfü- gung steht.

Somit ist zusammenfassend zu bemerken, daß die Realisierung einer verteilten Anwendung mit Java RMI sich im Java-Umfeld anbietet. Aufgrund des beson- ders formulierten Ziels seitens SUN, das RMI möglichst nahtlos in die Sprache Java einzufügen, ist es für Java-Entwickler nicht besonders schwierig oder aufwendig ist eine Verteilte Anwendung zu realisieren. Die Anforderung liegt eher im Analyse und Design der Applikation, was aber genereller Natur ist.

Eine Realisierung von Clientobjekten mit Java und dem RMI für heterogene verteilte Systeme, die über den CORBA-Standard kommunizieren, bietet sich noch nicht an. Damit ist das Java RMI zur Zeit noch nur für einheitlich in Java entwickelten verteilten Systemen einzusetzen.

7. Literaturverzeichnis

[RMISpec97] Java™ Remote Method Invocation Specification, SUN, JDK

1.1, Revision 1.4, February 10, 1997

http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmi TOC.doc.html

[RMITut97] Java™ Remote Method Invocation Tutorial, SUN, JDK 1.1,

Revision 1.3, February 10, 1997

http://java.sun.com/products/jdk/1.1/docs/guide/rmi/getstart.d oc.html

[ObjSer97] Java™ Object Serialisation Specification, SUN, JDK 1.1,

Revision 1.3, February 10, 1997

http://chatsubo.javasoft.com/current/doc/serial-spec/serial- spec.pdf

[Core96] Cornel, G., Hostmann, C.S., „Core Java“2nd Edition, Chapter

15 „Remote Objects“, Prentice-Hall, Inc., New Jersey 1996.

http://www.prenhall.com/~java_sun/corehtml/sample.html