Entfernter Prozedur/Methodenaufruf · Typische Probleme (1) • Heterogenität – Hersteller – Hardware – Betriebssysteme – Programmiersprachen vsis inf min uni hh ws 12_13

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


Ausgangspunkt verteilter Verarbeitung: lokale Netzwerke

eher lokal

Charakteristika

eher homogeneher kleineher proprietäreher überschaubar


Ziel: WeltweiteNetzwerke


Typische Probleme (1)

• HeterogenitätHeterogenität– Hersteller– Hardware– Betriebssysteme– Programmiersprachen



• Verteilung– verschieden(artig)e Netze– skaliert von 2m bis 20.000km– Übertragungskosteng g– Bandbreite– Sicherheit



• Integrationserfordernisse– ‘Compound Documents’– CAD, CIM, CASE– Anwendungsintegrationg g– ‘Legacy’ - Systeme (!)



• Software “Engineering”

Ziele:

– Erweiterbarkeit– Ersetzbarkeit– Wiederverwendbarkeit

Maintenance Costs !!![M 1997][Meyer 1997]


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]:


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


- 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


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


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


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", ...


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


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


+ 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


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


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


Client Server Client Server

sendreceiveunmarshallexecute req.

send


receiveunmarshallexecute req.

marshallsendreceive

unmarshallprocess res.marshall

marshallsend

marshallsend

receiveunmarshallmarshall

send receiveunmarshallexecute req.marshall

receiveunmarshall

execute req.marshallsend

marshallsend

receiveunmarshall

process res.

receiveunmarshallprocess res


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


- 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


- 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;

};


} ;

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.


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

};


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)

};


};};

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


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'


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


• 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


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


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]


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


D


• 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


t

locallocalC


localinvocation

invocationA B

D

F


D


• 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


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


Dlong number();}; (CDK 05)


• 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


t

locallocalC


localinvocation

invocationA B

D

F


D


• 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


t

locallocalC


localinvocation

invocationA B

D

F


D


• 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


t

locallocalC


localinvocation

invocationA B

D

F


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


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


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


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


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


Reply


remote

Reply


servant



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]


Reply


remote

Reply


servant



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.


(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


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


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


[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");


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

}


}

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)


[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)


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


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