Università degli Studi di Torino
Scuola di Scienze della Natura
Corso di Laurea in Informatica
Progettazione e Sviluppo di un
Ambiente Distribuito per R
Tesi di Laurea di:
Davide Dal Farra
Matr. 177766
Relatore:
Prof.ssa Rosa Meo
a.a. 2012/2013
Indice
Introduzione 1
1 Modelli, tecnologie e stato dell’arte 3
1.1 I sistemi distribuiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Definizione e architettura di un Web Service REST . . . . . . . . . . . . 6
1.2.1 RESTful Web Services . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Il linguaggio R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Che cos’è R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Principali funzionalità . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 L’ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Sistemi e strumenti per l’integrazione di R all’interno di applicazioni . . . 15
1.4.1 Esecuzione in modalità non interattiva . . . . . . . . . . . . . . . 16
1.4.2 R/WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.3 PL/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.4 RJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.5 Rserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Sistemi distribuiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5.1 FastRWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5.2 RevoDeployR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
iii
Progettazione e Sviluppo di un Ambiente Distribuito per R
2 Descrizione del progetto di ricerca 25
2.1 I componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 I nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 La libreria Replica . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.3 Replica Web Service . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 La console di gestione . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1 La libreria Replica . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2 Replica Web Service . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Workspace e sessioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 La libreria Replica 37
3.1 I nodi e la loro configurazione . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.1 Il sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.2 R e i suoi moduli . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.3 Rserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.4 Componenti e configurazioni aggiuntive . . . . . . . . . . . . . . 41
3.2 La libreria Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.1 Il pacchetto org.rosuda.REngine . . . . . . . . . . . . . . . . . . 43
3.2.2 Istanziare un oggetto Replica . . . . . . . . . . . . . . . . . . . . 43
3.2.3 Il database relazionale . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.4 La gestione dei nodi . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.5 Il metodo connect() . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.6 Assegnazione dei valori in input . . . . . . . . . . . . . . . . . . 47
3.2.7 Esecuzione di un programma R . . . . . . . . . . . . . . . . . . 47
3.2.8 La gestione dei programmi R . . . . . . . . . . . . . . . . . . . . 48
iv
Progettazione e Sviluppo di un Ambiente Distribuito per R
4 Replica Web Service 51
4.1 Il server applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Il Cross-Origin Resource Sharing . . . . . . . . . . . . . . . . . 52
4.1.2 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Descrizione del processo . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.1 Il framework Spring . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.2 L’ Authentication controller . . . . . . . . . . . . . . . . . . . . 56
4.3.3 Lo ScriptExecutionController . . . . . . . . . . . . . . . . . . . 57
4.4 Lo schema relazionale . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Serializzazione dei parametri e dei risultati . . . . . . . . . . . . . . . . . 60
4.5.1 I parametri in input . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.2 Serializzazione dei risultati . . . . . . . . . . . . . . . . . . . . . 61
5 La console amministrativa 63
5.1 L’interfaccia utente e le funzionalità fornite . . . . . . . . . . . . . . . . 63
5.1.1 Funzionalità di configurazione . . . . . . . . . . . . . . . . . . . 64
5.1.2 La gestione degli script . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.3 Gestione degli utenti e assegnazione dei ruoli . . . . . . . . . . . 66
5.1.4 Gestione dei nodi . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.5 Il terminale di test . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 L’implementazione lato server . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.1 Il server applicativo . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2 Le librerie e il framework Spring . . . . . . . . . . . . . . . . . . 68
v
Progettazione e Sviluppo di un Ambiente Distribuito per R
5.2.3 La logica di controllo . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Lo sviluppo dell’interfaccia utente . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Il modello architetturale . . . . . . . . . . . . . . . . . . . . . . 71
5.3.2 Il terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6 Un esempio di utilizzo: test di verifica di normalità 77
6.1 Il problema: test di verifica di normalità . . . . . . . . . . . . . . . . . . 77
6.1.1 Il test di Anderson-Darling . . . . . . . . . . . . . . . . . . . . . 78
6.1.2 Un’implementazione in R . . . . . . . . . . . . . . . . . . . . . 78
6.1.3 La dimensione del dataset . . . . . . . . . . . . . . . . . . . . . 79
6.2 Test di normalità distribuito . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.1 Il dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3.2 La funzione R . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.3 Il codice JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.4 Configurazione del browser . . . . . . . . . . . . . . . . . . . . 85
6.4 Risultato dell’analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1 Prestazioni e utilizzo della memoria . . . . . . . . . . . . . . . . 86
7 Conclusioni e sviluppi futuri 87
Bibliografia 89
vi
Elenco delle figure
1.1.1 Un sistema distribuito . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Metodi per la gestione dei un oggetto WebSocket . . . . . . . . . . . . . 18
1.4.2 Definizione di un listener per l’evento onmessage. . . . . . . . . . . . . . 18
1.4.3 Esempio di funzione PL/R e relativa query di selezione. . . . . . . . . . . 19
1.5.1 Esempio di programma FastRWeb . . . . . . . . . . . . . . . . . . . . . 22
1.5.2 Elaborazione di una richiesta dal pacchetto FastRWeb . . . . . . . . . . . 22
1.5.3 Diagramma delle tecnologie utilizzate da RevoDeployR . . . . . . . . . . 23
1.5.4 Esempio di architettura distribuita su RevoDeployR . . . . . . . . . . . . 24
2.1.1 Componenti del sistema distribuito per il calcolo di analisi statistiche
attraverso l’uso dell’ambiente R . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 Rappresentazione dei singoli nodi . . . . . . . . . . . . . . . . . . . . . 27
2.1.3 La libreria Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.4 Replica Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.5 La console di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1 Schema di esecuzione di uno script R . . . . . . . . . . . . . . . . . . . 31
2.2.2 Schema del funzionamento di Replica Web Sevice . . . . . . . . . . . . . 33
2.3.1 Esempio di workspace durante l’esecuzione di Replica . . . . . . . . . . 34
2.3.2 Gestione del workspace durante l’esecuzione di Replica Web Service . . . 35
vii
Progettazione e Sviluppo di un Ambiente Distribuito per R
3.1.1 Rserve e la gestione dei workspace . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Diagramma della classe Replica . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2 Diagramma della classe REngine . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3 Schema del database relazionale in appoggio alla libreria Replica . . . . . 45
3.2.4 Processo di esecuzione di un programma R . . . . . . . . . . . . . . . . 48
4.1.1 Configurazione minima per fornire supporto CORS in Tomcat . . . . . . 53
4.2.1 Diagramma funzionale ed utilizzo del servizio web Replica . . . . . . . . 54
4.3.1 L’autentication controller . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.2 Lo ScriptExecution controller . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.1 Schema del database relazionale in appoggio al servizio web . . . . . . . 59
4.5.1 Esempio di stringa JSON per l’input di un programma R . . . . . . . . . 60
4.5.2 Esempio di serializzazione dell’output di un programma R . . . . . . . . 61
5.1.1 L’interfaccia utente suddivisa per aree di contenuto . . . . . . . . . . . . 64
5.1.2 Modifica di un programma R . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.3 Modifica degli output di un programma R . . . . . . . . . . . . . . . . . 65
5.1.4 Finestra di modifica utente . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.5 Interfaccia per la gestione dei nodi del sistema distribuito . . . . . . . . . 67
5.1.6 Il terminale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1 Diagramma delle classi Replica Console per il controllo delle richieste . . 69
5.2.2 Struttura di un controller . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.1 Architettura dell’interfaccia utente . . . . . . . . . . . . . . . . . . . . . 72
5.3.2 Organizzazione del codice sorgente dell’interfaccia utente . . . . . . . . . 73
5.3.3 Funzionamento del terminale . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.4 Il metodo replica.authenticate . . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.1 Implementazione del test di Anderson-Darlin in linguaggio R . . . . . . . 78
viii
Progettazione e Sviluppo di un Ambiente Distribuito per R
6.2.1 Diagramma funzionale: test di normalità distribuito . . . . . . . . . . . . 80
6.3.1 Componenti utilizzati per l’implementazione del test di normalità distribuito 81
6.3.2 Codice SQL per la selezione di 100.000 valori casuali . . . . . . . . . . . 82
6.3.3 Programma R per il calcolo del test di Anderson-Darling su di una parti-
zione di dati prelevata da un database MySQL . . . . . . . . . . . . . . . 83
6.3.4 Distribuzione dei valori del dataset . . . . . . . . . . . . . . . . . . . . . 84
6.3.5 Programma JavaScript per il calcolo del test di normalità attraverso il
servizio web Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4.1 Output su terminale con risultato del test e console di debug del browser
con visualizzazione delle chiamate AJAX e risposta . . . . . . . . . . . . 86
ix
Elenco delle tabelle
1.1 Mappatura dei metodi HTTP sulle operazioni più frequenti implementate
dai Web Service REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Tipi consentiti nella definizione dei parametri di input e output . . . . . . 61
5.1 Elenco dei ruoli utente disponibili . . . . . . . . . . . . . . . . . . . . . 66
6.1 Risultato test Anderson-Darling . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Confronto dei consumi di memoria e tempi di esecuzione del test di Anderson-
Darling in esecuzione su Replica Web Service e R . . . . . . . . . . . . . 86
xi
Introduzione
L’idea di progettare un ambiente distribuito per l’analisi statistica nasce dalla necessità di
sviluppare applicativi per il controllo della qualità in ambito manifatturiero che sfruttino
algoritmi di comprovato funzionamento e fama.
Grazie alla vasta disponibilità di librerie per lo Statistical Process Control e per la meto-
dologia Six Sigma, R è risultato essere l’unico ambiente con licenza open source in grado
di eguagliare, in qualità dell’output e funzionalità, prodotti commerciali come SPSS e
Minitab. Di difficile integrazione con linguaggi di alto livello, e difficilmente adattabile
in ambienti in cui requisiti come scalabilità e fault tolerance sono lo standard, si è pensato
di progettare e sviluppare un sistema che permetta di integrare R, indipendentemente dal
linguaggio utilizzato, in qualunque applicazione, e di centralizzarne la gestione attraverso
un sistema client-server distribuito.
Attraverso l’analisi delle funzionalità fornite dall’ambiente R e attraverso le conoscenze
maturate in anni di lavoro su ambienti distribuiti, si è provveduto a sviluppare una serie
di componenti che estendono i limiti di utilizzo di R e ne permettano l’integrazione in
pressoché qualunque ambito.
La trattazione dei temi enumerati, in particolare, si divide in 6 capitoli. All’interno del
primo capitolo si introducono i modelli architetturali, le tecnologie e gli standard che sono
alla base dello studio degli argomenti trattati nelle sezioni successive.
Il secondo capitolo fornisce una descrizione completa del progetto di ricerca. In modo
specifico, in questa parte è stato riservato ampio spazio alla definizione dei componenti e
al loro funzionamento, per i quali sono state evidenziate dipendenze e interazioni.
1
Progettazione e Sviluppo di un Ambiente Distribuito per R
Terminata l’analisi architetturale, i successivi tre capitoli descrivono, ognuno nel detta-
glio e fino a definirne i particolari implementativi, uno specifico componente del sistema,
dalla libreria Replica, che rappresenta lo strato intermedio del sistema, alla console di
amministrazione, un’applicazione web progettata per semplificare la gestione dell’interno
ambiente distribuito.
Nel sesto capitolo, allo scopo di individuare anche le applicazioni pratiche del progetto
stesse, vengono, infine, affrontati la progettazione e lo sviluppo di un algoritmo per il
calcolo del test di normalità distribuito su più nodi del sistema.
2
Capitolo 1
Modelli, tecnologie e stato dell’arte
Prima di passare alla discussione della tesi, si andranno a visionare alcuni degli argomenti
chiave analizzati da questa ricerca. Per prima cosa verrano date le definizioni di sistema
distribuito e di servizio web, successivamente verrà introdotto l’ambiente R insieme alle
soluzioni attualmente disponibili per la sua integrazione con altri linguaggi e software;
infine si concluderà con l’analisi di alcune soluzioni in grado di fornire l’accesso ad R in
maniera distribuita.
1.1 I sistemi distribuiti
Un sistema distribuito può essere visto come un insieme di elaboratori indipendenti in
grado, però, di apparire ai propri utenti come un singolo e coerente sistema. Questa defi-
nizione, seppure a prima vista elementare, racchiude due concetti fondamentali: il primo
è l’indipendenza dei singoli nodi, che agiscono in maniera autonoma, il secondo è il pun-
to di vista degli utenti che, di fatto, interagiscono con un unico singolo sistema. Questo
significa che i componenti del nostro insieme devono necessariamente collaborare; le mo-
dalità di implementazione costituiscono il cuore dello sviluppo di un sistema distribuito
[22].
3
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 1.1.1: Un sistema distribuito
L’indipendenza dei nodi appartenenti al sistema permette di delineare ulteriori caratteri-
stiche. L’eterogeneità dei singoli elaboratori, così come le modalità di comunicazione,
sono spesso nascoste all’utente. La stessa affermazione vale anche per l’organizzazione
interna. Utenti e applicazioni possono interagire con un sistema distribuito in maniera
consistente e uniforme, senza considerare quindi dove e quando l’interazione ha luogo.
Grazie a quanto affermato, in linea di principio i sistemi distribuiti sono adatti all’espan-
sione e alla scalabilità. Un ambiente distribuito, infatti, è realizzato in modo tale da essere
sempre disponibile, anche quando un nodo viene temporaneamente a mancare.
La differenza di architettura dei singoli nodi e delle loro interconnessioni richiede, per
offrire un’unica visione d’insieme, lo sviluppo di uno strato software frapposto tra un
livello più alto che consiste nelle applicazioni accedute dagli utenti, e uno più basso,
occupato dai singoli sistemi operativi. Come mostrato nella Fig. 1.1.1, questo strato
intermedio prende il nome di middleware.
1.1.1 Caratteristiche generali
Un sistema distribuito deve generalmente rispettare una serie di requisiti[9]:
Eterogeneità
Parte del problema è spesso rappresentato dalla varietà di differenti tipologie di rete, siste-
mi operativi, hardware e linguaggi di programmazione, che devono comunicare e collabo-
4
Progettazione e Sviluppo di un Ambiente Distribuito per R
rare tra loro. Protocolli standard come TCP/IP mascherano efficientemente le differenze
che si possono avere a livello di rete, il middleware, posizionato subito sopra il sistema
operativo, si occupa di livellare le differenze architetturali rimanenti.
Apertura
Un sistema distribuito nasce per essere estensibile: il primo passo è la pubblicazione
dell’interfaccia dei componenti.
Sicurezza
La cifratura può essere utilizzata per fornire un adeguato livello di protezione delle risorse
condivise e per mantenere protette le informazioni quando vengono trasmesse, tramite
messaggi, attraverso una rete.
Scalabilità
Un sistema distribuito è scalabile se il costo di aggiunta di un utente è costante in termini
di risorse che devono essere aggiunte al sistema stesso. Gli algoritmi utilizzati per acce-
dere ai dati condivisi devono essere scelti in modo da evitare colli di bottiglia1, mentre
l’accesso ai dati dovrebbe essere organizzato gerarchicamente in modo da ridurre i tempi
di accesso. Frequentemente l’accesso ai dati può essere replicato.
Tolleranza ai guasti
Ogni processo, nodo fisico o rete potrebbe smettere di funzionare correttamente indipen-
dentemente dagli altri. Per questo motivo ogni componente del sistema deve essere in
grado di funzionare anche quando uno o più componenti da cui esso dipende non sono
disponibili.
1Il “collo di bottiglia” è un fenomeno che si verifica quando le prestazioni di un sistema o le sue capacitàsono fortemente vincolate da un singolo componente. Il componente viene spesso chiamato anch’esso collodi bottiglia o punto del collo di bottiglia. Il termine è una metafora del collo di bottiglia reale, che limita ilflusso d’uscita dell’acqua.
5
Progettazione e Sviluppo di un Ambiente Distribuito per R
Concorrenza
La presenza di più utenti utilizzatori di un sistema è indice della necessità di permettere
un uso delle risorse in maniera concorrente. Ogni risorsa deve essere progettata per essere
acceduta in sicurezza.
Trasparenza
L’obiettivo di un sistema distribuito è riuscire a mascherare determinati aspetti della di-
stribuzione. Questo dà la possibilità al programmatore di concentrarsi unicamente sullo
sviluppo dell’applicazione.
1.2 Definizione e architettura di un Web Service REST
Il World Wide Web Consortium2 definisce i Web Service (Servizi Web) come sistemi
software che forniscono agli sviluppatori un mezzo per permettere l’interoperabilità tra
applicazioni differenti e non vincolate da una medesima tecnologia o framework [1].
1.2.1 RESTful Web Services
REST, REpresentational State Transfer, è uno stile architetturale per sistemi software di-
stribuiti. Il termine è stato introdotto e definito nel 2000 da Roy Fielding, uno dei princi-
pali autori delle specifiche del protocollo HTTP3. Indica una serie di principi archietturali
per la progettazione di Web Service [19].
Concetto centrale di un sistema RESTful è quello di risorsa. Una risorsa è qualunque
entità che possa essere indirizzabile tramite web, cioè accessibile e trasferibile tra client
2Organizzazione non governativa internazionale la cui attività principale consiste nello stabilire standardtecnici per il World Wide Web inerenti sia linguaggi di markup che protocolli di comunicazione.
3L’HyperText Transfer Protocol (HTTP) (protocollo di trasferimento di un ipertesto) è un protocolloapplicativo (livello 7 del modello OSI) alla base della trasmissione delle informazioni sul world wide web.
6
Progettazione e Sviluppo di un Ambiente Distribuito per R
METODO HTTP OPERAZIONE DESCRIZIONE
POST Creazione Crea una nuova risorsaGET Lettura Ottiene una risorsa esistentePUT Aggiornamento Aggiorna una risorsa o ne modifica lo stato
DELETE Cancellazione Elimina una risorsa
Tabella 1.1: Mappatura dei metodi HTTP sulle operazioni più frequenti implementate daiWeb Service REST
e server. Ad ogni chiamata quello che viene trasferito è una rappresentazione dello stato
interno della risorsa4.
Inizialmente REST viene descritto da Fielding nel contesto del protocollo HTTP e questo
è il protocollo, a livello di applicazione, maggiormente utilizzato. A differenza di altre
specifiche per Web Service, REST sfrutta, infatti, a pieno la semantica e la ricchezza dei
comandi HTTP e le sue funzionalità come, ad esempio, la negoziazione dei contenuti.
Perchè un Web Service sia conforme alle specifiche REST deve avere alcune specifiche
caratteristiche:
• identificazione delle risorse. Ciascuna risorsa deve essere identificata univocamen-
te. Essendo in ambito Web, il meccanismo più naturale per individuare una risorsa
è dato dal concetto di URI;
• comunicazione senza stato. Ogni ciclo di richiesta-risposta deve rappresentare
un’interazione completa del client con il server. In questo modo non è necessa-
rio mantenere, sul server, informazioni relative al client, minimizzando così l’uso
della memoria del server e semplificandone la logica;
• utilizzo esplicito dei metodi HTTP. Come principio generale, è utile evitare l’uso
di verbi negli URI, limitandosi ad utilizzare i metodi (o verbi) predefiniti di questo
protocollo, e cioè GET, POST, PUT e DELETE.
4Ad esempio l’ultimo post in un blog può essere servito ad un browser come una pagina in formatohtml, mentre ad un news reader come un documento xml.
7
Progettazione e Sviluppo di un Ambiente Distribuito per R
1.3 Il linguaggio R
Come si evince dall’incipit della sua guida ufficiale, R è un ambiente ed un linguaggio
per l’analisi statistica [10]. Non è unico nel suo genere, possiamo, infatti, facilmente
identificare numerosi prodotti analoghi come SAS, SPSS, MINITAB, solo per citarne
alcuni, programmi solitamente costosi, il cui uso viene concesso unicamente su licenza
da parte del produttore.
R vede la sua nascita proprio da due di questi: S, linguaggio creato da Becker, Chambers
e Wilks presso l’AT&T Bell Laboratories (luogo in cui videro la luce sia UNIX sia C) e
Scheme (Sussman). Il risultato è un linguaggio molto simile, in apparenza, ad S ma di
semantica derivata da Scheme.
Una delle principali differenze che hanno accelerato la diffusione di R è la licenza trami-
te la quale viene distribuito. R è un prodotto open source5 protetto dalla GNU General
Public License6. Questo significa che è possibile ottenere una copia dell’ambiente diretta-
mente dal sito http://r-project.org, installarlo e utilizzarlo senza alcun vincolo ma, soprat-
tutto, grazie alla disponibilità dei sorgenti, alla dettagliata documentazione e al supporto
della community, non vi è limite alla sua estensione e alla creazione di nuovi moduli e
funzionalità.
1.3.1 Che cos’è R
R è un ambiente statistico per la manipolazione, l’analisi e la rappresentazione dei dati le
cui caratteristiche principali possono essere riassunte in pochi punti:
• semplicità nella gestione e manipolazione dei dati;5In informatica il termine “open source” indica un software i cui autori (più precisamente i detentori dei
diritti) permettono e favoriscono il libero studio e l’apporto di modifiche da parte di altri programmatoriindipendenti. Questo è realizzato mediante l’applicazione di apposite licenze d’uso che ne vincolano ladistribuzione unitamente al codice sorgente.
6La GNU General Public License, comunemente indicata con l’acronimo GNU GPL o semplicementeGPL, è una licenza per software libero, originariamente redatta nel 1989 da Richard Stallman per distribuirei programmi creati nell’ambito del Progetto GNU della Free Software Foundation (FSF). Essa garantisceagli utenti finali di utilizzare, condividere e persino modificare il software (quest’ultima operazione non erainvece garantita dalle licenze per software proprietario).
8
Progettazione e Sviluppo di un Ambiente Distribuito per R
• disponibilità di metodi e funzioni per operazioni su vettori, matrici e altre operazio-
ni complesse;
• vasta disponibilità di strumenti integrati per l’analisi statistica;
• rappresentazione grafica dei dati semplificata grazie a numerose soluzioni integrate
flessibili e personalizzabili;
• linguaggio ad oggetti che permette una rapida estensione della libreria così come la
creazione di nuove funzioni.
E’ un prodotto multi piattaforma, sviluppato nel 1996 per Mac OS da Ross Ihaka e Robert
Gentleman del dipartimento di Statistica dell’Università di Auckland in Nuova Zelanda,
è stato successivamente “portato”7 su tutti i principali sistemi operativi.
A differenza di altri software statistici, R non viene fornito con una interfaccia grafica; tut-
te le operazioni devono, infatti, essere eseguite attraverso una console testuale. Esistono
tuttavia numerosi progetti in grado di sopperire a questa mancanza.
Un’importante differenza a livello di filosofia tra R e la maggior parte dei software stati-
stici è la differenza di output. Spesso con prodotti come Minitab8 ad una analisi statistica
seguono una notevole quantità di dati. R invece utilizza una serie di passi i cui risultati in-
termedi sono memorizzati all’interno di oggetti. Ad ogni passo l’output è minimo, dando
così all’utente la possibilità di analizzare e utilizzare il contenuto degli oggetti secondo la
reale necessità.
1.3.2 Principali funzionalità
La licenza open source unitamente alla vasta disponibilità di codice scritto in S, hanno per-
messo un rapido sviluppo dell’ambiente, tanto che già nel 1997 potè nascere l’R Develo-
7La portabilità, (in lingua inglese porting), in informatica, indica un processo di trasposizione, a volteanche con modifiche, di un componente software, volto a consentirne l’uso in un ambiente di esecuzionediverso da quello originale.
8Minitab è un software statistico distribuito dalla Minitab Inc., una compagnia privata con sede in StateCollege, Pennsylvania.
9
Progettazione e Sviluppo di un Ambiente Distribuito per R
pment Core Team, un gruppo formato da statistici di tutto il mondo che si occupa, ancora
oggi, dello sviluppo e della distribuzione del programma, mentre nel 2003 la R Founda-
tion for Statistical Computing iniziò a lavorare incessantemente al solo scopo di diffonde-
re e promuovere il linguaggio. Nuovi pacchetti vengono costantemente inseriti all’interno
del CRAN9, aumentando così le funzionalità messe a disposizione dell’ambiente.
Proprio i pacchetti o package, sono alla base dell’ambiente R. Un package è un insieme
di strumenti che svolgono determinate funzioni, ma che può contenere anche solo dati
oppure solo documentazione. Attualmente è disponibile una vasta gamma di pacchetti,
scaricabili dal CRAN repository, utilizzabili per la risoluzione di specifici problemi o per
analisi statistiche molto particolareggiate.
Il cuore di R è rappresentato da un pacchetto denominato base che “permette ad R di
funzionare come un linguaggio”[12] introducendo funzionalità aritmetiche, di input/out-
put, di flusso, e molte altre. Viene caricato automaticamente insieme ai pacchetti graphics
e stats che forniscono all’utente gli strumenti per le più importanti e diffuse analisi sta-
tistiche come ANOVA, regressione lineare, statistica descrittiva ed inferenziale, grafici
elementari, modelli lineari generalizzati, generazione di campioni delle più comuni va-
riabili casuali, operazioni su matrici e vettori, analisi dei dati di serie temporali e test
statistici (ad esempio test di normalità, test Chi-quadro, etc).
Ad oggi il CRAN repository consta di oltre cinquemila packages che spaziano attraverso
i più disparati campi della statistica applicata, tuttavia può essere utile, per comprendere
le potenzialità di R, identificare alcuni dei componenti più significativi che abbracciano
le più importanti e diffuse tipologie di analisi statistiche dei dati:
• pacchetti come grid, lattice, rgl e scatterplot3d consentono la realizzazione e mani-
polazione di grafici avanzati e tridimensionali;
• nel caso in cui si debbano effettuare analisi su dati multidimensionali, i pacchetti
9CRAN è l’acronimo di Comprehensive R Archive Network, un sistema per documentare e renderedisponibili i moduli aggiuntivi al software statistico R. E’ una rete di server FTP e di server web cheoffrono la versione aggiornata di R, assieme alla documentazione ed ai moduli aggiuntivi.
10
Progettazione e Sviluppo di un Ambiente Distribuito per R
mva, amap, miltidim, e multiv forniscono, tra le varie funzionalità, analisi del-
le componenti principali, analisi fattoriale, correlazione canonica, scaling multidi-
mensionale, clustering gerarchico;
• il pacchetto cluster è il modulo specializzato per l’analisi dei gruppi;
• nls permette, invece, di effettuare l’analisi della regressione con modelli non lineari
sfruttando i metodi dei minimi quadrati (Nonlinear Least Squares);
• l’uso avanzato di matrici e vettori è permesso dal package matrix, insieme a metodi
numerici per l’algebra lineare;
• l’integrazione con altri software statistici è fornita dal pacchetto foreign, contenente
una serie di funzioni utili all’importazione di file provenienti da software statistici
come Minitab, S, SAS, SPSS, Stats.
1.3.3 L’ambiente
La manualistica a disposizione di R è uno dei fattori che ne hanno determinato il suc-
cesso. La sua adozione come ambiente di lavoro per molte università di tutto il mondo
ha permesso la diffusione di guide, manuali, how-to e paper in grado di accontentare sia
il neofita che si avvicina per la prima volta ad R, sia l’utente esperto. In questa sezio-
ne ci limiteremo ad analizzare unicamente alcuni dei principali comandi, istruzioni che
torneranno utili nella gestione di un ambiente R distribuito.
La guida in linea
Nonostante la mancanza di una interfaccia grafica, R dispone di un efficiente sistema
di aiuto in linea che consente di ottenere informazioni dettagliate sulle funzioni in es-
so implementate. Ad esempio digitando help.start() un HTTP server, contenente la
guida in linea, viene attivato sull’indirizzo localhost:20134, permettendo così un ra-
11
Progettazione e Sviluppo di un Ambiente Distribuito per R
pido accesso alla documentazione tramite un qualunque browser che punti alla locazione
/doc/html/index.html.
Se si vuole accedere in maniera mirata alle informazioni di un solo specifico comando,
è inoltre possibile utilizzare la sintassi ?command il cui risultato è comparabile a quello
delle manpage di unix.
Data la quantità di comandi disponibili l’utente può inoltre cercare una parola chiave
all’interno della guida semplicemente utilizzando la funzione search:
> help.search("keyword")
Il workspace
All’uscita dall’ambiente ogni oggetto definito durante una sessione di lavoro (vettori,
matrici, data frames, liste e funzioni) viene solitamente memorizzato all’interno del file
Rdata, mentre la history, ovvero la cronologia dei comandi, all’interno del file Rhistory.
L’unione di Rdata e Rhistory dà origine al concetto di workspace.
Il salvataggio di questi file non è limitato esclusivamente al termine della sessione; può
essere, infatti, molto utile memorizzare una istantanea dell’ambiente ad un certo punto
della sessione e caricarla successivamente, magari perfino su di un’altra macchina.
Attraverso un piccolo set di funzioni, l’utente ha la possibilità di salvare un’istantanea
dell’ambiente di lavoro
> save.image("/tmp/myworkspace")
> savehistory("/tmp/myhistory")
e di poterla ricaricare successivamente
> load("/tmp/myworkspace")
> loadhistory("/tmp/myhistory")
è possibile anche salvare variabili presenti nel workspace su di un file al fine di poterli
archiviare o richiamare all’occorrenza
12
Progettazione e Sviluppo di un Ambiente Distribuito per R
> save(nomevariabile ,file=/tmp/myvariable)
e, sempre con la funzione load, aggiungerle al workspace corrente
> load("/tmp/myvariable")
Ridirezione dell’output
Normalmente R utilizza lo standard output10 come dispositivo di visualizzazione del
risultato dei comandi digitati; tuttavia è possibile reindirizzare lo stream di dati verso
una qualunque connessione (file, url, pipe, fifo, socket) permettendo, ad esempio, la
memorizzazione dell’output di una funzione tramite la ridirezione dello stesso su di un
file.
Il comando da utilizzare è sink, del pacchetto base
> sink("myoutput.txt")
la cui chiamata senza argomenti determina la chiusura della connessione precedentemente
aperta
> sink()
Personalizzazione
Nei capitoli successivi si potrà osservare come una corretta personalizzazione del sistema
sia fondamentale, ad esempio, per la gestione degli errori che possono verificarsi durante
l’esecuzione di un programma utilizzato in modalità non interattiva. Attraverso l’oggetto
options è possibile controllare numerose impostazioni quali, ad esempio, il numero di
cifre decimali da visualizzare o come deve apparire l’output.
Una lista completa delle opzioni disponibili si può visualizzare digitando in R il comando:
10I “canali standard” (o standard streams), in tutti i moderni sistemi operativi, rappresentano i dispositivilogici di input e di output che collegano un programma con l’ambiente operativo in cui esso viene ese-guito (tipicamente un terminale testuale) e che sono connessi automaticamente al suo avvio. I tre canalidi input/output predefiniti sono detti: standard input, standard output e standard error (talvolta abbreviatirispettivamente in stdin, stdout e stderr).
13
Progettazione e Sviluppo di un Ambiente Distribuito per R
> ?options
ad esempio, se all’interno del workspace corrente si vogliono visualizzare gli output a
virgola mobile con sole quattro cifre decimali, è necessario inserire il comando:
> options(digits =4)
La gestione dei pacchetti
L’elenco di pacchetti della Sez.1.3.2 fornisce un’idea di come un modulo aggiuntivo possa
aumentare le potenzialità di R. La stessa gestione dei package è demandata ad una serie di
comandi, tuttavia prima di fornire maggiori dettagli è necessario distinguere due tipologie
di pacchetti:
• moduli disponibili ma non caricati nel workspace;
• moduli reperibili in rete.
Un’istanza di R contiene, oltre ai pacchetti base, una serie di librerie aggiuntive gene-
ralmente molto utilizzate o spesso usate come dipendenza da librerie più specializzate.
L’elenco di questi pacchetti è ottenibile attraverso il comando
> library ()
mentre il caricamento di un pacchetto, necessario nel caso in cui si voglia utilizzare anche
solo una delle funzioni fornite, deve avvenire attraverso il comando
> library("packagename")
L’installazione di un nuovo pacchetto è un’operazione che può avvenire secondo due
modalità differenti:
• il pacchetto risiede nel CRAN repository
• il pacchetto è disponibile sul filesystem locale
14
Progettazione e Sviluppo di un Ambiente Distribuito per R
L’accesso alle risorse pubblicate sul CRAN repository è gestito direttamente da R. L’uti-
lizzo di questo metodo è senz’altro da preferirsi, in quanto consente di lavorare sempre
con moduli aggiornati e privi di errori noti.
Una volta identificato il nome del pacchetto è sufficiente invocare il comando
> install.packages("packagename")
Nel caso in cui si disponga del modulo in locale, uno dei metodi più utilizzati per la sua
installazione è la chiamata di R da shell con il parametro INSTALL
# R CMD INSTALL /tmp/package.tar.gz
1.4 Sistemi e strumenti per l’integrazione di R all’interno
di applicazioni
Tutti i più diffusi ambienti di programmazione possiedono una o più librerie sviluppate
per risolvere problemi statistici, tuttavia, la possibilità di poter sfruttare le funzionalità
di R da qualunque software, va ben oltre la semplice adozione di una libreria statistica
specializzata.
La base dell’interoperabilità tra R e il mondo esterno, è rappresentata dalle R-API, do-
ve un vasto numero di entry point11 presenti nell’eseguibile di R e nelle sue librerie ne
permette la chiamata da codice C12 [23]. Sebbene molto efficiente da un punto di vista
prestazionale, l’adozione del linguaggio C può essere molto restrittiva, specie nello svi-
luppo di applicazioni orientate al web, dove lo standard è dato da linguaggi di più alto
livello.11In programmazione un entry point è un indirizzo di memoria corrispondente a uno specifico punto del
codice sorgente di un programma. Normalmente un programma eseguibile possiede un singolo entry point,mentre una libreria molteplici.
12Il C è un linguaggio di programmazione ad alto livello sviluppato da Dennis Ritchie. Tuttavia, poi-ché esso mantiene evidenti relazioni semantiche con il linguaggio macchina e l’assembly, risulta moltomeno astratto di linguaggi anche affini (appartenenti allo stesso paradigma di programmazione), come peresempio il Pascal. Per questo motivo, talvolta viene anche identificato come linguaggio di medio livello.
Il C è rinomato per la sua efficienza, e si è imposto come linguaggio di riferimento per la realizzazionedi software di sistema su gran parte delle piattaforme hardware moderne.
15
Progettazione e Sviluppo di un Ambiente Distribuito per R
La difficoltà di interfacciamento tramite le R-API ha spinto allo sviluppo di soluzioni
alternative, spesso basate sulle API C, ma volte a semplificare il lavoro di integrazione
fornendo interfacce alternative per l’accesso ai metodi. Ecco alcune tra le soluzioni più
utilizzate:
• esecuzione di R in modalità batch non interattiva;
• RWebSockets;
• PL/R;
• RJ;
• RServe.
1.4.1 Esecuzione in modalità non interattiva
Nonostante la console interattiva rappresenti il metodo più diffuso per lavorare con l’am-
biente, è la modalità a riga di comando il modo più semplice per eseguire un programma
R e prelevarne il suo risultato:
# R CMD BATCH [options] infile [outfile]
dove infile rappresenta il nome del file da eseguire e outfile il nome del file su cui memo-
rizzare l’output.
Il vantaggio principale della modalità batch risiede nell’assenza di ulteriori pacchetti o
software da installare nel sistema. Un qualunque programma può eseguire una nuo-
va istanza di R, agganciarvi uno script e prelevarne l’output semplicemente sfruttando
i comandi messi a disposizione dal sistema operativo.
Questo modello di esecuzione non è esente da svantaggi. Nel caso in cui il program-
ma preveda l’inizializzazione di strutture complesse al momento dell’esecuzione, que-
ste devono necessariamente essere riempite prevedendo nella logica la lettura da file o
database.
16
Progettazione e Sviluppo di un Ambiente Distribuito per R
Di notevole impatto è la latenza introdotta dall’avvio dell’ambiente R, specie nel caso in
cui si preveda l’esecuzione di più istanze dello stesso programma contemporaneamente.
1.4.2 R/WebSockets
Grazie all’introduzione del pacchetto RWebSockets, R è in grado di interfacciarsi con
qualunque browser abilitato ai WebSocket HTML513.
I WebSocket
I WebSockets sono una tecnologia recentemente introdotta dallo standard HTML5 per
permettere alle applicazioni web di mantenere una comunicazione bidirezionale14 con
il processo server e fornire così agli sviluppatori uno strumento che può sostituire e
migliorare AJAX15.
Basati sul protocollo TCP16, forniscono un canale di comunicazione bidirezionale (sia
client-server sia viceversa) e full duplex (lettura e scrittura avvengono contemporanea-
mente).
Le API esposte sono molto semplici: ad esempio l’oggetto JavaScript17 WebSocket ri-
chiede come unico parametro l’indirizzo della risorsa
var webSocket = new WebSocket("ws://www.websocket.org");
13L’HTML5 è un linguaggio di markup per la strutturazione delle pagine web. Le novità introdotte dal-l’HTML5 rispetto alla versione 4 sono finalizzate soprattutto a migliorare il disaccoppiamento tra struttura,definita dal markup, caratteristiche di resa (tipo di carattere, colori, eccetera), definite dalle direttive di sti-le, e contenuti di una pagina web, definiti dal testo vero e proprio. Inoltre l’HTML5 prevede il supportoper la memorizzazione locale di grosse quantità di dati scaricati dal browser, per consentire l’utilizzo diapplicazioni basate su web anche in assenza di collegamento a Internet.
14Una modalità di trasmissione e ricezione di informazioni su un canale di comunicazione con caratteri-stiche tipiche di completa bidirezionalità. Si contrappone invece alla modalità simplex che ha caratteristichedi unidirezionalità.
15Acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo software per la realizzazio-ne di applicazioni web interattive. Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio didati in background fra browser e server, che consente l’aggiornamento dinamico di una pagina web senzaesplicito ricaricamento da parte dell’utente.
16Il Transmission Control Protocol (TCP) è un protocollo di rete a pacchetto di livello di trasporto.17JavaScript è un linguaggio di scripting orientato agli oggetti comunemente usato nella creazione di siti
web.
17
Progettazione e Sviluppo di un Ambiente Distribuito per R
webSocket.send("Hello world");
webSocket.close ();
Figura 1.4.1: Metodi per la gestione dei un oggetto WebSocket
webSocket.onmessage = function(event) {
console.log("Server says " + event.data);
}
Figura 1.4.2: Definizione di un listener per l’evento onmessage.
ed una volta istanziato permette di inviare informazioni al server e gestire il canale attra-
verso la chiamata di appositi metodi (Fig. 1.4.1).
L’interazione con i messaggi ricevuti avviene tramite la definizione di eventi specifici, a
cui è necessario associare delle funzioni di ascolto, chiamate listener (Fig. 1.4.2).
R/WebSockets
Introdotto nel 2011 e distribuito sotto licenza GNU LGPL versione 3 (che ne permette
quindi l’utilizzo anche da software commerciale e non open source), è una implementa-
zione del protocollo WebSocket HTML5 secondo le specifiche W3C, interamente scritta
in linguaggio R.
Il pacchetto fornisce i metodi per configurare un WebSocket server direttamente dall’am-
biente R e risulta particolarmente efficace nel permettere l’interazione tra R e linguaggi
di web scripting come JavaScript. Il supporto di più connessioni simultanee lo rende,
inoltre, idoneo per un utilizzo concorrente.
Sebbene i vantaggi introdotti da questa architettura siano notevoli, l’ambito di utilizzo
ristretto dei WebSocket ne limita fortemente la diffusione e adozione in applicativi non
orientati al web. Anche in questi ultimi è possibile identificare delle incompatibilità dove
l’assenza di un sistema in grado di suddividere il carico su più WebSocket pone forti limiti
sulla reale utilità in ambienti distribuiti quali quelli tipici del World Wide Web.
18
Progettazione e Sviluppo di un Ambiente Distribuito per R
create function r_logistic(x0 numeric , length integer , r numeric)
returns setof t_logistic as $$
ret = rep(x0, length)
index = as.character(as.Date (1:length , origin='1970 -01 -01'))
for (i in 2: length) {
ret[i] = r * ret[i-1] * ( 1 - ret[i-1] )
}
ret = cbind(r, ret , index );
return(ret)
$$ language 'plr';
select * from r_logistic (.5, 10, 3.5);
Figura 1.4.3: Esempio di funzione PL/R e relativa query di selezione.
1.4.3 PL/R
L’estensione per il database PostgreSQL, denominata PL/R, permette di integrare l’am-
biente statistico a livello della base dati grazie alla possibilità di definire funzioni e trigger
in linguaggio R. Non necessitando di alcuna libreria specifica, PL/R è la soluzione idea-
le per l’integrazione di R in applicazioni prive di codice sorgente, quindi difficilmente
modificabili.
L’output del programma R, solitamente definito a livello di funzione, può essere utilizzato
per la creazione di viste o semplici query di selezione. Dato che ogni chiamata diretta
all’interprete PL/R richiede la creazione di un nuovo processo dell’ambiente statistico,
l’utilizzo dell’estensione in concorrenza è scoraggiata, specie se si considera che il deploy
di entrambi i software deve avvenire sullo stesso sistema operativo, limitando così la
scalabilità, oltre che di R, anche dello stesso database.
1.4.4 RJ
RJ è una libreria open source che fornisce strumenti ed interfacce per integrare R all’in-
terno di applicazioni Java. Originariamente sviluppata per l’integrazione di una conso-
le R nel plugin per Eclipse StatET, è oggi una libreria flessibile che permette l’utilizzo
dell’ambiente statistico da applicazioni Java.
Nonostante la completezza delle funzionalità rese disponibili dalla libreria, l’adozio-
19
Progettazione e Sviluppo di un Ambiente Distribuito per R
ne delle JNI18 per la comunicazione con R ne vincola l’utilizzo in architetture multi-
piattaforma. La scarsità di documentazione e l’assenza di una vera e propria community
inoltre, rendono il progetto di difficile adozione.
1.4.5 Rserve
RServe è un server TCP/IP che facilita l’utilizzo dell’ambiente R da parte di linguaggi di
programmazione diversi, senza la necessità di inizializzare R o referenziare le sue API.
Costruito su modello client-server, la computazione del codice R è eseguita dall’oggetto
Rserve, un servizio in grado di rispondere a richieste provenienti da client quali, ad esem-
pio, applicazioni. La comunicazione tra Rserve e i client è basata sull’uso di socket di
rete, solitamente sfruttando il protocollo TCP/IP.
Grazie a questo modello, Rserve può gestire più client simultaneamente. Ogni connes-
sione ad Rserve viene allocata in un proprio spazio di memoria e in una propria directory
di lavoro, con l’immediato vantaggio di garantire un buon livello di isolamento tra le
connessioni.
Per ridurre la quantità di dati trasferiti e incrementare la velocità di trasferimento, lo
scambio dati tra le applicazioni ed Rserve avviene in forma binaria; inoltre, essendo gli
oggetti derivanti dall’elaborazione dei programmi R memorizzati internamente ad Rserve,
il trasferimento dati è minimizzato dal passaggio dei soli valori di reale interesse.
Un tipico utilizzo di Rserve consiste nel caricare tutti i dati necessari all’interno di R,
eseguire l’elaborazione e ritornare i risultati all’applicazione. Dati ed oggetti vengono
de-allocati unicamente alla chiusura della connessione, questo permette all’applicazione
di aprire una connessione ed instaurare un dialogo con il server, producendo elaborazioni
dipendenti dall’input dell’utente[24].
18La Java Native Interface o JNI è un framework del linguaggio Java che consente al codice Java dirichiamare (o essere richiamato da) codice cosiddetto "nativo", ovvero specifico di un determinato sistemaoperativo o, più in generale, scritto in altri linguaggi di programmazione, in particolare C, C++ e assembly.
20
Progettazione e Sviluppo di un Ambiente Distribuito per R
L’interfaccia ad Rserve è modulare e documentata, il che ha permesso lo sviluppo di
librerie che ne consentono l’utilizzo da parte di applicazioni e linguaggi di sviluppo
diversi.
1.5 Sistemi distribuiti
Le soluzioni esposte in questa sezione permettono non solo di integrare R all’interno di
applicazioni, ma anche di suddividere la computazione su più istanze dell’ambiente.
1.5.1 FastRWeb
Definito dallo stesso autore come un framework, permette di interfacciare R ad un server
HTTP che supporti lo standard Common Gateway Interface (CGI)19. Come per il pac-
chetto RWebSockets, anche FastRWeb ha come scopo quello di permettere una semplice
integrazione dell’ambiente R in applicativi web.
Sviluppato in linguaggio C e distribuito sotto licenza GNU GPL, necessita dei seguenti
componenti installati e configurati:
• un server web con supporto CGI
• un’istanza dell’ambiente R su cui vi sia installato e configurato il pacchetto Rserve
La logica è molto simile a quella usata dai linguaggi di scripting, come perl o PHP, per
generare il contenuto. Dal punto di vista della programmazione il concetto è semplice:
ogni risorsa servita dal server web corrisponde ad una specifica funzione R. Gli argomen-
ti della funzione corrispondono ai parametri in input forniti al momento della richiesta, e
possono essere arbitrati o basati sullo stato della sessione. Il risultato della funzione rap-
presenta il contenuto della risposta e può variare a seconda delle necessità implementative
(ad esempio da codice HTML a grafici interattivi).
19Tecnologia usata dai web server per interfacciarsi con applicazioni esterne e generare contenuti webdinamici.
21
Progettazione e Sviluppo di un Ambiente Distribuito per R
# file: kmeans.png.R
run <- function(clusters=3, ...) {
cl <- kmeans(x, clusters)
p <- WebPlot (600, 400)
plot(x, col = cl$cluster , pch =19)
points(cl$centers , col = 1:clusters , pch = 8, cex=2)
dev.off()
p
}
Figura 1.5.1: Esempio di programma FastRWeb
Figura 1.5.2: Elaborazione di una richiesta dal pacchetto FastRWeb
La Fig. 1.5.1 mostra uno script per la generazione di un grafico. I parametri della fun-
zione run, entry point del programma, vengono riempiti al momento della richiesta, che
solitamente corrisponde ad un URL come ad esempio:
http :// myserver/R/kmeans.png?clusters =4
Grazie alla combinazione di script parametrizzati ed interfaccia utente, l’interattività con
il contenuto può facilmente essere implementata con tecnologie quali hyperlinking20 e
AJAX, generando una serie di richieste e risposte interconnesse.
Il processo di elaborazione della richiesta schematizzato in Fig.1.5.2 mostra che è il brow-
ser, o un altro applicativo in grado di istanziare una richiesta HTTP, a fornire un URL con
la specifica dello script. L’URL, insieme agli eventuali parametri, viene successivamente
processato dal server web e passato ad una istanza di R che ne esegue la logica, istan-
ziando, dove necessario, gli oggetti e le strutture di supporto. A computazione avvenuta,
il risultato della funzione deve essere convertito in una forma conveniente per essere tra-
sportata dal protocollo HTTP e mostrata in un applicativo. E’ lasciata all’implementatore
la decisione di adottare uno standard piuttosto che un altro, e di avvalersi di componenti
terze parti per il rendering come, ad esempio, di output in formato HTML.
20Un collegamento ipertestuale (in inglese hyperlink) è un rinvio da un’unità informativa su supportodigitale ad un’altra. E’ ciò che caratterizza la non linearità dell’informazione propria di un ipertesto.
22
Progettazione e Sviluppo di un Ambiente Distribuito per R
1.5.2 RevoDeployR
RevoDeployR è un framework per l’integrazione dell’ambiente R in applicazioni basate
su tecnologie web. All’interno del sistema sviluppato da Revolution Analytics è possibile
evidenziare quattro componenti principali:
• un insieme di API per l’accesso ai web service;
• un insieme di web service per la gestione delle sessioni, dell’ambiente di esecuzione
e degli oggetti R;
• una console grafica per l’amministrazione del sistema;
• un’applicazione per il test dei servizi web.
Figura 1.5.3: Diagramma delle tecnologie utilizzate da RevoDeployR
Costruito sopra tecnologie open source, il framework dipende da numerosi componenti
software come ad esempio lo stesso ambiente R. Tra gli oggetti presenti nel diagramma in
figura Fig. 1.5.3, è possibile osservare la presenza del pacchetto Rserve, responsabile della
comunicazione tra il linguaggio R e i componenti di RevoDeployR. Il database relazionale
MySQL è invece utilizzato per mantenere un repository di script ed oggetti R, mentre a
livello applicativo il framework Spring fornisce una base per la gestione dei web service
e del modello di sicurezza[21].
23
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 1.5.4: Esempio di architettura distribuita su RevoDeployR
Per poter far fronte ad un aumento del carico di elaborazione, il sistema fornisce la possi-
bilità di variare il numero di istanze dell’ambiente R a disposizione degli utenti. La Fig.
1.5.4 mostra come più istanze di Rserve possano essere associate ad una singola istanza di
RevoDeployR. Le frecce di collegamento sono in realtà socket di rete, quindi gli oggetti R
ed Rserve che compongono il sistema possono essere posizionati localmente o all’interno
di una nuvola.
Grazie alla completezza delle funzionalità rese disponibili da RevoDeployR, il sistema
permette l’esecuzione di programmi R secondo due diverse modalità: prelevandoli da
un repository di script centralizzato, oppure inviando al server un blocco di codice R da
eseguire.
La flessibilità dell’ambiente, la centralizzazione della gestione e la scalabilità fanno del
framework RevoDeployR lo stato dell’arte tra i prodotti per l’integrazione di programmi
R in applicativi connessi al web. Tuttavia la scelta di Revolution Analytics di fornire un
software così complesso, ne limita notevolmente l’adozione in progetti in cui R viene
relegato al semplice uso come libreria statistica21, dove pertanto molte funzioni del fra-
mework si tramuterebbero in soli costi aggiuntivi. Proprio gli alti costi di licenza, uniti
all’impossibilità di poter personalizzare ed espandere il framework secondo le proprie esi-
genze, hanno ispirato lo sviluppo di un sistema simile a RevoDeployR come architettura,
ma più semplice e distribuito su licenza open source.
21Un insieme di funzioni specializzate non soggette a frequenti cambiamenti.
24
Capitolo 2
Descrizione del progetto di ricerca
Nello sviluppo di software statistico, uno degli aspetti principali da valutare in sede di
progettazione è la scelta del linguaggio, spesso vincolata dalla disponibilità di librerie in
grado di risolvere, se non totalmente, almeno parzialmente il problema.
In questo capitolo viene descritta l’architettura di un sistema che permetta l’utilizzo di un
linguaggio statistico specializzato, e delle sue librerie, indipendentemente dalle tecnologie
scelte per sviluppare il software.
2.1 I componenti
Quando si affronta lo sviluppo di applicazioni statistiche è bene valutare una serie di fat-
tori che andranno poi ad impattare sulle prestazioni e sulla bontà del sistema. La quantità
di dati che dovranno essere trattati, ad esempio, è spesso direttamente proporzionale al
tempo impiegato dal software per il calcolo dei risultati. Uno dei metodi più utilizzati per
garantire delle buone performance è l’adozione di strumenti di calcolo distribuito, ovvero
di tecniche che permettano la suddivisione del problema su più elaboratori ed in parallelo.
Il problema delle performance non è l’unica avversità che uno sviluppatore di software
statistico deve affrontare. La bontà, cioè la correttezza, dell’algoritmo è di fondamen-
tale importanza. L’adozione di costosi software statistici garantisce un certo livello di
25
Progettazione e Sviluppo di un Ambiente Distribuito per R
sicurezza ma, di contro, ne compromette l’espandibilità, vincolando il programmatore
all’utilizzo di tecnologie spesso proprietarie.
L’esperienza maturata in anni di sviluppo di software per il controllo statistico della qua-
lità ha portato alla decisione di progettare e realizzare un sistema scalabile e multiutente
costruito su tecnologie open source quali Java ed R. La Fig. 2.1.1 ne elenca i principali
componenti, impilati dal basso verso l’alto.
Figura 2.1.1: Componenti del sistema distribuito per il calcolo di analisi statisticheattraverso l’uso dell’ambiente R
Lo Strato più basso è occupato dai singoli nodi, che insieme contribuiscono alla creazione
di un array di macchine, tra di loro indipendenti, sulle quali il calcolo verrà distribuito.
Lo strato intermedio vede la libreria Replica come punto di unione tra la griglia e le
singole applicazioni utilizzatrici del sistema. Una console di gestione permette inoltre di
amministrare agevolmente l’aggiunta di nuovi nodi e l’inserimento di nuovi algoritmi. In-
fine, un database relazionale, e un cache server, completano l’insieme fornendo ai singoli
componenti uno strato dati ad accesso condiviso.
2.1.1 I nodi
In un array di elaboratori ogni elemento è costituito da un singolo computer, nel nostro
caso capace di interpretare codice R e comunicarne i risultati al suo strato superiore.
26
Progettazione e Sviluppo di un Ambiente Distribuito per R
Requisito fondamentale di ogni nodo è supportare l’esecuzione di R e dei suoi pacchetti.
Essendo R un linguaggio multi-piattaforma, la scelta del sistema operativo e dell’hard-
ware sottostante influenza unicamente le capacità di calcolo del nodo, non la compatibilità
con l’intero sistema.
Figura 2.1.2: Rappresentazione dei singoli nodi
La Figura 2.1.2 mostra due istanze di R installate su sistemi operativi e hardware diversi.
E’ però indispensabile notare come alcuni elementi del grafico siano comuni, nel dettaglio
la presenza del pacchetto Rserve e la sua configurazione, così come l’installazione di
ulteriori moduli.
Nonostante l’indipendenza e l’eterogeneità dei singoli nodi nel basso livello, ogni istanza
di R deve essere identica, come identica dovrà essere la configurazione del pacchetto
Rserve, strumento fondamentale per il corretto funzionamento dell’intero sistema.
2.1.2 La libreria Replica
Come si può osservare nella Fig. 2.1.1, la libreria Replica si posiziona nello stato inter-
medio del sistema proposto rendendo di fatto possibile la comunicazione tra l’insieme di
nodi e gli applicativi.
Strutturare lo strato middleware come libreria ne permette un doppio utilizzo. Sebbene
il sistema nasca con l’obiettivo di fornire una interfaccia web service di alto livello, un
27
Progettazione e Sviluppo di un Ambiente Distribuito per R
applicativo può referenziare direttamente Replica e sfruttarne le funzionalità in completa
autonomia, mantenendo così uno stack applicativo basso.
Figura 2.1.3: La libreria Replica
La Fig. 2.1.3 evidenzia questa doppia natura indicando come componente utilizzatore
una generica applicazione. Proseguendo verso il basso si osserva come Replica dipenda
da una serie di classi e componenti quali REngine e java.sql.
REngine è una libreria Java distribuita a corredo del pacchetto Rserve. Insieme a poche
altre classi fornisce un completo set di strumenti per comunicare con Rserve e di fatto
permettere lo scambio dati con i singoli nodi.
La configurazione dell’intero sistema, costituita dall’elenco dei nodi e dai programmi R
a disposizione degli utenti, è memorizzata in un database relazionale acceduto tramite
le funzionalità fornite dal package java.sql1. L’adozione di classi quanto più possibile
native della distribuzione Java, ha limitato la complessità del sistema pur mantenendo,
grazie all’adozione di driver specifici JDBC2, un buon livello di personalizzazione.
1Parte integrante della libreria JDBC, fornisce le funzioni per l’accesso e l’elaborazione di datimemorizzati in una sorgente dati (solitamente un database relazionale).
2JDBC (Java DataBase Connectivity) è un connettore per database che consente l’accesso alle basi didati da qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipodi DBMS utilizzato.
28
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 2.1.4: Replica Web Service
2.1.3 Replica Web Service
Salendo lungo la pila di componenti elencati in Fig. 2.1.1, incontriamo l’oggetto Replica
Web Service. Strato applicativo della libreria Replica, estende quest’ultima pubblicando
la sua interfaccia via HTTP grazie all’implementazione di un servizio web di tipo REST.
Per il deploy dell’oggetto ci si è avvalsi della versatilità del server applicativo Apache
Tomcat, una piattaforma software per l’esecuzione di applicazioni Web sviluppate in
linguaggio Java.
Lo sviluppo del componente si basa sul concetto di separazione del modello, della vista e
della logica (in inglese model, view, control), noto pattern architetturale3 la cui implemen-
tazione è stata facilitata dall’adozione del framework Java Spring. Nel dettaglio Spring
ha permesso di gestire in maniera efficiente l’interfaccia REST e l’accesso alla base dati,
attraverso l’uso della libreria Hibernate.
2.1.4 La console di gestione
La gestione dell’intero sistema è demandata ad un applicativo web appositamente svi-
luppato per poter efficientemente configurare le varie componenti e testare il corretto
funzionamento degli script R.
3Un design pattern è un concetto che può essere definito come una soluzione progettuale generale aun problema ricorrente. Si tratta di una descrizione o modello logico da applicare per la risoluzione di unproblema che può presentarsi in diverse situazioni durante le fasi di progettazione e sviluppo del software,ancor prima della definizione dell’algoritmo risolutivo della parte computazionale.
29
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 2.1.5: La console di gestione
Per semplificarne lo sviluppo e il deploy, si è scelto di adottare le stesse tecnologie presenti
alla base del Replica Web Service. Anche la console utilizza il pattern MVC e si avvale
dei framework Spring e Hibernate.
Nello sviluppo del componente ha assunto un ruolo fondamentale il design dell’interfac-
cia utente. Dovendo fornire un semplice e veloce accesso alle molteplici configurazioni
del sistema distribuito, si è scelto di adottare una libreria di controlli grafici completa e
con supporto multi browser quale ExtJS.
Completano il diagramma in Fig. 2.1.5, due ulteriori componenti: la libreria JQuery e
uno strato di comunicazione tra i nodi e la console occupato dal protocollo SSH4.
La libreria JQuery è alla base del terminale per il test. Una console testuale, accessibile via
web, che fornisce un set di comandi per la verifica dei programmi R inseriti nel sistema.
L’osservazione e la gestione dei nodi avviene attraverso il protocollo SSH. L’interfaccia
fornisce un piccolo set di funzionalità per l’avvio, l’arresto e la diagnostica dei processi
Rserve in esecuzione sui singoli nodi.
4SSH (Secure SHell, shell sicura) è un protocollo di rete che permette di stabilire una sessione remotacifrata tramite interfaccia a riga di comando con un altro host di una rete informatica.
30
Progettazione e Sviluppo di un Ambiente Distribuito per R
2.2 Funzionamento
Data l’architettura modulare del sistema, è possibile suddividere il processo di esecuzio-
ne in due fasi: l’invocazione dei metodi della libreria istanziando direttamente l’oggetto
Replica da un programma Java, e l’utilizzo dell’interfaccia fornita dal suo web service.
2.2.1 La libreria Replica
In Fig. 2.2.1 è possibile osservare i passi necessari all’esecuzione di uno script R.
Figura 2.2.1: Schema di esecuzione di uno script R
Il punto di partenza è rappresentato da un generico applicativo Java che, dovendo inter-
facciarsi con un programma R, istanzia la libreria Replica.
Il passo successivo, la selezione del nodo, avviene in contemporanea con l’apertura della
connessione verso l’oggetto Rserve. La libreria preleva, dal database in cui risiede la
configurazione del sistema, l’elenco dei nodi che insieme costituiscono l’array di istanze
R. La selezione del nodo candidato all’esecuzione avviene attraverso un scelta casuale
pesata.
31
Progettazione e Sviluppo di un Ambiente Distribuito per R
Instaurata la connessione, lo script oggetto della richiesta viene prelevato (sempre dalla
base dati) e i valori specificati in input dall’applicazione chiamante, passati all’istanza di
R.
Ottenuti i dati in input e il sorgente del programma, il nodo può eseguire il codice R. Nel
caso non siano state sollevate eccezioni la computazione termina con successo permet-
tendo alla libreria di prelevare dal database l’elenco delle variabili in output attese e di
richiedere all’istanza di R il fetching dei valori associati.
Una volta ritornato l’insieme di coppie “variabile, valore” all’applicazione, la connessione
può essere chiusa e le risorse liberate.
2.2.2 Replica Web Service
L’esecuzione di programmi R attraverso l’interfaccia pubblicata dal Replica Web Service
deve essere vista come un’estensione delle funzionalità fornite nativamente dalla libreria.
Osservando la Fig. 2.2.2 è possibile notare come la comunicazione fra l’applicativo e il
sistema sia demandata al protocollo HTTP (o HTTPS5 nel caso sia presente uno strato
SSL aggiuntivo).
Dato il differente metodo di distribuzione, ad esempio internet (nel caso si pubblichi il
servizio via web), è obbligatorio che l’applicazione client si autentichi tramite username
e password. Questo layer di protezione, assente nell’utilizzo diretto della libreria, impe-
disce l’uso illecito del sistema e, grazie all’identificazione dell’utente, permette, inoltre,
di differenziare il consumo delle risorse (resource shaping).
Ottenuto un codice hash6 come identificativo univoco della sessione, il metodo richiesto
dal client viene eseguito. Nel caso il programma necessiti di parametri in input, que-
5L’HTTPS (HyperText Transfer Protocol over Secure Socket Layer) è il risultato dell’applicazione diun protocollo di crittografia asimmetrica al protocollo di trasferimento di ipertesti HTTP. Viene utilizzatoper garantire trasferimenti riservati di dati nel web, in modo da impedire l’intercettazione dei contenutiscambiati.
6Risultato di una funzione hash, cioè una funzione non iniettiva (e quindi non invertibile) che mappauna stringa di lunghezza arbitraria in una stringa di lunghezza predefinita.
32
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 2.2.2: Schema del funzionamento di Replica Web Sevice
33
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 2.3.1: Esempio di workspace durante l’esecuzione di Replica
sti vengono deserializzati7 e passati all’oggetto Replica che viene istanziato ed eseguito
secondo la logica descritta nel paragrafo precedente.
A computazione avvenuta l’output dello script viene a sua volta serializzato e trasferito
all’applicazione come corpo della risposta.
2.3 Workspace e sessioni
Nel Par.1.3.3 si è parlato di workspace, di come questi vengono gestiti da R e quale sia la
loro importanza nell’esecuzione di un nuovo script. Per una completa descrizione dell’ar-
chitettura è necessario soffermarsi ulteriormente su questa particolarità dell’ambiente R,
analizzandone le implicazioni sul sistema distribuito.
Per comprendere i meccanismi di utilizzo della risorsa, è bene distinguere tra due diverse
gestioni del workspace: creato durante l’uso di Replica quando utilizzata come libreria da
un applicativo Java e quando istanziata dal Web Service.
7La serializzazione è un processo con il quale è possibile salvare un oggetto in un supporto di memo-rizzazione lineare (ad esempio, un file o un’area di memoria), o trasmetterlo su una connessione di rete. Laserializzazione può essere in forma binaria o può utilizzare codifiche testuali (ad esempio il formato XML)direttamente leggibili dagli esseri umani. Lo scopo della serializzazione è di trasmettere l’intero stato del-l’oggetto in modo che esso possa essere successivamente ricreato nello stesso identico stato dal processoinverso, chiamato deserializzazione.
34
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 2.3.2: Gestione del workspace durante l’esecuzione di Replica Web Service
Il diagramma in Fig. 2.3.1 fornisce un esempio del workspace durante l’esecuzione della
libreria Replica. Non appena viene istanziata la connessione con un nodo, R provvede alla
creazione di un workspace vuoto, che verrà riempito con le variabili in input necessarie
all’esecuzione del programma R. I passi successivi, ovvero l’esecuzione del codice e la
lettura delle variabili in output, non causano una immediata chiusura e de-allocazione
dello spazio di lavoro. E’ l’applicazione che, mantenendo il controllo della connessione,
ha il compito di terminare la comunicazione con il nodo, operazione che internamente
porta alla cancellazione del workspace associato.
Durante l’intera durata della connessione l’utente può quindi decidere di riutilizzare le
risorse presenti nello spazio di lavoro per, ad esempio, eseguire nuovi programmi sulla
base dei risultati precedentemente ottenuti e lasciati nel workspace.
Il ciclo di vita del workspace cambia notevolmente nel momento in cui Replica viene
istanziata attraverso le funzionalità messe a disposizione dal servizio web. L’assenza di
mantenimento dello stato del processo, caratteristica fondamentale dei web service di
tipo REST, non permette di mantenere aperta la connessione con R attraverso chiamate
consecutive, causandone così la chiusura immediata al termine dell’elaborazione.
La Fig. 2.3.2 mostra come ad ogni richiesta effettuata, un nuovo spazio utente venga
creato e distrutto non appena la computazione termini.
35
Capitolo 3
La libreria Replica
Si è parlato più volte della libreria Replica, in questo capitolo se ne descriverà il funzio-
namento, analizzandone l’implementazione, e i componenti ad essa collegati.
3.1 I nodi e la loro configurazione
Per comprendere il funzionamento della libreria, è necessario prima fornire una definizio-
ne formale di nodo del sistema.
Un nodo è un elaboratore collegato ad una rete TCP/IP in cui, tra i processi in background,
vi è in esecuzione un’istanza di Rserve, opportunamente configurata secondo delle linee
guida definite in questo capitolo.
3.1.1 Il sistema operativo
Pur non essendo vincolante, la scelta del sistema operativo è importante per l’efficienza
del sistema e la gestione dell’array di nodi. Le attuali versioni di R ed Rserve possono
essere eseguite su sistemi operativi di tipo Windows, OS X, Unix e Linux. Quest’ultimo,
Linux, più precisamente nella versione Ubuntu 12.04 LTS, è il sistema operativo utilizzato
per la progettazione e lo sviluppo del prototipo realizzato durante il lavoro di ricerca.
37
Progettazione e Sviluppo di un Ambiente Distribuito per R
Sistemi operativi diversi da Linux garantiscono una compatibilità con il sistema ma po-
trebbero introdurre differenze a livello di configurazione e gestione del cluster1.
3.1.2 R e i suoi moduli
Non esistendo un metodo univoco per l’installazione di R, si lascia alle indicazioni di ogni
singola distribuzione il compito di fornire indicazioni per un corretto deploy.
Una volta disponibile, l’ambiente deve essere personalizzato in modo da supportare tutti i
pacchetti necessari all’esecuzione dei programmi R eseguibili dal sistema. E’ importante
notare come tutti i nodi dovranno avere gli stessi pacchetti installati. E’ infine consi-
gliabile mantenere tutte le istanze di R, con i relativi moduli, aggiornati e alla stessa
revisione.
3.1.3 Rserve
La presenza del pacchetto Rserve su ogni singolo nodo è obbligatoria. A differenza degli
altri pacchetti, generalmente privi di configurazione, Rserve necessita di alcune modifiche
e aggiunte al file system.
Configurazione
La configurazione di Rserve, nel caso si utilizzi un sistema operativo Linux, è memoriz-
zata nel file /etc/Rserve.conf.
All’esecuzione del demone2, Rserve viene caricato con una configurazione di default
spesso sufficiente per la maggior parte degli scenari applicativi.
Nel listato che segue viene riportata la configurazione in uso nell’ambiente di ricerca.
interactive off
1Un cluster è un insieme di computer connessi tra loro tramite una rete dati.2Nei sistemi Unix, e più in generale nei sistemi operativi multitasking, un demone (daemon in inglese)
è un programma eseguito in background, senza che vi sia un controllo diretto dell’utente.
38
Progettazione e Sviluppo di un Ambiente Distribuito per R
remote enable
encoding utf8
source /etc/Rserve/RScripts/source.R
Lasciando alla guida ufficiale di Rserve la descrizione dettagliata dei parametri di confi-
gurazione, ci si soffermerà unicamente sulla direttiva source.
Inizializzazione del WorkSpace di R
Per una corretta comprensione delle funzionalità disponibili nell’ambiente, è fondamen-
tale fornire alcuni dettagli sulla gestione dei workspace, più precisamente su come questi
vengano creati.
Figura 3.1.1: Rserve e la gestione dei workspace
Successivamente all’esecuzione del servizio Rserve, si assiste, come evidenziato in Fig.
3.1.1 alla creazione di una nuova istanza dell’ambiente R. Il workspace appena creato vie-
ne riempito con l’output dell’esecuzione del file source.R specificato nella configurazione
di Rserve.
39
Progettazione e Sviluppo di un Ambiente Distribuito per R
Per limitare la latenza che la generazione di un nuovo processo R introdurrebbe ad ogni
istanziamento, Rserve, in seguito ad ogni connessione entrante, esegue un fork3 del pro-
cesso R, dando vita ad una nuova istanza copia di quella iniziale. In questo modo tutte
le richieste vengono eseguite in un ambiente uguale in cui lo script source.R ha ruolo
determinante per la configurazione iniziale.
E’ importante notare come, ad esempio, la decisione di specificare il caricamento delle
librerie più di uso comune internamente a source.R ottimizzi l’esecuzione dei programmi
eseguiti, specie se in condizioni di concorrenza.
L’uso di una libreria condivisa tra tutti i nodi del sistema permette inoltre di fornire ai
programmi un set di istruzioni comuni che, in sistemi orientati alla soluzione di spe-
cifici compiti come l’analisi qualitativa, semplifica notevolmente la logica dei singoli
programmi.
Esecuzione di Rserve e log
Trattandosi di un pacchetto aggiuntivo per R, è lasciato agli implementatori il compito di
fornire un metodo per la corretta esecuzione del servizio sul nodo.
Nel caso di sistemi operativi Linux, è possibile reindirizzare l’output del demone su di un
file sfruttando le funzionalità fornite dalla shell Bash:
#!/bin/sh
R CMD Rserve --no -save --RS -conf /etc/Rserve.conf > /var/log/Rserve/log 2>&1
Il re-indirizzamento dei flussi di error e output (stderr e stdout), permette di ottenere
con poco sforzo una efficiente infrastruttura di logging completamente gestita dal sistema
operativo.
3Una fork in programmazione è la modalità attraverso la quale un processo crea in memoria una copia dise stesso: la copia prenderà il nome di processo figlio, mentre il processo originale verrà chiamato processopadre.
40
Progettazione e Sviluppo di un Ambiente Distribuito per R
3.1.4 Componenti e configurazioni aggiuntive
Da semplici istanze di Rserve in esecuzione su sistemi operativi minimali, i nodi possono
richiedere anche configurazioni più complesse. Questo in base al tipo di problemi che
verranno trattati dal sistema.
Non essendo l’obiettivo di questa tesi affrontare una specifica casistica, ci si limiterà
alla descrizione di due ulteriori configurazioni che permettono, spesso con le risorse già
presenti in un sistema operativo Linux, di risolvere problemi complessi come il calcolo
distribuito su di un insieme di nodi.
Definizione di una base dati comune
La definizione di una base dati comune è forse il primo passo necessario per la costruzione
di uno strato che permetta la comunicazione inter-nodo. Di semplice implementazione,
richiede il deploy di un database accessibile da tutti gli elementi del cluster e dei pacchetti
R necessari alla sua interfaccia.
Configurazione di un filesystem condiviso
Protocolli come NFS4, spesso nativamente supportati dal sistema operativo sottostan-
te, permettono la definizione di una porzione di filesystem condivisa in cui, ad esem-
pio, poter salvare un’istantanea del workspace corrente. Sebbene l’accesso concorren-
te possa limitare l’utilizzo di questo tipo di risorsa, se ben strutturata fornisce un layer
di comunicazione inter-nodo veloce ed efficiente, che non necessita di alcun pacchetto
aggiuntivo.
Redis e calcolo distribuito
La soluzione di problemi attraverso l’esecuzione di più operazioni distribuite su nodi di-
versi, ognuno dedicato alla soluzione di una parte del problema, non è nuova nel panorama4Il Network File System (NFS) è un protocollo per l’implementazione di un file system di rete che
consenta ai computer di utilizzare la rete per accedere ai dischi rigidi remoti come fossero dischi locali.
41
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 3.2.1: Diagramma della classe Replica
di R. Redis è una base dati di tipo no-SQL che, grazie alla sua velocità nel gestire il flus-
so di dati in ingresso e uscita, è spesso accoppiata a pacchetti specializzati nel calcolo
distribuito.
3.2 La libreria Replica
La libreria Replica è formata da un insieme di classi Java che, una volta istanziate,
funzionano da interfaccia dell’insieme di processi Rserve in esecuzione sull’array.
Come mostrato nella Fig. 3.2.1, è la classe Replica che, istanziando un oggetto di tipo
RConnection, permette la comunicazione con i nodi sottostanti.
42
Progettazione e Sviluppo di un Ambiente Distribuito per R
3.2.1 Il pacchetto org.rosuda.REngine
Prima di passare alla formalizzazione dell’oggetto Replica, è necessario soffermarsi sul-
l’analisi dei package org.rosuda.REngine e org.rosuda.REngine.Rserve.
I due package rappresentano lo stato dell’arte per la connessione ad un processo Rserve
da un applicativo Java. Distribuiti dietro licenza GNU LGPL, possono essere prelevati dal
sito ufficiale di Rserve e utilizzati in ogni tipo di software Java (anche non open source).
La classe REngine, oggetto principale della libreria, funziona da proxy5 tra l’istanza di
Rserve e l’applicativo client. Fornisce i metodi per il parsing, l’esecuzione di codice R e
l’assegnazione di valori alle variabili presenti nel workspace.
La comunicazione con il server Rserve è gestita dalla classe RConnection che, come
mostrato in Fig. 3.2.2, estende la classe REngine implementando un set di funzioni per la
gestione della connessione TCP/IP.
3.2.2 Istanziare un oggetto Replica
Partendo dall’analisi del costruttore, di seguito listato, è possibile iniziare a descrivere nel
dettaglio il funzionamento della libreria.
public Replica(String connectionString , String driver , String prefix ,
IReplicaCache replicaCache) throws ReplicaException {
...
}
Come evidenziato in Fig. 2.2.1, il sistema necessita della presenza di una base dati con-
tenente una serie di informazioni quali l’elenco dei nodi e i programmi R eseguibili dal
sistema.
La dipendenza di Replica da una base dati è evidente se si osservano i primi tre parametri
del costruttore: una stringa di connessione6, un JDBC driver e un prefisso per i nomi delle
tabelle.5Un proxy è un programma che si interpone tra un client ed un server facendo da tramite o interfaccia
tra i due host, ovvero inoltrando le richieste e le risposte da uno all’altro.6La stringa di connessione specifica: un insieme di regole per identificare la risorsa a cui accedere e la
configurazione del canale di comunicazione tra client e server. Alcune informazioni solitamente sono: il
43
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 3.2.2: Diagramma della classe REngine
44
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 3.2.3: Schema del database relazionale in appoggio alla libreria Replica
3.2.3 Il database relazionale
Per permettere una gestione centralizzata del sistema distribuito, l’intera configurazio-
ne, costituita dall’elenco dei nodi Rserve, dai programmi R eseguibili e dai loro output,
risiede internamente ad un database relazionale compatibile con lo standard JDBC7.
Il diagramma in Figura 3.2.3 fornisce i dettagli dello schema, necessari per istanziare
correttamente la libreria Replica.
3.2.4 La gestione dei nodi
Principio fondamentale della libreria è fornire un metodo per l’accesso alle risorse del
sistema. La gestione, come ad esempio l’aggiunta di un nuovo nodo, va considerata
come un’operazione esterna e pertanto non inclusa nel set di istruzioni pubblicate dalla
classe. Premesso questo, è ugualmente importante comprendere come i nodi debbano
essere organizzati internamente alla base dati.
driver di connessione (dipendente dal tipo di database a cui ci si vuole connettere), il tipo di autenticazione,l’indirizzo del server, il database che si vuole utilizzare e informazioni supplementari ( quali ad esempiocharset, regole di confronto, gestione dei NULL, etc.)
7Per lo sviluppo del modello oggetto di questa tesi, si è utilizzato il prodotto Oracle MySQL nellaversione 5.5 e il suo connettore JDBC nella versione 5.1.29.
45
Progettazione e Sviluppo di un Ambiente Distribuito per R
La tabella server elenca l’insieme di istanze Rserve presenti nel sistema. L’aggiunta o
rimozione di un singolo elemento può avvenire agendo direttamente sulla tabella e sui
suoi campi:
address è l’indirizzo ip dell’elaboratore su cui viene eseguito il processo Rserve;
port è la porta del socket a cui Rserve risponde;
weight è il peso da associare al nodo, un valore intero che influenza la selezione del nodo
durante il prelievo random dalla lista;
3.2.5 Il metodo connect()
Istanziato l’oggetto e fornita una configurazione, è possibile aprire una connessione verso
uno dei nodi dell’array utilizzando il metodo connect pubblicato dalla classe Replica. E’
a questo punto dell’esecuzione che avviene la selezione del nodo.
Selezione del nodo e bilanciamento del carico
Parlando di sistemi distribuiti, è impossibile non imbattersi sul concetto di load balan-
cing8. Una corretta distribuzione del carico sui nodi costituenti un sistema assicura che
ogni risorsa (cpu, memoria, disco e rete) venga sfruttata in maniera quanto più simile
rispetto alle altre. Essendo la selezione del nodo un evento collegato all’esecuzione di
codice, e quindi al consumo di risorse, influisce in maniera diretta sul bilanciamento del
carico.
Un buon sistema di load balancing dovrebbe essere generico, stabile, scalabile e non
costituire esso stesso una fonte di rallentamento [4]. Considerata l’architettura dell’array,
costituito da elementi non connessi, si è scelto di utilizzare un algoritmo statico, quindi
8Il load balancing è una tecnica informatica utilizzata nell’ambito dei sistemi informatici che consistenel distribuire il carico di elaborazione di uno specifico servizio tra più server. Ad esempio nel caso in cuivengano effettuate 10 richieste su di un cluster di 3 server, alle prime 3 risponderà il "primo" server, a 3 il"secondo" ed alle ultime 4 il "terzo".
46
Progettazione e Sviluppo di un Ambiente Distribuito per R
non basato sull’osservazione del sistema in esecuzione ma sul suo comportamento medio
atteso.
Un algoritmo di selezione randomizzato e pesato
Un algoritmo randomizzato utilizza, per la selezione del processo, numeri casuali. Nono-
stante la semplicità insita nella selezione casuale di un nodo, questo genere di algoritmi
può ottenere ottime performance, anche se comparato a metodi di selezione più complessi
o dinamici[11].
Durante la lettura dei nodi, questi vengono inseriti all’interno di un oggetto di tipo Ran-
domCollection, una struttura dati i cui elementi possono essere estratti in maniera casuale.
Nel caso in cui gli elementi del sistema siano eterogenei e le risorse non ugualmente
distribuite sui nodi, l’equità della scelta viene comunque garantita dalla possibilità di
assegnare un peso al singolo elemento, cioè un numero positivo che identifichi una singola
istanza di Rserve come maggiore candidata per la selezione.
3.2.6 Assegnazione dei valori in input
In base alla logica e al tipo di programma da eseguire sull’istanza Rserve selezionata,
può essere necessario inserire nel workspace una o più variabili il cui valore assegnato
influenzerà l’elaborazione dello script. Per istanziare, e allo stesso tempo riempire, le
variabili ospitate nel workspace R, la classe Replica fornisce il metodo assignParameter
i cui overload9 permettono di trattare i principali tipi primitivi di R.
3.2.7 Esecuzione di un programma R
Selezionata un’istanza Rserve, è possibile avvalersi del metodo execute per eseguire un
programma R e ritornarne i risultati.
9Caratteristica del linguaggio Java che permette di “sovraccaricare” un metodo di una classe con diversevarianti, in base ai parametri passati come riferimento. Dal punto di vista dell’utilizzo della classe ciò ciconsente di definire in maniera dinamica il metodo che meglio si adatta all’esigenza di utilizzo.
47
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 3.2.4: Processo di esecuzione di un programma R
Il metodo getScriptContent, che come mostrato inFig. 3.2.4 rappresenta il primo passo
dell’esecuzione, si occupa della lettura del listato del programma R prelevato dalla base
dati relazionale.
Non appena disponibile, lo script viene eseguito sulla connessione Rserve selezionata. In
caso di errori l’esecuzione viene interrotta sollevando una eccezione di tipio ReplicaEx-
ception.
Eseguito il codice, i risultati sono temporaneamente memorizzati nel workspace dell’i-
stanza R: è, infatti, compito del metodo getOutputScript prelevare dal database le variabili
specificate come output e prelevarne il valore attraverso una serie di ulteriori chiamate ad
Rserve.
Terminata la fase di prelievo dell’output i risultati, memorizzati all’interno di una struttura
dati di tipo “chiave, valore”, sono passati al metodo chiamante.
La connessione rimane aperta permettendo al programma successivo di essere eseguito
all’interno dello stesso workspace.
3.2.8 La gestione dei programmi R
Analogamente alla gestione dei nodi, la libreria non fornisce metodi a supporto della
memorizzazione e manipolazione dei programmi R e dei loro output. Tuttavia la scelta
di utilizzare una base dati come repository dà all’utente la possibilità di centralizzarne
la gestione attraverso l’utilizzo di uno dei diversi client solitamente a forniti insieme al
database engine.
48
Progettazione e Sviluppo di un Ambiente Distribuito per R
Ogni programma, per poter essere eseguito dal sistema distribuito, deve essere inserito
all’interno della tabella script mostrata in Fig. 3.2.3. In particolare il campo content
contiene il listato del programma in linguaggio R, mentre name e id ne associano ri-
spettivamente un nome ed un identificativo univoci che dovranno essere utilizzati per
l’esecuzione e la configurazione degli output.
Come descritto nella Sez. 3.2.7, l’esecuzione non comporta necessariamente il ritorno di
risultati, si pensi ad esempio a programmi il cui output viene memorizzato su di una base
dati o a piccoli script creati per eseguire solo una parte dell’elaborazione (il cui output è
l’input del programma successivo).
La specifica dei risultati, e le istruzioni su come prevelarli, sono demandati alla tabella
output, di seguito descritta:
id valore auto-incrementato dal sistema per identificare univocamente il singolo output;
script contiene l’identificativo del programma a cui l’output si riferisce;
variable obbligatorio; è il nome della variabile del workspace da cui prelevare il valore;
code opzionale; contiene una o più istruzioni in linguaggio R da eseguire e il cui risultato
verrà inserito all’interno della variabile specificata nel campo “variable”.
49
Capitolo 4
Replica Web Service
Analizzando la vendita di libri e manuali specializzati [18], oppure osservando come de-
terminati termini siano utilizzati all’interno di motori di ricerca 1 [16], è possibile misurare
la popolarità e la diffusione di un linguaggio di programmazione quale, ad esempio, Java.
Nonostante il prodotto della Oracle sia tra i linguaggi più utilizzati, la sua diffusione è in
netto calo [3]; da diversi anni infatti si assiste alla crescita di linguaggi interpretati2 quali
PHP e JavaScript, da cui l’utilizzo della libreria Replica, senza lo sviluppo di un servi-
zio che ne permetta l’integrazione, risulta impossibile. Per far fronte a questo problema
e permettere l’integrazione di R anche da applicazioni non-Java, si è proceduto con la
progettazione e lo sviluppo di un servizio web che permetta l’esecuzione dei metodi di
Replica attraverso semplici chiamate HTTP.
4.1 Il server applicativo
La progettazione del web service ha richiesto innanzitutto l’identificazione di un server
applicativo adatto all’esecuzione del servizio e conforme agli standard e alle tecnologie
più recenti che ne permettano l’utilizzo indipendentemente dal dominio di origine.
1Google Trends2Eseguiti da un interprete. Un interprete ha lo scopo di eseguire un programma in un linguaggio di alto
livello senza la previa compilazione dello stesso.
51
Progettazione e Sviluppo di un Ambiente Distribuito per R
4.1.1 Il Cross-Origin Resource Sharing
Uno scenario ricorrente nelle applicazioni web è quello in cui la pagina, mediante Ja-
vaScript e XmlHttpRequest, accede a dei dati consumando un servizio REST. In questo
scenario, per attenuare i rischi derivanti da attacchi di tipo "Cross Site Scripting" o "Man
in the middle", i browser applicano una restrizione, detta same-origin, per assicurare un
livello di sicurezza adeguato e scongiurare gli attacchi citati. Tutto questo si traduce, in
sintesi, nell’impossibilità di accesso ai dati esposti da un servizio REST-based sul do-
minio www.aaa.com, da parte di un’applicazione web esposta su un dominio diverso, ad
esempio www.bbb.com [26].
Esistono diversi workaround per aggirare la restrizione same-origin, uno dei quali è JSONP
ovvero JSON with Padding. Questo espediente consiste nell’iniettare uno script, esposto
come risorsa remota su un dominio differente. Tipicamente si tratta di una risorsa fittizia,
rappresentata da una risposta costruita lato server (ASP.NET, PHP, etc.) contenente codi-
ce JavaScript + dati JSON, entrambi vengono utilizzati dal client, nella pagina richiedente,
per servire la richiesta iniziale.
Con HTML5 si ha facoltà di disabilitare la restrizione same-origin, consentendo chiama-
te AJAX verso domini differenti, a patto di includere nella risposta (prodotta dal server)
l’header Access-Control-Allow-Origin in cui sono specificati i domini autorizzati ad ef-
fettuare chiamate. La risposta prodotta dall’ipotetico servizio REST www.aaa.com, dovrà
quindi contenere l’header:
Access -Control -Allow -Origin:www.bbb.com
oppure, se s’intende esporre pubblicamente l’api, senza alcuna limitazione (ma con tutti i
rischi del caso), sarà sufficiente specificare:
Access -Control -Allow -Origin :*
52
Progettazione e Sviluppo di un Ambiente Distribuito per R
4.1.2 Apache Tomcat
Apache Tomcat (o semplicemente Tomcat) è un web container open source sviluppato
dalla Apache Software Foundation. Implementa le specifiche JSP e Servlet di Oracle,
fornendo, quindi, una piattaforma per l’esecuzione di applicazioni Web sviluppate nel
linguaggio Java.
Dalla versione 7.0.41, grazie ad un apposito filtro, Tomcat fornisce pieno supporto al
Cross-Origin Resource Sharing [2]. Essendo la specifica CORS uno dei requisiti fonda-
mentali per l’utilizzo del web service da applicazioni JavaScript, il listato in Fig. 4.1.1
fornisce un esempio di configurazione minimale.
<filter >
<filter -name>CorsFilter </filter -name>
<filter -class>org.apache.catalina.filters.CorsFilter </filter -class>
</filter >
<filter -mapping >
<filter -name>CorsFilter </filter -name>
<url -pattern >/*</url -pattern >
</filter -mapping >
Figura 4.1.1: Configurazione minima per fornire supporto CORS in Tomcat
4.2 Descrizione del processo
L’ambito di utilizzo di un web service è spesso molto diverso da quello di una libreria.
Nonostante il fine comune, cioè fornire funzionalità aggiuntive al programma, la pubbli-
cazione del servizio, solitamente in ambienti aperti e non sicuri come internet, implica
lo sviluppo di una serie di accorgimenti che è possibile ritrovare anche all’interno del
Replica Web Service.
4.2.1 Autenticazione
L’utilizzo dei metodi e delle funzioni pubblicate dal servizio web è subordinato all’iden-
tificazione del processo consumatore. Per poter eseguire un programma R il primo passo
necessario è quindi fornire le credenziali per l’accesso, autenticandosi così sul sistema.
53
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 4.2.1: Diagramma funzionale ed utilizzo del servizio web Replica
Il processo di autenticazione prevede la chiamata, da parte del consumatore (solitamente
un browser), del metodo authenticate.action a cui, come evidenziato in Fig. 4.2.1, dovran-
no essere comunicate username e password di un utente abilitato all’utilizzo di Replica
Web Service.
Ad autenticazione avvenuta il servizio genera una chiave (authentication token) che viene
immagazzinata in una tabella della base dati e infine ritornata come risposta al processo
consumatore.
4.2.2 Esecuzione
Ottenuto un authentication token valido l’applicativo può utilizzare il metodo exec.action,
pubblicato dal web service, per eseguire un qualunque programma R disponibile nel siste-
ma. I dati contenuti nel messaggio HTTP della chiamata, codificati in JSON3, istruiscono
3JSON, acronimo di JavaScript Object Notation, è un formato adatto per lo scambio dei dati inapplicazioni client-server. Pur essendo basato sul linguaggio JavaScript ne è indipendente.
54
Progettazione e Sviluppo di un Ambiente Distribuito per R
il servizio sul programma da eseguire e sulle variabili da inserire nel workspace. A com-
putazione avvenuta, la risposta HTTP conterrà la codifica JSON degli output dello script
specificati nella configurazione di Replica.
4.3 Implementazione
Oltre all’utilizzo del server applicativo Apache Tomcat, la progettazione del servizio web
ha richiesto l’adozione di ulteriori framework e librerie, permettendo così uno sviluppo se-
condo paradigmi architetturali moderni, quali RAD e MVC, e una più facile espandibilità
futura.
4.3.1 Il framework Spring
Il Framework Spring è una piattaforma open source Java, inizialmente scritta da Rod
Johnson e rilasciata sotto licenza Apache 2.0 (nel Giugno 2003). Le funzionalità appar-
tenenti al core del Framework Spring possono essere usate per lo sviluppo di qualsiasi
tipo di applicazione Java; esistono poi estensioni apposite per creare Web Application. Il
target del framework è quello di rendere più semplice lo sviluppo di applicazione J2EE e
quello di usare e promuovere buone consuetudini di programmazione usando un modello
di programmazione basato sui POJO4.
Spring MVC
Spring MVC è un framework per realizzare applicazioni web basate sul paradigma ar-
chitetturale Model View Controller. Esso si occupa di mappare metodi e classi Java con
La semplicità di JSON ne ha decretato un rapido utilizzo specialmente nella programmazione in AJAX.Il suo uso tramite JavaScript è particolarmente semplice, infatti l’interprete è in grado di eseguirne il parsingtramite una semplice chiamata alla funzione eval(). Questo fatto lo ha reso velocemente molto popolare acausa della diffusione della programmazione in JavaScript nel mondo del Web.
4Con l’acronimo POJO, Plain Old Java Object, si usa enfatizzare l’utilizzo di oggetti Java discendentidiretti della classe Object.
55
Progettazione e Sviluppo di un Ambiente Distribuito per R
determinati url, di gestire differenti tipologie di “viste” restituite al client, di realizzare ap-
plicazioni internazionalizzate e di gestire i cosiddetti temi per personalizzare al massimo
l’esperienza utente.
Il pattern MVC
Per comprendere al meglio il framework è necessario introdurre il pattern teorico che esso
implementa ovvero il modello MVC (acronimo per Model View Controller).
Grazie all’adozione di questo modello architetturale, la logica dell’applicativo viene se-
parata ed organizzata secondo i criteri di seguito esposti:
• i Model (modelli), oggetti che si occupano di fornire l’accesso ai dati necessari alla
logica implementata nell’applicazione;
• le View (viste), classi specializzate nella creazione dell’interfaccia (non necessaria-
mente grafica);
• i Controller (controllori), contenitori di metodi e funzioni che, integrando le due
componenti precedenti, ricevendo gli input dell’utente, gestendo i modelli per la
ricerca dei dati e la creazione di viste da restituire all’utente, compongono la logica
dell’applicazione.
4.3.2 L’ Authentication controller
La logica responsabile dell’autenticazione di un client sul sistema distribuito è specificata
all’interno della classe AuthenticationController.
Grazie al framework Spring MVC, che fornisce un efficiente sistema per il routing delle
richieste verso gli oggetti controllori, la richiesta viene intercettata e direzionata al metodo
authenticateAction che procede, prima di ogni altra azione, alla verifica delle credenziali.
56
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 4.3.1: L’autentication controller
Nel caso in cui l’utente non sia già stato precedentemente riconosciuto, i valori di user-
name e password contenuti nella richiesta HTTP vengono confrontati con quelli presenti
nel database.
A riconoscimento avvenuto, il sistema provvede ad assegnare un codice identificativo
della connessione che, salvato nella tabella rest_session, permette di riconoscere il client
durante le richieste successive senza la necessità di trasmettere nuovamente le proprie
credenziali.
Il dialogo termina con la scrittura del codice identificativo creato all’interno della risposta
HTTP e la sua spedizione all’oggetto chiamante.
4.3.3 Lo ScriptExecutionController
La richiesta di esecuzione di un programma R viene intercettata dalla classe ScriptExecu-
tionController e reindirizzata al metodo execAction.
Come evidenziato in Fig 4.3.2, la richiesta di esecuzione è costituita da un blocco da-
57
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 4.3.2: Lo ScriptExecution controller
ti serializzato in JSON e, tra gli header HTTP, dal codice ottenuto durante la fase di
autenticazione.
La check dell’autenticazione è la prima operazione eseguita dal controllore. Il metodo
verifica che il codice identificativo della sessione sia presente nella tabella rest_session e
che il timestamp associato non sia più vecchio di 15 minuti.
Il processo prosegue con la deserializzazione dei valori passati in input, da cui viene
estratto anche il nome del programma R da eseguire, per permetterne l’esecuzione su una
nuova istanza della libreria Replica.
A computazione terminata, i valori di output attesi vengono prelevati dal workspace e
serializzati in una stringa JSON memorizzata nel pacchetto di risposta HTTP.
4.4 Lo schema relazionale
Oltre alle tabelle necessarie all’esecuzione di un programma R attraverso l’uso di Replica,
l’implementazione del servizio web estende lo schema in Fig. 3.2.3 introducendo una
58
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 4.4.1: Schema del database relazionale in appoggio al servizio web
serie di nuove tabelle necessarie alla gestione degli utenti e dei client connessi.
Gli utenti
La tabella users definisce gli utenti abilitati all’uso del web service e ne memorizza le
credenziali di accesso. Nel dettaglio:
id codice identificativo univoco dell’utente, normalmente gestito in automatico dal siste-
ma;
username nome utente;
password campo contenente la codifica della password secondo le specifiche della libre-
ria Spring Security e della classe StandardPasswordEncoder;
enabled può contenere il valore 0 se l’utente non è abilitato all’uso del servizio o 1 nel
caso contrario.
Le sessioni REST
Nonostante i servizi web di tipo REST si basino sul concetto di “assenza di stato”, per
permettere un più efficiente utilizzo del servizio qualora i programmi siano strutturati per
svolgere solo parzialmente la soluzione di un problema, e quindi ipotizzando un frequente
uso del metodo exec.action, il database ospitala tabella rest_session contenente lo storico
delle autenticazioni avvenute sul sistema e di seguito descritta:
id identificativo univoco della sessione, normalmente gestito in automatico dal sistema;
59
Progettazione e Sviluppo di un Ambiente Distribuito per R
created data e ora dell’avvenuta autenticazione;
keepalive data e ora della scadenza della sessione; ad ogni richiesta il sistema provvede
a mantenere questo campo aggiornato, evitando così la creazione di nuove entry per
sessioni già istanziate;
token campo contenente l’identificativo alfanumerico generato casualmente e associato
al momento dell’autenticazione.
4.5 Serializzazione dei parametri e dei risultati
Il processo di codifica e decodifica dei parametri in formato JSON è affidato alla libre-
ria Jackson, parte integrante del framework Spring. I metodi per la serializzazione e
deserializzazione sono pubblicati dal servizio ParameterService, un oggetto Java Bean
specializzato nella gestione dei parametri e disponibile a livello di istanza.
[{
"name": "variableName",
"type": "int[]",
"value": [1,1,1,2,3,3,3,4]
},{
"name": "secondVariableName",
"type": "string",
"value": "something"
}]
Figura 4.5.1: Esempio di stringa JSON per l’input di un programma R
4.5.1 I parametri in input
La stringa JSON in Fig. 4.5.1 mostra un esempio di codifica dei parametri in input accet-
tata dal web service. La struttura in radice è rappresentata da un array di oggetti JSON
costruiti secondo le seguenti specifiche:
name contiene il nome della variabile del workspace a cui si riferisce l’oggetto;
60
Progettazione e Sviluppo di un Ambiente Distribuito per R
{
"normality" : {
"type" : "double",
"value" : "1.0"
}
}
Figura 4.5.2: Esempio di serializzazione dell’output di un programma R
type per permettere una corretta interpretazione dei valori specificati, è necessario indi-
care in questo campo il tipo di variabile che si andrà a definire nel workspace; la
Tab. 4.1 elenca i differenti tipi di input supportati dal sistema;
value il valore da assegnare alla variabile
TIPO TIPO R SINTASSI JSONint integer 1
int[] integer[] [1,2]double double 0.123
double[] double[] [0.123,0.1234]string string “abc”
string[] string[] [“abc”,”def”]
Tabella 4.1: Tipi consentiti nella definizione dei parametri di input e output
4.5.2 Serializzazione dei risultati
La trasmissione dei risultati al programma chiamante avviene grazie alla serializzazione,
in formato JSON, delle variabili specificate come output dello script. Come si può osser-
vare dalla Fig. 4.5.2, la struttura utilizzata è simile a quella adottata per il passaggio dei
valori in ingresso. L’array di oggetti è sostituito da un unico JavaScript object compo-
sto da una serie di proprietà, ognuna corrispondente ad una delle variabili definite come
output dello script. I tipi consentiti sono quelli elencati in Tab. 4.1.
61
Capitolo 5
La console amministrativa
Nei capitoli precedenti si è sottolineato come la mancanza di un’interfaccia di gestione,
anche solo a livello di libreria, obblighi gli utenti del sistema ad intervenire manualmente
nella configurazione agendo sul database e sui singoli nodi. Per ovviare a questo incon-
veniente e allo stesso tempo mantenere un’architettura dei singoli componenti minimale,
si è progettata e sviluppata una apposita applicazione web: Replica Console.
5.1 L’interfaccia utente e le funzionalità fornite
Un importante metodo per realizzare sistemi semplici all’utilizzo e all’apprendimento è
renderli esplorabili [17]. Come mostrato in Fig. 5.1.1, il legame funzionalità-interfaccia
utente è stato consolidato organizzando le funzionalità in elenchi accessibili da specifiche
aree della pagina web.
La porzione superiore della pagina, organizzata attraverso l’utilizzo di tab pages, permette
la navigazione tra le due macro sezioni di Replica Console:
• il setup, che fornisce un rapido accesso alle configurazioni maggiormente soggette
a cambiamenti;
• il terminale di test, una console testuale da cui gli utenti del sistema possono testare
i programmi R a disposizione di Replica.
63
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.1.1: L’interfaccia utente suddivisa per aree di contenuto
5.1.1 Funzionalità di configurazione
L’area posta a sinistra della pagina di setup permette la navigazione delle funzionalità di
configurazione disponibili all’utente e in uso nel sistema:
• gestione degli script;
• gestione degli utenti;
• gestione dei nodi;
• gestione della configurazione di Replica Console.
5.1.2 La gestione degli script
Attraverso la gestione degli script viene permesso l’inserimento, la rimozione e la modi-
fica dei programmi R presenti nella base dati associata al sistema distribuito.
La funzionalità è accessibile dalla sezione “R Scripts” dell’interfaccia di setup, selezio-
nando, appunto, la voce script dal menù di sinistra.
Un elenco navigabile permette la selezione dei programmi R, mentre una serie di bottoni
alla base ne abilitano la rimozione o la creazione.
64
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.1.2: Modifica di un programma R
Figura 5.1.3: Modifica degli output di un programma R
L’editing avviene tramite il form mostrato in Fig. 5.1.2. Qui l’utente ha la possibilità di
variare nome e descrizione dello script e di inserirne il codice R associato.
La gestione dei valori di ritorno è invece accessibile aprendo il pannello output alla
base della finestra di modifica (Fig. 5.1.3). L’editing, abilitato unicamente in segui-
to all’assegnazione di un identificativo numerico allo script, avviene direttamente sulla
griglia.
65
Progettazione e Sviluppo di un Ambiente Distribuito per R
RUOLO DESCRIZIONE
ROLE_USER Accesso alla console di testROLE_SETUP Accesso alle funzionalità di configurazione del sistema distribuitoROLE_ADMIN Accesso alle funzionalità di configurazione di Replica Console
Tabella 5.1: Elenco dei ruoli utente disponibili
5.1.3 Gestione degli utenti e assegnazione dei ruoli
Per garantire un accesso riservato alle funzionalità pubblicate dalla Console, l’infrastrut-
tura utilizzata per la gestione degli utenti Replica Web Service è stata estesa aggiungendo
il supporto ai ruoli utente.
Grazie alla condivisione della base dati e, nello specifico, della tabella users, Repli-
ca Console è in grado di gestire, attraverso un’unica interfaccia, sia gli utenti abilitati
all’esclusivo utilizzo di Replica Web Service, sia quelli amministratori.
Per la gestione dei permessi è necessario assegnare uno o più ruoli elencati in Tab. 5.1.
Figura 5.1.4: Finestra di modifica utente
5.1.4 Gestione dei nodi
L’inserimento e la rimozione dei nodi, così come l’assegnazione e la variazione del peso
associato ai singoli componenti del sistema distribuito, è gestibile attraverso l’interfaccia
di gestione dei server mostrata in Fig 5.1.5.
66
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.1.5: Interfaccia per la gestione dei nodi del sistema distribuito
Figura 5.1.6: Il terminale
5.1.5 Il terminale di test
Accessibile tramite l’apposita tab Terminal, il terminale si presenta all’utente come una
console testuale in stile unix. Proprio alcune delle caratteristiche principali delle inter-
facce a linea di comando quali la composizione di funzioni e la sinteticità [14], unite alla
possibilità di integrare il parser JavaScript già presente nel browser, ha portato allo svilup-
po di un terminale non grafico. Comandi e funzioni, richiamabili solitamente attraverso la
compilazione di moduli web, sono stati sostituiti da comandi richiamabili da un ambiente
JavaScript appositamente strutturato per fornire un accesso rapido alle funzioni del web
service e in maniera del tutto analoga ad una implementazione reale.
67
Progettazione e Sviluppo di un Ambiente Distribuito per R
Comandi disponibili
help mostra i comandi disponibili;
replica.authenticate si autentica sul servizio web e ritorna l’identificativo di sessione
associato all’evento;
replica.execscript permette l’esecuzione di un programma R su di un servizio web Re-
plica;
5.2 L’implementazione lato server
Per semplificare l’implementazione ed il deploy, molti strati dell’architettura di Repli-
ca Console, così come molte tecnologie utilizzate, sono comuni a quelli adottati per lo
sviluppo degli altri componenti del sistema.
5.2.1 Il server applicativo
L’intera logica del server viene eseguita da una istanza di Apache Tomcat.
5.2.2 Le librerie e il framework Spring
Sviluppato secondo il paradigma del Model View Controller, anche Replica Console in-
corpora il framework Spring per la gestione del routing delle richieste e la separazione
fra logica, modello e presentazione. La connessione al database è gestita dall’estensione
Spring per la libreria Hibernate, anch’essa parte integrante del progetto.
5.2.3 La logica di controllo
La logica di controllo dei flussi di richieste è gestita dalle classi evidenziate nel diagramma
di Fig. 5.2.1.
68
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.2.1: Diagramma delle classi Replica Console per il controllo delle richieste
Per mantenere una separazione del codice sorgente a livello logico, ad ogni funzionalità
elencata nella Sez. 5.1 corrisponde un oggetto di tipo Controller, istanziato dal framework
Spring all’avvio del servizio.
I controller
Nonostante ogni controller sia progettato per svolgere una serie di operazioni specializzate
e diverse, grazie ad una architettura fortemente orientata agli oggetti è possibile evidenzia-
re i componenti e le classi comunemente coinvolte nell’elaborazione dell’informazione.
Questa struttura ricorrente, realizzata anche grazie alle funzionalità fornite dal framework
Spring, ha permesso di concentrarsi maggiormente sulla soluzione del problema piuttosto
che sull’implementazione dell’azione.
Come mostrato in Fig. 5.2.2, il pacchetto HTTP inviato dal browser contiene i dettagli
69
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.2.2: Struttura di un controller
della richiesta serializzati in JSON. La prima operazione effettuata dal controller è quin-
di la deserializzazione dei dati, che avviene grazie all’utilizzo dei metodi della libreria
GenericUtil.
Non appena disponibili, i parametri della richiesta sono utilizzati per processare l’azione.
Per permettere il riuso di metodi e funzioni, la logica è implementata da particolari oggetti
JavaBean denominati servizi, la cui particolarità è quella di essere allocati a livello di
istanza e quindi facilmente riutilizzabili.
Per la gestione della persistenza e l’interfacciamento con la base dati, necessaria per porta-
re a termine la maggior parte delle operazioni fornite da Replica Console, è stato utilizzato
il pattern DAO.
I Data Access Object, o classi di persistenza, forniscono i metodi per l’interrogazione e
la manipolazione delle classi di dominio associate allo schema relazionale. Nel dettaglio
è fornita l’implementazione delle funzionalità di base CRUD (Create, Read, Update e
Delete).
Completata l’operazione richiesta, il controllo passa al framework Spring che, prelevato il
valore di ritorno del metodo controllore, procede alla sua serializzazione, permettendone
70
Progettazione e Sviluppo di un Ambiente Distribuito per R
così l’inoltro al client.
5.3 Lo sviluppo dell’interfaccia utente
In un applicativo web come Replica Console, la progettazione dell’interfaccia utente deve
tenere conto di numerosi fattori, primo tra tutti la necessità di fornire un prodotto semplice
all’utilizzo e graficamente allineato agli standard attuali. Nonostante negli ultimi anni si
sia assistito alla diffusione di numerose tecnologie per lo sviluppo web lato client, la scelta
è ricaduta sull’adozione del framework JavaScript ExtJS, considerato lo stato dell’arte per
la creazione di applicativi web dinamici e conformi allo standard HTML5.
Il framework ExtJS
ExtJS è un framework JavaScript per lo sviluppo di applicazioni web interattive. Basato
sugli standard Ajax, DHTML e DOM, dalla versione 4, grazie all’adozione del paradig-
ma MVC, è in grado di garantire scalabilità, semplicità e flessibilità; qualità fino ad ora
riservate solitamente alla logica lato server.
5.3.1 Il modello architetturale
Negli applicativi web Java conformi al paradigma MVC, lo sviluppo della logica di pre-
sentazione è solitamente demandato alle Java Servlet Page, una tecnologia in grado di
fornire contenuti dinamici in formato HTML o XML.
Come mostrato nella Fig. 5.3.1, Replica Console utilizza le JSP unicamente come conte-
nitore per ospitare un’applicazione ExtJS, demandando a quest’ultima il compito di creare
e gestire l’intera interfaccia utente. L’oggetto Application è un particolare container della
libreria ExtJS che fornisce allo sviluppatore una serie di metodi e funzionalità utili al-
la definizione di un applicativo web istanziabile dall’interprete JavaScript del browser e
associabile ad una qualunque porzione di una pagina HTML.
71
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.3.1: Architettura dell’interfaccia utente
72
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.3.2: Organizzazione del codice sorgente dell’interfaccia utente
La differenza principale tra un’applicazione ExtJS e una qualunque applicazione web
implementata attraverso l’uso di HTML e JavaScript, è la totale assenza di codice HTML e
CSS. Tutti gli aspetti riguardanti la definizione della grafica sono gestiti dagli oggetti View
dell’applicazione: ad esempio per mostrare un bottone è necessario istanziarlo all’interno
di una view, assegnandogli parametri quali il testo dell’etichetta e la dimensione.
La logica di controllo è gestita da oggetti di tipo Controller in cui viene fornita l’im-
plementazione delle funzioni JavaScript associate agli eventi dei componenti istanziati
nelle viste. E’ compito dell’oggetto controller iniziare la comunicazione con il server ed
elaborarne le risposte aggiornando, dove necessario, la grafica della view.
Nel caso di controlli web (oggetti dinamici per l’input e output dei dati) orientati alla ge-
stione e visualizzazione di dataset, il framework fornisce uno strato per la manipolazione
dei dati costituito da modelli, entità rappresentati i dati, e data store, collezioni di modelli.
Nella Fig. 5.3.2 è possibile vedere la porzione del file system contenente l’applicativo
ExtJS responsabile della visualizzazione e gestione dell’intera interfaccia grafica utente.
73
Progettazione e Sviluppo di un Ambiente Distribuito per R
Il file app-setup.js, richiamato dalla JSP, istanzia i vari controller contenuti nell’omonima
directory, i quali a loro volta, se necessario, provvedono all’allocazione di viste, modelli
e store.
5.3.2 Il terminale
Nell’analisi dello sviluppo dell’interfaccia grafica è necessario fornire una descrizione
separata per quello che è il terminale di test fornito a corredo dell’applicazione Repli-
ca Console. L’oggetto, pur essendo inserito all’interno dell’applicativo ExtJS, sfrutta le
funzionalità di una libreria JavaScript diversa, jQuery.
La libreria jQuery
jQuery è una libreria di funzioni JavaScript, browser-indipendente, per le applicazioni
web, che si propone come obiettivo quello di semplificare la programmazione lato client
delle pagine HTML. Il framework fornisce metodi e funzioni per gestire al meglio aspetti
grafici e strutturali come posizione di elementi, effetto di click su immagini, manipolazio-
ne del Document Object Model e altro ancora, mantenendo la compatibilità tra browser
diversi e standardizzando gli oggetti messi a disposizione dall’interprete JavaScript del
browser.
L’architettura
Analogamente al resto dell’interfaccia utente, anche il terminale è un oggetto JavaScript
generato da una apposita JSP. La console si presenta all’utente come una pagina web a
sfondo nero in grado di ospitare una serie di caratteri costituenti un comando.
Come mostrato in Fig. 5.3.3 il comando, una volta raccolto dall’interprete, può essere
elaborato in due modi differenti: come comando console o come istruzione JavaScript.
74
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 5.3.3: Funzionamento del terminale
A differenza dei comandi nativi della console, riservati esclusivamente a funzioni di utilità
quali l’aiuto in linea, le istruzioni JavaScript permettono di sfruttare appieno l’interprete
del browser permettendo l’allocazione di oggetti e la chiamata di funzioni.
L’oggetto “replica”
Specificato internamente al file bin.js, un contenitore di classi JavaScript a disposizione
dell’utente per il test e la diagnostica del sistema distribuito, replica è l’oggetto che per-
mette di testare i metodi pubblicati dal web service. Istanziato durante l’inizializzazione
della console, l’oggetto replica pubblica le funzioni authenticate (Fig. 5.3.4) ed exec-
script, utilizzabili, rispettivamente, per l’autenticazione e l’esecuzione di programmi R
attraverso il terminale di Replica Console.
75
Progettazione e Sviluppo di un Ambiente Distribuito per R
authenticate: function(host , username , password) {
var me = this;
$.ajax({
url: host + '/authenticate.action?username=' + username + '&password=' + password ,
dataType : 'json',
xhrFields: {
withCredentials: true
},
statusCode: {
404: function () {
me.echo('Host not found');
},
500: function () {
me.echo('Server error');
}
}
}). done(function(data) {
if (data.success) {
me.echo('Server answer: ' + data.message );
me.echo('Variable <span class="gray">authtoken </span > is ' +
data.data['SpcRest -Auth -Token']);
} else {
me.echo('Server answer: ' + data.message );
}
this.authtoken = data.data['SpcRest -Auth -Token '];
});
return '';
}
Figura 5.3.4: Il metodo replica.authenticate
76
Capitolo 6
Un esempio di utilizzo: test di verifica di
normalità
Considerato che la quantità di memoria disponibile per l’allocazione del workspace e la
complessità degli algoritmi possono influenzare la corretta esecuzione del codice fino an-
che a impedirne il raggiungimento del risultato, può essere utile analizzare una soluzione
che preveda la suddivisione del problema su più istanze di R in parallelo.
6.1 Il problema: test di verifica di normalità
La distribuzione normale è considerata il caso base delle distribuzioni di probabilità con-
tinue a causa del suo ruolo nel teorema del limite centrale. Più specificamente, assumendo
certe condizioni, la somma di n variabili casuali con media e varianza finite tende a una
distribuzione normale al tendere di n all’infinito. Grazie a questo teorema, la distribuzione
normale si incontra spesso nelle applicazioni pratiche, venendo usata in statistica e nelle
scienze naturali e sociali come un semplice modello per fenomeni complessi.
77
Progettazione e Sviluppo di un Ambiente Distribuito per R
6.1.1 Il test di Anderson-Darling
Nonostante i test a disposizione siano molto numerosi, e la maggior parte di questi siano
disponibili nei vari pacchetti di R, l’implementazione di questo esempio si basa sul test di
Anderson-Darling (dai suoi autori Theodore Wilbur Anderson e Donald A. Darling che lo
descrissero nel 1952). Spesso utilizzato per il controllo qualità attraverso la metodologia
dello Statistical Process Control1, è un test di verifica d’ipotesi utilizzato in statistica per
verificare se un campione di valori può essere generato da una determinata variabile ca-
suale. Quando applicato per verificare l’appartenenza ad una variabile casuale gaussiana,
diventa uno degli strumenti statistici più potenti per individuare la non corrispondenza
con la gaussiana.
6.1.2 Un’implementazione in R
Disponibile nella libreria nortest (che accoglie numerosi test di normalità), la funzione
ad.test(x), dato un vettore contenente i dati da analizzare, restituisce un valore p (livello
di significatività osservato) che permette o meno di accettare l’ipotesi di normalità.
> library (nortest)
> x <- rnorm (200, 10, 2)
> ad.test(x)
Anderson -Darling normality test
data: x
A = 0.4915 , p-value = 0.2167
Figura 6.1.1: Implementazione del test di Anderson-Darlin in linguaggio R
L’esempio di Fig. 6.1.1 mostra le righe di codice R necessarie alla generazione di un
dataset di 200 elementi (composto da valori normalmente distribuiti aventi media=10 e
deviazione standard=2) e al suo test di normalità.
Come sottolineato dalla Tab. 6.1, essendo il valore-p ritornato (0,2167) maggiore di 0,05,
si può concludere che l’insieme di dati analizzati è normalmente distribuito.
1Una metodologia per il controllo della qualità basata su funzioni statistiche.
78
Progettazione e Sviluppo di un Ambiente Distribuito per R
IPOTESI NULLA (H0) I DATI SEGUONO UNA DISTRIBUZIONE NORMALE
Accetto H0 p-value > 0,05Rifiuto H0 p-value <= 0,05
Tabella 6.1: Risultato test Anderson-Darling
6.1.3 La dimensione del dataset
La dimensione del dataset è direttamente proporzionale alla quantità di memoria e al
tempo necessari all’esecuzione del test. Ad esempio l’elaborazione delle poche centinaia
di valori contenuti nel vettore x in Fig.6.1.1 richiedono una frazione di secondo e pochi
kilobyte di memoria.
6.2 Test di normalità distribuito
Nel caso in cui si debba eseguire il test di normalità su popolazioni molto grandi2, i
tempi di elaborazione richiesti e i limiti imposti dall’architettura di R, che non permette
l’allocazione di variabili di dimensione superiore alla quantità di memoria disponibile nel
sistema, hanno portato alla progettazione di un algoritmo adatto all’esecuzione parallela
del test di Anderson-Darling su di un sistema distribuito quale Replica.
Per semplificare l’implementazione e limitare lo scambio dati client-server ai soli parame-
tri, l’algoritmo, definito in Fig. 6.2.1, ha come prerequisiti l’adozione di una base dati cen-
tralizzata su cui vi è memorizzato il dataset e l’utilizzo di un numero intero (progressivo
e senza interruzioni) come chiave della tabella.
A meno che non siano conosciuti a priori, l’algoritmo inizia con l’estrazione del valore
chiave (ID) minimo e massimo associato al set di dati. Il risultato viene utilizzato per
popolare una tabella di supporto temporanea, solitamente creata in memoria, che contiene
un insieme di valori interi casuali compresi tra il minimo e massimo dell’insieme delle
chiavi.
2La cui dimensione è maggiore di 107
79
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 6.2.1: Diagramma funzionale: test di normalità distribuito
80
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 6.3.1: Componenti utilizzati per l’implementazione del test di normalità distribuito
Stabilita la dimensione k del sottoinsieme su cui effettuare il test e il numero di osserva-
zioni s da effettuare, per evitare che la distribuzione dei campioni sia stata distorta a causa
dell’effetto randomico del campionamento, si procede con l’esecuzione, in parallelo, del
test sugli s sottoinsiemi di k elementi casuali. Terminati i processi e raccolti i livelli di
significatività osservati, se il risultato viene confermato per almeno il 95% dei casi allora
vi è una probabilità del 95% che i risultati siano normalmente distribuiti.
6.3 Implementazione
Prima di procedere con la descrizione dei passi necessari all’implementazione dell’algo-
ritmo, è utile fornire alcuni dettagli sulla configurazione utilizzata durante il test.
Come evidenziato in Fig. 6.3.1, il sistema utilizza tre nodi distinti. Un database MySQL
ospita il dataset da analizzare e le tabelle di supporto create durante la fase iniziale del
test. Le frecce esterne alla superficie tratteggiata indicano collegamenti Gigabit Ethernet.
L’intera gestione dell’array è demandata ad un’unica istanza di Replica WebService la
cui configurazione è ospitata all’interno di un apposito server MySQL. Tutti i test sono
effettuati utilizzando un browser connesso al terminale della console di gestione.
81
Progettazione e Sviluppo di un Ambiente Distribuito per R
CREATE TABLE tmp_rand_numbers (
number int (11) NOT NULL ,
KEY IDX_number (number)
);
DELIMITER $$
CREATE PROCEDURE InsertRand(IN NumRows INT , IN MinVal INT , IN MaxVal INT)
BEGIN
DECLARE i INT;
SET i = 1;
START TRANSACTION;
WHILE i <= NumRows DO
INSERT INTO tmp_rand_numbers VALUES (MinVal + CEIL(RAND() * (MaxVal - MinVal )));
SET i = i + 1;
END WHILE;
COMMIT;
END$$
DELIMITER;
CALL InsertRand (100000 , 1022507 , 51022506);
SELECT * from tmp_rand_numbers
LEFT JOIN dataset ON tmp_rand_numbers.number = dataset.id
Figura 6.3.2: Codice SQL per la selezione di 100.000 valori casuali
6.3.1 Il dataset
Non è difficile procedere alla selezione casuale di un certo numero di record appartenenti
ad una tabella: la funzione random è ormai presente in tutti i più utilizzati RDBMS, e il
suo utilizzo all’interno di una SELECT può portare a termine il compito con pochissime
istruzioni di codice SQL. Tuttavia, considerata la dimensione della base dati utilizzata per
il test, composta da 50.000.000 di record, la selezione basata su condizione randomica
porta a tempi di elaborazione dell’ordine di decine di secondi (anche su sistemi molto
performanti).
Come mostrato in Fig. 6.3.2, per la selezione, in maniera efficiente, di un insieme ar-
bitrario di valori casuali, si è proceduto come prima cosa alla creazione di una tabella
temporanea riempita con valori casuali generati dalla procedura InsertRand. La selezione
dei valori avviene incrociando, con una clausola di JOIN, i valori generati con le chiavi
del dataset.
82
Progettazione e Sviluppo di un Ambiente Distribuito per R
drv <- dbDriver('MySQL')
con <- dbConnect(drv , username='root', host='10.77.5.8 ', port=as.numeric('3306'),
dbname='test', password='')
rs <- dbSendQuery(con , paste('SELECT value FROM tmp_rand_numbers
LEFT JOIN norm ON tmp_rand_numbers.number = norm.id
LIMIT', start , ',', limit ));
data <- fetch(rs,n=-1)
x <- data$value
n <- ad.test(x)
dbDisconnect(con)
normality <- if (n[2] >= 0.05) 1 else 0
Figura 6.3.3: Programma R per il calcolo del test di Anderson-Darling su di una partizionedi dati prelevata da un database MySQL
6.3.2 La funzione R
L’esecuzione del test di Anderson-Darling è demandata al programma R in Fig. 6.3.3 che,
prelevata una porzione casuale del dataset, ne verifica la normalità ritornando il valore
intero 1 quando l’ipotesi è accettata e 0 nel caso contrario.
Per l’accesso alla base dati si è utilizzato il pacchetto RMySQL mentre, per il calcolo della
funzione di test di normalità, il pacchetto nortest. In previsione di un utilizzo prevalen-
temente concorrente, per ridurre il tempo di esecuzione dello script, entrambe le librerie
vengono caricate nel workspace di Rserve durante l’avvio del servizio. Le direttive library
non sono quindi presenti nel listato di Fig. 6.3.3 perché già inserite nel file source.R
La selezione del sottoinsieme da analizzare è affidata alla clausola LIMIT della query
SQL istanziata dalla funzione dbSendQuery. Gli oggetti R start e limit, sono gli unici
valori in input richiesti dal programma. Attraverso la selezione di range sempre diversi, è
possibile ripartire l’analisi su più chiamate indipendenti.
6.3.3 Il codice JavaScript
La logica responsabile dell’istanziamento degli oggetti Replica (attraverso le chiamate al
web service) e della ripartizione del test sul sistema distribuito è demandata al programma
JavaScript listato in Fig. 6.3.4.
Ottenuto, attraverso la chiamata del metodo replica.authenticate, l’accesso al sistema e
istanziato il vettore che ospiterà i risultati del test, l’esecuzione continua con un ciclo for
83
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 6.3.4: Distribuzione dei valori del dataset
replica.authenticate(localhost ,"user","pass");
var results = [];
var s = 60, k = 5000, p = 0;
for (i = 0; i < s; i++) {
input = [{
"name":"start", "type":"int", "value":i*k
},{
"name":"limit", "type":"int", "value":(i+1)*k
}];
replica.execscript(localhost ,"normality",replica.authtoken ,input ,
function(data) {
results.push(data.data.normality.value);
}
);
}
Figura 6.3.5: Programma JavaScript per il calcolo del test di normalità attraverso ilservizio web Replica
di lunghezza s che ha il compito di eseguire il programma R “normality” su partizioni,
diverse e continue del dataset randomizzato, aventi dimensione k. Data l’asincronicità del-
le chiamate AJAX, il risultato delle singole elaborazioni, non appena disponibile, viene
infine processato dalla funzione di callback specificata tra i parametri del metodo repli-
ca.execscript. I risultati, inseriti in un array di numeri interi, possono essere analizzati e
utilizzati per stabilire una percentuale di probabilità.
84
Progettazione e Sviluppo di un Ambiente Distribuito per R
6.3.4 Configurazione del browser
Le specifiche del protocollo HTTP/1.1 suggeriscono l’utilizzo di non più di due connes-
sioni simultanee verso uno stesso dominio[13]. Nonostante i limiti imposti dai normali
browser siano notevolmente più ampi (normalmente da 6 a 8 accessi contemporanei), per
permette un utilizzo delle risorse in maniera quanto più possibile concorrente, è stato ne-
cessario innalzarne il valore. La procedura, permessa solo nei browser in cui il numero
non sia specificato a livello di codice sorgente3, e l’hardware a disposizione per i test4,
hanno permesso l’allocazione di circa 20 chiamate contemporanee.
6.4 Risultato dell’analisi
Il test di 60 campioni di 5000 elementi casuali prelevati da un dataset di 50.000.000 di
record ha confermato, come mostrato dalla Fig. 6.4.1, l’ipotesi di normalità per il 96.6%
delle volte. Considerando che il test di Anderson-Darling effettuato sull’intero dataset
(Fig. 6.3.4), precedentemente generato dal comando rnorm di R, restituisce un p-value di
0,5585, il risultato ottenuto dall’algoritmo proposto risulta attendibile.
3Firefox dalla versione 17, Opera dalla versione 10.4Workstation Linux con processore Intel i7-4700HQ, 16GB di memoria RAM e disco SSD.
85
Progettazione e Sviluppo di un Ambiente Distribuito per R
Figura 6.4.1: Output su terminale con risultato del test e console di debug del browser convisualizzazione delle chiamate AJAX e risposta
6.4.1 Prestazioni e utilizzo della memoria
Nonostante le specifiche architetturali imposte dal browser, in particolare l’uso di un sin-
golo thread per la gestione delle chiamate AJAX, abbiano limitato l’utilizzo in concorren-
za dell’ambiente, come è possibile osservare nella Tab. 6.2, le prestazioni e il consumo
di memoria ottenuti dal sistema distribuito risultano migliori rispetto all’esecuzione del
processo su di una singola istanza di R.
REPLICA WEB SERVICE RTempo necessario al calcolo del test di normalità 26813ms 78844ms
Memoria allocata da R ~30MB per nodo ~600MB
Tabella 6.2: Confronto dei consumi di memoria e tempi di esecuzione del test diAnderson-Darling in esecuzione su Replica Web Service e R
86
Capitolo 7
Conclusioni e sviluppi futuri
Nata come libreria per fornire supporto al calcolo statistico in software per il controllo
qualità, Replica si è evoluta fino a diventare un prodotto completo e scalabile.
Soprattutto la diffusione di applicativi web e la potenziale integrazione dell’ambiente R
all’interno di sistemi mobili (quali smartphone e tablet), ha incentivato lo studio e l’im-
plementazione di un’architettura indipendente da linguaggi, sistemi operativi e hardware.
Inoltre, le funzionalità a disposizione dell’ambiente R, unite alla flessibilità di JavaScript,
aprono possibilità pressoché infinite.
Il codice sorgente di Replica è disponibile, con un semplice comando git clone, all’indi-
rizzo https://gitlab.com/codref/replica
La scelta di distribuire il software in licenza GNU GPL permette di adottare il sistema
distribuito come alternativa a costosi prodotti commerciali, favorendo quindi lo sviluppo
di progetti con risorse economiche limitate.
Miglioramenti e progetti futuri
Sarebbe un errore definire Replica un progetto “completato”. Nonostante le funzionalità
introdotte siano sufficientemente stabili da essere utilizzate tuttora in diversi prodotti, è
87
Progettazione e Sviluppo di un Ambiente Distribuito per R
bene definire alcune aree in cui l’implementazione può essere migliorata o integrata con
nuove funzionalità.
Gestione centralizzata dei nodi
La gestione dei nodi, sia come insieme sia come entità singola, è uno dei primi miglio-
ramenti necessari. Al crescere del cluster la complessità della gestione dell’intero siste-
ma aumenta, richiedendo lo sviluppo di automatismi che permettano la configurazione
speculare delle singole istanze di Rserve e il loro monitoring.
Estensione del supporto ai tipi nativi di R
Al di fuori della libreria Replica, il limitato supporto ai tipi nativi di R aumenta la com-
plessità degli script, costringendo l’utente a separare i valori manualmente utilizzando
le funzionalità di gestione dell’output. L’estensione e l’introduzione di nuovi metodi re-
sponsabili della serializzazione degli oggetti REXP in JSON risolverebbe efficacemente
il problema, semplificando la gestione degli script.
Aggiunta di metodi per l’esecuzione di programmi R
Come definito nel Cap. 4, l’esecuzione di programmi R attraverso l’utilizzo del Web
Service è limitata ad una singola connessione che viene chiusa non appena i risultati siano
stati prelevati dal workspace. Il modello di esecuzione può essere migliorato fornendo la
possibilità all’utente di salvare il workspace e di richiamarlo durante l’istanziamento di
una nuova richiesta. Questo permetterebbe di mantenere l’ambiente bilanciato (evitando
chiamate successive allo stesso nodo e limitando lo scambio dati client-server) anche in
circostanze in cui vi sia la necessità di implementare algoritmi complessi che richiedano
la frammentazione della logica su più procedure.
88
Bibliografia
[1] Web Services Architecture, . Disponibile all’indirizzo: http://www.w3.org/
TR/ws-arch/.
[2] CORS Enabled. W3C Wiki, . Disponibile all’indirizzo: http://www.w3.org/
wiki/CORS_Enabled#For_Apache.
[3] TIOBE Index, February . Disponibile all’indirizzo: http://www.tiobe.com/
index.php/content/paperinfo/tpci/index.html.
[4] S.S. Apte ABHIJIT A. RAJGURU. A Comparative Performance Analysis of Load Ba-
lancing Algorithms in Distributed System using Qualitative Parameters. Internatio-
nal Journal of Adhesion and AdhesivesRecent Technology and Engineering
(IJRTE), .
[5] Enrico Melis Gaetano Santucci ANTONIO MASSARI, Massimo Mecella. Ar-
chitetture dei sistemi distribuiti, chapter 1, pages 1–41. Franco Angeli,
.
[6] Jeffrey Horner B. W. LEWIS. HTML 5 Websocket Interface for R. .
[7] Jeff BANFIELD. Rweb:Web-based Statistical Analysis. Journal of Statistical
Software, . Disponibile all’indirizzo: http://www.jstatsoft.org/v04/
i01.
[8] Roberto BOGGIANI. Introduzione ad R. .
89
Progettazione e Sviluppo di un Ambiente Distribuito per R
[9] George F. COULOURIS and Jean DOLLIMORE. Distributed Systems: Concepts and
Design. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, .
[10] Michael J. CRAWLEY. The R Book. Wiley, .
[11] Anthony T. Chronopoulos DANIEL GROSU. Noncooperative load balancing in
distributed systems. Jorunal of parallel and distributed computing, .
[12] R DOCUMENTATION. The R Base Package, . Disponibile all’in-
dirizzo: https://stat.ethz.ch/R-manual/R-devel/library/base/html/
base-package.html.
[13] et al. FIELDING. Hypertext Transfer Protocol - HTTP/1.1. The Internet Society,
.
[14] Mark KAMPE. Guidelines for Command Line Interface Design. Pomona Colle-
ge, Seminar on Big Software, . Disponibile all’indirizzo: http://www.cs.
pomona.edu/classes/cs181f/supp/cli.html.
[15] Michael LUNDHOLM. Working with R in batch mode: Some notes for beginners.
.
[16] Julia Kodysh Rob Schonberger Hyunyoung Choi & Sanjiv Kumar MATT MOHEBBI,
Dan Vanderkam. Google Correlate Whitepaper. .
[17] Donald A. NORMAN. The Design of Everyday Things. Basic Books, .
[18] Tim O’REILLY. Programming Language Trends. O’Reilly Radar,
. Disponibile all’indirizzo: http://radar.oreilly.com/2006/08/
programming-language-trends.html.
[19] Andrea PINAZZI. RESTful Web Service. .
[20] Vito RICCI. R: un ambiente opensource per l’analisi statistica dei dati. .
90
Progettazione e Sviluppo di un Ambiente Distribuito per R
[21] Joseph B. RICKERT. R for Web-Services with RevoDeployR. Revolution Analytics,
.
[22] Andrew S. TANENBAUM and Maarten van STEEN. Distributed Systems: Principles
and Paradigms (2Nd Edition). Prentice-Hall, Inc., .
[23] R Development Core TEAM. Writing R Extensions. .
[24] Simon URBANEK. A Fast Way to Provide R Functionality to Applications. .
[25] Simon URBANEK. FastRWeb: Fast Interactive Web Framework for Data Mining
Using R. AT&T Labs - Statistics Research, .
[26] Anne VAN KESTEREN. Cross-Origin Resource Sharing. W3C Recommendation,
. Disponibile all’indirizzo: http://www.w3.org/TR/cors/.
91