Docstoc

JAVA_RMI

Document Sample
JAVA_RMI Powered By Docstoc
					                       JAVA RMI

Java Remote Method Invocation ermöglicht das Aufrufen von Java-Methoden auf
                        Objekte die in einem über
               ein Netzwerk verbundenen Rechner residieren.




             Seminar Verteilte Systeme

                            Vom Guangyao Liao
                       gliao@informatik.tu-cottbus.de




                                   -1-
Inhaltsverzeichnis

1. Einleitung ........................................................................................................... - 3 -
          1.1 Was ist RMI ........................................................................................ - 3 -
          1.2 Hintergrund ......................................................................................... - 3 -
          1.3 Was kann RMI .................................................................................... - 3 -

2. Die Eigenschaften von RMI ........................................................................... - 4 -
         2.1 Ähnlichkeit mit RPC ........................................................................... - 4 -
         2.2 Warum nicht RPC ............................................................................... - 4 -
         2.3 Konzipiert für Java .............................................................................. - 4 -
         2.4 OO Prinzip .......................................................................................... - 4 -
         2.5 Passing Behavior ................................................................................. - 5 -
         2.6 Sicherheit ............................................................................................ - 5 -
         2.7 Einfach zu schreiben und zu benutzen ................................................ - 5 -
         2.8 Integrieren von bestehenden Systemen ............................................... - 5 -
         2.9 Einmal schreiben, überall laufen......................................................... - 5 -
         2.10 Verteilte Garbage Collection ............................................................ - 6 -

3. Der Aufbau von RMI ....................................................................................... - 6 -
        3.1 Allgemeine Veranschaulichung .......................................................... - 6 -
        3.2 Abstraktionsprinzip:............................................................................ - 7 -
        3.3 RMI Architektur Schichten ................................................................. - 8 -
        3.4 Stub und Skeleton Schicht .................................................................. - 9 -
        3.5 Remote Reference Schicht ................................................................ - 10 -
        3.6 Transport Schicht .............................................................................. - 10 -
        3.7 Registry ............................................................................................. - 12 -
        3.8 Verteiltes Garbage Collection ........................................................... - 12 -
        3.9 Serialisierung der Remote Objekten ................................................. - 13 -
        3.10 Sicherheitsmechanismen ................................................................. - 14 -
        3.11 Dynamisches Laden von Klassen ................................................... - 15 -

4. Anwendung z.B. im Agent System .............................................................. - 15 -

5. Eine einfache Demo ........................................................................................ - 17 -
         5.1. Definition des Remote Interface ...................................................... - 17 -
         5.2. Implementierung des Interface (Server) .......................................... - 17 -
         5.3. Entwicklung des Clients .................................................................. - 18 -
         5.4. Kompilierung der Remote Interface, Server, Client ........................ - 18 -
         5.5. Stub und Skeleton generieren .......................................................... - 19 -
         5.6. RMI Registry starten ........................................................................ - 19 -
         5.7. Server starten ................................................................................... - 19 -
         5.8. Client starten .................................................................................... - 19 -




                                                            -2-
1. Einleitung



   1.1 Was ist RMI

   Java RMI steht für Java Remote Method Invocation. Das ist eine Technologie
   von Sun, die für die einfache Realisierung von verteilten Objekten in Java
   konzipiert wurde.


   1.2 Hintergrund

   Immer mehr werden Anwendungen eingesetzt, welche auf verschiedenen
   Rechnern gemeinsam eine Aufgabe lösen. Die Anwendungslogik in solchen
   Systemen ist im Rechnerverbund verteilt, und die einzelnen Komponenten
   kooperieren miteinander, um die Aufgabe zu lösen. Java RMI ist eine
   vergleichsweise einfache Technologie, um solche verteilte Anwendungen zu
   realisieren.


   1.3 Was kann RMI

   RMI bietet ein einfaches und direktes Model für verteilte Berechnungen mit
   Java Objekten. Diese Objekte könnten neue Java Objekten, oder könnten auch
   einfache Java Umgebung von existierenden API sein. Also wie auch Java
   immer tut: „Einmal schreiben und überall verwenden“. RMI erweitert das Java
   Model um überall laufen zu können.

   Da RMI ein Bestandteil von Java ist, bringt RMI die Sicherheit und
   Portierbarkeit von Java auch in das verteilte Rechnen mit.

   RMI kann auch mit existierenden Systemen Verbindungen herstellen können,
   welche die standardisierte das Interface JNI benutzt. RMI kann auch auf
   relationalen Datenbankensystemen durch JDBC zugreifen. Die Kombination
   von RMI/JNI und RMI/JDBC bietet uns die Möglichkeit, die bestehende nicht
   Java basierte Servern zu verbinden.




                                  -3-
2. Die Eigenschaften von RMI



   2.1 Ähnlichkeit mit RPC

   Man kann RMI als eine Art von dem RPC (Remote Procedure Call) in Java
   betrachten, welches das Kommunikationsinterface des Prozedur-Aufrufs
   abstrahiert. Anstatt der direkten Arbeit mit Sockets, kann der Programmierer
   den Eindruck gewinnen, dass er mit lokalen Prozeduren arbeitet, obwohl in
   Realität die Argumenten für den Aufruf gepackt und zu dem Remote-Ziel
   geschickt werden. RPC Systemen kodieren die Argumente und schicken die
   Resultaten in XDR (eXternal Data Representation) zurück.


   2.2 Warum nicht RPC

   RPC sind aber nicht für die objektorientiert Systemen geeignet. RMI hat
   vielen Vorteile gegenüber RPC, da es ein Teil von Java ist und deswegen
   objektorientiert. Traditionelle RPC Systemen sind programmierspracheneutral,
   und deswegen werden mit RPC oft nur sehr wenig gemeinsamen
   Funktionalitäten realisiert, da es auf allen Zielplattformen unterstützt werden
   muss.


   2.3 Konzipiert für Java

   RMI ist vor allem für Java gedacht und läuft nur im Java VM. Das heißt man
   kann damit ein neutrales, direktes, und voll unterstütztes Verteiltes Rechnen
   System einfach aufbauen. Die benötigten Java-Funktionalitäten können
   nahtlos zu dem System hinzufügt werden.
   RMI ist ein Teil von Java Plattform ab JDK 1.1. Es läuft auf jedem JVM ab
   Version 1.1. Alle RMI Systemen kennen dasselbe Protokoll, so dass alle Java
   Systemen ohne irgendwelchen Overhead mit einander kommunizieren können.



   2.4 OO Prinzip

   RMI kann ganzen Objekten als Argumenten verschicken und als Rückgabe
   empfangen. Nicht nur die vordefinierten Datentypen. Das heißt dass man komplexe
   Daten Typen, zum Beispiel eine Liste, als ein Argument problemlos verschicken
   kann. In existierenden RPC Systemen würde man bei solchen Datentypen erst in ein
   primitives Datentype zerlegen, verschicken, und dann wieder auf dem Server
   rekonstruieren. Mit RMI kann man das direkt über die Leitung schicken und braucht
   kein extra Code auf der Clientseite.




                                     -4-
2.5 Passing Behavior

Wenn man einmal ein Interface definiert hat, kann die Implementierung leicht
verändert werden. Der RMI Client wird beim Aufruf von den entfernten
Methoden automatisch die neueste Klasse herunterladen. Damit ist die
Verwaltung von veränderten Programmen wesentlich einfacher als zum
Beispiel das Verteilen der Kopie des Programms auf allen Clients, was
üblicherweise man bei normalem Programm machen muss.


2.6 Sicherheit

RMI benutzt das integrierte Java Security Mechanismen. Das schützt unser
System bei dem Unterladen von Implementierungen. RMI benutzt das
Security Manager um unseren Systemen und Netzwerken vor den schädlichen
untergeladenen Codes zu schützten. In vielen Fällen kann ein Server das
Unterladen völlig verweigern.


2.7 Einfach zu schreiben und zu benutzen

RMI macht es möglich, das Schreiben von Remote Java Servern und Java
Clients, die solchen Servern zugreifen, zu vereinfachen. Ein Remote Inferface
ist auch gleichzeitig auch ein Java Interface. Ein Server braucht ungefähr nur 3
Zeilen um sich als Server zu deklarieren, und andererseits ist der Server auch
wie alle andere ein Java Objekt. Diese Eigenschaft macht es sehr einfach
Servern für voll skalierbare verteilte Objekte Systemen zu schreiben. Und das
auch schnell als Prototyp und Testversion zu entwickeln. Da RMI Programme
einfach zu schreiben sind, sind sie auch einfach zu warten.


2.8 Integrieren von bestehenden Systemen

Die Interaktion zwischen RMI und existierenden Systemen geschieht durch
Java’s Native Method Interface (JNI). Dadurch kann man das Client in Java
schreiben und den bestehenden Server beibehalten. Wenn man den Server neu
schreiben will, kann man beliebigen Teile des Servers in Java schreiben, und
kann damit alle Vorteile von Java in den neuen Codes haben. Das geht auch
mit bestehenden relationalen Datenbank Systemen, wenn man JDBC benutzt.
Mit JDBC kann man ohne Modifizierung von existierenden Quellecodes, die
nicht in Java geschrieben sind, die bestehenden relationalen Datenbanken
benutzen.


2.9 Einmal schreiben, überall laufen

RMI ist ein Teil von Java. Jedes RMI-basierte System ist 100% portierbar zu
allen JVM. Das gilt auch für ein RMI/JDBC System. Wenn man mit Hilfe von
RMI/JNI mit bestehenden Systemen interagiert, wird der mit JNI geschriebene
Code auf jedem JVM laufen können.


                                  -5-
   2.10 Verteilte Garbage Collection

   RMI verwendet seine verteilten Garbage Collection Funktionen, um die
   Remote Server Objekten, die nicht mehr von irgendeinem Client im Netzwerk
   verwendet werden, zu sammeln. Analog zur Garbage Collection in einer JVM,
   kann man mit verteilter Garbage Collection die Server Objekten als
   unbrauchbar definieren und entfernt wenn sie nicht mehr von Clients
   gebraucht werden.



   2.11 Paralleles Rechnen/Nebenläufigkeit

   RMI ist multi-threadsfähig. Das erlaubt den Servern die Client- Anfragungen
   parallel zu verarbeiten, was die Leistung steigt.




3. Der Aufbau von RMI



   3.1 Allgemeine Veranschaulichung

   Ein RMI System besteht aus 3 wesentlichen Schichten, zwar die
   Programmschicht, Schnittstelleschicht und Remote Reference Layer. Die
   Programmschicht beinhaltet die gewöhnlichen Programme, was die
   eigentlichen Funktionen des Systems realisiert. Mit so genannten Stub und
   Skeleton werden die Objekte aus der Programmschicht in Byte-Stream
   übersetzt bzw. umgekehrt, damit die Objekte für die Übertragung durch
   Internet erst ermöglicht werden kann. Das folgende Bild zeigt den Aufbau
   eines RMI Systems:




                                  -6-
     (Abb. 1, Quelle: Vorlesungsscript Verteilte Systeme vom Pr. Krämer, 2000, BTU)




Das Ziel des Designs für die RMI Architektur war ein verteiltes Java Objekt
Model zu entwickeln, was natürlich in die Programmiersprache Java und
lokalen Objekten integriert werden kann. RMI Architekturen haben die
Vorteile von Java: Sicherheit und Robustheit in der Welt des verteilen
Rechnens.



3.2 Abstraktionsprinzip:

Einer der Vorteile bei der Einführung von RMI ist die Abstraktion, das heißt
man trennt die Definition und die Implementierung. Wodurch das verteilte
System einfach zu konstruieren und die Implementierung leicht verändert
werden kann. Also das Definieren von Vorgaben und deren separaten
Implementierung ist ein wichtiges Prinzip im RMI.

Das erfüllt die Anforderung eines verteilten Systems, wo Clients nur auf der
Definition eines Services konzentrieren kann und der Server nur um die
Bereitstellung des Services kümmern muss.

Speziell in RMI ist die Definition eines Remote Services mit einem Java
Interface beschrieben. Die Implementierung eines Remote Services geschieht
in einer Klasse. Der Schlüssel zum Verstehen von RMI ist einfach zu merken,
dass das Interface die Vorgaben definiert und die Klassen das zu
implementieren haben.

Das folgende Bild zeigt diese Separation:




                                     -7-
   (Abb.2, Quelle: http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html)




Noch zu merken ist: ein Java Interface beinhaltet keinen ausführbaren Codes.
RMI unterstützt zwei Klassen, welche dasselbe Interface implementiert. Die
erste Klasse ist die Implementierung vom Verhalten, und das läuft auf dem
Server. Die zweite Klasse fungiert als einen Proxy für das Remote Service und
es läuft auf dem Client. Das wird in folgender Graphik gezeigt:




   (Abb.3, Quelle: http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html)




Ein Client Programm macht Methodenaufrufen von dem Proxyobjekt, RMI
sendet die Anfragung zu dem Remote JVM, und leitet das zur
Implementierung weiter. Das Antwort von der Implementierung wird zum
Proxy zurückgesendet und dann zu dem Client Programm.

3.3 RMI Architektur Schichten

Wir betrachten jetzt die Implementierung auf niederer Schicht.

Die erste der 3 abstrakten Schichten von RMI Implementierung ist die Stub-
und Skeleton-Schicht, welche der Entwickler direkt begegnet. Die nächste
Schicht ist die Remote Reference Layer. Diese Schicht ist für die
Interpretation und Management der Referenzen, welche von den Clients aus zu
den Remote Service Objekten zeigen, zuständig.


                                      -8-
Die Transport Schicht basiert auf TCP/IP Verbindungen zwischen den
Rechnern in einem Netzwerk. Sie bietet sowohl die Verbindungsbasis, als
auch einige Funktionen zum Beispiel wie das Durchdringen vom Firewall.

Bei einem Schichtenmodel kann man die verschiedenen Schichten einfach
erneuern und austauschen, ohne die Resten der Schichten zu ändern. Z.B. die
Transport Schicht kann durch eine UDP/IP Schicht ersetzt werden.

3.4 Stub und Skeleton Schicht

Die Stub und Skeleton Schichten von RMI liegen direkt vor dem
Entwicklersaugen. In dieser Schicht, RMI benutzt das Proxy Design
Pattern(Entwurfsmuster). In einen Proxy Pattern, ein Objekt in einem Kontext
ist repräsentiert durch ein andere in einem separaten Kontext. Der Kontext
übernimmt die Weiterleitungsfunktion der Methodenaufrufe zwischen
verschiedenen Objekten. Das folgende Klassendiagramm illustriert das Proxy
Pattern:




  (Abb.4, Quelle: http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html)




In der Verwendung von RMI Proxy Pattern, die Stub-Klasse spielt die Rolle
als Proxy, und die Remote Service Implementierung spielt die Rolle als
RealSubject.

Ein Skeleton ist eine Hilfeklasse was für RMI generiert wurde. Der Skeleton
übernimmt die Kommunikation mit dem Stub durch die RMI Link. Der
Skeleton liest den Parameter für den Methodenaufruf von dem Link, leitet den
Aufruf zu dem Remote Service Implementierungsobjekt weiter, akzeptiert den
Returnwert, und dann schreibt den Returnwert zurück zum Stub.

In der Java 2 JDK Implementierung von RMI, das neue Wire-Protokoll macht
dem Skeleton überflüssig. RMI benutzt die Reflektion um mit den Remote
Service Objekten zu verbinden. Man muss nur um die Skeleton Klassen und
Objekten in JDK 1.1 kümmern.




                                     -9-
3.5 Remote Reference Schicht

Die Remote Reference Schicht definiert und unterstützt die Aufrufsemantiken
von der RMI Verbindung. Diese Schicht bietet ein RemoteRef Objekt, was das
Link zu einem Remote Service Implementierungsobjekt darstellt, an.

Die JDK 1.1 Implementierung von RMI bietet nur eine Möglichkeit für
Clients um mit den Remote Serveice Implementierungen verbinden zu können:
ein Unicast, also Punkt-zu-Punkt Verbindung. Bevor ein Client ein Remote
Service benutzen kann, muss das Service auf dem Server instanziert und nach
das RMI System exportiert werden.

Die Java 2 SDK Implementierung von RMI hat noch zusätzliche Semantik für
die Client-Server Verbindung. In dieser Version, RMI unterstützt aktivierbaren
Remote Objekten. Wenn einen Methodenaufruf für das Proxy gemacht wird,
überprüft das RMI ob das aufzurufende Objekt aktiv ist. Wenn das nicht der
fall ist, wird RMI dafür das Objekt instanzieren und aus einer gespeicherten
Datei wiederherstellen. Wenn ein aktivierbares Objekt einmal im Speicher ist,
verhaltet sich das Objekt wie ein normales Objekt in JDK 1.1.



3.6 Transport Schicht

Die Transport Schicht verbindet die JVMs. Alle Verbindungen sind
strömmungbasierte TCP/IP Netzwerkverbindungen

Auch wenn zwei JVMs auf einem gemeinsamen physikalischen Rechner
laufen, kommunizieren sie sich durch TCP/IP. Das folgende Diagramm zeigt
den Ablauf:




   (Abb.5, Quelle: http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html)

Wie man schon weiß, bietet TCP/IP eine persistente, strömmunbasierte
Verbindung zwischen zwei Rechnern per IP Adresse und Portnummer auf
beiden Seiten. Normale Weise wird einen DNS Name statt eine IP Adresse
verwendet. In der aktuellen Version von RMI wird TCP/IP Verbindung als
Fundament für alle Rechner-zu-Rechner Verbindungen benutzt.



                                     - 10 -
Oberhalb von TCP/IP benutzt RMI das so genannte JRMP (Java Remote
Method Protocol). JRMP ist ein proprietäres, strömmunbasiertes Protokoll. Es
sind zwei Versionen von dem. Die erste war mit JDK 1.1 veröffentlicht und
bracht Skeleton-Klasse auf dem Server. Die zweite ist Bestandteil von JDK
1.2 und ist optimiert für Performance und braucht Skeleton nicht.

Sun und IBM haben gemeinsam auf der nächsten Version von RMI gearbeitet,
was RMI-IIOP heißt, welche dann Bestandteil von Java 2 SDK Version 1.3 ist.
Das Interessante an dem RMI-IIOP ist das Ersetzen von JRMP durch OMG
(Object Management Group) Internet Inter-ORB Protocol, IIOP, um die
Kommunikation zwischen Clients und Servern zu ermöglichen.

Die RMI Transport Schicht ist für die Verbindung zwischen Client und Server
gedacht, was manchmal die Hindernisse im Netzwerk umgehen kann.
Während die Transport Schicht die multiple TCP/IP Verbindungen
bevorzugen, erlauben manche Netzwerkkonfiguration nur eine einzige
Verbindung zwischen Server und Client. In solchem Fall wird die Transport
Schicht mehrere virtuellen Verbindungen innerhalb einer TCP/IP Verbindung
durch Multiplexverfahren aufbauen.




                               - 11 -
3.7 Registry

Durch die Präsentation von RMI Architektur, wird man sich die Frage stellen:
„Wie kann ein Client ein RMI Remote Service finden?“. Hier werden Sie die
Antwort zu der Frage finden. Clients können die Remote Services durch ein
Naming- oder Verzeichnisdienst finden. Um das zu ermöglichen, muss dieser
Dienst auf einem bekannten Server mit bekannter Portnummer laufen.

RMI kann viele unterschiedlichen Diensten, einschließlich das Java Naming-
und Verzeichnisdienst Interface (JDNI) verwenden. RMI selbst hat einen
einfachen Dienst, was RMI-Registry, rmiregistry heißt. Das RMI Registry
läuft auf jedem Rechner, welcher die Remote Service Objekten bietet und
Anfragungen nach Diensten akzeptiert, mit der Portnummer 1099 wenn nichts
anderes vorgegeben ist.

Auf einem Hostrechner, ein Server Programm stellt ein Remote Service bei
der ersten Erstellung ein lokales Objekt, welches dieses Service implementiert.
Als nächste wird dieses Objekt zu RMI exportiert. Wenn das Objekt exportiert
ist, stellt RMI einen Dienst dar, welcher auf der Verbindungsanfrage der
Clients wartet. Nach dem Exportieren wird das Objekt in dem RMI Registry
unter einem öffentlichen Name registriert.

Auf der Clientseite, das RMI Registry wird durch die statische Klasse
„Naming“ zugegriffen. Es bietet die Methode lookup() an, womit ein Client
ein Registry anfragen kann. Die Methode lookup() akzeptiert URLs, welche
den Hostname des Servers und den Name des Dienstes spezifizieren. Das URL
hat folgende Form:

rmi://<Host> [:<Port>]/<Servicename>

wobei der Hostname einer Name im LAN oder einer DNS Name im Internet
ist. Das name_service_port wird nur angegeben falls der Naming Dienst auf
einer anderen Portnummer als 1099 läuft.



3.8 Verteiltes Garbage Collection

Das JVM hat einen automatischen Mechanismus was den Hauptspeicher
bereinigt, was so viel bedeutet, dass die Objekten, die nicht mehr von den
anderen Objekten referenziert sind, automatisch von JVM entfernt wird. Das
spart dem Programmierer jede Menge Zeit und vereinfacht das Programmieren
sehr.

Eine der Ziele des RMI Designs ist die nahtlose Integration in die
Programmiersprache Java, welche auch das Garbage Collection beinhaltet.
Alleine das Design eines Garbage Colletion für einen allein stehenden
Rechnern ist schon schwer, um das auch für verteilte Systeme zu machen, ist
sehr schwer.



                                - 12 -
Das RMI System bietet eine Referenz Zähler Algorithmus für das verteilte
Garbage Collection. Sie basiert auf Modula-3’s Netzwerk Objekten. Dieses
System arbeitet damit, dass der Server merkt, welche Objekte auf der
Serverseite die Clients benutzt haben. Wenn eine Referenz erstellt wird, wird
der Server das Objekt als „dirty“ markieren und wenn ein Client die Referenz
wieder los lässt, wird es als „clean“ markiert.

Das Interface zu DGC (Distributed Garbage Collector) versteckt sich in der
Stubs und Skeletons Schicht. Ein Remote Objekt kann das Interface
java.rmi.server.Unreferenced   implementieren    und     bekommt       eine
Benachrichtigung via die Methode unreferenced wenn es kein Client mehr gibt,
was diese Referenz hält.

Zusätzlich zu dem Referenz Zähler Mechanismus, hat eine live Client
Referenz eine Zeitzähler. Wenn ein Client die Verbindung zu dem Remote
Objekt vor dem Auslauf des Zählers nicht erneuert, wird die Referenz als tot
definiert und das Remote Objekt möglicherweise von dem Garbage Collector
entfernt.

Wegen dieser Garbage Collection Semantik, ein Client muss darauf achten,
dass manchmal ein Remote Objekt einfach “verschwindet”.

3.9 Serialisierung der Remote Objekten




(Quelle: http://www.lrz-muenchen.de/services/compute/linux-cluster/cpjava/cpjava-
36.html)


Um Methodenaufrufe über das Netzwerk zu ermöglichen sind zwei Lösungen
vorhanden:

       1. Das entfernte Objekt wird als Remote Reference transportiert (das
       Objekt selbst "verlässt" die JVM nicht, java.rmi.Remote).
       2. Das entfernte Objekt wird als Kopie übertragen (entspricht einem
       "call by value", java.lang.Serializable)




                                   - 13 -
3.10 Sicherheitsmechanismen

Die Programmiersprache Java gehört zu einer der sichersten Sprache
überhaupt. Von Anfang an hat Java die so genannte Applets unterstützt. Die
Applets werden von Klassen vom entfernten Quelle untergeladen, die
möglicherweise auch sicherheitskritisch sein könnten. Das soll auch ähnlich
für RMI funktionieren.

Die bereits in der Sprache bereitgestellten Sicherheitsfunktionen werden auch
für RMI-Applikationen verwendet. In dieser Abschnitte wollen wir die
möglichen Sicherheitmechanismen, die die Risiken durch RMI Anwendungen
verursacht werden sind, nahe angehen.

Die meisten Sicherheitsaspekte in einem verteilten System können in eine der
folgenden Kategorien eingeteilt werden:

       Laufzeit-Integrität. Das dynamische Laden von Klassen ermöglicht das
       Download von Klassendatein aus entfernten Servern. Dazu muss
       sichergestellt werden, dass das Ausführen der heruntergeladenen
       Klassen die Systemintegrität nicht verletzt.

       Verschlüsselung. Beim Aufruf von entfernten Methoden werden
       Parametern und Rückgabewerten über das Netzwerk übertragen. Wenn
       die Daten aus sensiblen Gründen vorm Abhören geschützt werden
       müssen, sind Verschlüsselungen notwendig.

       Authentifizierung. Um unberechtigten Zugriffe auf entfernten Objekten
       zu unterbinden, ist manchmal die Zugriffskontrolle erforderlich.

Die in Java RMI Package enthaltene Klassen RMIClassLoader und
RMISecurityManager sind für das Bewahren der Laufzeit-Integrität
verantwortlich. Wobei RMIClassLoader für das Laden von Stubs, Skeletons
und erweiterte Klassen mit Parametern und Rückgabewerten zuständig ist.
Wenn Klasse B beispielsweise A erweitert und ein Objekt vom Typ B an eine
entfernt gelegene Methode geschickt wird, die so definiert ist, dass sie ein
Objekt vom Typ A erwartet, wird die erweiterte Klasse von A vom
RMIClassLoader geladen. Um bösartige Klasse zu vermeiden, die zum
Beispiel einen Zeiger anlegen und an eine fremde Stack-Position schreiben
und damit möglicherweise das Verhalten einer anderen Methode stören, wird
eine Bytecode-Verifizierung vom RMIClassLoader für die Klasse
durchgeführt. Die Bytecode-Verifizierung untersucht nach Gültigkeit der
heruntergeladen Klassen.

Bevor Sie eine Klasse von einer entfernt gelegenen Quelle laden können,
müssen Sie einen Sicherheitsmanager installieren. Der Sicherheitsmanager
können Sie selber definieren oder den beschränkenden RMISecurityManager()
verwenden. Das wird dann so aussehen: System.setSecurityManager(new
java.rmi.RMISecurityManager());




                                - 14 -
   Das Standardverhalten von RMISecurityManager() ist, die meisten
   privilegierten Dienste nicht zu erlauben, wenn eine der Methoden auf dem
   Ausführungs-Stack zu einer Klasse gehört, die von einer entfernt gelegenen
   Quelle geladen wurde.

   Obwohl RMI keine direkte Verschlüsselung hat, kann man jedoch diese
   Aufgabe durch die Sockets erledigen lassen. Da die Kommunikation von RMI
   durch Sockets geschieht, ist es einfach, die verwendete Sockets zu
   verschlüsseln. Dazu muss noch der Verschlüsselungsalgorithmus
   implementiert werden und eine SocketFactory definieren und setzen, die die
   definierten Cleint- und Server-Sockets zurückgibt. SocketFactory wird in der
   Klasse RMISocketFactory beschrieben.

   3.11 Dynamisches Laden von Klassen

   Durch Internet ist die Verteilung von Software effizienter als vorher
   geworden. Die Möglichkeit, mit Hilfe von RMI Klassen dynamisch zu laden,
   lässt die Software-Verteilung über das Internet noch einfacher, da dadurch das
   automatische        Herunterladen         von        Anwendungen          und
   Anwendungskomponenten zur Laufzeit unterstützt wird. Um das dynamische
   Laden von Klassen mit Hilfe von RMI zu verstehen, können Sie die Klasse
   RMIClassLoader mit ClassLoader für Applets vergleichen.

   Der RMIClassLoader unterstützt zwei Arten des dynamischen Ladens von
   Klassen. Erstens kann der RMIClassLoader verwendet werden, um Stubs,
   Skeletons und die erweiterten Klassen von Parametern herunterzuladen und
   Werte zurückzugeben. Das wird gebraucht, falls ein Client die Klassen für
   den Aufruf einer entfernten Methode braucht, die aber nicht explizit in der
   Client-Anwendung verwendet werden. RMIClassLoader kann noch verwendet
   werden, um beliebige Klassen herunterzuladen, ebenso wie alle Klassen, die
   innerhalb der Klasse verwendet werden.

   Ein Beispiel dafür wäre:

          Class cl = RMIClassLoader.loadClass("myclient");

          Runnable client = (Runnable)cl.newInstance();

          client.run();




4. Anwendung z.B. im Agent System


   Wir haben vorher das dynamische Laden von Klassen schon grob vorgestellt,
   jetzt nutzen wir die umgekehrte Richtung: Objekte und ihre zugehörigen


                                   - 15 -
Klassen werden vom Client zum Server übertragen, um deren Methoden auf
dem Server lokal auszuführen. Man spricht vom Mobile Agent, welche im
Auftrag eines Clients bestimmte Aufgaben auf einem anderen Rechner erledigt
und danach zurückkehrt. Typisches Beispiel wäre die Kontrolle der
Netzknoten oder die Suche nach bestimmten Informationen. Wobei die
Kontrolle der Netzknoten uns nicht fremd ist, nämlich Computer Würmer
ähnlich.

Das können wir uns so vorstellen, ein Server, der beliebige Aufgaben vom
Client entgegennimmt, diese ausführt und die Ergebnisse zurückliefert. Die
Klassen, die die Aufgaben implementieren, müssen in dem Moment seiner
Entwicklung nicht bekannt sein, denn es kann zu beliebigem Zeitpunkt vom
Client heruntergeladen werden. Wichtig ist nur, dass der Server die
Laufumgebung dafür freigibt. Zu jeder Zeit können neue Aufgaben erstellt und
dem Server per RMI zu dem Server geschickt und ausgeführt werden.

Ein typisches Code-Beispiel wird so ein Interface implementieren:

Public interface Beispiel extends java.io.Serializable {

       Void run() throws Exception;

       Objekct getResult();

}

Nach der Übertragung zu dem Server kann der Client die Methode run()
aufrufen und danach mit der Methode getResult() die Ergebnisse
zurückgewinnen. Wenn der Client gleicht zeitig auch als Server für das selbe
Mobile Agent konfiguriert ist, kann sogar die Verbindung nach dem Aufruf
unterbrochen werden, falls das Mobile Agent eine Methode besitzt, die
automatisch wieder das Client sucht und sich dann zurückt per RMI
übertragen lässt.




                                 - 16 -
5. Eine einfache Demo


   Nachdem wir schon so viele über RMI erzählt haben, können wir jetzt selbst
   ein kleines Programm schreiben und testen, um das Wissen auch mal
   umzusetzen können.

   Die Erstellung einer RMI Anwendung läuft wie folgendes beschrieben.

   1)    Definition des Remote Interface
   2)    Implementierung des Interface (Server)
   3)    Entwicklung des Client
   4)    Kompilierung der Remote Interface, Server und Client
   5)    Stub und Skeleton generieren
   6)    RMI Registry starten
   7)    Server starten
   8)    Client starten

   5.1. Definition des Remote Interface

   (Code Quelle: Vorlesungsscript Verteilte Systeme vom Pr. Krämer, 2000,BTU,
   verändert):


   Der Quellcode für Hello.java:

        package examples.hello;
        public interface Hello extends java.rmi.Remote {
                  String sayHello() throws java.rmi.RemoteException;
        }


   5.2. Implementierung des Interface (Server)
     package examples.hello;

        import java.rmi.*;
        import java.rmi.server.UnicastRemoteObject;
        public class HelloImpl
                  implements Hello
                  extends UnicastRemoteObject{
                  private String name;
                  public HelloImpl(String s) throws RemoteException {
                            super();
                            name = s;
                  }


                                     - 17 -
            public String sayHello() throws RemoteException {
                      return "Hello World!";
            }
            public static void main(String args[]) {
                      // Erzeugen und installieren des SecurityManagers
                                System.setSecurityManager(new
                      RMISecurityManager());
                      try {
                                HelloImpl obj = new HelloImpl("HelloServer");
                               Naming.rebind("//192.168.1.1/HelloServer", bj);
                                          System.out.println("HelloServer
                                          bound in registry");
                      } catch (Exception e) {
                                System.out.println("HelloImpl err: " +
                                                   e.getMessage());
                                e.printStackTrace();
                      }
            }
  }

5.3. Entwicklung des Clients

In diesem Beispiel ist es ein Applet:

  package examples.hello;

  import java.awt.*;
  import java.rmi.*;

  public class HelloApplet extends java.applet.Applet {
            String message = "";
            public void init() {
                     try {
                                 Hello obj = (Hello)Naming.lookup("//" +
                                           getCodeBase().getHost() +
                                           "/HelloServer");
                                 message = obj.sayHello();
                     } catch (Exception e) {
                                 System.out.println("HelloApplet exception: " +
                                           e.getMessage());
                                 e.printStackTrace();
                     }
            }
            public void paint(Graphics g) {
                     g.drawString(message, 25, 50);
            }
  }

5.4. Kompilierung der Remote Interface, Server, Client
javac -d c:\rmi\examples *.java


                                 - 18 -
5.5. Stub und Skeleton generieren
rmic –d c:\rmi\examples examples.hello.HelloImpl

5.6. RMI Registry starten
rmiregistry

5.7. Server starten

java examples.hello.HelloImpl

5.8. Client starten
Appletviewer examples\hello\index.html
Das sieht dann so aus:




                                - 19 -
A: Glossar
      CORBA: Common Object Request Broker Architecture
      DNS:       Dynamic Naming Service
      IIOP:      Internet Inter-ORB Protocol
      JDK:       Java Development Kit
      JDBC:      Java Data Base Connectivity
      JNI:       Java Native Interface
      JRMP: Java Remote Method Protocol
      JVM:       Java Virtual Machine
      LAN:       Local Area Network
      RMI:       Remote Method Invocation
      RPC:       Remote Procedure Call
      TCP:       Transmission Control Protocol { Teil der TCP/IP-Suite, welcher
       eine gesicherte Datenübertragung ermöglicht
      URL        Uniform Resource Locator
      XDR        eXternal Data Representation




                                   - 20 -
B: Literatur
        http://developer.java.sun.com/developer/onlineTraining/rmi/index.html
        http://www.javasoft.com
        Einführung in Java (Vorlesungsscript zur verteilten Systemen vom Pr.
         Krämer, 2000, BTU)
        Dietmar Abts: Aufbaukurs Java, Client/Server Programmierung mit
         JDBC, Sockets, XML-RPC und RMI, Vieweg,2003
        William Grosso: Java RMI, O’Reilly,2002
        K. Arnold; J. Gosling;D. Holmes: Die Programmiersprache Java,
         deutsche Übersetzung von RederTranslations, Adison-Wesley, 2001
        Michael Morrison: Java 1.1 für Insider, SAMS, 1997
        http://www.lrz-muenchen.de/services/compute/linux-
         cluster/cpjava/cpjava-47.html




                                 - 21 -

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:53
posted:11/2/2010
language:German
pages:21