Determinazione mediante Reti Neurali del profilo dell’Utente di una computing grid

INTRODUZIONE 
 7
requisiti dell’utente. 
La realizzazione di applicazioni grid-enabled è un compito impegnativo; gli 
studi riportati in letteratura[5,6] evidenziano come la comunità scientifica stia cercando 
di rendere più semplice l’interazione utente-griglia. 
D’altro canto altre ricerche denotano l’esistenza di un’insieme di utenti che 
posseggono le conoscenze necessarie per la corretta selezione delle risorse. Gli studi 
riportati in [7,8] evidenziano come la scelta delle risorse da utilizzare dipende 
fortemente dal tipo di job da schedulare. 
Da questi due aspetti nasce l’idea di valutare la possibilità di sviluppare un 
sistema software che, acquisendo la conoscenza “disseminata” dagli utenti che 
possiamo dunque definire esperti, fornisca un supporto al generico utente di griglia 
durante tutto il processo di selezione delle risorse. 
Acquisire la conoscenza degli utenti esperti significa apprendere le regole e i 
criteri che essi adottano durante la selezione delle risorse o, in altri termini, significa 
realizzare un modello comportamentale dell’utente di griglia. I processi decisionali 
utilizzati dall’utente sono, in generale, difficili da modellare e descrivere in quanto essi 
sono spesso basati su un’insieme di regole empiriche o comunque difficilmente 
formalizzabili. 
La prima fase dell’analisi del software consiste dunque nel verificare se è 
possibile realizzare tale modello. 
Il primo obiettivo di questa tesi è quello di studiare un meccanismo 
intelligente, basato sull’utilizzo di una rete neurale artificiale, il cui compito è appunto 
quello di catturare la conoscenza posseduta dall’utente esperto di griglia. In pratica tale 
meccanismo deve essere implementato da un sottosistema. 
 Il secondo obiettivo della presente tesi è dunque quello di proporre una 
architettura preliminare di tale sottosistema, che d’ora in poi verrà identificato come 
NeuralSlSr. 
Lo studio è stato condotto mediante l’uso di un simulatore realizzato ad hoc 
battezzato “NeuralSlSrSimulator”. Lo scopo di tale software è quello di  simulare sia il 
comportamento dell’utente di griglia, sia lo stato della griglia al momento 
dell’interazione fra essi, al fine di memorizzare un insieme di esempi dai quali estrarre il 
modello dell’utente. Tale modello, come già detto, deve essere realizzato dal sistema 
NeuralSlSr, per cui NeuralSlSrSimulator deve simulare anche il comportamento di 
NeuralSlSr allo scopo di valutarne le prestazioni. 
INTRODUZIONE 
 8
La tesi è organizzata in questo modo: nel capitolo 1 è fornita una analisi delle 
problematiche e delle soluzioni ad esse, rispettivamente nei sistemi a griglia in generale 
e nel progetto EU-DataGrid. Nel capitolo 2 viene descritta in maniere più approfondita 
l’interazione utente-griglia al fine di evidenziarne i punti deboli e le cause di 
inefficienza; viene altresì presentata la soluzione al problema individuato. Il capitolo 3 
giustifica i presupposti che sono alla base della soluzione descritta nel capitolo 2 ed 
inoltre fissa le caratteristiche del modello dell’utente e della griglia che verranno 
utilizzati per le simulazioni. Il capitolo 4 riporta la descrizione dell’architettura del 
sistema software che implementa la soluzione individuata. Il capitolo 5 contiene i valori 
sperimentali ottenuti mediante simulazioni. Infine il capitolo 6 riporta l’analisi e il 
progetto del software utilizzato per eseguire le misure prima citate. 
 
 
CAP.1:IL PROGETTO EU-DATAGRID 
 9
CAPITOLO 1 
 IL PROGETTO EU-DATAGRID 
 
In questo capitolo si cerca di fornire le caratteristiche e l’architettura di EU-
DataGrid, progetto di una griglia geograficamente estesa su tutta l’Europa, facilmente 
estendibile all’intero pianeta. Come già il nome suggerisce, EU-DataGrid è 
classificabile come griglia di dati: è, dunque, orientata essenzialmente verso 
applicazioni high-throughput di tipo parameter-sweep, tipiche di comunità scientifiche 
che necessitano l’analisi di enormi moli di dati, distribuiti nei vari centri di ricerca 
(sarebbe impossibile concentrarli in un unico punto), condividendo sia le applicazioni, 
sia i dati di analisi, sia i risultati dell’analisi.  
Sebbene EU-DataGrid è una griglia di dati l’obiettivo finale è quello di 
costruire un sistema adatto ad ogni tipo di applicazione, da quella scientifica di tipo 
parameter-sweep a quella multimediale come una videoconferenza, che richiede 
requisiti di QoS non strettamente necessari alle applicazioni high-throughput. Prima 
della descrizione del progetto EU-DataGrid si da un rapida definizione di griglia e 
sull’architettura generica di tale sistema di calcolo. 
1.1 Definizione di Griglia 
Una Griglia è un sistema distribuito di network computing su larghissima scala 
[10]. Il concetto di Griglia nacque come progetto di collegamento di siti con 
supercomputer. le applicazioni che possono usufruire dei servizi offerti da una 
infrastruttura a griglia sono molteplici, tra queste ricordiamo collaborative engineering, 
data exploration, high throughput computing, e naturalmente distributed 
supercomputing. Costruire una Griglia richiede lo sviluppo e l’installazione di un certo 
numero di servizi, quali il resource discovery (servizio di individuazione e selezione 
delle risorse partecipanti all’allestimento della Griglia), il resource management 
(servizio di gestione dei job, delle applicazioni utente e delle risorse). Di conseguenza la 
Griglia  è da intendersi anche come una infrastruttura che può collegare e unificare tra 
loro risorse estremamente eterogenee distribuite su tutto il globo terrestre.  
L’obiettivi che una Griglia deve raggiungere sono raggruppabili in cinque 
punti[4][11]: 
    L’eterogeneità: una griglia coinvolge risorse eterogenee per natura sparse su vari 
CAP.1:IL PROGETTO EU-DATAGRID 
 10
domini amministrativi distribuiti su distanze geografiche. 
    La scalabilità: una griglia può includere da poche a milioni di risorse, per questo le 
applicazioni grid-enabled devono essere tolleranti alla latenza dovuta ai 
collegamenti su distanza geografica. 
    La dinamicità o adattabilità: in una griglia il guasto di una risorsa è una regola, non 
un’eccezione. Dunque sia i servizi offerti dalla griglia, sia le applicazioni orientate 
alla griglia devono avere un comportamento dinamico per ottenere la massima 
prestazione dalle risorse attualmente disponibili.  
    L’estensibilità: questa proprietà viene garantita nel momento in cui si adotta una 
progettazione modulare; i moduli sono progettati in maniera indipendente l’uno 
dall’altro e comunicano mediante precisi e ben documentati protocolli. Questo 
modus operandi crea due vantaggi: 1) diventa facile sostituire o aggiornare un 
modulo senza dover reinstallare l’intera architettura; 2) si rende la griglia altamente 
adattabile alle esigenze degli utenti e al loro carico di lavoro. 
    L’autonomia del sito: la condivisione di risorse all’interno di una VO non deve 
andare a intaccare la loro normale amministrazione e quindi autonomia. 
Le cinque caratteristiche di una griglia su elencate possono essere 
implementate seguendo i seguenti passi:  
1. L’integrazione dei componenti individuali hardware e software in una risorsa di 
rete: questo comporta: 1) la definizione di un linguaggio di descrizione della risorsa, 
che possa astrarla dal livello fisico e renderla catalogabile e pubblicabile all’interno 
dell’information service;  2) l’implementazione di gestori della risorsa.  
2. L’implementazione di un middleware (software basato su infrastrutture già esistenti) 
che provvede ad una visione trasparente delle risorse disponibili. 
Nella figura 1.1 si possono osservare i componenti principali della griglia, 
secondo una architettura a strati, di cui si dà ora la descrizione: 
    Livello Fabric: esso raggruppa tutte le risorse hardware e software messe a 
disposizione della infrastruttura di griglia. Si osservi che non tutte le risorse fisiche 
di un sito possono apparire in questo livello: tali risorse risultano essere inesistenti e 
inaccessibili per la griglia. 
CAP.1:IL PROGETTO EU-DATAGRID 
 11
 
 
    Livello Middleware: è il cuore della griglia, raggruppa l’insieme dei protocolli, dei 
servizi di base e delle interfacce tra griglia e risorse del livello fabric. Il livello 
Middleware mostra come l’intera infrastruttura di griglia si poggia su architetture 
già esistenti: non tenta di sostituirsi ai gestori locali delle risorse ma si integra con 
essi, creando così un utente virtuale che si affianca agli utenti fisici sul campo. 
    Livello Tools:  a questo strato la Griglia offre servizi di alto livello, quali il servizio 
di informazione (tiene traccia di tutti gli utenti e le risorse attualmente presenti e 
operanti sulla griglia); il servizio di logging, indispensabile sia a livello utente (per 
mantenere traccia della propria attività sulla griglia), che a livello amministrativo 
(per effettuare analisi statistiche di workload ); il servizio di catalogo e management 
delle repliche di file, fondamentale nelle DataGrid; i vari servizi di brokering delle 
risorse, ad esempio lo schedulatore dei job. Oltre a ciò, a questo livello si collocano 
tutte le librerie grid-enabled, cioè librerie di programmazione che aiutano l’utente a 
interfacciare la propria applicazione con la griglia. 
    Livello Applications: a questo livello si pongono tutte le applicazioni 
ingegneristiche e scientifiche che hanno bisogno della griglia per ottenere risultati, 
come le applicazioni high-throughput; tali applicazioni possono avere un forte grado 
di parallelismo, oppure agiscono su un’incredibile mole di dati (data-intensive), 
superiori a quelle di qualsiasi singola unità di memorizzazione. 
 
APPLICAZIONI 
Scientifiche 
 
Web Applications Ingegneristiche ... 
Applications 
AMBIENTI DI SVILUPPO E STRUMENTI 
Linguaggi 
 
Web Tools Librerie Monitoring Scheduler ... 
Tools 
SERVIZI DI ACCOPPIAMENTO DELLE RISORSE DISTRIBUITE 
Comunicazioni 
 
Sicurezza Informazioni Accesso ai dati QoS … 
Middleware 
LOCAL RESOURCE MANAGERS 
Operating System Queuing 
System 
Librerie e Kernel delle 
applicazioni 
TCP/IP & 
UDP 
… 
RISORSE DISTRIBUITE INTERNE ALLE ORGANIZZAZIONI 
Computer Cluster Storage 
Systems 
Data Sources Strumenti 
Scientifici 
… 
Fabric 
Figura 1.1: Componenti di una Griglia 
CAP.1:IL PROGETTO EU-DATAGRID 
 12
Nella progettazione di una griglia è necessario seguire una serie di principi di 
base, al fine di facilitare la coesione di risorse eterogenee ed autonome [4]: 
    La griglia non deve interferire con l’amministrazione e l’autonomia del sito; 
    Non deve compromettere la sicurezza degli utenti e dei siti; 
    Non deve sostituirsi ai sistemi operativi e ai protocolli di rete già presenti; 
    Deve permettere sempre ad un sito di connettersi o sconnettersi dalla rete quando 
vuole; 
    Deve provvedere ad una infrastruttura affidabile e fault tolerant con nessun punto 
debole; 
    Deve utilizzare gli standard già presenti; 
    Deve fornire agli sviluppatori di software librerie grid-enabled. 
1.2 Architettura di Griglia 
Nella definizione di un’architettura di griglia occorre porre attenzione al 
problema centrale dell’interoperabilità tra tutti i partecipanti alla Griglia. In un 
ambiente di rete, l’interoperabilità si ottiene utilizzando protocolli comuni. Dunque, 
l’architettura di Griglia è prima e principalmente un’architettura di protocolli. Le linee 
guida specificate in [1] e seguite dal Global Grid Forum [9]  indicano che il progettista 
Grid deve porre maggiore attenzione nella progettazione dell’interazioni delle risorse: il 
motivo sta nel fatto che le VO sono estremamente mutevoli, donde la necessità che la 
condivisione sia supportata da protocolli leggeri e flessibili, che facciano forti astrazioni 
sulle caratteristica della risorsa. Protocolli con queste proprietà si prestano ad un 
efficiente resource discovery.  
L’architettura proposta in [1] e riportata graficamente della figura 2.1 può 
essere definita a strati: ciascuno strato raggruppa protocolli specifici di quel livello, i 
quali possono interagire con protocolli di livello inferiore, il viceversa non può 
accadere. Lo scopo ultimo è quello di arrivare a pochi protocolli che possano astrarre in 
maniera soddisfacente tutte le risorse attive sulla Griglia. 
1.2.1 Livello Fabric: Risorse delle Griglie Computazionali 
Il livello Fabric è composto dalle risorse della Griglia, caratterizzate da tre 
aspetti: i) estrema eterogeneità anche nella tipologia; ii) appartenenza ad 
amministrazioni differenti; iii) distribuzione su larga scala. Ogni Virtual Organization 
mette a disposizione degli altri le proprie risorse ma ne mantiene sia la proprietà che la 
CAP.1:IL PROGETTO EU-DATAGRID 
 13
piena libertà di gestione. 
 
 
Figura 2.1: Architettura di Protocolli per una Griglia Computazionale 
  
1.2.2 Livello Connectivity: Comunicazione fra le Risorse 
Nel livello Connectivity si trovano i protocolli di comunicazione che 
permettono alle componenti del livello Fabric di scambiarsi dati ed informazioni. Questi 
protocolli devono permettere il trasporto, l’instradamento e l’assegnazione di nomi ai 
diversi nodi. Naturalmente, dal momento che le griglie si basano su infrastrutture già 
esistenti e diffuse (è il concetto di middleware) sono  adoperati gli standard de facto 
affermatisi con Internet, cioè i protocolli IP, TCP, UDP e DNS. 
1.2.3 Livello Resource: Accesso alle Risorse  
Il livello Resource si preoccupa di rendere uniforme l’accesso a risorse 
eterogenee, ossia crea risorse logiche uniformi adoperando quelle del livello Fabric. I 
componenti di questo livello possono essere suddivisi in due categorie: 
    Sistemi informativi: forniscono informazioni sulla struttura e lo stato di una risorsa. 
    Sistemi di gestione: permettono l’accesso e l’utilizzo condiviso delle risorse. 
1.2.4 Livello Collective: Coordinazione delle Risorse 
Se il livello Resource permette l’accesso ad una risorsa, il livello Collective 
contiene i servizi che permettono l’utilizzo e la coordinazione di più risorse. I servizi di 
Resource 
Fabric 
Collective  
Applications
Connectivity
CAP.1:IL PROGETTO EU-DATAGRID 
 14
questo livello si distinguono in: 
    Servizi di indicizzazione: permettono di scoprire l’esistenza di risorse. 
    Servizi di co-allocazione, scheduling e brokering: permettono l’allocazione di una o 
più risorse pianificando l’esecuzione di job. 
    Servizi di replicazione dati: permettono la gestione dei dati realizzando meccanismi 
come la replicazione, che incrementano le prestazioni nell’accesso ai dati. 
    Servizi di individuazione del software: permettono la scelta della “miglior” 
implementazione software e della “miglior” piattaforma d’esecuzione. 
1.2.5 Livello Application: Applicazioni delle Griglie Computazionali 
Il livello Application è costituito dagli strumenti (linguaggi, librerie, 
compilatori) che permettono la realizzazione di applicazioni Grid e dalle stesse 
applicazioni. Le applicazioni che più si avvantaggiano dell’ambiente di griglia sono 
quelle che sfruttano: 
    Supercalcolo distribuito: è necessario tutte le volte che la complessità 
dell’applicazione rende improponibile la sua esecuzione su un unico elaboratore.  
    Elaborazione high-throughput: con l’elaborazione high-throghput si cerca di 
pianificare l’esecuzione di un gran numero di job debolmente correlati. 
    Elaborazione on-demand: l’elaborazione on-demand viene adoperata ogniqualvolta 
c’è la necessità di una gran potenza computazionale per un breve periodo di tempo. 
    Elaborazione data-intensive: le applicazioni data-intensive sintetizzano nuove 
informazioni partendo dai dati conservati in database distribuiti geograficamente.  
Nella figura 3.1 si osserva un riassunto grafico dell’architettura appena 
esaminata. 
 
APPLICATION 
supercalcolo distribuito, high-throughput, on-demand, data-
intensive,linguaggi, librerie, compilatori 
COLLECTIVE 
resource discovery, co-allocazione, scheduling, brokering, 
replicazione dei dati, individuazione del software 
RESOURCE monitoraggio e gestione delle risorse 
 
CONNECTIVITY 
protocolli di comunicazione,meccanismi di autenticazione 
FABRIC 
 
sistemi operativi, sistemi operativi di rete,protocolli di 
comunicazione,database, supercomputer,workstation, pc,reti, 
microscopi, radiotelescopi, satelliti, sensori 
Figura 3.1: Architettura di Griglia 
CAP.1:IL PROGETTO EU-DATAGRID 
 15
1. 3 Il Progetto EU-DataGrid. 
1.3.1 DataGrid, generalità 
In questo paragrafo sono esposte le caratteristiche e l’architettura di EU-
DataGrid, progetto di una griglia geograficamente estesa su tutta l’Europa, facilmente 
estendibile all’intero pianeta. Come già il nome suggerisce, EU-DataGrid è 
classificabile come griglia di dati secondo la tassonomia proposta in [14]: è, dunque, 
orientata essenzialmente verso applicazioni high-throughput di tipo parameter-sweep, 
tipiche di comunità scientifiche che necessitano l’analisi di enormi moli di dati, 
distribuiti nei vari centri di ricerca, condividendo sia le applicazioni, sia i dati di analisi, 
sia i risultati dell’analisi. I più interessati all’uso della griglia europea sono i fisici della 
HEP (High Energy Physic, fisica delle alte energie). L’obiettivo finale rimane 
comunque quello di costruire un sistema adatto ad ogni tipo di applicazione. 
1.3.1.1 Motivazioni e finalità del progetto  EU-DataGrid 
Il CERN (Organizzazione Europea per la Ricerca Nucleare), con sede a 
Ginevra, è il più grande istituto che si occupa dello studio della fisica delle particelle, 
fornendo da anni fondamentali risultati e scoperte in questo ambito, attraverso il 
progetto, la realizzazione e la gestione di grandi acceleratori.  
Tra i tanti esperimenti finora effettuati, il più importante è stato LEP, per il 
quale si è costruito il più grande acceleratore di particelle del mondo, di 27 km di 
circonferenza. La massima energia di collisione tra particelle raggiunta è stata di 209 
GeV. Nonostante i notevoli risultati conseguiti, LEP ha lasciato, e creato, molte 
questioni in sospeso. Nasce dunque la necessità di passare ad un livello superiore: 
l’esperimento LHC mira dunque a superare la soglia di massima energia conseguita 
durante LEP e studiare la cosiddetta fisica delle alte energie (HEP).  
Sono in programma 4 diversi esperimenti, i cui nomi sono ALICE, ATLAS, 
CMS e LHCb  [16]. In complessivo si stima che al CERN verranno raccolti circa 3,5 PB 
di dati all’anno, sotto forma di oggetti RAW (Real Raw Data, sono l’output dei 
rilevatori) e SIM (Simulated Raw Data, frutto della simulazione del fenomeno fisico). 
Successivamente questi dati verranno selezionati e quindi analizzati. Durante 
questo processo, i dati, finora raccolti tramite hardware dedicato connesso al rilevatore, 
quindi necessariamente locati al CERN, vengono filtrati e analizzati: prima vengono 
“trasformati” in oggetti ESD (Event Summary Data, dopo ricostruzione), quindi in 
CAP.1:IL PROGETTO EU-DATAGRID 
 16
oggetti AOD (Analysis Object Data, dopo analisi) e infine in oggetti DPD (Derived 
Physics Data, dopo analisi individuale). Schematicamente il processo di analisi consiste 
in: 
RAW/SIM Î ESD Î AOD Î DPD 
Si possono agevolmente elencare motivazioni per cui risulta necessaria una 
architettura DataGrid: 
    La mole di dati da analizzare è così grande che da sole non bastano tutte le risorse 
attualmente presenti o aggiunte in futuro al CERN, considerando che queste saranno 
impegnate nel controllo dell’acceleratore e nella produzione degli oggetti RAW. 
    Il formato dei dati è quello di file di pochi MB, solitamente di sola lettura, che, 
quindi, si prestano facilmente al processo di replicazione, in quanto non comportano 
problemi di consistenza. 
    L’analisi di ciascun evento è fatta in maniera assolutamente incorrelata: nessun 
evento può essere scartato a priori e tutti gli eventi sono indipendenti. 
I passi computazionali per un esperimento LHC, il cui fine è quello di 
pubblicare i risultati dei fisici, sono molto simili a quelli degli attuali esperimenti e 
comporteranno intense computazioni su grandi flussi di dati .I dati prodotti all’uscita dei 
rilevatori sono bufferizzati sul disco e spostati permanentemente su nastro magnetico 
alla frequenza di circa 100 MB/s. In tutto vengono raccolti approssimativamente 1 PB 
all’anno per ogni esperimento, 3,5 PB/anno considerando tutti e quattro gli esperimenti. 
A questi dati vanno sommati quelli prodotti dalla simulazione degli eventi. La 
simulazione richiede una potenza computazionale elevata (basta pensare che la 
simulazione di un evento LEP, meno complesso di un evento LHC, richiede un carico 
computazionale di circa 60 SI95*sec[17]). 
La fase di ricostruzione è il processo per cui dati di tipo RAW (letteralmente 
allo stato grezzo) sono trasformati in eventi fisici. Il risultato di questo processo, gli 
oggetti ESD, occupa circa il 10% del volume dei dati originali. Gli eventi vanno letti da 
nastro, processati, quindi salvati su disco e rimessi su nastro (in grado di memorizzare 
molto più di un disco, con minore costo a scapito però della velocità di accesso): questa 
fase richiede molta potenza di calcolo e di I/O. 
Il terzo passo degli esperimenti LHC consiste nell’analisi batch e interattiva degli 
oggetti ESD da parte delle migliaia di fisici, che hanno accesso ai dati ricostruiti. Questa 
fase richiede una potenza di calcolo stimata attorno ai 350 KSI95 per ciascun 
esperimento: nessun centro di calcolo possiede questa potenza, e probabilmente non 
CAP.1:IL PROGETTO EU-DATAGRID 
 17
sarà mai possibile, in termini economici, concentrare tutte queste risorse in un unico 
luogo. 
 
1.3.1.2 Architettura di DataGrid 
Alla luce di quanto detto, è chiaro che il modello di analisi distribuito 
implementato tramite una DataGrid può competere col modello di analisi centralizzato, 
che vuole tutte le risorse concentrate al CERN: diventa addirittura superiore se l’uso 
delle risorse di griglia è affidabile e viene data la possibilità al fisico di accedere a tutti i 
dati dell’esperimento LHC a cui partecipa indipendentemente dal luogo in cui egli si 
trova o in cui risiedono i dati da lui richiesti. 
L’elemento chiave di questo modello distribuito per l’analisi LHC è 
un’organizzazione delle risorse secondo un modello gerarchico multi-tier. Secondo 
questo modello, per ogni esperimento, la produzione di dati RAW e una parte della 
ricostruzione viene effettuata al Tier0, cioè al CERN. L’analisi e parte della 
ricostruzione, assieme all’immagazzinamento degli altri tipi di oggetti sono compiti dei 
centri regionali (Tier1) di livello nazionale o internazionale, dei centri regionali 
(laboratori e università, Tier2), dei dipartimenti (Tier3) e infine dei singoli desktops dei 
fisici (Tier4) (Figura 4.1).   
Secondo questo modello, i dati sono tutti inizialmente prodotti al Tier0, il 
CERN: esso mantiene nei suoi archivi (principalmente su nastro) gli oggetti RAW 
prodotti dai rilevatori e gli oggetti ESD derivanti dalla prima parziale ricostruzione. La 
caratteristica di questi oggetti è quella di essere a sola lettura: si prestano bene quindi al 
processo di replicazione in quanto non sussiste il problema della consistenza tra copia 
originale (master) e le sue repliche (anch’esse a sola lettura). In seguito, nella fase di 
analisi batch e interattiva, migliaia di fisici accedono al database del Tier0 per richiedere 
i dati da analizzare: questi dati deve essere replicati dalla loro posizione originaria al 
luogo dove avverrà la computazione. 
CAP.1:IL PROGETTO EU-DATAGRID 
 18
 
 
Figura 4.1: Modello multi-tier di DataGrid 
 
Nelle intenzioni del progetto EU-DataGrid, il fisico deve avere l’impressione 
di operare come se stesse agendo in locale, anziché attraverso un sistema distribuito. 
Egli sottomette la propria attività specificando quali sono i file o gli oggetti di input, i 
nomi dei file di output e dove devono essere pubblicati, e attende. La Griglia, invece, 
compie per lui una serie di passi [15]: 
    Cerca un posto opportuno dove poter effettuare la computazione. 
    Organizza efficientemente l’accesso ai dati, essenzialmente effettuando una fase di 
staging nella quale i dati vengono copiati dal sito remoto sulla cache del nodo dove 
deve essere lanciato il job. Questa operazione può essere sostituita, se conviene, 
dalla replica dei file di ingresso dall’host originario a un data server (Storage 
Element, SE) più vicino al nodo di calcolo (Computing Element, CE) in termini di 
throughput del collegamento: in questo modo un’applicazione (ma solo se grid-
enabled) può accedere ai dati remotamente senza perdere niente in prestazioni. 
    Gestisce le autenticazioni e le autorizzazioni sui vari siti che saranno usati. 
    Gestisce l’allocazione delle risorse richieste interagendo con i gestori locali. 
    Esegue il job. 
    Monitorizza l’esecuzione del job. L’utente può sempre conoscere lo stato della 
propria applicazione e la sua evoluzione temporale.