Di seguito si descrive brevemente il funzionamento di EXaM. I dettagli implementativi verranno trattati ampiamente nei capitoli 8 e 9.
5.4.1
Il file di configurazione
Come già descritto sopra, il file di configurazione di EXaM, in formato XML, descrive concretamente il sistema, ossia ciò che l’architettura software delinea in modo astratto. Con questo file si determina una corrispondenza univoca tra l’architettura software e il sistema reale di componenti realizzato su una rete con gli host coinvolti nel monitoring.
L’utente che compila il file di configurazione deve avere una conoscenza del sistema e di cosa si vuole monitorare. Al momento della compilazione, inoltre, è necessario conoscere l’esatto mapping tra i componenti descritti nel- l’architettura software e gli host sulla rete, in modo da eseguire e monitorare ogni applicazione target sul componente corretto.
Ciò che si richiede è l’individuazione della struttura e delle decisioni chia- ve che riguardano il modo in cui il software deve funzionare in termini di comportamenti attesi e di tracce prodotte. In particolare è richiesto di:
• individuare la struttura del sistema in termini di componenti : significa determinare gli host coinvolti nel monitoring e le applicazioni target da eseguire su ciascuno di essi;
• specificare le connessioni tra i componenti di cui si vuole ottenere il mo- nitoring: consiste nell’individuare i componenti (packages e interfacce) e le invocazioni di si vuole ottenere le tracce di esecuzione;
• supportare in modo appropriato il processo di monitoring: consiste nel- l’occuparsi di vari dettagli tecnici, come individuare le porte attive, le
directory in cui produrre i risultati e i parametri della Virtual Machine necessari per eseguire e avviare il monitoring delle applicazioni target.
EXaM fornisce anche un supporto grafico per la compilazione del file di con- figurazione, qualora essa risultasse ostica o troppo a basso livello per utenti inesperti.
5.4.2
Lo schema master - slave
EXaM (vedi Figura 5.3) esegue ed effettua il monitoring di un sistema di- stribuito su una rete di processori. La configurazione del master e degli slave risulta totalmente centralizzata, poiché, come già spiegato, è il master a pre- disporre, sulla base delle direttive dell’utente, quali componenti gireranno sui vari host della rete. Una tale struttura facilita il recupero e la gestione delle informazioni riguardanti le relazioni inter-componente e comporta solo l’installazione dei programmi che implementano lo slave su ciascun host, al momento di configurare la rete ospite. Ciascun monitoring, quindi, richiede solo l’avvio di uno o più slave, a seconda della complessità dell’applicazione oggetto dell’analisi, lasciando in attesa di una richiesta di esecuzione gli altri slave non coinvolti.
Con il parsing del file XML di configurazione, il master recupera tutte le informazioni necessarie ad eseguire l’applicazione target e ad effettuarne il monitoring: il numero e l’indirizzo dei nodi coinvolti e, per ogni nodo, il componente da eseguire e le relazioni da tracciare. Il master trasmette poi a ogni nodo, attraverso la metodologia RMI, le informazioni specifiche, avvia i rispettivi processi su ciascun slave e aspetta i risultati dell’elaborazione.
Alla chiamata del master, ciascun slave risponde leggendo le informazioni che lo riguardano, ossia tutte le informazioni relative al componente da ese- guire, e provvedendo a scaricare il codice eseguibile della componente target, utilizzando un listener messo a disposizione dal master. Con questi dati, lo slave può eseguire il monitoring del componente, accedendo a livello della Virtual Machine in esecuzione. Per le interfacce e i packages di cui si è fatta richiesta, vengono derivate le tracce, sotto forma di file XML e compresse in
Figura 5.3: La struttura di EXaM
un unico file .zip, infine spedite al master perché le elabori e le convogli verso un’entità esterna predisposta ad analizzarle.
Il funzionamento di EXaM, suddiviso secondo il master e lo slave, è dettagliatamente descritto da un punto di vista tecnico in 7.
EXaM, eseguendo l’applicazione oggetto del monitoring, verifica che essa sia stata concepita e sviluppata correttamente non solo producendo tracce che verranno analizzate da un tool specifico, ma intervenendo in modo asso- lutamente non invasivo nell’avvio di ciascun componente, favorendo dunque l’emergere di eventuali difetti nel codice. Poniamo, per esempio, che l’appli- cazione da monitorare sia una semplice applicazione RMI costituita da un server, app1, che implementa il metodo Hello() e un client, app2, che richia- ma tale metodo in remoto. EXaM esegue il codice di app1, fornito come file app1.jar (per i dettagli sulla compressione di un’applicazione in un unico file jar, vedi Appendice A), sull’host A ed esegue poi app2.jar sull’host B senza un particolare ordine e soprattutto senza attendere che app1.jar sia correttamente in esecuzione e in attesa di chiamate remote. Tale compor-
tamento mira a far emergere eventuali e frequenti errori nello sviluppo di un’applicazione RMI:
1. il client non gestisce il caso in cui il server remoto non sia attivo perché momentaneamente fuori uso o non ancora avviato;
2. il client e il server utilizzano stub validi solo nel classpath locale, ossia definiti con percorsi del tipo file:// e senza un apposito codebase che si registri correttamente sull’rmiregistry;
3. il client contiene riferimenti all’interfaccia remota, senza un’appropriato meccanismo che riconduca all’implementazione della classe.
Analogamente, EXaM mira a evidenziare eventuali malfunzionamenti met- tendo a disposizione le tracce delle chiamate remote e le tracce delle chiamate interne tra componenti diversi, sebbene la compilazione del file di configu- razione possa risultare onerosa dal momento che richiede una conoscenza dettagliata dell’applicazione da analizzare.