progettazione e sviluppo di un ambiente distribuito per r · 1.3.1 che cos’è r ... l’idea di...

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


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


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


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


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


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


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


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


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


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


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


• 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


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


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


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


> 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


> ?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


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


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


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


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


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


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


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


# 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


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


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


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


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


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


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


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


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


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


Figura 2.2.2: Schema del funzionamento di Replica Web Sevice

33


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


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


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


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


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


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


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


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


Figura 3.2.2: Diagramma della classe REngine

44


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


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


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


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


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


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


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


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


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


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


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


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


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


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


{

"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


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


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


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


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


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


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


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


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


Figura 5.3.1: Architettura dell’interfaccia utente

72


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


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


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


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


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


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


Figura 6.2.1: Diagramma funzionale: test di normalità distribuito

80


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


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


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


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


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


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


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

http://www.w3.org/TR/ws-arch/

http://www.w3.org/TR/ws-arch/

http://www.w3.org/wiki/CORS_Enabled#For_Apache

http://www.w3.org/wiki/CORS_Enabled#For_Apache

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://www.jstatsoft.org/v04/i01

http://www.jstatsoft.org/v04/i01


[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

https://stat.ethz.ch/R-manual/R-devel/library/base/html/base-package.html

https://stat.ethz.ch/R-manual/R-devel/library/base/html/base-package.html

http://www.cs.pomona.edu/classes/cs181f/supp/cli.html

http://www.cs.pomona.edu/classes/cs181f/supp/cli.html

http://radar.oreilly.com/2006/08/programming-language-trends.html

http://radar.oreilly.com/2006/08/programming-language-trends.html


[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

http://www.w3.org/TR/cors/

progettazione e sviluppo di un ambiente distribuito per r · 1.3.1 che cos’è r ... l’idea di...

Documents