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 RPC – RMI - Web Services 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 RPC – RMI - Web Services 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? RPC – RMI - Web Services 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 RPC – RMI - Web Services 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 RPC – RMI - Web Services 6 Sequenza temporale L’effetto è quello di una chiamata sincrona RPC – RMI - Web Services 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 RPC – RMI - Web Services 8 Schema di RPC Il percorso di ritorno (parametri per valore e valori di rittorno) è simmetrico RPC – RMI - Web Services 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 RPC – RMI - Web Services 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 RPC – RMI - Web Services 11 Un esempio di sistema basato di IDL (DCE) RPC – RMI - Web Services 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 RPC – RMI - Web Services 13 Schema di un sistema ad oggetti distribuiti Proxy (o stub) = client stub Skeleton = server stub RPC – RMI - Web Services 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 RPC – RMI - Web Services 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 RPC – RMI - Web Services 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(); }; }; RPC – RMI - Web Services 17