9.RPC-RMI

Transcript

9.RPC-RMI

Applicazioni distribuite e
sistemi ad oggetti distribuiti
RPC – RMI - Web Services
1
Complessità delle applicazioni distribuite
La scrittura di applicazioni distribuite basate
sull’utilizzo di protocolli di comunicazione asincroni è
complessa e soggetta ad errori difficili da trattare
Gli sviluppatori applicativi non hanno l’abitudine a
trattare con dettagli di basso livello come quelli
richiesti dall’utilizzo di TCP/IP e dei socket
Inoltre si trovano a disagio con logiche di tipo
asincrono
Per questi motivi nel corso del tempo sono stati
proposti e realizzati meccanismi per creare
applicazioni distribuite sulla base di modelli sincroni
2
RPC: la soluzione
RPC = Remote Procedure Call
Il modello di base è stato proposto da Birrell e Nelson
nel 1984
L’obiettivo è quello di consentire l’invocazione di
procedure (funzioni) su altre macchine
In questo modo la comunicazione interprocesso si
riconduce ad un modello conosciuto e
fondamentalmente sincrono
E’ un astrazione di livello elevato che nasconde
dettagli di basso livello e rende trasparente la
presenza di una comunicazione attraverso una rete
Dal punto di vista del programmatore applicativo non
c’è (almeno in teoria) differenza fra chiamate locali e
remote
3
RPC: il mondo non è così semplice
E’ un’astrazione non banale da realizzare:
Le architetture delle due macchine su cui girano i
processi possono essere diverse
Ogni macchina ha uno spazio di indirizzamento
diverso.
Come si possono passare i parametri (di tipi diversi
e anche molto complessi)?
Cosa accade se cade la rete o una delle due
macchine (o entrambe) va in crash durante la
chiamata di procedura?
4
Chiamate di procedura locali
In una normale invocazione di procedura (o funzione) il
chiamante e la procedura comunicano in virtù del fatto
che condividono lo spazio di memoria
Per il passaggio di parametri si usa lo stack:
Nel caso di parametri passati per valore i valori
vengono ricopiati sullo stack
Nel caso di passaggio per riferimento nello stack
viene inserito un puntatore che consente alla
procedura di modificare il valore della variabile
originale
Anche il valore di ritorno della funzione viene
ripassato al chiamante utilizzando lo stack
5
RPC: un gioco di prestigio
Nel caso di procedure remote il meccanismo è diviso
in due parti e si ricorre a due mediatori che realizzano
il “trucco”:
Il client stub: implementa sulla macchina locale
l’interfaccia attraverso cui la funzionalità remota
può essere invocata (fa finta di essere la procedura
remota)
Il server stub: implementa la reale funzionalità
Il client stub impacchetta i parametri (marshalling) e li
invia al server usando un canale di comunicazione
(socket TCP/IP)
Il server stub spacchetta i parametri (unmarshalling) e
li passa alla procedura reale
Per i parametri di ritorno la cosa funziona in modo
simmetrico
6
Sequenza temporale
L’effetto è quello di una chiamata sincrona
7
I dieci passi di una RPC
1. La procedura chiamante invoca il client stub nel modo
usuale (chiamata locale)
2. Il client stub costruisce il messaggio e invoca il
sistema operativo locale (libreria socket)
3. Il S.O locale invia il messaggio al S.O remoto
4. Il S.O remoto consegna il messaggio al server stub
5. Il server stub spacchetta i parametri e chiama il
server (procedura effettiva)
6. Il server esegue il compito desiderato e restituisce i
risultati al server stub
7. Il server stub li impacchetta e invoca il suo S.O.
8. Il S.O del server invia il messaggio al S.O. del client
9. Il S.O. del client consegna il messaggio al client stub
10.Il client stub spacchetta il risultato e lo restituisce al
chiamante
8
Schema di RPC
Il percorso di ritorno (parametri per valore e valori di
rittorno) è simmetrico
9
I problemi di RPC
RPC funziona decisamente bene se le macchine sono
omogenee
Le complicazioni nascono quando le due macchine
coinvolte usano diverse codifiche di caratteri (ad
esempio EBCDIC e ASCII).
Anche l’ordine dei byte è un problema
Le macchine Intel sono “big-endian”.
Sun Sparc, Motorola e PowerPC sono “littleendian”.
Bisogna inserire meccanismi aggiuntivi nello schema
dell’RPC per gestire le conversioni
Questo aggiunge complessità e peggiora le
prestazioni
10
Chi scrive gli stub?
Il meccanismo dell’RPC prevede l’esistenza di due
mediatori (client e server stub) per poter funzionare
Devono essere scritti a mano?
Fortunatamente no: dal momento che si tratta di
codice molto ripetitivo si può automatizzarne la
creazione
Esistono dei linguaggi – di tipo dichiarativo - chiamati
IDL (Interface Definition Languages) che permettono
di definire le interfacce delle funzioni
Si utilizzano poi dei compilatori IDL che sulla base di
una descrizione IDL generano entrambi gli stub in un
linguaggio di alto livello (per esempio C)
Con un normale compilatore C si creano quindi il client
e il server stub
11
Un esempio di sistema basato di IDL (DCE)
12
RMI
RMI = Remote Method Invocation
I sistemi ad oggetti distribuiti si basano su RMI che
può essere considerata come un estensione object
oriented del meccanismo RPC
Un aspetto importante del modello OO è la netta
separazione fra interfaccia (quello che un oggetto sa
fare) e implementazione (come lo fa)
Le invocazioni di metodi provocano cambiamenti di
stato nell’oggetto mediati dall’interfaccia
In un sistema distribuito l’interfaccia di un oggetto
risiede su una macchina e l’implementazione risiede
su un’altra
13
Schema di un sistema ad oggetti distribuiti
Proxy (o stub) = client stub
Skeleton = server stub
14
Ancora su RMI
Viene creato localmente solo il riferimento ad un
oggetto remoto, che è effettivamente attivo su un host
distinto.
Un programma invoca i metodi attraverso questo
riferimento locale.
La struttura che si occupa di intercettare le
invocazioni dei metodi per trasmetterli (con i relativi
argomenti) all'oggetto sul server è denominata Object
Request Broker o ORB.
Le tipologie più diffuse di RMI sono:
CORBA (Common Object Request Broker
Architecture): standard aperto, multilinguaggio
DCOM (Distributed Component Object Model).
Microsoft, multilinguaggio
Java RMI: Sun, linguaggio Java
15
Architettura Java RMI e livelli OSI
Applicazione
Presentazione
Sessione
Trasporto
Stub e skeleton implementano il livello di
presentazione
Il Remote Reference Layer (RRL)
implementa invece il livello di sessione
Il protocollo applicativo di trasporto,
basato su TCP/IP, si chiama IIOP (Internet
Inter Orb Protocol) e deriva da CORBA
Rete
Datalink
Fisico
16
RMI e IDL
Anche per l’RMI si ricorre a linguaggi di descrizione
delle interfacce e ai relativi compilatori per la
creazione automatica di stub e skeleton
Gli IDL sono stati estesi in modo da comprendere
concetti object-oriented (interfacce, subtyping,
polimorfismo ecc.)
Esempio di IDL: un oggetto che restituisce data e ora:
module DateTimeApp
{
interface DateTime
{
string getDate();
string getTime();
long getMSecs();
};
};
17

9.RPC-RMI

Transcript

Documenti analoghi

Comunicazione tra Processi

Remote Procedure Call (RPC)

Cerco libro di Programmazione di rete Re:Cerco libro di - E

OggettoA: metodo1 metodo2 metodo3 Oggetto B OggettoA.metodo1

- Società Numismatica Italiana

ESERCITAZIONE TIGA: RMI, unico host, caricamento locale delle

Distributed Garbage Collection

qui