In einer verteilten Rechenumgebung ermöglicht die verteilte Objektkommunikation die Kommunikation zwischen verteilten Objekten . Ihre Hauptaufgabe besteht darin, Objekten den Zugriff auf Daten und den Aufruf von Methoden entfernter Objekte (Objekte, die sich nicht im lokalen Speicherbereich befinden) zu ermöglichen. Der Aufruf einer Methode eines entfernten Objekts wird als Remote Method Invocation ( RMI ) oder Remote Invocation bezeichnet und ist das objektorientierte Äquivalent zum Remote Procedure Call (RPC).

Klassenzettel und Skizzen

Der weit verbreitete Ansatz zur Implementierung des Kommunikationskanals besteht in der Verwendung von Stubs und Skeletons . Dabei handelt es sich um generierte Objekte, deren Struktur und Verhalten vom gewählten Kommunikationsprotokoll abhängen , die aber im Allgemeinen zusätzliche Funktionalität bieten und so eine zuverlässige Kommunikation über das Netzwerk gewährleisten.

In RMI wird ein Stub (der entsprechende Teil auf Clientseite) vom Programmierer als Schnittstelle definiert . Der RMI-Compiler rmic verwendet diesen, um den Klassen-Stub zu erstellen. Der Stub führt die Typüberprüfung durch. Das Grundgerüst ist in einer Klasse definiert, die die Schnittstelle „Stub“ implementiert . [ 1 ]

Wenn ein Aufrufer einen Remote-Aufruf an das aufgerufene Objekt durchführen möchte, delegiert er die Anfragen an seinen Stub , der die Kommunikation mit dem Remote- Skeleton initiiert . Der Stub übergibt die Argumente des Aufrufers über das Netzwerk an den Server-Skeleton. Dieser leitet die empfangenen Daten an das aufgerufene Objekt weiter, wartet auf eine Antwort und gibt das Ergebnis an den Client-Stub zurück. Es findet keine direkte Kommunikation zwischen dem Aufrufer und dem aufgerufenen Objekt statt.

Im Detail besteht die Kommunikation aus mehreren Schritten:

  1. Der Aufrufer ruft eine lokale Prozedur auf , die vom Stub implementiert wird.
  2. Stub- Marshalls wandeln den Aufruftyp und die Eingabeargumente in eine Anforderungsnachricht um.
  3. Der Client-Stub sendet die Nachricht über das Netzwerk an den Server und blockiert den aktuellen Ausführungsthread .
  4. Das Server-Skelett empfängt die Anforderungsnachricht aus dem Netzwerk.
  5. Das Skelett extrahiert den Aufruftyp aus der Anforderungsnachricht und sucht die Prozedur im aufgerufenen Objekt.
  6. Argumente der Prozedur zum Unmarshalling des Skeletts
  7. Das Skeleton führt die Prozedur auf dem aufgerufenen Objekt aus.
  8. Das aufgerufene Objekt führt eine Berechnung durch und gibt das Ergebnis zurück.
  9. Skeleton packt die Ausgabeargumente in eine Antwortnachricht.
  10. Skeleton sendet die Nachricht über das Netzwerk zurück an den Client.
  11. Der Client-Stub empfängt die Antwortnachricht vom Netzwerk.
  12. Der Stub entpackt Ausgabeargumente aus der Nachricht.
  13. Der Stub übergibt die Ausgabeargumente an den Aufrufer, gibt den Ausführungsthread frei und der Aufrufer setzt die Ausführung fort.

Der Vorteil dieser Architektur besteht darin, dass weder der Aufrufer noch das aufgerufene Objekt Netzwerklogik implementieren müssen. Diese Funktionalität, die einen zuverlässigen Kommunikationskanal über das Netzwerk gewährleistet, wurde in die Stub- und Skeleton -Schicht ausgelagert.

Stub

Das clientseitige Objekt, das an der verteilten Objektkommunikation teilnimmt, wird als Stub oder Proxy bezeichnet und ist ein Beispiel für ein Proxy-Objekt .

Der Stub fungiert als Schnittstelle zwischen Client-Objekten und allen ausgehenden Anfragen an Server-Objekte. Er kapselt die Funktionalität der Client-Objekte und gewährleistet durch Hinzufügen der Netzwerklogik einen zuverlässigen Kommunikationskanal zwischen Client und Server. Der Stub kann manuell erstellt oder je nach gewähltem Kommunikationsprotokoll automatisch generiert werden.

Der Stub ist verantwortlich für:

Skeleton

Das serverseitige Objekt, das an der verteilten Objektkommunikation teilnimmt, wird als Skelett (oder Stub; dieser Begriff wird hier vermieden) bezeichnet.

Ein Skeleton dient als Schnittstelle für serverseitige Objekte und leitet alle eingehenden Clientanfragen darüber. Er kapselt die Funktionalität der Serverobjekte und stellt sie den Clients zur Verfügung. Durch die Integration der Netzwerklogik gewährleistet er zudem einen zuverlässigen Kommunikationskanal zwischen Clients und Server. Skeletons können manuell erstellt oder je nach gewähltem Kommunikationsprotokoll automatisch generiert werden.

Das Skelett ist verantwortlich für:

  • Übersetzung eingehender Daten vom Stub in die korrekten Upcalls an Serverobjekte
  • Entpacken der Argumente aus den empfangenen Daten
  • Argumente an Serverobjekte übergeben
  • Marshalling der von Serverobjekten zurückgegebenen Werte
  • Werte über das Netzwerk an den Client -Stub zurückgeben

Protokolle mit Stub/Skeleton-Ansatz

Siehe auch

Referenzen