Capitolo 2

Capitolo 2

Open Grid Service Architecture (OGSA)

In [3] Ian Foster, Carl Kesselman, Jeffrey M.Nick e Steven Tuecke mettono in evidenza la necessità di integrare i servizi offerti dalle imprese nell’ambito e-business ed in quello e-science attraverso organizzazioni virtuali (VO) dinamiche, eterogenee e distribuite. Tali VO sono formate da varie risorse di una singola impresa e/o da risorse esterne da condividere e da politiche di service provider in base alle quali si gestiscono accessi alle risorse, permessi, ecc. La

Open Grid Services Architecture (OGSA) [3] è un insieme di specifiche e di standard che combinano i vantaggi del Grid Computing e dei Web Services. Grazie ad OGSA, gli utenti hanno ora la possibilità di accedere e condividere "on demand" le risorse di elaborazione su Internet, basandosi su un'infrastruttura flessibile, che può essere gestita in modo autonomo.

OGSA definisce meccanismi standard per la creazione, il naming ed il discovering delle istanze transienti di un servizio; fornisce il location trasparency (possibilità di accedere le risorse senza conoscere dove esse siano allocate) ed i

protocolli binding1 multipli per le istanze di un servizio; supporta l’integrazione con le funzionalità della piattaforma sottostante e supporta la creazione, la gestione e l’utilizzo di insiemi di servizi gestiti dalle organizzazioni virtuali. L’architettura usa il Web Service Description Language (WSDL) per definire le interfacce e le convenzioni associate, i meccanismi richiesti per la creazione e la composizione di sistemi distribuiti più complessi che includono funzionalità rivolte alla gestione delle risorse quali il lifetime management, il change management, e la notification.

OGSA introduce il concetto di Grid Service, che è un web service che rispetta un insieme di convenzioni (interfacce e comportamenti) che definiscono come un client può interagire con il servizio stesso. I Grid Service svolgono un ruolo cruciale per garantire che le server farm complesse ed eterogenee, utilizzate per erogare un servizio in modalità SP (Service Provider) o in interazioni B2B, riescano a garantire la qualità del servizio (QoS) che gli utenti si aspettano.

2.1 Tecnologie usate per definire OGSA

Le tecnologie che vengono utilizzate per definire la Open Grid Services Architecture sono il Globus Toolkit, che è stato ampiamente adottato come una delle soluzioni della tecnologia Grid per il calcolo tecnico e scientifico, ed i Web services, che mirano a rendere semplice, efficiente e standardizzata l’interazione fra programmi all’interno di ambienti complessi ed eterogenei.

2.1.1 Globus Toolkit

Il Globus Toolkit è un insieme di servizi e librerie software che supportano le Grid e le applicazioni che girano su ciascuna di esse, inoltre si occupa delle problematiche riguardanti la sicurezza, il discovery dell’informazione, il resource

management, la comunicazione, il fault detection e la portabilità. Il Globus Toolkit è costituito da un insieme di componenti che possono essere utilizzati singolarmente o insieme per sviluppare delle applicazioni.

I componenti del toolkit più importanti in OGSA sono:

• il protocollo Grid Resource Allocation e Management (GRAM) ed il

suo servizio “gatekeeper”, che provvede alla creazione ed alla gestione di un servizio sicuro ed affidabile;

• il Meta Directory Service (MDS-2), che memorizza le informazioni

riguardanti le risorse in maniera soft state (le informazioni variano periodicamente in quanto vengono mantenute per un tempo massimo prestabilito). Tali informazioni verranno utilizzate per il discovery di una risorsa. Inoltre si occupa del data modeling e fornisce un registry locale (GRAM reporter);

• il Grid Security Information (GSI), che supporta il single sign on e la

delegation.

Il protocollo GRAM fornisce la creazione e la gestione remota, sicura ed affidabile di computazioni chiamate istanze di servizio transitorio. La creazione di un servizio è gestita da un processo gatekeeper, chiamato factory. Il GRAM reporter, chiamato registry, monitorizza e pubblica le informazioni riguardanti l’identità e lo stato delle computazioni locali. I meccanismi GSI sono usati per l’autenticazione, l’autorizzazione e la delegazione verso computazioni remote. MDS-2 fornisce una struttura uniforme, chiamata discovery interface, per scoprire ed accedere le informazioni riguardanti lo stato e la configurazione di un sistema, quali ad esempio la configurazione di un server di calcolo, lo stato di una rete o i siti in cui sono memorizzati insiemi di dati replicati. Inoltre, MDS-2 usa un protocollo soft state, il Grid Notification Protocol, per il lifetime management dell’informazione pubblicata.

2.1.2 Web Services

I Web Services sono delle interfacce che descrivono una collezione di operazioni, accessibili attraverso il Web mediante messaggi codificati in formato XML. Un Web Service può essere a sua volta descritto mediante una descrizione

del servizio che specifica in modo formale tutte le informazioni necessarie per la

sua invocazione: ad esempio, la localizzazione, il formato dei messaggi, il protocollo di trasporto. La descrizione dei web services è anch'essa basata su un apposito formato XML, il WSDL (Web Services Description Language) di cui parleremo in seguito. I Web Services standards sono stati definiti dal World Wide Web Consortium (W3C). In OGSA sono presi in considerazione alcuni di questi standards, che sono SOAP, WSDL, WS-Inspection, UDDI.

• Il Simple Object Access Protocol (SOAP) definisce una struttura di

comunicazione per scambiare i dati in formato XML attraverso Internet [21, 22].

• Il Web Service Description Language (WSDL) è un documento XML

per la descrizione di Web services, cioè descrive cosa un web service può fare, dove risiede e come invocarlo [21, 22].

• Universal Description Discovery and Integration (UDDI) è un Web

Service che usa dei meccanismi di registry e discovery. Viene usato per pubblicare informazioni riguardanti un web service quali ad esempio la sua locazione, il file WSDL, il proprietario del servizio ed altre informazioni utili alla fase di discovery del servizio.

• Ws-Inspection è un formato Xml che può essere usato per determinare

quali servizi sono disponibili su uno specifico service provider e come possono essere richiamati. Un documento di tipo Ws-Inspection fornisce un modo per riunire i riferimenti alle varie descrizioni del servizio. La descrizione di un Web Service può essere recuperata usando o il file WSDL o le informazioni contenute nel registry UDDI.

I riferimenti al file WSDL di un servizio o al registry UDDI possono essere contenute in un documento WS-Inspection [23].

2.2 Open Grid Services Architecture

Negli ultimi anni si è capito che all’interno di un’infrastruttura IT (Information Tecnologies) di un’impresa o di un service provider, ma soprattutto all’interno di Griglie, la necessità di soddisfare esigenze di calcolo sempre più complesse ha portato alla creazione, gestione ed applicazione di un insieme dinamico di risorse e servizi (e persone) chiamate organizzazioni virtuali (VO).

In questo paragrafo sono descritte alcune note generali riguardanti l’utilità di un’architettura Griglia orientata ai servizi (SOA), la virtualizzazione delle risorse nella Griglia ed alcune caratteristiche essenziali di un servizio griglia.

In una Griglia sono necessari dei meccanismi che abilitino l’interoperabilità tra le risorse. Con una visione orientata ai servizi possiamo partizionare il problema dell’interoperabilità in due sottoproblemi: la definizione delle interfacce di un servizio e l’identificazione dei protocolli che possono essere usati per invocare una particolare interfaccia.

Una visione orientata ai servizi ci permette di rispondere al bisogno di meccanismi di definizione di interfacce, location transparency locale/remota e semantiche di servizio in modo da facilitare l’utilizzazione delle risorse e dei servizi da esse forniti. Inoltre ci permette di semplificare la virtualizzazione, che è un meccanismo che tiene conto degli accessi consistenti alle risorse attraverso piattaforme eterogenee multiple mediante il meccanismo di location transparency locale o remoto, abilita il mapping delle istanze multiple della risorsa logica nella stessa risorsa fisica, permette che la gestione delle risorse venga fatta all’interno di una organizzazione virtuale. Inoltre, permette anche la composizione di servizi semplici per la costruzione di servizi più sofisticati. La virtualizzazione è più

semplice se le funzioni di un servizio possono essere invocate in una forma standard e per questo motivo viene utilizzato il WSDL.

WSDL adotta un’interfaccia di servizio detta “definition”, che è distinta dal protocollo bindings (CORBA, SOAP, DCOM) usato per l’invocazione di un servizio. Inoltre, tiene conto dei bindings multipli per una singola interfaccia, includendo i protocolli di comunicazione distribuiti per le interazioni tra i processi che usano un servizio e processi che effettuano una richiesta (di servizio) sullo stesso host. Altre proprietà binding possono includere l’affidabilità come pure l’autenticazione e la delegazione di credenziali.

OGSA supporta il meccanismo di location transparency locale e remoto rispetto all’individuazione e all’invocazione di un servizio. Inoltre fornisce il protocollo bindings (CORBA, SOAP, DCOM) per facilitare l’invocazione dei servizi quando questi sono ospitati localmente dal richiedente.

2.2.1 Semantiche di servizio: Grid Service (Servizio di Griglia)

2

Per virtualizzare e comporre dei servizi sono necessarie delle definizioni di interfacce standard e delle semantiche standard per le interazioni di un servizio in modo che altri servizi seguano le stesse convenzioni. Per questo scopo, OGSA definisce il Grid Service, cioè un Web service che fornisce un insieme di interfacce ben definite che segue specifiche convenzioni. Le interfacce sono rivolte al discovery, alla creazione dinamica, al lifetime management, alla notifica ed alla maneggiabilità di un servizio; le convenzioni, invece, sono rivolte al naming ed all’espandibilità (upgradebility) di un servizio. Inoltre, in OGSA sono previste delle interfacce per l’autorizzazione ed il controllo della concorrenza, mentre altri due aspetti importanti quali l’autenticazione e l’invocazione attendibile di un servizio sono visti come un protocollo bindings di

2 _{Nel seguito di questo capitolo e della stessa tesi useremo indistintamente le espressioni}

un servizio e per questo sono esterni alla definizione del core Grid Service, ma devono essere presi in considerazione all’interno di una completa implementazione OGSA.

Le interfacce e le convenzioni che definiscono un Grid Service sono rivolte, in particolare, ad aspetti riguardanti la gestione di istanze di servizi transitorie. La necessità di utilizzare nella Griglia le istanze di servizio transitorie deriva dal fatto che i Web Services permettono di scoprire ed invocare servizi persistenti e questo può creare un problema di condivisione degli accessi, in quanto è possibile invocare contemporaneamente lo stesso metodo dello stesso servizio. Inoltre, i Web Services sono stateless, cioè non è possibile mantenere informazioni tra un’invocazione e l’altra del servizio, mentre nella Griglia ad ogni istanza di servizio è associato uno stato logico persistente (questo potrebbe creare un problema di gestione della concorrenza). Infatti, le VO di una griglia non contengono solo un insieme statico di servizi persistenti che gestiscono le richieste dei client per attività complesse, ma anche nuove istanze di servizio transitorie instanziate dinamicamente che amministrano la gestione e le interazioni associate allo stato delle specifiche attività richieste. Quando lo stato di una attività non è più necessario, l’istanza di servizio può essere distrutta.

2.2.1.1 Convenzioni di Espansibilità (Upgradeability) e Protocolli di Trasporto

In un sistema distribuito complesso i servizi devono essere indipendentemente espandibili (upgradeable). La versione e la compatibilità tra i servizi devono essere gestite ed espresse in modo che i clienti possano scoprire non solo le versioni di uno specifico servizio, ma anche i servizi compatibili tra loro. Inoltre, i servizi e gli ambienti ospitanti (hosting) in cui essi sono eseguiti devono essere espandibili senza interrompere le azioni richieste dal cliente. Ad esempio, un aggiornamento di un ambiente hosting può cambiare l’insieme dei

protocolli di rete, che possono essere utilizzati per comunicare con un servizio, mentre un aggiornamento di un servizio può correggere i malfunzionamenti o anche aggiungere all’interfaccia altre operazioni da poter eseguire sul servizio. Quindi OGSA definisce delle convenzioni che permettono di identificare quando un servizio cambia lo stato e quando questi cambiamenti sono incompatibili rispetto alle interfacce e alle semantiche vigenti; definisce anche dei meccanismi per permettere ad un cliente di essere sempre aggiornato su di un servizio, ovvero conoscere sempre quali protocolli di rete possono essere usati per comunicare o quali operazioni sono compatibili con tale servizio. Una descrizione di un sevizio indica il protocollo bindings (CORBA, SOAP, DCOM) che può essere usato per comunicare con il servizio stesso ed in tali bindings sarà richiesta la presenza delle seguenti proprietà:

• Invocazione attendibile di un servizio. I servizi interagiscono tra di loro

scambiandosi messaggi. Un sistema distribuito è per sua natura incline ai fallimenti delle sue componenti e perciò non si può garantire che un messaggio inviato ad un componente sia stato ricevuto. L’esistenza dello stato interno deve garantire che un servizio abbia ricevuto correttamente i messaggi a lui destinati.

• Authentication. I meccanismi di autenticazione permettono di

conoscere l’identità delle persone e dei servizi che sono stati stabiliti per mezzo di una politica predefinita. Per questo motivo sarà necessario avere un protocollo di trasporto che provvede all’autenticazione dei clienti e delle istanze di servizio.

2.2.1.2 Interfacce standard

Le interfacce (dette in WSDL “portType”) che definiscono un Grid service sono elencate nella Tabella 1 (mostrata nella pagina seguente). Sono state introdotte qui, ma verranno trattate più approfonditamente nella sezione 3, cioè

quella in cui viene data una descrizione più dettagliata delle convenzioni, delle astrazioni e delle interfacce associate ai servizi di Griglia.

3 _{Handle: è usato in modo generale per identificare il concetto più specifico di GSH}

(Grid Service Handle) che è un URI (Uniform Resource Identifier) che identifica in modo uniforme un’istanza di un servizio

4 _{Grid Service Reference (GSR): documento WSDL che contiene informazioni sulla}

PortType Operazione Descrizione

FindServiceData Viene utilizzata per fare la ricerca di istanze di servizi di Griglia con specifiche caratteristiche. Per far questo utilizza le informazioni descriventi un servizio.

SetTerminationTime Imposta e invia il tempo di terminazione per l’istanza di un servizio di Griglia

GridService

Destroy Termina l’istanza di servizio di Griglia

Notification-Source SubscribeTo-NotificationTopic Utilizzata per condividere le notifiche di eventi connessi ad un servizio, basati sul tipo di messaggio e sullo stato di interesse. Notification-

Sink DeliverNotification Esegue la “consegna” dei messaggi di notifica in modo asincrono. RegisterService Gestisce una registrazione soft-state delle

handle3 _{del servizio di Griglia} Registry

UnregisterService Cancella la registrazione della handle del Grid service

Factory CreateService Crea una nuova istanza di un Grid service HandleMap FindByHandle Restituisce il Grid Service Reference

(GSR)4 correntemente associato al Grid Service Handle passato in input

Discovery. Le applicazioni richiedono dei meccanismi per il discovering dei

servizi utilizzabili e per individuare le caratteristiche di tali servizi. Ciò comporta che quest’ultimi vengono configurati in maniera appropriata come pure le richieste rivolte loro. Tali richieste sono inviate definendo:

• una rappresentazione standard per i service data, che sono

informazioni sulle istanze di servizio Griglia, le quali sono rappresentate come un insieme di elementi XML che hanno un tipo ed un nome, detti services data elements;

• una operazione standard, la FindServiceData, per recuperare i service

data dalle singole istanze di servizio di Griglia (modalità di accesso “pull”);

• interfacce standard utilizzate per registrare l’informazione riguardante

le istanze di servizio di Griglia con i servizi di registrazione (Registry) e per mappare le “handle” ai “reference5” (HandleMap);

Creazione dinamica di un servizio. La possibilità di creare e gestire

dinamicamente un servizio è il principio base del modello OGSA e quindi è necessaria l’esistenza di un servizio adibito a questo scopo. Il modello OGSA fornisce un’interfaccia standard (Factory) utilizzata per la creazione di un servizio.

Lifetime Management. Nei sistemi distribuiti è alta la probabilità che le

operazioni tra i servizi non vengano eseguite correttamente a causa di fallimenti che occorrono durante l’elaborazione di tali operazioni, perciò è necessario che tali sistemi prevedano funzionalità atte a trattare i fallimenti. In un sistema che include le istanze di un servizio transitorio, devono essere inclusi dei meccanismi per recuperare i servizi e lo stato associato alle operazioni fallite. Per soddisfare queste richieste sono state definite due operazioni standard: Destroy e

SetTerminationTime utilizzate, rispettivamente, per la distruzione e il lifetime

management delle istanze di servizio di Griglia.

Notification. Una collezione di servizi distribuiti e dinamici deve poter

notificare, in maniera asincrona, ogni cambiamento che riguardi il loro stato. OGSA definisce le astrazioni comuni ad un servizio e le interfacce di servizio per la condivisione di “eventi” (NotificationSource), e per il discovery di “eventi” (NotificationSink) come notifications. Tale classificazione è data dalla necessità che i servizi derivati dalla composizione di servizi più semplici possono trattare tali notifications (ad esempio messaggi di errore) in un modo standard. L’interfaccia NotificationSource è integrata con un service data, in modo che una richiesta di notifica sia espressa come una richiesta che precede una successiva restituzione, in modalità “push”, del service data.

Altre interfacce. Oltre alle interfacce standard sopra elencate, il Global Grid

Forum (GGF) [24] ha definito altre interfacce rivolte ai problemi quali l’autorizzazione ed il controllo degli accessi. Inoltre, per il prossimo futuro saranno definite delle interfacce addizionali standard rivolte a problemi quali la gestione della politica, il monitoraggio e la gestione di insiemi potenzialmente grandi di istanze di servizio di Griglia.

2.2.2 Il ruolo degli Hosting Environments (Ambienti Ospitanti)

OGSA definisce le semantiche di un’istanza di servizio di Griglia, cioè come creare un servizio, come invocarlo, come determinare il suo lifetime, come comunicare con il servizio ed altro ancora, ma non si occupa di altri aspetti quali il modello di programmazione e gli strumenti da utilizzare per l’implementazione di un servizio, il linguaggio di programmazione più adatto. Di questi aspetti se ne occupa invece l’ambiente di esecuzione, detto hosting environment, che non solo

definisce tali aspetti, ma stabilisce anche come un’implementazione di un servizio Griglia debba rispettare le semantiche del servizio di Griglia stabilite da OGSA.

Nell’ambito e-science le applicazioni Griglia fanno affidamento sui processi di un sistema operativo visti come hosting environment, dove ad esempio la creazione di un’istanza di servizio richiede la creazione di un processo. In tali ambienti un servizio può essere implementato con diversi linguaggi di programmazione come C, C++, Java o Fortran.

Al contrario, i Web services possono essere implementati su hosting environment più sofisticati di tipo container o component-based come J2EE, Websphere, .NET e Sun One. Tali ambienti definiscono una struttura (container) dentro cui le componenti dell’ambiente aderiscono alle interfacce standard definite su di essi e possono essere istanziati e composti per costruire applicazioni complesse. Confrontati con gli hosting environment originari che forniscono scarse funzionalità, gli hosting environment di tipo component/container tendono ad offrire una maggiore programmabilità, gestibilità, flessibilità e sicurezza. Di conseguenza, gli hosting environment basati su component/container sono ampiamente usati per la costruzione di servizi e-business.

Nel contesto OGSA, un container (hosting environment) ha la responsabilità primaria di assicurarsi che i servizi che tale ambiente supporta, rispecchino le semantiche del servizio di Griglia in modo da renderli OGSA-compliant.

Nel definire le semantiche di un servizio, OGSA definisce le interazioni tra i servizi in modo indipendente da qualunque hosting environment. Tuttavia l’implementazione di un servizio di Griglia può essere facilitata specificando delle caratteristiche di base che tutti gli hosting environment devono avere e definendo le interfacce “interne” all’ambiente che vengono esposte all’ambiente Griglia globale.

2.2.3 Costruire strutture di una VO utilizzando “meccanismi”

OGSA

Le applicazioni devono poter creare e scoprire servizi transitori e determinare le proprietà dei servizi accessibili. Le interfacce Registry, Factory, GridService ed HandleMap di OGSA favoriscono la creazione di istanze di servizio transitorie, la scoperta e la rappresentazione delle istanze di servizio associate ai VO. Queste interfacce possono essere utilizzate per costruire una varietà di strutture di servizi offerti da un VO, come illustrato nella Figura 2.1 e descritto nel seguito.

Ambienti ospitanti semplici. Un semplice ambiente di esecuzione è un

insieme di risorse individuate dentro un singolo dominio amministrativo. In OGSA, l’interfaccia utente per un tale ambiente sarà strutturata come un servizio registry, uno o più servizi factory ed un servizio handleMap6. Gli handle che identificano le factory sono memorizzati nel registry per permettere ai client di scoprire le factory utilizzabili. Quando una factory riceve una richiesta client per creare un’istanza di servizio Griglia, invoca le funzionalità di uno specifico hosting environment in modo da creare una nuova istanza di servizio a cui assegnare una handle, successivamente memorizza l’istanza creata tramite il registry e rende lo handle utilizzabile per il servizio handleMap.

Hosting environment virtuali. In ambienti più complessi le risorse associate

ad un VO espanderanno gli hosting environment geograficamente distribuiti ed eterogenei (ad esempio, in Figura 2.1 queste risorse espandono due hosting environment semplici). Questi “hosting environment virtuali” possono essere resi accessibili ai client attraverso la stessa interfaccia utilizzata per gli hosting

6 _{I servizi hanno di solito il nome, scritto in minuscolo, dell’interfaccia che forniscono.}

environment semplici. In tali ambienti sono create delle factory ad un “livello più alto” (vedere Figura 2.1) che delegano le richieste di crezione alle factory del livello più basso. Allo stesso modo viene creato un registry ad un livello più alto che conosce le factory a tale livello e le istanze di servizio che esse hanno creato. I client possono usare il registry del VO per trovare le factory e le altre istanze di servizio associate al VO e, successivamente, possono usare le handle restituite dal registry per invocarle direttamente. Le factory ed il registry al livello più alto implementano interfacce standard in modo da essere indistinguibili da altre factory e registry.

Collective operations. E’ possibile costruire un ambiente ospitante virtuale

che fornisce partecipanti VO con servizi virtuali “end-to-end” o “collective” più sofisticati. In questo caso il servizio registry tiene traccia delle factory che creano le istanze di servizio al livello più alto. Una tale istanza è realizzata chiedendo alle factory del livello più basso di creare istanze di servizio multiple che sono poi composte in un’unica istanza di servizio che sarà il risultato dell’invocazione di una delle factory del livello superiore (vedere Figura 2.1).

Figura 2.1 Tre differenti strutture di VO. Da sinistra a destra: hosting environment semplice, hosting environment virtuale, collective services.

Questi tre esempi e la discussione precedente illustrano come i “meccanismi” definiti da OGSA possono essere usati per integrare le risorse distribuite sia attraverso i confini di più VO sia all’interno delle infrastrutture IT commerciali. In entrambi i casi un insieme di servizi di Griglia, registrato insieme ad appropriati servizi di discovery, può favorire le interazioni di quality-of-service tra insiemi di risorse distribuite. Le applicazioni ed il middleware possono sfruttare questi servizi per la gestione delle risorse distribuite tra piattaforme eterogenee.

2.3 Dettagli Tecnici

In questa sezione sarà data una descrizione più dettagliata delle convenzioni, delle astrazioni e delle interfacce associate ai servizi Griglia.

2.3.1 Il modello di servizio OGSA

Una premessa base che viene fatta in OGSA è che ogni cosa è rappresentata come un servizio (Grid service): risorse computazionali, risorse di memorizzazione, reti, databases. L’adozione di un modello service-oriented uniforme implica che tutti i componenti di un ambiente sono virtuali.

Un servizio di Griglia implementa delle interfacce (portTypes in WSDL), dove ognuna di esse definisce un insieme di operazioni che sono invocate per scambiare una precisa sequenza di messaggi. I servizi di Griglia possono mantenere lo stato interno per il lifetime del servizio. L’esistenza dello stato distingue un’istanza di un servizio da un’altra che fornisce la stessa interfaccia, e viene utilizzato in tal senso il termine istanza di un servizio Griglia.

I servizi OGSA possono essere creati e distrutti dinamicamente, in particolar modo essi possono essere distrutti esplicitamente o divenire inaccessibili in seguito ad un fallimento di sistema, come ad esempio il crash del sistema

operativo o di una partizione della rete. In questo contesto le interfacce sono state definite per gestire il lifetime di un servizio. Poiché i servizi di Griglia sono dinamici e con stato, è necessario definire un modo per distinguere un’istanza di un servizio creata dinamicamente da un’altra. Per questo motivo ad ogni istanza viene assegnato un nome globalmente unico, il Grid Service Handle (GSH) che distingue una specifica istanza di servizio di Griglia da tutte le altre istanze sia quelle che sono state create prima, sia quelle che verranno dopo tale istanza. Il GSH non consente ad un client di comunicare con un servizio di Griglia, per questo è stato necessario definire un documento WSDL che descrive in che modo si effettua la comunicazione con il servizio, dove è allocato, il protocollo bindings da utilizzare durante la comunicazione, l’indirizzo di rete a cui connettersi ed tutte le informazioni necessarie per interagire con una specifica istanza di servizio. Tale documento è chiamato Grid Service Reference (GSR). Diversamente dal GSH, il GSR, può cambiare durante il lifetime del servizio. A tal proposito, al momento della creazione viene assegnato al GSR un esplicito tempo di terminazione che potrebbe non concludersi correttamente; infatti, il GSR potrebbe essere “invalidato” in qualsiasi momento durante il lifetime del servizio (ad esempio a causa di un fallimento di sistema) e per questo motivo OGSA definisce un meccanismo di mapping, descritto in seguito, che restituisce un GSR aggiornato. E’ necessario notare che l’utilizzo di un GSR valido non garantisce l’accesso alle istanze di servizio di Griglia perchè le politiche locali o le restrizioni per il controllo degli accessi possono proibire che una simile richiesta venga soddisfatta. Inoltre, un’istanza di servizio di Griglia può fallire prima che il GSR possa essere usato (ad esempio quando un client vuole connettersi ad una istanza di servizio di Griglia ed è in attesa di ricevere il GSR per farlo).

Come detto in precedenza, ogni cosa in OGSA è un servizio di Griglia, pertanto devono esistere dei servizi di Griglia che gestiscono: altri servizi di Griglia, handle e le astrazioni di riferimento che definiscono il modello OGSA.

Per definire tali servizi in [3] è stato deciso di adottare un approccio flessibile e di definire un insieme di interfacce base in OGSA che possono essere combinate in modi differenti per produrre un ricco insieme di servizi di Griglia. La

Tabella 2.1 mostrata nelle pagine precedenti riporta i nomi e le descrizioni di tali interfacce. E’ importante notare che tra le interfacce della Tabella 2.1 vi è l’interfaccia GridService che è la sola che “deve” essere implementata da tutti i servizi di Griglia.

2.3.2 Creazione di servizi transitori: Factory

OGSA definisce una classe di servizi di Griglia che implementano un’interfaccia, detta Factory, la quale crea nuove istanze di un servizio di Griglia. Un servizio che implementa una tale interfaccia è detto factory. Per creare un’istanza di un servizio di Griglia l’interfaccia Factory offre l’operazione “CreateService” che crea una nuova istanza di tale servizio e restituisce al richiedente il GSH e il GSR iniziale per la nuova istanza creata.

L’interfaccia Factory non specifica come l’istanza del servizio sia creata. Uno scenario comune per tale interfaccia è implementato in qualche modo dallo hosting environment, che fornisce meccanismi standard per la creazione di nuove istanze di servizio. Lo hosting environment può definire come sono implementati i servizi (ad esempio il linguaggio di programmazione usato), ma questo in OGSA è trasparente ai richiedenti del servizio, che vedono solo l’interfaccia Factory.

2.3.3 Servizio di Lifetime Management

L’introduzione delle istanze di un servizio transitorie pone il problema di determinare il lifetime di un servizio, cioè determinare quando un servizio potrebbe terminare, in modo da recuperare le risorse che gli erano state associate.

elaborare uno specifico task, e termina con il completamento del task stesso, oppure attraverso una esplicita richiesta da parte del richiedente o da parte di un altro servizio designato dal richiedente. Nei sistemi distribuiti le componenti di un sistema possono fallire ed i messaggi possono essere perduti, per questo un servizio potrebbe non ricevere la richiesta di terminazione esplicita e di conseguenza potrebbe consumare illimitatamente le risorse che gli sono state assegnate. OGSA si occupa di questo problema con un approccio “soft state” in cui le istanze di un servizio di Griglia sono create con uno specifico lifetime.

Il lifetime iniziale può essere esteso per un certo periodo di tempo se il client effettua una specifica richiesta di estensione del lifetime o se quest’ultima viene effettuata da parte di un servizio di Griglia per conto del client stesso. Se tale tempo “extra” termina senza che l’istanza del servizio abbia ricevuto ulteriori richieste di estensione da parte del client, allora lo hosting environment ha la libertà di terminare l’istanza di servizio e di rilasciare alcune delle risorse associate.

Una possibile implementazione del lifetime management “soft state” può essere fatta attraverso l’operazione SetTerminationTime (Tabella 2.1) fornita dall’interfaccia GridService, la quale tramite le sue operazioni permette di definire un lifetime iniziale da assegnare alla nuova istanza di un servizio, di richiedere un’estensione del lifetime e di recuperare l’istanza del servizio quando il suo lifetime è scaduto. L’assegnazione del lifetime iniziale e quella di un’eventuale estensione non è casuale, infatti vi sono delle regole da seguire:

• Assegnazione di un lifetime iniziale. Quando viene richiesta la

creazione di una nuova istanza di un sevizio di Griglia attraverso il servizio factory, il client indica un tempo minimo ed uno massimo accettabili per il lifetime iniziale. Il servizio factory ne seleziona uno all’interno di tale intervallo e lo restituisce al client.

• Richiesta di un’estensione del lifetime. Un client richiede

SetTerminationTime inviato all’istanza del servizio di Griglia, in cui è specificato un tempo minimo ed uno massimo accettabili per il nuovo lifetime. L’istanza del servizio seleziona il nuovo lifetime e lo restituisce al cliente.

Nell’operazione SetTerminationTime viene utilizzato il tempo assoluto, questo implica l’esistenza di un orologio globale che è sufficientemente ben sincronizzato e per questo scopo viene utilizzato il Network Time Protocol

(NTP), che fornisce meccanismi standard per la sincronizzazione (dell’orologio).

2.3.4 Gestione delle Handle e dei Reference

Come discusso in precedenza, il risultato di una richiesta factory è un GSH ed un GSR; il primo riferisce in maniera univoca l’istanza di un servizio di Griglia creata, mentre il secondo è creato con un lifetime finito e può cambiare durante il lifetime del servizio. Questa strategia ha il vantaggio di una maggiore flessibilità dalla prospettiva del fornitore dei servizi di Griglia, ma introduce il problema di ottenere un valido GSR una volta che il primo, cioè quello restituito dall’operazione di creazione del servizio, è terminato.

L’approccio adottato in OGSA è di definire un’interfaccia HandleMap che tenga traccia della corrispondenza handle-reference. L’operazione (FindByHandle) fornita da questa interfaccia prende un GSH e restituisce un GSR valido. Il possesso di un GSR valido non assicura che un’istanza di un servizio sia contattata poiché, da quando viene rilasciato a quando viene utilizzato, l’istanza di servizio può essere fallita o può essere terminata.

Introducendo l’interfaccia HandleMap, il problema di ottenere un GSR per un arbitrario servizio è suddiviso in due sottoproblemi più specifici:

1. Identificare un servizio HandleMap che contiene il mapping per il GSH specificato e

Per essere sicuri che si possa sempre mappare un GSH ad un GSR è necessario che ogni istanza di servizio di Griglia sia registrata ad almeno un servizio handleMap, che viene detto home handleMap. Se si definisce il GSH in modo da includere l’identità dello home handleMap si può determinare quale servizio handleMap contattare per ottenere un GSR per un dato GSH. Pertanto è necessario che ogni GSH abbia associato esattamente un handleMap.

Si potrebbe richiedere un GSR ad un handleMap senza richiedere un servizio handleMap stesso, infatti si potrebbe richiedere che tutti i servizi del home handleMap siano identificati da un URL e che supportino un protocollo ben conosciuto, come HTTP (o HTTPs). Quindi, invece di usare un GSR per descrivere quale protocollo adoperare per contattare il servizio handleMap, viene utilizzata l’operazione HTTP GET applicata alla URL che indirizza alla home handleMap e restituisce, in forma WSDL, il GSR per il servizio handleMap.

Esiste un rapporto tra i servizi che implementano le interfacce HandleMap e Factory, in particolar modo il GSH restituito da una richiesta factory deve contenere la URL della home handleMap, ed il mapping GSH/GSR deve essere inserito ed aggiornato nel servizio handleMap. L’implementazione di un servizio factory deve decidere quale servizio usare come home handleMap. In generale un servizio può implementare sia l’interfaccia Factory che quella HandleMap.

2.3.5 Service Data e Discovery del Servizio

Ad ognuna delle istanze di un servizio di Griglia è associato un insieme di dati, cioè una collezione di elementi XML raggruppati come service data element del servizio. La struttura di ogni elemento include un nome che identifica univocamente l’istanza di un servizio di Griglia, un tipo e l’informazione del time-to-live che può essere utilizzata da chi richiede un servizio per eseguire il lifetime management.

L’interfaccia GridService definisce un’operazione WSDL standard, la FindDataService, con cui si possono chiedere e recuperare i service data. Associato a tale interfaccia c’è un insieme di elementi contenenti informazioni base riguardanti un’istanza di un servizio di Griglia, come GSH, GSR e la home handleMap. Un’applicazione dell’operazione FindServiceData offerta dall’interfaccia GridService è il discovery del servizio, che è definito come il processo che identifica un sottoinsieme di GSH da un insieme basato sugli attributi di un servizio quali il GSH, le interfacce fornite da un servizio, il numero di richieste servite ed il carico del servizio.

Un servizio Griglia che permette il discovery del servizio è chiamato registry, il quale è definito da due caratteristiche:

• l’interfaccia Registry, che fornisce le operazioni tramite cui i GSH

possono essere registrati

• un service data element associato che è usato per contenere le

informazioni riguardanti i GSH registrati.

Quindi l’interfaccia Registry è usata per registrare i GSH e l’operazione FindServiceData dell’interfaccia GridService è utilizzata per recuperare le informazioni riguardanti i GSH registrati.

2.3.6 Atre Interfacce

Oltre alle interfacce sopra citate e’ stata definita un’interfaccia, Manegiability interface, utilizzata per fornire un insieme di operazioni, che permettono di gestire insiemi potenzialmente grandi di istanze di servizio Griglia. Un’altra interfaccia che sarà definita è la Concurrency interface, che fornirà le operazioni per il controllo della concorrenza.