Bacheca: Supporto alla creazione e diffusione di annunci basato su CORBA

Università degli studi di Bologna
                Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
                  A. A. 2006/2007

       Bacheca:
Supporto alla creazione
e diffusione di annunci
   basato su CORBA

            Corso di Reti di Calcolatori LS
                Prof. Antonio Corradi

                               Progetto di Elisa Addimanda
                                   Matricola: 0000231103

1. Introduzione
L’avvento della rete e l‘evoluzione della computazione distribuita, la
necessità di integrare e rendere interoperabili risorse tecnologiche
distribuite, mostrano in maniera evidente la necessità di far interagire
sistemi complessi del tutto diversificati ed eterogenei. A questo proposito ci
vengono in aiuto tutta una serie di middleware, come ad esempio lo
standard CORBA, nati con lo scopo di evitare che l’applicazione si carichi di
alcune responsabilità, facilitando non solo l’interazione delle applicazioni,
ma anche l’interazione dell’utente finale, e supportando applicazioni aperte
senza vincoli architetturali.
L’obiettivo di questo progetto è stato quello di realizzare un’applicazione
per la gestione di una bacheca, sfruttando le facilitazioni e gli strumenti
forniti dallo standard CORBA, e ponendo particolare attenzione alla
gestione delle risorse e della tolleranza ai guasti.
Bacheca è quindi un’applicazione che permette agli utenti di consultare e
pubblicare diversi annunci, suddivisi per categorie risiedenti su server
assolutamente eterogenei, e venire notificati della presenza di nuovi
annunci inseriti in aree di interesse preventivamente selezionate.
Nella parte che segue verranno illustrati gli aspetti chiave della
progettazione e realizzazione di tale applicazione. In particolare, nella
sezione 2 verrà descritto nel dettaglio il comportamento dell’applicazione,
ponendo l’attenzione separatamente sui diversi server e sul client. Nella
sezione 3 verranno discusse le problematiche relative alla replicazione
delle risorse e alla tolleranza ai guasti. Nella sezione 4 saranno descritti
brevemente alcuni dettagli relativi all’implementazione e agli strumenti
utilizzati. Nella sezione 5 verranno illustrate le possibile evoluzioni future.
Infine, nella sezione 6, si terminerà con una breve conclusione sugli
obiettivi raggiunti.

2. Il funzionamento del sistema
In figura 1 è mostrato il comportamento generale del sistema. All’ingresso
nel sistema, per prima cosa, viene chiesto al client di autenticarsi (è
prevista anche la possibilità di registrazione per i nuovi utenti), dopodiché
il client riceverà le eventuali notifiche (avvisi di inserimento di nuovi
messaggi nelle categorie di interesse) e potrà colloquiare con i vari server

                                                                         2 | 10

di categoria, ricevendo l’elenco degli                 annunci     presenti    o
pubblicando/rimuovendo i propri annunci.

                                      autenticazione

                                         notifiche

          case           auto           eventi                    …

                   Figura 1: Il comportamento del sistema.

2. 1 Il client
Appena viene fatta partire l’applicazione, la prima cosa che viene mostrata
è una form per effettuare il login, attraverso la quale è possibile autenticarsi
attraverso l’inserimento di username e password, oppure effettuare una
nuova registrazione.
Una volta ricevuta la risposta di conferma della corretta autenticazione, il
client riceve un messaggio di notifica dell’eventuale presenza di nuovi
annunci nelle proprie categorie di interesse.
A questo punto, dopo questa fase iniziale, il client potrà colloquiare
liberamente con i vari server di categoria attraverso un’interfaccia come
quella mostrata in figura 2, ricevendo l’elenco degli annunci pubblicati,
inserendo nuovi annunci, o rimuovendo i propri annunci precedentemente
inseriti. È, inoltre, possibile modificare l’elenco delle categorie di interesse,
selezionandone di nuove o deselezionandone alcune precedentemente
scelte. Infine è possibile rispondere agli annunci pubblicati o ai messaggi
ricevuti, o cancellare questi ultimi dopo averli letti. Tutto questo è mostrato
nel diagramma dei casi d’uso in figura 3.

                                                                          3 | 10

Figura 2: Interfaccia client.

Per tutta la durata dell’esecuzione lo stato (quali annunci sono stati letti, e
quali categorie di interesse sono state selezionate) viene memorizzato sul
client, per non creare un traffico eccessivo verso il server, ma, all’atto della
disconnessione, questo viene registrato sul server per garantirne la
persistenza, e per permettere all’utente di collegarsi da una qualunque
postazione senza perdere memoria di ciò che è stato fatto.
Per quanto riguarda la comunicazione con i server, sono stati usati il name
service di CORBA, e la dynamic invocation interface. Il name service ci ha
consentito in modo aperto di ritrovare gli oggetti che ci servivano, e di
passarne i riferimenti nell’ambiente client, da cui è stato possibile invocarli,
senza bisogno di avere i riferimenti agli oggetti a priori. La dynamic
invocation interface, invece, attraverso l’operazione sincrona invoke
sull’oggetto request, ci ha permesso di invocare i servizi, senza aver dovuto
generare staticamente i proxy. Tutto questo rende il client completamente
indipendente dalla struttura del server, dandogli la possibilità di effettuare
richieste senza sapere a quale server andrà realmente a connettersi.

                                                                          4 | 10

Figura 3: Diagramma dei casi d’uso.

2. 2 I server
Lato server si è scelto, per semplicità, di non usare la dynamic server
interface, generando staticamente gli skeleton attraverso l’IDL.
Naturalmente sarebbe stato possibile anche usare skeleton dinamici, ma
questo avrebbe complicato notevolmente il progetto.
Per quanto riguarda le politiche di attivazione dei servant, sono state fatte
scelte diverse (che verranno discusse in seguito) in base alla tipologia dei
diversi server.

2. 2. 1 Il server per le autorizzazioni
Il server per le autorizzazioni (authServer) fornisce un’interfaccia molto
semplice, contenente due soli metodi: “authenticate” e “register”.
Il metodo “autenticate” richiede in ingresso due stringhe rappresentanti
username e password, e, dopo aver controllato la correttezza dei dati
forniti, restituisce un booleano rappresentante l’esito dell’operazione.
Il metodo “register” richiede anch’esso due stringhe rappresentanti
username e password, e dopo aver controllato che lo username non sia già
stato usato, memorizza i nuovi dati e restituisce una stringa rappresentante
l’esito dell’operazione (vuota se andata a buon fine, altrimenti contenente la
descrizione del problema verificatosi).
Per la realizzazione di questo server si è scelto di usare una politica di tipo
“on demand activation”, attivando, cioè, un nuovo servant ad ogni richiesta,

                                                                         5 | 10

e distruggendolo al termine. Questa scelta è stata fatta pensando che le
richieste per le autenticazioni non sono molto frequenti (soltanto all’atto
della connessione), perciò sarebbe inutile mantenere attivo un servant che
risulterebbe poi inutilizzato.

2. 2. 2 I server delle categorie
I server delle categorie sono molto simili fra loro, ma sono stati realizzati
separatamente, per dare la possibilità di avere server di categorie diverse
situati in locazioni diverse, e per dare la possibilità di aggiungere in seguito
ulteriori categorie. In questo esempio sono state realizzate le categorie
“case” (caseServer), “auto ‐ moto” (autoServer), “eventi ‐ feste”
(eventiServer), “libri ‐ appunti ‐ ripetizioni” (libriServer) e “varie”
(varieServer).
Essi memorizzano l’elenco degli annunci in un database xml ben
strutturato, in cui per ogni annuncio viene memorizzato l’autore, un
identificatore progressivo, e il testo dell’annuncio.
Le interfacce fornite sono molto simili e contengono principalmente tre
metodi: “nuovoAnnuncio”, “aggiorna” e “rimuovi”.
Il metodo “nuovoAnnuncio” permette la creazione di un nuovo annuncio, e
richiede che vengano fornite in ingresso lo username dell’utente che vuole
creare l’annuncio e il testo dell’annuncio. Tale annuncio viene così
memorizzato nel file xml e restituito un booleano rappresentante l’esito
dell’operazione.
Il metodo “aggiorna” permette di fornire al client che effettua la richiesta,
l’elenco e il numero complessivo di annunci memorizzati (per ogni
annuncio vengono forniti autore, id e testo).
Il metodo “rimuovi” permette di cancellare un proprio annuncio inserito
precedentemente: se lo username dell’utente che effettua la richiesta
coincide con l’autore dell’annuncio che si intende rimuovere, l’operazione
andrà a buon fine e l’annuncio effettivamente cancellato. L’esito
dell’operazione viene restituito al client che effettua la richiesta attraverso
un booleano.
Poiché tali server ricevono continuamente richieste da parte dei vari client
durante tutta l’esecuzione dell’applicazione, si è scelto di usare una politica
di tipo “single servant”, recuperando ogni volta il servant già attivo
attraverso un oggetto denominato “servant_locator”, per non dover pagare
ogni volta il costo dell’attivazione di un nuovo servant.

2. 2. 3 Il server per le notifiche
Il server per le notifiche (notificationServer) è quello che si occupa di
avvisare il client della presenza di nuovi annunci non ancora letti nelle
categorie di interesse, e della gestione della messaggistica fra gli utenti.
I dati sono memorizzati in un file xml, in cui per ogni utente vengono
memorizzati l’elenco dei messaggi ricevuti e l’elenco delle preferenze
selezionate. I messaggi, oltre al testo, contengono lo username del mittente,

                                                                          6 | 10

un id sequenziale. L’elenco delle preferenze memorizza per ogni categoria
selezionata il nome e l’ultimo annuncio letto.
Questo server implementa un interfaccia contenente quattro metodi:
“registerStatus”, “refresh”, “sendMessage” e “removeMessage”.
Il metodo “registerStatus” permette di memorizzare lo stato del client
all’atto della disconnessione, modificando in maniera opportuna l’elenco
delle preferenze.
Il metodo “refresh” fornisce al client l’elenco di messaggi ricevuti e lo stato
registrato sul server, che può così essere confrontato con lo stato attuale del
client ed eventualmente notificare le differenze.
Il metodo “sendMessage” richiede la trasmissione, oltre al testo del
messaggio, di due stringhe contenenti lo username del mittente e quello del
destinatario, per poter andare a modificare in modo opportuno l’elenco dei
messaggi memorizzati.
Il metodo “removeMessage”, infine, è quello che permette all’utente di
cancellare i propri messaggi ricevuti.
Per quanto riguarda le politiche di attivazione, anche qui, come per il server
per le autenticazioni, si è scelto una politica di tipo “on demand activation”,
poiché le richieste non sono eccessivamente frequenti, ma concentrate
all’atto della connessione e della disconnessione dell’utente, perciò si è
scelto di non mantenere attivo costantemente un servant scarsamente
utilizzato.

3. Replicazione e tolleranza ai guasti
Per rispondere al requisito di fault – tolerance sono state prese alcune
precauzioni che permettono di tollerare i guasti, nell’ipotesi di guasto
singolo.
A tale scopo è stato quindi previsto un ulteriore server, che implementi
tutte le interfacce dei server realizzati, costituendo in tal modo una replica
per ognuno di essi, andandosi a sostituire, di volta in volta, quando
necessario, all’eventuale server caduto.
È quindi necessaria una fase di identificazione dell’eventuale guasto per
poter poi procedere all’eventuale sostituzione. A tale proposito, è stata
prevista la creazione di un thread, che periodicamente si occupa di
interrogare i vari server per testarne la vitalità. Questo viene fatto
sfruttando la funzione “send one way” fornita da CORBA, la quale ci
permette di effettuare una richiesta una sola volta in modo non bloccante.
Se il server in questione è caduto, tale funzione genera un’eccezione che
può essere catturata per identificare il guasto. Una volta identificato il
guasto, viene distrutto il thread che si occupava del controllo, e viene
attivato un nuovo thread che si occupa di svolgere il servizio del server
guasto.
Una volta che il guasto è stato riparato, il server originale ricomincerà a
svolgere il suo compito, e la replica smetterà di fornire quel servizio e

                                                                         7 | 10

riattiverà il thread che si occupava del controllo dei server. Per fare questo,
il server adibito a replica, oltre a implementare le interfacce dei server che
intende sostituire, dovrà fornire un ulteriore interfaccia con una serie di
metodi che permettano ai server, una volta riattivati, di capire se la replica
sta fornendo il loro servizio e, in questo caso di farla terminare.

                    Figura 4: Identificazione del guasto.

Pensiamo, ad esempio, come mostrato in figura 4, che si verifichi un guasto
in caseServer che ne determini la caduta. In questo caso il thread che si
occupa del controllo, invocando la send one way su uno dei metodi di tale
server catturerà un’eccezione che determinerà l’attivazione di un nuovo
thread che andrà a fornire il servizio fornito precedentemente da
caseServer. Una volta riparato il guasto caseServer potrà riprendere la sua
esecuzione. A questo punto attiverà un nuovo thread che si occuperà di
invocare il metodo “isCaseServer” fornito dalla replica. Tale metodo fornirà
risposta affermativa e a questo punto il thread invocherà il metodo
“termina” della replica e terminerà la sua esecuzione. Il metodo “termina”
della replica, consiste semplicemente nella disattivazione del thread che
sostituiva il server caduto, e nella riattivazione del thread che effettuava il
controllo di vitalità.
Infine, per quanto riguarda la gestione dello stato, è stato previsto un
meccanismo a copia calda passiva. Per ottenere questo è stato previsto un

                                                                         8 | 10

ulteriore metodo fornito dalla replica, denominato “aggiornaFile”. Perché la
copia sia realmente calda, ogni server, in seguito a una qualunque
operazione di scrittura, attiva un thread (il Manager in figura 5) che andrà a
invocare l’operazione “aggiornaFile”, che consiste nella propagazione delle
modifiche sulla copia, mantenendo, in questo modo, lo stato sempre
aggiornato. Si è scelto di effettuare questa operazione con un thread
separato per rispettare il principio di minima intrusione, in modo che un
eventuale problema nell’aggiornamento della copia non blocchi
l’esecuzione del server impedendo l’erogazione del servizio.

                              Figura 5: Copia calda.

4. Implementazione
Per quanto riguarda la realizzazione del prototipo e la scelta dell’ORB da
utilizzare, si è optato per IONA Orbix, che ci ha permesso di sviluppare
parte del progetto in java e parte in C/C++.
I server di categoria e il server per le autorizzazioni sono stati realizzati in
C/C++, mentre il server per le notifiche, la replica e il client sono stati
realizzati in java.
Per la creazione dei thread nei server C/C++ è stata usata la libreria
windows.h, il che ne impedisce l’esecuzione su sistemi operativi differenti.
Il sistema è stato testato su una rete di 3 computer, ognuno dotato di
un’installazione di IONA Orbix (requisito necessario per il funzionamento
del sistema), producendo i risultati attesi.

4. 1 Esecuzione
Per avviare i componenti è necessario lanciare i file “authServerExec.bat”,
“autoServerExec.bat”,          “caseServerExec.bat”,      “eventiServerExec.bat”,
“libriServerExec.bat”, “varieServerExec.bat”, “NotificationServerExec.bat” e
“replicaServerExec.bat” per l’esecuzione dei server, e “bachecaExec.bat” per
l’esecuzione dei client.
Tali file, oltre a lanciare gli eseguibili, hanno il compito di settare le variabili
richieste da Orbix prima di far partire l’esecuzione del rispettivo
componente.

                                                                             9 | 10

5. Sviluppi futuri
L’implementazione realizzata fornisce un primo prototipo per
l’applicazione, ma è possibile estenderla sfruttando la dynamic server
interface di CORBA e dando, quindi, la possibilità di aggiungere
dinamicamente nuove interfacce e quindi nuove categorie che non erano
state previste a priori sfruttando l’Interface Repository. Inoltre è possibile
sostituire il server per le notifiche, ottenendo un risultato analogo
sfruttando il Notification Service di Orbix. Infine si può aumentare la QoS
rendendo sicura la comunicazione con il server per le autorizzazioni,
sfruttando il Security Service di Orbix.

6. Conclusioni
Concludendo, con questo progetto è stata realizzata una semplice
applicazione distribuita per la gestione di una bacheca, che ci ha permesso
di approfondire i servizi e le facilitazioni forniteci dallo standard CORBA,
affrontando le problematiche relative alla replicazione, alla gestione delle
risorse e alla tolleranza ai guasti.

                                                                      10 | 10