È proprio in un contesto di Griglia che questa tesi viene svolta, ed in

Introduzione

La popolarità di Internet e la disponibilità di potenti elaboratori e di reti ad elevate prestazioni stanno cambiando il modo con il quale oggi vengono usati i calcolatori. Infatti, oggi è possibile organizzare una vasta gamma di risorse computazionali e di dispositivi distribuiti geograficamente, come un’unica risorsa computazionale. Tale insieme viene comunemente indicato con i termini Griglia Computazionale (Computational Grid) o, semplicemente, Griglia (Grid) [1, 2].

Essa rappresenta un insieme coordinato di risorse geograficamente distribuite e condivise in maniera dinamica da utenti appartenenti ad organizzazioni virtuali (VO) [3], che sono collezioni dinamiche di individui, di istituzioni e di risorse che definiscono chiaramente e accuratamente: che cosa è condiviso, a chi è permesso condividere e le condizioni sotto cui occorre la condivisione.

È proprio in un contesto di Griglia che questa tesi viene svolta, ed in

particolare l’argomento che viene affrontato riguarda il resource management in

un tale ambiente. È importante notare che in una Griglia una risorsa non è vista

solo come il processore, la memoria o lo spazio disco di un computer, ma anche

come dei dati o dei metadata utilizzabili da chiunque faccia parte della Griglia.

Il Resource Management costituisce un’importante componente di una griglia computazionale e il suo scopo principale è di schedulare efficientemente le richieste delle applicazioni sulle risorse utilizzabili, inoltre fornisce dei meccanismi di controllo delle autorizzazioni e di monitoring ed adotta delle politiche di Accrediting, Reclamation, Allocation e naming delle risorse.

Negli ultimi anni, nei settori e-business ed e-commerce si è avuto un sempre maggiore interesse verso le griglie computazionali. Ciò ha portato l’ambiente scientifico, le grandi aziende e le multinazionali, come ad esempio la IBM, ad investire in progetti in cui sono coinvolte le tecnologie Grid.

La tesi si inserisce nel contesto di un progetto, finanziato dalla comunità europea e svolto da partner europei, chiamato GRid Application Service Provision ( GRASP) [38]. Le finalità del progetto GRASP sono quelle di studiare, progettare, sviluppare e validare un’infrastruttura innovativa per l’Application Service Provision (ASP) basata su tecnologie Grid e commodity (come Microsoft .NET, Web Services [2, 12, 13, 21, 22], XML [39], SOAP [2, 12, 13, 21, 22], ecc.). Il core dell’infrastruttura GRASP è dato dal Service Instantiator, Service Locator e Service Orchestartor che sono dei servizi (saranno realizzati come servizi di Griglia) dell’ambiente GRASP atti a fornire funzionalità per la gestione sia delle richieste di servizi che dei servizi offerti da vari provider.

Nella tesi è stato sviluppato uno di questi servizi, il Service Locator, che ha il compito di individuare i servizi ed i relativi fornitori in un ambiente GRASP.

Come in una Griglia anche in un ambiente GRASP le risorse sono distribuite e condivise da organizzazioni virtuali (VO). In ciascuna VO sarà presente un service Locator che, tramite un service directory, pubblica, cerca e gestisce le informazioni relative ai servizi forniti dai provider presenti nella VO.

In fase di progettazione del Service Locator è stato deciso di utilizzare come

service directory il registro UDDI [28] fornito dal sistema operativo Windows

Server 2003 [40]. Inoltre è stata fornita un’architettura del Service Locator in cui

sono previsti tre thread (principali) utilizzati per: ricevere le richieste da parte di

uno (o più) client che può essere un Provider, un Requestor o un altro Locator, inviare le richieste ad altri Locator dell’ambiente in caso di ricerca (distribuita) di un servizio, interagire con il registro UDDI per inserire/aggiornare/cancellare/cercare un servizio. La scelta dei tre thread permette di sfruttare due livelli di parallelismo che permettono di soddisfare più richieste contemporaneamente. L’interazione con il registro UDDI, fornito dal Windows Server 2003, ha richiesto uno studio dello UDDI stesso per quanto riguarda le modalità di inserzione e cancellazione delle informazioni riguardanti i servizi ed i provider che li forniscono. Inoltre, in UDDI tali informazioni sono

“catalogate” secondo degli schemi di categorizzazione, che sono dei file XML che descrivono come le informazioni riguardanti un servizio possono essere memorizzate o cercate. Per questo motivo è stato necessario realizzare uno schema ad-hoc per l’ambiente GRASP, il GrASPCategorizationSchema, che nell’attuale versione del Service Locator prevede tre categorie (Category, Price, QoS) che contengono delle sottocategorie, tramite cui è possibile aggiungere o cercare un servizio nel registro UDDI.

In fase di implementazione è stato utilizzato un ambiente di sviluppo fornito da Microsoft, il Visual Studio .Net 2003 [27], ed il linguaggio di programmazione utilizzato in tale ambiente è stato il C# [27].

Per verificare che il comportamento del Service Locator rispondesse alle specifiche di progetto sono stati effettuati dei test con dati di input conformi ai requisiti previsti per tale servizio in fase di progettazione ed altri dati non conformi a tali requisiti. Inoltre è stato fatto un confronto con un servizio di Griglia, detto ServiceGroup

, presente nell’ambiente runtime del toolkit di Globus ( GT3 [33]). Tale servizio è conforme alle specifiche definite dalla Open Grid Service Architecture (OGSA) [3]. Tale confronto è stato fatto per verificare se anche il Service Locator realizzato è un servizio conforme a tali specifiche.

1

ServiceGroup: è un servizio di Griglia che mantiene informazioni riguardanti altri

Infine è stato descritto e valutato il ruolo del Service Locator all’interno dell’infrastruttura core dell’ambiente GRASP, denominata Preliminary Infrastructure Prototype Instantiation/Location/Orchestration (PIP_ILO). Tale infrastruttura è costituita, oltre che dal Service Locator, anche dal Service Instantiator e dal Service Orchestrator. Anche in questo caso, come per il service Locator, sono stati effettuati dei test per verificare che il comportamento del prototipo fosse conforme ai requisiti funzionali stabiliti in fase di progettazione.

La tesi è strutturata in sette capitoli di cui: i primi due introduttivi, il terzo ed il quarto illustrano gli strumenti utilizzati ed il contesto in cui si è svolto il lavoro, il quinto espone come il service Locator è stato realizzato, il sesto mostra le interazioni del Service Locator con il Service Instantiator ed il Service Orchestrator all’interno dell’infrastruttura GRASP, mentre il settimo chiude la tesi con le conclusioni relative al lavoro svolto.

Nel primo capitolo sono illustrate le Griglie computazionali, la loro architettura, le risorse che possono essere presenti in una tale Griglia ed alcuni strumenti esistenti utilizzati per gestirle.

Nel Capitolo 2 illustriamo quali sono le specifiche definite da OGSA, introduciamo il concetto di Grid Service e forniamo un insieme di convenzioni (interfacce e comportamenti) che definiscono come un client può interagire con il servizio stesso.

Nel Capitolo 3 sono illustrati gli strumenti utilizzati per lo sviluppo del service Locator. Abbiamo descritto le caratteristiche di ciascuno strumento ed il ruolo che ciascuno assume nella fase di implementazione del servizio.

Nel Capitolo 4 è stato introdotto il progetto GRASP e quali sono gli obiettivi

che in tale progetto si intendono raggiungere. Inoltre, in questo capitolo sono

descritte le attività svolte dai componenti e dai servizi presenti in un ambiente

GRASP e le loro interazioni e viene data una descrizione delle funzionalità

fornite dal Service Locator.

Nel Capitolo 5 è trattato l’intero “ciclo di vita” del Service Locator, dalla fase di progettazione alla fase di implementazione ed infine alla fase di test. Nella fase di progettazione è stata proposta una possibile architettura del Locator che è stata sottoposta al consorzio GRASP, cioè ai vari partner europei che partecipano a tale progetto. Nella fase di implementazione è stato realizzato il service Locator e le funzioni che esso fornisce. Per dare un’idea di come tale servizio sia stato realizzato, abbiamo fornito nel capitolo un diagramma UML delle classi che simulano il comportamento dei vari componenti dell’architettura proposta e dei diagrammi di flusso che mostrano quali operazioni vengono eseguite quando viene invocata una delle funzioni offerte dal Locator. Infine, nella fase di test viene verificato che il Locator soddisfi i requisiti definiti in fase di progettazione.

Nel Capitolo 6 è illustrato il core dell’infrastruttura GRASP, costituito dal Service Instantiator, dal Service Locator e dal Service Orchestrator che sono tre dei principali servizi presenti nell’ambiente GRASP. Nel capitolo mostriamo come tali servizi interagiscono tra loro per soddisfare le richieste provenienti da un client, ed effettuiamo dei test considerando l’infrastruttura usata in un contesto biomedico. Con tali test si vuole verificare che sia i comportamenti di ogni singolo servizio che la cooperazione dei servizi all’interno dell’infrastruttura GRASP soddisfino a dei requisiti prestabiliti.

Il Capitolo finale riporta le conclusioni relative al lavoro svolto e descrive la

valutazione fatta per verificare quanto il servizio implementato sia conforme alle

specifiche OGSA.