entfernter prozedur/methodenaufruf · typische probleme (1) • heterogenität – hersteller –...
TRANSCRIPT
Entfernter Prozedur/Methodenaufruf
vsis inf min uni hh ws 12_13 VIS-1 RPC-1
Gliederung
• Ziel und grundlegende Funktionsweise des RPC/RMIV t ilt Obj kt d ll• Verteiltes Objektmodell
• Design• ImplementationImplementation• Beispiel: Java-RMI
vsis inf min uni hh ws 12_13 VIS-1 RPC-2
Ausgangspunkt verteilter Verarbeitung: lokale Netzwerke
eher lokal
Charakteristika
eher homogeneher kleineher proprietäreher überschaubar
vsis inf min uni hh ws 12_13 VIS-1 RPC-3
Ziel: WeltweiteNetzwerke
vsis inf min uni hh ws 12_13 VIS-1 RPC-4
Typische Probleme (1)
• HeterogenitätHeterogenität– Hersteller– Hardware– Betriebssysteme– Programmiersprachen
vsis inf min uni hh ws 12_13 VIS-1 RPC-5
Typische Probleme (2)
• Verteilung– verschieden(artig)e Netze– skaliert von 2m bis 20.000km– Übertragungskosteng g– Bandbreite– Sicherheit
vsis inf min uni hh ws 12_13 VIS-1 RPC-6
Typische Probleme (3)
• Integrationserfordernisse– ‘Compound Documents’– CAD, CIM, CASE– Anwendungsintegrationg g– ‘Legacy’ - Systeme (!)
vsis inf min uni hh ws 12_13 VIS-1 RPC-7
Typische Probleme (4)
• Software “Engineering”
Ziele:
– Erweiterbarkeit– Ersetzbarkeit– Wiederverwendbarkeit
Maintenance Costs !!![M 1997][Meyer 1997]
vsis inf min uni hh ws 12_13 VIS-1 RPC-8
Kooperation: Nachrichtenversand vs. Methodenaufruf
A) Nachrichtenaustausch:• i.d.R. keine Verteilungstransparenzg p• Nachrichtenaustausch über explizite 'Ports'• Zugriff von (vielen!) Prozessen auf Ports
S h i i d h li i N h i h h• Synchronisation durch expliziten Nachrichtenaustausch• Nebenläufigkeit als dominantes Programmierparadigma
B) Entfernter Prozeduraufruf:• Einfache Analogie Inter- / Intraprozessmodell
keine e pli iten Komm nikationspfade• keine expliziten Kommunikationspfade• Kooperation z.B. durch Sperren, Semaphore oder Monitore • Verteilungstransparenz möglichg g• Sequentialität als dominantes Programmierparadigma
„On the Duality of Operating System Structures “ [Lauer/Needham, 1979]:
vsis inf min uni hh ws 12_13 VIS-1 RPC-9
Dualität beider Modelle !
Entfernter Methodenaufruf „Remote Method Invocation (RMI)“( )
Idee:A f f tf t M th d i l k l M th d f f ( V t il t “)Aufruf entfernter Methoden wie lokaler Methodenaufruf („Verteilungstransparenz“)Objektorientierte Weiterentwicklung vom RPC (Remote Procedure Call)Abstraktion von:Abstraktion von:
- Kommunikationsdetails ,
- Übertragungsfehlern, ...
Modell:Aber: z.B.
- Fehlertransparenz ist nie vollständig möglich- Einschränkungen bei den Parametertypen
Client ServerR
CallBeispiele für RPC/RMI Systeme:
- Birrel & Nelson (81), XEROXLiskov et al (83): 'Argus' MIT Response- Liskov et al. (83): 'Argus', MIT
- SUN RPC (85)- ISO/OSI Remote Operations (89): ROSE, RPC- OSF DCE RPC, ...
vsis inf min uni hh ws 12_13 VIS-1 RPC-10
- Java-RMI (97)
RPC/RMI-Aufruf aus Programmierersicht
Rechner A Rechner B
Client-Prozess
Prozeduraufruf
Server-Prozess
Ausführung derRequest
fährt fort
gProzedur
Ergebnis-Rückgabe
suspendiertReply
fährt fort
• Prozeduraufruf im entfernten Rechner ähnlich wie im lokalen Fall
• RPC/RMI realisiert die Kommunikationsgrundstruktur des Client/Server-Modells
Abstraktion von der Verteilung RPC/RMI realisiert die Kommunikationsgrundstruktur des Client/Server-Modells
-> spiegelt Semantik der Aufrufe zwischen unterschiedlichen Modulen wider-> einfach zu verstehen und zu implementieren
RPC/RMI ist in verteilten Systemen oft ein geeignetes Mittel zur effizienten
vsis inf min uni hh ws 12_13 VIS-1 RPC-11
RPC/RMI ist in verteilten Systemen oft ein geeignetes Mittel zur effizienten Implementierung von (abstrakten) Datenobjekten !
Request-reply communication
ServerClient
RequestdoOperationgetRequestmessageselect object
(wait)
Replymessage
executemethod
select object
sendReply(continuation)
message sendReply
vsis inf min uni hh ws 12_13 VIS-1 RPC-12
Aspekte der Verteilungstransparenz beim RPC
-> vollständige Transparenz bzgl. des lokalen Prozduraufrufs ist nicht möglich:
Aspekte der Verteilungstransparenz beim RPC
g p g g• Parameterübergabe• Performanz• Kommunikations- und Knotenfehler• Ausnahmebehandlung
-> vollständige Transparenz ist auch nicht immer unbedingt wünschenswert !
1) keine Garantie bei Fehlerfällen ('maybe'-Semantik)
2) höchstens einmal ('at most once')Alternative
RPC- ) ( )
3) mindestens einmal ('at least once')
- Vernichten von Duplikaten auf Server-Seite,sonst nur einmalige Nachrichtenübertragung
RPCSemantiken
3) mindestens einmal ( at least once )
4) t A füh d S P d (' tl ')
- nur für wiederholbare Funktionen- transparent für Klient
vsis inf min uni hh ws 12_13 VIS-1 RPC-13
4) atomare Ausführung der Server-Prozedur ('exactly once')- Server-Prozedur wird ganz oder gar nicht ausgeführt
Unterschiede zum lokalen ProzeduraufrufAllgemeine Charakteristik des RPC:
- Parameterübergabe durch 'Call by Value' - Keine globalen Variablen- Parameterübergabe durch Call by Value - Keine globalen Variablen - Typenprüfung - Alternativen der Fehlersemantik- Autorisierung - Lokale Leistungsoptimierung
Unterschiede zum lokalen Prozeduraufruf:
• disjunkte Ausführungsumgebungen -> verschiedene Prozesse> kein Zugriff auf gemeinsame Variable
• Performanz• Kommunikations- und Knotenfehler• Ausnahmebehandlung
-> kein Zugriff auf gemeinsame Variable-> nur Call-by-value
g• Authentisierung oftmals notwendig
Ä HW/SW Off S h i ll D (U ) M h lli "S b "zu lösende Probleme:HETEROGENITÄT: HW/SW, Offene Systemschnittstellen, Datentypen, (Un-) Marshalling, "Stubs"TRANSPARENZ: Fehlersemantik (o, 1, n mal), Parameterübergabe, ExceptionsBINDUNG: Client/Server, Schnittstellen, Syntax- und Semantikdefinition, "Trading", ...
vsis inf min uni hh ws 12_13 VIS-1 RPC-14
PARALLELITÄT: (Nicht) blockierender RPC, Multi-Prozesssysteme, Threads
Transaktionsgeschützter RPC
CallClient Server
Response
Transaktionssicherung
• Server implementiert "Dienst" als abstraktes "Objekt" ; Implementationsdetails unsichtbar.p j p• Server exportiert Operationen und Regeln für deren Benutzung über Kommunikationsschnitt-
stelle.• Zugang zum Server über Menge von vorgegebenen Nachrichten.• Schnittstellen und Protokolle sind standardisiert für Kommunikation in heterogenen Systemen.• Transaktionen garantieren "genau/ höchstens/ mindestens einmal"-Semantik des RPC.
RPC-Erweiterungen:• Call-back: aufgerufener Prozess meldet sich selbst wieder
• Broadcast: -> bei Server-Klassen: Aufruf aller (Muticast: vieler) anderer Prozesse
vsis inf min uni hh ws 12_13 VIS-1 RPC-15
Broadcast: -> bei Server Klassen: Aufruf aller (Muticast: vieler) anderer Prozesse
Beispiel: zustandsbehafteter Server
Beispiel: Einfacher Datei-Server mit Zustandsinformationen
O (fil d )
Client-Prozess Server-Prozess
Open (filename, mode)
File descriptor
R d (fil d b t )
Server-Zustand:
Dateiname, Be-Read (file desc., bytes)
Bytes read, data read
,schreibg., Mode,Aktuelle Positionin der Datei
Client muss Server Fehler feststellen- Client muss Server-Fehler feststellen- Client muss nach Fehlern synchronisieren- Server hält ev. ungültige Zustandsinformation+ Effiziente Implementierungen möglich
Ei f h P i di
vsis inf min uni hh ws 12_13 VIS-1 RPC-16
+ Einfaches Programmierparadigma
Beispiel: zustandslose Server
Beispiel: Einfacher Datei-Server ohne Zustandsinformationen
Read (filename, file
Client-Prozess Server-Prozess
( ,position, num bytes)
Num bytes read newNum. bytes read, newfile position, data readClient-Zustand:
Dateiname, Be-schreibg Modeschreibg., Mode,Aktuelle Positionin der Datei
+ Einfaches Protokoll in Fehlerfällen+ Client braucht Server- oder Netzfehler nicht speziell zu berücksichtigen
vsis inf min uni hh ws 12_13 VIS-1 RPC-17
p g+ Kein Recovery nach Fehlern nötig - einfaches Wiederholen des RPC genügt
UNIX-Beispiel: C/S-Bindung mittels 'Portmapper'UNIX-Beispiel: C/S-Bindung mittels Portmapper
Client-Programm
Port-mapper111
2
3C
...1
2
4
Server-ProgrammS
Client-Knoten Server-Knoten
1. Server meldet sich beim Portmapper an2. Client fragt Dienst beim Portmapper nach3. Client bekommt Server-Port vom Portmapper
vsis inf min uni hh ws 12_13 VIS-1 RPC-18
4. Client ruft Dienst (direkt) auf
Zeitlicher Ablauf beim (a)synchronen Aufruf des RPC/RMI
synchron asynchron
Cli t S Cli t S
process args.marshall
process args.marshall
Client Server Client Server
sendreceiveunmarshallexecute req.
send
process args.marshall
receiveunmarshallexecute req.
marshallsendreceive
unmarshallprocess res.marshall
marshallsend
marshallsend
receiveunmarshallmarshall
send receiveunmarshallexecute req.marshall
receiveunmarshall
execute req.marshallsend
marshallsend
receiveunmarshall
process res.
receiveunmarshallprocess res
vsis inf min uni hh ws 12_13 VIS-1 RPC-19
process res. process res.time
Ablauf eines RPC-AufrufesClient Server
Client Serverstub
Nachrich-ten-Modul
ServerClientstub
Nachricht-enModul
lokaler P d
Verpackend E f
Auspackend
Prozedur-Senden>Prozedur-
aufrufderArgumente
Empfangen derArgumente
aufruf
Ausführ-ung derProzedur
der Anfrage >
Sendendes Ergebnis
AuspackendesErgebnis
lokale Antwort
EmpfangenVerpackendesErgebnis
RückgabederAntwort
<
• Client-Stub - generiert die Nachrichtführt das Glätten (marshalling) der Nachricht z B mit Hilfe der
• Server Stub
- führt das Glätten (marshalling) der Nachricht - z.B. mit Hilfe derXDR-Routinen durch
- kreiert Portregistriert sich beim Portmapper
vsis inf min uni hh ws 12_13 VIS-1 RPC-20
- registriert sich beim Portmapper- Entpacken der Nachricht (unmarshalling)- Dispatching (Aufruf der entsprechenden Server-Prozedur)
RPC-Schnittstellendefinition- Definition der Typen der Argumente - Spezifikation der Prozedurköpfe- Zuweisung von Id.nummern zu den Prozeduren
• Bestandteile InterfaceDefinitiong
- Definition des Programms und der Version
• Schnittstellenspracheö S f
Language
- wird benötigt, wenn die Sprache kein Definitionsmodul besitzt oder wenn Client und Server in unterschiedlichen Sprachen geschrieben sind
- bietet skalare und strukturierte Datentypen- kann oft von verschiedenen Sprachen aus benutzt werdenkann oft von verschiedenen Sprachen aus benutzt werden- Bsp. RPC-Language (umfasst auch XDR-Funktionen in UNIX)
- entspricht von der Idee her der Definitionsdatei in Modula-2- Server exportiert die Schnittstelle Client importiert die Schnittstelle
• Datenabstraktion- Server exportiert die Schnittstelle, Client importiert die Schnittstelle- Server und Client müssen dieselbe Version der Schnittstelle benutzen
• Marshalling/Unmarshalling-Routinen- Generierung einer Marshalling/Unmarshalling-Prozedur für jeden im
Schnittstellenmodul definierten Datentyp• Prozedurnummern
vsis inf min uni hh ws 12_13 VIS-1 RPC-21
- Client und Server kommunizieren nur über die Prozedurnummern- Dispatching erfolgt über die Prozedurnummern
IDL-Beispiel: 'Files Interface' in Sun XDR
/* File ReadWrite service interface definition in file File ReadWrite.x*//
struct readargs {FileIdentifier f;FilePointer position;
const MAX = 1000;typedef int FileIdentifier;typedef int FilePointer;
FilePointer position;Length length;
};
typedef int Length;struct Data {
int lengthh b ff [MAX]
program FILEREADWRITE {version VERSION {
char buffer [MAX];};struct writeargs {
Fil Id tifi f version VERSION {void WRITE (writeargs) = 1;data READ (readargs) = 2;
FileIdentifier f;FilePointer position;Data data;
}; } = 2;
} = 9999;
};
vsis inf min uni hh ws 12_13 VIS-1 RPC-22
} ;
IDL-Beispiel: 'Files Interface' in ANSA IDL
FileReadWrite : INTERFACE =FileReadWrite : INTERFACEBEGIN
FileIdentifier, FilePointer, Length : TYPE = CARDINAL;D t TYPE SEQUENCE OF CHARData : TYPE = SEQUENCE OF CHAR;
Write : ANNOUNCEMENT OPERATION [f: FileIdentifier; position: FilePointer; data: Data;] RETURNS [ ];
Read OPERATION [f: FileIdentifier; position: FilePointer; length: Length;] RETURNS [ Data ];
END.
vsis inf min uni hh ws 12_13 VIS-1 RPC-23
IDL-Beispiel: 'RoomBooking' in CORBA IDL
aus: A Vogel K Duddy: "Java Programming with CORBA" John Wiley & Sons 1997
module RoomBooking {
aus: A. Vogel, K. Duddy: Java Programming with CORBA , John Wiley & Sons, 1997
interface Meeting {// A meeting has two read-only attributes which describe the// purpose and the participants of that meeting.
readonly attribute string purpose;readonly attribute string participants;
};interface MeetingFactory {
// A meeting factory creates meeting objects.Meeting CreateMeeting ( in string purpose, in string participants );
};
vsis inf min uni hh ws 12_13 VIS-1 RPC-24
IDL-Beispiel: 'RoomBooking' in CORBA IDL (cont.)interface Room {
// A Room can be booked for several (here: 8) time slots. Sl t { 9 10 11 12 1 2 3 4}enum Slot {am9, am10, am11, pm12, pm1, pm2, pm3, pm4};
// Since cardinality of slots cannot be determined in IDL MaxSlots defines it: const short MaxSlots = 8;
// "Meetings" associates meetings with time slotstypedef Meeting Meetings [MaxSlots];exception NoMeetingsInThisSlot {};exception SlotAlreadyTaken {};
// The attribute "name" names a room:readonly attribute string name;
// "View" returs the bookings for a room, "Book" and "Cancel" book resp. cancel// reservation for a room (here: only for a day):
Meetings View ();g ();void Book ( in Slot a_slot, in Meeting a_meeting ) raises (SlotAlreadyTaken);void Cancel ( in Slot a_slot ) raises (NoMeetingsInThisSlot)
};
vsis inf min uni hh ws 12_13 VIS-1 RPC-25
};};
Automatische SW-Generierung beim UNIX-RPClokales Client-Anwendungs-programm
Schnittstellendefinition (IDL) lokale Server-Prozeduren
IDL C il“rpcgen”
IDL - Compiler
XDRRoutinen
ClientStub_0
ServerStub_0
HeaderDatei
C-CompilerC-Compiler C-Compiler C-Compiler
ClientStub
Anwendungs-objekt
ServerStub
Prozeduren-objekt
Linker Linker
vsis inf min uni hh ws 12_13 VIS-1 RPC-26
Client-Programm
Server-Programm
Effiziente Realisierung: 'Multi-threaded' Server
Transaktionssicherung
Client ServerCall
Client Server
Response
Client i Server iClient_i Server_i
Ei S k h T kti l i h iti b t ili t iEin Server kann an mehreren Transaktionen gleichzeitig beteiligt sein
Ein Server bearbeitet zu jedem Zeitpunkt genau eine Transaktion - kann aber auf eine andere umschalten bevor die erste beendet wird (durch 'commit'
vsis inf min uni hh ws 12_13 VIS-1 RPC-27
auf eine andere umschalten bevor die erste beendet wird (durch commit oder 'rollback')
Effiziente Realisierung von (RPC-) Servern
1) E i S P fü j d Cli t A f
Alternativen:
1) Erzeugen eines neuen Server-Prozesses für jede neue Client-Anfrage-> mehrere Instanzen desselben Prozesses bestehen gleichzeitig-> Synchronisation beim Zugriff auf gemeinsame Variable notwendig
2) Ein Server-Prozess läuft kontinuierlich und wartet auf Client-Anfragen-> Erhöhung des Parallelitätsgrades durch Threads
Beispiel für RPC-Implementierung mittels Threads (s.u.):
- wird aktiviert - Herausholen des Auftrags- Prozedurausführung - Versenden der Antwort- wait ( Arbeiter 5 )
• Ablauf des Arbeiter 5:
• Verteiler: - Thread, der auf Anfragen wartet- Schreibt ankommende Aufträge in den gemeinsamen Speicher - aktiviert den nächsten Arbeiter-Thread
vsis inf min uni hh ws 12_13 VIS-1 RPC-28
• Synchronisation: -> durch Monitor
Beispiel für RPC-Implementierung mit Hilfe von Threads
Rechner A Rechner B
A b it Arbeiter
Arbeiter
Arbeiter 1:Prozeduraufrufwait(Arbeiter1)
Nachrichten-PufferNachrichten-
Puffer 1210
Verteiler Verteiler
Arbeiter3
10
8 Verteiler
Arbeiter
Verteiler
Arbeiter ConditionVariableA b it 5
signal(Arbeiter5)signal(Arbeiter1) 4569
ArbeiterArbeiter5
wait( Arbeiter5 )Arbeiter 5Condition
VariableArbeiter1
7
vsis inf min uni hh ws 12_13 VIS-1 RPC-29
RPC-Implementierung: Server-Klassend.h.: auf verschiedenen Rechnern läuft mind. ein Server-Prozess desselben Dienstes
R h A
Client
Server-Prozess 1 Server-
Rechner A
Rechner C
Client Prozess 4
Server-Prozess 3
Server-Prozess 2
Rechner B
Prozess 3 Prozess 2Probleme:
Wann werden Server-Klassen vergrößert / verkleinert?gdurch Systemverwalter vorgegebene Scheduling-Strategie--> Dynamische Erweiterung / Verkleinerung der Klasse
Wie viel Zustandsinformation muss ein Server verwalten?Server ist kontextfrei vs. Zustand wird in Datenbank verwaltet (für Fehlertoleranz)--> Verwaltung von Zustandsinformationen in den Servern
Wann / Wie wird Last-Balancierung durchgeführt?G i W t hl / S h d l d t j d Cli t i S
vsis inf min uni hh ws 12_13 VIS-1 RPC-30
Gemeinsame Warteschlange / Scheduler ordnet jeden Client einem Server zu.--> Lastverteilung (Load Balancing) - z.B. durch ausgezeichneten Verteiler-Server
A remote object and its remote interface
remoteobject
remote Data
interfacem1m2m3
m4m5m6
implementation{ of methods{
[C/D/K12]
vsis inf min uni hh ws 12_13 VIS-1 RPC-31
Verteiltes objektorientiertes Modell (1)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— Referenzen:
• Identifizierer für einen Methodenaufruf• Ein/Ausgabeparameter einer Methode
• Übertragung dieser Semantik auf den verteilten Fall über Remote-Übertragung dieser Semantik auf den verteilten Fall über RemoteReferenzen
invocation invocationremote
t
locallocalC
Einvocation invocationinvocationremote
localinvocation
invocationA B
D
F
vsis inf min uni hh ws 12_13 VIS-1 RPC-32
D
Verteiltes objektorientiertes Modell (2)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— Schnittstellen (Interfaces):
• dienen der Spezifikation von Diensten• bestehen aus einer Menge an Methodensignaturen (+Attributen)
• Schnittstellen für entfernte Objekte: Remote InterfacesSchnittstellen für entfernte Objekte: Remote Interfaces• Verbergen von evtl. vorhandener Heterogenität -> Standards für Interface
Definition Languages
invocation invocationremote
t
locallocalC
Einvocation invocationinvocationremote
localinvocation
invocationA B
D
F
vsis inf min uni hh ws 12_13 VIS-1 RPC-33
D
Verteiltes objektorientiertes Modell (2)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— Schnittstellen (Interfaces):
• dienen der Spezifikation von Diensten• bestehen aus einer Menge an Methodensignaturen (+Attributen)
• Schnittstellen für entfernte Objekte: Remote InterfacesSchnittstellen für entfernte Objekte: Remote Interfaces• Verbergen von evtl. vorhandener Heterogenität -> Standards für Interface
Definition Languages// CORBA IDL Beispiel: Person.idl
invocation invocationremote
t
locallocalC
E
pstruct Person {
string name; string place;long year;
} ;invocation invocationinvocationremote
localinvocation
invocationA B
D
F} ;interface PersonList {
readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);l b ()
vsis inf min uni hh ws 12_13 VIS-1 RPC-34
Dlong number();}; (CDK 05)
Verteiltes objektorientiertes Modell (3)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— Operationen:
• dienen der Kapselung von Verhalten• können den Zustand des Empfängers ändern• 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
t
locallocalC
Einvocation invocationinvocationremote
localinvocation
invocationA B
D
F
vsis inf min uni hh ws 12_13 VIS-1 RPC-35
D
Verteiltes objektorientiertes Modell (4)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— 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
t
locallocalC
Einvocation invocationinvocationremote
localinvocation
invocationA B
D
F
vsis inf min uni hh ws 12_13 VIS-1 RPC-36
D
Verteiltes objektorientiertes Modell (5)
• Wichtige objektorientierte Konzepte und ihre Implikationen in verteilten SystemenSystemen— Garbage Collection (GC):
• dient der automatischen Speicherbereinigung• nicht verwendete Objekte werden freigegeben• Beispiel: Mark-and-Sweep Algorithmus
• Freigabe von entfernten Objekten über verteilte GC• Problem der verteilten Adressräume
invocation invocationremote
t
locallocalC
Einvocation invocationinvocationremote
localinvocation
invocationA B
D
F
vsis inf min uni hh ws 12_13 VIS-1 RPC-37
D
RMI-Design: Fehlersemantiken• Im lokalen Fall besitzt der Methodenaufruf exactly-once-Semantik• Im verteilten Fall gibt es unterschiedliche Semantiken:
— Maybe-Semantik (0-1 Aufrufe): y ( )• 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)• 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
Fault tolerance measures Invocation semantics
Retransmit request Duplicate fil i
Re-execute procedure i lmessage filtering or retransmit reply
No
Yes
Not applicable
No
Not applicable
Re-execute procedure At-least-once
Maybe
vsis inf min uni hh ws 12_13 VIS-1 RPC-38
Yes Yes Retransmit reply At-most-once
RMI-Design: Transparenz
• Inwieweit kann und sollte der RMI/RPC-Aufruf transparent sein?Unterscheidung von Transparenz für den Anwender und den Programmierer— Unterscheidung von Transparenz für den Anwender und den Programmierer
— RMI ist eine Technologie für den Programmierer— Pro: einfache Benutzbarkeit, höheres Abstraktionsniveau
C t U i h it k I ffi i füh— 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 notwendigg g
• Konsens:— so viel Transparenz wie möglich z B gleiche Syntax— so viel Transparenz wie möglich, z.B. gleiche Syntax — aber erkennbar machen, dass es sich um Remote-Aufrufe handelt— Ausnahmen explizit machen
vsis inf min uni hh ws 12_13 VIS-1 RPC-39
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— (Un)Marshalling des Aufrufs ServerprozessClientprozess— (Un)Marshalling des Aufrufs Serverprozess
Serverobjekt
Clientprozess
Clientobjekt
remoteclient server
Server-SkeletonClient-Stub
Proxy-Objekt
object A object BskeletonRequestproxy for B
Reply
for B’s class& dispatcher
remote
Reply
CommunicationRemote Remote referenceCommunicationmodule
servant
vsis inf min uni hh ws 12_13 VIS-1 RPC-40
modulemodulereference module module
"Marshalling" der Nachrichten
- Nachrichten werden gepackt und vom Empfänger wieder entpackt- Mechanismus muss Client und Server bekannt sein
Nach-richten
Nachrichtentyp Request-ID Nachrichten-ID Client-Port Methoden-Nr. Argumente(request/reply) für Server für Clientrichten-
formatzum Herausfiltern von Duplikaten zur Zuordnung der Antwort zur Anfrage
• Realisierung der Fehlersemantiken über die IDs• Übertragung von komplexen Objekten als Parameter möglich• Voraussetzung: Serialisierbarkeit• Remote Referenzen werden geeignet aufgelöst• Remote-Referenzen werden geeignet aufgelöst
vsis inf min uni hh ws 12_13 VIS-1 RPC-41
RMI-Implementation (2)• Remote-Referenz-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( ) y j
remoteclient server
object A object BskeletonRequestproxy for B
Reply
for B’s class& dispatcher
remote
Reply
CommunicationRemote Remote referenceCommunicationmodule
servant
vsis inf min uni hh ws 12_13 VIS-1 RPC-42
modulemodulereference module module
RMI-Implementation (3)• Proxy:
— Stellvertreterobjekt mit gleichem Interface wie Serverobjekt SchnittstelleServerobjekt
— sieht für A wie normales B Objekt aus— macht den Serveraufruf für A transparent durch Mar-
shalling/ Unmarshalling
• Dispatcher/Skeleton: — Aufrufbearbeitung auf Serverseite
f f f
Proxy ObjektClient
— macht den Aufruf für das B transparent
remoteclient server
[Hammerschall 05]
object A object BskeletonRequestproxy for B
Reply
for B’s class& dispatcher
remote
Reply
CommunicationRemote Remote referenceCommunicationmodule
servant
vsis inf min uni hh ws 12_13 VIS-1 RPC-43
modulemodulereference module module
RMI-Registry
• Server registriert ein Remote Object bei der RMI-Registry. Cli t d t RMI R i t Obj kt f f d R t• Client verwendet RMI-Registry, um Objektreferenz auf das Remote Object zu erhalten.
• Client ruft eine Methode aus der Objektreferenz auf.j• Server-JVM führt die Methode auf dem Remote Object aus.• Client erhält Ergebnisse des Aufrufs.
vsis inf min uni hh ws 12_13 VIS-1 RPC-44
(Wikipedia 2008)
RMI-Beispiel: Java-RMI
Java-RMI Architektur t llt ll t di A t il b it (St b / Sk l t C il K• stellt alle notwendigen Anteile bereit (Stubs/ Skeleton Compiler, Kommu-
nikationsmodule, Registry etc.)• bietet viele sinnvolle Erweiterungen wie Security, Callbacks, Activation, g y, , ,
Remote Classloading, und DGC• ist direkt in das JDK eingebunden
d t di J S h (V t il Ei f hh it N ht il J )• verwendet die Java-Sprache (Vorteil: Einfachheit, Nachteil: nur Java)
Server ObjektClient Main Methode
Server-Main-Methode
R t R f R t R f
Stub/Skeleton-SchichtStub/Skeleton-Schicht
Server-ObjektClient-Main-Methode
Kommunikationsprotokoll (IIOP)
Remote-Reference-Schicht / JVM
Remote-Reference-Schicht / JVM
vsis inf min uni hh ws 12_13 VIS-1 RPC-45[Hammerschall 05]
Protokoll-Stack
Java RMI Sicherheitsmodell
• ursprüngliche Motivation: Java-Applets• Java Plattform nutzt das sog Sandbox-Java Plattform nutzt das sog. „Sandbox
Modell“• Unterscheidung zwischen Trusted / Un-
trusted Code• Untrusted Code läuft mit beschränkten
Rechten in der Sandbox— kein Zugriff zum File-System— keine Möglichkeiten zum Aufbau neuer
Internetverbindungen• als Untrusted Code gilt:
[JavaWorld 97]— über das Netz bezogener Code (Klassen-
definitionen)— entfernte Aufrufe
• Überwachung der Aktionen einer Anwen
[ ]
• Überwachung der Aktionen einer Anwen-dung über Security Manager
• feine ressourcenbasierte Steuerung der Rechte über Policy Files
vsis inf min uni hh ws 12_13 VIS-1 RPC-46
Rechte über Policy Files
Java-RMI Callbacks
• Der Client benötigt Informationen über Zustandsänderungen vom Remote ObjektRemote-Objekt— a) Klient fragt in Abständen den Server (busy-wait Polling-Aufrufe)
• kann die Performance des Servers negativ beeinflussen• Klienten können u.U. Anwender nicht rechtzeitig über Änderungen
informieren— b) Server teilt dem Klienten Änderungen proaktiv mit (Callbacks)) g p ( )
• Server muss (aktuelle) Liste von interessierten Klienten besitzen• Server muss zur Abarbeitung eine Reihe von synchronen RMI-Aufrufen
durchführendurchführen
1 Registrierung
A B2..n-1 Callback
n Deregistrierung
vsis inf min uni hh ws 12_13 VIS-1 RPC-47
Java-RMI Beispiel DateServer
• einfacher Dienst zum Nachfragen des aktuellen Datums• Remote Anwendungs-Interfaces müssen:Remote Anwendungs Interfaces müssen:
— das Interface Remote erweitern (zeigt entferten Aufruf an) und— in der Methodensignatur eine RemoteException deklarieren.
• In der Schnittstelle können alle Java-Typen als Parameter verwendet werdenIn 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-Parameter müssen das Serializable Interface implementieren oder Remote
Referenzen sein.
import java.rmi.*p jimport java.util.Date
public interface RemoteDate extends Remote{
public Date holeDatum() throws RemoteException;}
vsis inf min uni hh ws 12_13 VIS-1 RPC-48
[Hammerschall 05]
Beispiel DateServer: Der Server
• Abgeleitet von der Klasse UnicastRemoteObject— Vererbung der Fähigkeiten zur entfernten Kommunikationg g— 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— Anmeldung über eindeutigen Namen und Referenz— Die Objektreferenz enthält die genaue Adresse des Objekts
• Die Methode main() 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");
vsis inf min uni hh ws 12_13 VIS-1 RPC-49
} 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 desRMI Registry die Objektreferenz vom Namensdienst zur Kontaktierung des Server-Objekts
• Die Referenz ist Grundlage für die Generierung eines Proxy Objekts• Über den Proxy können alle Methoden des Serverobjekts angesprochen werden• Über den Proxy können alle Methoden des Serverobjekts angesprochen werden
import java.rmi.*;import java util Date;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();Date datum = dateobject.holeDatum();System.out.println("Das Serverdatum ist: " + datum);
} catch (Exception e) {e.printStackTrace();}}
}
vsis inf min uni hh ws 12_13 VIS-1 RPC-50
}
Der RMI-Compiler - rmic
• Generierung von Stub und Skele-ton über rmic Client ServerSchnittstelleton über rmic
• ab Java 1.5 nicht mehr notwendig (DynamicProxies)
Client(Java)
Server(Java)
Schnittstelle(Java)
Der Aufruf ....rmic DateServer
javac
erzeugt zwei Dateien:DateServer_Stub.class Client
(B t d )Server
(B t d )Schnittstelle(B t d )
Client Server
DateServer_Skel.class (Bytecode) (Bytecode)
Client-Stub(Bytecode)
(Bytecode)
rmicServer-Skel.(Bytecode)
vsis inf min uni hh ws 12_13 VIS-1 RPC-51
[Hammerschall 05] : U. Hammerschall: „Verteilte Systeme und Anwendungen“, Pearson Studium – IT, 2005
Die RMI-Registry - rmiregistry
• verwaltet Remote-Objekte/Dienstei t b i A ld i R t R f• 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• 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)rmiregistry & (Unix)
start rmiregistry (Windows)
vsis inf min uni hh ws 12_13 VIS-1 RPC-52
Das Vorgehen im Überblick
• Implementation:D fi iti d S h itt t ll i h Cli t d S— Definition der Schnittstelle zwischen Client und Server
— Implementierung des Dienstes (Service-Objekts)— Implementierung des Servers— Implementierung des Clients— Dienst, Client und Schnittstelle mit javac übersetzen— (optional:) Generieren der Stubs mit rmic— (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 Servers, der den Dienst anmeldet und verwaltet— Starten eines Clients, der den Dienst in Anspruch nimmt
vsis inf min uni hh ws 12_13 VIS-1 RPC-53
Zusammenfassung
• RMI dient der Erweiterung des objektorientierten Paradigmas auf verteilte SystemeSysteme
• RMI ist als Erweiterung des prozeduralen Konzepts RPC entstanden• Funktionsweise ist dem lokalen Methodenaufruf sehr ähnlich (mit einigen• Funktionsweise ist dem lokalen Methodenaufruf sehr ähnlich (mit einigen
Unterschieden wie z.B. Fehlersemantiken, Transparenz)• RMI basiert intern auf dem Versenden von Nachrichten in denen die Auf-
rufinformationen enthalten sind (Request/Reply)• RMI überbrückt als Middleware Heterogenität auf unteren Ebenen• Beispiel Java-RMI: ergänzt das Basismodell mit diversen Funktionen wie
Security, Activation, DGC, Callbacks, …
vsis inf min uni hh ws 12_13 VIS-1 RPC-54