From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100299.html | 267 +++++++++++++++++++++ 1 file changed, 267 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100299.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100299.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100299.html b/Master/Reference Architectures and Patterns/hjp5/html/k100299.html new file mode 100644 index 0000000..f5ff4e4 --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100299.html @@ -0,0 +1,267 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 47 - Remote Method Invocation +
+
+ + + + +

47.1 Einleitung

+
+ +
+ + + + +

47.1.1 Prinzipielle Arbeitsweise

+ +

+Im vorigen Kapitel wurde die Netzwerkprogrammierung mit Hilfe von +Sockets und URL-Objekten erläutert. Dabei wurden im wesentlichen +Dienste verwendet, deren Aufgabe es war, Daten zwischen zwei +Netzwerkknoten zu übertragen. Höhere Anwendungen, wie etwa +das Kopieren von Dateien, die Manipulation von Verzeichnissen oder +das Starten von Programmen auf dem Server, wurden mit zusätzlichen +Anwendungsprotokollen wie FTP oder HTTP realisiert. + +

+Neben der reinen Übertragung von Daten besteht eine weitere wichtige +Anwendung von Netzwerkstrukturen darin, Programmcode zu verteilen +und von unterschiedlichen Arbeitsplätzen im Netz aufzurufen. +Auf diese Weise können spezielle Aufgaben einer Applikation (wie +etwa der Datenbankzugriff oder die Kommunikation mit externen Systemen) +an geeignete Server delegiert und so die Applikationslast gleichmäßiger +verteilt und die Skalierbarkeit des Systems erhöht werden. + +

+Mit RMI (Remote Method Invocation) stellt das JDK seit der +Version 1.1 einen Mechanismus zur Verfügung, der es ermöglicht, +Objekte auf einfache Weise im Netz zu verteilen und ihre Dienste anderen +Arbeitsplätzen zur Verfügung zu stellen. Die prinzipielle +Arbeitsweise von RMI läßt sich wie folgt skizzieren (siehe +Abbildung 47.1): +

+

+ + +

+ +

+Abbildung 47.1: Prinzipielle Arbeitsweise von RMI

+ +

+RMI etabliert also eine Client-Server-Architektur zwischen lokalen +Java-Objekten und den von ihnen aufgerufenen Remote-Objekten. Die +eigentliche Kommunikation zwischen den Teilnehmern ist fast vollständig +unsichtbar. + +

+Die Rollen von Client und Server sind dabei keineswegs statisch festgelegt. +So kann ein Client durchaus Server-Funktionalitäten implementieren +oder ein Server kann zur Ausführung eines Client-Calls die Hilfe +eines anderen Remote-Objekts in Anspruch nehmen. Eine interessante +Eigenschaft von RMI besteht auch darin, fehlenden Code dynamisch nachzuladen. +Benötigt beispielsweise ein Server zur Ausführung eines +Auftrags eine bis dato unbekannte Klasse vom Client (die natürlich +ein ihm zur Compilezeit bekanntes Interface implementiert), so kann +er diese dynamisch vom Client laden und - dank der Plattformunabhängigkeit +von Java - auf dem Server ausführen. + + + + +

47.1.2 Einzelheiten der Kommunikation

+ +

+Bei der Kommunikation mit RMI hat der Client den Eindruck, Methoden +von Objekten aufzurufen, die auf dem Server liegen. In Wirklichkeit +liegen die Dinge natürlich etwas komplizierter, denn der Client +hat von der RMI-Registry lediglich ein Stub-Objekt +erhalten, und das Remote-Objekt hat den Server nicht wirklich verlassen. +Ein Stub ist eine Klasse, die - wie das implementierende Remote-Objekt +- das Remote-Interface implementiert und daher für den Client +als Platzhalter für den Zugriff auf das Remote-Objekt dient. + +

+Der Stub kommuniziert über eine TCP-Verbindung mit dem als Skeleton +bezeichneten Gegenstück auf der Server-Seite. Das Skeleton kennt +das tatsächliche Applikationsobjekt, leitet die Anfragen des +Stubs an dieses weiter und gibt den Rückgabewert an ihn zurück. +Stub und Skeleton werden während der Entwicklung mit Hilfe eines +Tools generiert und verbergen die komplizierten Details der Kommunikation +zwischen Server und Client. +

+ + +

+ +

+Abbildung 47.2: Stubs und Skeletons

+

+ + + + + + + + + +
+ +

+RMI verfolgt mit der Verteilung von Objekten im Netz einen ähnlichen +Ansatz wie CORBA (die Common Object +Request Broker Architecture, siehe beispielsweise http://www.omg.org). +Da auch CORBA von Java sehr gut unterstützt wird, muss man sich +als Entwickler natürlich die Frage stellen, welche der beiden +Architekturen in einem entsprechenden Projekt die bessere Wahl ist. +Für CORBA spricht die Vielzahl der verfügbaren Implementierungen, +die größere Verbreitung und die Tatsache, dass neben Java +auch andere Programmiersprachen unterstützt werden (etwa C++). +Es ist daher ideal für heterogene Projekte, deren Größe +eine gewisse kritische Masse überschreiten. + +

+RMI ist dagegen einfacher zu erlernen, bietet dynamischen Code-Austausch, +erfordert keine zusätzlichen Lizenzen und kommt mit insgesamt +weniger Aufwand aus. Für reine Java-Projekte könnte es sich +daher als geeignete Wahl erweisen. Seit der Version 1.3 unterstützt +das JDK die RMI-Kommunikation auch auf der Basis des CORBA-Protokolls +IIOP und erleichtert so die Integration +von RMI- und CORBA-Anwendungen.

 + + + + +
 Hinweis 
+
+ +

+Bei der Kommunikation zwischen Client und Server (wenn also der Client +eine Methode auf einem Remote-Objekt aufruft) sind drei Arten von +Datentypen zu unterscheiden: +

+

+ + + + + + + + + + + +
+ +

+Objekte, die weder Remote-Referenzen noch serialisierbar sind, können +per RMI nicht ausgetauscht werden. Beispiele dafür sind die Klassen +Thread, +System +oder RandomAccessFile. +Derartige Objekte haben allerdings auch meist nur lokale Bedeutung, +und die Übertragung an eine andere virtuelle Maschine macht wenig +Sinn.

 + + + + +
 Warnung 
+
+

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3