• si riducono le dipendenze del servizio, facilitando il deployment;
• si necessitano meno interventi su un eventuale firewall, che deve consentire la comunicazione nelle sole porte usate direttamente dal servizio;
• si ha una maggiore flessibilit`a del sistema di scambio dati, come dimostra la possibilit`a di implementare un protocollo per l’update propagation di tipo pull2.
CAPITOLO 4
Integrazione di Sw/Attachments in CONStanza
4.1
Modifiche apportate a CONStanza
Prima di analizzare il lavoro di integrazione della tecnologia Sw/A come meccani-smo di trasporto di file nel servizio di consistenza per dati replicati CONStanza, verr`a fornito l’insieme delle modifiche ed integrazioni al codice di CONSTanza che sono state necessarie nella fase di implementazione. Alcuni concetti chiave per la presente trattazione saranno poi ripresi ed ampliati nel seguito di questa sezione.
Moduli Di tutti i moduli di CONStanza, `e stato necessario modificare in preva-lenza il LRCS. Modifiche minori sono state effettuate sui DBWatcher per adeguare le URI propagate per le update unit al particolare meccanismo di trasferimento utilizzato (Sw/A e GridFTP). Per come `e stata progettata l’interazione tra i moduli in CONStanza, `e stato possibile implementare il meccanismo Sw/A senza modificare in alcun modo il modulo GRCS;
Client e server Prima di implementare lo scambio di file via Sw/A, il componente LRCS era sia un server SOAP a s´e stante, sia un client SOAP del modulo GRCS. Dal momento che diviene poi necessaria la comunicazione SOAP diretta tra LRCS, questi dovranno integrare funzionalit`a di client LRCS;
per includere i metodi direttamente coinvolti nello scambio di dati. `E stato inoltre necessario inserire alcuni metodi locali che offrissero l’accesso ad alcuni parametri del server LRCS, ad esempio per informare il DBWatcher del nodo master di quale fosse la porta TCP usata dal LRCS locale ai fini della costruzione delle URI delle update unit.
4.2
Struttura interna di CONStanza
In questa sezione si analizzeranno i dettagli implementativi di CONStanza rile-vanti ai fini dello sviluppo del meccanismo di trasferimento file via SOAPw/Atta-chments da utilizzare all’interno del servizio di consistenza dati CONStanza. In particolar modo ci si concentrer`a sui meccanismi di comunicazione e sulle entit`a coinvolte.
4.2.1 Comunicazione via SOAP
Come gi`a detto, CONStanza si basa su gSOAP per creare il sistema di comunica-zione tra i moduli. Il linguaggio di programmacomunica-zione utilizzato `e prevalentemente il C++, con una strutturazione del codice secondo il paradigma Object Orien-ted. Come visto nella sezione 2.4.3, gSOAP pu`o produrre gi`a del codice utile per l’implementazione ad oggetti di un sistema di comunicazione via gSOAP: in particolare, a partire dalle definizioni dei prototipi dei metodi da invocare via SOAP e degli eventuali tipi di dato utilizzati, il preprocessore soapcpp2 produce una classe Proxy ed una classe Object.
La classe Proxy `e uno stub, ovvero un modulo software utilizzato dai client del servizio per avere l’interfaccia usata dal server. In particolare la classe Proxy definisce, nel costruttore, l’inizializzazione dell’ambiente gSOAP e una serie di
metodi, ognuno dei quali collegato ad un metodo invocabile via SOAP. La classe Proxy`e progettata per essere estendibile: tutti i metodi ad eccezione del costrut-tore sono dichiarati virtual.
La classe Object `e invece uno skeleton, ovvero un prototipo compilabile che per-mette la creazione di un server SOAP a s´e stante. Essenzialmente implementa l’inizializzazione dell’ambiente SOAP e le principali funzioni di gestione di una connessione TCP. L’header che contiene lo skeleton possiede, al di fuori della classe, tutte le dichiarazioni delle funzioni del server richiamabili via SOAP, da implementare separatamente. Anche la classe Object `e progettata per essere este-sa da un’altra classe: tutti i suoi metodi, a parte il costruttore, sono dichiarati come virtual.
Questa impostazione `e utilizzata dai due moduli principali di CONStanza, ovvero GRCS ed LRCS, all’interno del proprio core, che implementa tutte le funziona-lit`a server side, e una API, utilizzata per la creazione di client, di cui molti sono distribuiti contestualmente a CONStanza.
4.2.2 Struttura delle classi
Per i moduli GRCS ed LRCS sono state create delle gerarchie di classi che, a partire dagli stub e skeleton prodotti da gSOAP, implementano la logica dei pac-kage core e API, citati in precedenza, e del pacpac-kage comm che si occupa della gestione del framework di comunicazione. Nelle gerarchie di classi e nel resto dell’applicazione, si distingue tra le componenti relative alla sola infrastruttura di comunicazione e quelle che implementano anche della logica applicativa. I nomi utilizzati sono indicativi per questa suddivisione, che vede le componenti per l’infrastruttura di comunicazione aventi prefisso o infisso WRCS per il modulo
GRCS e WLRCS per il modulo LRCS. La “W” sta ad indicare “Web interface”. La struttura indicata di seguito prende in esame il modulo LRCS, ma risulta altrettanto valida anche lato GRCS, ove non specificato espressamente.
4.2.3 Server side
L’infrastruttura di comunicazione SOAP si basa sulla classe WLRCS, contenuta nel file lrcsWLRCSObject.h prodotto dal preprocessore gSOAP, e sull’implementa-zione delle routine invocate automaticamente dal framework gSOAP tramite un meccanismo di callback. Queste ultime risiedono nel file WLRCS.cc incluso nel package comm. A questo punto sarebbe gi`a possibile avviare un server SOAP standalone tramite la classe WLRCS: questa infatti possiede tutte le funzionalit`a richieste ad un server TCP (bind, accept, ...). Questa quale accetterebbe i mes-saggi SOAP in ingresso richiamando tramite callback le funzioni contenute in WLRCS.cc. Per gestire meglio il server `e stata per`o racchiusa tutta la logica ap-plicativa server side all’interno di una classe, chiamata LRCS, avente una funzione membro per ogni servizio accessibile all’esterno via SOAP. In questo modo, tutte le funzioni incluse nel file WLRCS.cc richiamate automaticamente dall’ambiente gSOAP non fanno altro che chiamare la rispettiva funzione membro della classe LRCS. Manca un ultimo passo: per gestire il server per tutta la durata della sua esecuzione si fa in modo di avere una singola istanza di LRCS attiva.
Per permettere alle funzioni in WLRCS.cc di richiamare questa istanza, si `e estesa la classe WLRCS in modo da rendere disponibile un puntatore a LRCS at-traverso il campo void* user della struttura struct soap incluse nella classe WLRCS. La nuova classe utilizzata per gestire il framework di comunicazione `e chia-mata WLRCS_svt, che oltre a quanto descritto si preoccupa anche di inizializzare il
Figure 4.1: Catena di chiamate lato server
plugin di sicurezza GSI per gSOAP. In Figura 4.1 viene mostrato indicativamente come il controllo passi da un entit`a ad un’altra a lato server, al ricevimento di una richiesta SOAP da un client.
4.2.4 Client side
Sul lato client la situazione `e pi`u semplice, in quanto la logica applicativa `e lasciata allo sviluppatore, a cui viene fornita semplicemente una API di programmazio-ne. Questa realizza i meccanismi che permettono di stabilire una comunicazione SOAP con un LRCS e di fruire dei servizi offerti da quest’ultimo. In particolare, a basso livello si ha la classe WLRCS definita nel file lrcsWLRCSProxy.h, creato dal preprocessore gSOAP. Questa classe realizza uno stub attraverso la cui inter-faccia si possono chiamare direttamente i metodi del server LRCS. Questa classe `e stata estesa per attivare il plugin di sicurezza GSI, e la classe derivata ha il nome di WLRCS_wrp. Un client che volesse utilizzare i metodi esportati via SOAP da un server LRCS potrebbe instanziare WLRCS_wrp inizializzando l’indirizzo IP e la porta a cui rivolgere le richieste di servizio, e chiamare successivamente i
metodi remoti attraverso l’interfaccia locale dello stub. `E stato aggiunto per`o un altro strato software attraverso una classe, LRCSStub, che contiene come membro privato una istanza di WLRCS_wrp. Lo scopo principale di questa nuova classe `e costituito dalla gestione degli errori, effettuata sia a livello SOAP, controllando lo stato d’uscita delle funzioni invocate attraverso il framework gSOAP, sia a pi`u alto livello: ogni metodo remoto infatti ha un parametro di output in cui speci-fica, oltre ai dati che rappresentano direttamente i dati di uscita del metodo, lo stato di uscita della chiamata remota, tipicamente attraverso un int.
4.3
Trasferimento dati via SOAP
Come spiegato nella Sezione 3.4.1, il protocollo implementato attualmente in CONStanza `e di tipo pull, ovvero i LRCS slave, non appena informati dal GRCS dell’esistenza di un’update unit disponibile presso la replica master, contattano il gestore di quest’ultima per ottenere i dati. La URI dell’update unit viene generata dal DBWatcher, e propagata attraverso GRCS fino ai LRCS slave. A questo punto, gli slave inviano un messaggio SOAP al master, contenente la URI del file da trasferire. Il master semplicemente carica in RAM il file richiesto, lo serializza in un messaggio SOAP di risposta contenente un attachment MTOM e lo invia. In questo modo il trasferimento dati vero e proprio si traduce in una singola interazione SOAP, secondo lo schema di comunicazione challange-response.
Per fare questo ogni LRCS slave deve implementare un client LRCS: la fun-zione requestFile, che `e deputata alla richiesta di trasferimento dati da un LRCS remoto sulla macchina locale, instanzia un LRCSStub e su questo chiama la funzione fileCopy. Quest’ultima chiamata su LRCSStub viene tradotta nel messaggio SOAP da inviare al gestore della replica master. La particolarit`a della comunicazione SOAP finalizzata allo scambio di file rispetto alle altre normali
Figure 4.2: Interazioni tra i moduli nel trasferimento dell’updatre
interazioni SOAP tra LRCS `e individuabile nel parametro di output del metodo remoto: come si `e detto, la risposta SOAP deve contenere il file richiesto, per cui il metodo remoto deve restituire, oltre al normale stato di uscita per la gestione degli errori, anche un parametro contenente l’attachment che poi dovr`a essere gestito dal LRCS slave. In questo senso, lo stub per la funzione requestFile `e un po’ pi`u complessa degli altri, in quanto deve gestire anche la copia su file remoto dell’attachment ricevuto.
Si pu`o notare come, sebbene lo scambio di messaggi sia stato implementato per rispecchiare il meccanismo pull-based utilizzato anche attraverso il meccanismo GridFTP, `e comunque possibile implementare un meccanismo che sia push-based, ovvero per il quale l’update unit venga spedito appena possibile direttamente dal
LRCS master ai gestori delle repliche slave. Questo `e realizzabile semplicemente non inserendo l’attachment contestualmente ad una risposta SOAP, cos`ı come `e stato descritto precedentemente, ma assieme ad una richiesta. In questo senso, lo slave che riceva correttamente l’update pu`o utilizzare la sua response SOAP segnalando l’avvenuta ricezione, per mantenere aggiornato il sistema della nuova versione della replica da lui gestita.
