Capitolo 3

(1)

Capitolo 3

Strumenti utilizzati per implementare il

Grid Middleware realizzato nel progetto

GRASP

In questo capitolo illustriamo gli strumenti utilizzati per realizzare i servizi che costituiscono il middleware realizzato nel progetto GRASP (argomento del prossimo capitolo). In particolare, tali servizi sono realizzati come servizi di Griglia ed offrono delle funzionalità atte a soddisfare i requisiti del progetto.

Uno di questi servizi di Griglia, chiamato Service Locator, costituisce il nostro caso di studio che sarà trattato nei prossimi capitoli.

Nel capitolo è anche riportata una breve descrizione del toolkit di Globus, il GT3 [25], che è uno standard de facto per l’implementazione e la gestione dei

servizi su Griglia. Nel nostro caso tale toolkit è stato utilizzato per fare dei test con i quali abbiamo studiato il comportamento di tale strumento nell’eseguire la

(2)

ricerca di un servizio. Tale studio è stato preso in esame per verificare se il servizio di Griglia realizzato nel nostro caso di studio è conforme alle specifiche definite da OGSA.

3.1 Microsoft .NET

Microsoft .NET è la piattaforma Microsoft costituita da un insieme di tecnologie software allo scopo di agevolare il collegamento di utenti, sistemi e periferiche. Tale piattaforma rende possibile un alto livello di integrazione del software attraverso l’utilizzo degli XML Web Services, ossia crea un insieme di applicazioni, devices e sistemi che possono dialogare tra loro via internet. Gli XML Web Services sono moduli software creati utilizzando il linguaggio XML per lo scambio di dati, in modo da garantire l’interazione tra applicazioni, servizi e periferiche. Condividendo i dati tramite XML queste entità, di per se indipendenti, possono interagire integrandosi ad altre per soddisfare l’esecuzione di determinate attività. Il funzionamento degli XML Web Services è paragonabile al gioco delle costruzioni Lego. Come i Lego, gli XML Web Services sono unità indipendenti caratterizzate da un metodo di connessione standard, rappresentato dalla messaggistica XML. Combinando i Lego si può costruire una casa, un aeroplano o una barca, mentre componendo i Web Services si può creare una soluzione software che esegue una determinata attività. Analogamente alle costruzioni Lego, in cui un pezzo può far parte di diversi oggetti, un singolo XML Web Services può essere utilizzato in molti gruppi differenti e far parte di soluzioni finalizzate a diverse attività.

(3)

Figura 3.1 Componenti di Microsoft .NET

.NET permea l’intera gamma dei prodotti che costituiscono la piattaforma Microsoft offrendo la capacità di creare, ospitare, offrire ed utilizzare in modo rapido ed affidabile soluzioni applicative sicure ed online attraverso gli XML Web Services ed i server necessari per entrare a far parte di questo network profondamente integrato.

Come si può vedere in Figura 3.1 sono illustrate le quattro componenti base della piattaforma Microsoft .NET:

Smart Client. Le applicazioni software del tipo “Smart” client ed il

sistema operativo danno ai PCs ed agli altri smart computing devices la possibilità di comunicare tramite gli XML Web Services, permettendo un accesso alle informazioni in ogni luogo ed in qualsiasi momento.

XML Web Services. Sono un insieme di Web Services, sviluppati da

Microsoft, che possono essere combinati con altri XML Web Services oppure usati con applicazioni smart client. Per esempio Microsoft MapPoint .NET è un XML Web Services che permette di integrare mappe

(4)

di alta qualità con sistemi di guida ed altri strumenti di localizzazione all’interno di un’applicazione o di un processo business o persino all’interno di un sito Web.

Server Infrastructure. In questa infrastruttura è inclusa la famiglia di

Microsoft Windows 2000 Server, di .NET Enterprise Server e di Microsoft .NET Server. L’infrastruttura Server è un insieme di applicazioni per la creazione, la distribuzione e il funzionamento dei servizi Web XML. Le tecnologie chiave includono il supporto per XML ed il coordinamento dei processi aziendali tramite applicazioni e servizi.

.NET framework e Visual Studio .NET. Rappresentano un insieme di

strumenti di sviluppo per costruire, utilizzare ed eseguire i Web Services. .NET framework include un ricco insieme di APIs ed il Common Language Runtime (CLR) di cui si parlerà in seguito.

3.1.1 .NET Framework

.NET Framework è un componente di Microsoft .NET che fornisce un modello di programmazione ed un supporto runtime per servizi Web XML, applicazioni Web ed applicazioni di tipo client. .NET Framework è progettato per ottenere gli obiettivi indicati di seguito:

• Fornire un ambiente di esecuzione coerente ed orientato agli oggetti sia

che il codice degli oggetti sia memorizzato ed eseguito localmente, sia che sia eseguito localmente ma distribuito in rete, sia che sia eseguito in modalità remota.

• Fornire un ambiente di esecuzione del codice che consenta di ridurre al

(5)

• Fornire un ambiente di esecuzione del codice che garantisca

un’esecuzione protetta anche quando il codice è fornito da terze parti non note.

• Fornire un ambiente di esecuzione che consenta di migliorare i

problemi derivanti dall’uso di ambienti di scripting o di interpretazione.

• Garantire l’uniformità dello sviluppo in tipi di applicazioni molto

diverse, quali applicazioni per Windows e quelle basate sul Web.

• Basare tutte le applicazioni di comunicazione su standard del settore

(commerciale, industriale, ecc.) al fine di garantire l’integrazione del codice basato su .NET Framework con qualsiasi altro tipo di codice, indipendentemente dal linguaggio o dalla piattaforma su cui è stato sviluppato.

I due elementi principali del .NET Framework sono il Common Language

Runtime (CLR) e la libreria di classi .NET Framework. Il CLR rappresenta la base del .NET Framework e può essere considerato come un agente che gestisce codice in fase di esecuzione, fornendo servizi di base quali la gestione della memoria, dei thread e dei servizi remoti, attivando al contempo una rigida indipendenza dei tipi (tipi valore1 e tipi riferimento2) ed altre forme di “correttezza” del codice che assicurano protezione e solidità del codice stesso. Il concetto di gestione del codice è di fatto un principio fondamentale del runtime. Il codice che è destinato al runtime viene detto codice gestito, mentre quello non destinato al runtime viene detto codice non gestito. La libreria di classi è costituita da un insieme di tipi riutilizzabili orientato agli oggetti. Inoltre è possibile utilizzare tale insieme per sviluppare applicazioni che vanno da quelle

1_{I tipi valore rappresentano i dati che possono essere acceduti direttamente con una}

variabile. Tipicamente sono tipi primitivi quali interi e caratteri.

2_{I tipi riferimento rappresentano gli indirizzi o i riferimenti ai dati memorizzati in una}

(6)

tradizionali fatte a riga di comando a quelle basate sulle recenti innovazioni fornite da ASP.NET, quali Web Form e servizi Web XML.

3.1.1.1 Common Language Runtime

Il Common Language Runtime (CLR) gestisce l’allocazione della memoria, l’esecuzione dei thread, l’esecuzione del codice, la verifica della protezione del codice, la compilazione ed altri servizi di sistema. Tali funzionalità permettono di soddisfare i seguenti requisiti all’interno del .NET Framework:

- Protezione: ai componenti gestiti vengono assegnati vari livelli di attendibilità sulla base di alcuni fattori tra cui la loro provenienza (Internet, rete aziendale, computer locale). La realizzazione di applicazioni protette risulta complessa in assenza di un ambiente gestito. Tuttavia, un tale ambiente garantisce la protezione a discapito della funzionalità dell’applicazione. Un componente gestito può pertanto essere o meno in grado di eseguire operazioni di accesso ai file o al registro di sistema oppure ad altre importanti funzioni anche se utilizzato in un’applicazione protetta in fase di esecuzione.

La protezione di accesso al codice è messa in atto dal runtime. Gli utenti possono ad esempio consentire ad un eseguibile incorporato in una pagina Web di riprodurre un’animazione o una canzone senza tuttavia accedere ai dati personali degli utenti stessi, al file system o alla rete.

Il runtime contribuisce alla validità del codice grazie all’implementazione di un’infrastruttura rigorosa di verifica del codice e dei tipi, denominata Common Type System (CTS), che supporta la capacità di condividere le componenti tra diversi linguaggi di programmazione. - Affidabilità: il runtime gestisce automaticamente il layout degli oggetti ed

i riferimenti agli oggetti, rilasciandoli quando non vengono più utilizzati e risolvendo, in tal modo, i due errori più comuni riscontrati nelle

(7)

applicazioni, ossia perdite di memoria (durante l’esecuzione di un processo) e riferimenti non validi alla memoria. In questo modo le applicazioni stesse diventano più affidabili perché risultano meno soggette ad errori dovuti a codice scritto non correttamente.

- Produttività: il runtime consente di incrementare la produttività degli sviluppatori, fornendo un modello di programmazione unificato, indipendente da linguaggi di programmazione, dai tipi di applicazione e dalle piattaforme usate. Infatti i programmatori possono scrivere nel linguaggio di programmazione scelto e sfruttare tutti i vantaggi in termini di tempo e di correttezza del codice che sono dati dall’uso del runtime, della libreria di classi e delle componenti scritte in altri linguaggi da altri sviluppatori.

- Interoperabilità: pur se progettato per il software di nuova generazione, il runtime è in grado di supportare anche il software attualmente disponibile o quello sviluppato in passato. Infatti, l’interoperabilità tra il codice gestito e non gestito consente di continuare ad utilizzare le componenti realizzate in Common Object Model (COM)3_{e le dinamic link}

library (DLL)4_{acquistate o create. Per l’integrazione del software}

esistente non è richiesto l’accesso al codice sorgente, è sufficiente fare riferimento alla libreria o all’oggetto COM ed aggiungere il codice come se si trattasse di un componente Microsoft .NET nativo.

- Prestazioni: il runtime è progettato in modo da ottimizzare le prestazioni tramite un rivoluzionario processo di compilazione. Sebbene il Common Language Runtime fornisca molti servizi di run-time standard, il codice

3_{COM: ambiente runtime precedente a .NET}

(8)

gestito non viene mai interpretato. Grazie alla compilazione Just-in-time

(JIT) tutto il codice gestito viene eseguito nel linguaggio macchina nativo

del sistema in uso. Inoltre, il gestore della memoria consente di ovviare alla frammentazione della memoria e di migliorare la gestione della stessa con conseguente ottimizzazione delle prestazioni.

3.1.1.2 Libreria di classi .NET Framework

La libreria di classi .NET Framework è costituita da un insieme di tipi riutilizzabili strettamente integrati con il Common Language Runtime, è orientata ad oggetti e fornisce i tipi da cui deriva la funzionalità del codice gestito. In questo modo, non solo viene semplificato l’utilizzo dei tipi .NET Framework ma viene anche ridotto il tempo necessario all’apprendimento delle nuove funzionalità del framework. Inoltre, è possibile integrare uniformemente i componenti di altri produttori nelle classi del .NET Framework.

Basato su un’architettura orientata ad oggetti, .NET Framework è completamente espandibile e consente di migliorare, modificare ed adattare le funzionalità di base in relazione alle esigenze dell’utente o dell’organizzazione.

Come ci si aspetta da una libreria di classi orientata ad oggetti, i tipi di .NET Framework consentono di eseguire numerose attività di programmazione tra cui la gestione delle stringhe, la raccolta dei dati, la connettività al database e l’accesso ai file. Oltre a queste attività comuni, la libreria di classi include tipi che supportano vari scenari di sviluppo specializzati. Infatti, è possibile utilizzare .NET Framework per sviluppare tipi di applicazioni e servizi quali le applicazioni console, le applicazioni GUI Windows, le applicazioni ASP.NET, WebServices e servizi Windows.

(9)

3.1.2 Funzionalità di Microsoft .NET utilizzati per il Resource

Management

Microsoft .NET offre delle funzionalità tramite cui è possibile realizzare il Resource Management in ambiente Grid. Tali funzionalità sono fornite da componenti di Microsoft .NET quali .NET Framework ed altri. In particolare, l’uso congiunto di tali funzionalità fornite da Microsoft .NET permette di realizzarne altre che sono specifiche del Resource Management. In particolare:

• Cercare informazioni riguardanti una risorsa all’interno di un

“contenitore” come ad esempio un Information Service [5, 6] in Globus.

• Gestione (inserzione, cancellazione, update) delle risorse.

• Monitoring ed updating del contenitore delle informazioni sulle

risorse.

Per quanto riguarda la ricerca delle informazioni, Microsoft .NET fornisce due namespace che svolgono questo compito, System.DirectoyService [26] e

System.Management [26]. Il System.DirectoyService è un namespace che

contiene due classi, DirectoryEntry e DirectorySearcher, che usano la tecnologia

Active Directory Service Interfaces (ADSI) [26]. ADSI è un insieme di interfacce che Microsoft fornisce per lavorare con una varietà di network provider. Inoltre, permette all’amministratore di rete di individuare e gestire le risorse su una rete. Le classi fornite dal namespace System.DirectoryService possono essere usate insieme con altri software utilizzati per la gestione del servizio Active Directory, come ad esempio Internet Information Service (IIS) e Lightweight Directory Access Protocol (LDAP).

Active Directory è una struttura ad albero in cui ogni nodo contiene un insieme di proprietà. Il namespace System.DirectoryService è usato per cercare i nodi nell’albero e accedervi in lettura o scrittura. In particolare la ricerca all’interno di una Active Directory viene fatta tramite la classe

(10)

DirectorySearcher, mentre l’accesso alle informazioni tramite la classe DirectoryEntry.

Il namespace System.Management fornisce accessi ad un ricco insieme di informazioni di gestione, quali ad esempio la percentuale di utilizzo del processore e lo spazio di hard disk libero, inoltre gestisce gli eventi riguardanti il sistema, i servizi e le applicazioni. Le informazioni di gestione possono essere recuperate tramite delle query fatte usando le classi ManagementQuery e

ManagementObjectSearcher fornite dal namespace System.Management. In

particolare con la classe ManagementQuery è possibile effettuare le query per individuare specifiche informazioni di gestione, mentre con la classe ManagementObjectSearcher è possibile recuperare tali informazioni.

La gestione delle risorse viene realizzata usando i namespace

System.Resource [26] e System.Collections [26] forniti da Microsoft .NET. Il

namespace System.Resource fornisce classi ed interfacce che permettono di creare, memorizzare e gestire le risorse usate in un’applicazione. Una delle classi più importanti del namespace System.Resource è la Resource.Manager che permette agli utenti di accedere e di controllare le risorse memorizzate nello assembly5_{principale o in una risorsa assembly satellite.}

Infine, per quanto riguarda gli aspetti riguardanti il monitoring e lo updating delle informazioni descriventi le risorse, Microsoft .NET fornisce i namespace

System.Diagnostic [26] e System.DirectoryService trattato in precedenza. Il

namespace System.Diagnostic fornisce le classi, Process, EventLog,

PerformanceCounter, che permettono, rispettivamente, di interagire con i

processi di sistema, i file di log6 di Windows ed i contatori di performance. La classe Process fornisce le funzionalità per monitorare i processi di sistema attraverso la rete e per attivare l’esecuzione dei processi di un sistema locale. Inoltre permette di recuperare la lista dei processi in esecuzione o di avere

5_{Assembly: collezione logica di uno o più file EXE o DLL che contengono il codice di}

un’applicazione e le risorse da essa utilizzate.

(11)

informazioni sui processi che in un dato istante hanno accesso al processore. La classe EventLog fornisce le funzionalità per scrivere e leggere i file di log, creare e cancellare tali file ed i sorgenti degli eventi che vengono memorizzati in tali file. In particolare, è necessario creare un sorgente di eventi per poter scrivere in un file di log, cioè un tale sorgente è visto come la strada di accesso ad uno specifico file di log. Infine, la classe PerformanceCounter fornisce dei contatori che monitorizzano vari componenti di un sistema operativo, quali la memoria, la CPU, ecc..

3.2 Windows Server 2003 e UDDI

Windows Server 2003 è un sistema operativo prodotto da Microsoft. L’impiego di tale sistema operativo è derivato dal fatto che in esso è stato integrato il .NET Framework 1.1 che utilizziamo per sviluppare (tramite l’ambiente di sviluppo Visual Studio .NET 2003 [27]) servizi di Griglia e dal fatto che esso offre il servizio Universal Description Discovery e Integration (UDDI) che è stato impiegato come registry per conservare le informazioni relative a tali servizi. L’accesso a UDDI è fornito tramite interfaccia utente Web-based oppure da programma attraverso interfacce SOAP. Il servizio UDDI trae vantaggio da alcune caratteristiche del servizio Active Directory, il quale fornisce aspetti di sicurezza quali autenticazione ed autorizzazione per i servizi UDDI. Tutti gli accessi ed i permessi per leggere, pubblicare o coordinare le informazioni contenute all’interno dei servizi UDDI sono assegnati attraverso un insieme di ruoli (amministratore, utenti, coordinatore) definiti durante l’installazione all’interno di un servizio Active Directory. Inoltre, tale servizio fornisce un mezzo per trovare i server sulla rete in cui sono in esecuzione dei servizi UDDI, che possono anche essere installati all’interno di un servizio Active Directory in modo da permettere ad amministratori, utenti o applicazioni di elaborare delle semplici query per ottenere una lista di tutti i servizi UDDI

(12)

sulla rete. I servizi UDDI ricevono le richieste provenienti da un programma attraverso delle API UDDI che permettono agli sviluppatori di pubblicare, scoprire e condividere le informazioni riguardanti i Web services [28].

3.2.1 Modellare i dati nei servizi UDDI

Per registrare un Web service all’interno di un servizio UDDI è necessario specificare quattro entità base, quali Provider, Service, Binding, tModel. In Figura 3.2 sono illustrati i rapporti tra tali entità.

.

Figura 3.2 Rapporto tra le entità di un servizio UDDI

Un provider è un’entità padre sotto cui sono memorizzati ed organizzati nello UDDI: l’informazione per contattarlo, i servizi e le informazioni sui binding. Un provider è visto come un’organizzazione, una persona, un computer o un’applicazione che offre dei servizi.

Un servizio è un’entità logica, cioè costituita da una collezione logica di bindings. Descrive e fornisce accessi ad un servizio fornito da un provider e condiviso con altri utenti del servizio UDDI. Informazioni tecniche che descrivono un servizio non possono essere fornite al livello Service (Figura 3.2),

Provider: Information about the

entity who offers a service

0…n

Service: Descriptive information

about a particular family of

technical offerings

0…n

Binding: Technical information

about a service entry point

0…n

tModel: Descriptions of

specifications for services.

specifications for services. Bindings contains

Bindings contains

references to tModels.

These references declare

the interface specifications

for a service.

0…n

tModel: Descriptions of

specifications for services.

specifications for services. specifications for services. tModel: Descriptions of tModel: Descriptions of

specifications for services. Bindings contains

Bindings contains

references to tModels.

These references declare

the interface specifications

for a service.

(13)

infatti a tale livello possono essere forniti solo accessi e informazioni generali riguardanti un servizio. Tale problema può essere risolto fornendo dei metadati che descrivono il servizio.

Diversamente dal livello Service, nel livello Binding (Figura 3.2) sono contenute delle entità fisiche, ovvero i punti di accesso ad un Web service o ad un altro servizio, dette binding.

L’entità tModel offre un approccio estremamente flessibile per fornire informazioni tecniche riguardanti le entità memorizzate nello UDDI. Rappresentano file come ad esempio i documenti WSDL che definiscono le interfacce, le quali possono essere usate da uno o più servizi. Le entità tModel possono anche “puntare” a tipi di dato XML Schema (XSD) [29], file XML ed altri documenti situati sulla rete, ma non contengono tali documenti.

3.2.2 Usare la Categorizzazione in un servizio UDDI

Lo scopo di UDDI è di descrivere e scoprire i servizi. Non è sempre facile elaborare richieste o query se non si hanno delle informazioni “guida” per farlo, per questo motivo sarebbe utile utilizzare uno schema di categorizzazione che rappresenti una guida sia per chi vuole pubblicare un servizio, sia per chi vuole ricercarlo all’interno di un registry UDDI. I servizi pubblicati in UDDI hanno diverse caratteristiche e per questo un singolo schema di categorizzazione potrebbe non essere sufficiente, ma questo non è un problema visto che non esiste un limite al numero di schemi di categorizzazione che possono essere creati, né tantomeno al numero di elementi che possono essere contenuti in ciascuno si essi. Uno schema di categorizzazione può essere creato tramite un editor fornito dal Resource Kit di un servizio UDDI. Tale editor genera un file XML che l’amministratore del servizio UDDI può importare nel sistema e renderlo utilizzabile. In sostanza, uno schema di categorizzazione è un insieme di categorie che permettono di integrare le informazioni che descrivono un servizio

(14)

in modo da “categorizzarlo” e quindi renderlo individuabile. Oltre ai servizi possono essere categorizzati anche i provider ed i tModel, cioè tutte le entità che costituiscono l’informazione memorizzata nello UDDI.

La capacità di integrare le entrate di un servizio UDDI con dei metadata classificati da uno schema di categorizzazione conosciuto, rappresenta un vantaggio chiave nell’uso del servizio UDDI.

Per trarre vantaggio dall’utilizzo degli schemi di categorizzazione è necessario che questi vengano stabiliti prima che i servizi siano pubblicati in UDDI. Ad esempio, possiamo integrare un servizio con delle categorie che dichiarano che il servizio è:

• un servizio finanziario • situato negli Stati Uniti

• utilizzabile ventiquattro ore al giorno per sette giorni alla settimana

La proprietà che dichiara che il servizio è negli Stati Uniti deriva da un sistema di categorizzazione geografico, mentre la proprietà che descrive le informazioni del service level agreement (SLA) derivano da un sistema di categorizzazione di QoS (quality of service). L’integrazione di queste informazioni all’interno di un servizio UDDI fornisce dei metadata che possono essere usati per individuare ed utilizzare il servizio.

3.3 OGSI.NET Framework

Come detto nel Capitolo 2 la Open Grid service Architecture (OGSA) rappresenta il mezzo per costruire in larga scala dei sistemi griglia interoperabili. Tale interoperabilità è garantita rispettando le specifiche dello Open Grid

Services Infrastructure (OGSI) [30]. OGSI è un insieme di specifiche WSDL che sono consistenti alle specifiche OGSA e che possono essere implementate su una varietà di piattaforme hosting. A questo proposito il Grid Computing Group dell’Università della Virginia ha realizzato OGSI.NET [31], una piattaforma per

(15)

il grid computing7 su .NET. OGSI.NET è un’implementazione delle specifiche OGSI su una piattaforma .NET di Microsoft.

Il framework OGSI.NET fornisce un’infrastruttura basilare per costruire e pubblicare servizi griglia nel mondo .NET/Windows che siano conformi alle specifiche di OGSI. Per questo motivo tale framework è stato utilizzato nel caso di studio descritto nei prossimi capitoli.

Il progetto base di OGSI.net è di avere un’entità container che gestisce tutte le istanze dei servizi in esecuzione su un host. Il processo container consiste di una collezione di AppDomain, ciascuno dei quali è un meccanismo di Microsoft per la protezione della memoria intra-process. Nella versione attuale di OGSI.net (Tech Preview 1.1) ogni istanza di un servizio viene eseguita nel suo proprio AppDomain. In una versione futura si può pensare ad avere più istanze di un servizio nello stesso AppDomain, questo permetterebbe di avere delle comunicazioni inter-service più efficienti a discapito però della sicurezza. Infatti, un’istanza di un servizio che genera un errore a tempo di esecuzione o un’altra che termina prematuramente a causa di un errore nel contatore del timeout, ha accesso alla memoria che è condivisa da tutte le istanze di servizio eseguite sullo stesso AppDomain. Di conseguenza, un tale comportamento anomalo potrebbe recare dei danni a tali istanze.

In un’architettura OGSI.net, un client fa una richiesta inviando un messaggio allo IIS (Internet Information Server) web server. Le richieste client sono intercettate ad un primo stadio nella catena di richieste IIS da un filtro usato da OGSI.net e chiamato ISAPI filter. Tale filtro decodifica la richiesta che IIS spedirà allo HttpHandler (è un codice gestito), il quale la invia al container di OGSI.net. Il processo container è costituito da un insieme di thread ed alla ricezione di ogni richiesta IIS uno di questi provoca l’esecuzione del dispatcher, che determina quale servizio potrebbe ottenere la richiesta e trasferisce

7_{Grid Computing: meccanismo attraverso cui viene assicurata la collaborazione e la}

(16)

l’esecuzione di tale thread ad un oggetto nell’appropriato AppDomain. Un diagramma del sistema è mostrato in Figura 3.3.

Figura 3.3 OGSI container su piattaforma .NET

Dentro un AppDomain il controllo è trasferito ad un oggetto chiamato Grid

Service Wrapper (GSW) che racchiude un’istanza di un servizio incluso i suoi

service data8 e l’implementazione dei suoi metodi. Il GSW mantiene una lista di port type9 che il servizio offre, sia quelle realizzate da chi ha scritto il servizio che quelle standard definite con le specifiche di OGSI e fornite dal container (ad esempio grid service port type, notification source port type, ecc.). Inoltre, mantiene i “serializzatori” ed i “deserializzatori” necessari per i vari protocolli di messaging che il servizio offre (SOAP o Microsoft remoting [32]). Il GSW

8_{service data: modello utilizzato in OGSA tramite cui si possono racchiudere le}

informazioni riguardanti un servizio

9_{port type: sono le interfacce che un servizio espone ad un client, che le può utilizzare}

(17)

svolge l’elaborazione di alcune informazioni di uno specifico messaggio (ad esempio header Soap) e deserializza tale messaggio per ottenere il nome del metodo da invocare ed alcuni parametri necessari a tale metodo. Successivamente il GSW cerca tra le port type quella che implementa il metodo richiesto, poi usa il reflection10 sulla porta selezionata per ottenere un handle che permetta di invocare tale metodo passandogli alcuni parametri ed i dati specificati nel messaggio (ad esempio i dati contenuti nello header SOAP). I dati restituiti dall’invocazione del metodo sono serializzati dal GSW e inviati al dispatcher come un array binario. Tale dispatcher invia l’array indietro allo IIS che lo restituirà al client.

Per completare la panoramica su OGSI.net diamo una breve illustrazione dei maggiori componenti di tale sistema: il dispatcher, i wrapper del servizio, le factory ed i gestori del messaggio.

Il dispatcher, come si può vedere da Figura 3.3 e da quanto detto sopra, è l’interfaccia tra la richiesta client e l’istanza di un servizio che la serve. La sua funzione principale è quella di instradare i messaggi di una richiesta all’istanza di un servizio appropriata e di restituire i risultati al client.

Tra i wrapper di un servizio distinguiamo: il wrapper di un servizio di Griglia ed il wrapper di un servizio light-weight. Il wrapper di un servizio di Griglia o GSW racchiude le varie unità funzionali di un tale servizio. Ogni AppDomain nel container ha un GSW ed ogni GSW “wrappa” un’istanza di un servizio di Griglia. Il GSW fornisce a chi ha scritto il servizio di griglia un modello di programmazione conveniente, permettendo:

• Serializzatori/deserializzatori per un messaggio di uno specifico

servizio.

• Una semplice specifica delle port type offerte dal servizio.

10_{reflection: metodo che permette di ottenere una URL valida alla definizione WSDL}

(18)

• Supporto alle port type (ad esempio grid service port type) offerte dal

servizio, ma che non sono state implementate da chi lo ha scritto. Il wrapper di un servizio di Griglia dipende dalle funzionalità del processo container per gestire le richieste e creare o distruggere dinamicamente le istanze di un servizio. Il container presenta una vasta gamma di funzionalità agli autori dei servizi su lato server, ma ci sono delle occasioni in cui i servizi sono utili anche dal lato client (ad esempio, notification sink11). In questo caso i servizi forniscono delle interfacce conformi alle specifiche OGSI, ma hanno limitate funzionalità. In OGSI.net tali servizi sono chiamati servizi light-weight e sono racchiusi dai wrapper del servizio light-weight (LWSW). I servizi light-weight sono simili ai servizi di Griglia, ma hanno alcune restrizioni:

• Non possono creare altri servizi (un GSW contiene i riferimenti ai servizi

light-weight che ha creato, ma il LWSW non ha una funzionalità equivalente).

• Non hanno i service data element (SDE).

• Sono terminati quando il servizio griglia padre o il client termina (oppure

quando viene distrutto esplicitamente dal padre/client).

I servizi light-weight non sono solo usati dal lato client, ma anche internamente al container di OGSI.net per ricevere i messaggi di notifica.

Le factory sono servizi che creano istanze di altri servizi. In OGSI.net questo significa creare un nuovo AppDomain ed un nuovo GSW in tale dominio. Successivamente, il GSW caricherà lo assembly (vedi nota 4) del servizio che deve essere eseguito nello AppDomain ed istanzierà una nuova istanza di tale servizio. Una factory memorizza i riferimenti al GSW nel nuovo dominio insieme con il nome dell’istanza pubblicata. Tali informazioni sono passate anche al dispatcher.

11_{Meccanismo tramite cui dal lato client si avverte il lato server di essere interessati alla}

(19)

I gestori del messaggio elaborano i messaggi che hanno uno specifico formato su un’istanza di un servizio. OGSI.net contiene due gestori del messaggio, uno per il formato del messaggio remoting e l’altro per il formato del messaggio SOAP. Quando l’istanza di un servizio è creata, il GSW di tale istanza creerà l’oggetto gestore del messaggio per ogni formato del messaggio che il servizio supporta. Il gestore del messaggio deserializza il messaggio contenente la richiesta che arriva dal dispatcher, determinando la funzione da invocare e creando i parametri necessari a tale funzione. Quando la richiesta è completata, lo handler serializzerà i risultati in uno stream di byte che è poi passato al dispatcher, il quale lo restituirà al client.

3.4 Globus Toolkit 3 Core

L’infrastruttura core di Globus Toolkit 3 (GT3 Core) [33] è basata sulle primitive e sui protocolli definiti da OGSI. Il principale obiettivo del progetto Globus è quello di rendere la tecnologia OGSI semplice da usare, riusare ed estendere per integrare nuovi servizi di Griglia. Il GT3 offre un ambiente run-time capace di ospitare i servizi di Griglia. Tale ambiente fa da mediatore tra l’applicazione e la rete sottostante ed i motori dei protocolli di trasporto. GT3 Core fornisce dei metodi per lo sviluppo dei servizi che includono dei modelli di programmazione per esporre ed accedere le implementazioni di un servizio di Griglia.

Il GT3 è stato utilizzato in questo contesto per fare dei test sulla pubblicazione e la ricerca di un servizio. Lo studio fatto su questo strumento ha il fine di verificare se il servizio di griglia realizzato nel caso di studio ed illustrato nei capitoli successivi è conforme alle specifiche OGSA.