Università degli Studi di Napoli Federico II. Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi Sperimentale di Laurea Triennale Realizzazione di una Web User Interface: un portale per l'accesso sicuro, trasparente e personalizzato alla GRID. Relatori Prof. Guido Russo Ing. Giovanni Battista Barone Dott.ssa Vania Boccia Candidato Anno accademico 2009/2010

2 Indice Generale 1 Introduzione Il Grid Computing e il middleware glite Introduzione Al Grid Sicurezza E Autenticazione Il Middleware GLite I sistemi di accesso alla Grid stato dell'arte Command Line Interface (CLI): GLiteUI Applicazione Stand Alone: Grid2Win Portali Web Genius Portal P-Grade Analisi dei requisiti e progettazione Specifica Dei Requisiti Di Sistema Use Case Diagram Rappresentazione Dei Casi D'uso Tramite Tabelle Di Cockburn Analisi Dell'architettura Diagramma Delle Classi Sequence Diagram La Web User Interface: moduli software e strategie implementative Modulo Di Autenticazione Strumenti utilizzati: Java Web Start La Procedura Guidata per l'autenticazione Moduli Per Il Data Management, Il Job Management E L'Information System Strumenti per l'implementazione: Liferay, Web application, Portlet La gestione dei Job L'Information System Il Data Management Guida all'uso dell'applicazione realizzata La Web User Interface: Guida All'utilizzo Data Management System Information Appendice Procedura Di Installazione Del Sistema Codice Bibliografia Pagina 2 di 146

3 1 Introduzione Il presente lavoro di tesi ha avuto come obiettivo la realizzazione di una Web User Interface, una Web Application che consente ad una eterogenea classe di utenti, più o meno esperti nell'utilizzo dei sistemi di calcolo, di accedere ad infrastrutture complesse come quelle di Grid Computing. In particolare, lo scopo del lavoro è stato quello di fornire un unico punto di accesso ai sistemi GRID, attraverso un'interfaccia web che semplifichi le operazioni di autenticazione/autorizzazione tramite dei certificati X509, job management (sottomissione, monitoraggio, ritiro dell'output), data management (spostamento di dati tra le risorse) e system information (recupero delle informazioni). Le motivazioni che hanno portato alla realizzazione di questo lavoro di tesi, vanno ricercate nei limiti delle soluzioni software attualmente disponibili per l'accesso utente alle infrastrutture GRID: le classiche User Interface di tipo CLI (Command Line Interface), proprie dei sistemi Unix, i portali web e le applicazioni grafiche stand-alone. Un esame accurato di queste soluzioni e dei loro limiti verrà presentato nel Capitolo 3. Ciò che differenzia la web user interface realizzata, dai sistemi appena citati, è l'utilizzo di un'interfaccia grafica intuitiva che semplifichi le operazioni di accesso ed utilizzo della GRID all'utente meno esperto ma, allo stesso tempo, non limiti le esigenze di utenti più esperti, garantendo inoltre la portabilità su sistemi differenti. Un ulteriore valore aggiunto del lavoro è rappresentato dall'utilizzo del web server/portlet container, Liferay, un Enterprise Open Source Portal, accessibile tramite web e che offre tutti i servizi di un portal manager. Esistono diverse implementazioni open source e commerciali di web server/portlet container ma questo è, al momento, il prodotto che mostra il maggior numero di potenzialità. Nel capitolo 2 verrà fatta un'introduzione ai sistemi distribuiti Grid, l'architettura, le Virtual Organizzation e il middleware glite; Nel Capitolo 3 verrà trattato lo stato dell'arte relativo alle user interface presenti sul mercato Pagina 3 di 146

4 attualmente. Verranno analizzati i pregi e difetti di queste applicazioni, e del perchè si è scelto di realizzare un punto di accesso unico. Il capitolo 4 tratterà la parte di analisi e i requisiti dell'applicazione sviluppata, con i relativi diagrammi. Nel capitolo 5 si parlerà dell'implementazione, delle varie componenti del sistema, delle tecnologie e di come sono state realizzate. Nel capitolo 6 viene presentata una guida all'uso del software realizzato, con screeshot di esempi di funzionamento ed un tipico utilizzo del sistema. Il lavoro è stato testato sull'infrastruttura Grid, realizzata nell'ambito del progetto PON S.Co.P.E dall'università degli Studi di Napoli Federico II Pagina 4 di 146

5 2 Il Grid Computing e il middleware glite 2.1 Introduzione al Grid Alla base del concetto di Grid Computing c'è l'idea di collegare su larga scala risorse di calcolo e di memorizzazione anche eterogenee, distanti geograficamente tra loro e gestite da enti o persone differenti. La grande disponibilità di risorse di calcolo e di storage, consente non solo la memorizzazione e la condivisione di enormi quantità di dati, ma anche la loro rapida elaborazione per la risoluzione di problemi complessi di carattere per lo più scientifico. Esistono due tipi di infrastrutture di Grid Computing : Le Griglie Computazionali: rappresentano un'aggregazione di risorse computazionali differenti fra loro. Le Griglie di Dati: usate per memorizzare e condividere una grande quantità di dati fra gli utenti di differenti domini Alla base del paradigma Grid c'è il concetto di virtualizzazione che permette di aggregare differenti sistemi distribuiti geograficamente, in maniera trasparente all'utilizzatore: la virtualizzazione riesce a nascondere all'utente tutta la complessità del sistema e le relazioni tra le varie componenti, in modo da dargli l'idea di avere a disposizione un unico e potente centro di calcolo. Come la maggior parte dei sistemi informatici di grandi dimensioni, anche le griglie sono scomposte in sottosistemi, o strati, o livelli: ogni strato esporta le proprie funzionalità e servizi gli strati superiori per mezzo delle interfacce, e allo stesso modo utilizza le funzionalità di quelli inferiori: la struttura a livelli permette di risolvere alcuni problemi e garantire maggiore efficienza per quanto riguarda la protezione, lo sviluppo incrementale dell'intero sistema, la manutenibilità e per ultimo la portabilità, ma allo stesso tempo presenta alcuni svantaggi. La modifica dell'interfaccia di un livello al quale accedono più strati, comporta Pagina 5 di 146

6 necessariamente la modifica di tutti gli strati che sfruttano tale servizio. Figura 1 - Livelli e connessioni di un'infrastruttura Grid In figura 1, è rappresentata l'architettura multilivello di un'infrastruttura GRID. Come si può vedere ogni livello sfrutta i servizi offerti dai livelli inferiori: ad esempio il livello Application sfrutta i servizi offerti da tutti i livelli inferiori, Collective, Resource e Connectivity. Nell'architettura Grid è molto importante il concetto di interoperabilità, ovvero l'uso di protocolli comuni, usati per negoziare, usufruire e gestire relazioni di condivisione di risorse. Questi protocolli infatti permettono di specificare come gli elementi facenti parte di un sistema distribuito, interagiscono fra loro. I livelli di un'architettura Grid sono 5, come si vede dalla figura precedente, ognuno con un ruolo specifico: Il livello Fabric fornisce tutte le risorse fisiche, tra cui le risorse di calcolo (cioè quelle richieste per eseguire programmi e monitorare l'esecuzione dei processi), le risorse di archiviazione (per il salvataggio e il recupero dei file), le risorse di rete (per il trasferimento dei dati). Il livello Connectivity racchiude i protocolli di comunicazione e di autenticazione del Pagina 6 di 146

7 Grid. I protocolli di comunicazione comprendono i protocolli di rete, di trasporto e applicazione, appartenenti al modello ISO/OSI, e permettono lo scambio di dati. Per quanto riguarda l'autenticazione, questi protocolli forniscono meccanismi di sicurezza facendo in modo di verificare l'identità degli utenti. Il livello Resource contiene i protocolli per la negoziazione delle risorse, considerate questa volta singolarmente, per il recupero delle informazioni sulle singole risorse, per la gestione delle risorse e per il monitoraggio. Il livello Collective, a differenza di quello sottostante, si concentra sull'interazione delle singole risorse, considerandole come collezione. Per questo motivo, i protocolli presente in questo livello, gestiscono appunto le loro interazioni. L'ultimo livello è quello Application, che comprende le applicazioni utente che utilizzano la Grid. Un'architettura Grid può, per quanto appena detto, essere rappresentata da una clessidra, con un collo di bottiglia al centro di essa, rappresentato dai livelli Resource e Connectivity (e quindi dai protocolli che questi livelli contengono), comunemente denominato middleware. A partire dal 1999 ad oggi, diversi sono stati i GRID middleware sviluppati. Per citarne solo alcuni più noti: Globus, Unicore, DataGRID, ecc. Ancora oggi non esiste, in merito, un vero e proprio standard ma piuttosto standard de-facto: in tutta Europa si utilizza il middleware glite. Gruppi di risorse e di utenti abilitati ad utilizzare tali risorse e i servizi offerti, costituiscono le cosiddette Virtual Organization (VO). Le Virtual Organization differiscono tra loro per numero di partecipanti, struttura e tipo di attività svolta. Ogni utente della GRID deve essere iscritto ad almeno una delle VO afferenti alla GRID: l'appartenenza ad una specifica VO è infatti un requisito fondamentale per permettere ad un utente di accedere alle risorse ed quindi a qualunque servizio offerto dalla griglia computazionale. Un'istituzione può essere iscritta a più VO, decidendo di mettere a disposizione tutte o parte Pagina 7 di 146

8 delle proprie risorse, di storage o computazionali. Figura 2 - esempio di Virtual Organization 2.2 Sicurezza e autenticazione Come anticipato nel paragrafo precedente, la comunità è raggruppata in Virtual Organization, le quali permettono agli utenti, dopo essersi registrati, di accedere alle risorse offerte nella griglia. Fattore critico, nella condivisione e nell'accesso alle risorse, è ovviamente la sicurezza. In Pagina 8 di 146

9 ambito Grid, la sicurezza è fornita dal GSI (Grid Security Infrastructure) e si basa sull'utilizzo dei certificati X.509. Per accedere alla Grid, un utente deve munirsi di un certificato digitale rilasciato da una Certification Authority (CA) riconosciuta. Questo certificato, protetto da una chiave privata, viene usato per generare un ulteriore certificato provvisorio, il proxy certificate, (o semplicemente proxy), che servirà per il riconoscimento dell'utente (autenticazione) e per l'autorizzazione all'uso delle risorse all'interno della Grid. Il proxy ha una validità limitata, normalmente intorno alle 12 ore, al fine di ridurre i possibili rischi causati da accessi indesiderati nel sistema. Lo standard X.509 prevede una coppia asimmetrica di chiavi, una chiave privata che è nota unicamente al possessore del certificato ed una chiave pubblica. Un certificato di questo tipo contiene diverse informazioni sul possessore, come per esempio, i dati dell'utente, la CA che ha rilasciato il certificato, e il tempo di scadenza del certificato. La struttura del certificato x.509 è mostrato nella seguente figura: Figura 3: Struttura del certificato standard x.509 Pagina 9 di 146

10 2.3 Il middleware glite Il middleware è un componente software fondamentale per i sistemi Grid e rappresenta un software che opera in modo da rendere invisibile all'utente utilizzatore la complessità della griglia. Il middleware che si è considerato in questo lavoro di tesi è glite. Il middleware glite si basa sul concetto di elemento e sito e implementa le classi collective e core. I servizi relativi alla classe core sono servizi locali ad un sito e permettono la condivisione delle risorse di calcolo e di storage, mentre i servizi collective sono dei servizi distribuiti che, lavorando al di sopra delle risorse locali ai vari siti, ne consentono la gestione. I servizi core sono: User Interface (UI): rappresenta il punto di accesso tra il client e la griglia. Tramite una UI l'utente può essere autenticato tramite un certificato personale, e successivamente iniziare ad utilizzare i servizi e le funzionalità del middleware. Computing Element (CE): rappresenta una risorsa di calcolo, la cui principale funzionalità è legata alla gestione dei job (sottomissione, controllo e gestione..). Inoltre fornisce tutti i servizi necessari per l'accesso alle risorse computazionali. Il CE comunica in maniera diretta con i singoli nodi (Worker Node). Storage Element (SE): permette un accesso uniforme alle risorse di storage e fornisce servizi per la gestione degli storage locali in maniera trasparente all'utente. Worker Node (WN): è la componente che fornisce i servizi per il calcolo e la computazione reale. Site BDII (SBDII): permette il recupero di informazioni sulle risorse locali, utili per effettuare il monitoraggio e la raccolta di informazioni. Pagina 10 di 146

11 Figura 4 I servizi core di glite L'accesso, da parte dell'utente, alle risorse di calcolo e storage di un sito locale, non avviene direttamente dalla UI ma passa attraverso i cosiddetti servizi collective che, tra l'altro consentono all'utente: di essere riconosciuto e di dichiararsi parte di una Virtual Organization, mediante il certificato X.509 di trasferire dati tra le risorse di utilizzare le risorse di calcolo per eseguire e controllare i propri job. Il servizio che si occupa del riconoscimento degli utenti (autenticazione) di una Virtual Organization e del rilascio delle autorizzazioni all'utilizzo delle risorse si chiama VOMS (Virtual Organization Membership Service). Esso mette a disposizione un'insieme di Pagina 11 di 146

12 strumenti che permettono agli amministratori di definire ruoli e capacità ai singoli utenti, oppure di aggiungere utenti ad una specifica VO. Per effettuare la sottomissione e la gestione dei job, viene utilizzato il WMS (Workload Management System). Esso si occupa di soddisfare le richieste dell'utente, selezionando tramite il sistema informativo (Top BDII) un CE, che soddisfi i requisiti per il job, tramite l'operazione detta di matchmaking. L'implementazione, il collegamento e l'accesso alle risorse dell'intera infrastruttura Grid è completamente trasparente all'utente, che interagisce soltanto tramite la user interface. Nel prossimo paragrafo verranno trattate le modalità di accesso e le user interface con cui utilizzare il middleware glite. Pagina 12 di 146

13 3 I sistemi di accesso alla Grid stato dell'arte Nel capitolo precedente sono emersi due aspetti critici relativi all'accesso e all'utilizzo delle infrastrutture GRID: 1. l'importanza della sicurezza delle risorse condivise e dei meccanismi che consentono il l'autenticazione e l'autorizzazione degli utenti 2. la complessità dell'architettura multi-livello che l'utente non deve percepire. In questo capitolo sarà brevemente descritto come la sicurezza viene preservata solitamente in ambienti GRID e quali sistemi di accesso sono attualmente messi a disposizione degli utenti per l'accesso alle risorse. In infrastrutture GRID, basate su glite, l'unico punto di accesso per l'utente è rappresentato dalla User Interface. Questa componente fornisce tutte le interfacce per le funzionalità della griglia all'utente e permettere l'interazione con tutte le altre componenti del middleware. E' perciò una delle parti più importanti di un sistema dal punto di vista dell'utente, in quanto rappresenta una sorta di finestra, che mostra tutte le potenzialità del sistema, e che per molti si identifica con il sistema stesso, essendo una delle poche componenti visibili. Essendo l'unico punto di accesso per tutti gli utenti, essa ha il compito di semplificare all'utente l'esecuzione delle varie funzionalità. Nei prossimi paragrafi è riportata una panoramica sulle varie implementazioni, attualmente disponibili, di User Interface per le GRID basate su glite, riportando per ognuna di esse le caratteristiche ed evidenziandone i limiti di utilizzo per alcune tipologie di utenti. 3.1 Command Line Interface (CLI): gliteui Ancora oggi per la maggior parte degli utenti esperti, il punto di accesso standard alla Grid è la Command Line Interface (CLI), ovvero una modalità di interazione tra l'utente e il sistema che prevede l'immissione di comandi attraverso un terminale testuale. La Command Pagina 13 di 146

14 Line Interface è disponibile per sistemi operativi Unix-like ed è sprovvista di interfaccia grafica. Utilizzare glite tramite terminale non è un'operazione semplice per un utente non abituato. Le operazioni da mettere in pratica affinchè sia possibile accedere ed utilizzare le funzionalità esposte dalla user interface, sono schematizzate di seguito: Accesso: Per accedere alla user interface bisogna eseguire una connessione tramite ssh specificando indirizzo e nome utente relativo alla user interface alla quale ci si vuole connettere. Questo presuppone la presenza di un account utente sul server che la ospita; Autenticazione: La fase di autenticazione è una delle più importanti in quanto permette di avere un accesso illimitato al grid, ma allo stesso tempo non è di semplice realizzazione. Prevede infatti la copia e la manipolazione del certificato personale X.509 dalla propria postazione alla user interface, e in seguito l'immissione di altri comandi che porteranno alla creazione di un ulteriore certificato temporaneo. Il tutto dovrà essere scritto dall'utente il quale dovrà ricordare l'esatta successione dei comandi, in caso contrario riceverà dei messaggi di errore. La presenza del certificato X.509 sulla user interface rappresenta un fattore di rischio, in quanto permette un accesso illimitato al sistema Grid, senza limiti di tempo; Gestione dei job: Anche per quanto riguarda la gestione dei job, ogni operazione sarà rappresentata da un comando (di solito composto da un singolo comando e una serie di parametri di cui necessita) che l'utente dovrà digitare. Nel caso in cui voglia scrivere il codice di un job, dovrà farlo senza l'aiuto di un editor grafico, ma utilizzandone uno testuale, il che comporta la conoscenza di ulteriori comandi che permettono di creare salvare o anche modificare il file in questione. Dopo ogni sottomissione, l'utente dovrà salvare e conservare l'id relativo al job che ha inviato, altrimenti perderà ogni riferimento a quest'ultimo. Anche quest'ultima azione è a carico dell'utente. Recupero delle informazioni: Ogni informazione che si intende ottenere dal sistema, è associata ad un parametro differente dello stesso comando, e non sempre è facile capire a quale componente si riferisce. Ad esempio il parametro tag del comando Pagina 14 di 146

15 lcg-infosites vo unina.it permette di recuperare tutte le informazioni relative ai software installati sui vari WM. Gestione dei dati: Stesso discorso anche per il salvataggio e il recupero dei dati memorizzati su un SE. Sarà sempre l'utente a doversi ricordare la sequenza di comandi da digitare per recuperare o inviare un file su un SE, cosi come il GID associato ad ogni file e utile per avere un collegamento con il file stesso. Ma vediamo un esempio che mostra un tipico utilizzo di glite per la sottomissione di un job. Il comando corrispondente è: glite-wms-job-submit -a [ path del job ] dove il path del job rappresenta il percorso relativo o assoluto del file JDL contenente il codice del job. L'output del comando viene mostrato nella figura sottostante: Figura 5 - esempio relativo al comando di sottomissione del job Pagina 15 di 146

16 Come è facile notare, l'interfaccia non è user-friendly e quindi non adatta ad utenti inesperti. Inoltre l'utilizzo della CLI è ristretto ai sistemi Unix ed ha quindi una portabilità limitata. Una prima soluzione per migliorare l'usabilità del sistema, è quella di creare un'interfaccia grafica, in modo che l'utente possa interagire con la user interface in maniera visuale. Si passa perciò dall'utilizzare un sistema basato sulle CLI ad un'applicazione stand-alone, che necessita di differenti sistemi operativi su i quali essere installata ed eseguita. L'idea di sviluppare una user interface grafica è già stata presa in considerazione nel progetto progetto di Grid2Win, un porting di glite sui sistemi Windows. 3.2 Applicazione Stand alone: Grid2Win Anche se le distribuzioni Linux sono in piena espansione, molti utenti continuano a preferire l'utilizzo di sistemi Microsoft, in particolare il sistema operativo Windows. Da questa considerazione è nato il progetto Grid2Win ( eela.eu/new/index.php) che mira ad "aprire" i servizi di rete per i sistemi Microsoft. Tale iniziativa è volta a coinvolgere gli utenti windows nell'uso della potenza di calcolo offerta da Grid computing. Per fare ciò, il gruppo di Grid2Win ha realizzato un porting del middleware glite per le piattaforme windows. L'interfaccia utente (UI), a differenza delle CLI, è completamente grafica e rispecchia tutte le funzionalità di glite. Per un utente non esperto, l'utilizzo di queste applicazioni grafiche risulta semplificato rispetto alle CLI. Infatti ogni pulsante indica una precisa operazione, descritta in maniera sintetica nel nome del componente. Sparisce perciò la necessità di doversi ricordare la successione dei vari comandi per poter eseguire le operazioni. Le stesse operazioni che potevamo fare tramite la CLI, possono essere eseguite con grid2win ma con maggiore semplicità: Accesso: Dopo aver configurato l'applicazione, l'accesso è trasparente all'utente che non deve far altro che avviarla. Anche in questo caso però è necessario un account Pagina 16 di 146

17 utente sul server. Autenticazione: Per effettuare l'autenticazione è necessario avvia la procedura guidata la quale chiederà l'inserimento della password e di specificare dove risiede il certificato X.509. In seguito, cliccando sulla voce di menu crea proxy, sarà possibile creare il certificato proxy. La sequenza di operazioni è notevolmente diminuita e semplificata, grazie alla presenza di menu e procedure guidate, ma resta comunque un problema di sicurezza dovuto al salvataggio del certificato X.509 sul server. Gestione dei job: Anche la gestione dei job è migliorata, in quanto l'utilizzo di un ambiente grafico consente di avere un riepilogo di tutti i job sottomessi e del relativo stato. Recupero delle informazioni: Per recuperare le informazioni basta cliccare la relativa voce di menu, e successivamente i pulsanti relativi ai componenti di cui vogliamo ottenere informazioni. Gestione dei dati: L'invio e la ricezione dei file è simile alla gestione delle cartelle nei sistemi windows, con un albero delle cartelle che mostra sia i file locali che quelli sul server. Pagina 17 di 146

18 Figura 6 - schermata di utilizzo di Grid2Win Anche se abbiamo risolto i problemi derivanti dalle CLI, non ci troviamo davanti ad una soluzione definitiva. Prima di tutto, una volta installata sulla propria macchina, dovrà essere configurata altrimenti risulterà inutilizzabile. Questa procedura dovrà essere effettuata ogni qual volta si vorrà utilizzare grid2win su un computer differente. Inoltre questo tipo di applicazioni hanno una limitata portabilità, ristretta esclusivamente ai sistemi windows per cui, se da una parte viene risolto il problema di poter utilizzare un'applicazione grafica per i sistemi grid, dall'altra questo problema resta per gli ambiente Unix e OSX. Nel caso in cui l'utente voglia utilizzarla su altri computer, dovrà per forza effettuare una nuova installazione, con relativa configurazione per poter accedere al Grid. La User Interface dovrà perciò essere si basata su un'interfaccia grafica, ma che sia al tempo stesso portabile, ovvero utilizzabile su qualunque sistema. Considerando che la user Pagina 18 di 146

19 interface, per poter inviare e ricevere i dati dal Grid, necessita comunque di una connessione ad internet, perchè non sviluppare un'applicazione web, o web user interface da utilizzare direttamente in un browser internet? In questo modo si ha la possibilità di utilizzare il sistema tramite un browser internet, senza quindi necessità di nessuna installazione e la sua portabilità viene garantita su tutti i sistemi operativi. L'accesso sarà possibile ovunque, su qualunque computer, senza più nessun vincolo. Si arriva cosi ad avere un unico punto di accesso, grafico e semplice da utilizzare. Per permettere l'esecuzione dell'applicazione, abbiamo bisogno di una sorta di contenitore che si occupi di eseguire l'applicazione e gestirla. Per far ciò abbiamo bisogno di un portale web. 3.3 Portali web Un portale web costituisce un punto di ingresso ad un gruppo di risorse internet. Tradizionalmente i portali contenevano una raccolta di documenti HTML, per poi trasformarsi in sistemi per la diffusione e l'aggregazione di dati e applicazioni. Attualmente i potali hanno assunto un ruolo fondamentale e si sono evoluti fino ad arrivare ai recenti Enterprise Information Portal (EIP), applicativi che integrano un'architettura e un insieme di tecnologie che rappresenta lo stato dell'arte nell'ambito dei sistemi distribuiti. Gli EIP garantiscono all'utilizzatore un accesso personalizzato fornendo una sorta di desktop configurabile nel contenuto e nella rappresentazione. Consentono di rendere l'informazione pertinente, accessibile e aiutano gli utilizzatori nella gestione dei dati. I servizi messi a disposizione degli utenti possono essere catalogati secondo 2 categorie distinte: Integrazione dei contenuti provenienti da sorgenti differenti e non necessariamente localizzate nella stessa area Personalizzazione del livello di presentazione del portale tramite la modifica dei contenuti e delle interfacce Pagina 19 di 146

20 Generalmente una tipica interfaccia di un portale presenta quindi diverse aree. Una prima area detta personalization permette la personalizzazione dei contenuti in modo da visualizzare le informazioni a cui sono interessati e filtrare tutto il resto. In una seconda area, detta customization, viene data la possibilità all'utente di decidere il proprio profilo tramite l'aggiunta di servizi messi a disposizione dell'eip e la modifica del layout. L'architettura di un EIP segue uno standard introdotto dalla SUN e IBM, e definito in seguito nella Java 2 Enterprise Edition (J2EE) [Java 2 Platform Enterprise Edition, In generale viene visto come una Web Application che necessita di un Application Server per la gestione nell'ambiente java delle portlet e delle servlet, e un Web Server per reindirizzare le pagine generate e trasmettere i dati secondo il protocollo HTTP. L'integrazione viene effettuata mediante l'utilizzo dei portlet. I portlet sono in sostanza dei moduli web riusabili all'interno del portale, ognuno dei quali definisce il contenuto di ogni singola finestra che compone il portale stesso. L'uso di un portale web e di un'applicazione eseguita in esso, sembrerebbe la soluzione ideale al nostro problema. Ovvero un'applicazione grafica portabile su qualunque sistema, facile da utilizzare e accessibile via web. Sul mercato sono stati sviluppati alcuni sistemi che rispecchiano queste i requisiti che vogliamo dare al nostro sistema e tra questi riportiamo 2 progetti maggiori: Genius e P-Grade. Entrambi uniscono la semplicità di utilizzo simile alle applicazioni grafiche, alla possibilità di avere un accesso unico tramite un'interfaccia web. Ma vediamo in dettaglio in cosa consistono i due progetti Genius Portal GENIUS ( ) è un portale web sviluppato nel 2002 da INFN (National Institute of Nuclear Physics), il cui obiettivo è stato quello di creare uno strumento semplice, ma allo stesso tempo personalizzabile, per poter interagire con i sistemi Grid. Molti utilizzatori inesperti, per quanto riguarda l'uso del Grid, erano spesso scoraggiati dalla Pagina 20 di 146

21 complessità dell'interfaccia a linea di comando (CLI) offerta dal middleware per gli ambienti Unix-like, ostile per la maggior parte degli utenti. Figura 7 - Schermata di login di Genius Per ovviare a questi inconvenienti, Genius presenta un'interfaccia user-friendly, basato su EnginFrame, e utilizza il middleware glite per accedere, attraverso un comune web browser, ai servizi messi a disposizione dal Grid. Ci troviamo di fronte ad un sistema di semplice utilizzo, e allo stesso tempo basato su un'interfaccia web. EnginFrame è un software per la creazione e la gestione di Grid Portals basato su standard quali Java, XML, HTML, XSL, HTTP. EnginFrame è, ad ora, uno dei principali Grid Portal commerciali presenti a livello mondiale. EnginFrame è quindi un framework per il portale basato su tecnologia Java Web Servlet, per la creazione delle interfacce di alto livello, in grado di mediare il dialogo tra l'utente ed i diversi tipi di middleware computazionali a basso livello. Essendo un software proprietario, prevede delle restrizioni sul suo utilizzo, e viene distribuito attraverso una licenza a pagamento. Pagina 21 di 146

22 3.3.2 P-Grade P-Grade Portal (Parallel Grid di run-time e Application Development Environment) è un portale web che fornisce un ambiente grafico per eseguire operazione di gestione del certificato, sottomissione e trasferimento di job e file e recuperare informazioni sull'infrastruttura. Grazie all'uso di una semplice interfaccia grafica, il tempo per riuscire ad imparare ad utilizzare i comandi Grid è stato significativamente ridotto, grazie anche all'utilizzo di alcuni tool presenti sul portale. Quest'ultimo contiene, inoltre alcuni strumenti, non presenti in glite, come il Workflows e lo studio dei parametri, che può essere definito e gestito da un editor grafico. P-Grade nasconde la struttura della griglia e dei meccanismi di accesso al sistema, in modo tale da risultare trasparenti per l'utente. Figura 8 - Finestra gestione certificato di P-Grade Purtroppo il portale è stato sviluppato principalmente su WebSphere, un brand di IBM, che rappresenta una sorta di middleware software, usato per definire ed interagire con applicazioni e-business. WebSphere è un Application Server che implementa la specifica Java 2EE. E' un software proprietario, per cui per poterlo utilizzare è necessario acquistare una licenza. Pagina 22 di 146

23 4 Analisi dei requisiti e progettazione Nel capitolo precedente ho trattato le soluzioni attualmente presenti sul mercato. Partendo dalle interfacce testuali, scomode da utilizzare per utenti non esperti, si è passato alle applicazioni stand-alone grafiche, molto più comode e semplici ma dipendenti dal sistema operativo per le quali venivano sviluppate. L'attenzione si è poi spostata sui portali web, che permettono un accesso e utilizzo delle user interface direttamente tramite un browser. Purtroppo esistono solo soluzioni basate su progetti a pagamento o closed. Un ulteriore problema riguarda la sicurezza, in quanto tutte le soluzioni presentate prevedono che il certificato utente sia copiato sul server e che venga successivamente utilizzato per creare il certificato proxy temporaneo. Nel caso in cui il certificato venisse acquisito o copiato da altri, si riuscirebbe ad avere un accesso senza limiti di tempo alla griglia. In questo lavoro di tesi si è cercato perciò di superare le problematiche appena discusse, creando una web user interface che rappresentasse un punto unico di accesso per poter effettuare le vari operazioni sulla griglia e che sia basata su un prodotto open-source. Riassumiamo brevemente le caratteristiche principali che l'applicazione dovrebbe avere: User Friendly: in quanto presenta un'interfaccia orientata all'utente, intuitiva e facile da utilizzare; Accessibile via web: per eseguire l'applicazione è necessario connettersi al portale web che la ospita, utilizzando un web browser che supporta la tecnologia Java; Cross platform: in quanto l'applicazione può essere eseguita indipendentemente dal sistema utilizzato, essendo sviluppata in Java; Compatibile con glite: rispecchia la maggior parte delle funzionalità presenti in glite; Sicura: perchè a differenza delle soluzioni precedenti, il certificato utente X.509 non verrà inviato direttamente al server. Infatti sarà possibile creare un certificato temporaneo detto proxy. Il proxy, con una durata limitata a 12 ore, permetterà di eseguire tutte le operazioni sul Grid, quali la sottomissione e il controllo dei job. Pagina 23 di 146

24 4.1 Specifica dei requisiti di sistema Il sistema è sostanzialmente suddiviso in due unità: il client e il server; il client è una piccola applicazione che ha lo scopo di autenticare l'utente, e permette di creare un certificato temporaneo utilizzato per accedere a tutti i servizi della griglia per un tempo limitato, mentre il server ospita il portale e la web user interface. Figura 9 Le 2 sezioni principali dell'applicazione L'autenticazione viene resa possibile tramite una piccola applicazione che l'utente scarica dal portale web; non necessita di installazione e una volta eseguita mostrerà una piccola procedura guidata ( wizard ) che guiderà l'utente nella fase di autenticazione. Il primo passo sarà quello di selezionare un certificato x509, rilasciato preventivamente da una Certification Authority e successivamente inserire la password usata per esportare il certificato dal browser internet. Nell'ultima fase l'applicazione invierà i dati al server. Nessun file, tranne che il certificato proxy, verrà copiato sul server. Ciò permette di migliorare la sicurezza, evitando che il certificato x509 venga copiato altrove. Il server esegue invece l'applicazione web vera e propria, con la quale l'utente interagisce, formata da varie schermate che guidano l'utente nella gestione dei job, del data management e Pagina 24 di 146

25 dell'information system. Per quanto riguarda la gestione dei job, ogni utente sarà in grado di sottometterne uno secondo tre modalità differenti. Nella prima, l'utente può caricare direttamente il file che contiene il codice del job, ovvero il file JDL, memorizzato sulla sua macchina; nella seconda potrà scrivere il codice in un editor di testo; nella terza si troverà davanti una schermata con delle linee guida sul codice da inserire. Ogni job sottomesso sul Grid è identificato da un numero univoco, un ID, che rappresenta l'unica informazione che permette di tenere traccia del job, che può essere utilizzato per recuperare informazioni e per eseguire operazioni sul job stesso. Sarà il sistema ad occuparsi dell'archiviazione di questo valore, caricando i dati in un database e associando ogni ID all'utente e al nome del job, che verrà mostrato in una tabella nella home. Ogni utente avrà la possibilità di controllare lo stato del job, e altre informazioni relative ad esso, semplicemente cliccando su un pulsante. Ogni job non ancora eseguito potrà essere cancellato inviando una richiesta al grid; una volta cancellato un job non sarà più possibile recuperarlo. Se il job lo prevede, l'utente potrà recuperarne l'output, una volta che avrà terminato la sua l'esecuzione. Le operazioni che riguardano il data management, permettono all'utente di copiare e recuperare dei dati verso/da i vari Storage Element (SE) e LFC (LCG File Catalog), che registra e tiene traccia dei file logici e fisici. In ultima analisi, è possibile recuperare informazioni sul sistema, tra cui informazioni sul computing Element (CE), Storage Element (SE), LFC (LCG File Catalog), TAG (il software presente su ogni CE). Pagina 25 di 146

26 Requisiti Funzionali il sistema è una web user interface la cui funzione principale consiste nel permettere agli utenti di accedere e gestire i job in un sistema grid, di recuperare informazioni sul sistema Grid e di salvare/recuperare i dati sui vari Storage Element Il sistema permette di effettuare l'autenticazione tramite un certificato personale x509 il sistema permette di inviare dei job al sistema grid il sistema permette di controllare lo stato di ogni job appartenente all'utente il sistema permette di eliminare i job appartenenti all'utente il sistema permette di recuperare l'output dei job appartenenti all'utente. Il sistema segnala eventuali errori attraverso dei messaggi chiari che comprendono il motivo di tale errore il sistema permette di recuperare informazioni relative agli Storage Element, Computing Element, LFC e TAG il sistema permette di inviare e recuperare file dai vari Storage Element e di registrarli tramite LFC Pagina 26 di 146

27 4.2 Use Case Diagram Figura 10 - Use Case Diagram relativo alla gestione dei job Un utente, per poter utilizzare le funzionalità dell'applicazione, deve prima creare un certificato proxy. Una volta convalidato il certificato proxy, l'utente può sottomettere un job, o inserendo le istruzioni secondo il Job Description Language (JDL) in un'apposita area, oppure caricando sul server il file.jdl che identifica il job; controllare lo stato di un job tramite l'id univoco assegnato ad ogni job; cancellare un job tramite il suo id; recuperare l'output di un job se eventualmente sono stati specificati dei file di output per il job. Pagina 27 di 146

28 Figura 11 - Use Case Diagram relativo al Data Management Il sistema dovrà essere in grado di gestire l'invio e la ricezione di file da e verso gli Storage Element. Un utente potrà infatti decidere di inviare un file ad uno specifico SE, oppure recuperarlo. Inoltre per tenere traccia della corrispondenza fra file logici e fisici, è necessario registrare il file sull'lfc. Figura 12 - Use Case Diagram relativo all'information System Pagina 28 di 146

29 Nell'ultimo Use Case, vengono mostrate le operazioni permesse all'utente riguardo il recupero delle informazioni riguardante i componenti del sistema Grid. Sarà infatti possibile avere informazioni circa gli Storage Element, i Computing Element, l'lfc e il software installato sui vari CE. 4.3 Rappresentazione dei casi d'uso tramite tabelle di Cockburn Creazione del certificato proxy USE CASE #1 Creazione del certificato proxy Obiettivo L'utente deve poter creare il certificato proxy Precondizioni Il server deve essere online, l'utente deve aver avviato l'applicazione per la creazione del proxy Condizioni di Successo L'utente riesce a creare il certificato proxy Condizioni di Fallimento L'utente non riesce a creare il certificato proxy Attore Primario Utente Trigger Avvia l'applicazione client Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente seleziona il certificato personale e la password 2 Recupera il certificato e la password relativa 3 Crea il certificato proxy 4 Salva il certificato nella cartella utente 5 Ritorna alla schermata Pagina 29 di 146

30 principale Estensione 1 Il Job non può essere sottomesso a causa di un errore sul certificato errato N Passo Azione Utente 4(b) Variazione 2 Azione Sistema Mostra una finestra di errore L'utente decide di non creare più il proxy N Passo 1(b) Azione Utente Azione Sistema L'utente clicca sul pulsante Annulla 2(b) Elimina eventuali file temporanei 3(b) Ritorna alla Home Sottomissione del job tramite scrittura del file JDL USE CASE #1 Sottomissione del job tramite scrittura del file JDL Obiettivo L'utente deve poter sottomettere il job sulla griglia scrivendo il codice del job Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver scritto il codice del job nell'apposito campo. Condizioni di Successo L'utente sottomette correttamente il job Condizioni di Fallimento L'utente non riesce a sottomettere il job Attore Primario Utente Trigger Click sul tasto Completa Descrizione Pagina 30 di 146

31 dei passi Descrizione dei passi Estensione 1 N Passo 1 Azione Utente L'utente clicca sul tasto per l'invio del Job 2 Crea un file temporaneo 3 Invia il file al middleware 4 Recupera l'id del job 5 Ritorna alla schermata principale 6 Visualizza l'id del job appena caricato Il Job non può essere sottomesso a causa di un errore sul proxy N Passo Azione Utente 4(b) Variazione 1 Azione Sistema Azione Sistema Mostra una finestra di errore L'utente deve caricare alcuni file nell'inputsandbox N Passo Azione Utente 1(b) L'utente clicca sul pulsante sfoglia 2(b) Seleziona un file da caricare. 3(b) Clicca sul pulsante Completa Azione Sistema 4(b) Crea un file temporaneo che identifica il job 5(b) Carica il file selezionato per l'inputsandbox 6(b) Invia il file al middleware Pagina 31 di 146

32 Variazione 2 7(b) Recupera l'id del job 8(b) Ritorna alla schermata principale 9(b) Visualizza l'id del job appena caricato L'utente decide di non inviare più il Job N Passo 1(b) Azione Utente Azione Sistema L'utente clicca sul pulsante Annulla 2(b) Elimina eventuali file temporanei 3(b) Ritorna alla Home Sottomissione del job tramite upload del file JDL USE CASE #1 Sottomissione del job tramite l'upload del file JDL Obiettivo L'utente deve poter sottomettere il job sulla griglia effettuando l'upload del file.jdl Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato il file nell'apposito campo. Condizioni di Successo L'utente sottomette correttamente il job Condizioni di Fallimento L'utente non riesce a sottomettere il job Attore Primario Utente Trigger Click sul tasto Completa Descrizione dei passi Descrizione dei passi N Passo Azione Utente Azione Sistema Pagina 32 di 146

33 1 Estensione 1 L'utente clicca sul tasto per l'invio del Job 2 Invia il file al middleware 3 Recupera l'id del job 4 Ritorna alla schermata principale 5 Visualizza l'id del job appena caricato Il Job non può essere sottomesso a causa di un errore sul proxy N Passo Azione Utente 4(b) Variazione 1 Mostra una finestra di errore L'utente deve caricare alcuni file nell'inputsandbox N Passo Variazione 2 Azione Sistema Azione Utente 1(b) L'utente clicca sul pulsante sfoglia 2(b) seleziona un file da caricare. 3(b) slicca sul pulsante Completa Azione Sistema 4(b) Carica il file selezionato per l'inputsandbox 5(b) Invia il file al middleware 6(b) Recupera l'id del job 7(b) Ritorna alla schermata principale 8(b) Visualizza l'id del job appena caricato L'utente decide di non inviare più il Job Pagina 33 di 146

34 N Passo 1(b) Azione Utente Azione Sistema L'utente clicca sul pulsante Annulla 2(b) Elimina eventuali file temporanei 3(b) Ritorna alla Home Recuperare lo stato di un job USE CASE #1 Recuperare lo stato di un job Obiettivo L'utente deve poter leggere lo stato attuale in cui si trova un job Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato l'id del job da controllare. Condizioni di Successo L'utente riesce a recuperare lo stato del job Condizioni di Fallimento L'utente non riesce a recuperare lo stato del job Attore Primario Utente Trigger Click sull' ID di un job Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente seleziona l'id di un job 2 Mostra la schermata relativa al job selezionato 3 Mostra tutte le informazioni relative al job selezionato Pagina 34 di 146

35 Estensione 1 Il Job non può essere controllato a causa di un errore sul proxy N Passo Azione Utente 4(b) Azione Sistema Mostra una finestra di errore Cancellare un job USE CASE #1 Cancellare un job Obiettivo L'utente deve poter cancellare un job Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato l'id del job da cancellare. Condizioni di Successo L'utente riesce a cancellare il job Condizioni di Fallimento L'utente non riesce a cancellare il job Attore Primario Utente Trigger Click sul pulsante Cancella Job nella schermata relativa al job selezionato Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante Cancella Job 2 Recupera l'id del job 3 Invia la richiesta di eliminazione al Grid 4 Elimina il job 5 Elimina l'id del job dal database 6 Ritorna alla Home Pagina 35 di 146

36 Estensione 1 Il Job non può essere controllato a causa di un errore sul proxy N Passo Azione Utente 4(b) Azione Sistema Mostra una finestra di errore Recuperare l'output di un job USE CASE #1 Recuperare l'output di un job Obiettivo L'utente deve poter recuperare l'output di un job Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato l'id del job da cui recuperare l'output, e il job deve essere stato completato. Condizioni di Successo L'utente riesce a recuperare l'output del job Condizioni di Fallimento L'utente non riesce a recuperare l'output del job Attore Primario Utente Trigger Click sul pulsante Scarica nella schermata relativa al job selezionato Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante Scarica File 2 Recupera l'id del job 3 Invia la richiesta per l'output al Grid 4 Recupera i file il job 5 Ritorna alla schermata dello stato del job Pagina 36 di 146

37 Estensione 1 Il Job non può essere controllato a causa di un errore sul proxy N Passo Azione Utente 3(b) Azione Sistema Mostra una finestra di errore Recuperare un file da un SE USE CASE #1 Recuperare un file memorizzato su un SE Obiettivo L'utente deve poter recuperare il file Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato il pulsante per il recupero del file Condizioni di Successo L'utente riesce a recuperare il file Condizioni di Fallimento L'utente non riesce a recuperare il file Attore Primario Utente Trigger Click sul pulsante per il recupero del file Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante Get File 2 Recupera il file dall'se in cui è memorizzato 3 Lo copia sulla User Interface 4 Mostra una finestra di download all'utente Pagina 37 di 146

38 Estensione 1 Il file non può essere recuperato a causa di un errore sul proxy N Passo Azione Utente 2(b) Estensione 2 Azione Sistema Mostra una finestra di errore Il file non può essere recuperato perchè inesistente N Passo Azione Utente 2(b) Azione Sistema Mostra una finestra di errore Carica un file su un SE USE CASE #1 Inviare un file su un SE Obiettivo L'utente deve poter caricare il file Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato il file da caricare Condizioni di Successo L'utente riesce a caricare il file Condizioni di Fallimento L'utente non riesce a caricare il file Attore Primario Utente Trigger Click sul pulsante per il carica file Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante Copy 2 Carica il file sulla User Interface 3 Invia il file al Grid Pagina 38 di 146

39 4 Estensione 1 Recupera l'id del file Il file non può essere caricato a causa di un errore sul proxy N Passo Azione Utente 3(b) Azione Sistema Mostra una finestra di errore Carica e registra un file sull'lfc USE CASE #1 Inviare un file su un SE e registrarlo nell'lfc Obiettivo L'utente deve poter caricare e registrare il file Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver selezionato il file da caricare Condizioni di Successo L'utente riesce a caricare e registrare il file Condizioni di Fallimento L'utente non riesce a caricare e registrare il file Attore Primario Utente Trigger Click sul pulsante per il carica file Descrizione dei passi Descrizione dei passi N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante Copy & Register 2 Carica il file sulla User Interface 3 Invia il file al Grid e lo registra 4 Recupera l'id del file Pagina 39 di 146

40 Estensione 1 Il file non può essere caricato a causa di un errore sul proxy N Passo Azione Utente 3(b) Azione Sistema Mostra una finestra di errore Recuperare informazioni riguardanti i componenti del Grid USE CASE #1 Recuperare informazioni circa un SE Obiettivo L'utente deve poter recuperare le informazioni sull'se Precondizioni Il server deve essere online, il certificato temporaneo dell'utente deve essere ancora valido, e l'utente deve aver cliccato sul pulsante SE List Condizioni di Successo L'utente riesce a recuperare le informazioni Condizioni di Fallimento L'utente non riesce a recuperare le informazioni Attore Primario Utente Trigger Click sul pulsante SE List Descrizione dei passi Descrizione dei passi Estensione 1 N Passo 1 Azione Utente Azione Sistema L'utente clicca sul pulsante SE List 2 Recupera le informazioni sull'se 3 Mostra i dati sulla pagina web Il file non può essere caricato a causa di un errore sul proxy N Passo 2(b) Azione Utente Azione Sistema Mostra una finestra di errore Pagina 40 di 146

41 4.4 Analisi dell'architettura Il sistema prevede un'architettura di tipo Model Control View, grazie al quale si ha un controllo centralizzato dell applicazione, implementato da una portlet di controllo che gestisce tutte le richieste e le soddisfa delegando l elaborazione a opportune classi Java. In questo modello i ruoli di presentation, control e business logic vengono affidati a componenti diversi e sono tra di loro disaccoppiati, con evidenti vantaggi in termini di riusabilità, manutenibilità, estensibilità e modularità. Le 3 componenti principali possono essere schematizzate come di seguito: Controller: le classi che gestiscono il flusso di esecuzione dell applicazione e garantiscono la comunicazione tra il Model e la View; ne fanno parte l'intera portlet a cui si aggiungono anche una serie di classi di utilità. Model: le classi che definiscono lo stato dell'applicazione e le sue funzionalità. E' identificato dal sistema Grid e dalle funzionalità che esporta all'esterno. View: le pagine web che realizzano le interfacce utente. Sia il controller che il model sono costituiti da classi java, in modo da garantire un'elevata portabilità e sicurezza. Il model contiene una classe java che comunica con il sistema Grid, inviando i dati e recuperando le informazioni ottenute dopo l'esecuzione di determinate istruzioni. Infine la view è formata dalle pagine html e jsp che acquisiscono i dati di input dell'utente e mostrano a video il risultato dell'interazione. Pagina 41 di 146

42 Figura 13 Schema generale del sistema Per un corretto funzionamento del sistema, in base alle funzionalità che quest'ultimo deve esportare all'esterno, è necessario creare una serie di componenti diverse ed indipendenti tra loro che svolgano i compiti richiesti. Prima di tutto c'è bisogno di un modulo centrale che gestisca il flusso di dati, come specificato nel paragrafo precedente, fra il model e la view, una sorta di controllore. Considerando che l'utente dovrà interagire con il sistema tramite delle interfacce grafiche, queste ultime dovranno essere in grado sia di acquisire gli input dell'utente sia di mostrare eventuali output o nuovi stati del sistema. Essendo il sistema un'applicazione web, per far ciò si è pensato di utilizzare delle pagine web dinamiche che variano il loro contenuto in base allo stato del sistema. Prendiamo adesso in esame le varie funzionalità del sistema. Come prima cosa, l'utente deve essere in grado di creare un certificato temporaneo, detto proxy, per poter usufruire del sistema Grid. La creazione del proxy è relegata ad un componente esterno, che mostrerà all'utente una sorta di procedura guidata, guidandolo passo passo nella creazione del proxy. Basterà seguire le istruzioni a video, mentre tutte le operazioni saranno a carico del Pagina 42 di 146

43 componente. Per quanto riguarda gli altri moduli per la gestione dei job, verranno creati appositamente in modo da poter utilizzare delle API di glite, in grado di interagire con il sistema Grid. I moduli dovranno essere in grado di sottomettere dei job partendo dalle specifiche richieste dall'utente, e di recuperarne l'id; dovranno interrogare il sistema Grid per recuperare lo stato dei job partendo dal loro ID; essere in grado di recuperare eventuali output presenti sul sistema per un job terminato correttamente e infine cancellare un job qualora non fosse ancora terminato e su richiesta dell'utente. Per quanto riguarda le informazioni relative all'information System, abbiamo un unico modulo che si occupa di inviare e recuperare le informazioni sul sistema. Sarà poi compito del controller gestire questi dati e inviarli alla view affinchè vengano visualizzati. Infine abbiamo un ultimo modulo che si occupa dell'invio e ricezione dei file sullo Storage Element. Quest'ultimo dovrà essere in grado di caricare un file scelto dall'utente, ed inviarlo ad un SE, recuperando l'id del file. Nel caso in cui l'utente lo richieda, dovrà anche registrare il file sull'lfc oppure recuperare il file memorizzato sull'se. A fronte di queste specifiche, possiamo suddividere le varie componenti come mostrato nell'elenco seguente: Web Application: Rappresenta il core dell'intera applicazione; gestisce le componenti a cui è associato per elaborare i dati ricevuti dal client, invia i dati e e riorganizza gli output del sistema. View Unit: E' formata dalle componenti che servono all'acquisizione dei dati di input, come il codice del job o i file necessari alla sua esecuzione, sia quelle necessarie a mostrare l'output del sistema, come lo stato di un job. Comprende perciò tutte le interfacce grafiche con cui l'utente interagisce e su cui controlla lo stato di ogni interazione, quindi le pagine html e jsp. Log Class: Unità necessaria a tenere traccia di tutti gli errori che si verificano durante Pagina 43 di 146

44 l'esecuzione. CancelJob Class: E' il componente a cui è delegata la cancellazione del job richiesto dall'utente Status Class: E' la componente che interroga il sistema Grid, per recuperare lo stato attuale di un job. Output Class: La componente recupera l'output di un job terminato con successo. Di solito si tratta di pochi file, che l'utente può scaricare. Sql Class: La componente ha il compito di gestire tutte le comunicazioni con il database centrale, che tiene traccia degli utenti e del job corrispondenti. SubmitJob Class: E' la componente che si occupa dell'invio dei file al Grid, sia che si tratti dei job, sia i file necessari a quest'ultimo per essere eseguito. Certificate Class: E' la componente utilizzata per la creazione del certificato. Wmproxy API: Rappresentano le API che servono per comunicare con il sistema Grid. Information Class: Si occupa di recuperare informazioni relative al Grid Data_Management_Calss: Si occupa di caricare, registrare e recuperare i file presenti su un determinato SE Pagina 44 di 146

45 4.5 Diagramma delle Classi Figura 14 Diagramma delle Classi Pagina 45 di 146

46 4.6 Sequence Diagram Creazione del certificato temporaneo proxy Figura 15 Sequence Diagram relativo alla creazione del proxy Pagina 46 di 146

47 Sottomissione del job tramite upload del file jdl Figura 16 Sequence Diagram relativo alla sottomissione di un job Pagina 47 di 146

48 Sottomissione del job tramite scrittura nell'editor del file jdl Figura 17 Sequence Diagram relativo alla sottomissione di un job tramite scrittura Pagina 48 di 146

49 Recuperare lo stato di un Job Figura 18 Sequence Diagram relativo al recupero dello stato di un job Pagina 49 di 146

50 Cancellare un Job Figura 19 Sequence Diagram relativo all'eliminazione di un job Pagina 50 di 146

51 Recuperare l'output di un job Figura 20 Sequence Diagram relativo al recupero dell'output di un job Pagina 51 di 146

52 Recuperare informazioni sul sistema Grid Figura 21 Sequence Diagram relativo al recupero delle informazioni sui componenti Grid Pagina 52 di 146

53 Copiare un file sullo Storage Element Figura 22 Sequence Diagram relativo alla copia del file sullo Storage Element Pagina 53 di 146

54 Copiare e registrare un file sullo Storage Element e LFC Figura 23 Sequence Diagram relativo alla copia e registrazione del file sullo Storage Element e LFC Pagina 54 di 146

55 5 La Web User Interface: moduli software e strategie implementative Le caratteristiche principali che il progetto deve rispettare sono la portabilità, la semplicità di utilizzo tramite interfacce grafiche e la possibilità di avere un punto unico di accesso via web. Per realizzare il sistema quindi, era necessario far uso di un linguaggio quanto più portabile possibile, che permettesse la creazione di un'applicazione che potesse funzionare interamente in un browser web, senza che l'utente debba installare nulla. La scelta perciò è ricaduta su le web application, ed in particolare sulle portlet, costituite interamente da classi java. Queste ultime, eseguite da un portlet container, permettono di accedere al sistema oltre che in maniera grafica, anche direttamente da un browser web. In aggiunta, è stata utilizzata anche la java web start, affinchè si potesse creare, direttamente sulla macchina dell'utente in modo da evitare problemi di sicurezza, il certificato temporaneo per l'utilizzo del proxy. Nei paragrafi successivi verranno analizzate queste soluzioni. 5.1 Modulo di Autenticazione Per poter utilizzare il sistema, è necessario autenticarsi tramite un certificato x509, fornito da una CA. Una volta ottenuto il certificato, quest'ultimo dovrà essere esportato dal browser in modo da ottenere cosi un file in formato p12. Partendo dal certificato in formato p12, si dovrà essere creato un ulteriore certificato, chiamato certificato proxy o semplicemente proxy, che servirà ad utilizzare tutte le funzionalità della web user interface. Questo certificato ha una validità temporanea, normalmente intorno alle 12 ore, ed è memorizzato sul server che esegue la user interface. La modalità di autenticazione è molto semplice. L'utente avvia una piccola applicazione dal browser internet, chiamata Java Web Start, che si occuperà, tramite una procedura guidata, di aiutare l'utente nella fase di autenticazione. Pagina 55 di 146

56 5.1.1 Strumenti utilizzati: Java Web Start Java Web Start è un framework, sviluppato dalla Sun Microsystem, che permette agli utenti di eseguire applicazioni software, per la piattaforma Java, direttamente da internet e usando un browser web. A differenza delle applet, queste applicazioni non vengono eseguite all'interno del browser. Questa modalità di esecuzione permette di superare i problemi di incompatibilità che spesso si presentano con i plug-in Java presenti nei browser. Le caratteristiche principali della Java Web Start sono: Distribuzione tramite internet: la distribuzione delle applicazioni avviene tramite internet e attraverso un browser web. Esecuzione autonoma: una volta scaricate le applicazioni, queste non necessitano del browser per essere eseguite, in quanto presentano una loro finestra e un loro ambiente di esecuzione. Applicazioni firmate: è possibile firmare le applicazioni in modo da permettere un accesso controllato al computer client nel quale vengono eseguite. Questa caratteristica le differenzia dalle applicazioni non firmate, le quali vengono eseguite in un ambiente detto sandbox. In questo ambiente vengono eseguire applicazioni che non sono state verificate, e che quindi potrebbero essere potenzialmente pericolose. Essendo eseguite nell'ambiente sandbox, a queste applicazioni viene negato l'accesso alla macchina client. Strettamente collegato a Java Web Start, troviamo il protocollo JNLP (Java Network Launching Protocol), definito da uno schema XML, e specifico per lanciare applicazioni JWS. JNLP consiste in un insieme di regole, che definiscono esattamente come implementare il meccanismo per permettere l'esecuzione delle applicazioni JWS. Le informazioni presenti nei file JNLP riguardano la posizione dei file Jar da eseguire, il nome della classe principale dell'applicazione e altri parametri utili al programma. Tramite una configurazione adeguata del browser, i file JNLP scaricati dalle pagine internet vengono passati alla Java Runtime Pagina 56 di 146

57 Environment (JRE) che provvede a scaricare l'applicazione sulla macchina dell'utente e ad eseguirla. L'intera operazione ha inizio esclusivamente quando l'utente effettua un click su un link presente nella pagina web, mentre le successive fasi, fino all'esecuzione dell'applicazione, sono completamente trasparenti all'utente. Un'altra caratteristica delle JWS, è quella di scaricare ed installare automaticamente, in caso il computer dell'utente ne fosso sprovvisto, l'ultima versione disponibile di JRE. Vediamo in che modo vengono eseguite le applicazioni JWS. Nel complesso possiamo dividere il processo in 3 fasi: L'utente clicca sul link presente sulla pagina web; Il browser invia l'url al web server, il quale restituisce al client un file JNLP (invece di un file HTML) collegato all'applicazione da eseguire; Una volta eseguito il file JNLP, quest'ultimo si farà carico di richiedere il file jar (vedi figura successiva), che rappresenta l'applicazione da eseguire, restando in attesa fino a che il recupero di tutte le risorse necessarie al programma non sarà completato e infine eseguirà l'applicazione. Figura 24 Download dell'applicazione Pagina 57 di 146