Übersicht über die RMI-Architektur

In einer verteilten Anwendungsarchitektur ist immer eine Kommunikation zwischen zwei verschiedenen Anwendungen erforderlich. In Java-basierten Anwendungen kommuniziert eine Anwendung mit einer anderen Remote- / anderen Anwendung, die an einem anderen Ort ausgeführt wird, mithilfe eines Mechanismus, der als RMI-Architektur bezeichnet wird.

RMI steht für Remote Method Invocation. Es ist eine von Java bereitgestellte API, die es einem Objekt in einer JVM (Java Virtual Machine) ermöglicht, auf ein Objekt zuzugreifen oder es aufzurufen, das in einer anderen JVM ausgeführt wird. Die andere JVM kann sich auf demselben Computer oder auf demselben Remote-Computer befinden. Dies ist eine interessante Funktion, da es in Echtzeitanwendungen für Java-Anwendungen sehr einfach ist, ohne externe Kommunikationsmechanismen direkt miteinander zu kommunizieren. Darüber hinaus ist eine sichere Kommunikation zwischen Anwendungen auf der Grundlage einer verteilten Anwendungsarchitektur immer erforderlich.

RMI-Design

Bevor wir uns mit der detaillierten Architektur befassen, werden wir das grundlegende Design der RMI-Architektur verstehen.

  • Die RMI-API ist im Paket java.rmi enthalten. Lassen Sie uns zwei Begriffe für das Verständnis der RMI-Entwurfsarchitektur einführen. Erstens ist der Kunde; Die JVM, die das entfernte Objekt und den zweiten aufruft, ist der Server. Die JVM, die das ferne Objekt enthält. Der Client ruft also den Server auf, in diesem Fall für das Objekt zum Methodenaufruf.
  • Der Server gibt dann die Referenz des Objekts an den Client zurück. Der Haken dabei sind beide Objekte, dh lokal und remote werden als lokales Objekt auf dem Server angezeigt. Es wird keine Unterscheidung zwischen den beiden geben. Die Syntax der Methoden beider Objekte ist ebenfalls gleich. Daher verhält sich die Server-JVM wie eine normale JVM, ohne zu wissen, ob es sich um ein lokales oder ein fernes Objekt handelt.
  • Das gleiche Objekt kann sowohl ein Server als auch ein Client sein. Die Referenz für ferne Objekte wird abgerufen und verwendet, als wäre es ein lokales Objekt. Die RMI-Infrastruktur ist dafür verantwortlich, das Remote-Objekt zu finden, den Methodenaufruf abzufangen und die Remote-Anforderung remote zu verarbeiten. Der Client ruft Methoden für das Objekt erst auf, nachdem er einen Verweis auf ein entferntes Objekt erhalten hat.

RMI-Architektur

Unten sehen Sie das Diagramm der RMI-Architektur auf einfache Weise. Im Internet finden Sie verschiedene Formen der gleichen Architektur, aber wir haben eine einfache, um dies besser zu erklären.

Beginnen wir mit dem Verbinden von Punkten aus Entwurfsperspektive mit einem Architekturdiagramm.

Die Clientanwendung und die Serveranwendung sind die jeweiligen JVMs des Clientcomputers und des Servercomputers. In der RMI-Anwendung schreiben wir jeweils zwei Programme. das Client-Programm, das sich auf dem Client befindet, und das Server-Programm, das sich auf dem Server befindet.

Anwendungsschicht:

Diese Schicht ist das eigentliche System, dh Client und Server, die an der Kommunikation beteiligt sind. Das Java-Programm auf der Clientseite kommuniziert mit dem Java-Programm auf der Serverseite.

Stub:

Von Design Intro haben wir Client-Objekte; In der RMI-Architektur wird es als Stub bezeichnet. Es ist ein Objekt, das sich auf dem Clientcomputer befindet und als Proxy für das entfernte Objekt fungiert. Es ist wie ein Gateway für das Client-Programm.

Der Stub hat die gleichen Methoden wie ein Remote-Objekt. Wenn der Client das Stub-Objekt aufruft, leitet der Stub diese Anforderung über die RMI-Infrastruktur an ein Remote-Objekt (Skeleton) weiter, das dann auf dem Server ausgeführt wird.

Stub Führt die folgenden Ereignisse aus: -

  1. Initiiert die Verbindung mit der fernen JVM.
  2. Schreibt und überträgt (Marshals) Parameter an entfernte JVM,
  3. Wartet auf das Ergebnis,
  4. Liest das zurückgegebene Ergebnis,
  5. Übergeben Sie das empfangene Ergebnis an den Anrufer.

Skelett:

Das Serverobjekt, das sich auf einem Server befindet, wird als Skeleton bezeichnet. Stub kommuniziert mit der Serveranwendung mithilfe eines dazwischen liegenden Skeleton-Objekts.

Die Verantwortung des Gerüstobjekts besteht darin, Parameter an die Methodenimplementierung zu senden und die Rückgabewerte an den Client zurückzusenden.

Skelett Führt die folgenden Ereignisse aus: -

  1. Liest den vom Client übergebenen Parameter,
  2. Ruft die Methode für das aktuelle Remote-Objekt auf.
  3. Übermitteln Sie das Ergebnis an den Anrufer.

Stub / Skeleton-Schicht:

  • Die Stub / Skeleton-Ebene ist dafür verantwortlich, vom Client getätigte Anrufe abzufangen und diese Anrufe an das entfernte Objekt umzuleiten. Diese Schicht wird auch als Proxy-Schicht bezeichnet. Stub und Skeleton sind die Proxys für Client und Server. Die Stub- und Skeleton-Objekte sind wie eine Schnittstelle zwischen einer Anwendung und dem Rest des RMI-Systems.
  • Diese Ebene dient zum Übertragen von Daten auf die Remote-Referenzebene durch Objektserialisierung. Dieser Prozess des Konvertierens von Daten / Objekten in Byte-Streams wird als Marshalling bezeichnet, und der umgekehrte Prozess wird als Unmarshalling bezeichnet. Marshaling wird ausgeführt, wenn das Objekt vom Server angefordert wird, und Unmarshalling wird ausgeführt, wenn Daten- / Objektreferenzen vom Server empfangen werden.

Remote-Referenzschicht:

  • Die Proxy-Schicht ist über die Remote-Referenzschicht mit dem RMI-Mechanismus verbunden. Diese Schicht ist für die Kommunikation und Übertragung von Objekten zwischen Client und Server verantwortlich. Die Aufrufsemantik der RMI-Verbindung wird von dieser Schicht definiert und unterstützt.
  • Remote Reference Layer ist dafür verantwortlich, die Sitzung während des Methodenaufrufs aufrechtzuerhalten. Das heißt, es verwaltet die vom Client auf das Remote-Server-Objekt gemachten Verweise. Diese Ebene ist auch für den Umgang mit duplizierten Objekten verantwortlich.

Transportschicht:

Die Transportschicht ist für den Aufbau der Kommunikation zwischen den beiden Maschinen verantwortlich. Diese Schicht verwendet das Standard-TCP / IP-Protokoll für die Verbindung. Der eigentliche Datentransport erfolgt über diese Schicht. Diese Schicht ist Teil der Remote-Referenzschicht.

Fazit

  • Der Remote Method Invocation (RMI) ist eine sehr nützliche API, die in JAVA bereitgestellt wird und die Kommunikation zwischen zwei verschiedenen JVMs erleichtert. Es ermöglicht einem Objekt, eine Methode für ein Objekt aufzurufen, das sich in einem anderen Adressraum befindet.
  • Es bietet eine sichere Möglichkeit für Anwendungen, miteinander zu kommunizieren. Diese Funktionalität wird durch die Konzepte Stub (Client Calling Object) und Skeleton (Remote Object auf dem Server) erreicht.
  • Mit RMI werden verteilte Anwendungen erstellt. Es bewahrt die Art der Sicherheit. Die RMI-Architektur minimiert die Komplexität der Anwendung in einer verteilten Architektur.

Empfohlene Artikel

Dies war ein Leitfaden für die RMI-Architektur. Hier diskutieren wir das RMI-Design und die Architektur im Detail mit einem entsprechenden Blockdiagramm. Sie können auch unsere anderen Artikelvorschläge durchgehen, um mehr zu erfahren -

  1. Data Warehouse-Architektur
  2. Was ist das TCP-Protokoll?
  3. Was ist Desktop-Software?
  4. CCNA Interview Fragen