View
214
Download
0
Category
Preview:
Citation preview
VIS2-RPC-1© lbapdbwl vsis inf min uni hh 13_14
Kommunikationsunterstützung:Entfernter Prozedur/Methodenaufruf
VIS2-RPC-2© lbapdbwl vsis inf min uni hh 13_14
Gliederung
• Ziel und grundlegende Funktionsweise des RPC/RMI• Verteiltes Objektmodell • Design• Implementation• Beispiel: Java-RMI
VIS2-RPC-3© lbapdbwl vsis inf min uni hh 13_14
Kooperation: Nachrichtenversand vs. Prozeduraufruf
A) Nachrichtenaustausch:• i.d.R. keine Verteilungstransparenz• Nachrichtenaustausch über explizite 'Ports'• Zugriff von (vielen!) Prozessen auf Ports• Synchronisation durch expliziten Nachrichtenaustausch• Nebenläufigkeit als dominantes Programmierparadigma
B) Entfernter Prozeduraufruf:• Einfache Analogie Inter- / Intraprozessmodell• keine expliziten Kommunikationspfade• Kooperation z.B. durch Sperren, Semaphore oder Monitore • Verteilungstransparenz möglich• Sequentialität als dominantes Programmierparadigma
„On the Duality of Operating System Structures “Lauer / Needham (1979): Dualität beider Modelle !
VIS2-RPC-4© lbapdbwl vsis inf min uni hh 13_14
Entfernter Methodenaufruf „Remote Method Invocation (RMI)“
Client ServerResponse
Call
Modell:
Idee:Aufruf entfernter Methoden wie lokaler Methodenaufruf („Verteilungstransparenz“)Objektorientierte Weiterentwicklung vom RPC (Remote Procedure Call)Abstraktion von:
- Kommunikationsdetails,- Übertragungsfehlern, ...
Aber: z.B.- Transparenz ist nie vollständig möglich
• Parameterübergabe, Performanz, Knotenfehler, Ausnahmebehandlung
Beispiele für RPC/RMI Systeme: - Birrel & Nelson (81), XEROX- Liskov et al. (83): 'Argus', MIT- SUN RPC (85)
- ISO/OSI Remote Operations (89): ROSE, RPC- OSF DCE RPC, …- Java-RMI (97)
VIS2-RPC-5© lbapdbwl vsis inf min uni hh 13_14
RPC/RMI-Aufruf aus Programmierersicht
Client-Prozess
Prozeduraufruf
fährt fort
Server-Prozess
Ausführung derProzedur
Ergebnis-Rückgabe
suspendiert
Rechner A Rechner B
Request
Reply
• Methodenaufruf im entfernten Rechner ähnlich wie im lokalen Fall
• RMI realisiert die Kommunikationsgrundstruktur des Client/Server-Modells
Abstraktion von der Verteilung
-> spiegelt Semantik der Aufrufe zwischen unterschiedlichen Objekten wider-> einfach zu verstehen und zu implementieren
VIS2-RPC-6© lbapdbwl vsis inf min uni hh 13_14
process args.marshallsend
receiveunmarshallexecute req.marshallsendreceive
unmarshallprocess res.marshallsend receive
unmarshallexecute req.marshallsend
receiveunmarshallprocess res.
process args.marshallsend
process args.marshallsend
receiveunmarshallexecute req.marshallsend
receiveunmarshallprocess res.
receiveunmarshallexecute req.marshallsend
receiveunmarshallprocess res.
time
Zeitlicher Ablauf beim (a)synchronen Aufruf des RPC/RMI
synchron asynchron
Client Server Client Server
VIS2-RPC-7© lbapdbwl vsis inf min uni hh 13_14
RPC vs. RMI
• Gemeinsamkeiten— Programmierung mittels Schnittstellen— Basieren auf Request/Reply-Protokoll— Unterstützen verschiedene Fehlersemantiken (at-least-once, at-most-once, …)— Ähnlicher Level gebotener Transparenz
• RMI unterscheidet sich dahingehend, dass … (u.a.)— Objekt-orientierte Programmierung— Erweiterte Parameterübergabe-Semantik durch Objekt-Referenzen
• nicht nur Call-by-Value, sondern auch Call-by-Reference
VIS2-RPC-8© lbapdbwl vsis inf min uni hh 13_14
Verteiltes objektorientiertes Modell
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten Systemen— Referenzen:
• Als Identifizierer für einen Methodenaufruf• Als Ein/Ausgabeparameter einer Methode
• Übertragung dieser Semantik auf den verteilten Fall über Remote-Referenzen
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
VIS2-RPC-9© lbapdbwl vsis inf min uni hh 13_14
Verteiltes objektorientiertes Modell
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten Systemen— Schnittstellen (Interfaces):
• Dienen der Spezifikation von Diensten• Bestehen aus einer Menge an Methodensignaturen (+Attributen)
• Schnittstellen für entfernte Objekte: Remote Interfaces• Verbergen von evtl. vorhandener Heterogenität -> Standards für Interface
Definition Languages
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
// CORBA IDL Beispiel: Person.idlstruct 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();
}; (CDK 05)
VIS2-RPC-10© lbapdbwl vsis inf min uni hh 13_14
Verteiltes objektorientiertes Modell
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten Systemen— Operationen:
• Dienen der Kapselung von Verhalten• Können den Zustand des Empfängers ändern• Können neue Objekte erzeugen• Können weitere Aufrufe an anderen Objekten initiieren
• Aufrufe können über mehrere Prozessräume hinweg erfolgen• Instantiierungen erfolgen im gleichen Prozessraum
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
VIS2-RPC-11© lbapdbwl vsis inf min uni hh 13_14
Verteiltes objektorientiertes Modell
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten Systemen— Garbage Collection (GC):
• Dient der automatischen Speicherbereinigung• Nichtverwendete Objekte werden freigegeben• Beispiel: Mark-and-Sweep Algorithmus
• Freigabe von entfernten Objekten über verteilte GC• Problem der verteilten Adressräume
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
VIS2-RPC-12© lbapdbwl vsis inf min uni hh 13_14
Verteiltes objektorientiertes Modell
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten Systemen— Ausnahmen (Exceptions):
• Dienen der Anzeige von Fehlern• Ändern den aktuellen Programmfluss• Können von der Anwendung über Handler behandelt werden
• Jeder RMI-Aufruf kann fehlschlagen• Entfernte Fehler sollten im Prozess des Aufrufenden auftreten
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
VIS2-RPC-13© lbapdbwl vsis inf min uni hh 13_14
RMI-Design: Fehlersemantiken
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-once
At-least-once
Maybe
• Im lokalen Fall besitzt der Methodenaufruf exactly-once Semantik• Im verteilten Fall gibt es unterschiedliche Semantiken:
— Maybe-Semantik (0-1 Aufrufe): • Ergebnis des Aufrufs: Ergebnis (1 Aufruf) oder Exception (kein Ergebnis)• Kritisch sind Übertragungs- und Servercrashfehler
— At-least-once-Semantik (>=1 Aufrufe) :• Ergebnis des Aufrufs: Ergebnis (>=1 Aufruf) oder Exception (kein Ergebnis)• Übertragungsfehler werden maskiert• Akzeptabel nur für idempotente Operationen
— At-most-once-Sematik (<=1 Aufrufe):• Ergebnis des Aufrufs: Ergebnis (1 Aufruf) oder Exception (kein Ergebnis)• Übertragungsfehler werden maskiert• Kommt dem lokalen exactly-once am nächsten
VIS2-RPC-14© lbapdbwl vsis inf min uni hh 13_14
RMI-Design: Transparenz
• Inwieweit kann und sollte der RMI-Aufruf transparent sein?— Unterscheidung von Transparenz für den Anwender und den Programmierer— RMI ist eine Technologie für den Programmierer— Pro: einfache Benutzbarkeit, höhreres Abstraktionsniveau— Contra: Unwissenheit kann zu Ineffizienzen führen
• Besonderheiten:— Neue Fehlerquellen wie Netz und Server— Um Größenordnungen höhere Latenzen eines Remote-Aufrufs— Unter Umständen Authentisierung notwendig
• Konsens:— Soviel Transparenz wie möglich, z.B. gleiche Syntax — Aber erkennbar machen, dass es sich um Remote-Aufrufe handelt— Ausnahmen explizit machen
VIS2-RPC-15© lbapdbwl vsis inf min uni hh 13_14
RMI-Implementation (1)• Objekt A ruft Methode auf einem Proxy von Objekt B auf• Kommunikationsmodul:
— Ausführung des Request/Reply-Protokolls— Umsetzung der gewählten Aufrufsemantik— Wahl des Dispatchers— Auflösen der Remote Reference
object A object BskeletonRequestproxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
servant
VIS2-RPC-16© lbapdbwl vsis inf min uni hh 13_14
- Nachrichten werden gepackt und vom Empfänger wieder entpackt- Mechanismus muss Client und Server bekannt sein
Nach-richten-format
Nachrichtentyp Request ID Remote Reference Operation ID Argumente(request/reply)
zum Herausfiltern von Duplikaten
"Marshalling" der Nachrichten
• Realisierung der Fehlersemantiken über die IDs• Übertragung von komplexen Objekten als Parameter möglich• Voraussetzung: Serialisierbarkeit• Remote-Referenzen werden geeignet aufgelöst
VIS2-RPC-17© lbapdbwl vsis inf min uni hh 13_14
RMI-Implementation (2)• Remote Reference-Modul:
— Hält Remote-Objekttabelle: lokale Referenzen – systemweite Remote-Referenzen
— Aufgaben: Erzeugung und Auflösen von Remote-Referenzen— Auflösen kann sowohl zu lokalen als auch (neuen) Proxy-Objekten führen
object A object BskeletonRequestproxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
servant
VIS2-RPC-18© lbapdbwl vsis inf min uni hh 13_14
RMI-Implementation (3)• Proxy:
— Stellvertreterobjekt mit gleichem Interface wie Serverobjekt
— Sieht für A wie normales B Objekt aus— Macht den Serveraufruf für A transparent durch
Marshalling/Unmarshalling
• Dispatcher/Skeleton: — Aufrufbearbeitung auf Serverseite— Macht den Aufruf für das B transparent
object A object BskeletonRequestproxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
servant
(Hammerschall 05)
Proxy ObjektClient
Schnittstelle
VIS2-RPC-19© lbapdbwl vsis inf min uni hh 13_14
RMI-Registry
• Server registriert ein Remote Object bei der RMI-Registry • Client verwendet RMI-Registry um Objektreferenz auf das Remote Object
zu erhalten• Client ruft eine Methode aus der Objektreferenz auf• Die Server-JVM führt die Methode auf dem Remote Object aus• Client erhält Ergebnisse des Aufrufs
(Wikipedia 2008)
VIS2-RPC-20© lbapdbwl vsis inf min uni hh 13_14
RMI-Beispiel: Java-RMI
• Java-RMI Architektur stellt alle notwendigen Anteile bereit (Stubs/Skeleton Compiler, Kommunikationsmodule, Registry etc.)
• Bietet viele sinnvolle Erweiterungen wie Security, Callbacks, Activation, Remote Classloading, und DGC
• Ist direkt in das JDK eingebunden• Verwendet die Java-Sprache (Vorteil: Einfachheit, Nachteil: nur Java)
(Hammerschall 05)
VIS2-RPC-21© lbapdbwl vsis inf min uni hh 13_14
Java RMI Sicherheitsmodell
• Ursprüngliche Motivation Java-Applets• Java Plattform nutzt das sog.
„Sandbox-Modell“• Unterscheidung zwischen
Trusted/Untrusted-Code• Untrusted-Code läuft mit beschränkten
Rechten in der Sandbox— Kein Zugriff zum Filesystem— Keine Möglichkeiten zum Aufbau neuer
Internetverbindungen• Als Untrusted-Code gilt:
— Über das Netz bezogener Code (Klassendefinitionen)— Entfernte Aufrufe
• Überwachung der Aktionen einer Anwendung über SecurityManager• Feine ressourcenbasierte Steuerung der Rechte über Policy Files
(JavaWorld 97)
VIS2-RPC-22© lbapdbwl vsis inf min uni hh 13_14
Java-RMI Callbacks
• Der Client benötigt Informationen über Zustandsänderungen vom Remote-Objekt— a) Der Klient fragt in Abständen den Server (busy-wait Polling-Aufrufe)
• Kann die Performance des Servers negativ beeinflussen• Klients können u.U. Anwender nicht rechtzeitig über Änderungen
informieren— b) Der Server teilt dem Klienten Änderungen proaktiv mit (Callbacks)
• Server muss (aktuelle) Liste von interessierten Klienten besitzen• Server muss zur Abarbeitung eine Reihe von synchronen RMI-Aufrufen
durchführen
A B1 Registrierung
2..n-1 Callback
n Deregistrierung
VIS2-RPC-23© lbapdbwl vsis inf min uni hh 13_14
Java-RMI Beispiel DateServer
• Einfacher Dienst zum Nachfragen des aktuellen Datums• Remote Anwendungsinterfaces müssen:
— Das Interface Remote erweitern (zeigt entferten Aufruf an)— In der Methodensignatur eine RemoteException deklarieren
• In der Schnittstelle können alle Java-Typen als Parameter verwendet werden• Neue Klassen können definiert und ebenfalls als Parameter von Methoden
verwendet werden• Parameter müssen das Serializable Interface implementieren oder Remote-
Referenzen sein
import java.rmi.*import java.util.Date
public interface RemoteDate extends Remote{
public Date holeDatum() throws RemoteException;}(Hammerschall 05)
VIS2-RPC-24© lbapdbwl vsis inf min uni hh 13_14
Beispiel DateServer – Der Server
• Abgeleitet von der Klasse UnicastRemoteObject— Vererbung der Fähigkeiten zur entfernten Kommunikation— Unterstützt Kommunikation über TCP
• Binden der Remote-Objekte über die Registrierung Naming— Anmelden von Serverobjekte am Namensdienst, der RMI Registry— Anmeldung über eindeutigen Namen und Referenz— Die Objektreferenz enthält die genaue Adresse des Objekts
• Die main() Methode initialisiert das Serviceobjekt und meldet es am Namensdienst an
public class DateServer extends UnicastRemoteObject implements RemoteDate {public DateServer() throws RemoteException {
super();}public Date holeDatum(){
return new Date();}public static void main(String[] args) {
try{DateServer ds = new DateServer();Naming.rebind("DateServer", ds);System.out.println("Der Server wartet auf Anfragen");
} catch (Exception e) {e.printStackTrace();}}
} (Hammerschall 05)
VIS2-RPC-25© lbapdbwl vsis inf min uni hh 13_14
Beispiel DateServer – Der Client
• Verschafft sich über die statische Methode lookup() der Klasse Naming bei der RMI-Registry die Objektreferenz vom Namensdienst zur Kontaktierung des Serverobjekts
• Die Referenz ist Grundlage für die Generierung eines Proxy Objekts• Über den Proxy können alle Methoden des Serverobjekts angesprochen werden
import java.rmi.*;import java.util.Date;import rmiserver.RemoteDate;
public class DateClient {
public static void main(String[] args) {try {
RemoteDate dateobject = (RemoteDate)Naming.lookup("DateServer");Date datum = dateobject.holeDatum();System.out.println("Das Serverdatum ist: " + datum);
} catch (Exception e) {e.printStackTrace();}}
}
VIS2-RPC-26© lbapdbwl vsis inf min uni hh 13_14
Der RMI-Compiler rmic
• Generierung von Stub und Skeleton über rmic
• Ab Java 1.5 nicht mehr notwendig (DynamicProxies)
Der Aufruf ....rmic DateServer
erzeugt zwei Dateien:DateServer_Stub.classDateServer_Skel.class
Client(Java)
Server(Java)
Client(Bytecode)
Server(Bytecode)
Client-Stub(Bytecode)
Schnittstelle(Java)
javac
Schnittstelle(Bytecode)
rmicServer-Skel.(Bytecode)
Client Server
(Hammerschall 05)
VIS2-RPC-27© lbapdbwl vsis inf min uni hh 13_14
Die RMI-Registry - rmiregistry
• Verwaltet Remote-Objekte/Dienste• Generiert bei Anmeldung eine Remote-Rreferenz• Diese enthält eine genaue Ortbeschreibung zur Lokalisierung des Serviceobjekts:
— IP-Adresse— Port— ObjektID
• Die Objektreferenzen werden unter einem kennzeichnenden Namen an der Registry angemeldet
• Ein Client holen sich über den Namen die Objektreferenz von der Registry und kann damit auf das Serviceobjekt zugreifen
• Die Registry ist ein eigener (Hintergrund)Prozessrmiregistry & (Unix)start rmiregistry (Windows)
VIS2-RPC-28© lbapdbwl vsis inf min uni hh 13_14
Das Vorgehen im Überblick
• Implementation:— Definition der Schnittstelle zwischen Client und Server— Implementierung des Dienstes (Serviceobjekts)— Implementierung des Servers— Implementierung des Clients— Dienst, Client und Schnittstelle mit javac übersetzen— (Optional) Generieren der Stubs mit rmic
• Deployment:— Verteilung der implementierten und generierten Dateien— Starten der RMI-Registry— Starten eines Servers, der den Dienst anmeldet und verwaltet— Starten eines Clients, der den Dienst in Anspruch nimmt
VIS2-RPC-29© lbapdbwl vsis inf min uni hh 13_14
Zusammenfassung
• RMI dient der Erweiterung des objektorientierten Paradigmas auf verteilte Systeme
• Ist als Erweiterung des prozeduralen Konzepts RPC entstanden• Funktionsweise ist dem lokalen Methodenaufruf sehr ähnlich
(mit einigen Unterschieden wie z.B. Fehlersemantiken, Transparenz)• Basiert intern auf dem Versenden von Nachrichten in denen die
Aufrufinformationen enthalten sind (Request/Reply)• Überbrückt als Middleware Heterogenität auf unteren Ebenen• Beispiel Java-RMI: Ergänzt das Basismodell mit diversen Funktionen wie
Security, Activation, DGC, Callbacks, …
Recommended