Scarica Paradigma della programmazione distribuita: Java RMI e più Sbobinature in PDF di Ingegneria del Software solo su Docsity!
Capitolo 1
Java RMI: Programmazione distribuita
1.1 Paradigma di programmazione degli oggetti distribuiti
A differenza della programmazione orientata agli oggetto dove gli oggetti con i suoi metodi potevano essere invocati solo localmente quando parliamo di programmazione distribuita ad oggetti, vogliamo dire che gli oggetti con i suoi metodi possono essere invocati remotamente dunque, non per forza devono essere presenti sulla nostra macchina ma, possono trovarsi anche su altre macchine. Naturalmente, deve esistere una connessione tra chi invoca il metodo remotamente e chi lo fornisce
Le risorse disponibili in una connessione di rete sono viste come oggetti distribuiti dove: i metodi relaviti ad un oggetto distribuito sono detti metodi remoti; se, invece, si fa riferimento ad un oggetto locale parleremo di metodo locale
1.1.1 Architettura di un sistema a oggetti distribuito
L’architettura utilizzata per rendere possibile la programmazione distribuita si basa su una architettura client - server composta, in particolare, da tre elementi fondamentali: Object Client, Object Server e, Object Registry Dal punto di vista logico abbiamo che:
- Gli oggetti distribuiti sono resi disponibili ai vari processi Object Client, dall’Object Server il quale, per rendere disponibile un oggetto remotamente deve effettuare l’operazione di register dell’oggetto sull’Object Registry, così che l’Object Registry possa mantenere il riferimento all’oggetto remoto
- L’Object Client dal suo lato, per poter accedere ad un oggetto remoto deve contattare l’Object Registry ed effetturare un operazione, detta di lookup, per ottenere il riferimento all’oggetto remoto, da cui potrà invocare i suoi metodi
L’invocazione di un metodo in un sistema distribuito è detta: Remote Procedure Call (RPC) dove, la chiamata è invocata da un processo all’altro e, i dati sono passati come argomenti della procedura. Ciò che accade fisicamente nell’architettura è:
- Lato Client:
- Il Client invoca il metodo sull’oggetto remoto, come se fosse un metodo locale
- La chiamata del metodo è gestita da un componente chiamato Client Proxy che, interagisce con il software del Client attraverso il Runtime support
- Il Runtime support gestisce la chiamata e, effettua anche il marshalling, il meccanismo di passaggio dei parametri all’oggetto remoto
- La richiesta passa per la rete di comunicazione attraverso il Network support
- Lato Server:
- La richiesta viene gestita grazie al Runtime support del server
- Viene effettuato l’unmarshalling dei parametri inviati
- La richiesta viene inoltrata al Server Proxy il quale, comunica con l’oggetto remoto e, invoca il metodo richiesto con i parametri ricevuti
Marshalling e Unmarshalling
Le operazione di marshalling e unmarshalling sono fondamentali per il paradigma della programmazione distribuita infatti, l’operazione di marshalling consente di trasformare i dati da traferire in un flusso di byte che può viaggiare sulla rete mentre, l’operazione di unmarshalling non fa altro che l’operazione contraria permette, preso il pacchetto di risalire ai dati
1.2 Java RMI
L’obbiettivo di Java RMI è quello di estendere il modello Java Object per supportare la programmazione con oggetti distribuiti, rendendola più semplice possibile. I principali componenti che Java RMI utilizza sono:
- Remote Objects: corrispondono a normali oggetti java ma, la loro classe estende le classi RMI che contengono il supporto per l’invocazione remota
- Remote references: sono i rifermenti agli oggetti remoti contenuti nelle macchine remote
- Remote interfaces: corrispondono a normali interfacce java ma, vogliono specificare un oggetto remoto e, per far questo devono estendere l’interfaccia marker di java.rmi.Remote
Per supportare la programmazione distribuita, java RMI fa uso di tecnologie di supporto quali:
- Registries: i registri sono il posto in cui la macchina locale cerca i rifermenti agli oggetti remoti
- Serializzazione: per fare in modo che i processi remoti possano scambiarsi dati e risultati, è necessario seria- lizzare gli oggetti. La serializzazione è necessaria per effettuare le operazioni di marshalling e unmarshalling dei parametri da passare ai metodi remoti
- Caricamento delle classi dinamico: questa tecnologia, permette di poter carica dinamicamente una classe non nota al nostro processo ma, di cui ha bisogno; in questo modo, la classe sarà caricata dinamicamente e, il nostro processo avrà tutte le informazioni necessarie per continuare la sua esecuzione
- Security manager: è un meccanismo usato per controllare il comportamento del codice caricato da un host remoto prevenendo cose non autorizzate; essendo un sistema distribuito, la sicurezza ricopre un ruolo importante
Si nota, come Java RMI è basato sulle interfacce. Tutti gli oggetti remoti devono implementare l’interfaccia ja- va.rmi.Remote. L’interfaccia risiede lato Client mentre, lato Server abbiamo l’implementazione infatti, è sul server che viene eseguito il programma
1.2.4 Linee guida per la costruzione di un sistema Java RMI
Componenti
- Interfaccia remota e, sua implementazione
- Un server che ospiti gli oggetti remoti
- Un servizio RMI per la pubblicazione degli oggetti remoti
- Un programma client che usi il servizio offerto dal server
Implementazione
- Definire l’interfaccia remota L’interfaccia remota deve soddisfare i requisiti di: - Estendere l’interfaccia java.rmi.Remote - Dichiarare i suoi metodi includendo la clausola throws con l’eccezione java.rmi.RemoteException
- Implementazione dell’interfaccia remota L’implementazione deve prevedere oltre a fare l’implements dell’interfaccia remota creata precedentemente, di fare anche l’extends della classe UnicastRemoteObject. Il costruttore dell’implementazione deve richiamare al suo interno: super();
- Creare il Server Si tratta di una Java Application che crea una o più istanze di oggetti remoti e, li associa all’RMI registry tramite il metodo Naming.rebing("...")
- Creare il Client Il Client, ottiene il riferimento ad un oggetto chimando il metodo Naming.lookup("...", ricevendo lo stub dell’oggetto remoto quindi, richiama i metodi direttamente sul riferimento
1.2.5 Meccanismo di CallBack
In alcune architetture RMI può essere utile rendere il Client anche un Server, così che il Client non possa accedere ad oggetti remoti ma, possa anche caricare dei propri oggetti sull’RMI registry. Il meccanismo è detto CallBack, in particolare, si fa uso delle Cliet CallBack, ciò permette al Client di essere notificato da un server per un evento che il Client stesso aspettava; questa notifica non è altro che l’invocazione da parte del Server di un metodo remoto sul Client.
Per far ciò, lasciare che il Client estenda la classe java.rmi.server.UnicastRemoteObject sarebbe poco opportuno quindi, l’oggetto del Client viene reso "remoto" chiamando il metodo statico UnicastRemoteObject.exportObject(obj)
Per rendere disponibile il meccanismo è necessario:
Lato Server
Mantenere un riferimento al Client sul quale effettuare il CallBack quindi, oltre a fare tutto ciò che facevamo prima per il server, bisogna aggiungere, tra i metodi remoti quello che il client invocherà per inviare il riferimento sul quale verrà fatta la callback
Lato Client
Bisogna fornire il metodo remoto che il Server invocherà per eseguire la CallBack. Quindi:
- Si definisce l’interfaccia remota sul Client nella quale si dichiarerà il metodo invocato dal Server per eseguire la callback; naturalmente, l’interfaccia estenderà java.rmi.Remote
- Si implementa l’interfaccia remota del Client, implementanto il metodo remoto
- Nell’esecuzione, si dovrà creare un’istanza dell’interfaccia remota del Client che sarà poi passata al server, su cui potrà eseguire la callback
1.2.6 Sicurezza
Per quanto riguarda un sistema distribuito, la sicurezza riguarda un argomento molto importante perché la macchina Client dovrà fare il download di codice per avere lo stub di oggetti remoti Tutti i vari download sono gestiti e controllati da un Security manager che agisce le rispetto di policy specificate in un file di testo chimato security policy. In tal modo il security manager controlla il codice dello stub e ne verifica che rispetta le regole stabilite nel file di policy prima di scaricare il codice
File di policy
Il file di policy usato in RMI specifica quale codice scaricato da un codebase è permesso per il download. Un codabase è un’insieme di classi che servono per accedere ad un oggetto remoto, che quindi, devono essere scaricate se si fa uso di quell’oggetto. Il file di policy può essere settato direttamente dal codice del programma tramite il metodo System.setProperty()
Il file è composto da blocchi di grant e, ogni blocco di grant specifica i permessi per un codebase Es. grant{...}
Security Manager
Se il security manager non viene settato, il file di policy viene ignorato. Quindi, è importantissimo settare il security manager. Il security manager può essere dichiarato esplicitamente nel codice usando il metodo System.setSecurityManager(new RMISecurityManager()) e, ciò deve essere fatto in tutte le applicazioni che hanno bisogno di scaricare codice
1.2.7 Dinamic Class Downloading
Una caratteristica della piattaforma Java RMI è la possibilità di scaricare dinamicamente il codice di delle classe ed eseguirle. Il codebase di classi da scaricare sono identificate da un URL, attraverso esso si specifica il percorso da seguire per scaricare il codebase. Una volta noti i file bisogna assicurasi che essi siano disponibili al class loader di ogni JVM
Ciò è fatto normalente in una applicazione RMI per scaricare i file delle classi di supporto all’applicazione per gli oggetti remoti, di cui il Client non ne conosce l’esistenza
Nelle ultime versione, i progettisti RMI hanno esteso il concetto di class loading, includendo il caricamento di classi da server HTTP; l’URL del codebase è quindi definito in modo tale da specificare dove si trovano le classi di cui ha bisogno la JVM
1.2.8 Distributed Garbage Collector
Come era stato introdotto un garbage collector per la versione standard di java, che permette di liberare spazio di memoria occupato da dati non più utilizzati, anche nella versione RMI è stato fornito un distibuted garbage collector
Il Distributed garbage collector è basato sulla tecnica del reference counting. In questo caso, è il Server a mantenere il conteggio dei riferimenti mentre, compito del Client è quello di avvertire quando stabilisce un riferimento ad un oggetto e, poi quando si libera di quel riferimento. Il DGC è esso stesso un server che implementa l’interfaccia remota java.rmi.dgc. L’interfaccia offre due metodi:
- dirty(), invocato dal Client quando richiede il riferimento ad un oggetto remoto; in questo caso il server incrementa il contatore
- clean(), invocato dal Client quando non utilizza più un riferimento ad un oggetto remoto; in questo caso il server decrementa il contatore
Quando il contatore di un oggetto si azzera vuol dire che l’oggetto remoto sarà libero da qualsiasi Client; l’oggetto viene messo nella weak reference list per poi essere eliminato
