1 / 109

Verteilte Kommunikation oberhalb der Socket-API

Verteilte Kommunikation oberhalb der Socket-API. Datencodierung, Remote Procedure Calls, Verteilte Objektkommunikation, Namensdienste und Ortstranparenz. Zunächst mal 2 Probleme. Kommunikation basiert auf Nachrichtenaustausch (über Sockets) Ein grundsätzliches Problem mit Sockets ist

skule
Download Presentation

Verteilte Kommunikation oberhalb der Socket-API

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verteilte Kommunikation oberhalb der Socket-API Datencodierung, Remote Procedure Calls, Verteilte Objektkommunikation, Namensdienste und Ortstranparenz Clemens Düpmeier, 18.09.2014

  2. Zunächst mal 2 Probleme • Kommunikation basiert auf Nachrichtenaustausch (über Sockets) • Ein grundsätzliches Problem mit Sockets ist • Wir müssen Encoding / Decoding der Nachrichten definieren, dass jeder Kommunikationspartner versteht • Nachrichten sollen dabei beliebig komplex sein können (i.e. auch komplexe binäre Strukturen) • 2. Problem: • Wir brauchen einfache, aber universell funktionierende Mechanismen an Stelle von selbst-definierten Protokollen (Abstraktion oberhalb der Protokollebene) • Höherwertige Kommunikationsmechanismen stellen Lösungen für diese beiden Probleme bereit Clemens Düpmeier, 18.09.2014

  3. Übertragung komplexer binärer Daten Clemens Düpmeier, 18.09.2014

  4. Externe Datenrepräsentation • Höherwertige Kommunikationsmechanismen nutzen ein gemeinsames Datenformat, genannt externe Datendarstellung zur transparenten Übertragung von beliebigen (binären) Daten. • Notwendig wegen der Heterogenität der Umgebungen • Unterschiedliche Hardwarearchitektur • Verschiedene Betriebssysteme • Verschiedene Programmiersprachen • Unter Marshalling versteht man den Prozess der Transformation strukturierter Datenelemente und elementarer Werte in eine (mit einer Nachricht übertragbaren) externe Datendarstellung • Unter Un-Marshalling versteht man den Prozess der Erstellung elementarer Werte aus ihrer externen Datendarstellung und den Wiederaufbau der ursprünglichen Datenstrukturen. Clemens Düpmeier, 18.09.2014

  5. Sender und Empfänger sind sich über die Reihenfolge und die Typen der Datenelemente in einer Nachricht einig ISO: ASN.1 (Abstract Syntax Notation) Sun ONC (Open Network Computing)-RPC: XDR (eXternal Data Representation) Corba: IDL und CDR (Common Data Representation): CDR bildet IDL-Datentypen in Bytefolgen ab. Vollständige Informationen über Reihenfolge und die Typen der Datenelemente sind in einer Nachricht enthalten Java: Objektserialisierung, d.h. Abflachung eines (oder mehrerer) Objektes zu einem seriellen Format inkl. Informationen über die Klassen.Deserialisierung ist die Wiederherstellung eines Objektes ohne Vorwissen über die Typen der Objekte. Formen von externen Darstellungen Clemens Düpmeier, 18.09.2014

  6. Typ Sequence String Array Struct Enumerated Darstellung Länge gefolgt von Elementen in der angegebenen Reihenfolge Länge gefolgt von Zeichen in der angegebenen Reihenfolge Array-Elemente in der angegebenen Reihenfolge Die Reihenfolge der Deklarationen der Komponenten Unsigned Long Index in Bytefolge 4 Byte Länge der Zeichenkette “Smith” 5 0–3 "Smit" 4–7 "h___" 8–11 12–15 6 Länge der Zeichenkette “London” "Lond" 16–19 "on__" 20-23 1934 unsigned int 24–27 Corba CDR Format Reihenfolge und Typen der Elementebei Sender und Empfänger bekannt! Struct Person{ string name; string place; unsigned int year; }; Smith London 1934

  7. Java Objektserialisierung: vereinfacht public class Person implements Serializable{ private String name; private String place; private int year; public Person(String aName, String aPlace, int aYear) { name = aName; place = aPlace; year = aYear; } // gefolgt von Methoden für den Zugriff auf die Instanzvariablen } Person p = new Person(„Smith“,“London“,1934); Klassenname, Versionsnummer Person 8-Byte Versionsnummer h0 java.lang.String java.lang.String Nummer, Typ und Name der Instanzvariablen int year 3 place: name: 1934 5 Smith 6 London h1 Werte der Instanzvariablen Das echte serialisierte Format enthält zusätzliche Typkennzeichner; h0 und h1 sind Handles, also Verweise auf serialisierte Objekte

  8. Fazit • Zuerst die schlechte Nachricht: das sieht alles ziemlich kompliziert zu implementieren aus, und das ist es auch! • Die gute Nachricht: Solche externen Datendarstellungen sind schon konzipiert und implementiert • und ihre Nutzung ist (insbesondere bei objektorientierten Sprachen) einfach Clemens Düpmeier, 18.09.2014

  9. Elementare Kommunikationsmuster Clemens Düpmeier, 18.09.2014

  10. Blockierende, synchrone Interaktion • über Anfrage-Anwort (Request-Reply) Protokoll • Client schickt Anfrage-Nachricht an Server • Server empfängt Nachricht und führt zugehörige Aktion durch • Server sendet Antwort-Nachricht an Client zurück • Ausführung auf dem Client blockiert nach Schicken der Anfrage-Nachricht so lange, bis Antwort-Nachricht erhalten wurde • Beide, Client und Server, müssen zur Zeit der Interaktion verfügbar sein • Wenn nicht, muss durch wiederholtes Senden von Nachrichten Fehlersituation bereinigt werden • Typischer Weise über Verbindungs-orientierte Sockets implementiert • Punkt-zu-Punkt Verbindung • Kommunikationspartner müssen direkt verbunden sein (Keine Message-Router dazwischen) • Viele mögliche Fehlersituationen Clemens Düpmeier, 18.09.2014

  11. 1) Verlust der Auftragsnachricht 2) Verlust der Ergebnisnachricht 3) Ausfall des Servers 4) Ausfall des Clients 1) 3) 4) 2) Mögliche Fehlersituationen bei Request-Reply Client Server Clemens Düpmeier, 18.09.2014

  12. Liste der Requests Request Request Bearbeitung des Requests Request Bearbeitung des Requests; Request eintragen Reply Request Reply Bearbeitung des Requests Request Liste der Requests über- prüfen; Verwerfen des 2. Requests Reply Request Reply Acknowledge- ment Request löschen Ergebnis kann verschieden sein! at least once Semantik at most once Semantik Client Client Server Server Timeout Timeout Timeout Timeout Timeout Timeout Clemens Düpmeier, 18.09.2014

  13. Fehlersemantiken und Eigenschaften Clemens Düpmeier, 18.09.2014

  14. Weiteres zur Fehlerbehandlung • Um zu verhindern, dass ein Service vorübergehend nicht verfügbar ist, kann • Replizierung des Service (Serverteils) und automatische Lastverteilung und Relokation bei Fehlern eingesetzt werden • Für eine "Exactly Once"-Strategie und kompliziertere Konsistenzerhaltung von Daten benötigt man Transaktionskonzept (siehe später) Clemens Düpmeier, 18.09.2014

  15. Remote Procedure Calls (RPC) Vorläufer der Verteilten Objektkommunikationsmechanismen Clemens Düpmeier, 18.09.2014

  16. Idee für einen entfernten Prozeduraufruf Clemens Düpmeier, 18.09.2014

  17. Remote Procedure Calls (Sun-RPC) • Realisieren entfernten Funktionsaufruf • übernehmen Funktion des Anwenderprotokolls bei Socket-orientierter Kommunikation • At least once Semantik (d.h. entfernter Prozeduraufruf wird mindestens 1-mal ausgeführt) • synchrone Kommunikation • beliebig komplexe Argument(e) und Returnwerte werden als komplexe Datenstrukturen aufgefasst und mit XDR kodiert übertragen bzw. dekodiert. Clemens Düpmeier, 18.09.2014

  18. Synchrone Kommunikation in RPC‘s Client vor Aufruf Client wartet Client nach Aufruf Client RPC Aufruf RPC Return Lokale Funktion aufrufen Server Lokale Prozedur Zeit Clemens Düpmeier, 18.09.2014

  19. Registrierung von RPC Programmen Portmap / rpcbind Client Programm Lookup 111 Registrierung RPC Server RPC Call Server System Client System Clemens Düpmeier, 18.09.2014

  20. Registrierung einer lokalen Prozedur im Laufzeitsystem des Servers unter Angabe von Programmnummer, Version Prozedurnummer Lokaler Funktion Parameterdecodierung Returnwertdecodierung Starten der Laufzeitinfrastruktur des Servers Laufzeitinfrastruktur registriert Programme und Prozeduren im Namensdienst Beispiel für RPC Server (Low Level) #include <stdio.h> #include <rpc/rpc.h> #include <rpcsvc/rusers.h> /* lokale Funktion, die Anzahl Benutzer feststellt */ void *rusers(); main() { if (rpc_reg(RUSERSPROG,RUSERSVERS,RUSERSPROCNUM,rusers, xdr_void, xdr_u_int, /* Welche Argument hat RPC Prozedur, * was wird zurückgegeben */ "visible") == -1) /* Tranportwege = hier alle */ { fprintf(stderr, "Couldn't register myself as RPC program\n"); exit(1); } svc_run(); /* Endlosschleife, * nur return, wenn durch Signal abgebrochen */ fprintf(stderr, "Programm wurde beendet\n"); exit(1); } Clemens Düpmeier, 18.09.2014

  21. Aufruf der Prozedur unter Angabe von Hostname, Programmnr., Version Prozedurnummer Codierer + Parameter Decodierer, Variable für Returnwert Ausgabe des Wertes auf Standardausgabe Beispiel für RPC Client (Low Level) /* einige includes */ main(argc, argv) int argc; char **argv;{ unsigned int nusers; enum clnt_stat cs; if (argc != 2) { fprintf(stderr,"usage: rusers hostname\n"); exit(1); } if (cs= rpc_call(argv[1], RUSERSPROG, /* Programmnummer */ RUSERSVERS, RUSERSPROC_NUM,/* Version, Prozedur */ xdr_void, (char *)0, /* Argumente */ xdr_u_int, (char *)&nusers, /* Returnwert */ "visible") != RPC_SUCCESS) { clnt_perrno(cs); /* Gebe RPC Fehlercode auf Console aus */ exit(1); } fprintf(stdout, "%d users on %s\n", nusers, argv[1]); exit(1); } Clemens Düpmeier, 18.09.2014

  22. Low Level RPC sieht wirklich hässlich aus • Problem: sieht noch nicht wirklich wie lokaler Prozeduraufruf aus • Lösung hierfür ist Stub- und Skeleton Generierung • Führe RPC Sprache ein, mit der RPC Aufrufe bzgl. Parameter (welche XDR Typen gehören dazu, etc.) spezifiziert werden • RPC-Compiler generiert daraus lokale Funktionen • XDR-Kodierungs- und Dekodierungsfunktionen • Stubs für die Clientseite (sehen wie lokale Funktionen aus) • Anwendungsprogrammierer benutzt nur die Stubs • Skeleton für die Serverseite (Skeleton ruft normale Anwenderprozedur auf) • Anwendungsprogrammierer programmiert nur Anwendungsprozeduren • Stubs und Skeleton kommunizieren dann miteinander über die bereits vorgestellte Low Level RPC Schnittstelle • Ähnliches Prinzip sehen wir gleich auch bei RMI und CORBA Clemens Düpmeier, 18.09.2014

  23. /* einige includes */ main(argc, argv) int argc; char **argv;{ unsigned int nusers; if (argc != 2) { fprintf(stderr,"usage: rusers hostname\n"); exit(1); } nusers=rusers(argv[1]); // Aufruf Stub fprintf(stdout, "%d users on %s\n", nusers, argv[1]); exit(1); } Bedeutung von Stubs Aufruf von Stub int rusers(char *hostnname) { if (cs= rpc_call(hostname, RUSERSPROG, /* Programmnummer */ RUSERSVERS, RUSERSPROC_NUM,/* Version, Prozedur */ xdr_void, (char *)0, /* Argumente */ xdr_u_int, (char *)&nusers, /* Returnwert */ "visible") != RPC_SUCCESS) return -1; else return cs; } Stub-oder Proxy Clemens Düpmeier, 18.09.2014

  24. Wo wird RPC eingesetzt? • RPC Einsatz findet sich an vielen Stellen bei Linux und Windows Betriebssystemen • Beispiele Unix / Linux • NFS - Network File Sytem • YP - YP / NIS Verzeichnisdienst • Mount Daemon für das Mounten von Netzwerklaufwerken • ... • Windows - alles an Diensten, was abhängig vom RPC Dienst ist • COM+ Ereignissystem (COM+ Kommunikation allgemein) • Dateireplikation • Distributed Transaction Dienst • Druckerdienst • ... • RPC Schnittstellen stellen oftmals unbekannte Sicherheitslücken im Netz dar Clemens Düpmeier, 18.09.2014

  25. Verteilte Objektkommunikation Clemens Düpmeier, 18.09.2014

  26. lokaler Aufruf lokaler Aufruf entfernter Aufruf entfernter Aufruf lokaler Aufruf Entfernte und lokale Methodenaufrufe • Jeder Prozess hat Objekte, einige, die entfernte Aufrufe erhalten können - entfernte Objekte genannt -, einige, die nur lokale Aufrufe erhalten können • Objekte müssen die entfernte Objektreferenz eines Objektes in einem anderen Prozess kennen, um dessen Methoden aufrufen zu können. Wo bekommen sie diese Referenz her ? • Die entfernte Schnittstelle spezifiziert, welche Methoden entfernt aufgerufen werden können Clemens Düpmeier, 18.09.2014

  27. Eigenschaften Verteilter Objekte • Interagierende Objekte sind auf mehr als einen Prozess verteilt • Wichtige Begriffe (Auswahl, vereinfacht): • Entfernte Objektreferenz: die „Adresse“/eindeutige Identität eines Objekts im ganzen verteilten System • Entfernte Schnittstellen: die Schnittstelle eines entfernten Objekts (interface definition language, IDL) • Ereignisse/Aktionen: Ereignisse/Aktionen von Objekten können Prozessgrenzen überschreiten • Exceptions/Ausnahmen: verteilte Ausführung des Systems erweitert das Spektrum möglicher Fehler • Garbage Collection: Freigabe nicht mehr benutzten Speichers wird im verteilten System schwieriger Clemens Düpmeier, 18.09.2014

  28. 32 bits 32 bits 32 bits 32 bits Schnittstelle des entfernten Objektes Internetadresse Port-Nummer Zeit Objektnummer • Über Raum und Zeit garantiert eindeutig! • Bestehen aus • Internetadresse: gibt den Rechner an • Port-Nummer und Zeit: Identifizieren eindeutig den Prozess • Objektnummer: Identifiziert das Objekt • Schnittstelle: beschreibt die entfernte Schnittstelle des Objekts • Werden erzeugt von einem speziellen Modul - dem entfernten Referenzmodul - wenn eine lokale Referenz als Argument an einen anderen Prozess übergeben wird und in dem korrespondierenden Proxy gespeichert. Achtung: Diese Art der Referenz erlaubt kein Verschieben des Objektes in einen anderen Prozess zur Laufzeit! Entfernte Objektreferenzen

  29. Entfernte Schnittstellen • Die entfernte Schnittstelle gibt an, wie auf entfernte Objekte zugegriffen wird (Signatur der Methodenmenge). • Ihre Beschreibung enthält • Den Namen der Schnittstelle • Möglicherweise Datentypdefinitionen • Die Signatur aller entfernt verfügbaren Methoden, bestehend aus • Dem Methodennamen • Ihrer Ein- und Ausgabeparameter • Ihrem Rückgabewert • Jede Verteilte Objektkommunikationstechnologie besitzt eine eigene Sprache, um solche Schnittstellen zu beschreiben. Clemens Düpmeier, 18.09.2014

  30. struct Person { string name; string place; long year; } ; interface PersonList { readonly attribute string listname; void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); }; CORBA hat Strukturen, Java hat Klassen entfernte Schnittstelle Signatur: Definition der Methoden Parameter sind in, out oder inout Daten Implementierung der Methoden entfernte Schnittstelle lokaler Aufruf m1 m2 m3 m4 m5 m6 entfernter Aufruf Enternte Schnittstelle: Beispiel CORBA IDL

  31. <<interface>> Subject RealSubject Proxy +request() +request() +request() Proxy Design Pattern realSubject Clemens Düpmeier, 18.09.2014

  32. Bedeutung von Schnittstellen Client Server Implementierungim Server Gewünschte Schnittstelle im Client Proxy Object (Stub) Skeleton Kommunikationsschnittstelle Netzwerk Clemens Düpmeier, 18.09.2014

  33. Teile einer Implementierung • Kommunikationsschnittstelle: zuständig für das Request-/Reply (Anfrage-Antwort) Protokoll • Entferntes Referenzmodul: Übersetzt zwischen entfernten und lokalen Objektreferenzen; besitzt meist eine entfernte Objekt-Tabelle, in der diese Zuordnung eingetragen wird. Beim ersten Aufruf wird die entfernte Objektreferenz von diesem Modul erzeugt. • Proxies und Skeletons • Proxies (auch Stubs) genannt stellen Client Schnittstelle zur Verfügung • Skeletons rufen serverseitige Objektimplementierung auf Clemens Düpmeier, 18.09.2014

  34. Server Request Reply Client Kommunikations- schnittstelle Kommunikations- schnittstelle Objekt A Objekt B Proxy B Dispatcher B Skeleton B Entferntes Referenzmodul Entferntes Referenzmodul Rolle von Proxy und Skeleton Proxy: schafft Transparenz für Client. Proxy implementiert entfernte Schnittstelle. Marshals Request und unmarshals Reply. Leitet Request weiter. Ausführung des Request/Reply Protokolls Dispatcher: wählt Methode im Skeleton aus. Skeleton: implementiert Methoden der entfernten Schnittstelle. Unmarshals Request und Marshals Reply. Ruft Methode in entferntem Objekt auf. Übersetzung zwischen lokalen und entfernten Objektreferenzen

  35. Parameterübergabe: Referenz- und Kopiersemantik • Entfernte Methodenaufrufe sollten Parameterübergabe-Semantik der verwendeten Programmiersprache respektieren: • In Java Übergabe von Werten per Kopie, Übergabe von Objekten per Referenz • In C++ freie Wahl der Übergabeart • Probleme: • Entfernte Referenzen auf Werte prinzipiell nicht möglich • Entfernte Referenzen auf Objekte nur möglich, wenn entsprechende Stubs und Skeletons existieren • Empfänger benötigt Implementierungsklasse für erhaltenes Objekt (Kopiersemantik) bzw. Stub (Referenzsemantik) Clemens Düpmeier, 18.09.2014

  36. ASkeleton AServant B Beispiel für Parameterübergabe Betrachte folgende Objektklasse: import B; public interface A extends Remote{ public void setB(B b) throws Throwable; public B getB() throws Throwable;}} public class AServant extends UnicastRemoteObjectimplements A{ private B b; public void setB(B b) { this.b = b; } public B getB() { return this.b; }}

  37. Adressraum 1 Adressraum 2 "getB" Klienten-objekt AStub ASkeleton AServant B Parameterübergabe: Kopiersemantik (1) 1. Clientobjekt hältReferenz auf Instanzvon A, ruft daraufMethode getB() auf. 2. Stub übermitteltMethodenaufruf anSkeleton 3. Skeleton delegiertMethodenaufruf anServant 4. Servant übergibtReferenz auf Instanzvon B an Skeleton Clemens Düpmeier, 18.09.2014

  38. Adressraum 1 Adressraum 2 codierter Zustandvon B Klienten-objekt AStub ASkeleton AServant B B Parameterübergabe: Kopiersemantik (2) 8. Stub übergibtVerweis auf neueInstanz an Aufrufer 7. Stub lädt Klasse B,dekodiert Zustandund erzeugt damitneue Instanz von B 6. Kodierter Zustandwird an Stubübertragen 5. Skeleton kodiertZustand von Instanzgemäß Wire Protocol B.jar Clemens Düpmeier, 18.09.2014

  39. Adressraum 1 Adressraum 2 "getB" Klienten-objekt AStub ASkeleton AServant B Parameterübergabe: Referenzsemantik (1) 1. Clientobjekt hältReferenz auf Instanzvon A, ruft daraufMethode getB() auf. 2. Stub übermitteltMethodenaufruf anSkeleton 3. Skeleton delegiertMethodenaufruf anServant 4. Servant übergibtReferenz auf Instanzvon B an Skeleton Clemens Düpmeier, 18.09.2014

  40. Adressraum 1 Adressraum 2 (hostname, port) Klienten-objekt AStub ASkeleton AServant BStub B BSkeleton Parameterübergabe: Referenzsemantik (2) 8. A-Stub übergibtVerweis auf B-Stuban Aufrufer 7. A-Stub erzeugtneuen B-Stub, derNetzwerkadresse vonB-Skeleton enthält 6. A-Skeleton sendetNetzwerkadresse vonB-Skeleton an A-Stub 5. A-Skeleton erzeugtneues Skeleton für B,falls nicht bereitsvorhanden B.jar Clemens Düpmeier, 18.09.2014

  41. Weitere Aspekte der Objektübergabe • Festlegung der Übergabesemantik i.A. durch Typ des formalen Parameters: • Referenzen und keine Referenzen sind zunächst alles Werte! Die Übergabesemantik regelt die Art der Interpretation. • Referenzübergabe, wenn formaler Parameter bestimmtes Interface (in Java RMI z.B. java.rmi.Remote) implementiert • Wertübergabe sonst • Bei Wertübergabe Komplikationen möglich: • Wenn übergebenes Objekt direkt oder indirekt andere Objekte referenziert, müssen diese ebenfalls übergeben werden (mit welcher Übergabesemantik?) • Sharing von Objekten muss auf der Clientseite rekonstruiert werden • Wenn übergebenes Objekt echter Untertyp des formalen Parameters ist, ist u.U. Upcast erforderlich • Was ist mit Garbage Collection von Serverobjekt, wenn Client Referenz darauf hat (siehe nächste Folie)? Clemens Düpmeier, 18.09.2014

  42. Weitere Implementierungsaspekte • Namensdienst, der Clients Objektreferenzen zunächst unabhängig von ihrer Lage vermitteln kann • Parallele Abarbeitung: Um zu verhindern, dass ein entfernter Aufruf einen anderen Aufruf verzögert, weisen Server der Ausführung jeden entfernten Aufrufs einen eigenen Thread zu! • Aktivierung: Automatische Erzeugung einer Instanz und Initialisierung der Instanzvariablen. • Persistenter Objektspeicher: Verwaltet persistente Objekte, also Objekte, die zwischen Aktivierungen weiterbestehen. • Verteiltes garbage collection: Stellt sicher, dass in einem verteilten System garbage collection durchgeführt wird. Problem: Referenzen, die nur in Nachrichten vorhanden sind. Clemens Düpmeier, 18.09.2014

  43. Fallbeispiel(e) Am Beispiel von Java Clemens Düpmeier, 18.09.2014

  44. Beispiel RMI Clemens Düpmeier, 18.09.2014

  45. RMI – Remote Method Invocation • Definiert Verteilte Objektkommunikation von Java-Objekten unabhängig von ihrem Ort • Eine reine Java-Lösung • Callback Funktionalität und dynamisches Laden von Code • Alle entfernten Objekte müssen eine entfernte Schnittstelle definiert als Java Interface abgeleitet von java.rmi.Remote besitzen • Es sind Werkzeuge für die Generierung von Stubs und Skeletons vorhanden. • JDK stellt eine Implementierung eines Naming-Service zur Verfügung: die RMIregistry. • Ein RMI-Dämon erlaubt eine flexible (on-demand)-Instanziierung (Aktivierung) von Objekten. Clemens Düpmeier, 18.09.2014

  46. RMI Architektur Server Client Client Programm Server Programm Gemeinsames Interface Skeleton/Reflection Stubs RMI Komponenten Remote Reference Layer Remote Reference Layer Transport Layer Transport Layer Netzwerk Clemens Düpmeier, 18.09.2014

  47. Remote Reference Layer (RRL) • Stub benutzt RRL-API, um Methodenaufrufe auf die Serverseite zu übertragen • RRL auf Serverseite benutzt Reflection oder Skeleton Objekte, um auf Serverobjekt zuzugreifen • RRL unterstützt unicast Punkt-zu-Punkt Objektverbindungen und aktivierbare Objekte • Andere Formen (Multicast) sind denkbar Clemens Düpmeier, 18.09.2014

  48. Transportlayer • Stellt eigentliche Verbindung zwischen JVM's her • spricht JRMP (Java Remote Method Protocol) als stream-basiertes Protokoll oberhalb von TCP/IP • RMI ab JDK 1.3 spricht zusätzlich das RMI-IIOP Transportprotokoll basierend auf IIOP (Internet Inter-ORB Protocol) • ermöglicht Kommunikation zwischen CORBA und RMI Objekten • enthält Fähigkeiten, RMI Verkehr über andere Verbindungen zu tunneln (z.B. über HTTP) Clemens Düpmeier, 18.09.2014

  49. Beispiel: Interfacebeschreibung eines RMI Objektes (entfernten Objektes) public interface Compute extends Remote { <T> T executeTask(Task<T> t)throws RemoteException;} • Interface von Remote ableiten • Jeder Methode throws java.rmi.RemoteException hinzufügen • Objekte, die so ein "Remote" Interface implementieren, sind entfernte Objekte Clemens Düpmeier, 18.09.2014

  50. Verwendet "normales" Objekt mit Interface Task import java.io.Serializable;public interface Task<T> { T execute();} • Nicht-Remote Objektparameter von entfernten Methoden müssen serialisierbar sein • Implementierungen müssen also sagen:implements Serializable • Ein Task ist für uns ein beliebiges Objekt, dass eine execute() Methode zur Ausführung einer Berechnung besitzt und irgendein Ergebnis zurückgibt • Objekte, die Task implementieren, sind lokale Objekte Clemens Düpmeier, 18.09.2014

More Related