Giampiero Allamprese 0000260193

PROGETTO DI UN MIDDLEWARE PER L’ACCESSO REMOTO A UN REPOSITORY

Reti di Calcolatori LS prof. Antonio Corradi

A.A. 2007/2008

ABSTRACT L’obiettivo di questo progetto è la realizzazione di un middleware che consenta di realizzare un servizio di accesso remoto a un repository da parte di utenti operanti in ambienti eterogenei e su piattaforme diverse. In particolare il caso concreto preso in considerazione come problema di partenza è quello della realizzazione di uno strumento con il quale un team di sviluppo software possa accedere al repository centrale in cui sono conservati i sorgenti dell’applicazione in via di sviluppo, reperire i file da modificare e ampliare e, dopo averlo fatto, salvarli sul repository stesso, secondo opportune politiche di interazione e sincronizzazione. Il progetto pone l’accento sulla realizzazione del middleware che garantisce la comunicazione tra gli utenti e il server centrale, garantendo politiche flessibili e intercambiabili e utilizzando un formato standard per la trasmissione di dati. La gestione in sé del repository, per quanto riguarda organizzazione di file e cartelle, replicazione dei dati e autenticazione è demandata al livello applicativo del server e non è trattata in questo progetto. INTRODUZIONE Uno strumento fondamentale per i progettisti di software delle moderne Software House consiste

nella possibilità di organizzare e memorizzare il codice prodotto man mano che si procede nello sviluppo di un’applicazione, in maniera efficiente e che consenta una corretta interazione da parte dei membri del team di sviluppo. La soluzione più immediata e diffusa è quella che prevede l’utilizzo di uno spazio disco (il repository appunto) su una macchina remota affidabile e sicura, su cui vengono mantenuti tutti i file di codice dell’applicazione, a cui i vari sviluppatori possono accedere per ottenere una copia dei sorgenti su cui lavorare localmente. Una volta modificati, i file dovranno poi essere salvati sul server aggiornando il contenuto del repository. Questo progetto vuole affrontare la problematica della realizzazione di un middleware di supporto che consenta di realizzare la comunicazione appena descritta tra utenti e server, consentendo di applicare in maniera flessibile politiche diverse di interazione e sincronizzazione, con la possibilità di operare in un ambiente eterogeneo sia per applicazioni sia per piattaforme. Lo scopo è quello di realizzare uno strumento modulare flessibile e interoperabile, al fine di implementare un generico servizio di accesso a un repository contenente dati utilizzabili da utenti diversi, senza necessariamente legarsi al caso specifico dello sviluppo di software. L’interoperabilità e la flessibilità nella configurazione delle politiche richiedono un

formato standard per la rappresentazione dei dati. Nella seconda sezione dell’articolo si analizzeranno le criticità principali del problema, nella terza sezione si descriveranno le scelte effettuate in fase di progettazione e la architettura prevista per il sistema, la quarta sarà dedicata all’implementazione e alla descrizione di un caso di prova. 2 CRITICITA’ DEL SISTEMA 2.1 Gestione flessibile dell’interazione

e della sincronizzazione Caratteristica fondamentale per la realizzazione di un sistema flessibile è la possibilità di configurarne il comportamento da parte dello strato applicativo superiore in tempo reale e in maniera semplice. In particolare in un sistema di questo tipo si possono immaginare diverse politiche di gestione dell’accesso al repository e di interazione tra clients e server. La soluzione più semplice è quella di tipo “lock – modify - unlock”, che prevede una gestione sequenziale dei singoli file: un utente richiede un sorgente, ne ottiene il lock,lo copia e lo modifica in locale e solo dopo avere aggiornato il repository rilascia il lock e consente ad altri di modificare quello stesso file. Naturalmente un approccio di questo tipo è logicamente semplice ed evita problemi di consistenza ma limita fortemente la parallelizzazione del lavoro. Una soluzione più efficace, ma anche molto più complessa è quella che prevede la possibilità per tutti di accedere allo stesso file e di modificarlo in parallelo, dopodiché l’applicazione di gestione del repository riceverà tutti i file aggiornati e cercherà di ottenerne un’unica versione tramite un’operazione di merging. Il middleware dovrà dunque supportare politiche di interazione e sincronizzazione diverse (non soltanto i due esempi presentati, naturalmente) in maniera semplice ed efficiente, e senza interruzione

di servizio, tenendo conto che suo compito sarà solo quello di garantire meccanismi di comunicazione adeguati alla politica scelta, lasciando poi all’applicazione lato server la responsabilità di implementarla logicamente (nel secondo esempio fatto il middleware dovrà solo fare in modo di consegnare all’applicazione le diverse versioni del file e sarà poi quest’ultima a effettuare il merging). Dovrà quindi essere presente nell’applicazione di gestione del repository un modulo con cui il middleware si possa interfacciare per inoltrare le richieste dei clienti e ottenere i file desiderati nel formato standard di comunicazione. 2.2 Modalità di comunicazione La comunicazione dovrà essere evidentemente di tipo client/server, in quanto l’architettura stessa di un repository ad accesso remoto è di questo tipo. Si può presumere che le primitive che lato client inoltrano le richieste al server siano bloccanti, in quanto l’applicazione che richiederà il sorgente che si trova sul repository non avrà altre elaborazioni da svolgere fino a quando non si sia reperito il file. D’altra parte volendo rendere il sistema flessibile e slegato dal caso specifico dello sviluppo software si può anche pensare ad un supporto che possa mettere a disposizione primitive che non blocchino l’applicazione che le invoca. Le richieste servite saranno poi caratterizzate da un diverso grado di difficoltà: richieste come l’ottenimento di un file in sola lettura o creazione di file e directory non pongono grandi problemi e possono essere gestite in maniera relativamente semplice; il servizio più complesso e problematico, invece, è quello che prevede di fornire all’utente un file a cui possano essere apportate modifiche che successivamente

dovranno essere salvate sul repository. Questa richiesta richiede una maggiore complessità di gestione a causa delle problematiche di sincronizzazione e consistenza che pone. In effetti le diverse politiche di gestione delle richieste implementabili nel middleware riguardano soprattutto la modalità con cui viene gestita questa particolare richiesta, in quanto le altre saranno gestite all’incirca sempre nello stesso modo. 2.3 Supporto all’interoperabilità Per garantire il supporto ad ambienti eterogenei sia a livello software che di piattaforma, è indispensabile che il middleware utilizzi un formato standard per la rappresentazione dei dati, con cui sistemi diversi possano scambiarsi dati e informazioni e con cui si possano anche implementare le politiche e la configurazione del sistema. E’ importante anche scegliere un linguaggio di programmazione con cui implementare il servizio che sia indipendente dalla piattaforma e portabile. 2.4 Affidabilità Per garantire una adeguata affidabilità del sistema e la possibilità di fornire il servizio senza interruzioni sarà necessario prevedere la possibilità di replicare il server che riceve le richieste dei client. La gestione dell’affidabilità del servizio di repository vero e proprio (ad esempio la possibilità di utilizzare un file system distribuito e replicato, di rendere il servizio accedibile da diversi nodi, ecc..) viene demandata invece all’applicazione. 3 ARCHITETTURA DEL SISTEMA 3.1 Formato dati Come formato standard per la comunicazione dei dati e la definizione dei

file di configurazione si è scelto XML, per la diffusione e la comodità offerta. Come linguaggio invece si è scelto il Java per le sue caratteristiche di portabilità e la diffusione anche in ambienti mobili. 3.2 Server File di configurazione Il server conterrà un file di configurazione in formato xml, tramite il quale verranno specificate informazioni necessarie alla corretta fornitura del servizio. In particolare saranno specificate: − La politica di fornitura del servizio

(ad es. Lock-Modify-Unlock) − I parametri fondamentali per la

comunicazione, quali tempi di timeout e numero di ritrasmissioni

− Il percorso delle cartelle in cui salvare i file xml ricevuti dai client e dall’applicazione di gestione del repository

− Il nodo su cui si trova l’applicazione a cui inoltrare le richieste.

− Un parametro che indichi la presenza di un proxy, seguito da informazioni sul nodo in cui si trova

Modificando il file di configurazione si otterrà una modifica in tempo reale del comportamento del server. All’arrivo di ogni richiesta da parte degli utenti, infatti, l’applicazione accederà al file xml per verificare con quale politica dovrà essere gestita e con quali parametri di comunicazione, adattando il proprio comportamento in maniera completamente dinamica. La specifica del nodo su cui si trova l’applicazione di gestione del repository è essenziale a causa della replicazione del server di comunicazione; se infatti il server principale non è attivo e si utilizza una copia, l’applicazione potrebbe non

essere più accedibile in locale, ma solo tramite un riferimento remoto. Naturalmente se l’applicazione prevede anch’essa una replicazione sugli stessi nodi in cui è replicato il server del middleware, si potrà continuare ad interagire con essa in locale, senza bisogno di accessi remoti. L’indicazione della presenza o meno di un proxy, è invece necessaria per far sì che il sistema possa supportare con facilità sia la presenza di un proxy, e la conseguente replicazione del server, sia una comunicazione diretta tra client e server. Fornitura del servizio All’arrivo di una richiesta da parte di un client il server analizzerà il proprio file di configurazione per capire come deve essere gestita. successivamente inoltrerà la richiesta al modulo di interfaccia dell’applicazione superiore fornendo il file xml contenente il profilo dell’utente necessario per la procedura di autenticazione e specificando il file richiesto o invato dall’utente. In caso di richiesta di un file da parte dell’utente, dopo averlo ottenuto già tradotto in formato xml, sarà inviato al client. Se il file era invece stato inviato dall’utente si manderà semplicemente la conferma dell’avvenuta operazione. 3.3 Client Profilo utente Sul client saranno presenti due file xml: un primo contente il profilo dell’utente che vuole effettuare una richiesta al repository, e un secondo di configurazione. Il file di profilo non è strettamente necessario ai fini delle operazioni svolte dal middleware, ma si è ritenuto comunque indispensabile prevedere uno strumento di questo tipo, poiché è evidente che per l’applicazione di gestione del repository è necessario sapere quale utente richiede una determinata operazione per capire se

è autorizzato a compierla e se devono essere utilizzate particolari preferenze legate a quello stesso utente. Il profilo, quindi, conterrà le informazioni necessarie all’identificazione dell’utente e all’autenticazione da parte del gestore del repository. Nel file di configurazione, invece, saranno specificati tutti i dati necessari alla comunicazione (indirizzo del server, tempi di timeout, percorso delle cartelle dei file temporanei, ecc…) Per il profilo si è scelto di utilizzare un file xml, che verrà poi inviato al server insieme alla richiesta del file, per rendere l’applicazione il più possibile flessibile e adattabile. Se infatti il protocollo di autenticazione richiedesse nuove e diverse informazioni da parte dell’utente non sarebbe necessario riscrivere le classi del middleware ma basterebbe cambiare e aggiornare il contenuto del file di profilo. Comunicazione Il client metterà a disposizione dell’utente diversi tipi di richieste per il repository: − Richiesta di file in sola lettura − Richiesta di file da modificare − Richiesta di creazione di nuovi file o

cartelle Allo stesso modo, poi, con cui il server può dinamicamente modificare la politica con cui gestire le richieste che gli arrivano, il client può definire modalità diverse per inoltrare le richieste (ad es. può essere preferibile avere a disposizione primitive che non blocchino l’applicazione esterna che le ha chiamate). Basterà indicare nel file di configurazione la modalità scelta e il sistema automaticamente la utilizzerà. 3.4 Proxy Per gestire la replicazione volta a garantire l’affidabilità e la disponibilità

del sistema si è deciso di utilizzare un pattern Proxy. Sarà dunque presente un’entità intermedia a cui i client si rivolgeranno, che identificherà tra un insieme di server replicati quello da utilizzare per ottenere il servizio. Anche il proxy, dunque, avrà un suo file di configurazione in cui saranno elencati i vari nodi su cui cercare un server attivo, a partire da un server principale, che tendenzialmente ma non necessariamente sarà quello che si trova sullo stesso nodo dell’applicazione di gestione del repository. La replicazione quindi prevede un modello Master/Slave, con un’unica copia attiva, e una serie di copie di riserva pronte a sostituire il server principale in caso di problemi. Il modello è quello di un sistema di replicazione a copie fredde. Si è deciso di effettuare questa scelta poiché a seconda della politica utilizzata dal server le informazioni di stato da trasmettere cambierebbero, e sarebbe eccessivamente oneroso implementare una soluzione in grado di supportare tutte le possibilità. Inoltre va considerato che le informazioni di stato interesserebbero solo le richieste di ottenimento e modifica dei file, mentre le altre possono essere eseguite immediatamente e senza particolari accorgimenti da parte del server; dunque solo una parte delle richieste ricevute sarebbe realmente interessata a una aggiornamento dei server in standby. Un accorgimento fondamentale è che il server, nel caso in cui salti solo il collegamento col proxy, ma sia comunque in grado di servire eventuali richieste in coda, si renda conto immediatamente di non essere più il master, in modo da interrompere le richieste rimaste da servire. Queste potranno essere perciò reinoltrate al proxy dal client e girate al master attualmente funzionante con una minima perdita di priorità. Ciò limiterebbe fortemente i danni provocati dalla caduta del server,

rendendo quindi la soluzione a copie fredde non eccessivamente penalizzante. All’arrivo di una richiesta da parte del client, quindi, il proxy tenterà di contattare il server principale, e in caso di mancata risposta proverà uno dopo l’altro tutti i server di riserva. Trovata una copia attiva comunicherà all’utente l’indirizzo al quale connettersi. Il server, a sua volta, al termine di ogni operazione di get+commit interrogherà il proxy per verificare di essere ancora il master, e in caso contrario potrà tempestivamente cancellare le richieste rimaste. 4 IMPLEMENTAZIONE Il sistema è stato suddiviso in tre package principali: client, server e proxy, ognuno dei quali contiene le classi utilizzate dai relativi attori della comunicazione. Inoltre è stato realizzato un ulteriore package tools, contenete classi che implementano funzionalità di base utilizzate da tutti gli altri package. 4.1 CLIENT La struttura del client può essere analizzata a partire dal diagramma delle classi riportato di seguito in Figura 1. La classe principale, ClientComunicator, contiene tutte le primitive con cui un’applicazione di livello superiore può inoltrare richieste a un repository remoto. Per gestire le richieste dell’utente il ClientComunicator si appoggia alla classe ClientBlockComManager, che implementa effettivamente il protocollo di comunicazione con il server, appoggiandosi a sua volta alla classe SendReceive del package tools che realizza le primitive di comunicazione di base.

Figura 1 L’aver incapsulato tutto il protocollo di comunicazione del middleware lato client in questa classe fa sì che se si volesse realizzare un diverso protocollo, oppure lo stesso protocollo con modalità diverse (ad esempio usando il pattern poll object si potrebbe avere una soluzione non bloccante), sarebbe possibile farlo senza modificare le altre classi. La dinamicità del sistema descritta prima, per cui specificando una modalità di gestione delle richieste nel file di configurazione questa viene applicata in tempo reale, deriva proprio dal fatto che è sufficiente realizzare più di una classe di questo tipo e che il ClientComunicator interrogando il file xml capisca quale deve utilizzare. Per questo è stata definita l’interfaccia ClientComManager che indica quali primitive devono realizzare classi di questo tipo, lasciando però, ovviamente, completa libertà sul come realizzarle. Il sistema una volta letto il file xml creerà a tempo di esecuzione un’istanza di una classe il cui nome è definito dalla seguente notazione: “Client’valore letto nel file xml’ComManager”. Nel progetto sviluppato la classe ClientBlockComManager realizza il protocollo di comunicazioni con primitive bloccanti per l’applicazione che invoca i metodi del ClientComunicator. Le altre due classi del package servono per la lettura dei dati contenuti nel file di configurazione: la classe ClientConfig incapsula tutte le proprietà indicate nel file

e i relativi valori; la classe ClientXmlManager, invece, realizza il metodo readXml() con cui si accede al file xml e si aggiorna il contenuto della classe ClientXmlManager. Per fare questo si utilizzano i metodi della classe statica XmlFileReader contenuta nel package tools, che consente di accedere a un file xml e leggerne il contenuto, grazie alle librerie jdom importate nel progetto che rendono l’operazione molto più semplice rispetto alle funzionalità offerte dalle normali classi Java. Il file di configurazione del client avrà questo formato:

4.2 SERVER La struttura del server è rappresentata dal diagramma delle classi presentato in Figura 2.

Figura 2 La classe principale in questo caso è ServerComunicator, che realizza il pattern Singleton dal momento che si vuole che ci sia un solo server attivo su un nodo. Questo oggetto nel proprio costruttore fa partire il thread ServerAcceptThread, che si incarica di creare la ServerSocket in ascolto e tramite una accept ottenere le socket di connessione con i vari client. Prima di passare la gestione delle richieste alle classi sottostanti, però, viene effettuata una prima receive sulla socket appena creata per capire se si è in contatto con un client o con un proxy. In quest’ultimo caso il proxy vorrà semplicemente verificare se il server è online e farlo diventare il master se non lo è già, e quindi sarà sufficiente rispondere in maniera affermativa, senza delegare il compito ad altre classi. Le richieste del client, invece, vengono gestite da un oggetto della classe ServerLMUComManager. Come nel caso del client, poiché si vogliono poter realizzare diverse politiche di gestione delle richieste, queste sono incapsulate all’interno di una classe e dei thread che questa fa partire. La classe viene identificata dal file di configurazione e creata dinamicamente proprio come prima. In questo caso si è deciso di implementare una politica di gestione delle richieste di tipo lock-modify-unlock.

La classe ServerLMUComManager identificherà l’operazione richiesta dal client e invocherà due differenti Thread per la loro gestione. Il ServerFileFolderThread si incaricherà delle richieste di file in sola lettura, e di creazione di file o cartelle. Queste operazioni non sono particolarmente complesse da gestire e saranno servite immediatamente creando un thread per ogni richiesta ricevuta. Il ServerCommitThread, invece, dovrà gestire le richieste di file da modificare, che, secondo la politica che si vuole implementare, dovranno essere rigidamente sequenzializzate. Dunque verrà creato un Thread diverso non più per ogni richiesta, ma per ogni file richiesto, in modo che se un client richiede un file che già un altro utente sta modificando, la sua richiesta verrà accodata e servita dal thread dopo che il client precedente avrà fatto l’operazione di commit. La coda di richieste da servire è implementata da un oggetto della classe ServerQueue. Tale oggetto contiene al suo interno un vettore di stringhe che identificano i file attualmente gestiti da un thread, e dunque in fase di modifca da parte di un client; inoltre, per ogni file memorizzato sarà mantenuto un vettore di prenotazioni, rappresentate dalla classe Booking, che conterranno tutte le informazioni necessarie e la socket da usare per la gestione della richiesta quando sarà il suo turno. Naturalmente l’oggetto ServerQueue deve essere unico nell’applicazione e tutti si suoi metodi saranno synchronized poiché accedibili da più thread contemporaneamente. Ovviamente una politica di tipo lock-modify-unlock richiede che sia definito un tempo massimo di possesso da parte di un utente del diritto di modifica di un file. Scaduto questo tempo la richiesta sarà annullata e si passerà alla gestione della richiesta successiva in coda, se presente.

Per fare ciò il ServerCommitThread, all’inizio di ogni gestione di una richiesta di file attiva un TimeoutThread che, scaduto il valore di timeout specificato nel file di configurazione, avvertirà il thread di gestione che interromperà l’attesa della commit. Al termine dell’operazione di commit, inoltre, il thread proverà a contattare il proxy per verificare di essere il master, in modo che, in caso di risposta negativa, possa interrompere la richiesta servita e mettersi in standby. Le richieste rimaste in coda verranno quindi tempestivamente cancellate e potranno, se riproposte dai client, essere accodate al nuovo master senza perdere troppa priorità Infine per far sì che ogni server rimanga in standby fino a quando il proxy non lo indica come master si usa la classe statica Go, il cui valore è di default false, e viene messo a true solo in caso di ricezione di un messaggio da parte del proxy. Per ultimo va notato che la realizzazione della classe di interfacciamento con l’applicazione che gestisce il repository viene demandata all’applicazione stessa, che si incaricherà anche della traduzione da e in xml dei file. Il sistema definisce semplicemente un’interfaccia, ServerApplInterface, che indica quali metodi devono essere implementati da questa classe. Essa sarà acceduta in locale se l’applicazione si trova sullo stesso nodo del server, altrimenti si utilizzerà rmi come sistema di riferimenti remoti. 4.3 PROXY Il diagramma delle classi del proxy è il seguente:

Figura 3 Anche in questo caso la classe principale, Proxy, è un singleton. Essa farà partire due thread: ProxyAcceptThread è incaricato della gestione delle richieste dei client, mentre ProxyAcceptSrvThread gestirà quelle dei server. Innanzitutto l’elenco dei server disponibili viene letto dal file di configurazione e inserito in un oggetto di tipo ProxyServerList. Esso è unico per tutto il proxy e al suo interno sono indicati il master originario, il master attuale, i server che risultano online, e quelli che risultano offline. Quando un client inoltra la propria richiesta essa viene raccolta dalla classe ProxyAcceptThread, che effettuata la accept invocherà un ProxyQueryThread che si incaricherà di verificare che il server che risulta come master sia attivo. Se così non è verranno prima provati tutti i server online e poi quelli offline fino a quando non ne verrà trovato uno correttamente funzionante. In questo caso si invierà al client l’indicazione dell’indirizzo al quale connettersi, aggiornando il master se è cambiato e inserendo nella offline list tutti i server che non hanno risposto.

Se nessun server ha risposto viene inviato al client un messaggio di errore che faccia terminare la funzione invocata senza aspettare lo scadere del timeout. Il ProxyAcceptSrvThread, invcece, resterà in attesa di richieste di connessione da parte dei server che alla fine di un’operazione di commit vogliono verificare di essere il master. Se così non è il thread verificherà comunque che il server sia almeno nell’elenco dei server online, dato che evidentemente è funzionante. La comunicazione tra client, proxy e server potrà dunque essere schematizzata con il seguente diagramma:

Prima di tutto il client contatta il proxy, il quale identificato un server funzionante lo setta come master, lo fa partire e ne restituisce l’indirizzo al client. Questo a sua volta riproporrà la richiesta al server il quale risponderà con un acknowledge. A questo punto il client invierà il proprio profilo utente, e ricevuto un ulteriore acknowledge rimarrà in attesa del file richiesto o invierà il file modificato a seconda dell’operazione che deve eseguire.

5 SVILUPPI FUTURI Possibili sviluppi futuri per il middleware possono essere l’implementazione di altre politiche di gestione rispetto a quelle implementate per il client e per il server. Si può inoltre pensare di sviluppare anche una serie di funzionalità che consentano di gestire la problematica dell’autenticazione e della gestione dei diritti, demandati qui a livello applicativo. Inoltre si può anche pensare ad un maggiore coordinamento tra server per realizzare un sistema a copie calde se lo si ritenesse indispensabile per una aumento delle prestazioni. 6 CONCLUSIONI Si è realizzato un middleware che consente la comunicazione tra una serie di client e un servizio di repository remoto, per soddisfare diverse tipologie di richieste. Il sistema presentato garantisce un utilizzo flessibile e interoperabile e permette grazie alla sua modularità di essere significativamente espanso in futuro, aggiungendo nuove politiche e modalità di gestione che potranno essere integrate facilmente semplicemente configurando gli opportuni file di configurazione. Si è inoltre anche realizzata una replicazione del server di comunicazione per garantire una buona affidabilità del sistema grazie ad un proxy in grado di dirigere la richiesta dell’utente verso un server funzionante.