InterProcess Communication (IPC)

Transcript

1 CdL MAGISTRALE in INFORMATICA A.A corso di Sistemi Distribuiti 5. IPC (Inter Process Communication) (parte 2): da RPC a RMI Prof. S.Pizzutilo InterProcess Communication (IPC) Modelli e tecnologie per la comunicazione e la sincronizzazione fra processi: I tipi di comunicazione: Comunicazione diretta (es. client/server) e indiretta (es.multicast) Comunicazione discreta (es. socket) e a flussi (streaming) Le forme ed i modelli della comunicazione : Ø Sistema di comunicazione basato sui messaggi ( MOM = Message Oriented Middleware). Ø Chiamata a procedura remota (es. RPC) e la comunicazione tra oggetti (es. RMI). Ø Comunicazione Multicast. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti 1

2 I modelli di comunicazione Client-server Function shipping Group multicast Peer to Peer 1) trasmissione di una richiesta da un processo (client) ad un altro processo (server) 2) esecuzione della richiesta sul server 3) trasmissione di una risposta dal server al client Ogni richiesta contiene un identificatore che viene usato anche dal server per trasmettere la risposta al client. E una estensione del modello client-server in cui il client non invia un messaggio con solo dati, bensì la procedura intera con cui il server deve operare sui dati. Il server in tal caso opera come ambiente di esecuzione (o interprete) dei programmi che il client gli invia. Corrisponde ad un message passing con un target multiplo, formato da un gruppo di processi destinatari/server. In questo caso ad un singolo send corrisponde un receive eseguito da ciascun membro di un gruppo di processi. Per localizzare un oggetto. Per aumentare fault tolerance. Per un multiple update. Ogni computer (nodo autonomo ed indipendente) può operare indifferentemente come client o come server, consentendo accessi condivisi a diverse risorse (come file, periferiche e sensori) senza la necessità di un server centrale. Ciò comporta che ciascun computer della rete utilizzi programmi compatibili che consentano questo tipo di comunicazione. Da message passing a procedure call ü L IPC basato sui messaggi consente due operazioni: Send (messaggio) la dimensione del messaggio può essere fissa o variabile Receive (messaggio) ü Se P e Q vogliono comunicare, hanno bisogno di: stabilire un canale di comunicazione fra di loro, fisicamente (es. memoria condivisa, bus hardware) logicamente (es. proprietà logiche) scambiare messaggi per mezzo di send e receive 2

3 Encoding e decoding dei messaggi Conservazione della semantica dei messaggi tra sistemi disomogenei Nodo A Nodo B buffer messaggio encoding Messaggio codificato I valori dei puntatori perdono il loro significato quando sono trasferiti da uno spazio degli indirizzi di un processo ad un altro. Oggetti diversi di un programma occupano spazio di memoria diverso a seconda delle architetture messaggio decoding Messaggio codificato buffer Tagged representation : nel messaggio vengono codificati il tipo ed il valore degli oggetti Untagged representation : il messaggio contiene solo il valore dell oggetto senza alcuna specifica del tipo. Presuppone che il programma ricevente sappia decodificare i dati ricevuti. Istruzioni di chiamata a procedura locale ü ü L istruzione di chiamata ( Call ) è un istruzione di salto, il cui operando è l indirizzo della prima istruzione della procedura, detto entry-point address L istruzione di ritorno ( Return ), al termine della esecuzione della procedura chiamata, è una istruzione di salto alla procedura chiamante, alla istruzione che segue immediatamente la istruzione di call: Necessità di conservare l indirizzo di tale istruzione, detto return address main. call A.. call A Proc A call B... return Proc B... return Il return address può essere conservato in: Registri o locazioni di memoria Difficoltà nel chiamare un altra procedura all interno di quella chiamata (procedure nidificate) Locazione di memoria associata alla procedura L istruzione di return è una istruzione di salto alla locazione di memoria che conserva l indirizzo della istruzione della procedura chiamante È possibile la nidificazione delle procedure Stack È possibile sia la nidificazione delle procedure che la ricorsività (abilità di una procedura a chiamare se stessa) 3

4 Passaggio dei parametri tra procedure La procedura chiamante può passare alla procedura chiamata dei valori detti parametri (o argomenti o dati ). La procedura chiamata fornisce dei parametri ( o risultati) alla procedura chiamante La procedura chiamante pone i parametri nello stack, prima di effettuare la chiamata (trasmissione per valore), da dove vengono letti dalla procedura chiamata La procedura chiamante pone gli indirizzi dei parametri nello stack (trasmissione per indirizzo o referenza), la procedura chiamata legge gli indirizzi per accedere ai valori e modificarli o calcolarne di nuovi. Trasmissione per copia/ripristino : il chiamante pone i parametri nello stack, il chiamato li legge dallo stack e pone i risultati nello stack, il chiamante legge dallo stack e ricopia i dati in memoria sovrascrivendo i parametri precedentemente trasmessi. I protocolli per la comunicazione tra processi remoti Le caratteristiche principali di un DCE (Distributed Computing Environment) sono: p. Un tool di rappresentazione dei dati indipendente dalla macchina (per permettere a macchine diverse di scambiarsi i dati), p. un protocollo per specificare responsabilità a basso livello del client e del server durante la comunicazione, p. un compilatore di protocollo che generi le componenti necessarie alla comunicazione, p. servizi di autenticazione per migliorare la sicurezza, p. servizi di naming di rete, p. servizio di DFS (Distributed File System) per eliminare ridondanza di files. Client Risposta Richiesta Client Richiesta Risposta Richiesta Server Risposta Client 4

5 RPC (Remote Procedure Call) L'RPC permette la chiamata di procedure esterne che risiedono su diversi spazi di indirizzi in modo simile ad una chiamata locale. u Gli argomenti e i valori di ritorno sono automaticamente impacchettati e inviati dalle procedure locali a quelle esterne, in modo da mantenere la semantica delle chiamate delle procedure remote simile a quella delle chiamate locali. u L'RPC è stato progettato per la creazione di applicazioni distribuite su ambienti eterogenei, quindi l attività di marshalling dei dati è fondamentale : i parametri trasmessi tra le procedure in RPC devono essere impacchettati in un formato canonico indipendente dall'architettura prima di essere passati alle procedure remote. u Una tipica applicazione RPC è costituita da un client ed un server che comunicano tra loro per mezzo dei rispettivi stub che si occupano di convertire i dati dal formato della macchina a quello generale e viceversa. RPC (Remote Procedure Call) L RPC opera a livello di sessione del modello ISO-OSI, utilizzando l XDR a livello di presentazione come modo di rappresentazione dei dati. In una chiamata a procedura remota il chiamante (client) e il chiamato (server) interagiscono nel seguente modo: Il client esegue una chiamata ad una funzione server e si blocca sino a che non ottiene il risultato. Un processo di gestione delle RPC raccoglie i valori dei parametri, forma un messaggio (stub) e lo invia al server remoto. Il kernel del server riceve la richiesta, spacchetta i parametri, invoca la procedura e invia indietro la risposta al client. 5

6 Procedura Chiamante Procedure call e RPC Chiamata a procedura locale argomenti Procedura Chiamata risultato La differenza fra una call locale ed una remota consiste nello spazio di indirizzi su cui le procedure operano. argomenti messaggio Chiamata a procedura remota risultati risultati argomenti Il processo client effettua una call richiesta messaggio messaggio locale allo stub del client ; lo stub la risposta messaggio risposta richiesta intercetta insieme ai suoi argomenti, RETE lo impacchetta e genera un trap al kernel del client con il messaggio di richiesta. Questo viene inviato sulla rete dal kernel della macchina client utilizzando un protocollo di trasmissione (TCP,UDP,...), raggiungendo così lo stub del server. Il kernel della macchina server lo riceve, lo spacchetta e lo trasforma in una call locale al processo server. I risultati vengono inseriti nel messaggio di risposta, che lo stub del server invia sulla rete allo stub del client con lo stesso meccanismo. Client Processo Chiamante Client Stub Server Processo Chiamato Server Stub Marshalling dei dati Lo stub contiene l interfaccia di comunicazione e i dati. Gli stub possono essere generati automaticamente da un compilatore di protocollo e sono trasparenti all utente. Il client ed il server stub si occuperanno di: Ø Risolvere problemi riguardanti la diversa rappresentazione dei dati (big endian, little endian), implementando meccanismi di marshalling in un formato canonico (XDR). Ø Passaggio dei parametri puntatore: al server viene passato il dato e non il puntatore, questo sarà memorizzato in una locazione del server e creato un puntatore alla locazione (tecnica del copia / ripristino). 6

7 Standard di Network Computing OpenNetworkComputing RPC (Sun, AT&T, Novell, Netwise) Application Programs NFS NIS REX NLM RPC Transport Level Interface XDR Socket Low level network protocols (TCP, UDP, OSI, SPX/IPX) OpenSoftwareFoundation NCS/NCA RPC (HP, Apollo, IBM, DEC, Microsoft) Application Programs Location Broker Global Local RPC NDR Low level network protocols (TCP, UDP, OSI, SPX/IPX) ONC-RPC binding Tutto il meccanismo avviene dopo che fra il client ed il server è stata creata una connessione (binding), che viene realizzata, durante l esecuzione del client, da un istruzione della RPC che crea un handle (un puntatore al CLIENT). La clnt_create() restituisce un puntatore ad un indirizzo che contiene la posizione del server. Questa viene individuata da un servizio del sistema server (il portmapper) che conserva il numero di porta di connessione su cui il processo server si è registrato ed è in ascolto (1). Una volta che il client ottiene il numero di porta del server (2) inviando anche l indirizzo dove ricevere le risposte, apre una connessione, che resta aperta (3) fino a quando non viene invocata la funzione clnt_destroy() che la chiude. Client 2 Server Portmapper 1 porte di com. Programma client 3 Programma Server 7

8 Il binding (cont.) RETE Fino a quando la connessione resta aperta, il client può invocare tutti i servizi del server (send). Durante una richiesta il client resta in attesa della risposta (blocked). Il processo server invece è sempre in attesa (in receive) e si attiva solo quando riceve una richiesta di servizio (messaggio) sulla porta di ascolto. Allora invoca la procedura richiesta e, dopo averla eseguita, assembla la risposta. Quindi la invia (send) al client, che a questo punto può riprendere la sua esecuzione, e si rimette in receive. Macchina client programma client attesa... Call rpc() con richiesta return() con risposta Macchina server demone del servizio in ascolto invoca il servizio chiamata alla procedura Return() risultato esecuzione della proc. richiesta esaurita costruzione della risposta demone del servizio in ascolto Higher level RPC e Lower level RPC Esistono due modi per utilizzare il meccanismo RPC: ad alto livello (Higher level RPC) ed a basso livello (Lower level RPC). Nell' Higher level RPC la specifica dei tipi di dati che si passano e l identificazione della procedura server remota è a carico del programmatore che genera manualmente gli stub (per il server e per il client). Per la specifica dei tipi di dati si definisce un file header che verrà incluso sia nel codice client che nel codice server. Per comunicare al portmapper la registrazione del programma server si usa l'istruzione Register_rpc( ) in cui sono specificate le procedure contenute e le versioni corrispondenti; sono anche specificati i filtri di codifica e decodifica (XDR). In questo modo il portmapper assegna una porta al programma server e invia informazioni ai client circa gli indirizzi assegnati al programma server. Dopo il Register_rpc( ), il server, con il comando Svc_run( ), si mette in ascolto sulla socket e aspetta le richieste del client. Con questa procedura il server verifica l'indirizzo e la versione del client, una volta accettata la sua richiesta. Il client deve solo richiamare una RPC con il comando Callrpc( ). Questo comando contiene il numero di porta dell'host remoto, il numero di programma e di versione settando il canale di comunicazione I/O per l'esecuzione in remoto della procedura richiesta. 8

9 Lower level RPC Nel Lower level RPC non è invece necessario inserire nel codice server e client i protocolli di trasmissione perché le relative funzioni sono implementate negli stub del server e del client. Gli stub vengono generati automaticamente dal compilatore di protocollo con il comando RPCGEN nomefile.x. Il file nomefile.x si scrive in un linguaggio simile al C, l RPCL (RPC Language) che fornisce le primitive per la definizione dei dati e delle procedure delle RPC. Si definiscono i tipi di dati utilizzati ( se non predefiniti), ed alcune informazioni proprie delle RPC quali il nome del programma, un numero e una versione di programma per i prototipi delle funzioni remote. Lower level ONC-RPC RPCGEN supporta entrambi i protocolli di trasmissione (TCP e UDP), permette più flessibilità nella stesura del codice client con un piccolo aumento di tempo di esecuzione dovuto ad una maggiore complessità dei programmi generati. Specifiche RPC nomefile.x Oltre agli stub (nomefile_clnt.c e nomefile_svc.c) viene generato anche un file header (nomefile.h) da far condividere al client e al server e un file contenente i filtri (contenuti in una libreria RPC) per la comunicazione tra i due processi (nomefile_xdr.c). Client stub nomefile_clnt.c Header nomefile.h RPCGEN Filtri XDR nomefile_xdr.c Server stub nomefile_svc.c Nel file nomefile_xdr.c sono specificate le procedure di conversione del formato dei dati, affinchè i processi client e server possano comunicare ( Marshalling dei dati). Questo perché client e server devono comunicare usando una rappresentazione di dati indipendente dalla macchina. ONC RPC usa un formato canonico per la rappresentazione dei dati ( XDR). Compilatore C Compilatore C Compilatore C Client stub nomefile_clnt.o Filtri XDR nomefile_xdr.o Server stub nomefile_server.o La compilazione del client avviene linkando il codice sorgente della procedura client (nomefile_client.c) con lo stub del client ed il filtro XDR e generando così l eseguibile client. Linker Programma client nome_client.o Client eseguibile nome_client Linker Programma server nome_server.o La compilazione del server avviene linkando il codice sorgente della procedura server (nomefile_server.c) con lo stub del server ed il filtro XDR, generando così l eseguibile server. Compilatore C Programma client nome_client.c Server eseguibile Nome_server Compilatore C Programma server nome_server.c 9

10 Il marshalling dei dati Il trasferimento dei dati tra i due processi (client e server) richiede la codifica e la decodifica del messaggio stesso. E questa l operazione che viene conosciuta come marshalling dei dati nei sistemi RPC. Nello standard ONC-RPC la codifica e la decodifica sono eseguite tramite dei filtri XDR (External Data Representation), i quali operano delle conversioni di tipo sugli argomenti delle procedure. Nel file nomefile_xdr.c sono contenute le definizioni dei tipi e delle costanti che vengono utilizzati. Tale file è generato sulla base di ciò che è specificato nel file nomefile.x. Tipicamente le operazioni di marshalling sono: acquisizione degli argomenti dal processo client, o dei risultati dal processo server, che formeranno i dati del messaggio da inviare al processo remoto, codifica dei dati del messaggio passati dal mittente, decodifica dei dati del messaggio sulla macchina ricevente. L'ordine e il metodo di rappresentazione usati per i risultati e gli argomenti devono essere conosciuti sia dal client che dal server. Il processo di marshalling deve riflettere le strutture di tutti i tipi di dati usati nel programma oggetto, includere i tipi di primitive, i tipi strutturati ed i tipi definiti dall'utente. Un buon sistema RPC può generare codice marshalling in linea per ogni chiamata remota, in tal modo l'utente è sollevato dallo scrivere le proprie procedure di marshalling. Ma in pratica è difficile realizzare questo metodo di RPC perché così si dovrebbe generare una grande quantità di codice per manipolare tutti i tipi possibili di dati. Esempio di applicazione ONC-RPC (realizzato da :Cozzolongo Giovanni e Spina Maria Antonietta) I due processi possono risiedere su macchine separate o essere situate sulla stessa postazione. Questo comunque non inficia sul buon funzionamento del sistema perché all avvio del processo client sarà necessario specificare il nome dell Host su cui è attivo il processo server, e le RPC trattano i due casi allo stesso modo. Al processo server sono affidati tutti i compiti relativi alla elaborazione dei dati; al processo client sono invece affidati i compiti relativi alla interfaccia con l utente. Ricerca.x rpcgen %#define DATABASE "archivio.txt" %#define HELP "help.txt" %#define MAXSTR 130 struct LINEA { string CORRENTE<MAXSTR>; int TROVATO; }; program ANALIZZA{ version ANALIZZAV{ LINEA ANALIZZA_GH (LINEA) =1; int APRIARCHIVIO (LINEA) =2; LINEA LEGGITESTO (LINEA) =3; }=1; }=0x ; Ricerca.h Ricerca_svc.c Ricerca_clnt.c Ricerca_xdr.c Server.c #include <rpc/rpc.h> #include <stdio.h> Client.c #include <stdlib.h> #include <stdio.h> #include <string.h> #include <stdlib.h> #include "ricerca.h" #include <string.h> /* dichiarazioni delle funzioni RPC */ #include <rpc/rpc.h> LINEA *analizza_gh_1(linea *gh); #include "ricerca.h" int *apriarchivio_1(linea *testo); void menu(char *); /* interfaccia utente*/ LINEA *leggitesto_1(linea *testo); void analisi(char *); /* ricerca nell'archivio */ /* procedura locale */ void elenca (char *,char *); /* visualizza l'archivio int */ ricerca(linea *gh); void chiamata (char *); /* crea l'handle e verifica FILE la presenza *fp=null; del server */ void stampa(char *,char); /* stampa i messaggi di FILE output *hp=null; */ static LINEA *result=null; CLIENT *cl=null; /* variabile che contiene l'handle per la comunicazione RPC */ /* MAIN *****/ main (argc,argv) int argc; char *argv[]; { char *server; server = (char *)malloc (sizeof (char *)); if (argc!=2) LINEA *tempgh=null; /* definizione di analizza_gh_1 */ LINEA *analizza_gh_1(gh) LINEA *gh; { if (!tempgh) {.. { fprintf(stderr,"sintassi: %s server \ninserire nome del server:\t", argv[0]); scanf("%s",server); } else (strcpy(server,argv[1]));... 10

11 RPC sincrono ed asincrono 2-12 a) Interconnessione tra client e server nellrpc tradizionale b) Linterazione mediante un RPC asincrono Dalla chiamata a procedura alla invocazione di metodi (O-O) Ad esempio RMI RMI è il meccanismo fornito da Java per invocare metodi di oggetti distribuiti su macchine virtuali diverse sparse sulla rete. Con l'rmi è possibile passare e ritornare oggetti in modo trasparente durante una chiamata a un metodo oltre che tipi di dati predefiniti.. RMI consente al programmatore di scrivere solo una volta il codice per implementare un oggetto che sarà immediatamente visibile sia al client (tramite la sua interfaccia) che al server (sul quale è implementato).. RMI permette sulle applicazioni distribuite l uso di thread da parte di un server RMI per garantire la gestione ottimale della concorrenza tra oggetti distribuiti. 11

12 Java Remote Object Invocation (RMI) Java RMI permette di eseguire classi di funzioni remote usando la stessa semantica delle function call locali Local Machine (Client) Remote Machine (Server) SampleServer remoteobject; int s; s = remoteobject.sum(1,2); 1,2 3 public int sum(int a,int b) { return a + b; } System.out.println(s); Remote Method Invocation RMI richiede l utilizzo esclusivo di Java come linguaggio di sviluppo e consiste in: un operazione di LOCALIZZAZIONE DI OGGETTI REMOTI mediante meccanismi di REGITRY degli oggetti, Un operazione di COMUNICAZIONE con gli oggetti remoti mediante funzioni di INVOCAZIONE dei metodi appartenenti ad oggetti remoti da parte dei client, Un operazione di CARICAMENTO delle definizioni delle CLASSI degli oggetti remoti: (Dynamic Code Loading) possibilità di scaricare il bytecode di una classe se la classe non è definita nella virtual machine del ricevente, mantenendo la definizione dei tipi e il loro comportamento Perche RMI? L obiettivo è di permettere ad una applicazione in esecuzione su una macchina locale di invocare i metodi di un oggetto in esecuzione su un altro computer. Si definisce client il programma chiamante che ottiene riferimento all oggetto remoto, server il programma che crea gli oggetti remoti. Tali applicazioni sono anche denominate distributed object application. Quali vantaggi? miglioramento delle prestazione complessive semplicità nella gestione delle risorse distribuite incremento della potenza operativa Ad es: suddivisione di una computazione pesante in procedure più piccole, eseguite tutte su macchine diverse diminuendo in tal modo il tempo complessivo di esecuzione 12

13 Componenti base dell RMI Client (Interfaccia) Server (Implementazione) Stub Skeleton Remote Reference Layer Remote Reference Layer Transport Layer (Connessione TCP/IP) Un client è dotato dell'interfaccia dei metodi disponibili sul server remoto, ma tutta l'implementazione è lasciata sul lato server. Nel programma client i dettagli dell'implementazione dei metodi remoti sono quindi invisibili. Ciò che realmente collega il client e il server in un sistema RMI è una connessione stratificata, trasparente agli sviluppatori, effettuata dal sottosistema RMI delle due macchine virtuali coinvolte. Lo Stub e lo Skeleton RMI Client Stub call skeleton RMI Server return Il client invoca un metodo remoto sul proprio stub. Lo stub è responsabile della spedizione del call remoto allo skeleton del server. Lo stub apre una socket con il server, facendo il marshalling (serializzazione) dei parametri ed inviando allo skeleton del server un data stream. Lo skeleton del server contiene un metodo per ricevere i remote call dai client, per deserializzare (unmarshalling) i parametri ed invocare limplementazione delloggetto remoto (a lui locale). 13

14 Architettura generale di RMI Il server deve innanzitutto registrarsi (bind ad un registry) Il client cerca il nome del server nel registry per stabilire i riferimenti remoti. Lo Stub serializza i parametri verso lo skeleton sul server localizzato. Lo Skeleton invoca il metodo remoto (locale al server) e serializza il risultato verso il client stub. Remote Machine bind RMI Server Registry skeleton return call lookup stub RMI Client Local Machine Architettura di RMI La struttura di un applicazione RMI è organizzata in strati orizzontali sovrapposti Simulazione locale sul client RMI Client Stubs Java Virtual Machine RMI Server Skeleton Oggetto reale eseguito sul server Il primo livello di questa connessione stratificata è rappresentato dagli stub (lato client) e gli skeleton (loto server) ai quali si riferiscono rispettivamente il client e il server senza occuparsi di ulteriori dettagli di più basso livello. Remote Reference Layer Transport Layer Connessione virtuale Connessione fisica Remote Reference Layer Transport Layer A loro volta gli stub e gli skeleton d e m a n d a n o l'esecuzione di ciascuna a t t i v i t à a l l o s t r a t o immediatamente sottostante: il remote reference layer (RRL) che gestisce i riferimenti delle variabili agli oggetti remoti, usando la connessione TCP/IP del Transport layer sottostante. 14

15 Architettura di RMI Lo strato più alto è costituito da applicazioni (client e server) eseguite dalla Java Virtual Machine. Lo stub e lo skeleton forniscono la rappresentazione dell oggetto remoto: lo stub gestisce la simulazione locale sul client e, agendo come proxy, consente la comunicazione con l oggetto remoto; lo skeleton invece consente l esecuzione dell oggetto remoto sul server. Il client esegue i metodi dell oggetto remoto in modo del tutto analogo alla chiamata locale: ris = OggettoRemoto. nomemetodo (par1, par2,..) senza preoccuparsi dei dettagli della comunicazione. Passaggio di parametri Qualsiasi classe, i cui oggetti devono essere trasmessi con una connessione RMI, deve essere dichiarata come tale indicando che deve implementare l'interfaccia java.io.serializable. Ogni parametro passato o ritornato da un metodo remoto deve essere o un oggetto di una classe primitiva Java, o un tipo di dato primitivo oppure un oggetto che implementa l'interfaccia java.io.serializable. Un client richiede al server un riferimento ad un oggetto usando lo stub sul lato client. Il server ottiene la richiesta dallo skeleton sul lato server. Tra i due c'è il remote reference layer che negozia le richieste convertendo gli oggetti in un formato trasmissibile attraverso la rete. Questa conversione è chiamata marshalling. Se i dati da trasmettere non sono né primitivi né serializzabili, lo stub lancerà un'eccezione MarshalException. Percorso dei parametri: Serializzati dalla Virtual Machine Inviati sotto forma di stream al server Deserializzati del server che li utilizza all interno del corpo del metodo invocato Il risultato segue il percorso inverso fino ad arrivare al client 15

16 La serializzazione Il meccanismo alla base utilizzato da RMI per la trasmissione dei dati fra client e server è quello della serializzazione che permette il flusso di dati complessi all interno di stream (può venir usata indipendentemente da applicazioni RMI). La serializzazione consiste nella trasformazione automatica di oggetti e strutture in sequenze di byte manipolabili coi vari stream del package java.io Gli stream sono associabili sia a socket che a file ad es: Record record = new Record() ObjectOutputStream oos = new ObjectOutputStream(myos) oos.writeobject(record); La serializzazione (2) Un oggetto è serializzabile se implementa l interfaccia Serializable Si possono serializzare oggetti con struttura e complessità arbitraria, senza particolari differenze, a patto che l oggetto sia serializzabile (implementi cioè l interfaccia Serializable) Ad es: public class Record implements Serializable{ private String Nome; public Record(String Nome){ this.nome = Nome } } La serializzazione è ricorsiva ( un oggetto serializzabile deve contenere oggetti serializzabili) La maggior parte delle classi del JDK è serializzabile (eccetto alcune che adottano strutture dati binarie dipendenti dalla piattaforma) 16

17 Gli strati RRL e TL Si occupano della gestione a basso livello ( all interno dell architettura RMI) della comunicazione. Il Remote Reference Layer (RRL) ha il compito di instaurare un connessione virtuale fra il client e il server ( esegue operazioni di codifica e decodifica dei dati). RRL adotta un protocollo generico e indipendente dal tipo di stub o skeleton utilizzato. Il Transport Layer esegue la connessione vera e propria tra le macchine utilizzando le specifiche standard di networking di Java, e quindi le socket con il protocollo TCP/IP. Il TL è quindi responsabile del controllo dello stato delle vari connessioni. Il TL si incarica di localizzare il server RMI relativo all oggetto remoto richiesto ed segue la connessione per mezzo di una socket. SVILUPPARE UN APPLICAZIONE RMI Così come altre applicazioni scritte in Java, un applicazione distribuita costruita con RMI è fatta sostanzialmente di interfacce e classi. Le interfacce dichiarano i metodi. Le classi implementano i metodi dichiarati nelle interfacce più altri metodi, se necessario. In una applicazione distribuita certe classi (implementazioni di metodi) possono non risiedere su una particolare macchina virtuale ma possono essere disponibili in remoto su altre macchine virtuali (oggetti remoti). Un oggetto diventa remoto implementando una interfaccia remota con le seguenti caratteristiche: Una interfaccia remota ESTENDE (extends) l interfaccia java.rmi.remote. Ciascun metodo dell interfaccia DICHIARA (declares) java.rmi.remoteexception nella sua clausola throws, oltre alle altre eccezioni specifiche della particolare applicazione. 17

18 SVILUPPARE UN APPLICAZIONE RMI Le classi e i metodi sono contenuti nei package java.rmi e java.rmi.server. Ø Disegnare ed implementare le componenti dell applicazione distribuita. Definire l interfaccia remota ( i metodi che possono essere invocati in remoto dai client ), con i tipi di oggetti che potranno essere usati (come i parametri e i valori di ritorno di questi metodi ) Implementare gli oggetti remoti che devono implementare una o più interfacce remote. Si definisce oggetto remoto un oggetto che implementi l interfaccia Remote i cui metodi possono essere eseguiti da un applicazione client posta su un altra macchina virtuale. Implementare il programma client. Ø Compilare i sorgenti con Javac (ed rmic con piattaforme Java antecedenti alla 5.0) e generare lo stub e lo skeleton. Ø Rendere accessibili in rete le classi (start dell RMI registry). Ø Start dell applicazione server e run del client. 18