JJPF: uno strumento per calcolo parallelo con JINI

16 CAPITOLO 1. INTRODUZIONE
• gestire le 
omuni
azioni;
• eseguire le operazioni di staging e di spawning;
• bilan
iare dinami
amente il 
ari
o;
• garantire un adeguato grado di fault toleran
e.
Quindi lo sviluppatore 
he usa JJPF può 
on
entrare la sua attenzione sul
problema da risolvere e sulla sua de
omposizione, senza doversi preo

upare
espli
itamente dei diversi aspetti legati al 
ontrollo della 
on
orrenza.
JJPF dà la possibilità di realizzare sempli
emente un'appli
azione parallela
se
ondo un paradigma di tipo farm o se
ondo una sua variante 
he 
onsenta la

ondivisione di dati fra i worker.
L'astrazione 
he Jini ore è quella di una federazione di un insieme di

lienti e servizi 
omuni
anti tra di loro.
Il framework realizzato, per sfruttare le possibilità oerte da Jini, fornis
e
una visione astratta di ogni risorsa 
omputazionale mostrandola ai 
lienti 
ome
un Servizio. Gli utilizzatori di questi servizi sono detti Clienti.
An
hè un 
al
olatore possa essere arruolato 
ome worker in una 
om-
putazione parallela realizzata utilizzando JJPF, è su
iente eseguire al
uni
sempli
i passi:
1. istanziare un oggetto 
he realizzi il Servizio
2. istanziare un oggetto 
he si o

upi di registrare il Servizio presso un
LookupServi
e (l'entità 
he tiene tra

ia dei Servizi attivi).
La realizzazione di un 
liente è leggermente più 
omplessa, per realizzarne uno
è ne
essario:
1. S
rivere una 
lasse 
he implementi i metodi di
hiarati nell'interfa

ia
Pro
essoIf:
• setData e getData per il trasferimento dei dati tra 
liente e servizio;
• run per mandare in ese
uzione il programma 
he il 
liente ha trasfer-
ito sul servizio;
• setSharedObje
t per indi
are al worker l'identi
atore dell'entità

ondivisa da utilizzare;
2. Istanziare un oggetto di tipo Basi
Client passando 
ome parametri al

ostruttore:
17
• una 
olle
tion Java 
ontenente l'insieme dei dati in input;
• una 
olle
tion java dove JJPF memorizzerà i risultati;
• il vettore delle 
lassi 
he saranno usate dal worker;
• (solo nel 
aso del farm 
on stato) una 
lasse 
he implementi l'in-
terfa

ia SharedObje
tIf: l'entità 
ondivisa 
he i worker dovranno
utilizzare;
Il framework sviluppato dimostra 
he la te
nologia Jini 
ostituis
e un valido
strumento per la realizzazione delle forme di parallelismo fornite da JJPF.
JJPF garantis
e, infatti, ottimi valori di s
alabilità [FB87℄ (Ÿ 3.1.1 a pagi-
na 35), adabilità (Ÿ 3.1.2 a pagina 35) e dinami
ità (Ÿ 3.1.3 a pagina 36).
Le prove sono state realizzate presso il 
entro di 
al
olo del Dipartimento
di Informati
a dell'Università di Pisa e saranno des
ritte dettagliatamente nel
paragrafo 4.2.4 a pagina 62. I test hanno dimostrato 
he il JJPF garantis
e
buoni livelli di s
alabilità no all'impiego di 
inquanta
inque 
al
olatori.
Il framework realizzato è stato progettato per gestire 
orrettamente l'im-
provvisa s
omparsa delle risorse di 
al
olo e permettere il re
upero dei dati
spediti ai 
al
olatori non più attivi. Le prove eettuate hanno dimostrato

he JJPF ries
e a garantire, an
he durante eventi 
riti
i un ottimo grado di
adabilità.
Inoltre i test hanno evidenziato 
he il framework sviluppato possiede un'ot-
tima 
apa
ità di reazione all'aggiunta e alla rimozione di risorse 
omputazionali.
Nelle prove in 
ui, a 
omputazione iniziata, è stato raddoppiato il numero di
ma

hine a disposizione, JJPF ha reagito di 
onseguenza, fornendo (dopo un
breve transitorio) prestazioni adeguate al nuovo numero di ma

hine.
Abbiamo organizzato la tesi in modo da analizzare in maniera organi
a tut-
ti gli aspetti n qua a

ennati. Abbiamo quindi de
iso di strutturarla nella
maniera seguente:
• nel 
apitolo 2 des
riviamo brevemente gli strumenti utilizzati, illustrando
le motivazioni 
he 
i hanno portato al loro uso;
• nel 
apitolo 3 vediamo il progetto logi
o del JJPF, ne des
riviamo gli
obiettivi, gli attori e i possibili s
enari d'uso; illustriamo inoltre i problemi

he abbiamo arontato durante la sua realizzazione;
• nel 
apitolo 4 mostriamo i dettagli implementativi del framework svilup-
pato, analizzando dettagliatamente ogni singolo pa
kage in 
ui è suddiviso;
18 CAPITOLO 1. INTRODUZIONE
• nel 
apitolo 5 analizziamo i test eettuati des
rivendo l'ambiente di prova
e gli strumenti utilizzati, valutandone i risultati;
• nel 
apitolo 6 traiamo inne le nostre 
on
lusioni sul lavoro svolto.
Inoltre sono presenti tre appendi
i:
• nell'Appendi
e A sono 
ontenute le informazioni inerenti l'installazione,
la 
ongurazione e l'uso del framework JJPF;
• nell'Appendi
e B mostriamo i diagrammi UML, sia se
ondo la vista ar-

hitetturale 
he quella di dettaglio.
• nell'Appendi
e C riportiamo il 
odi
e sorgente del JJPF;
Capitolo 2
Strumenti Utilizzati
Nell'introduzione abbiamo illustrato lo s
opo della nostra tesi: valutare quanto
Jini si presti ad essere utilizzato 
ome middleware di supporto per la realizza-
zione di un ambiente per il 
al
olo parallelo. In questo 
apitolo vedremo 
os'è
Jini, ne des
riveremo gli attori prin
ipali e il funzionamento di base.
2.1 Jini: Network Plug&Play
Jini è un sistema distribuito, s
ritto in Java, nalizzato alla 
ostruzione di reti
mutevoli e dinami
he, formate da 
omponenti, dispositivi e servizi eterogenei
[JNJ03, JFA04, BP01, UL00, S
i97, Jin℄.
Il suo obiettivo è la minimizzazione dei 
ompiti di amministrazione, 
on-
gurazione e gestione dei dispositivi 
onnessi. Jini 
onsente l'utilizzo di risorse
eterogenee in modo uniforme, astraendo la loro natura si
a 
ome oggetti.
Uno dei punti di forza di Jini è quello di 
onsentire la 
ongurazione e re-
gistrazione di una risorsa in modo automati
o [WJT99, JRW03, JBE, JK01,
CSGG01℄. Ogni dispositivo o servizio 
he viene 
onnesso alla rete e di
hiara la
sua presenza può essere trovato e utilizzato dai 
lienti.
L'uso di Jini è parti
olarmente interessante nelle reti 
aratterizzate da un
alto grado di dinami
ità [Cre04℄, in 
ui è frequente l'aggiunta o la rimozione
di elementi (stampanti, 
al
olatori, memorie di massa,...). Analizziamo al
uni
s
enari tipi
i al ne di rendere più 
hiaro questo 
on
etto:
• Una nuova stampante viene 
onnessa alla rete, annun
ia la sua presenza
e funzionalità: da questo momento qualsiasi 
liente può utilizzarla senza
dover essere appositamente ri
ongurato;
• Una ma

hina fotogra
a digitale può essere 
onnessa alla rete e fornire
19
20 CAPITOLO 2. STRUMENTI UTILIZZATI
un'interfa

ia 
he 
onsenta di eettuare foto e di spedirle ad una stam-
pante di rete;
• Una stampante 
he nis
a l'in
hiostro a 
olori può rendere nota in maniera
automati
a la sua transizione di stato da stampante-a-
olori a
stampante-in-bian
o-e-nero;
• Una stampante 
he nis
a la 
arta può 
ambiare il suo stato in offline;
Un sistema basato su Jini, detto an
he federazione, è un insieme di 
lien-
ti e servizi 
omuni
anti tra di loro tramite i proto
olli 
ompatibili 
ol frame-
work: nella maggior parte dei 
asi questo signi
a appli
azioni Java 
omuni
anti
tramite RMI.
2.2 Remote Method Invo
ation (RMI)
RMI è un me

anismo 
he 
onsente l'invo
azione di metodi su oggetti remoti,
mas
herando la te
nologia rete sottostante[WW04, SRW04, E
k03, JBM+℄.
Dato un oggetto X, in ese
uzione su una ma

hina A, 
he metta a dispo-
sizione al
uni dei suoi metodi e data una appli
azione Y, in ese
uzione su una
ma

hina B, grazie a RMI Y può utilizzare i metodi pubbli
ati da X 
ome se
entrambi gli oggetti si trovassero sulla stessa ma

hina (vedi Figura 2.1 a fronte
in alto).
RMI utilizza la serializzazione Java [PB02℄, una te
nologia 
he permette di
trasformare un oggetto in un insieme di byte pronti per essere trasferiti da una
JVM ad un'altra. L'entità 
he si o

upa della gestione delle 
omuni
azioni tra
X ed Y è 
hiamata proxy (letteralmente pro
ura).
La parte bassa della Figura 2.1 nella pagina su

essiva mostra un esempio
del funzionamento di RMI in 
ui un oggetto Y invo
a il metodo m1 esposto
dall'oggetto remoto X. Il suo 
omportamento può essere riassunto nelle sei fasi
seguenti:
1. l'oggetto Y in ese
uzione sulla ma

hina B invo
a il metodo m1 sul proxy
stub dell'oggetto X;
2. il proxy stub, 
he si trova su B, redirige al proxy skel sito sulla ma

hina
A la 
hiamata al metodo m1;
3. il proxy skel invo
a il metodo m1 sull'oggetto X;
4. X esegue il metodo e restituis
e il risultato al proxy skel;
5. il proxy skel spedis
e i risultati al proxy stub;
2.2. REMOTE METHOD INVOCATION (RMI) 21
Oggetto X Oggetto Y
Macchina A Macchina B
invocazione remota
risultato dell’invocazione 
            remota
Schema Logico del Funzionamento
dell’invocazione remota di metodi
Oggetto X Oggetto Y
Macchina A Macchina B
invocazione remota
risultato dell’invocazione 
            remota
Schema Logico del Funzionamento di Java RMI
Proxy Skel Proxy Stub
X.m1(); risultatorisultatoX.m1();
Figura 2.1: Invo
azione remota dei metodi
22 CAPITOLO 2. STRUMENTI UTILIZZATI
6. il proxy stub si o

upa di inoltrare i risultati ri
evuti ad Y;
La prima implementazione di RMI utilizzava 
ome proto
ollo di trasporto il
Java Remote Method Proto
ol (JRMP), basato su TCP.
In seguito sono nate diverse implementazioni di RMI 
he hanno 
onsenti-
to l'utilizzo di altri proto
olli, 
ome ad esempio HTTP [TBL96, RF99℄, IIOP
[RMI04a℄ (il proto
ollo di trasporto di CORBA [COR04℄), SSL [RMI04b℄ e
Firewire (IEEE 1394 [IEE04℄). Un punto dolente è 
he ognuna di queste imple-
mentazioni espone un'interfa

ia di programmazione distinta e mette a dispo-
sizione un insieme di 
lassi realizzate ad-ho
. Quindi una appli
azione s
ritta
utilizzando un parti
olare proto
ollo diventa di fatto dipendente da esso.
Un altro grosso problema di RMI è la 
reazione dei proxy: per generarli
è ne
essario passare in input all'appli
azione rmi
, il le risultante dalla 
om-
pilazione della 
lasse di 
ui si vogliono esporre i metodi, questo vin
olo limita
molto la dinami
ità delle appli
azioni 
reate poi
hè non 
onsente la generazione
di proxy a run-time.
Per risolvere questo problema Sun Mi
rosystems ha sviluppato il Jini Exten-
sible Remote Invo
ation (JERI), per la 
ui trattazione rimandiamo al paragrafo
su

essivo.
2.2.1 Jini Extensible Remote Invo
ation (JERI)
JERI [Ven02, Som03℄ è un'evoluzione di RMI (Ÿ 2.2 a pagina 20) in quanto ne

onsente una totale personalizzazione.
I punti 
hiave di JERI sono la possibilità di generare i proxy a tempo di
ese
uzione, tramite il me

anismo di esportazione, e la possibilità di s
egliere
il proto
ollo del livello di trasporto da utilizzare senza dover ris
rivere o ri
om-
pilare il 
odi
e.
Esportazione RMI 
lassi
o prevede 
he un oggetto, per rendersi visibile dal-
l'esterno della JVM sulla quale è istanziato, debba registrarsi presso di essa
eseguendo un'operazione 
hiamata esportazione.
Da questo momento in poi la JVM 
onos
e i metodi esportati verso l'esterno
e sa quando sostituire un oggetto vero e proprio 
on il suo proxy.
Il modo più sempli
e per utilizzare RMI è di
hiarare una 
lasse 
he esten-
da Uni
astRemoteObje
t ed implementi l'interfa

ia Remote (frammento di

odi
e 1 nella pagina su

essiva). In questo 
aso, la maggior parte dei 
ompiti
legati all'esportazione sono svolti dal 
ostruttore della 
lasse
Uni
astRemoteObje
t; l'uni
a attività ri
hiesta all'utente è la denizione di un

ostruttore senza parametri. Durante l'operazione di esportazione il runtime
Java 
rea il proxy 
orrispondente alla 
lasse da esportare. An
hè il runtime
2.2. REMOTE METHOD INVOCATION (RMI) 23
Frammento di Codi
e 1 RMI tramite Uni
astRemoteObje
t
publi
 
lass EsmpioRmi extends Uni
astRemoteObje
t implements
Remote
{
publi
 stati
 void main(String[℄ args) throws Ex
eption
{
// questa istanziazione esporta il proxy nel java runtime
// e fa partire un thread per mantenerlo in ese
uzione
new EsempioRmi();
}
// Il 
ostruttore senza parametri è ne
essario al runtime
// per generare il proxy
publi
 EsempioRmi() throws java.rmi.RemoteEx
eption
{
}
}
possa istanziare l'oggetto proxy, è ne
essario 
he sia disponibile la 
lasse 
he ne
denis
e la struttura. Per generare questa 
lasse è ne
essario, dopo la normale

ompilazione della 
lasse, utilizzare l'RMI 
ompiler (rmi
).
Utilizzando il Jini Extensible Remote Invo
ation, non è più ne
essaria la
generazione delle 
lassi proxy a tempo di 
ompilazione, il Jeri runtime si o

upa
della loro 
reazione a tempo di ese
uzione.
Il frammento di 
odi
e 2 nella pagina seguente mostra l'esempio di una

lasse 
he esporta il proprio proxy utilizzando JERI. In questo 
aso l'operazione
di esportazione deve essere fatta espli
itamente: si istanzia un oggetto della

lasse Basi
JeriExporter sul quale invo
are il metodo export passandogli per
parametro l'oggetto da esportare.
Congurazione L'altro grosso vantaggio di JERI rispetto all'RMI tradizionale
è la possibliità di s
egliere a run-time il proto
ollo del livello di trasporto da
utilizzare. Solitamente il proto
ollo di trasporto utilizzato da un'appli
azione
dipende dalle 
lassi di 
omuni
azione utilizzate durante la 
odi
a, al 
ontrario,
JERI, tramite un sistema di indirezioni, ore la possibilità di 
ambiare il sis-
tema di trasporto senza 
he sia ne
essario mettere mano al 
odi
e. JERI legge
le informazioni ne
essarie da un le di 
ongurazione.
Il frammento di 
odi
e 3 nella pagina su

essiva mostra un possibile le di

ongurazione.
Come abbiamo pre
edentemente illustrato JERI 
onsente la 
reazione di

lassi proxy a runtime, senza 
he sia ne
essario ri
orrere all'RMI 
ompiler. Il
24 CAPITOLO 2. STRUMENTI UTILIZZATI
Frammento di Codi
e 2 RMI tramite Export
publi
 
lass EsempioExport implements Remote
{
publi
 stati
 void main(String[℄ args) throws Ex
eption
{
// 
reazione di un exporter JERI
Exporter exp =
newBasi
JeriExporter(T
pServerEndpoint.getInstan
e(0)
new Basi
ILFa
tory());
// esportazione di un oggetto di questa 
lasse
Remote proxy = exp.export(new EsempioExport());
}
}
Frammento di Codi
e 3 File di Congurazione dell'Exporter
import net.jini.jrmp.*;
import net.jini.iiop.*;
JrmpEsempioExport {
exporter = new JrmpExporter();
}
IiopEsempioExport {
exporter = new IiopExporter();
}
2.3. JINI: COMPONENTI 25
Frammento di Codi
e 4 File di Congurazione dell'Exporter Jeri
import net.jini.jeri.Basi
ILFa
tory;
import net.jini.jeri.Basi
JeriExporter;
import net.jini.jeri.t
p.T
pServerEndpoint;
JeriEsempioExport {
exporter = new Basi
JeriExporter(T
pServerEndpoint.getInstan
e(0),
new Basi
ILFa
tory());
}
frammento di 
odi
e 4 mostra un le di 
ongurazione 
he sfrutta la tale possibil-
ità: anzi
hè utilizzare l'exporter di uno spe
i
o proto
ollo utilizza l'esportatore
standard di JERI, il Basi
JeriExporter.
I passi da eseguire a programma per poter leggere ed utilizzare le infor-
mazioni 
ontenute nei le di 
ongurazione sono po
hi e sempli
i:
1. invo
are il metodo stati
o getInstan
e della 
lasse ConfigurationProvider
per leggere il le di 
ongurazione;
2. utilizzare le informazioni ottenute al punto pre
edente per 
reare un ex-
porter;
3. esportare l'oggetto utilizzando l'exporter 
reato al punto 2;
Il frammento di 
odi
e 5 nella pagina su

essiva mostra 
ome sono lette le
informazioni di 
ongurazione dal le rappresentato nel frammento di 
odi
e 4.
2.3 Jini: Componenti
All'interno di una federazione possiamo individuare tre tipi di attori:
26 CAPITOLO 2. STRUMENTI UTILIZZATI
Frammento di Codi
e 5 Programma 
he 
ari
a a runtime la 
ongurazione
Jeri
import java.rmi.*;
import net.jini.
onfig.*;
import net.jini.export.*;
publi
 
lass EsempioConfigurazioneExport implements Remote
{
// In questo esempio il nome del file di 
onfigurazione è
// s
ritto direttamente nel 
odi
e, in realtà è possibile
// utilizzare un altro livello di indirezione per indi
are
// il per
orso dove trovare il file di 
onfigurazione
private stati
 String CONFIG_FILE = "jeri/jeri.
onfig";
publi
 stati
 void main(String[℄ args) throws Ex
eption
{
String[℄ 
onfigArgs = new String[℄ {CONFIG_FILE};
// leggo la 
onfigurazione dal file "jeri/jeri.
onfig"
Configuration 
onfig =
ConfigurationProvider.getInstan
e(
onfigArgs);
// uso le informazioni lette per 
reare un exporter
Exporter exp =
(Exporter) 
onfig.getEntry("JeriEsempioExport",
"exporter",
Exporter.
lass);
// esporto un oggetto di tipo EsempioConfigurazioneExport
Remote proxy =
exp.export(new EsempioConfigurazioneExport());
// rimuovo l'esportazione quando ho finito
exp.unexport(true);
}
}
2.3. JINI: COMPONENTI 27
Figura 2.2: Struttura sempli
ata di Jini
1. I Servizi: una stampante, un diskarray, un 
omputer o più in generale
qualsiasi entità 
he fornis
a funzionalità;
2. I Clienti: gli utilizzatori dei servizi
3. Il Servizio di Lookup (in seguito LookupServi
e) : memorizza le fun-
zionalità dei servizi, e le 
omuni
a ai 
lienti; il suo ruolo è quello di
intermediario.
Codi
e e dati vengono trasferiti tra i tre attori tramite la rete di inter
onnessione
(generalmente TCP/IP), per spostare gli oggetti tra una Java Virtual Ma
hine
ed un'altra si utilizzano i me

anismi di serializzazione messi a disposizione da
Java.
28 CAPITOLO 2. STRUMENTI UTILIZZATI
Gli elementi trasferiti possono essere oggetti veri e propri oppure proxy (RMI
e non) 
he a loro volta eseguono invo
azioni di metodi remoti.
2.3.1 Il Lookup Servi
e
Il lookup servi
e[JNJ03, JOT99℄ è il gestore 
entralizzato dei servizi disponibili
all'interno della federazione, ne memorizza le 
aratteristi
he e li rende visibili
agli altri membri. Per ogni servizio registrato, il LookupServi
e, mantiene una
propria rappresentazione: il servi
e item.
Ogni servi
e item è 
omposto da tre oggetti:
• servi
eID: l'identi
atore del servizio (rappresentato su 128 bit);
• servi
e: un'istanza del servizio (molto spesso un proxy);
• attributeSets: un insieme di attributi 
he des
rivono le 
aratteristi
he
del servizio registrato.
Un 
liente 
he vuole 
er
are un 
erto servizio, fa una ri
hiesta al LookupServi
e,
indi
ando nel messaggio le funzionalità di 
ui ne
essita. Il LookupServi
e esam-
ina le informazioni 
ontenute nella ri
hiesta del 
liente e le 
onfronta 
on quelle
memorizzate, se trova dei servi
e item 
ompatibili, li spedis
e al 
liente.
2.3.2 I Servizi
Con il termine Servizio indi
hiamo un'entità 
he mette a disposizione dei 
lienti
un insieme di funzionalità. In Jini un servizio è rappresentato da un'interfa

ia
Java.
All'interno di una federazione è possibile trovare, per ogni servizio, più imple-
mentazioni distinte. An
hè ognuna di esse possa essere trovata ed utilizzata dai

lienti, è ne
essario eseguire preventivamente un operazione di "registrazione".
Tale operazione, portata a termine da un'entità 
hiamata "servi
e provider", si
o

upa di registrare un'implementazione di un servizio presso un LookupServi
e.
Il servi
e provider è l'entità 
he si o

upa di:
1. istanziare l'implementazione di un servizio;
2. registrare l'oggetto 
reato in un LookupServi
e;
3. restare attivo eseguendo al
uni 
ompiti di gestione;
Un servi
e provider, per poter registrare un servizio, deve prima di tutto lo
aliz-
zare e 
ontattare almeno un LookupServi
e (Figura 2.3 nella pagina su

essiva),
per farlo esistono due modi diversi:
2.3. JINI: COMPONENTI 29
Figura 2.3: Contattato Registrar
• stabilire una 
onnessione TCP direttamente 
ol LookupServi
e;
• eseguire una ri
hiesta UDP su al
uni 
anali di Multi
ast;
Nel primo 
aso è ne
essario 
onos
ere a priori l'indirizzo IP della ma

hina 
he
ospita il LookupServi
e, nell'altro 
aso no.
Quando un LookupServi
e ri
eve una ri
hiesta, spedis
e all'host mittente
un oggetto 
hiamato registrar (Fig. 2.4 nella pagina seguente), quest'ultimo
funge da proxy tra il servi
e provider e il LookupServi
e (Fig. 2.5 nella pagina
su

essiva).
2.3.3 I Clienti
Il 
liente è l'utilizzatore delle funzionalità 
he uno o più servizi mettono a
disposizione.
Le operazioni 
he un 
liente deve portare a termine per 
er
are i servizi
nei LookupServi
e, sono simili a quelle 
ompiute da un servi
e provider per la
registrazione di un'istanza di servizio.
La fase di ri
er
a del LookupServi
e e quella di ri
ezione del registrar sono
prati
amente le stesse. Le dierenze si basano sui diversi ruoli assolti dalle
due parti, infatti, mente i servi
e provider si preo

upano di mettere a dis-
posizione nuove funzionalità, l'obiettivo del 
liente è lo
alizzare e utilizzare le
risorse disponibili.