Relazione sull’attività di ricerca svolta presso IL cs departme



Scaricare 71.5 Kb.
13.11.2018
Dimensione del file71.5 Kb.


CONSIGLIO NAZIONALE DELLE RICERCHE


PROGRAMMA SHORT - TERM MOBILITY

Anno 2007

Relazione sull’attività di ricerca svolta

presso il Department of Computer Science Strathclyde University - Glasgow

dal 3 Settembre 2007 al 24 Settembre 2007.

Andrea Manzi

Istituto di Scienza e Tecnologie della Informazione “Alessandro Faedo”

Consiglio Nazionale delle Ricerche

Area della Ricerca CNR di Pisa

Via G. Moruzzi,1 – 56124 Pisa, Italy

+39 050 3152802



andrea.manzi @isti.cnr.it

Scopo del Programma


L’attività di ricerca svolta presso il Computer Science Department della Stathclyde University di Glasgow prevedeva lo studio, il design e l'implementazione di un'estensione al GT4 WS Core per il supporto allo sviluppo di servizi per il framework gCube: per la favorire l'integrazione dei servizi nella infrastruttura per Biblioteche Digitali che è stata sviluppata nell’ambito del progetto europeo DILIGENT (N° 004260) nel quale sono coinvolto.

gCube e’ il software che è stato sviluppato nell'ambito del progetto DILIGENT, che al tempo dell'attività di ricerca era giunto alla versione Beta. gCube è un framework Service Oriented composto da una serie di servizi che cooperano per:



  • la creazione e gestione di Digital Library on-demand.

  • lo sharing di contenuti e applicazioni,

  • l'accesso a sorgenti di informazione e applicazioni di terze parti

  • effettuare tipiche operazioni di una Digital Library come la ricerca, le annotazioni, la personalizzazione e la visualizzazione di documenti.

Questi servizi sono stati disegnati per sfruttare il middleware gLite in modo da sfruttare le capacità computazionali e la di memorizzazione dell'infrastruttura Grid realizzata dal progetto EGEE.

L'implementazione WSRF sfruttata dal framework gCube è quella sviluppata all'interno del Globus Toolkit 4, In particolare tutti i servizi gCube si basano su queste funzionalità del framework GT4:


  • Implementazione delle 2004/06 OASIS WSRF delle WSN specifiche working draft ,

  • JNDI-based registry basato sul JNDI Registry di Apache Tomcat,

  • Un' implementazione delle specifiche del Work Manager e del Timer

  • Un embedded container

  • Delle interfacce di base per la persistenza delle risorse e il loro recovery

  • Supporto per la Sottoscrizione a Notifiche persistenti

  • L'attivazione automatica dei servizi e delle resource home allo start-up

  • Provider di Operazioni

Molte di queste features sono sfruttate nella parte di gCube chiamata Collective Layer ( contenente i servizi base per la creazione e la gestione di digital libraries), ma non sono state integrate in maniera corretta nei servizi e in particolare ogni servizio che fa parte dei layer superiori dell'architettura ha una sua particolare interfaccia verso il Collective Layer. Il lavoro di ricerca prevedeva quindi lo studio di un 'interfaccia comune a tutti i servizi gCube per interfacciarsi ai servizi del Collective Layer e sfruttare al meglio le funzionalità offerte dalla tecnologia WSRF.

Al termine della parte di studio e design, il lavoro di ricerca prevedeva di introdurre all'interno del framework gCube i seguenti componenti/ funzionalità:


  • Il supporto al DILIGENT Provider, un GT4 provider di operazioni per permettere ai servizi gCube di pubblicare informazioni sul gCube Information System (DIS).

  • Un'estensione ad-hoc di alcuni concetti del WS-Core ( Resource, Resource Home, Persistent Resource).

  • L'adozione dell'handler pattern all'interno dei servizi gCube.

  • Il design di un meccanismo di logging comune.

  • Il design di un'interfaccia verso l'infrastruttura per il data management di gLite.

Per il lavoro di ricerca è stata selezionato il dipartimento di Computer Science dell'università di Strathclyde dove lavora il prof. Fabio Simeoni, facente parte del consorzio DILIGENT, che aveva iniziato l'implementazione di alcuni parti della interfaccia del framework gCube.



lavoro svolto


L’attività di ricerca svolta al CS Department è iniziata con un giorno di lavoro a contatto con il prof. Fabio Simeoni e del suo collaboratore dott. Ralf Biering, per la pianificazione delle attività da svolgere durante le tre settimane del programma. Il dott. Simeoni è stato molto disponibile fin dall'inizio e ha cercato da subito di introdurmi nell'ambiente del dipartimento, assegnandomi una postazione nel suo ufficio e operando attivamente per la gestione delle pratiche burocratiche a me relative.

settimana

Dopo il giorno di pianificazione delle attività, come concordato con il prof. Simeoni ho iniziato lo studio dell'interfaccia verso il DIS implementate dai vari servizi. Il Diligent Information Service, è composto principalmente da 3 servizi:

  • DIS-Registry: gestisce la creazione, rimozione e aggiornamento dei DILIGENT Resource Profile ( file XML corrispondenti alle entità del DILGENT Resource Model( Collezioni, Servizi, RunningInstance, MetadataCollection.))

  • DIS-IC: collettore di informazioni basato sul Globus Aggregator Framework. Memorizza sia DILIGENT Resource, sia WS-Resource-Properties Document relativi pubblicate dai vari servizi

  • DIS-Broker: gestisce il brokeraggio di notifiche in ambiente DILIGENT. Consente ai servizi di sottoscriversi a notifiche riguardo eventi relativi a DILIGENT Resources e topic generici, senza conoscere la locazione dei produttori di notifiche.

Il mio studio si è focalizzato sulle WS-Resource-properties, il meccanismo implementato in GT4 per aggiungere un componente di stato ai web-services standard. I vari servizi possono pubblicare sul DIS le proprie WS-Resurce-properties per essere poi facilmente rintracciabili: Era però necessario un set di informazioni aggiuntive per discriminare le varie WS-Resource-Properties pubblicate. Per questo ho studiato un set di attributi da associare alle Resource Property Document dei vari servizi: dallo studio sono emerse sette caratteristiche necessarie a identificare una WS-Resource-Property:



  • DHN ID: id del DHN ( DILIGENT Hosting Node), il nodo dove il servizio sta girando

  • Running Instance ID: ID della Running Instance ( istanza del Servizio) che publlica le WS-Resource-Properties

  • Service ID: ID del Servizio relativo all'instanza che pubblica le informazioni.

  • Service Name: Nome del servizio.

  • Service Class: Classe del servizio (i.e. Information System).

  • VOName: il nome della VO (Virtual Organization) di cui il servizio fa parte

  • Dls: le Digital Library in cui il servizio sta operando.

Le informazioni sopra, sono contenute nei vari DILIGENT Resource Profiles locali al nodo dei servizi, quindi possono essere ricavate facilmente e pubblicate. Per poter pubblicare queste informazioni trasparentemente ai vari servizi, ho studiato il meccanismo degli Operation Provider in GT4. Gli operation providers sono dei plugins ai servizi GT4, utilizzati per aggiungere delle operazioni alle interfacce del servizio (anche delle WS-Resource-Properties) soltanto dichiarando la loro inclusione all'interno di file di configurazione del servizio. Ho scelto questo strumento per poter implementare l'aggiunta di WS-Resource-Properties e operazioni in maniera trasparente al servizio. Quindi ho implementato gli attributi dichiarati sopra come WS-Resource-Properties di un nuovo componente ( l'operation provider) e le operazioni per valorizzarne il contenuto.

Per testare l'integrazione dell'operation provider con i servizi gCube esistenti, ho preparato un servizio di test con una WS-Resource-Properties pubblicata nel DIS. A questo punto ho esteso il Servizio con l'operation provider implementato e deployato il mio servizio nella infrastruttura di test situata al CNR. Una volta pubblicate le informazioni ho sottomesso delle query al DIS di testing, per verificare la corretta valorizzazione degli attributi.

Terminata nella prima settimana la definizione di questo nuovo componente dell'architettura DILIGENT, ho avuto un meeting con il prof. Simeoni per illustrare i miei progressi e pianificare la seconda settimana della mia attività di ricerca. Durante il fine settimana ho iniziato uno studio approfondito di quello che il framework GT4 offre per lo sviluppo di servizi WSRF. Lo scopo dello studio è stato quello di individuare le funzionalità necessarie allo sviluppo di servizi gCube, e capire come queste potessero essere estese per inglobare in maniera trasparente alcune delle funzionalità già implementate in gCube. Ho anche ripreso il lavoro già svolto dal prof. Simeoni sul framework gCube, cercando di capirne la filosofia in modo da individuare le parti dell'implementazione mancanti.


2° settimana

La seconda settimana della mia permanenza a Glasgow, è stata dedicata per la maggior parte allo studio, all'estensione e al testing del framework gCube. La parte già implementata, comprendeva una serie di classi base per definire un servizio WSRF con embedding di funzionalità:

  • gCubeResource: la classe che, estendendo la Resource di GT4, permette di definire classi di risorse che di base forniscono la pubblicazione delle WS-Resource-Properties definite nell' IS Diligent , implementazione del Resource Lifetime ( sia distruzione immediata degli oggetti, sia schedulata con definizione di un Termination Time).

  • gCubeResourceHome: la classe che, estendendo la ResourceHome GT4, consente l'accesso e la creazione di gCubeResource.

  • gCubeServiceContext: la classe che interfaccia in maniera trasparente il servizio ai suoi parametri di configurazione definiti nel JNDI file.

  • gCubePortTypeContext: è un provider di informazioni relative al PortType (specifica interfaccia del servizio).

La parte del framework implementata comprende anche delle classi che gestiscono la gestione delle eccezioni personalizzata per gCube:

  • gCubeException: estensione delle RemoteException,

  • gCubeFault: estensione della specifica base fault con la definizione di tre tipi di eccezioni utili al process management:

    • GCubeRetryEquivalentException: in caso di eccezione nell’utilizzo di una particolare istanza del servizio, la chiamata viene gestita da un istanza semanticamente equivalente;

    • GCubeRetrySameException: in caso di eccezione, il metodo viene richiamato sulla stessa istanza del servizio che ha generato l’eccezione precedentemente.

    • GCubeUnrecoverableException: l’eccezione è fatale e non gestibile.

Sicuramente la parte più innovativa della library core implementata dal prof. Simeoni, è quella relativa agli handler. Il Package gCube Handler contiene una serie di classi che permettono di definire oggetti handler: gli handler sono particolari oggetti contenenti il riferimento ad un oggetto target su cui possono effettuare delle operazioni e sono molto utili per effettuare operazioni su oggetti in maniera trasparente. Il package contiene una serie di classi per la definizione di hanlders e soprattutto per la loro composizione: è possibile infatti effettuare operazioni su più oggetti in maniera sequenziale o parallela (utilizzando i relativi sequentialHanlder e parallelHandler) oppure creare Handler complessi ( complexHandler) o anche degli Handler che effettuano delle operazioni periodiche ( SchedulerHandler).


Una volta studiato a fondo quello che era stato implementato, ho cercato di capire quali componenti gia presenti nell’architettura DILIGENT potessero essere integrati all’interno delle librerie esistenti. La cosa più naturale è stato includere il Provider implementato la settimana precedente (DILIGENT Provider), in modo da integrare nella definizione di un nuovo servizio gCube la gestione delle WS-Resource-Properties necessarie alla pubblicazione nell’Information System di DILIGENT. Oltre all’integrazione di componenti già presenti in DILIGENT all’interno delle librerie del gCube Core, ho cercato di capire se le funzionalità già presenti coprissero tutto quello che Globus offre agli sviluppatori, o se mancava qualcosa che poteva essere incluso all’interno della gCube core per rendere lo sviluppo di servizi gCube più semplice. Una funzionalità molto utilizzata nell’implementazione di un servizio GT4 è sicuramente la persistenza su disco dello stato della WS-Resource. Il supporto dato da Globus prevede dei metodi per il loading e la memorizzazione di oggetti sul disco, ma mentre il loading è richiamato automaticamente dal container Globus in caso che venga richiamato un metodo che utilizza lo stato del servzio, la memorizzazione deve essere implementata e lanciata dallo sviluppatore quando la stato del servizio cambia. Ho pertanto deciso di includere all’interno delle librerie core, una nuova class chiamata gCubePersitentResource, che gli contiene all’interno il supporto alla memorizzazione automatica dello stato del servizio su file e che quindi gli sviluppatori di servizi gCube possono utilizzare in caso vogliano sfruttare la persistenza dello stato nei loro servizi.

3° settimana

Nell’ultima settima di attività di ricerca, mi sono soffermato sugli aspetti relativi alla sicurezza dei servizi gCube e logging. La parte di studio di un’interfaccia verso il Data Management di gLite che era tra gli obiettivi del periodo di short term mobility di comune accordo con il prof Simeoni non è stato trattato, vista la possibilità non troppo remota di abbandono dell’utilizzo del middleware gLite nel progetto DILIGENT e nel successivo D4Science.

Per quanto riguarda la parte di sicurezza, ho effettuato lo studio del modello di sicurezza implementato nel progetto DILIGENT. Sia per Autenticazione che Autorizzazione vengono utilizzati certificati x509 che vengono associati allo stub del servizio chiamante. Il servizio gCube può operare in due modalità:



  • Ottenere certificati da un servizio che si trova sullo stesso container chiamato DVOS Delegation Service, e usare tali credenziali per effettuare chiamate sicure ( service credentials)

  • Ottenere le credenziali dal servizio chiamante per effettuare chiamate sicure ( caller Credentials)

I servizi possono operare in entrambe le modalità; usare le credenziali del servizio per effettuare task periodici e quindi operare in maniera autonoma, e/o usare le credenziali del chiamante per effettuare chiamate sicure. Oltre al meccanismo naturale di autenticazione e autorizzazione , i certificati vengono anche utilizzati per identificare il contesto di chiamata di un servizio. Per contesto si intende la VRE ( Virtual Research Environment ) e la VO ( Virtual Organization ) nel quale il servizio sta agendo. Per questo era necessario un supporto adeguato da parte delle librerie del GCube Core per implementare in maniera trasparente l’acquisizione delle credenziali e il loro utilizzo. La parte in dell’architettura gCube che si occupa della gestione della sicurezza è il DVOS (Diligent Virtual Organizazion System) composto da tre servizi e alcune librerie:



  • DVOS Delegation Service: presente su tutti i nodi si occupa della delega delle credenziali localmente al nodo;

  • DVOS Credential Renewal Service: interagendo con il gLite VOMS e MyProxy Services, gestisce la creazione e il rinnovo delle credenziali per i servizi gCube;

  • DVOS Authentication API: implementano in maniera trasparente il setting delle credenziali nelle chiamate dei metodi e permettono l’estrazione di attributi dai certificati.

I Servizi che necessitano di operare con credenziali proprie ( service credentials), utilizzano il DVOS Delegation Service per ottenere le credenziali delegate dal Credential Renewal ( attraverso dei listeners locali). La parte di gCube core implementata dal prof Simeoni, non tiene conto delle problematiche relative alla sicurezza. Ecco perché ho cercato di studiare delle funzionalità da introdurre nella librerie per rendere la gestione della scurezza nei servizi meno intrusiva.

In particolare ho introdotto il concetto di gCubeSecurityManager: un manager per che si occupa della gestione degli aspetti di sicurezza sia dal lato server che client. La parte core relativa alla sicurezza è stata cosi strutturata:



  • gCubeSecurityManager: classe astratta che definisce il comportamento di un Security Manager: offre metodi astratti per il setting delle credenziali nei metodi.

  • gCubeSecurityManagetImpl: implementazione base della gCubeSecurityManager.

  • gCubeServiceSecurityManager: interfaccia che estende la gCubeSecurityManager e definisce i metodi per il getting/setting di service e caller credentials..

  • gCubeServiceManagerImpl: implementazione dell’interfaccia della gCubeServiceSecurityManager.

  • MultiVRESecurityManager: estensione delle classe gCubeServiceSecurityManager, per i servizi che operano nell’ambito di più VREs.

  • SingleVRESecurityManager: estensione della classe gCubeServiceSecurityManager, per i servizi che operano nell’ambito di una singola VRE.

L’implementazione del gCube security package è stata effettuata negli ultimi due giorni della mia permanenza a Glasgow insieme ad una piccola estensione della librerie Log4J contenuta nel package WS-Core di GT4. Il meccanismo di logging è stato esteso in modo da tenere traccia del subject ( estratto dal certificato del chiamante) dell’entità che effettua un’operazione su un servizio.



Conclusioni


Il giudizio complessivo sull’esperienza presso la University of Strathclyde è senz’altro positivo, sia per le numerose competenze acquisite sia per la crescita professionale che un periodo di studi di questo tipo comporta. L’approfondimento degli aspetti maggiormente legati a DILIGENT ed il generale scambio di competenze tra me, il prof. Fabio Simeoni e il dott. Ralf Biering credo che sia stato un buon risultato permesso da questo programma di Short Mobility.

Il rapporto di cordialità, ed in qualche caso anche di amicizia, stabilito con il prof. Simeoni faciliterà lo sviluppo ulteriore della libreria gCube nei prossimi mesi, e la sua adozione nello sviluppo dei futuri servizi gCube nell’ambito del progetto D4Science. Nel corso nei prossimi mesi avrò inoltre modo di trasferire le nuove conoscenze ai membri del consorzio DILIGENT in occasione dei periodici meeting tecnici tenuti a cui parteciperò.

Visto

Dott. Fausto Rabitti



Dirigente di Ricerca ISTI-CNR




Condividi con i tuoi amici:


©astratto.info 2019
invia messaggio

    Pagina principale