Analisi e valutazione dei servizi di globus Toolkit per la gestione delle informazioni e la ricerca di dati su griglia

particolare vengono elencati i passi necessari alla realizzazione e il deployment 
di  un Web  Service,  illustrando  il  significato  di  documento WSDL  e WSDD; 
infine un paragrafo  è dedicato  alla  gestione della  sicurezza  in GT4,  in  cui  si 
parla della GSI  – Grid Security  Infrastructure  e degli  standard utilizzati per  le 
differenti funzioni di autenticazione e autorizzazione. 
A  questo  punto  ci  si  addentra  all’interno  dell’architettura  del  GT4,  e 
vengono quindi descritti dettagliatamente i componenti fondamentali. 
Il capitolo 3 – Common Runtime – è dedicato a quella parte di GT4, che si 
occupa di  fornire  i  tools mediante  i quali un Web Service è reso  indipendente 
dalla piattaforma sulla quale andrà ad essere eseguito. In particolare si parlerà 
del  Java WS Core,  e dei  servizi  Java  offerti da  tale  tool,  tra  cui  lo  startup del 
container,  la  gestione  delle  risorse,  l’implementazione  del WSRF. Allo  stesso 
modo  il  C WS  Core  si  occupa  degli  medesimi  servizi  appena  descritti,  ma 
realizzati  in  linguaggio C. Sarà  l’utente a decidere quale utilizzare  in base alle 
proprie  preferenze.  Dopo  aver  brevemente  descritto  le  C  Common  Libraries, 
utilizzate  per manipolare  diversi  tipi  di  dati,  viene  descritto  un  componente 
fondamentale  quale Globus XIO  –  eXtensible  Input Output;  esso  è una  libreria 
estendibile per  l’input/output  che ha  come  obiettivo  fornire una  singola user 
API per tutti i protocolli di I/O della griglia, e di ridurre al minimo il tempo di 
sviluppo per la creazione di nuovi protocolli. 
Il  quarto  capitolo  –  Information  Service MDS4 ‐   introduce  i  componenti 
relativi alla ricerca e monitoraggio di servizi e risorse all’interno della griglia. In 
particolare  viene  descritta  l’architettura  di MDS4  e  le  relative Web  Service 
Interface  che  permettono  all’utente  di  trovare  risorse  e  servizi, monitorare  il 
loro stato, ricevere aggiornamenti sullo stato corrente, visualizzare i risultati di 
tale monitoraggio; verranno mostrati degli esempi di registrazione all’Index e al 
Introduzione 
ii
Trigger Service di Globus; verranno illustrati inoltre alcuni studi di prestazione 
del servizio confrontati con le precedenti implementazioni. 
Il capitolo 5  ‐ Execution Management – si riferisce a quei componenti che si 
occupano  di  inizializzare,  monitorare,  gestire,  schedulare  o  coordinare 
computazioni  remote.  Si  parlerà  in  particolare  del  servizio  GRAM  –  Grid 
Resource Allocatione and Management – e di come esso gestisce le risorse. 
In  una  griglia  computazionale,  dove  i  vari  nodi  possono  essere 
geograficamente distribuiti, un aspetto molto  importante  riguarda  le modalità 
di gestione dei dati,  in particolare  il  trasferimento degli  stessi  e  la  loro  facile 
reperibilità. A  tali  funzionalità  è dedicato  il  capitolo  6  – Data Management.  Si 
parlerà di GridFTP come protocollo per il trasferimento dati, verranno descritte 
le sue principali caratteristiche e funzionalità; verrà inoltre descritto come il solo 
GridFTP non sia sufficiente a  realizzare dei  trasferimenti dati affidabili, per  i 
quali  è  necessario  che  esso  sia  coadiuvato  dal  servizio  RFT  –  Reliable  File 
Transfer. Verranno illustrati degli esempi di trasferimento RFT, spiegando i vari 
parametri di  configurazione. Come detto  in precedenza è  importante  la  facile 
reperibilità  dei  dati  sulla  griglia;  a  tal  fine  viene  introdotto  quindi  il  Replica 
Location Service, che  si occupa di  tenere  traccia di una o più copie degli  stessi 
dati: ciò significa anche migliorare l’affidabilità in caso di guasti. 
Infine, l’ultimo capitolo è dedicato all’applicazione di alcuni servizi fin qui 
illustrati a un caso di studio. Il capitolo 7 – Caso di studio: applicazione dei servizi 
di  Globus  a  un  portale  di  geoprocessing  – mostra  infatti  l’implementazione  del 
servizio  RFT  e  dell’Index  Service  in  un  Grid  Portal  realizzato  all’interno 
dell’ICAR‐CNR,  e  vengono  fatti  vedere  alcuni  studi  di  prestazione  dei 
trasferimenti RFT,  in riferimento alla durata dei trasferimenti e al bitrate degli 
stessi.
 
Introduzione 
iii
  
 
 
 
 
Introduzione alle 
 Griglie computazionali 
 
 
 
 
 
 
 
 
 
 
 
 
na  griglia  computazionale  è  un  sistema  che  coordina  risorse  che  non 
sono oggetto di controllo centralizzato, che usa protocolli ed  interfacce 
standard,  aperte  e  per  scopi  pubblici  e  che  soddisfa  vari  tipi  di  qualità  del 
servizio.  
U 
Lo scopo delle griglie è quello di condividere delle risorse in modo coordinato, 
sicuro e flessibile tra un insieme di individui ed istituzioni.  
Ciò che si vuole fare è permettere a gruppi di utenti (Organizzazioni Virtuali) di 
condividere  delle  risorse  geograficamente  distribuite,  assumendo  appunto 
l’assenza di localizzazione centralizzata delle risorse, controllo centralizzato ed 
esistenza di relazioni di fiducia. 
Una  Organizzazione  Virtuale  è  definita  come  un  insieme  di  individui  o 
istituzioni  identificate  dall’essere  sottoposti  allo  stesso  insieme  di  regole,  che 
definisce: 
• Quali risorse condividere 
• A quali utenti è permesso di condividerle 
• Le condizione alle quali le risorse debbano essere condivise. 
I singoli membri possono  far parte di una o più organizzazioni virtuali, come 
mostrato dalla seguente figura: 
 
Fig 1: esempio di struttura di una griglia, in cui ogni membro può appartenere a diverse 
organizzazioni virtuali
Introduzione alle Griglie Computazionali 
2
 La  condivisione  delle  risorse  richiede  che  i  possessori  rendano  le  risorse 
disponibili,  e  sottoponendole  ai  vincoli  di  quando,  dove  e  come  farlo.  Ciò 
comporta la presenza di: 
• Politiche e meccanismi per esprimere le risorse 
• Autenticazione: l’assegnazione di un identificativo al consumer 
• Autorizzazione:  stabilire  se  un’operazione  è  conforme  alle  politiche  di 
condivisione della risorsa. 
Le  tecnologie antecedenti  la nascita delle griglie non erano adatte a gestire  le 
regole appena introdotte, in quanto vi erano diverse incompatibilità: 
• Richieste  complesse:  ad  esempio  “esegui  il  programma X  sul  sito Y  e 
sottoponilo alla politica di P, fornendo accesso ai dati a Z in accordo con 
le politiche di Q” 
• Alte prestazioni: sono necessarie delle alte performance 
• Risorse eterogenee: computers, reti, modalità di memorizzazione, ecc. 
• La  condivisione deve  sempre  sottostare a delle  condizioni  (pagamento, 
negoziazione, politica, ecc) 
La nascita dei  sistemi di analisi e computazione di dati distribuiti non è altro 
che un’estensione della più semplice modalità client‐server. 
Se dobbiamo dare una definizione formale di Griglia, possiamo rifarci a quanto 
esposto  nel  libro  di  I.Foster  e  C.Kesselman:  The  Grid:  Blueprint  for  a  New 
Computing Infrastructure, ovvero: 
Una griglia computazionale  è un’infrastruttura hardware e software che fornisce un 
accesso consistente, economico e dominante ad elevate capacità computazionali  
Introduzione alle Griglie Computazionali 
3
  
 
 
 
 
 
 
 
 
 
 
 
 
 
Capitolo 1: 
Griglie e Web Service 
 
 
 
 
 
 
 
 
 
 
 
 
Capitolo 1 – Griglie e Web Service 
1.1 Concetti fondamentali 
Un’applicazione  di  griglia  si  compone  di  numerosi  e  differenti 
componenti. Ad esempio, una tipica grid application potrebbe avere: 
 
• VO Management Service – per gestire quali nodi  e quali utenti  fanno 
parte di una particolare organizzazione virtuale 
• Resource  Discovery  and  Management  Service  –  in  modo  che  le 
applicazioni possano trovare le risorse di cui hanno bisogno in base alle 
loro necessità, e gestire tali risorse 
• Job Management Service – per permettere agli utenti  si  sottoporre dei 
job alla griglia 
• Altri servizi – inerenti la sicurezza, la gestione dei dati, ecc. 
 
Tutti questi servizi sono  in costante  interazione  fra di  loro. Ad esempio  il  Job 
Management  Service  potrebbe  consultare  il  Resource  Discovery  Service  per 
trovare  una  risorsa  computazionale  che  soddisfi  i  requisiti  del  job.  Con  un 
numero così elevato di  servizi, e un  livello così alto di  interazione  tra di essi, 
sussiste la reale possibilità di creare confusione e caos. Se ogni individuo decide 
di  implementare  un  Job  Management  Service  in  un  modo  completamente 
diverso  dagli  altri,  esporrebbe  agli  altri  delle  interfacce  differenti,  e  sarebbe 
davvero  difficile  (se  non  impossibile)  permettere  a  tutti  i  vari  componenti 
software di lavorare insieme. 
La soluzione al problema descritto consiste nella standardizzazione: definire 
un tipo di interfaccia comune per  ogni tipologia di servizio. 
La Open Grid Services Architecture  (OGSA),  sviluppata dal Global Grid 
Forum,  ha  proprio  lo  scopo  di  definire  un’architettura  comune,  standard  e 
Capitolo 1 – Griglie e Web Service 
5
aperta  per  le  applicazioni  basate  sulle  griglie.  L’obiettivo  di  OGSA  è 
standardizzare praticamente tutti i servizi che generalmente vengono offerti da 
un’applicazione  di  griglia  (servizi  di  job  management,  servizi  di  resource 
management,  servizi  di  sicurezza,  ecc)  specificando  un  insieme  di  interfacce 
standard  per  tali  servizi.  Tale  insieme  di  interfacce  è  tuttora  in  fase  di 
elaborazione,  ma  OGSA  ha  già  definito  quelle  necessarie  per  garantire  la 
corretta esecuzione dei principali servizi che un  individuo  incontra nelle Grid 
applications. 
Al fine di creare tale tipo di architettura è stato necessario individuare una 
sorta di middleware distribuito su cui basare la stessa. In altre parole, se OGSA 
stabilisce  che  l’interfaccia  JobSubmissionInterface  ha  il metodo  submitJob(),  ci 
deve  essere  un  procedura  standard  comune  per  invocare  tale  metodo.  La 
tecnologia scelta a sottostare a tale tipo di esigenze è quella dei Web Service. 
 
La  particolare  tipologia  di Web  Service  necessari  è  tuttavia  quella  degli 
stateful. Il Web Service Resource Framework (WSRF)  è una specifica definita da 
OASIS,  e  il  cui  obiettivo  è  proprio  quello  di  rendere  i  nostri Web  Service 
stateful. WSRF è uno sforzo comune delle communities della Griglia e dei Web 
Services, perciò si adatta abbastanza bene all’interno dell’intera architettura dei 
Web Services (WSRF estende i Web Services). 
 
Possiamo  affermare  che  OGSA  costituisce  l’architettura,  mentre  WSRF 
costituisce l’infrastruttura sulla quale l’architettura è stata costruita: infatti WSRF 
fornisce i servizi stateful di cui OGSA ha bisogno. 
Capitolo 1 – Griglie e Web Service 
6
 Fig 2: il ruolo di OGSA e di WSRF nella creazione di grid environment 
 
Quanto detto è rappresentato nella figura sopra (Fig 2), in cui notiamo che 
WSRF  specifica  dei Web  Service  Stateful,  mentre  OGSA  li  richiede;  i Web 
Service Stateful sono un’estenzione dei normali Web Service. 
 
1.2 Introduzione ai Web Services 
I Web Services possono essere definiti come una tecnologia di computing 
distribuito; essi permettono la creazione di applicazioni client/server. 
La differenza  tra un Web Site  e un Web Service  riguarda gli utilizzatori 
finali delle  informazioni che contengono:  le  informazioni contenute  in un  sito 
Web sono rivolte agli individui, quelle disponibili all’interno di un Web Service 
Capitolo 1 – Griglie e Web Service 
7
non  saranno mai accedute direttamente da un  individuo, ma  saranno  sempre 
accedute mediante software.  
 
Il  funzionamento dei Web Service è rappresentabile nella seguente  figura  (Fig 
3): 
 
Fig 3: funzionamento di un Web Service 
 
Il  client  invia  una  Service  Request  al Web  Service  ,  e  il Web  Service  in 
questione  risponde direttamente  al  client  inviandogli  le  informazioni  relative 
alla sua richiesta tramite una Service Response. 
I Web Services hanno degli ulteriori vantaggi rispetto alle altre tecnologie; 
infatti: 
• I Web Service sono  indipendenti dalla piattaforma  e dal  linguaggio,  in 
quanto essi utilizzano il linguaggio standard XML. 
• Molti Web Services utilizzano HTTP per la trasmissione dei messaggi. 
Allo  stesso  tempo,  come  risulta  inevitabile  per  qualsiasi  cosa,  sono  presenti 
anche dei fattori che costituiscono uno svantaggio di tale tecnologia, ovvero: 
• L’overhead. Trasmettere tutti i dati in formato XML è ovviamente molto 
meno  efficiente  rispetto  alla  trasmissione  binaria  dei  dati.  Ciò  che  si 
guadagna  in  portabilità  lo  si  perde  in  efficienza.  Nonostante  ciò 
l’overhead  risulta  generalmente  accettabile  per  la maggior  parte  delle 
Capitolo 1 – Griglie e Web Service 
8
applicazioni,  anche  se  sarà  praticamente  impossibile  realizzare 
un’applicazione real‐time che fa uso dei Web Services 
• La mancanza di versatilità. Attualmente  i Web Services non sono molto 
versatili, in quanto permettono solamente delle forme di invocazione dei 
servizi molto elementari. 
In  ogni  caso  c’è  una  caratteristica  importante  che  differenzia  i  Web 
Services. Mentre  le  tecnologie  come  CORBA  e  EJB  sono  orientate  a  sistemi 
distribuiti  altamente  accoppiati  (highly  coupled), dove  il  client  e  il  server  sono 
enormemente dipendenti l’uno dall’altro, i Web Services sono più adeguati per 
i  sistemi  scardamente  accoppiati  (loosely  coupled), dove  il  client potrebbe  non 
sapere  assolutamente  nulla  del Web  Service  che  andrà  ad  invocare  fino  a 
quando  esso  non  viene  effettivamente  invocato.  Comunque  i Web  Services 
soddisfano molto meglio le esigenze delle più aperte Internet application, come 
le applicazioni orientate alle griglie. 
 
1.3 Tipico scenario di esecuzione di un Web Service 
La richiesta di esecuzione di un Web Service coinvolge diverse operazioni 
da effettuare. Tali operazioni possono essere descritte in tal modo: 
1. Come già detto, un client potrebbe non sapere nulla sul Web Service che 
andrà ad  invocare. Perciò  il primo passo consiste nel  trovare  (discover) 
un Web Service che  soddisfa  le nostre esigenze. Tale operazione viene 
effettuata contattando un discovery service (che risulta anch’esso un Web 
Service) 
2. Il  discovery  service  risponderà  direttamente  al  client,  inviandogli  le 
informazioni relative a quali server forniscono il servizio richiesto. 
Capitolo 1 – Griglie e Web Service 
9
3. A questo punto il client conosce la locazioni del Web Service, ma ancora 
non sa assolutamente nulla su come tale servizio debba essere invocato. 
Perciò viene  inoltrata al Web Service una  richiesta di descrizione di sé 
stesso. 
4. Il Web Service riceve  la richiesta e  invia al client un documento WSDL 
contenente le informazioni relative a sé stesso e ai suoi metodi. 
5. Il  client  a  questo  punto  sa  dove  si  trova  il Web  Service  e  sa  come 
invocarlo.  L’invocazione  in  sé  viene  eseguita  in  un  linguaggio  detto 
SOAP; perciò il client dovrà inviare una SOAP request 
6. Il Web Service automaticamente risponderà con una SOAP response che 
include  le  informazioni  richieste  dal  client,  oppure  un  messaggio  di 
errore se la SOAP request era scorretta. 
 
Fig 4: passi tipici nell’interazione con un Web Service 
Capitolo 1 – Griglie e Web Service 
10
1.4 Architettura dei Web Service 
L’architettura dei Web Service è formata sostanzialmente da quattro livelli: 
il  livello  dei  processi,  il  livello  descrizione,  il  livello  invocazione  e  il  livello 
trasporto, così come mostrato dalla figura seguente: 
Fig. 5:  Architettura dei Web Services 
 
• Service Process. Questa parte dell’architettura  coinvolge  generalmente 
più Web  Services. Ad  esempio,  il  discovery  appartiene  a  questa  parte 
dell’architettura,  in  quanto  esso  permette  di  localizzare  un  particolare 
servizio all’interno di un insieme di Web Services 
• Service Description. Una delle più  interessanti  caratteristiche dei Web 
Services è che essi sono self‐describing. Questo vuol dire che una volta che 
il Web Service è stato  localizzato, è possibile chiedergli di descrivere sé 
stesso  ed  indicare  quindi  quali  operazioni  supporta  e  come  invocare 
l’esecuzione  di  tali  operazioni.  Questo  compito  è  svolto  mediante 
l’utilizzo del Web Service Description Language ‐ WSDL. 
• Service  Invocation.  L’invocazione  di  un Web  Service  coinvolge  uno 
scambio di messaggi tra il client e il server. SOAP – Simple Object Access 
Capitolo 1 – Griglie e Web Service 
11