Entfernter Prozedur/Methodenaufruf file© lbapdbwl vsis inf min uni hh 13_14 VIS2-RPC-1 Kommunikationsunterstützung: Entfernter Prozedur/Methodenaufruf

VIS2-RPC-1© lbapdbwl vsis inf min uni hh 13_14

Kommunikationsunterstützung:Entfernter Prozedur/Methodenaufruf


Gliederung

• Ziel und grundlegende Funktionsweise des RPC/RMI• Verteiltes Objektmodell • Design• Implementation• Beispiel: Java-RMI


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 !


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)


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


process args.marshallsend

receiveunmarshallexecute req.marshallsendreceive

unmarshallprocess res.marshallsend receive

unmarshallexecute req.marshallsend

receiveunmarshallprocess res.



receiveunmarshallexecute req.marshallsend


receiveunmarshallexecute req.marshallsend


time

Zeitlicher Ablauf beim (a)synchronen Aufruf des RPC/RMI

synchron asynchron

Client Server Client Server


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


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



• 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


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)



• 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


invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F



• 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


invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F



• 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


invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F


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


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


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


- 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


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


Reply



remoteclient server

servant


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


Reply



remoteclient server

servant

(Hammerschall 05)

Proxy ObjektClient

Schnittstelle


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)


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)


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)


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


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)


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)


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();}}

}


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)


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)


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


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, …

Documents

Entfernter Prozedur/Methodenaufruf file© lbapdbwl vsis inf min uni hh 13_14 VIS2-RPC-1 Kommunikationsunterstützung: Entfernter Prozedur/Methodenaufruf