Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea
Realizzazione di uno strumento
web-based
based per la simulazione remota di
reti di sensori senza filo
Anno Accademico 2009/2010
relatore
Ch.mo prof. Marcello Cinque
correlatore
ing. Catello Di Martino
candidato
Luigi, Paolo Rossi
matr. 534 000 308
A mio padre e mia madre
Non aetate verum ingenio apiscitur sapientia.
Indice
Introduzione
4
Capitolo 1. Wireless Sensor Network: Modellazione e Simulazione
1.1
Wireless Sensor Networks: Reti di Sensori senza filo
1.2
Progettare e Simulare una WSN
1.3
Il Tool Failure Model WSN Generator
1.3.1
Il simulatore Mobius
1.3.2
La topologia della rete
1.4
Motivazioni del remoting nella simulazione di WSN
7
7
11
19
21
22
24
Capitolo 2. Analisi dei Requisiti e Progettazione
2.1
Web Model WSN Generator: concetti chiave
2.2
Casi d’uso
2.3
Diminuire l’accoppiamento
2.3.1
La classe AmbientVar
2.3.2
Logging
27
27
31
33
35
36
Capitolo 3. Tecnologie e Strumenti per le Rich Internet Applications
3.1
Le RIA e metriche di valutazione
3.1.1
AJAX e JavaScript
3.1.2
Caratteristiche e metriche di valutazione dei framework
3.2
Java Server Pages e IceFaces
3.3
Openlaszlo
3.4
Adobe Flex
3.5
Echo 3
3.6
Google Web Toolkit
3.7
Apache Click
38
38
40
43
44
48
50
52
54
57
Capitolo 4. ZK Framework
4.1
Direct RIA: cos’è ZK Framework
4.2
Caratteristiche principali di ZK Framework
4.3
Integrazione con Java: il funzionamento di ZK Framework
4.3.1
Framework Server-Centrico
Server
e Client-Centrico
4.4
Estensibilità: MVC, Spring, Hibernate ed Integrazione
4.4.1
Il Pattern MVC con ZK
4.4.2
Spring con ZK
4.4.3
Hibernate con ZK
59
59
61
62
65
67
67
71
73
II
4.4.4
Integrare linguaggi in ZK
4.5
Qualità del supporto: ZK Forge e case studies
4.6
Curva di apprendimento: programming skills e linguaggio ZUML
ZUML
4.7
Strumenti di supporto: i tool di ZK
4.8
Costi di sviluppo: le versioni disponibili
Capitolo 5. Implementazione del tool
5.1
Pattern MVC e struttura della RIA
5.2
Le classi controller
5.3
Classi di utilità del tool web-based
web
5.4
La view ed i file ZUL
5.5
Il Disegno della Topologia: draw2d
5.6
Esempi di funzionamento
75
76
77
78
81
82
82
84
85
86
88
91
Conclusioni
Bibliografia
Sitografia
95
97
98
III
Introduzione
I recenti sviluppi nel campo delle reti di sensori senza filo hanno ampliato lo spettro delle
loro possibili applicazioni, l'efficienza di monitoraggio e i loro costi di sviluppo e di
produzione.
Se da una parte tale progresso ha portato a dei risultati sicuramente ottimali riguardo la
loro applicazione concreta nel settore delle reti wireless, d'altro canto non può non essere
osservato che tale procedimento innovativo ha condotto ad un diverso approccio nella
progettazione, modellazione e simulazione delle Wireless Sensor Networks. Ciò in ragione
della difficoltà di gestire un numero elevato di nodi sensore, ed inoltre, nei costi in termini
economici e di tempo per testare in maniera pratica il funzionamento di questi
microsistemi al fine di valutarne l'efficienza della trasmissione, l'affidabilità e la tolleranza
ai guasti.
In ragione di quanto appena affermato nella prassi applicativa delle Wireless Sensor
network (WSN), si è posta l'esigenza della modellazione del sistema da implementare e
della simulazione dello stesso al fine di valutare i risultati ottenuti e correggere le scelte
effettuate riguardo la loro progettazione nelle varie modalità di utilizzo.
In tal senso è stata diretta l'attività del laboratorio Mobilab del Dipertimento di Informatica
e Sistemistica, il quale ha apportato un notevole contributo sia nell'approccio della
modellazione e simulazione dei sistemi WSN, sia nell'implementazione di framework e
strumenti software.
Nel procedere a tale attività il suddetto laboratorio ha adottato un metodo che si basa sulla
4
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
necessità di valutare a priori l’affidabilità dei sistemi, ricorrendo a modelli che possano
rappresentare adeguatamente le caratteristiche rilevanti del sistema stesso e a metriche e
tecniche di valutazione dell’affidabilità. In seguito tale attività si è concretizzata
nell'implementazione di un tool per la generazione automatica di modelli di fallimento.
Nell'ambito di tale lavoro sono emerse delle problematiche riguardo agli utilizzi di questo
strumento software con i framework di sviluppo WSN che sono stati progettati e sviluppati
dal Mobilab, poiché tali applicazioni richiedono notevoli risorse di calcolo nonché
determinano difficoltà in ordine alla configurazione dei software e distribuzione degli
stessi agli utenti finali.
E' nata, pertanto, l'esigenza di convogliare questi strumenti ed in particolare il tool di
generazione automatica dei modelli di fallimento, in un ambiente operativo che abbia
determinate caratteristiche: immediata disponibilità, estensibilità, facile manutenibilità,
sicurezza dei dati, minore carico computazionale, riduzione costi di gestione e
accessibilità.
Si è resa, inoltre, l'esigenza di associare alle suddette caratteristiche una funzionalità che
permetta allo sviluppatore WSN di riprodurre graficamente la topologia della rete da
modellare e simulare senza l'utilizzo di ulteriori strumenti software.
Le suddette caratteristiche hanno portato alla realizzazione di uno strumento web-based
per la simulazione e modellazione remota di reti di sensori senza filo che è oggetto di
trattazione del seguente lavoro di tesi.
Al fine di pervenire alla realizzazione di tale strumento sono state effettuate delle ricerche
sulle tecnologie più diffuse per la realizzazione di applicazioni web che presentano più
elementi di somiglianza in ordine al loro comportamento e alla visualizzazione degli
applicativi desktop tradizionali, ovvero più simili non ad una web application tradizionale
ma ad una RIA (Rich Internet Application) al fine di rendere più agevole l'utilizzo dello
stesso nei confronti dell'utente finale.
Al fine di addivenire a tale risultato si è reso necessario strutturare tale lavoro di tesi nel
seguente modo: il Cap. 1 è dedicato ad una panoramica delle wireless sensor network,
delle motivazioni che portano al remoting nella simulazione di WSN ed introduce il lettore
5
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
al dominio del problema. La progettazione e le scelte principali che sono state effettuate in
ordine all'implementazione del suddetto strumento software sono poste ad oggetto del
Cap. 2, nel quale contemporaneamente si procede alla analisi dei suoi requisiti. La
progettazione della applicazione web procede nel Cap. 3, attraverso una panoramica delle
tecnologie più diffuse per lo sviluppo delle RIA alla stregua delle seguenti metriche di
valutazione: integrazione con Java, estensibilità, qualità del supporto, curva di
apprendimento, strumenti di supporto e costi di sviluppo. Il Cap. 4 è dedicato al
framework ZK procedendo allo studio delle sue caratteristiche, del suo funzionamento e
delle sue potenzialità applicative sfruttate in combinazione con il tool web-based
implementato. Tale iter progettuale si concretizza nel Cap. 5, il quale è completamente
dedicato alla implementazione del tool, nonché all’esposizione della funzionalità disegno
della topologia della WSN e su come si è utilizzato il framework per realizzarla.
6
Capitolo 1
Wireless Sensor Network: Modellazione e Simulazione
1.1 Wireless Sensor Networks: Reti di Sensori senza filo
I recenti progressi tecnologici nei sistemi MEMS (Micro Electro Mechanical System),
nelle comunicazioni wireless e nell'elettronica digitale hanno permesso lo sviluppo di
piccoli apparecchi a bassa potenza dai costi contenuti, multifunzionali e capaci di
comunicare tra loro tramite tecnologia wireless a raggio limitato. Questi piccoli
apparecchi, chiamati nodi sensori, sono formati da componenti in grado di rilevare
grandezze fisiche (sensori di posizione, temperatura, umidità ecc.), di elaborare dati e di
comunicare tra loro. Un sensore è comunemente definito come un particolare trasduttore
che si trova in diretta interazione con il sistema misurato.
Una rete di sensori (detta anche sensor network) è un insieme di sensori disposti in
prossimità oppure all'interno del fenomeno da osservare. Questi piccoli dispositivi sono
prodotti e distribuiti in massa, hanno un costo di produzione trascurabile e sono
caratterizzati da dimensioni e pesi molto ridotti. Ogni sensore ha una riserva d'energia
limitata e non rinnovabile e, una volta messo in opera, deve lavorare autonomamente; per
questo motivo tali dispositivi devono mantenere costantemente i consumi molto bassi, in
modo da avere un maggior ciclo di vita. Per ottenere la maggior quantità possibile di dati
occorre effettuare una massiccia distribuzione di sensori (nell'ordine delle migliaia o
decine di migliaia) in modo da avere una alta densità (fino a 20 nodi/m3) e far sì che i nodi
siano tutti vicini tra loro, condizione necessaria affinché possano comunicare.
7
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
Fig. 1.1 – un esempio di Wireless Sensor Network – monitoraggio incendi
Una delle più comuni applicazioni in cui è possibile far uso di una rete di sensori consiste
nel monitoraggio di ambienti fisici come il traffico in una grande città oppure dati rilevati
da un'area disastrata da un terremoto.
I nodi sensore all'interno di una rete hanno la possibilità di collaborare tra loro dal
momento che sono provvisti di un processore on-board; grazie a quest'ultimo, ciascun
nodo, invece di inviare dati grezzi ai nodi responsabili della raccolta dei dati, può
effettuare delle semplici elaborazioni e trasmettere solo i dati richiesti e già elaborati.
La comunicazione, realizzata tramite tecnologia wireless a corto raggio, è solitamente di
tipo asimmetrico in quanto i nodi comuni inviano le informazioni raccolte ad uno o più
nodi speciali della rete, detti nodi sink, i quali hanno lo scopo di raccogliere i dati e
trasmetterli tipicamente ad un server o ad un calcolatore. Una comunicazione può avvenire
autonomamente da parte del nodo quando si verifica un dato evento, o può venire indotta
dal nodo sink tramite l'invio di una query verso i nodi interessati.
Le reti di sensori possono essere utilizzate in numerose applicazioni; tuttavia la
8
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
realizzazione di queste ultime richiede l'uso di tecniche utilizzate anche nelle reti wireless
ad hoc. Sfortunatamente, molti degli algoritmi usati nelle reti ad hoc non sono compatibili
con i requisiti di questo tipo di reti. I principali motivi derivano dal fatto che:
Il numero di nodi che compongono una rete di sensori può essere di alcuni ordini di
grandezza maggiore rispetto al numero di nodi in una rete ad hoc
I nodi sono disposti con un’alta densità
I nodi sono soggetti a guasti
La topologia di una rete di sensori può cambiare frequentemente a causa di guasti ai
nodi o della loro mobilità
I nodi utilizzano un paradigma di comunicazione broadcast mentre la maggior parte
delle reti ad hoc sono basate su una comunicazione di tipo punto-punto
I nodi sono limitati rispetto ad alimentazione, capacità di calcolo e memoria
I nodi solitamente non possiedono un identificatore globale (come l’indirizzo IP dei
computer)
I nodi necessitano di una stretta integrazione con le attività di rilevamento
Per questo motivo, questa tipologia di rete necessita di algoritmi pensati e realizzati in
maniera specifica per gestire la comunicazione e l’instradamento dei dati.
Le reti di sensori possono migliorare in modo significativo la qualità delle informazioni:
ad esempio possono garantire una elevata fedeltà, possono fornire informazioni in tempo
reale anche da ambienti ostili e possono ridurre i costi di trasmissione delle stesse
informazioni.
Lo scopo fondamentale di una rete di sensori è di produrre su un periodo esteso di tempo,
una informazione globale significativa ottenuta da una serie di dati locali provenienti dai
singoli sensori. È importante notare che la rete deve essere realizzata in modo da
garantirne l'integrità per un periodo di tempo che sia il più lungo possibile, allo scopo di
ottenere informazioni accurate anche in caso di attacco alla rete da parte di organi esterni o
di cedimenti hardware.
Il fatto che un singolo sensore sia dotato di una piccola quantità di energia non deve
impedirgli di inviare le informazioni elaborate, che verranno raccolte e unite alle
9
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
informazioni provenienti dagli altri sensori. Un'importante via da seguire consiste nel
rilevare il maggior quantitativo possibile di dati locali, evitando la trasmissione dei dati
inefficienti attraverso la rete.
Una rete di sensori quindi può essere vista come un insieme di sensori di diverso tipo
capaci di rilevare grandezze come temperatura, umidità, pressione, luce, ma anche capaci
di rilevare il movimento di veicoli, la composizione del terreno, livello di rumore, etc.
Sono tantissime le applicazioni in cui possono essere impiegate WSN rispetto ad altre
soluzioni, per migliorarne l’affidabilità e ridurne i costi.
I principali impieghi, ad esempio, possiamo trovarli negli ambiti militari, ambientali,
sanitari, casalinghi e commerciali.
Nell’ambito militare le possibili applicazioni vanno dal monitoraggio di forze alleate,
equipaggiamenti e munizioni alla sorveglianza del campo di battaglia. E’ possibile usare
una rete di sensori per effettuare il riconoscimento di nemici, la stima dei danni di una
battaglia oppure il riconoscimento del tipo di attacco (nucleare, biologico o chimico).
Questo col vantaggio che, essendo una rete di sensori basata su una disposizione densa di
nodi monouso ed a basso costo, la distruzione di alcuni nodi da parte del nemico non
danneggia le operazioni militari come potrebbe accadere con la distruzione di sensori
tradizionali.
Nell’ambito ambientale, le reti di sensori potrebbero essere utilizzate per effettuare il
monitoraggio di una foresta e rilevare prontamente eventuali incendi, per la previsione e
rilevazione di inondazioni, oppure per il monitoraggio del movimento di uccelli, piccoli
animali, insetti con l’obiettivo di studiarne l’habitat e il loro comportamento. Più nello
specifico, le reti di sensori possono essere utilizzate in ambito ambientale nell'agricoltura
di precisione: monitorare il livello dei pesticidi nell'acqua, il livello di erosione del terreno
e il grado di inquinamento dell'aria in tempo reale. Sempre nel settore ambientale, le reti di
sensori possono essere di interesse per studiare gli spostamenti ed il dinamismo all'interno
dei ghiacciai. A tal proposito i sensori vengono distribuiti all'interno del ghiaccio a
profondità differenti. I sensori sono capaci di rilevare temperatura e pressione
comunicando con una stazione base posizionata in cima al ghiacciaio che provvederà al
10
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
trasferimento di questi a chi di competenza.
Nell’ambito sanitario gli utilizzi delle reti di sensori sono rivolte a fornire un'interfaccia
per le persone affette da handicap, al monitoraggio di dati fisiologici, all'amministrazione
ospedaliera sia essa relativa ai pazienti che ai medici (per una facile rintracciabilità).
Inoltre è anche possibile usare i sensori per l'identificazione di allergie.
L’utilizzo di una rete di sensori in ambito domestico è potrebbe focalizzarsi
sull'automazione delle abitazioni: l’utilizzi di nodi, inseriti anche negli elettrodomestici,
possono interagire l'uno con l'altro e anche con reti esterne tramite l'utilizzo di internet o
del satellite permettendo la gestione dell’habitat familiare anche da distanze remote.
L'ambiente domestico viene ad assumere così le stesse caratteristiche di un piccolo centro
fornito di una rete in grado di mettere in comunicazione tra loro tutti i vari strumenti di cui
l'ambiente è composto.
In ambito commerciale l’utilizzo di WSN abbraccia i campi più disparati: controllo
ambientale di uffici, rilevamento furti d’auto, rilevamento della posizione e del movimento
dei veicoli (car tracking), monitoraggio del traffico, monitoraggio del consumo energetico
di uffici e abitazioni, etc.
1.2 Progettare e Simulare una WSN
La progettazione di una rete di sensori è influenzata da molti fattori che non solo sono
necessari per la progettazione della rete, ma influenzano a loro volta la scelta degli
algoritmi utilizzati nella rete stessa. Tra i più importanti citiamo:
Tolleranza ai gusti:
Nella rete di sensori c'è la possibilità che alcuni nodi della rete siano affetti da
malfunzionamenti o guasti le cui cause possono essere danni fisici, interferenze o
batterie scariche. La tolleranza ai guasti è la capacità di far funzionare una rete di
sensori anche in caso di malfunzionamento da parte di alcuni nodi. I protocolli e gli
algoritmi possono essere progettati in modo da garantire il livello di tolleranza ai
guasti richiesto dalla rete. Il livello di tolleranza dipende fortemente dall'applicazione
in cui viene utilizzata la rete di sensori (uso militare, domestico, commerciale, etc...).
11
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
Scalabilità
Il sistema deve essere in grado di funzionare anche all'aumentare del numero di nodi
(che possono andare da un basso numero di unità, fino ad arrivare a qualche milione
di sensori). La scalabilità può essere ottenuta anche sfruttando la natura densa delle
reti di sensori.
Costi di produzione
Poiché una rete di sensori è formata da un grande numero di nodi, il costo di un
singolo nodo è molto importante. Se il costo della rete è maggiore rispetto all'utilizzo
dei sensori tradizionali allora l'uso di una rete di sensori non è giustificabile. Il costo
di un nodo sensore dovrebbe perciò essere abbastanza basso: un obbiettivo non molto
facile da raggiungere in quanto un nodo ha spesso molte unità hardware: processore,
campionatore, GPS, sistema radio e sensori di vario genere, e tutte queste cose
portano ad un incremento del costo di un sensore.
Ambiente Operativo
I sensori sono disposti molto vicino o addirittura all'interno del fenomeno da
osservare. Perciò, spesso, si trovano a lavorare in zone geografiche remote (es:
all'interno di un macchinario, in fondo all'oceano, sulla superficie dell'oceano durante
un tornado, in una zona biologicamente o chimicamente contaminata, in un campo di
battaglia etc..) e senza la supervisione dell'uomo. Tutto ciò dà un'idea delle condizioni
sotto le quali i sensori devono essere capaci di funzionare (devono sopportare alte
pressioni se lavorano in fondo all'oceano, alte o basse temperature etc..).
Topologia della rete
Un gran numero di nodi sono disposti l'uno accanto all'altro a volte anche con un'alta
densità. Questo richiede un'attenta attività per il mantenimento della topologia. Il
mantenimento e il cambiamento della topologia può essere diviso in tre fasi:
i) Pre-deployment e deployment phase: i sensori possono essere sia gettati sia disposti
uno ad uno nell'ambiente; infatti possono essere gettati da un aereo, da una catapulta,
collocati uno ad uno da un robot o da una persona umana.
ii) Post-deployment phase: i cambiamenti topologici della rete sono dovuti al
12
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
cambiamento della posizione dei nodi, oppure alla variazione della raggiungibilità di
un nodo, dell'energia disponibile, alla presenza di malfunzionamenti etc...
iii) Re-deployment of additional nodes phase: nodi sensore addizionali possono essere
ridisposti in qualsiasi momento per rimpiazzare i nodi malfunzionanti o a causa della
dinamica dei task. L'aggiunta di nuovi nodi comporta la necessità di riorganizzare la
rete. L'alta frequenza di cambiamenti topologici e il vincolo stringente del risparmio
energetico richiedono protocolli di routing molto particolari.
Consumo energetico
Un sensore è dotato di una limitata sorgente di energia. Il tempo di vita di un nodo
sensore dipende molto dal tempo di vita della batteria. In una rete di sensori ogni nodo
ha il ruolo sia di generare che di ricevere dati, perciò la scomparsa di alcuni nodi può
portare a significativi cambiamenti topologici che possono richiedere una
riorganizzazione della rete e del routing. È per queste ragioni che molte ricerche si
stanno concentrando sulla creazione di protocolli e algoritmi power-aware, cioè
protocolli che ottimizzano il consumo energetico. Mentre nelle reti mobili e nelle reti
ad hoc il consumo di energia è un importante fattore ma non è il principale (che risulta
invece il soddisfacimento della QoS, cioè della qualità del servizio), nelle reti
sensoriali il consumo di energia è la principale metrica per valutare le performance:
questo perché nelle altre reti è possibile ricaricare o cambiare le batterie dei nodi
mentre nelle reti sensoriali una volta che la batteria è scarica il nodo è da considerarsi
morto. Il consumo di energia in un nodo sensore è essenzialmente dovuto alle tre
principali attività svolte dal nodo:
i) Sensing: la potenza necessaria per effettuare il campionamento dipende dalla natura
dell'applicazione;
ii) Data processing: l'energia spesa nel processare i dati è molto piccola se comparata
a quella spesa per la comunicazione;
iii) Communication: dei tre fattori è quello che necessita della maggior quantità di
energia. La comunicazione comprende sia la ricezione che la trasmissione di dati i cui
costi energetici possono essere ritenuti uguali.
13
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
Un ultimo fattore, importantissimo per la progettazione di una rete di sensori, è
l’affidabilità (in inglese dependability).
Esprimendo questo fattore nel senso più ampio di “sistema”, possiamo dire che un sistema
è detto dependable se esibisce una probabilità alta di comportarsi così com'è definito nella
sua specifica, ovvero l'abilità di un sistema di fornire un servizio che può essere
considerato "fidato" in maniera giustificata. Il concetto di dependability viene solitamente
utilizzato (insieme ad altri concetti che caratterizzano la cosiddetta “qualità del sistema”)
come concetto base per definire sia la specifica che il rispetto della specifica da parte del
sistema; nel fare ciò diviene fondamentale poter valutare la dependability attraverso
opportune tecniche.
La valutazione della dependability costituisce un’operazione utile e versatile in ogni fase
del ciclo di vita di un sistema. Durante la fase di progettazione può conferire fiducia nelle
scelte progettuali effettuate, validando e confrontando le diverse soluzioni individuate,
durante la vita operativa del sistema permette di rilevare eventuali colli di bottiglia per
l’affidabilità e suggerisce quali siano le soluzioni da adottare in future revisioni. Per poter
effettuare una valutazione della dependability è necessario poter valutare caratteristiche sia
qualitative che quantitative del sistema. Soffermandosi su quest’ultime, le tecniche di
analisi quantitativa si possono classificare in tecniche basate su misure e tecniche
modellistiche, a loro volta suddividibili in tecniche analitiche e simulative.
Tecniche basate su misure
Le tecniche basate su misure si fondano sull’osservazione diretta del sistema sotto
analisi (o di un suo prototipo) utilizzando appositi moduli software e hardware
chiamati monitor (per questo spesso queste tecniche sono chiamate tecniche di
monitoraggio). Gli scopi di queste tecniche sono molteplici: permettono la
caratterizzazione qualitativa e quantitativa del carico di lavoro, delle performance e
dell'utilizzo delle risorse, informazioni utili ad esempio per creare un modello del
sistema, caratterizzare l'ambiente in cui il sistema opera e validare un modello creato.
Questo metodo è chiaramente costoso e complesso, e inoltre non sempre è attuabile
(si pensi al caso in cui il sistema non esista ancora e debba essere progettato), per di
14
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
più la dependability risulta spesso di difficile valutazione in quanto necessita di lunghi
tempi di osservazione.
Tecniche basate su modelli
Un modello è una rappresentazione fisica, matematica, logica o concettuale di un
sistema di entità, fenomeni o processi. Lo scopo che si pone un modello è quello di
ricapitolare la conoscenza di un fenomeno e del suo comportamento senza il bisogno
di un testbed, o di una misura diretta sul sistema. I modelli sono tipicamente usati
quando è impossibile o poco pratico generare le condizioni sperimentali nelle quali gli
scienziati possono direttamente misurare i risultati. Un modello è sempre frutto di
assunzioni che si fanno sul sistema, ciò è inevitabile dal momento che la realtà è
spesso troppo complessa per essere modellata senza l’uso di semplificazioni, più
queste sono numerose più l’accuratezza e l’attinenza del modello diminuiscono e
conseguentemente i risultati che si ottengono da esso si allontanano dal
comportamento reale del sistema. L’uso di modelli richiede sempre di trovare un
punto di equilibrio tra la fedeltà del modello, ovvero l’accuratezza con cui questo
rappresenta la realtà, e la trattabilità del modello, ovvero la possibilità di definire e
risolvere il modello per ottenere le misure di interesse.
Tecniche analitiche
La tecnica analitica (come anche quella simulativa) è basata sulla costruzione di un
modello del sistema e delle sue componenti; un modello rappresenta le nostre
assunzioni sul comportamento del sistema da analizzare. Nello specifico nei modelli
analitici le componenti del sistema sono rappresentate attraverso variabili di stato e
parametri, e le loro interazioni sono rappresentate attraverso relazioni fra queste
quantità. I limiti delle tecniche analitiche per la valutazione della dependability stanno
nella maneggevolezza e utilizzabilità del modello nei casi di sistemi di reale interesse,
in tali casi può spesso risultare difficile (anche se teoricamente possibile) riuscire a
trovare una rappresentazione esplicita che possa essere usata in maniera semplice: la
capacità di descrizione del modello e la sua aderenza al sistema reale stabilisce
l’eventuale necessità di passare ad un approccio simulativo.
15
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
Tecniche simulative
Le tecniche simulative sono uno strumento potente sia per predire il comportamento
futuro di un sistema già esistente (forecasting), sia come supporto alla progettazione
per valutare la dependability di un sistema prima che venga implementato e dando
quindi i mezzi per la convalida del sistema o, in caso contrario, indicazioni utili al
miglioramento del sistema stesso fornendo la possibilità di confrontare soluzioni
progettuali differenti; inoltre permette una valutazione del sistema in condizioni rare o
pericolose, se studiate sul sistema reale, senza l’uso di tecniche invasive su
quest’ultimo e con la possibilità di effettuare la simulazione con diverse
configurazioni del sistema e con riferimento ad intervalli temporali di qualsiasi durata
e con l’ulteriore vantaggio della riproducibilità della simulazione, cosa non sempre
possibile nella realtà fisica; tutto ciò con costo, valutato in termini di tempo e
complessità, generalmente minore se paragonato a tecniche basate su misure dirette
del sistema. Le tecniche simulative consistono nella riproduzione del comportamento
dinamico del sistema nel tempo, viene generata così una storia artificiale del sistema
che può essere usata per il suo studio; per fare ciò è necessaria la presenza di un
modello simulativo che, con un determinato formalismo, descriva il comportamento
del sistema e l'esecuzione di un software dedicato detto simulatore tale da permettere
la rappresentazione dell'evoluzione temporale del sistema e da fornire una stima delle
misure di interesse. Infatti la simulazione è una tecnica model based, e presuppone
quindi l'esistenza di un modello che sia adeguatamente aderente al sistema reale
oggetto di studio, ossia fornisca con sufficiente accuratezza una descrizione del
comportamento del sistema.
Per valutare le caratteristiche che un tool web-based deve avere nella simulazione di reti
wireless di sensori, analizziamo dapprima come l’utente interagisce con i modelli analitici
e la simulazione. Infatti I modelli analitici sono usati per definire il fallimento e il
funzionamento di riconfigurazione del sistema (ad esempio, per modelli WSN vengono
presi in considerazione l’esaurimento della batteria, guasti hardware e ripristino guasti,
fallimenti di comunicazione, ecc.) e per eseguire le misurazioni desiderate. D’altra parte, i
16
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
simulatori di funzionamento vengono usati per calcolare cifre utili per generare e
configurare modelli analitici che hanno come parametri valori realistici (ad esempio,
simulatori di funzionamento di WSN possono essere usati per mettere a punto numero e
tipi di nodi e la topologia di connessione, per caratterizzare il carico di lavoro in
esecuzione sui nodi, per valutare calcoli e cifre significative, come il consumo di energia,
il profilo di propagazione wireless, ecc.). La simulazione di modelli analitici può essere
suddivisa in due parti principali:
i) generando il modello analitico attraverso i risultati delle simulazioni e preferenze
dell’utente, e
ii) gestendo i cambiamenti ottenuti durante l’evoluzione dei modelli analitici aggiornando
il modello analitico con i nuovi valori ottenuti, cercando di evitare di eseguire nuove
simulazioni ogni volta che avvengono cambiamenti.
Fig. 1.5 – Diagramma del procedimento adottato nella modellazione e nella simulazione di WSN.
Dal diagramma si può notare che nel passo 1 l’utente fornisce gli input necessari per
specificare il sistema in oggetto e per configurare lo scenario da sperimentare. Per una
17
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
WSN, equivale a specificare: i) il numero ed il tipo di nodi, ii) la topologia della rete, iii) il
carico di lavoro (ad esempio le applicazioni da eseguire) su ogni nodo, iv) il tipo di radio
installata sui nodi, v) l’algoritmo di routing adottato, vi) il tipo di tecnologia di batterie per
ogni nodo e vii) la tecnologia hardware di sensing adottata su ogni nodo. Questi input
vengono usati per configurare i simulatori di funzionamento adottati (Tossim, Mobius,
Avrora, etc.). In questa fase l’utente fornisce anche un set di metriche da valutare, come
per esempio disponibilità, performance, etc.
E’ importante notare che quest’approccio consente all’utente di lavorare all’interno del suo
dominio di conoscenza: ovvero, uno sviluppatore di WSN interagisce esclusivamente con
l’ambiente relativo al suo dominio applicativo (numero, tipo e posizioni dei nodi,
programmi e algoritmi da eseguire sui nodi, etc.) e alla fine del processo ottiene le
misurazioni richieste senza sapere o preoccuparsi di come le misurazioni vengono
calcolate e, cosa più importante, non ha bisogno di conoscere i dettagli sui modelli
analitici utilizzati.
Il passo 2 riguarda la simulazione del comportamento del sistema in oggetto. L’obiettivo
della simulazione
è valutare i parametri necessari richiesti dall’external engine per
generare e popolare il modello analitico, durante i passi 3 e 4. I parametri del modello
possono essere sia statici che dinamici: i parametri statici sono relativi agli aspetti che non
mutano durante la simulazione del modello analitico (ad esempio per una WSN sono la
piattaforma hardware, la tecnologia della batteria, la tecnologia di comunicazione radio,
etc.), i parametri dinamici dipendono invece dalla configurazione corrente del sistema, ad
esempio il numero dei nodi WSN guasti, il numero di nodi isolati, il rate di trasmissione di
ogni nodo, etc. e necessitano di essere ricalcolati ad ogni cambiamento durante
simulazione del modello analitico. Nel caso di WSNs, esempi di parametri calcolati sono il
profilo di consumo energetico per ogni nodo, la probabilità di perdita pacchetti di ogni
link, e le caratteristiche dei workload, ovvero il duty-cycle (la media percentuale del
lavoro utile eseguito da ogni nodo non in fase di stand-by) e la dimensione media dei
pacchetti trasmessi/ricevuti.
La generazione automatica del modello analitico viene effettuata nel passo 3 dal Model
18
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
Generator. Il Model Generator produce modelli analitici partendo da una predefinita
libreria di template modello, e il numero e il tipo di modelli da generare dipendono dagli
input dell’utente.
Per esempio, N modelli di nodo saranno generati per una WSN
composta di N nodi. Ogni modello di nodo verrà poi specializzato a seconda della
topologia (la quale specifica i vicini di ogni nodo), della piattaforma hardware (dalla quale
dipenderà il modello di fallimento), etc. I valori iniziali dei parametri del modello vengono
impostati partendo dai risultati delle simulazioni e da un set predefinito di parametri, come
ad esempio il failure rate dei componenti hardware.
Il passo 4 riguarda la simulazione del modello analitico generato. Risulta chiaro come il
funzionamento di un singolo nodo modifichi il comportamento dell’intera rete in modi
inimmaginabili, e viceversa differenti scelte da parte dell’utente (come ad esempio
l’algoritmo di routing) influenzino il comportamento di ogni singolo nodo. Per cercare di
dominare questa complessità, utilizziamo modelli parametrici e riusabili, i quali sono
autonomi e capaci di adattarsi ai cambiamenti indotti da altri modelli.
Infine, durante la simulazione, vengono valutate le metriche scelte e i risultati vengono
proposti all’utente al passo 5. A questo punto, in dipendenza dai risultati ottenuti, l’utente
può decidere se necessario di rivedere le proprie scelte e di riprogettare il sistema.
1.3 Il Tool Failure Model WSN Generator
L’uso di strumenti quali la simulazione possono mostrare la necessità dell’apporto di
modifiche alle specifiche iniziali, al progetto del sistema da implementare, o allo stesso
modello, ciò porterà ad una nuova simulazione in un processo iterativo di modifiche dove
la flessibilità e la propensione al cambiamento è fondamentale, e ciò viene ben supportato
da un tool di generazione automatica dei modelli di fallimento. Il supporto di un tool per la
generazione automatica di modelli pone il modellista ad un livello di astrazione più alto
rendendo la modellazione stessa più flessibile ed i modelli prodotti generali e facilmente
particolarizzabili. L’idea si fonda sulla costruzione di un modello versatile e
rappresentativo di un’ampia gamma di sistemi da un lato e sulla possibilità, offerta da un
generatore automatico, di specializzare tale modello ottenendo gli effettivi modelli
19
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
utilizzabili per la simulazione di un dato particolare sistema senza snaturare la generalità
del modello iniziale e senza apportarne modifiche dirette; si è potuto così ottenere, per il
particolare caso di studio, a partire da un modello che descrivesse in modo generale una
famiglia di reti WSN, la specializzazione a una data rete con un proprio numero di nodi e
una propria topologia tramite generazione automatica.
Fig. 1.2 – L’applicazione Failure model WSN Generator
Il Tool Failure Model WSN Generator, progettato e implementato nel lavoro di tesi [4],
consiste in un applicazione desktop scritta in Java con gui Swing in cui l’utente:
i) immette la path in cui si trovano i file della topologia da analizzare
ii) seleziona la quantità di nodi presente nella topologia, il tempo di simulazione
desiderato e la scelta di un’ottimizzazione del modello da generare
iii) seleziona il percorso in cui verranno generati i file del modello da simulare.
L’applicazione è formata da una serie di classi progettate partendo da un reverseengineering del simulatore Mobius adottato, le quali dagli input dell’utente e dal click del
tasto “Generate” si occupano di ricavare dalla topologia il modello corretto in forma di
progetto Mobius da simulare, includendo sorgenti ed header in c++ necessari al progetto e
librerie del modello di fallimento. La fase della generazione del modello viene descritta da
20
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
una serie di messaggi inviati ad una JtextArea della GUI e alla Console di Sistema: alla
fine della generazione del modello di fallimento, l’applicazione lancia il simulatore
Mobius per la compilazione dei file e per la simulazione.
Fig. 1.3 – Il nuovo approccio alla modellazione e simulazione utilizzato da Failure Model WSN Generator
1.3.1 Il simulatore Mobius
Il tool Failure Model WSN Generator sfrutta il funzionamento del software Mobius[s1],
uno strumento per la modellazione del comportamento di sistemi complessi.
Benchè sia stato originariamente sviluppato per lo studio della reliability, availability, e le
performance di sistemi di elaborazione e sistemi di rete, l'uso di Mobius si è espanso
rapidamente. Ora è usato per un’ampia gamma di sistemi a eventi discreti dalle reazioni
biochimiche agli effetti di attacchi maliziosi sulla sicurezza di sistemi di elaborazione, in
aggiunta alle applicazioni originarie. L’ampia gamma di usi è possibile per via della
flessibilità e potenza riscontabili in Mobius, che provengono dal suo supporto alla
modellazione multiformalismo e alla possibilità di ricorrere a diverse tecniche per la
soluzione dei modelli. Questa flessibilità permette al modellista di rappresentare il sistema
oggetto di studio nel linguaggio di modellazione più appropriato al dominio del problema
21
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
in questione e poi risolvere il modello in maniera efficiente e accurata usando la tecnica di
risoluzione più appropriata in relazione alla dimensione e complessità del sistema. Sono
supportate dal tool la simulazione a eventi discreti distribuita e la risoluzione analitica e
numerica.
Fig. 1.4 – L’architettura del tool Mobius
Per la costruzione di un modello Mobius mette a disposizione vari editor classificabili in
base al tipo di modello da generare (atomico, composto etc.). Per ogni modello Mobius
genera e compila del codice sorgente C++ ed i file oggetto prodotti vengono raccolti per
formare un archivio di librerie. Queste librerie sono collegate insieme, attraverso l’uso di
un linker, alle librerie base di Mobius per formare l’eseguibile per il solver [Fig. 1.4], che
viene poi lanciato per generare i risultati; l’uso di codice C++ conferisce efficienza nella
risoluzione, e una grande flessibilità nella definizione del modello dal momento che è
possibile arricchire il codice generato automaticamente da Mobius con proprie librerie.
1.3.2 La topologia della rete
La topologia della rete data dal modellista in input al tool di generatore modelli di
fallimento è composta dai seguenti file (di estensione .TXT):
coordinate: racchiude le coordinate x e y esatte di ogni nodo. Esse sono espresse in
22
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
coppie di cifre in formato double separate da uno spazio e da un ritorno a capo per
ogni nodo.
distances: è un file contenente una matrice quadrata in cui sono presenti le distanze dei
nodi: l’elemento [j,k] della matrice rappresenta la distanza euclidea bidimensionale tra
il nodo j e il nodo k calcolata con la formula: d
x1 x2 y1 y2
2
2
; i valori j=k
(la distanza tra il nodo e se stesso) avranno ovviamente valore 0.000
energy: un elenco contente per ogni nodo dei valori che caratterizzano la tecnologia
della batteria utilizzata.
losses: contiene la matrice delle adiacenze, che associa all’elemento [j,k] della matrice
la probabilità che un’informazione giunga dal nodo j al nodo k: è un valore compreso
tra 0 e 1 ed esprime la qualità del link tra il nodo j e il nodo k.
neighbor: ogni riga del file è associata ad ogni della topologia, e descrive i nodi
“vicini” a seconda che ci sia un link, nella forma: numero del nodo, numero dei vicini,
numeri nodo dei vicini
radio: un elenco contenente per ogni nodo dei valori che caratterizzano la tecnologia
della radio utilizzata.
TinySan: contiene in cifre il numero di nodi che compongono la topologia.
topology: contiene un riepilogo riassuntivo dei file descritti in precedenza.
La generazione di questi file è a carico dell’utente, e si può immaginare come per
topologie con molti nodi ciò diventi un compito dispendioso soprattutto se svolto non
graficamente: la topologia può essere infatti ricavata da software di simulazione che hanno
come caratteristica la disposizione grafica dei nodi che compongono la topologia, in modo
che l’utente abbia anche una visione globale della disposizione dei nodi e di tutto
l’ambiente da modellare e simulare. Da ciò nasce l’esigenza di un tool nella progettazione
della topologia che si avvicini il più possibile all’ambiente WSN rispetto ad altri software
più “graficamente generici”, ma soprattutto che produca il file necessari per la
modellazione e la simulazione in modo diretto, senza che l’utente vada a ricavare o
modificare manualmente i file necessari al tool Failure Model WSN Generator. Ed è da
quest’esigenza e dagli innumerevoli vantaggi che comporta una web-application che è nata
23
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
la necessità di realizzare uno strumento web-based per la simulazione remota di WSNs.
1.4 Motivazioni del remoting nella simulazione di WSN
Le motivazioni subito evidenti nell’utilizzo di un’applicazione web-based piuttosto di
un’applicazione desktop-based derivano dal concetto stesso di web application, e dalle
caratteristiche che hanno decretato l’esigenza e il successo del web 2.0 e il trend attuale di
migrazione verso internet:
Disponibilità: una web application non ha bisogno di essere scaricata, installata o
configurata: il digitare semplicemente l’indirizzo web rende l’applicazione subito
disponibile.
Scalabilità: le applicazioni web-based possono crescere insieme all’esigenze di
un’azienda; features aggiuntive possono essere implementate immediatamente e rese
subito disponibili agli utilizzatori senza operazioni onerose quali installazione
aggiornamenti, verifica compatibilità ambiente, etc.
Manutenibilità: la risoluzione di bug, il miglioramento delle prestazioni e
l’aggiornamento del codice in una web application possono avvenire ed essere diffuse
molto più rapidamente rispetto alle applicazioni tradizionali.
Sicurezza dei dati: l’implementazione di un buon server, soprattutto se associata a
tecnologie di clustering o di cloud computing, assicura la conservazione e la
protezione dei dati (siao essi dati applicativi o dati utente) in caso di
malfunzionamenti, virus o problemi hardware in maniera più efficiente rispetto alle
applicazioni tradizionali. L’utente accede alla web application solo con il proprio
browser, e possiamo quindi immaginare che esso interagisce con una sorta di
“sandbox”, un ambiente protetto gestibile solo dal software di navigazione: dal lato
server inoltre un semplice servizio di backup automatico dei dati eseguito
periodicamente già è sufficiente per migliorare la sicurezza del sistema rispetto ad
un’applicazione che viene eseguita nel sistema non sandbox dell’utente.
Carico di lavoro: una web application può essere progettata per eseguire totalmente il
carico computazionale sul server, oppure a seconda delle esigenze e dei costi di
24
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
gestione può distribuire le operazioni necessarie al suo corretto svolgimento sia sul
client che sul server; in questo modo si può eliminare la scelta obbligatoria di un thick
client per eseguire applicazioni e calcoli complessi.
Riduzione costi di gestione: la migrazione verso i thin client piuttosto che la scelta
obbligata dei thick client, e l’indipendenza della web application dal sistema operativo
può permettere un risparmio sui costi di licenza, sui costi delle tecnologie hardware e
software.
Accessibilità: un’applicazione web-based può essere eseguita ovunque e su qualsiasi
dispositivo, compresi smartphone, PDA e moderne console da gioco; con una giusta
scelta delle tecnologie software impiegate per la sua realizzazione, l’unico limite resta
solo la risoluzione dello schermo dei dispositivi client e della disponibilità di una
buona connessione ad internet.
Alla luce di quanto detto possiamo descrivere le caratteristiche derivanti applicando uno
strumento di tipo web-based al caso di simulazioni remote di WSN: è evidente come i
vantaggi elencati all’inizio di questo paragrafo si riflettono nell’uso degli strumenti appena
elencati da parte del modellista, ed in particolare:
L’aggiunta di nuovi modelli analitici si propaga in tempo reale ed è subito a
disposizione di ogni utente che accede alla web application;
L’utente non ha bisogno di installare e configurare particolari software di
modellazione e di simulazione in ogni macchina che utilizza per lo sviluppo di WSN,
e può accedere all’applicazione ovunque e da ogni sistema dotato di un web browser;
Tutto il codice gestito dalla web application non è ne visibile ne accessibile da parte
dell’utente: tutto ciò che il modellista può accedere sono i dati di modellazione e
simulazione, accessibili ovunque e protetti da eventuali guasti hardware e software;
Il calcolo computazionale delle simulazioni e della generazione di modelli analitici in
base alla topologia della rete avviene sul server o potrebbe addirittura avvenire su un
sistema distribuito di server, in modo tale che il modellista può utilizzare un normale
thin client con notevoli risparmi in ambito economico.
Si può pensare che questo tipo di approccio unisca il vecchio approccio computazionale
25
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 1: Wireless Sensor Network: Modellazione e Simulazione
accademico di trent’anni fa, quando l’utente immetteva i propri dati in calcolatori grandi
come stanze intere e ne attendeva i risultati, al moderno web 2.0 dove l’interazione,
l’accessibilità e la portabilità sono i veri punti forza.
26
Capitolo 2
Analisi dei Requisiti e Progettazione
Dopo aver dato uno sguardo d'insieme sulle reti di sensori senza filo ed analizzati i
vantaggi di un tool web based per la simulazione remota di WSN, questo capitolo si
occupa dapprima dei concetti chiave dei requisiti che il tool deve soddisfare, poi dei
concetti chiave che il lavoro di questa tesi ha implementato, soffermandosi brevemente
sugli use case dell'applicazione. Il come questi requisiti, insieme alle caratteristiche
spiegate nel primo capitolo, si riflettano nel tool implementato verrà descritto iniziando dal
paragrafo 2.3, dedicato al primo passo della progettazione, e continuerà nel terzo capitolo
dedicato alla scelta delle tecnologie per le Rich Internet Applications. Si sottolinea il fatto
che la maggior parte della documentazione che accompagna il software (compresi SRS,
Class e Sequence Diagrams, Test Cases, etc.) è stata omessa per non rendere prolisso il
presente lavoro di tesi.
2.1 Web Model WSN Generator: concetti chiave
Seguendo l'approccio della modellazione e simulazione descritto nella Fig. 1.5 e avendo
l'obiettivo di remotizzare il tool in Java Failure Model WSN Generator, abbiamo che la
nostra applicazione da implementare, denominata Web Model WSN Generator, è
caratterizzata innanzitutto da una gestione multi-utente: infatti essendo una web
application, l'accesso ad essa non è limitato ad un solo utente per volta, ma deve gestire
anche contemporaneamente più utenti che si collegano con il proprio browser; questo
27
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
impone un accesso protetto con username e password per ogni sessione, ma soprattutto un
ambiente personalizzato per ogni utente. Ovvero ogni modellista, progettista e
sviluppatore di WSN deve possedere ed accedere sul server le proprie cartelle e i propri
file contenenti le topologie, i modelli, e i risultati delle proprie simulazioni. Eseguendo
correttamente il primo accesso al web server, infatti, il tool Web prepara l'ambiente
personalizzato per l'utente: a questo punto viene presentata l'applicazione, il cui obiettivo
primario è svolgere il passo 1 descritto nel paragrafo 1.6, cioè quello in cui l’utente
fornisce gli input necessari per specificare il sistema in oggetto e per configurare lo
scenario da sperimentare.
L'applicazione deve memorizzare il numero di nodi da modellare, la topologia della rete
(con la possibilità di essere sia inviata dall'utente tramite upload oppure disegnata
direttamente dalla web application) e il tempo di simulazione da valutare. A seguito di ciò
l'utente può scegliere di scaricare il modello (generato oppure direttamente compilato) in
file pronti per il simulatore Mobius, da simulare e valutare nel proprio computer, oppure
può scegliere di far simulare il modello generato direttamente dal server, e attenderne i
risultati o essere avvisato tramite e-mail quando la simulazione sarà completata: in questo
caso l'utente dovrà scegliere le metriche da valutare nella simulazione (disponibilità,
performance, etc.), ed al termine della simulazione (passo 5 del paragrafo 1.6) i risulati
verranno presentati direttamente nella web application tramite un foglio di calcolo on-line
con la possibilità di salvare, stampare ed esportare i dati ottenuti. Nel caso in cui l'utente
sceglie di disegnare on-line la topologia dei nodi che compongono la rete, dovrà comparire
una schermata simile ad un software di disegno, dove l'utente può disporre i nodi con un
drag and drop su un piano bidimensionale e modificare, per ogni nodo, le coordinate, il
tipo di radio, il tipo di tecnologia della batteria e l'applicazione installata. Nel disegnare la
topologia, infine, l'utente può selezionare per la rete di nodi l'algoritmo di routing e il
modello di propagazione del segnale, il quale differisce dall'ambiente scelto.
Per quanto riguarda i passi 2, 3, 4 descritti nel paragrafo 1.6, se l'utente non decide di
scaricare il modello generato, i parametri calcolati, i modelli analitici e la simulazione del
modello analitico devono avvenire totalmente sul server, ma soprattutto i parametri statici
28
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
e dinamici, le librerie predefinite di template modello e i valori utilizzati e aggiornati dalle
simulazioni devono essere nascosti dall'utente della web application; ovvero da un lato si
richiede che il tool Web failure model WSN generator sia progettato in maniera da essere
ampliato con altri modelli, framework, template di librerie e simulatori, ma che queste
modifiche devono essere effettuate solo da chi gestisce l'applicazione e il server, in modo
tale che l'utente abbia solo una scelta, non modificabile, dei modelli a disposizione.
Dalla descrizione appena fatta di cosa il web tool deve completamente svolgere, il
seguente lavoro di tesi si è concentrato sulle richieste fondamentali impostando un ottimo
punto di partenza per il successivo completamento dell'applicazione, soprattutto perché la
scelta delle tecnologie e il modo di programmazione effettuato si sono concentrate sulla
massima espandibilità possibile sia per quanto riguarda il web tool sia per il tool desktop.
Prima di focalizzare però in che modo e come l'espandibilità caratterizza il software
implementato, questo paragrafo termina con i requisiti implementati nel tool, derivati dai
concetti chiave descritti precedentemente.
Dal seguente lavoro di tesi si è richiesto che il tool Web Model WSN Generator visualizzi
dapprima una schermata di accesso, dove l'utente immette username e password:
all'accesso eseguito correttamente il sistema mette a disposizione, in base all'utente, delle
cartelle sul server dove memorizzare la topologia della rete e i modelli generati. In seguito
all'utente viene presentata una schermata in stile wizard dove dapprima esso sceglie il
numero di nodi che compone la rete e il tempo di simulazione desiderato. In seguito, se
l'utente noi invia con un upload un file (di estensione .zip) contenenti i dati della topologia,
viene data la possibilità di disegnare la topologia della rete di sensori. Il disegno deve
essere fatto in maniera visuale, nei modi descritti precedentemente, e in particolare:
l'utente per ogni modo immette le coordinate e sceglie da una lista, non ancora funzionante
e implementabile successivamente, la radio, la batteria e il carico di lavoro: queste liste
sono tutte settate ad un valore di default, ma deve essere data la possibilità di caricare sul
server i file che le caratterizzano. Nella schermata del disegno in seguito l'utente può
scegliere di settare manualmente i link che compongono la topologia, oppure scegliere da
una lista il modello di propagazione desiderato: il sistema si occuperà di tracciare i link tra
29
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
i nodi e di impostare per ogni collegamento la probabilità di perdita dei pacchetti,
ovviamente compresa tra 0 e 1. Per aiutare la progettazione della rete, all'utente viene data
la possibilità di spostare i nodi sul piano bidimensionale, di impostare la scala di
riferimento e di aggiungere come sfondo al piano un'immagine che rappresenti la mappa
di riferimento dove verranno predisposti i nodi. Al termine del disegno, l'utente può
proseguire con la modellazione oppure cliccare sul tasto “export” e salvare sulla propria
periferica il file della topologia della rete. Proseguendo con l'applicazione, all'utente viene
presentata una schermata simile sia graficamente sia in termini di funzionalità al tool
Failure Model WSN Generator, ovvero con delle aree testuali che rappresentano i log
dell'applicazione e dei messaggi inviati alla console di sistema del server, e con i pulsanti
“Generate”, “Compile model” e “Simulation” a seconda se l'utente vuole generare il
modello, compilarlo o simularlo. Nel caso della generazione e della compilazione,
all'utente viene dapprima mostrato il log della generazione e in seguito viene data la
possibilità di scaricare il modello sorgente o il modello compilato, entrambi utilizzabili
con il simulatore Mobius. Nel caso in cui venga scelta la simulazione, all'utente viene
mostrata una schermata di scelta delle metriche da analizzare, e sarà avvertito che la
simulazione non è ancora funzionante. Infine, tutti in passaggi elencati deve essere
implementato un pulsante di “logout” che da la possibilità all'utente di ritornare alla
pagina di accesso invece di chiudere la finestra del browser web e al sistema di rilasciare
le risorse utilizzate per il disegno, la modellazione e la futura simulazione.
30
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
2.2 Casi d’uso
Dai requisiti appena elencati vengono qui proposti i casi d'uso principali:
Fig. 2.1 – Use Case Diagram – funzionamento principale della web application
CASO D'USO GENERAZIONE MODELLO
Pre-condizioni: l'utente ha effettuato con successo il login
Flusso di eventi:
1. L'utente imposta il numero di nodi e il tempo di simulazione
2. L'utente carica sul server il file .zip della topologia WSN
3. IF l'utente non carica il file della topologia, l'utente disegna la topologia
4. Il sistema importa la topologia in una cartella personale dell'utente
5. L'utente chiede la generazione del modello
6. Il sistema genera il modello e invia come download il file compresso del
modello all'utente
7. IF L'utente sceglie anche la compilazione, il sistema genera e compila il
modello per poi consegnare il file compresso all'utente
31
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
CASO D'USO DISEGNO TOPOLOGIA
Pre-condizioni: l'utente ha effettuato con successo il login
Flusso di eventi:
1. L'utente sceglie di disegnare una topologia WSN
2. Il sistema visualizza all'utente soltanto la parte di disegno topologia
3. L'utente chiede l'esportazione della topologia disegnata
4. Il sistema genera un file compresso contenente la topologia WSN e lo invia
all'utente
CASO D'USO SIMULAZIONE
Pre-condizioni: l'utente ha effettuato con successo il login
l'utente ha terminato e compilato la modellazione della WSN
Flusso di eventi:
1. L'utente seleziona una o più metriche da valutare (caso d’uso “selezione
metriche”)
2. Il sistema memorizza le scelte dell'utente in un archivio
3. L'utente inizia la simulazione
4. Il sistema simula il modello dell'utente e lo avvisa per e-mail quando
l'elaborazione è completata
5. L'utente si ricollega e chiede di visualizzare i risultati
6. Il sistema mostra i risultati in un foglio di calcolo
7. IF l'utente chiede di scaricare i risultati, il sistema manda all'utente un file .csv o
.xls del foglio di calcolo visualizzato
32
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
2.3 Diminuire l’accoppiamento
In ingegneria del software, l'accoppiamento misura l'interdipendenza di due moduli
(definiti come raggruppamenti di istruzioni, procedure e dichiarazioni): ad esempio, un
modulo A chiama una funzione definita nel modulo B o accede ad una variabile dichiarata
dal modulo B. Due moduli hanno un elevato accoppiamento se dipendono strettamente
l'uno dall'altro. Per ottenere la capacità di comporre, scomporre, comprendere e modificare
il software in maniera modulare, l'ingegnere del software deve progettare i moduli in
modo che abbiano alta coesione (cioè tutti gli elementi devono essere strettamente
connessi) e basso accoppiamento.
Questa definizione è stata la prima scelta effettuata nella progettazione del tool web-based:
infatti esso si basa principalmente sull'applicazione Java desktop Failure Model WSN
Generator implementata nel lavoro [4], e come prima cosa si è cercato di capire e di
scomporre le classi Java del software con l'obiettivo di separare l'interfaccia grafica (che
sfrutta le librerie Swing) dalla logica applicativa, in modo tale da utilizzare solo la logica
dell'applicazione nella web application.
Da una prima analisi si è notato che l'accoppiamento tra l'interfaccia grafica e le classi che
si occupano della generazione del modello era molto forte: come illustra il class diagram
seguente, molte classi in gioco acquisivano i dati necessari alla generazione del modello di
fallimento direttamente dalle JTextArea, CheckBox e ComboBox dell'istanza della classe
InterfacciaInput (la GUI del tool), ma soprattutto i messaggi generati da queste classi per
notificare il corretto svolgimento della generazione del modello all'utente venivano inviati
ad un oggetto del tipo JTextArea attraverso l'invocazione diretta del metodo .append.
33
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
Fig. 2.2 – Class Diagram dell'elevato accoppiamento tra la classe InterfacciaInput ed alcune classi del tool
Tutto ciò era lecito e giustificato dal fatto che il tool desktop aveva una semplice
interfaccia grafica e soprattutto che esso non era progettato per essere adattato e
riutilizzato in altri ambienti, tantomeno nell'ambiente web. Nel seguente lavoro di tesi però
una modifica e riprogettazione del codice di questo tool è inevitabile, e si è proseguito per
questa strada raggiungendo i seguenti obiettivi:
Lo sviluppo dell'applicazione desktop e della web application possono essere eseguiti
in parallelo: eventuali correzioni di bug e migliorie del tool desktop-based verranno
riflesse automaticamente nel tool web-based.
Il tool desktop-based potrà essere adattato in altri ambienti, compreso ad esempio
l'esecuzione e il controllo in maniera testuale da console di sistema.
Ciò è stato ottenuto principalmente implementando la classe AmbientVar e utilizzando le
classi Log di Java.
34
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
2.3.1 La classe AmbientVar
La classe Java AmbientVar implementata nel progetto del tool web-based gestisce tutte le
variabili necessarie alla modellazione e alla compilazione del tool failure model WSN
generator. Essa è composta principalmente da metodi get e set delle variabili visualizzabili
dall'interfaccia grafica del tool desktop-based, ovvero: i) numero di nodi, ii) path della
topologia della rete, iii) path dei file del modello generato, iv) tempo di simulazione, v)
ottimizzazione del modello. Questa classe si sovrappone tra la logica applicativa e
l'interfaccia grafica del tool, in modo tale che le scelte dell'utente dalla GUI vanno a
settare i campi di AmbientVar, e le classi responsabili della generazione del modello di
fallimento
tramite chiamate
get
acquisiscono i
dati
configurati
dalla classe
InterfacciaInput a tempo di esecuzione. In aggiunta sono state implementate alcune
variabili “flag” necessarie al corretto svolgimento dell'applicazione web (non sfruttate
quindi dal tool desktop) ed alcuni metodi per catturare ed inviare i messaggi inviati dalle
classi responsabili della generazione del modello di fallimento. Come illustra il
diagramma seguente:
Fig. 2.3 – Class Diagram dell'accoppiamento diminuito con la classe AmbientVar
35
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
l'accoppiamento è stato diminuito in maniera soddisfacente per il progetto web, e risulterà
ulteriormente diminuito sfruttando le classi Log di Java.
2.3.2 Logging
L'attività di logging consiste nel registrare automaticamente eventi che vengono generati
da un programma in modo da fornire una traccia che permetta di ricostruire e
diagnosticare eventuali problemi. Nel linguaggio Java le possibilità di implementare il
logging sono molteplici, e tra molte soluzioni valide vanno citate Apache Log4J e Java
Logging API, presente dalla versione 1.4 di Java. Entrambi i prodotti hanno una struttura
comune che prevede l’utilizzo di un oggetto logger al quale viene fornito il messaggio di
logging da generare in base ad una priorità predefinita. Il layout del messaggio e la
destinazione finale dello stesso è separata dalla generazione e viene gestita da opportune
classi che si occupano di formattare il messaggio e di inviarlo alla destinazione opportuna.
Fig.2.4 – Principali componenti logici dei framework di logging.
Questa struttura consente una notevole flessibilità in quanto distingue la fase di
generazione del messaggio dalla fase di formattazione e di invio alla destinazione finale
che può essere la console di sistema, un file, una e-mail , una socket o qualsiasi altra
destinazione si desideri.
Applicando la classe java.util.log al nostro tool desktop di generazione dei modelli di
fallimento, si sono modificate le classi che inviavano messaggi dirottando questi su i due
log creati, logger (per i messaggi diretti alla console) e guiLogger (per i messaggi diretti
36
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 2: Analisi dei Requisiti e Progettazione
alla JTextArea della classe InterfacciaInput) con semplici direttive del tipo:
this.varAmbiente.guiLogger.info("messaggio");
Si è proseguito poi nella creazione di un Output handler modificato a seconda
dell'ambiente in cui vengono catturati i messaggi: infatti i log handler creati derivano dalla
classe java.util.logging.Handler e contengono degli override dei metodi publish, close,
flush e setLevel tali che il layout e la destinazione dei messaggi avvengano diversamente a
seconda che si tratti dell'applicazione desktop-based o dell'applicazione web-based; in
questo caso il tool desktop possiede una classe TextAreaHandler in cui il layout è del tipo:
final String message = logRecord.getMessage() + "\n" ;
e la destinazione è proprio la JTextArea della GUI:
jGuiTextArea.append(message);
Mentre l'applicazione web possiede un proprio handler, con il layout simile al layout di
TextAreaHandler ma con destinazione un oggetto di tipo StringBuilder associato ad un
componente di tipo Text Box del framework utilizzato:
this.sb.append(message);
E' evidente da quanto descritto come l'accoppiamento sia diminuito: il tool desktop-based
e la web application sfruttano gli stessi log catturati con handler diversi: qualsiasi futura
estensione di entrambi i tool può usufruire degli stessi log senza interventi al codice,
creando handler diversi e personalizzandone il layout.
37
Capitolo 3
Tecnologie e Strumenti per le Rich Internet Applications
Il presente capitolo descrive il secondo passo della progettazione del tool web-based per la
simulazione remota di WSN, il quale si focalizza nella ricerca effettuata sulle tecnologie
per implementare la web application o, più in generale, una RIA (Rich Internet
Application). Verrà illustrato quali sono le più diffuse tecnologie disponibili oggi sul
mercato, come queste riflettono alcune metriche di valutazione scelte per questo progetto,
e quali sono i vantaggi e gli svantaggi di adottare un software piuttosto che un altro. La
scelta e la sua motivazione della tecnologia realmente adottata per lo sviluppo di questo
tool verrà affrontata nel capitolo 4, dove verrà descritto in maniera più dettagliata il
framework ZK.
3.1 Le RIA e metriche di valutazione
Da un breve sguardo sui requisiti del tool web based si nota subito che l’applicazione web
deve riflettere quanto più possibile l’applicazione desktop del generatore dei modelli di
fallimento e d’altra parte deve possedere una funzionalità di disegno che, anche se
semplice, deve somigliare quanto più possibile and un’applicazione desktop di disegno
diagrammi. Da ciò nasce l’esigenza di implementare non una normale web application, ma
una Rich Internet Application (RIA). La differenza tra queste due applicazioni sembra
sottile, ma diventa molto chiara descrivendo cosa sono RIA:
«Le Rich Internet Application (RIA) sono applicazioni web che possiedono le
38
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
caratteristiche e le funzionalità delle applicazioni desktop, senza però necessitare
dell'installazione sul disco fisso.»
Le RIA si caratterizzano per la dimensione interattiva, la multimedialità e per la velocità
d'esecuzione: parte dell'applicazione che elabora i dati è trasferita a livello client e fornisce
una pronta risposta all'interfaccia utente, mentre la gran parte dei dati e dell'applicazione
rimane sul server remoto, senza appesantire il computer utente: esse si fondano perciò su
un'architettura di tipo distribuito.
L'interazione con una RIA avviene in remoto, tramite un comune web browser: pertanto
esse rappresentano una generazione di applicazioni che permettono un'interazione
totalmente rinnovata, fondata sugli aspetti migliori delle caratteristiche funzionali e
progettuali che finora erano prerogativa alternata del web o delle applicazioni desktop.
Per tale livello spinto di interattività che esse offrono, le Rich Internet Application
rappresentano uno dei canali migliori attraverso il quale si va imponendo il paradigma del
Cloud Computing, che costituisce una nuova modalità di fruizione del software tramite
architetture distribuite.
Con questa premessa si sono esclusi, durante la ricerca della piattaforma software più utile
all’implementazione del progetto, quei linguaggi e quelle tecnologie che si discostano dal
concetto di RIA, ed in particolare sono state escluse a priori quelle tecnologie software
che durante il loro funzionamento impongono i seguenti vincoli:
Il refresh della pagina sul browser web: caratteristica dei siti web in generale e
vincolo necessario fino a pochi anni fa, il refresh della pagina del client riduce
drasticamente l’interazione tra client e applicazione web, ed oltretutto risulta scomodo
ed inefficiente per lo sviluppatore di WSN che cerca di disegnare sul proprio browser
la topologia della rete.
La disposizione e il controllo dell’interfaccia grafica diversa dalle applicazioni
tradizionali: Lo sviluppatore WSN ma anche l’utente in generale sono abituati a
software desktop-based che presentano interfacce grafiche i cui componenti sono tutto
sommato simili: finestre, aree testuali e label, barre degli strumenti, barre di stato,
layout, canvas, etc.: si deve pertanto cercare di rendere l’uso della web application
39
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
quanto più simile all’esperienza di utilizzo delle applicazioni desktop-based.
I controlli degli input dell’utente non in tempo reale: il paradigma nel quale gli input
del client vengono direttamente spediti al server e, nel caso in cui sono errati o non
soddisfano determinati criteri, il server rimanda una risposta negativa al client, rende
l’uso dell’applicazione lento e produce un traffico internet maggiore rispetto al caso in
cui gli input del client vengono controllati direttamente dal client stesso.
La scelta della piattaforma software adottata si è basata innanzitutto sui vincoli appena
esposti, e ciò ha delineato una scelta obbligata sulla tecnologia AJAX e sull’utilizzo,
possibile ma non obbligatorio, del linguaggio Javascript
3.1.1 AJAX e JavaScript
L'acronimo AJAX, che significa esattamente Asynchronous JavaScript And XML
(JavaScript asincrono ed XML), è stato enunciato per la prima volta da Jesse Garrett, nel
18 Febbraio 2005 nel suo blog[s2]. Non si tratta di una nuova tecnologia né di
un'invenzione bensì di un concetto utilizzato per sviluppare applicativi avanzati e
particolari quali Gmail, Google Maps o Google Suggest. Il concetto è in parte espresso
nell'acronimo scelto, un utilizzo asincrono di Javascript che attraverso l'interfacciamento
con XML, può permettere ad un client di richiamare informazioni lato server in modo
veloce e trasparente, allargando gli orizzonti delle Rich Internet Applications. In
alternativa a queste tecniche di interazione client/server, quando nel 1996 venne introdotto
l'iframe in Internet Explorer 3, molti sviluppatori sfruttarono quest' ultimo modificando
l'attributo sorgente (src) della pagina racchiusa e simulando così un refresh trasparente di
una parte di contenuti, il che emulava, in modo abbastanza sporco, un'interazione
asincrona. Nel 1998 Microsoft cominciò a sviluppare una tecnologia, chiamata Remote
Scripting, con lo scopo di creare una tecnica più elegante per richiamare contenuti
differenti ed è in questo periodo, seppur con nome differente, che AJAX venne utilizzato
per la prima volta, per poi evolversi in versioni più mature fino a diventare un oggetto vero
e proprio, noto ora come XMLHttpRequest.
Il motivo principale di tanto successo è che solo ultimamente il Remote Scripting ha
40
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
suscitato lo stupore degli addetti ai lavori nel vedere cosa Google fosse riuscita a fare
all'interno dei suoi applicativi senza necessità di Flash Player o Java Virtual Machine,
mantenendo comunque la compatibilità con molteplici browser di utenti che per diversi
motivi non potevano usufruire di Javascript. Come spesso è accaduto negli ultimi anni,
molti hanno preso spunto da Google ed il web, noto per la sua immediatezza propositiva, è
stato in grado in poco più di un anno di regalarci numerosi esempi di applicativi basati su
AJAX, esagerando in alcuni casi nell'utilizzo ma considerando molto spesso e fin da
subito, a differenza di quanto accadde per Flash ed Applets anni prima, due delle
problematiche più diffuse del web attuale: accessibilità ed usabilità.
L'oggetto base di questa tecnologia è ovviamente XMLHttpRequest, che a seconda del
browser usato prende nomi differenti o viene richiamato in maniera differente: nel caso di
Internet Explorer, ad esempio, questo oggetto è restituito da un ActiveXObject mentre nei
browsers alternativi più diffusi (Mozilla, Safari, FireFox, Netscape, Opera, Internet
Explorer 7 e successivi, etc.) XMLHttpRequest è supportato nativamente.
Questo oggetto permette di effettuare la richiesta di una risorsa (con HTTP) ad un server
web in modo indipendente dal browser. Nella richiesta è possibile inviare informazioni,
ove opportuno, sotto forma di variabili di tipo GET o di tipo POST in maniera simile
all'invio dati di una form. La richiesta è asincrona, il che significa che non bisogna
necessariamente attendere che sia stata ultimata per effettuare altre operazioni,
stravolgendo sotto diversi punti di vista il flusso dati tipico di una pagina web.
Generalmente infatti il flusso è racchiuso in due passaggi alla volta, richiesta dell'utente
(link, form o refresh) e risposta da parte del server per poi passare, eventualmente, alla
nuova richiesta da parte dell' utente. Ciò che resta del vecchio flusso, il tempo di attesa,
passa spesso in secondo piano ed in molti tipi di interazione è praticamente impercettibile.
L'utilizzo di questa tecnologia in senso puro non può divincolarsi dalla conoscenza, anche
lieve, del linguaggio Javascript, di cui ora si descrivono brevemente l'etimologia e le sue
caratteristiche.
JavaScript è un linguaggio di scripting orientato agli oggetti comunemente usato nei siti
web. Fu originariamente sviluppato da Brendan Eich della Netscape Communications con
41
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
il nome di Mocha e successivamente di LiveScript, ma in seguito è stato rinominato
"JavaScript" ed è stato formalizzato con una sintassi più vicina a quella del linguaggio
Java. Esso è stato standardizzato per la prima volta tra il 1997 e il 1999 dalla ECMA con
il nome ECMAScript, ed è diventato uno standard ISO a partire dal 1999 (JavaScript 1.5).
La caratteristica principale di JavaScript è quella di essere un linguaggio interpretato: Il
codice quindi non viene compilato bensì c'è un interprete (in JavaScript lato client esso è
incluso nel browser che si sta utilizzando) che esegue riga per riga, a tempo di esecuzione,
quanto trascritto nello script. JavaScript presenta quindi tutte le caratteristiche di un
normale linguaggio interpretato (e di conseguenza i suoi vantaggi e svantaggi) con una
sintassi analoga a quella di un linguaggio compilato (essa è relativamente simile a quella
del C, del C++ e del Java), quindi con la possibilità di utilizzare funzionalità tipiche dei
linguaggi di programmazione ad alto livello (strutture di controllo, cicli, etc.) e con in più
anche la potenzialità di definire strutture più complesse, vicine a quelle adottate nei
normali linguaggi object oriented (creazione di prototipi, istanziazione di oggetti,
costruttori). Un'altra caratteristica importante di JavaScript consiste nel suo essere un
linguaggio debolmente tipizzato, ovvero il tipo delle variabili può non essere assegnato in
fase di dichiarazione e le variabili stesse vengono convertite in maniera automatica
dall'interprete. Inoltre JavaScript è un linguaggio debolmente orientato agli oggetti: ad
esempio il meccanismo dell'ereditarietà si discosta molto da Java e i suoi stessi oggetti
ricordano più gli array associativi del linguaggio Perl che gli oggetti di Java o del C++.
In JavaScript lato client il codice JavaScript viene eseguito interamente sul client, quindi il
server non viene sollecitato. Ciò risulta essere vantaggioso in quanto con la presenza di
script particolarmente complessi il server non verrebbe sovraccaricato. Di contro però, nel
caso di script che presentino una considerevole mole di dati, il tempo per lo scaricamento
potrebbe diventare troppo lungo.
Sebbene cominciare ad utilizzare AJAX sia abbastanza semplice e le conoscenze
necessarie potrebbero essere di livello molto basso, tutt'altro discorso vale per creare
applicativi ed interazioni avanzate: la padronanza nell'utilizzo del DOM (Data Object
Model) per la creazione avanzata di contenuti strutturali e per la manipolazione di file
42
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
XML, e le conoscenze di (X)HTML, CSS, XML ed XSLT (anche al di fuori di ambienti di
sviluppo visuali WYSIWYG come DreamWeaver, FrontPage, GoLive, etc.) fa sì che lo
sviluppatore utilizzi framework che si basano su AJAX piuttosto che utilizzare
direttamente questa tecnologia. D'altro canto però, la necessità di adattare vari tool
disponibili per le proprie esigenze (come ad esempio google maps, fogli di calcolo open
source oppure script per disegnare diagrammi) obbligano comunque la conoscenza del
linguaggio Javascript.
3.1.2 Caratteristiche e metriche di valutazione dei framework
Restando vincolati alla tecnologia AJAX, la scelta di un framework adatto per
implementare Web Failure Model WSN Generator si è basata considerando i seguenti
parametri:
Integrazione con Java: il tool desktop-based di cui si basa la web application è scritto
utilizzando esclusivamente il linguaggio Java, quindi il framework scelto dovrà il più
possibile interagire ed essere compatibile con tale linguaggio, con l’obiettivo da parte
dello sviluppatore di non implementare inutile codice wrapper, di adattamento.
Estensibilità: il framework deve supportare pattern e metodologie di sviluppo che
permettano interventi al codice nella maniera più efficiente possibile, e magari deve
essere permettere una facile integrazione con altri tool ed altri linguaggi di sviluppo
diversi da Java e Javascript.
Qualità del supporto: intesa in questo senso come la capacità del framework di essere
manutenuto e migliorato nel tempo. L’affidabilità del framework deve anche riflettersi
sul suo supporto dato dagli sviluppatori nel tempo, e magari suo successo ed
importanza nella community del Web 2.0.
Curva di Apprendimento: il framework deve avere una curva di apprendimento più
bassa possibile, tale da adattarsi ai tempi di sviluppo di un lavoro di tesi e alla
disponibilità dei futuri sviluppatori nell’imparare altri linguaggi di cui non hanno
un’immediata padronanza.
Strumenti di supporto: il framework deve essere dotato di strumenti di sviluppo e di
43
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
supporto
alla
web
appllication
in
modo
da
rendere
agevole
e
rapida
l’implementazione. Inoltre deve avere un parco di componenti a disposizione molto
ampio, come ad esempio componenti grafici, strumenti di report, gestione dei
database, etc.
Costi di sviluppo: sia in termini di tempo sia in termini economici, i costi di sviluppo
derivanti dall’utilizzo del framework devono essere i più bassi possibile: ad esempio è
preferibile utilizzare tecnologie open-source, ma deve essere un open.-source ben
documentato e supportato.
Alla luce di queste caratteristiche, vengono di seguito proposti ed analizzate varie
piattaforme software per lo sviluppo di RIA: ovviamente non saranno tutte le tecnologie
presenti sul mercato al giorno d’oggi, ma rappresentano le più famose, valide e
supportate attualmente, con uno sguardo d’attenzione ai canoni da seguire descritti
precedentemente
3.2 Java Server Pages e IceFaces
Come prima piattaforma software per lo sviluppo di RIA si parte da JSP (Java Server
Pages), poiché fa parte della versione enterprise di Java, nota come Java EE (Java
Enterprise Edition, o in passato J2EE) la quale rappresenta lo standard de facto per
sviluppare applicazioni di tipo enteprise e mission critical. Java Server Pages è una
tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in
formato HTML o XML. Si basa su un insieme di speciali tag con cui possono essere
invocate funzioni predefinite o codice Java (JSTL). In aggiunta, permette di creare librerie
di nuovi tag che estendono l'insieme dei tag standard (JSP Custom Tag Library). Le
librerie di tag JSP si possono considerare estensioni indipendenti dalla piattaforma delle
funzionalità di un Web server: nel contesto della piattaforma Java, la tecnologia JSP è
correlata con quella dei servlet. All'atto della prima invocazione, le pagine JSP vengono
infatti tradotte automaticamente da un compilatore JSP in servlet. Una pagina JSP può
quindi essere vista come una rappresentazione ad alto livello di un servlet. Per via di
questa dipendenza concettuale, anche l'uso della tecnologia JSP richiede la presenza, sul
44
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Web server, di un servlet container, oltre che di un server specifico JSP detto motore JSP
(che include il compilatore JSP); in genere, servlet container e motore JSP sono integrati
in un unico prodotto (per esempio, Tomcat svolge entrambe le funzioni).
Quindi le Pagine JSP sono in effetti un'estensione diretta dei Servlet Java e offrono,
rispetto ad altre attuali tecnologie Server-Side, il vantaggio e la possibilità di separare la
sezione di gestione delle operazioni e di produzione dei contenuti, da quello di
visualizzazione vera e propria.
I vantaggi di utilizzare JSP seguono dal fatto che:
JSP supporta il contenuto dinamico basato sia sugli script che sugli elementi di tipo
markup e consente agli sviluppatori di creare librerie di tag personalizzate per
soddisfare eventuali necessità specifiche di determinate applicazioni.
Le pagine JSP sono compilate in modo da essere elaborate più velocemente dal server.
Le pagine JSP possono essere usate insieme alle servlet che gestiscono la logica
applicativa, il modello preferito dai template engine per servel Java
JSP è una specifica, non un prodotto. Ciò significa che i produttori possono
confrontarsi con implementazioni diverse, con uno sforzo che porta a prestazioni e
qualità migliori.
Essendo parte integrande di Java EE, JSP può svolgere il suo compito sia nelle
applicazioni più semplici che in quelle più complesse e impegnative.
Normalmente una Pagina JSP è composta da: i) porzioni di codice HTML, JavaScript,
CSS e così via, non compilati dal motore Jsp (Jsp Engine) e comunemente definiti
blocchi di codice statico, e ii) porzioni di codice Java, compilati dal motore Jsp, che
prendono il nome di blocchi di codice dinamico: ciò equivale a dire che utilizzando solo
JSP si avrà alla fine un prodotto non RIA, ma simile alle web application tradizionali,
con refresh della pagina del browser e tutto quanto descritto in precedenza. Per
aggiungere la tecnologia AJAX, la tecnologia JSP può essere arricchita attraverso
l’utilizzo di IceFaces.
ICEFaces[s3] è un framework Ajax opensource utilizzato dagli sviluppatori Java EE per
creare ed effettuare il deploy di Rich Internet Application (RIA) usando il linguaggio
45
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Java. ICEFaces sfrutta l'intero ecosistema di tools ed ambienti di esecuzione basati su
standard Java EE, e permette di sviluppare applicazioni RIA con numerose caratteristiche
sviluppate in Java senza bisogno di applet o plugin proprietari da integrare nel Browser.
Le applicazioni ICEFaces sono applicazioni JSP così che non ci sia bisogno dell'utilizzo
di Javascript, inoltre il meccanismo che sta alla base (Ajax) è completamente trasparente
allo sviluppatore. Ciò diviene possibile da un'architettura particolare di IceFaces, formata
da tre elementi:
1) Il Framework IceFaces: un'estensione del framework standard JSF con la
fondamentale differenza con cui viene tratta la fase di rendering. Diversamente da
JSF il rendering avviene nel DOM lato server e solo cambiamenti parziali sono
lasciati al browser ed in seguito assemblati con un bridge Ajax molto leggero. Il
risultato è un render fluido, effettuato solo su certi elementi della pagina. Ajax
utilizza le Api inizializzate dal server ed integra il meccanismo similmente al cycle di
JSF.
2) Il Bridge Ajax: presenta elementi lato server e lato client che coordinano la
comunicazione (basata su Ajax) fra il browser del client e l'applicazione lato server.
Il Bridge quindi si occupa di apportare i cambiamenti alla presentazione dalla fase di
rendering al browser del client e del riassemblamento di questi cambiamenti nel
DOM del browser per applicare i cambiamenti. Inoltre ha il compito di rilevare le
interazioni dell'utente con la presentazione e di portare le azioni dell'utente indietro
all'applicazione per essere processate dal JSP lifecycle. Un meccanismo chiamato
partial submit è integrato nei componenti di ICEFaces e facilita la generazione di
eventi attraverso il bridge. La prima volta che la pagina viene caricata viene creato il
bridge Ajax e coordina gli aggiornamenti della presentazione e la trasmissione degli
eventi dell'utente per tutto il lifetime dell'applicazione.
3) La Suite di componenti di ICEFaces: la suite fornisce tutti i componenti per la
costruzione dell'interfaccia grafica dell'applicazione. Include sia i componenti
standard di JSP e una vasta gamma di componenti che consente allo sviluppatore di
costruire applicazioni sofisticate e dall'interfaccia intuitiva. Oltre al meccanismo
46
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
succitato dell'interazione diretta con il DOM i componenti possono utilizzare un set
di effetti come il drag and drop tutto ciò con la semplice modifica di attributi così che
non si debba mai ricorrere a Javascript.
Applicando le metriche di valutazione del paragrafo 3.1.2 si è valutato che JSP insieme a
IceFaces possiede:
Una perfetta integrazione con Java: essendo JSP parte integrante delle tecnologie Java
Enterprise Edition ed essendo IceFaces basato di JSP, viene naturale da parte dello
sviluppatore Java scrivere una web application con tale linguaggio;
Un’ottima estensibilità: una web application con queste tecnologie può essere di
qualsiasi dimensione, semplice o complessa: inoltre nell’architettura Java EE è
integrata JSF (Java Server Faces), un’architettura basata sul pattern MVC (Model
View Controller), sfruttata soprattutto da IceFaces, che ben si presta a far crescere o
decrescere un progetto.
Un’ottima qualità del supporto: Java EE è la migliore tecnologia opensource sul
mercato per lo sviluppo di applicazioni enterprise, e IceFaces, nato nel 2001, è
diventato un prodotto leader nel mondo dei framework complementari basati sullo
standard JSF.
Bassa curva di apprendimento: rispetto agli altri framework analizzati, lo sviluppo di
un’applicazione web con Java EE, JSP, JSF e IceFaces obbliga lo sviluppatore ad
avere una buona padronanza di queste tecnologie, nonché una buona conoscenza dei
DOM, di XML, CSS, ed HTML. Una conoscenza di questo tipo comporta
sicuramente un’implementazione ottimale di un progetto in tempi più rapidi rispetto
all’utilizzo di altri framework, ma comporta anche un certo tipo di preparazione
sicuramente non ottenibile in tempi brevi.
Strumenti di supporto ottimi: queste tecnologie si affidano a tool di sviluppo Java
potenti e gratuiti: IBM Eclipse, Sun NetBeans, Oracle Jdeveloper. I tool di supporto
ad IceFaces si integrano perfettamente con i software appena citati. Per quanto
riguarda componenti di terze parti, l’edizione commerciale di IceFaces comprende, a
pagamento, moltissimi strumenti in più per lo sviluppo delle RIA: componenti come
47
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
un foglio di calcolo, un canvas per il disegno e strumenti di report devono però essere
“importati” in maniera manuale.
Bassi costi di sviluppo: nonostante la formazione teorica e pratica degli sviluppatori
per l’utilizzo di queste tecnologie comporti una spesa non trascurabile, si utilizzano
comunque piattaforme open-source, ottimamente documentate e supportate, le quali
abbattono sicuramente i costi di licenza.
Java EE, JSP e IceFaces sono state le prime tecnologie analizzate per questo lavoro di
tesi, e sarebbero state sicuramente scelte per l’implementazione di Web Failure Model
WSN Generator, se non fosse stato per la praticità e per la nuova (e innovativa)
metodologia di sviluppo che caratterizzano il framework che si è realmente scelto.
3.3 Openlaszlo
Openlaszlo[s4] è una piattaforma degna di nota soprattutto dal fatto che è stata una delle
prime ad offrire librerie e strumenti opensource per lo sviluppo delle RIA.
Originariamente nota col nome di Laszlo Persentation Server (LPS), dal 2004 diventa
opensource e mette a disposizione dello sviluppatore una piattaforma che produceva in
output dei file .swf (letti dal browser con il plug-in Flash) che costituivano la RIA,
programmata non utilizzando strumenti proprietari della Macromedia, ma attraverso un
linguaggio coniato dalla stessa società fondatrice, Laszlo System Inc.
Dalla versione 4.0B1 (2009) le applicazioni scritte utilizzando Openlaszlo possono
essere compilate non soltanto in file flash, ma anche in file DHTML, introducendo quindi
AJAX nello sviluppo. L’intera piattaforma è basata su due componenti principali:
1) Linguaggio LZX: un linguaggio risultante dalla fusione di aspetti dichiarativi,
derivanti dall’XML, con altri linguaggi tipici della programmazione Object-Oriented.
2) Openlaszlo Server: una particolare servlet Java che compila le applicazioni LZX in
binari eseguibili per la macchina target.
In pratica le applicazioni Laszlo possono essere sviluppate come tradizionali servlet Java,
il cui output viene dinamicamente restituito al browser (in questo caso è necessario che il
WebServer abbia in esecuzione l'OpenLaszlo server) o, in alternativa, le applicazioni
48
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Laszlo possono essere compilate da LZX in un file SWF e caricate staticamente in una
pagina web esistente. Questa tecnica è nota come "SOLO deployment". Le applicazioni
sviluppate in questo modo mancano di alcune funzionalità rispetto alla versione basata su
servlet, come ad esempio la possibilità di interazione con Web Services tramite il
protocollo SOAP e la possibilità di effettuare invocazioni a procedure remote (RPC)
XML. In aggiunta, nel luglio 2009 è nato un progetto, di matrice italiana, di nome
“eu4ria” che ha l’obiettivo di integrare le applicazioni Openlaszlo con le componenti lato
server di un’applicazione Java EE in maniera semplice. In pratica il progetto consiste in
una serie di annotations nel codice Java, dalle quali vengono generate stubs in LZX in
maniera da invocare metodi di Java nel codice LZX. I criteri adottati nell’analisi dei
framework fanno sì che Openlaszlo possiede:
Una scarsa integrazione con Java: nonostante Laszlo Server sia una servlet Java, lo
sviluppatore utilizza prettamente il linguaggio LZX, il quale non è solo di tipo
dichiarativo: il progetto eu4ria d’altronde non è ancora maturo per essere un buon
brigde tra Java e LZX, soprattutto per applicazioni complesse;
Scarsa estensibilità: benché si presti bene a progetti software di piccole e medie
dimensioni, Openlaszlo si presta poco ai design pattern e all’integrazione con codice
di terze parti;
Buona qualità del supporto: Openlaszlo è comunque un framework molto supportato
dall’azienda e dalla comunità opensource: si può dire che al principio è partito non
molto bene (offrendo in output dei file flash, tecnologia chiusa e incompatibile con
molti sistemi hardware) ma sta proseguendo una buona strada supportando l’HTML
Dinamico, e l’esperienza che sta accumulando questi anni ne sta accrescendo
notevolmente l’utilizzo e il supporto.
Buona curva di apprendimento: il linguaggio LZX, anche se usato solo per
Openlaszlo, è molto simile a JavaScript, e sono presenti in rete molti esempi e molta
documentazione per apprenderlo velocemente. L’utilizzo del progetto eu4ria per
l’interfacciamento con Java comporta solo la padronanza, da parte dello sviluppatore,
dell’utilizzo delle annotations.
49
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Strumenti di supporto sufficienti: nonostante la poca maturità del framework, i tool di
sviluppo messi a disposizione da Openlaszlo sono stabili, efficienti e gratuiti; ma
l’assenza di strumenti di report, fogli di calcolo, mappe e canvas e la mancanza di
integrazione di tool di terze parti si nota ed è molto forte.
Bassi costi di sviluppo: sia in termini di tempo sia in termini economici, i costi di
sviluppo derivanti dall’utilizzo di Openlaszlo sono molto bassi: infatti questo
framework viene spesso definito dalla comunità di sviluppatori RIA come
l’alternativa opensource ed economica ad Adobe Flex.
3.4 Adobe Flex
Nonostante non abbia nessun tipo di supporto alla tecnologia AJAX, Adobe Flex[s5] è
degno di menzione poiché si è affermato quale principale piattaforma tecnologica per la
realizzazione di RIA: in effetti il termine Rich Internet Application è stato coniato
proprio dall’azienda Macromedia (acquisita in seguito da Adobe) nel marzo del 2002[s6],
e con la tecnologia Flash Adobe ha cercato sempre di offrire un’esperienza utente
innovativa rispetto alle tecnologie presenti. Dalla versione 3 (la versione attuale è la 4 ed
il nome del tool di progettazione e compilazione cambia da Flex Builder a Flash Builder
4) la tecnologia Flex è diventata opensource, nonostante tutti i tool per utilizzarla siano
closed e non-free.
Il punto di partenza di questo framework è stato il fatto che i programmatori tradizionali
di applicazioni hanno trovato impegnativo doversi adattare alla metafora di animazione
su cui la piattaforma Flash originalmente è stata sviluppata. Flex cerca di minimizzare
questo problema fornendo un workflow e un modello di programmazione noto a quegli
sviluppatori, attraverso l’utilizzo di un linguaggio XML denominato MXML per la
stesura di interfacce utente, e tramite un linguaggio di scripting noto come Actionscript,
simile a Javascript e basato anch’esso sulla programmazione ad oggetti. Flex
inizialmente è stato rilasciato come una applicazione Java EE o JSP che compilano
MXML e ActionScript al volo in applicazioni Flash (file binari SWF). Le versioni
successive di Flex supportano la creazione di file statici che vengono compilati nello step
50
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
di creazione e possono essere pubblicate online senza la necessità di una licenza server.
Flex è già provvisto di componenti e caratteristiche come web services, remote objects,
drag and drop, sortable columns, charting/graphing, built in animation effects e altre
semplici interazioni. Il client viene caricato una volta sola, il workflow è migliorato
moltissimo a differenza delle applicazioni non RIA (eg. PHP, ASP, JSP, ColdFusionMX)
le quali richiedono l'esecuzione di interi processi per ogni azione. Il linguaggio Flex e la
sua strutturazione in sorgenti MXML per la GUI ed ActionScript per la Business Logic
sono studiati per distinguere la logica della programmazione dal design implementando
di fatto il Design pattern MVC. Inoltre, il server Flex funziona come gateway per
permettere al client di comunicare con XML Web Services le Remote Objects (come
Coldfusion CFCs, classi Java, e qualsiasi altra cosa che integra Action Message Format).
Un componente particolarmente utile per interfacciare Flex con Java, escludendo il
commerciale WebOrb[s7], è il progetto opensource BlazeDS[s8], una tecnologia lato server
che offre tre tipi di servizi:
Remoting Service, che permette di richiamare metodi di Java object sul proprio
application server direttamente dall’applicazione sviluppata in Flex;
Message Service, che fornisce un’infrastruttura di tipo publish/subscribe;
Proxy Service, che permette di effettuare richieste a servizi di tipo cross-domain
BlazeDS è nato come parte integrante del componente Adobe LiveCycle Data Services
ES, una suite che permette una più ampia interazione con dati e business logic di
applicazioni Enterprise. Concludiamo questa breve descrizione di Flex descrivendone le
caratteristiche adatte al progetto Web Failure Model WSN Generator. Per
quest’applicazione web Adobe Flex presenta:
Una buona integrazione con Java: WebOrb, BlazeDS e LiveCycle Data Services sono
progetti maturi ed efficienti per integrare tecnologie flash con Java, e forse lo
sviluppatore di RIA impega più tempo a configurare questi servizi che ad adattare il
codice Java dell’applicazione desktop-based all’interfaccia in Flash.
Buona estensibilità: la piattaforma software sviluppata da Adobe oggi si presta bene
sia per piccoli progetti in espansione che per grandi progetti di tipo enterprise.
51
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Ottima qualità del supporto: Macromedia ha coniato il termine RIA, ed Adobe ha
sempre investito sul web dinamico. Da molti anni si è maturato in tutto il mondo il
supporto e la formazione, sia in termini commerciale sia in free community.
Curva di apprendimento media: oltre alla padronanza di Java e la conoscenza di Java
EE o del framework Spring, lo sviluppatore deve imparare altri due linguaggi, MXML
ed ActionScript: i tempi di sviluppo rispetto alla scelta di altri framework sono
mediamente più lunghi
Buoni Strumenti di supporto: Flex Builder è basato su Eclipse, e mette subito a suo
agio lo sviluppatore. Inoltre il parco software trovabile in rete di componenti per il
reporting, fogli di calcolo, diagrammi e canvas è molto ampio, anche se prettamente
closed e non-free.
Alti costi di sviluppo: l’SDK di Adobe Flex e BlazeDS sono gli unici prodotti privi di
costi di licenza. Tutti gli altri strumenti, compreso l’editor, i diagrammi, e le
tecnologie per l’accesso avanzato ad applicazioni enteprise sono a pagamento ma con
un buon supporto.
Nonostante Flex sia una tecnologia stabile ed efficiente per lo sviluppo di RIA, al giorno
d’oggi un punto debole resta proprio l’output in Flash che, rispetto ad AJAX, è closedsource e risulta spesso incompatibile e di scarse prestazioni in molti dispositivi client.
3.5 Echo 3
Il web framework Echo3[s9] è la prima tecnologia analizzata che unisce i vantaggi di
Openlaszlo a quelli di Adobe Flex e, insieme ad altri framework (compreso quello
scelto) introduce un concetto di sviluppo RIA innovativo: adattare il modello ad oggetti
Swing per lo sviluppare web application event-driven. Questo concetto, approfondito nel
prossimo capitolo, fa sì che lo sviluppatore implementi rich internet applications in tempi
brevi, utilizzando AJAX ma senza conoscere Javascript e il modello DOM, con la quasi
totalità del codice scritto nel linguaggio Java.
Infatti le applicazioni Echo3 sono compilate in byte code Java e vengono eseguite su un
server Java. Il loro Java code è eseguito dallo strato “Web Application Container” di
52
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Echo3, che risiede sopra una Servlet Java. Dal lato browser, il “Client Engine” di Echo
comunica ciò che è stato inviato dall’utente al Web Application Container tramite
richieste AJAX, con il server che risponde con direttive in modo da apportare
aggiornamenti incrementali allo stato del browser client.
Le componenti di Echo3 sono progettate per minimizzare una comunicazione
client/server il più possibile, limitandola nei tempi in cui il server deve essere notificato
immediatamente di eventi (ad esempio, semplici eventi come un input dell’utente in un
componente TextField non darà luogo ad una richiesta al server). La risposta del server è
il minimo insieme di istruzioni per l’aggiornamento incrementale del client, in modo da
riflettere uno nuovo stato della finestra del web browser. Inoltre i moduli Javascript del
framework Echo3 sono caricati pigramente (lazy-loaded) al client e da lì in poi messi in
cache. Un modulo sarà recuperato quando un componente che appare sul browser client
lo richiede. Il codice dell’applicazione non è mai mandato al client, solo lo stato
aggiornato dell’interfaccia utente.
Le applicazioni Echo3 supportano l’uso di una logica di applicazione distribuita o un
SOA (Service Oriented Architecture) o possono alternativamente essere costruite per
eseguirsi interamente su una singola istanza della JVM, appoggiata da un middle tier di
tipo POJO (Plain Old Java Object). Questo permette agli sviluppatori di costruire
applicazioni senza preoccuparsi della sicurezza della logica di applicazione distribuita –
affidata a robusti framework come Spring e Hibernate: inoltre, nessun oggetto remoto ha
bisogno di essere "esposto", poiché questo framework memorizza l’intero stato
dell’interfaccia web dell’utente sul server.
Per la scelta del framework da utilizzare, Echo 3 ha dimostrato di avere:
Un’ottima integrazione con Java: la web application può essere scritta direttamente
lato server in Java utilizzando API event-driven e component-oriented oppure, dalla
versione 3, utilizzando codice JavaScript lato client. La parte AJAX dell’applicazione
non è obbligatoriamente a carico dello sviluppatore.
Una buona estensibilità: la possibilità di integrare Struts, Hibernate e JSF con
applicazioni di terze parti (per la maggior parte però non ancora mature) rendono
53
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Echo 3 adatto anche per progetti di medie e grandi dimensioni
Sufficiente qualità di supporto: sia dalla società NextApp, autrice del framework, che
da molte applicazioni di terze parti, sono disponibili più prodotti in fase beta che
software stabile e maturo.
Bassa curva di Apprendimento: la buona documentazione a corredo e la caratteristica
di Echo 3 di essere basato solo su Java e Javascript rendono l’apprendimento del
framework semplice e veloce
Strumenti di supporto sufficienti: l’editor per l’implementazione di interfacce grafiche
in echo, a pagamento, non è attualmente stabile per la versione 3. I componenti di
terze parti per reportistica, diagrammi e fogli di calcolo scarseggiano e spesso bisogna
ricorrere a componenti esterne in JavaScript o Flash.
Bassi Costi di sviluppo: Echo 3 è nato opensource, ed i costi da sostenere si riflettono
solo sul suo tool eclipse-based.
Presente nel web 2.0 dal 2005, il framework Echo 3 non ancora è riuscito ad affermarsi
rispetto agli altri framework presi in esame, nonostante la presenza di molti componenti
che, anche se in fase beta, lo rendono un prodotto interessante e all’avanguardia.
3.6 Google Web Toolkit
Essendo più un set di tools che un vero e proprio framework, Google Web Toolkit è uno
strumento degno di nota poiché ha contribuito notevolmente alla diffusione di Javascript
e AJAX (le stesse Gmail e Google Maps, applicazioni che hanno destato molta curiosità
e diffusione su internet, sono web application create con questa libreria) ma soprattutto
perché possono trovarsi sul web molti framework per sviluppo RIA basate su questa
tecnlologia (tra i più importanti citiamo Ext GWT[s10], SmartGWT[s11] e Vaadin[s12])
Google Web Toolkit (GWT) è un framework Java per scrivere applicazioni AJAX il cui
approccio è quello di permettere di scrivere le applicazioni utilizzando sempre il
linguaggio Java e solo alla fine convertire (tramite il compilatore di GWT) da classi Java
a codice Javascript e HTML browser compliant (Internet Explorer, Firefox, Mozilla e
Safari per ora). Infatti il ciclo di sviluppo con GWT si può riassumere nel modo
54
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
seguente:
1. Utilizzo di un IDE Java (Eclipse, Netbeans, Junit, IntelliJ, Jprofiler, ecc.) per scrivere
l'applicazione scritta in linguaggio Java, con l'ausilio di alcune librerie messe a
disposizione da GWT.
2. Test dell'applicazione (Hosted Mode) come codice Java compilato che gira all'interno
della JVM.
3. Utilizzo del compilatore GWT per convertire le classi Java in un'applicazione web
composta da files JavaScript e HTML.
4. Verifica dell'applicazione (Web Mode) con i browser che si vuole supportare.
Per implementare questo ciclo di sviluppo, GWT è composto principalmente da 4
componenti:
1. Compilatore GWT Java-to-JavaScript: converte il codice Java in codice Javascript.
Deve essere utilizzato quando si vuole eseguire l'applicazione in modalità "web
mode".
2. GWT Hosted Web Browser: permette di eseguire le applicazioni in modalità "hosted
mode", ossia di eseguire il codice Java nella JVM senza convertire il codice in
linguaggio JavaScript/HTML. Per fare questo, il browser GWT include speciali
librerie per Internet Explorer su Windows e Gecko/Mozilla su Linux.
3. JRE emulation libraryGWT: Contiene le implementazioni in linguaggio Javascript
delle librerie Java standard maggiormente utilizzate (package java.lang.* e
java.util.*). Tutti gli altri package (ad es. java.io.*, java.net.*, ecc.) non sono
supportati nativamente da GWT.
4. GWT Web UI class library: libreria User Interface contenente un insieme di
interfacce e classi che permettono di disegnare le pagine web (ad es. bottoni, text
boxes, immagini, ecc.) . Questa è la libreria principale per creare applicazioni webbased basate su GWT.
GWT compila i sorgenti Java compatibili con J2SE 1.4.2. Ovviamente, dovendo il
compilatore fare una conversione da Java a Javascript, non è supportato tutto il
linguaggio Java ma solo una parte: ad esempio il tipo long è supportato ma, non
55
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
esistendo in Javascript, questo tipo viene convertito come numero floating point doubleprecision; così come GWT non è in grado di utilizzare la finalizzazione degli oggetti
durante il Garbage Collection in quanto non è supportato dal linguaggio Javascript,
oppure GWT accetta le istruzioni di sincronizzazione ma, essendo Javascript un
linguaggio single-threaded, non ha effetti in esecuzione.
L’utilizzo pratico di questo set di tool opensource è di creare semplici ma potenti
interfacce utente per web application: il collegamento il codice prodotto (ma anche
codice Javascript proprietario) con codice sorgente Java di classi business avviene
attraverso la JavaScript Native Interface (JSNI) e attraverso il meccanismo Remote
Procedure Call (RPC): in particolare per far comunicare l’applicazione con il web
server, è sufficiente definire le classi Java che si vogliono utilizzare nel colloquio come
serializzabili ed è stesso GWT che si preoccupa del trasporto: per testare sia l’interfaccia
utente che i colloqui RPC, è possibile utilizzare JUnit.
Come scelta di utilizzare Google Web Toolkit per il nostro progetto abbiamo che questo
framework presenta:
Una buona integrazione con Java: il codice è scritto e testato in Java e
successivamente convertito in JavaScript automaticamente, ma i tipi, la gestione delle
eccezioni e il multi-threading non sono completamente disponibili, e c’è bisogno di
uno sforzo ulteriore da parte dello sviluppatore di separare bene ciò che può essere
implementato con GWT e ciò che deve essere puramente lasciato in Java.
Una sufficiente estensibilità: essendo in sintesi una libreria che permette “traduzione”
di codice, pattern e metodologie di sviluppo sono supportate comunque, ma per la
gestione di progetti di media grandezza è consigliabile comunque affidarsi ad altri
framework basati su GWT piuttosto che utilizzarlo direttamente.
Buona qualità del supporto: dietro a GWT c’è Google, e versioni stabili vengono
rilasciate con molte frequenza. Inoltre il progetto è molto supportato dalla community
opensource.
Bassa curva di Apprendimento: basterebbe solo la conoscenza di Java per produrre
applicazioni web utilizzando GWT.
56
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
Strumenti di supporto sufficienti: il framework non ha a corredo strumenti particolari
che estendono gli ambienti di sviluppo che già si usano per creare applicazioni con
Java: anche particolari software che estendono le funzionalità dell’applicazione creata
con GWT sono da ricercare altrove, per poi integrarli attraverso JSNI.
Bassi Costi di sviluppo: GWT è opensource, e i costi di sviluppo sono quelli che offre
il mondo Java in generale.
3.7 Apache Click
Un'alternativa interessante ai framework studiati, in particolar modo nel caso della
realizzazione di RIA in ambiente J2EE, è rappresentata da Click[s13], proposto da
Apache, che intende superare il modello di interazione basato su MVC, implementato da
framework come Struts, per passare a un modello event driven, tipico dei framework
come Swing.
La progettazione di un'interfaccia con Apache Click consiste nella definizione di almeno
due entità: una classe Java che estenda la classe Page, in cui andiamo a definire tutti gli
oggetti della nostra interfaccia grafica e i relativi eventi da associare agli stessi oggetti, in
maniera del tutto analoga a quanto avviene in Swing.
L'altra entità da definire è una pagina HTML, che si occuperà di visualizzare i controlli,
precedentemente definiti, e l'output dell'interazione con la stessa interfaccia. Tutto ciò è
possibile utilizzando Apache Velocity, un template-engine opensource in Java, che
interagisce con gli oggetti definiti nella classe sopra descritta, utilizzando una sintassi
decisamente comprensibile.
Inoltre Apache Click fornisce un discreto insieme di widget da poter utilizzare nelle RIA;
si integra con framework come Spring Security per quanto riguarda la realizzazione di
meccanismi di autenticazione, e cpm Cayenne per l'interazione con gli ORM.
Ad Apache Click non sono state applicate le metriche descritte nel paragrafo 3.1.2
poiché non è stata considerata una scelta valida rispetto ai framework elencati in questo
capitolo: i motivi principali sono stati la scarsa maturità del progetto (è il framework più
giovane, nato nel Novembre 2009) e non è all’altezza, per varietà ed estetica, dei
57
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 3: Tecnologie e strumenti per le Rich Internet Applications
framework menzionati.
Resta comunque una piattaforma degna di nota e da prendere in considerazione negli
anni a venire poiché è basata sull’esperienza dell’Apache Software Foundation ed è
incentrata su un modo di sviluppare RIA diverso e per certi versi innovativo, molto
simile a quello del ZK Framework, il framework scelto per Web Failure Model WSN
Generator: il direct RIA.
Come riassunto dalla seguente tabella, ZK è il framework che soddisfa in pieno le
metriche scelte per l’implementazione del tool web-based.
58
Capitolo 4
ZK Framework
Questo capitolo termina la fase di progettazione descrivendo il framework con cui è stata
implementata la Rich Internet Application: ZK Framework[s14] della Potix Corporation.
E' stato necessario suddividere questo capitolo dal precedente poiché la descrizione, le
caratteristiche, le features più importanti utilizzate nel progetto meritavano una sezione a
parte: si procede quindi ad analizzare questo framework introducendo prima le sue
caratteristiche, e in seguito approfondendo gli aspetti particolari che lo rendono
innovativo, flessibile e potente. Verranno poi approfondite le metriche di valutazione
scelte e il loro rapporto con ZK Framework, fornendo esempi pratici su questa tecnologia.
Si è preferito tralasciare gli aspetti puramente di programmazione ed analizzare più in
dettaglio cosa lo rende qualitativamente valido nella progettazione di un software.
4.1 Direct RIA: cos’è ZK Framework
Nel vasto mondo dei framework per lo sviluppo di applicazioni web, ZK si presenta come
un Web Framework basato su componenti Ajax, scritto interamente in Java e che permette
di creare ricche interfacce grafiche per applicazioni web senza alcun bisogno di utilizzare
il linguaggio JavaScript né Ajax. Inoltre ZK è open source, e ha adottato di recente la
licenza LGPL che permette di usarlo liberamente anche in ambito commerciale. La parte
centrale di ZK consiste sostanzialmente in un meccanismo "event-driven" basato su oltre
duecento componenti Ajax, e un linguaggio di mark-up (XUL/XHTML) usato per
59
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
disegnare le interfacce grafiche.
A differenza di altri framework basati su Ajax, ZK non richiede al progettista né al
programmatore alcuna conoscenza di Javascript per sviluppare applicazioni web basate su
Ajax, poiché il cuore di questa tecnologia auto-genera il codice Javascript necessario per il
corretto svolgimento dell’applicazione. Ciò si traduce nel fatto che per sviluppare una
web-application bisogna conoscere, oltre a Java, soltanto un minimo di html, poiché lo
sviluppo avviene come se fosse un’applicazione desktop. Questo è uno dei punti forza di
questo framework, ovvero ciò che viene definito dagli stessi creatori il Direct RIA, Rich
Internet Application Diretta, in cui la parte di interfaccia grafica e il controllo associato ad
essa vengono sviluppate come se si stesse utilizzando una qualsiasi libreria grafica, Swing
o AWT per esempio: direttamente vengono utilizzati componenti (bottoni, finestre, label,
container, etc.) direttamente vengono implementati listeners sugli eventi che si vogliono
monitorare (onClick, onChange, buttonPressed, etc.) e direttamente i risultati delle
elaborazioni vengono mostrate al browser, come se fosse una GUI desktop, senza accedere
o controllare i tipici eventi DOM della tecnologia AJAX. La semplificazione dello
sviluppo di web application avviene anche attraverso il ZK User Interface Markup
Language (ZUML) che consente di creare e aggiungere componenti all’interfaccia grafica
(effettivamente possiamo chiamarla così, invece di pagina web) semplicemente
dichiarando e chiudendo tag, così come si fa con HTML, XML e così via. Ovvero, ZK è
un framework che fondamentalmente implica il modello di programmazione desktop alle
applicazioni Web.
Prima di concludere questo paragrafo però, è interessante descrivere cosa ZK non è:
Il framework di base non ha alcun metodo rivolto alla persistenza dei dati; ZK è stato
progettato per essere più leggero possibile, e i metodi che permettono la memorizzazione
di oggetti e dati in file e database vengono delegate ad altre tecnologie che, come vedremo
in seguito, possono essere implementate con facilità nel framework. Inoltre non è nato per
supportare molti task a livello client (per giochi 3d ad esempio) e, a meno di scrivere
componenti personalizzati, non è nato per applicazioni che delegano la maggior parte del
computing ai client: di questo però possono delegarsi altre tecnologie, come ad esempio
60
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
JavaFX o Flash, anch’esse supportate nativamente come integrazione.
4.2 Caratteristiche principali di ZK Framework
La piattaforma software ZK è stata progettata per massimizzare l’efficienza della logica
enterprise e per minimizzare i costi di sviluppo attraverso l’innovativa architettura Direct
RIA. Visitando l’home page del progetto viene mostrata subito un immagine che
racchiude le caratteristiche peculiari del software:
Fig. 4.1 – la semplicità e l’efficienza del framework ZK nell’immagine in home page del progetto
definisce un linguaggio dichiarativo XML (ZUML) per le interfacce grafiche (View)
che risulta essere estremamente intuitivo e molto meno prolisso del corrispondente
linguaggio XML usato dallo standard JSF;
è basato su lancio di eventi e sull’utilizzo di componenti: in questa maniera permette
di utilizzare lo stesso modello di programmazione usato nelle applicazioni desktop
anche per le applicazioni web. In particolare, è dotato di un supporto Ajax ad alto
livello: gli input dell’utente dal web browser giungono attraverso Ajax al modello
desktop dell’applicazione lato server;
si integra in maniera trasparente con Spring, Spring Web Flow, Spring Security, Jboss
Seam, JSP, JSF, Flash plugin, EJB. Oltre al supporto nativo con Hibernate, è
61
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
caratterizzato da un databinding efficiente tra annotations in-page e campi POJOs lato
server;
supporto completo del CSS: componenti e interfacce grafiche sono personalizzabili
tramite fogli di stile ed è possibile creare temi e skin custom;
componenti grafici avanzati, dotati di drag-and-drop, context menu (pop-up menu) e
Comet server push;
permette di gestire i bookmark, ed è nativamente compatibile con i SEO (Search
Engine Optimization);
presenta numerosi componenti di terze parti come: JFreeChart, JasperReports, Google
Maps, FCKeditor, Timeline, Timeplot, ExtJS, Dojo;
supporta pattern differenti per la creazione di user interface;
ZK Script: è possibile scrivere il codice di script che lega la parte business con la parte
vista in molti linguaggi: Java, JRuby, Groovy, JavaScript ma anche Python e PHP.
è disponibile un ottimo editor WYSIWYG (come plugin per Eclipse) per disegnare e
avere una preview delle pagine che si stanno scrivendo;
ZK Mobile: possibilità di adattare la web application su dispositivi mobili (in
particolare su Android, BlackBerry e dispositivi con Java Mobile o dotati di web
browser) senza modificare la business logic e il codice backend ;
è principalmente server-centrico, ma la versione attuale supporta anche la
programmazione lato client in Javascript.
Le principali caratteristiche appena elencate sono sufficienti a far capire il perché sia stato
scelto questo framework per lo sviluppo di Web Failure WSN Generator: si preferisce
però approfondire, nei paragrafi successivi, in che modo le funzionalità di ZK sono state
utili nella realizzazione di questo lavoro di tesi.
4.3 Integrazione con Java: il funzionamento di ZK Framework
La nostra web application si basa, come prima realizzazione, principalmente sul tool
Failure Model WSN Generator: ed è per questo che si è scelta come prima qualità da
rilevare una perfetta integrazione con l’ambiente Java. Per comprendere come il
62
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
framework scelto si integri con quest’ambiente, basta descrivere il funzionamento che sta
alla base di ogni RIA scritta utilizzando ZK Framework.
Il diagramma seguente mostra che ZK è composto da tre componenti principali: ZK
loader, ZK AU Engine e ZK Client Engine.
Fig. 4.2 – Componenti principali di una RIA con ZK Framework
In ascolto alle richieste degli utenti, ZK Loader carica una pagina ZK, la interpreta, e
presenta i risultati ottenuti in pagine HTML in risposta a richieste di tipo URL.
In particolare una pagina ZK è scritta in un linguaggio di markup chiamato ZUML.
ZUML, come HTML, è usato per descrivere quali componenti creare e come
rappresentarli visualmente. Questi componenti, una volta creati, rimangono disponibili
finché non avviene un timeout di sessione.
ZK Client Engine e ZK AU Engine (Asynchronous Update Engine) lavorano sempre
insieme come "ascoltatore" e "notificatore" di messaggi: essi si scambiano eventi che
scaturiscono dalle azioni richieste dall'utente nel browser, e aggiornano il DOM tree lato
browser web in base a quanti componenti sono manipolati dall'applicazione: queste azioni
sono alla base della programmazione guidata dagli eventi (event-driven programming
model) per le web application.
Il Flusso di esecuzione di una RIA con ZK Framework può essere descritto più
chiaramente in questo modo.
1. Quando un utente digita l’indirizzo web o clicca su un hyperlink nel web browser,
63
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
viene fatta una richiesta al Web server: la richiesta, se l’indirizzo dell’applicazione è
corretto, viene servita da ZK Loader.
2. ZK Loader carica la pagina specificata e la interpreta per creare correttamente i
componenti richiesti dalla pagina.
3. Dopo aver interpretato l’intera pagina, ZK Loader presenta il risultato in una pagina
HTML. La pagina HTML viene mandata al browser dell’utente insieme allo ZK Client
Engine.
4. ZK Client Engine resta in ascolto nel browser per individuare qualsiasi evento
scatenato dall’attività dell’utente, come ad esempio spostamenti del mouse,
cambiamenti di valori, click sui componenti grafici. Appena individuato l’evento,
notifica lo ZK AU Engine con una speciale richiesta Ajax.
5. Appena ricevuta la richiesta Ajax, lo ZK AU Engine aggiorna se necessario il
contenuto del componente corrispondente, e notifica l’applicazione attraverso
l’invocazione di un handler di eventi (se esiste).
6. Se l’applicazione lato server sceglie di cambiare il contenuto del componente, o
aggiungere o rimuovere nuovi componenti, l’AU Engine spedisce il nuovo contenuto
dei componenti alterati al Client Engine usando particolari richieste Ajax (ZK
responses).
7. Le Zk Responses istruiscono il Client Engine ad aggiornare correttamente il DOM
tree.
Lo ZK Client Engine in particolare è interamente scritto in JavaScript, con il vantaggio di
essere messo in cache dai browser, e quindi spedito dal server al client solo alla prima
visita della web application. Tutto il procedimento appena descritto, a meno di particolari
esigenze, è nascosto al programmatore e presentato al web server attraverso servlet Java.
Tutta la logica che lo sviluppatore deve implementare (o, nel nostro caso, integrare) sfrutta
package Java del framework ZK, e a meno di particolari componenti customizzati, non c’è
bisogno di una conoscenza, neanche minima, di Javascript e Ajax: si è potuto realmente
constatare come nel nostro caso l’integrazione del tool di generazione di modelli di
fallimento è avvenuta in maniera semplice, utilizzando direttamente le classi interessate al
64
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
funzionamento, focalizzando l’attenzione solo alla view della web application non in
maniera tradizionale, ma con una programmazione java ad eventi. In sostanza,
l’impressione che si è avuta nell’implementazione dell’applicazione web-based è stata
un’attenta sostituzione dell’interfaccia di tipo swing originaria con un’altra, implementata
alla stessa maniera, ma che gira all’interno di un browser: ed è questo uno dei veri punti di
forza e di innovazione di questo framework.
4.3.1 Framework Server-Centrico e Client-Centrico
Prima di
continuare ad esaminare
come
la piattaforma
ZK
si
è prestata
all’implementazione del tool web based, è utile analizzare come funziona l’impatto di
questo framework sulle performance di una Rich Internet Application: le prestazioni sono
una metrica che è risultata non cruciale per il progetto, ma è comunque una caratteristica
da prendere in considerazione per futuri sviluppi del tool web-based. In realtà non esistono
test affidabili per misurare quali siano le reali performance di un framework web (in
particolare di quelli esaminati nel capitolo 3), ma possiamo basarci empiricamente su una
caratteristica base, ovvero quella di essere un framework server-centrico o client-centrico.
Fig. 4.3 – Workload tra Web framework Server Centrici e Client Centrici
Si può notare dalla figura precedente che nel caso di frame work client-centrici il carico
computazionale che comporta l’applicazione web, insieme a quello comportato
65
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
dall’interazione del framework con l’ambiente di esecuzione, sia distribuito sia sul client
che sul server: una web application sviluppata attentamente può ridurre notevolmente il
workload del server e migliorarne le prestazioni soprattutto in caso di richieste elevate e
numero elevato di client connessi ad esso (ciò può essere “un’arma a doppio taglio”,
poiché il codice JavaScript aumenta in proporzione alla complessità dell’applicazione
stessa, e quindi diventa facile "rallentare" il browser quando si devono creare molti
widget). Questo miglioramento di prestazioni va a discapito però della manutenzione del
codice; infatti un’architettura di questo tipo impone quasi sicuramente che la parte che
riguarda il client e la parte che riguarda il server siano scritte in due linguaggi differenti:
nel nostro caso ad esempio, scegliendo ZK framework il lato client deve essere scritto
interamente in JavaScript mentre la logica applicativa in Java.
Nel caso di framework Server Centrici il codice applicativo gira interamente sul server,
mentre il web framework si distribuisce tra server e client, in modo che ci sia una
“traduzione” automatica di messaggi tra loro: questo permette la possibilità di utilizzare un
solo linguaggio per gestire due ambienti, ma comporta un consumo di memoria e un
workload maggiore nel server, che aumentano all’aumentare dei client connessi ad esso.
ZK Framework è nato come una piattaforma server-centrica, ma a partire dalla versione
5.0 si possono scrivere applicazioni web client-centriche tramite Javascript: l’utilizzo che
si è fatto per la realizzazione del tool web-.based però è stato principalmente servercentrico per i seguenti motivi:
1. si è utilizzato direttamente il runtime environment di Java e le librerie incluse nel
server: questo è un vantaggio impossibile nelle architetture client-centriche.
2. il tool web-based con l'architettura server-centrica si è integrato efficacemente con il
codice dell'applicazione desktop remotizzata.
3. con il framework server-centrico, si è raggiunto l'obiettivo scrivendo molte meno righe
di codice rispetto all'utilizzo client-centrico, e sono state utilizzate strutture dati e
librerie scritte in Java, quindi molto più "comode" e manutenibili: si è avuto in questo
modo un aumento di produttività e una riduzione dei tempi di sviluppo.
Da questi motivi c’è da dire che il discorso sulle performance non viene automaticamente
66
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
abbandonato: cioè qualora si decida di migliorare l’efficienza del tool web-based, è
consigliabile di adottare tecniche di replicazione server o di cloud computing che svolgono
questo compito egregiamente piuttosto che “spostare” codice verso i client: la scelta del
framework da usare per scrivere la propria applicazione web infatti dovrebbe ricadere su
ciò che permette di completare il lavoro nel minor tempo possibile e contemporaneamente
di produrre un ottimo risultato.
4.4 Estensibilità: MVC, Spring, Hibernate ed Integrazione
ZK Framework mette a disposizione in maniera nativa diverse tecniche e tool per rendere
il software prodotto scalabile: queste tecniche sono opzionali (ad esempio non è necessario
produrre web application tramite pattern MVC, ma è fortemente consigliato dagli stessi
sviluppatori del framework) ma diventano obbligatorie qualora c’è l’esigenza di
accrescere o decrescere le funzionalità dell’applicazione sviluppata mantenendo una buona
manutenibilità del codice, soprattutto se questo codice deve adattarsi a progetti Java
esistenti o a servlet particolari. Tra le tecniche degne di nota, che saranno sicuramente
utilizzate negli sviluppi futuri del tool web-based, vengono analizzate il pattern MVC, i
tool Spring ed Hibernate, e l’integrazione di altri linguaggi e il loro rapporto con il
framework ZK.
4.4.1 Il Pattern MVC con ZK
Il pattern architetturale Model-View-Controller (MVC, talvolta tradotto in italiano
Modello-Vista-Controllore) è molto diffuso nello sviluppo di interfacce grafiche di sistemi
software object-oriented: esso è basato sulla separazione dei compiti fra i componenti
software che interpretano tre ruoli principali:
il model fornisce i metodi per accedere ai dati utili all'applicazione;
il view visualizza i dati contenuti nel model e si occupa dell'interazione con utenti e
agenti;
il controller riceve i comandi dell'utente (in genere attraverso la view) e li attua
modificando lo stato degli altri due componenti).
67
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
Questo schema, fra l'altro, implica anche la tradizionale separazione fra la logica
applicativa (logica di business) a carico del controller e del model, e l'interfaccia utente a
carico della view.
Per comprendere come l’utilizzo del pattern MVC sia importantissimo anche scrivendo
semplici applicazioni, partiamo da un esempio semplice di un’applicazione scritta con ZK,
ovvero una semplice finestra “Hello World”, dotata di un input box in cui, con un click sul
tasto OK, viene aggiornata una label con il messaggio in input:
Fig. 4.3 – Esempio web application in ZK: Hello World
Tralasciando varie configurazioni con web server o application server (molte guide e
tutorial possono sono disponibili nei wiki di ZK) il codice, abbastanza semplice e
intuitivo, per generare quest’applicazione di esempio senza utilizzare il pattern MVC è il
seguente:
68
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
<zk>
<window title="My window" border="normal" height="200px"
width="200px" closable="true"
sizable="true">
Hello World Message:
<label id="lMessage" />
<textbox id="txMessage" />
<button id="okButton" label="OK" onClick="ok_onclick()" />
<zscript type="java">
<![CDATA[
//@DECLARATION
public void ok_onclick() {
lMessage.setValue(txMessage.getValue());
}
]]>
</zscript>
</window>
</zk>
Questo codice (salvato in index.zul nel web server) presenta prevalentemente tag nel
linguaggio di markup ZUL che descrivono i componenti dell’interfaccia grafica (in questo
caso una window, una label, una textbox e un button), tutti dotati di un univoco id,
fondamentale per accedere al componente grafico tramite script o controller. Tramite tag è
stato associato al button con id “okButton” l’evento onClick, gestito direttamente dal
codice Java introdotto nel file di esempio con il tag <![CDATA[ ]]>: è da notare che il
codice Java non fa parte di una classe, e che al linguaggio Java possono sostituirsi altri
linguaggi a seconda dell’interesse dello sviluppatore.
Lo stesso esempio riscritto utilizzando il pattern MVC è costituito da due file: il file
index.zul riscritto in questo modo:
<zk>
<window title="My window" border="normal" height="200px"
apply="esempio.HelloController"
width="200px" closable="true"
sizable="true">
Hello World Message:
<label id="lMessage" />
<textbox id="txMessage" />
<button id="okButton" label="OK" />
</window>
</zk>
e il file HelloController.java, del package esempio, che rappresenta la classe controller
69
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
associata al file index.zul:
package esempio;
import
import
import
import
org.zkoss.zk.ui.event.Event;
org.zkoss.zk.ui.util.GenericForwardComposer;
org.zkoss.zul.Label;
org.zkoss.zul.Textbox;
public class HelloController extends GenericForwardComposer {
protected Label
lMessage;
protected Textbox txMessage;
public void onClick$okButton(Event event) {
String message = txMessage.getValue();
lMessage.setValue(message);
}
}
Si intuisce facilmente che per ottenere il pattern MVC bisogna seguire le seguenti regole:
1. Nel file ZUL il componente da controllare deve avere nel tag l’attributo apply uguale
al nome della classe Java responsabile del controllo.
2. La classe Java controller deve estendere la classe GenericForwardComposer ed avere
come campi almeno i componenti descritti nel file ZUL con lo stesso nome id.
3. Ogni evento che si vuole controllare deve essere intercettato da un metodo dichiarato
nella forma: nomeEvento$nomeComponente (Event event)
In questo modo si applica il pattern MVC specificando che:
1) Con "Model" intendiamo sia le funzionalità di business che gli oggetti business, in
pratica logica applicativa e relativi oggetti.
2) La parte "View" è un insieme di componenti grafici che compongono la pagina web
(ZUL file) senza la logica di elaborazione degli eventi.
3) La parte "Controller" è una classe Java registrata su un EventListener di uno o più
componenti che ha il compito di elaborare gli eventi lanciati dalla View.
Seguendo questo approccio i vantaggi che ne derivano sono considerevoli: i file che si
ottengono sono più “puliti”, e sono sviluppabili separatamente; ovvero i progettisti di
70
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
interfacce grafiche possono lavorare ai vari file ZUL che compongono l’interfaccia
grafica, e parallelamente gli sviluppatori implementano la logica applicativa collegandosi
all’interfaccia grafica con il solo attributo apply=package.classeController.
4.4.2 Spring con ZK
Nell’esempio precedente abbiamo descritto come la parte Model quella contenente oggetti
business e di logica applicativa: possiamo quindi far gestire gli oggetti business ad un
framework come Spring. Spring è un framework open source per lo sviluppo di
applicazioni su piattaforma Java: Esso è stato largamente riconosciuto all'interno della
comunità Java quale valida alternativa al modello basato su Enterprise JavaBeans (EJB).
Rispetto a quest'ultimo, il framework Spring lascia una maggiore libertà al programmatore
fornendo allo stesso tempo un'ampia e ben documentata gamma di soluzioni semplici
adatte alle problematiche più comuni. Sebbene le peculiarità basilari di Spring possano
essere adottate in qualsiasi applicazione Java, esistono numerose estensioni per la
costruzione di applicazioni web-based costruite sul modello della piattaforma Java EE.
Questo ha permesso a Spring di raccogliere numerosi consensi e di essere riconosciuto
anche da importanti vendor commerciali quale framework di importanza strategica.
La scalabilità di cui è dotato ZK Framework ci permette di accedere al contesto di Spring
allo stesso modo come si accede a un qualsiasi altro componente grafico.
Come esempio, iniziamo ad aggiungere all’applicazione Hello World del paragrafo
precedente il listener di Spring (nel file web.xml del web container, es. Tomcat):
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/classes/applicationContext.xml
</param-value>
</context-param>
<listener> <listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class> </listener>
A questo punto definiamo un semplice servizio Spring che effettua una elaborazione sul
71
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
messaggio di saluto immesso dall’utente:
<beans>
<bean id="helloService" class="esempio.HelloService">
</bean>
</beans>
package esempio;
public class HelloService implements IHelloService{
public String processMessage(String message) {
return "Ecco il messaggio: " + message; }
}
In questo semplice esempio il servizio HelloService non fa nulla di complicato: aggiunge
solamente un messaggio di saluto; ma in una applicazione reale possiamo legare il servizio
a un catalogo che accede via JPA (Java Persistence API) a un database e questo
meccanismo è completamente trasparente all’intero modulo che implementa le pagine
web. Per legare il bean "helloService" al Controller HelloController, basterà dichiarare un
elemento della classe HelloController che si chiami esattamente "helloService", ovvero
introdurre nel file HelloController.java il campo “protected IHelloService helloService;”.
Infine per ultimare l’integrazione Spring-ZK bisognerà aggiungere al file index.zul
dell’esempio il tag:
<zk>
<?variable-resolver
class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
.....
</zk>
che permette di installare il DelegatingVariableResolver per Spring sulla componente
window di ZK dell'esempio.
Grazie all’integrazione tra ZK e Spring (ma lo stesso discorso si fa con gli EJB) riusciamo
72
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
non solo a disaccoppiare elegantemente la parte modulare che implementa le interfacce
grafiche (Web 2.0) e la parte modulare che implementa la business logic, ma possiamo
sfruttare la features messe a disposizione da Spring (un esempio su tutte: Spring Security).
4.4.3 Hibernate con ZK
Quando la web application è scritta in Java e utilizza una base di dati nel model, è utile
utilizzare la piattaforma Hibernate, una soluzione opensource che fornisce un servizio di
Object-relational mapping (ORM), ovvero che gestisce la rappresentazione e il
mantenimento su database relazionale di un sistema di oggetti Java.
L’integrazione tra Hibernate e ZK, come Spring, è semplice ed efficiente in quanto ci
permette di accedere agli oggetti persistenti messi a disposizione da Hibernate allo stesso
modo come si accede a un qualsiasi altro componente grafico.
Tralasciando le configurazioni su web container, le tabelle del database e le annotazioni,
possiamo dire sommariamente che se abbiamo una classe Evento:
package eventi;
import java.util.Date;
public class Evento {
//come esempio, I metodi get e set sono omessi
public Long id;
public String titolo;
public Date date;
public Evento() {}
}
Dopo aver reso persistente la classe con Hibernate, associando ad esso il file di
configurazione “OR-mapping” Evento.hmb.xml:
73
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping3.0.dtd">
<hibernate-mapping>
<class name="eventi.Evento" table="EVENTS">
<id name="id" column="EVENT_ID">
<generator class="native"/>
</id>
<property name="date" type="timestamp" column="EVENT_DATE"/>
<property name="title"/>
</class>
</hibernate-mapping>
E dopo aver specificato una classe responsabile dell’accesso ai dati (EventDAO):
package eventi;
import org.zkoss.zkplus.hibernate.*;
import java.util.Date;
import java.util.List;
public class EventDAO {
org.hibernate.Session _session;
public EventDAO() {
_session=HibernateUtil.getSessionFactory().getCurrentSession();
}
public void saveOrUpdate(Evento anEvent, String title, Date
date) {
anEvent.setTitle(title);
anEvent.setDate(date);
_session.saveOrUpdate(anEvent); }
public void delete(Event anEvent) {
_session.delete(anEvent); }
public Event findById(Long id) {
return (Event) _session.load(Evento.class, id); }
public List findAll() {
return _session.createQuery("from Event").list(); }
}
74
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
il collegamento tra i componenti ZK e gli oggetti persistenti viene implementato nel file
.zul dell’interfaccia grafica in questo modo:
<zk>
<zscript><![CDATA[
import java.util.Date;
import java.text.SimpleDateFormat;
import events.Evento;
import events.EventDAO;
//ricava tutti gli elementi dal database
List allEvents = new EventDAO().findAll();
]]></zscript>
<listbox id="lbxEvents">
<listhead>
<listheader label="Title" width="200px"/>
<listheader label="Date" width="100px"/>
</listhead>
<listitem forEach="${allEvents}" value="${each}">
<listcell label="${each.title}"/>
<zscript>
String datestr = new
SimpleDateFormat("dd/MM/yy").format(each.date);
</zscript>
<listcell label="${datestr}"/>
</listitem>
</listbox>
</zk>
Ovvero, tutto si riduce alla fine ad un attributo ${metodo} del componente (tabella, lista di
selezione, textbox, etc.) di cui si vuole che vengano catturati i dati.
4.4.4 Integrare linguaggi in ZK
Una RIA scritta utilizzando ZK Framework può essere successivamente ampliata
sfruttando altri linguaggi oltre a Java:
<button onClick="javascript:do_something_in_js()"/>
<zscript language="groovy">
def name = "Hello World!";
</zscript>
75
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
Attualmente ZK supporta oltre a Java I linguaggi JavaScript, Ruby, Groovy e Python. In
alternativa è possibile estendere il supporto ad altri linguaggi manualmente, con un
semplice procedimento:
1. Fornire una classe che implementa l'interfaccia org.zkoss.zk.scripting.Interpreter,
oppure che derivi dalla classe org.zkoss.zk.scripting.util.GenericInterpreter (se si
vuole gestire direttamente i namespaces). In alternativa, se l'interpreter supporta BSF
(Bean
Scripting
Framework),
si
può
derivare
la
classe
org.zkoss.scripting.bsh.BSFInterpreter.
2. Dichiarare il linguaggio di scripting sia nel file WEB-INF/zk.xml che in zk/config.xml:
<zscript-config>
<language-name>SuperJava</language-name>
<interpreter-class>
my.MySuperJavaInterpreter
</interpreter-class>
</zscript-config>
Da come si è potuto osservare, la scalabilità di una RIA creata con ZK Framework è
ottima: l’applicazione può crescere o decrescere incorporando altri linguaggi e utilizzando
pattern e tool di supporto mantenendo una buona leggibilità e manutenibilità del codice.
4.5 Qualità del supporto: ZK Forge e case studies
ZK è un framework ideato, progettato e manutenuto dalla società Potix di Taiwan. È una
giovane società che si occupa fin dagli anni ’90 di consulenza per aziende che necessitano
di sviluppare applicazioni per il web (tra gli investitori di Poitx vi sono iD Innovation, di
proprietà Acer, e Asus). Questo prodotto è largamente usato nel web: il sito di ZK conta
più di un milione di download in tre anni di vita (un milione e 300 nel 2010); tra i propri
clienti la Potix annovera una larga varietà di società private e istituzionali, dalle più
piccole alle più grandi. La piattaforma software ha più di 5 anni di vita, e soltanto dal 2007
al 2010 sono state rilasciate più di 30 versioni corrette ed aggiornate di ZK Framework.
76
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
Questo framework gode di una buona qualità del supporto, e lo testimonia anche il fatto
che aziende come: Barclays, Sun Microsystems, Swiss Re, Oracle, Societe’ Generale,
Alcatel-Lucent, State Grid, MMC, China Southern Power Grid (che sono degli esempi di
clienti che fanno parte di Fortune 500) lo hanno utilizzato per molti progetti interni, di
consulenza e di outsourcing. Nato prevalentemente come software opensource e standardbased, ha riscosso un notevole successo anche nelle free comunity: sulla rete si trovano
molti forum, tutorial, guide e corsi di formazione a riguardo. In aggiunta, in collaborazione
con sourceforge, la socità Potix ha implementato ZK Forge[s15], un container di
applicazioni open source create e supportate da free community. Per adesso sono presenti
progetti software quali:
ZeroKode, un ambiente Web-based per lo sviluppo visuale di pagine ZUML con dragn-drop.
Zk-Dojo, un insieme di componenti per DOJO Toolkit.
Zk-FCKEditor, un porting del noto rich text editor FCK come componente ZK.
Zk-Gmaps, un porting di Google Maps API come componenti ZK.
Zk Jet, un plug-in per i browser Firefox e Chrome che fornisce allo sviluppatore un
ambiente “sandbox” per testare applicazioni scritte in ZK.
La scelta di questo framework per implementare il tool web-based, con le prospettive
appena elencate, è sembrata una scelta affidabile per il futuro della web application.
4.6 Curva di apprendimento: programming skills e linguaggio ZUML
Allo sviluppatore che utilizza ZK Framework per implementare la propria RIA sono
richieste le sole conoscenze basi di:
Java o linguaggi java scripting engine, quali Groovy, Rhino, JRuby (Java Ruby),
Jython (Java Python)
HTML e XUL
In aggiunta, per sfruttare la scalabilità e tutte le features messe a disposizione da ZK, lo
sviluppatore (opzionalmente) deve avere una conoscenza di Javascript e Ajax (per la
programmazione lato client), Databinding dichiarativi (per avere controllo su POJO Java
77
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
Beans) e JSTL (JavaServer Pages Standard Tag Library). Si può notare che per progetti
web semplici non sono richieste conoscenze approfondite: in realtà si potrebbero sfruttare
sono linguaggi di scripting senza usare la programmazione ad oggetti (con tutti gli
svantaggi che ovviamente ne derivano). Per progetti più avanzati la curva di
apprendimento resta comunque bassa, considerando che oltre ad una buona conoscenza di
Java e della OOP lo sviluppatore deve imparare il linguaggio ZUML (ZK User Interface
Markup Language).
ZUML è un linguaggio di markup basato su XML usato esclusivamente per la definizione
di interfacce grafiche: il suo funzionamento può essere paragonato ai linguaggi XUL e
XHTML, ma chi ha dimestichezza con pagine web e HTML (requisito ovvio per lo
sviluppatore web) si trova subito a suo agio per leggerlo e comprenderlo; in aggiunta, il
tool di sviluppo visuale, ZK Studio, messo a disposizione dal framework, aiuta di molto
la comprensione nella definizione di componenti della RIA da implementare.
4.7 Strumenti di supporto: i tool di ZK
A corredo del framework RIA ci sono ottimi strumenti di supporto, suddivisi in prodotti
software creati dalla stessa Potix autrice del framework, e “tool wrapper” di software di
terze parti integrabili facilmente nella piattaforma di sviluppo.
Il primo software sicuramente utile al supporto di ZK è ZK Studio, un ambiente visuale di
sviluppo opensource integrato come plug-in Eclipse, che fornisce allo sviluppatore
strumenti intuitivi per il design UI, prototyping, sviluppo e deployment delle applicazioni
web scritte con ZK. Questo software mette a disposizione dello sviluppatore una View in
Eclipse dotata di una web window, una palette di componenti ZK, una property window e
un editor di file .zul : i componenti ZK possono essere inclusi nel progetto con un
semplice drag and drop, che va automaticamente ad aggiornare il file .zul del progetto,
oppure è possibile programmare nell’editor direttamente con i tag ZUML (compresa la
funzione di autocompletamento del codice) e il risultato viene aggiornato in tempo reale
nella web window. Per testare il funzionamento dell’interfaccia che si sta sviluppando con
ZK studio con il web container, il software si occupa automaticamente dei file manifest
78
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
XML necessari alla configurazione del server, e alla fine crea con poche configurazioni il
file .WAR della web application. In questo modo lo sviluppatore di RIA che utilizza
Eclipse come piattaforma di sviluppo non ha bisogno di tool esterni per programmare la
logica applicativa e l’interfaccia utente.
Fig. 4.3 – ZK Studio in esecuzione con Web Failure Model WSN Generator
Oltre a ZK Spring e ZK JSP Tags, librerie per l’integrazione di Spring e JSP analizzate nel
paragrafo precedente, il framework ZK è dotato di due software Ajax implementabili
liberamente nelle proprie web application: ZK Spreadsheet[s16] e ZK Calendar.
ZK Spreadsheet è un foglio di calcolo web-based con funzionalità ed interfaccia simili a
Microsoft Excel, con supporto a funzioni, grafici, import ed export di file .xls, e
diagrammi collaborativi. E’ un software molto utile per visualizzare, modificare ed
esportare dati in applicazioni web rimanendo nel web browser, e verrà sicuramente
utilizzato in Web Failure Model WSN Generator per visualizzare i risultati ottenuti dalle
simulazioni.
ZK Calendar è un invece un applicazione Ajax simile a Google Calendar che permette di
integrare un sistema di schedulino nelle proprie applicazioni web. Dal lato client offre
un’interfaccia intuitiva, con task e appuntamenti modificabili con drag and drop, mentre
lato server offre una efficiente integrazione con Java, database e Web services. Non è
certo un’applicazione utile per aumentare in futuro le funzionalità del tool web-based
79
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
implementato come lavoro di tesi, a meno che non si pensi di presentare all’utente uno
scheduling professionale sulle simulazioni e il tempo di simulazione effettuato, ma ZK
Calendar rimane comunque un’applicazione che dimostra il buon supporto del framework
ZK.
Fig. 4.4 – ZK SpreadSheet ZK Calendar
Per quanto riguarda i tool di terze parti, il framework ZK offre la possibilità di integrare e
gestire diversi tool sia come componenti grafici nei file .zul sia come metodi a
disposizione nelle classi Java. Tra i più importanti citiamo Jasper Report per la
reportistica, FCK Editor per l’editing di testi, JfreeChart per i grafici, SIMILE Timeline
per la visualizzazione di eventi time-based, Google Maps per le mappe interattive, etc.
L’integrazione e la gestione di questi tool viene implementata in realtà attraverso un
meccanismo di “wrapping” che può essere esteso[s17] teoricamente a qualsiasi software di
terze parti.
80
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 4: ZK framework
4.8 Costi di sviluppo: le versioni disponibili
Il Framework ZK e il software a corredo sono opensource e rilasciati con licenza GPL
nella versione 3 e LGPL nella versione 5. Inoltre la compatibilità con l’ambiente Eclipse e
l’utilizzo di Java fanno sì che lo sviluppo di applicazioni web con questa tecnologia sia
indipendente dal sistema operativo: ciò si riflette sui costi di sviluppo, che in termini
economici sono molto bassi rispetto ad altre piattaforme software presenti sul mercato.
Oltre a ciò esistono versioni due versioni commerciali del framework: Professional
Edition ed Enterprise Edition. Esse differiscono dalla versione free nell’aggiunta di nuovi
componenti grafici, nell’aumento generale di performance e nel supporto tecnico e
consulting; il fulcro principale però resta la community opensource del progetto, in quanto
ogni release viene prima rilasciata con licenza LGPL e poi perfezionata in ambienti
commerciali, e non viceversa.
Per quanto riguarda i costi in termini di tempo, si è discusso precedentemente
dell’innovazione di cui ZK è basato, ovvero quella di adottare una metodologia di
sviluppo di Rich Internet Applications simile allo sviluppo di Java Desktop Applications,
utilizzando programmazione orientata agli oggetti e guidata dagli eventi: analizzando vari
case studies di aziende che hanno sfruttato questo framework per i propri progetti si può
notare un netto miglioramento in termini di tempi di sviluppo. Un piccolo esempio lo è il
seguente lavoro di tesi, la cui implementazione pratica avrebbe richiesto con un approccio
tradizionale tempi di sviluppo più lunghi.
81
Capitolo 5
Implementazione del tool
Il presente capitolo descrive le fasi salienti per l’implementazione del tool web-based,
Web Failure Model WSN Generator. Nella tesi si è dato ampio spazio più alla
progettazione che all’implementazione, e per non dilungare troppo sulla programmazione
in sé, verranno descritte esclusivamente le classi create e il loro ruolo nel progetto.
Il capitolo termina sull’esposizione della funzionalità disegno topologia della WSN e su
come si è utilizzato il framework per realizzarla.
5.1 Pattern MVC e struttura della RIA
Per rendere il tool il più scalabile e modificabile possibile, si è adottato come prima scelta
implementativa la suddivisione dei componenti software utilizzando il pattern MVC, nelle
modalità elencate nel paragrafo 4.4.1. Si è scelto in particolare di racchiudere le classi del
progetto desktop-based Failure Model WSN Generator e il simulatore Mobius nel model,
compresa la nuova classe AmbientVar e il log. L’interfaccia grafica desktop scritta in
Swing, anche se esclusa dal funzionamento del tool web-based, resta comunque inclusa
nel progetto e nel model, in quanto si è prefissato nella progettazione che in futuro
entrambi i tool potranno essere sviluppati parallelamente. Nell’ambiente di sviluppo
eclipse, in particolare, non si sono inglobate le classi del progetto desktop nel progetto
web, ma si è creato un nuovo progetto (ZK Project) che fa riferimento al progetto esistente
del tool desktop-based: in questo modo il tempo che viene speso in configurazione (il
82
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
progetto desktop-based deve sempre rimanere aperto, e tutte le sue classi devono far parte
del classpath sia dell’ambiente eclipse che del web container tomcat scelto) ha reso più
efficiente e comodo lo sviluppo e il debugging di entrambi i tool.
Fig. 5.1 – struttura del tool web-based: MVC con ZK Framework
Alle componenti model è stata lasciata la possibilità di implementare un database
PostgreSQL, compatibile con Mobius, in quanto nelle future implementazioni è possibile
dotare questo simulatore di un archivio in cui memorizzare i risultati delle simulazioni.
Non essendoci vincoli stretti di compatibilità tra il web framework ed i vari software di
database, sarà possibile sfruttare l’archivio in PostgreSQL del server per memorizzare
anche le credenziali degli utenti, o per associare agli utenti le metriche di valutazione
83
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
scelte per la simulazione: per questo si è lasciato un collegamento progettuale, opzionale,
tra le classi controller che sfruttano quasi tutte il ZK Framework, e l’archivio dati.
In particolare il componente software controller racchiude le classi che dialogano sia con i
componenti ZK dell’interfaccia web, sia con i software Failure Model WSN Generator e
Mobius. Oltre a tutte le classi java realizzate per il controllo, questo componente include
anche il file .jar del progetto zkDiagram, un porting opensource della libreria JavaScript
draw2d necessaria per implementare la funzionalità disegno topologia WSN. La view
infine è composta di soli file .zul dell’interfaccia grafica dell’applicazione web, scritti
utilizzando sia il linguaggio ZUML sia HTML.
5.2 Le classi controller
Fanno parte del package webfamogen.controller tutte le classi che, richiamate dai file .zul
attraverso l’attributo “apply”, controllano il funzionamento della GUI web e dialogano con
i software desktop installati nel server. In particolare di questo package fanno parte le
classi:
LoginBoxController: responsabile della sessione e dell’autenticazione dell’utente
attraverso l’interfaccia del file login.zul. Non avendo ancora implementato un
database e una tabella utenti, l’autenticazione viene eseguita con un semplice
controllo tra i campi user e password: se i campi sono corretti e non vuoti, vengono
sfruttati i metodi delle classi di utilità per creare i file e le cartelle necessarie al
funzionamento della simulazione remota, e se già esistono viene collega la sessione
corrente con le cartelle specifiche dell’utente che ha eseguito l’accesso.
WebTopologyController: è la classe che controlla l’interfaccia principale del tool
web-based, responsabile di due compiti: emulare il comportamento del tool desktopbased (sia nell’interfaccia che nelle funzionalità) e gestire le scelte utente nella
modellazione e simulazione delle WSN.
ModelGeneratedUtil: è la classe che gestisce il modello generato o compilato sia dal
tool desktop-based che da Mobius. Essa fornisce all’utente la possibilità di salvare i
modelli generati nel proprio sistema piuttosto che conservarli sul server, sfruttando sia
84
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
le classi di utilità dell’applicazione web sia il metodo org.zkoss.zul.Filedownload.save
messo a disposizione dallo ZK Framework.
DesignerController: fa parte del package topology.designer ed è la classe controller
responsabile del disegno della topologia WSN ed in particolare della disposizione
corretta dei nodi, del corretto disegno dei link a seconda del metodo di propagazione
selezionato, e del controllo degli input dell’utente. Essa dialoga sia con l’interfaccia
grafica implementata in TopologyDesigner.zul, sia con la libreria ZKDiagram.jar, sia
con le classi di utilità.
BorderLayoutComposer: è classe che ha l’unico compito di gestire e mostrare tutti i
file ZUL che compongono l’interfaccia grafica all’utente, a seconda delle sue scelte.
E’ la classe con meno logica applicativa delle altre, ma è fondamentale sia per gestire
il layout (di tipo border) delle pagine web sia per consentire lo sviluppo della GUI
suddividendolo in più file, in modo da lavorare in maniera più organizzata.
5.3 Classi di utilità del tool web-based
Così come si è proseguito per il tool desktop-based, anche per il tool web-based si sono
create delle classi di utilità a supporto dell’applicazione, e in particolare a supporto delle
classi controller:
WebUtil: è la classe responsabile della creazione e controllo di directory e file
dell’utente correttamente autenticato al sistema. Essa fornisce metodi per la
decompressione del file .zip della topologia caricata dall’utente, per la compressione
del modello generato e compilato, e per la restituzione del path delle user directories.
In particolare WebUtil sfrutta i seguenti packages: java.io.File per la manipolazione
dei file e directory, java.util.zip per la compressione/decompressione,
org.zkoss.util.media e org.zkoss.zul.Fileupload per l’upload della topologia. I campi e
i metodi di questa classe sono stati implementati in modo da essere indipendenti dal
sistema operativo utilizzato per contenere il web server, in modo tale da far
distinzione tra i diversi filepath creati: si è notato infatti che i filepath creati nel
sistema Windows (con carattere separatore “\”), diversi dai percorsi creati nei sistemi
85
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
Unix/Linux (con carattere separatore “/”), impedivano il corretto funzionamento del
simulatore Mobius.
ZKTextBoxHandler: si occupa di gestire i log creati dall’applicazione Failure Model
WSN Generator. Come descritto nel paragrafo 2.2, diminuendo l’accoppiamento tra
l’interfaccia grafica e la logica applicativa del software desktop-based è stato
possibile, attraverso l’utilizzo dei log Java, catturare i messaggi dell’applicazione e
mostrarli all’utente o all’amministratore in qualsiasi modo si voglia, creando soltanto
un nuovo handler. In questo caso, questa classe fornisce un Handler che cattura i log
dell’applicazione desktop e li invia al browser dell’utente in una ZK Text Box
dell’interfaccia grafica. L’implementazione di questa classe, che eredita dalla classe
Handler, ha dato inizialmente risultati imprevisti: infatti è stato difficile gestire thread
generati dai log lato server (cioè in un ambiente Java ben disposto al multi-threading)
che direttamente si collegano al componente grafico ZKTextBox, che viene generato
in run-time sfruttando il linguaggio JavaScript, il quale non supporta nativamente il
multi-threading. Si è aggirato questo vincolo sfruttando lato server un oggetto
StringBuilder e lato client un timer in ZK che aggiorna periodicamente la Text Box
con il suo contenuto.
ExportUtil: insieme alle classi WSLink e WSNode, è responsabile della corretta
generazione dei file della topologia WSN disegnata dall’utente nel browser. Essa
viene richiamata dal controller DesignerController e sfrutta i package java.io.File e
java.util.zip per creare i file coordinate.txt, distances.txt, energy.txt, losses.txt,
neighbor.txt, radio.txt, TinySan.txt e topology.txt descritti nel paragrafo 1.5. Alla fine
della creazione questi file vengono compressi in un unico archivio zip e messi in
download all’utente.
5.4 La view ed i file ZUL
Lavorando con ZK Framework si è utilizzato un metodo molto comodo per separare e
sviluppare individualmente i componenti grafici visualizzabili dall’utente. Si possono
infatti creare diversi file .zul che compongono la grafica di un progetto, ognuno con un
86
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
diverso layout grafico, diversi componenti e comportamenti, e collegarli tra di loro sia
sfruttando il tag <include> del linguaggio ZUML sia chiamando i metodi Java
Executions.getCurrent().sendRedirect e Executions.createComponents messi
disposizione dal framework.
Ad esempio, per lanciare il tool web-based implementato bisogna digitare l’URL corretto
contenente il file index.zul: all’interno di questo file, escludendo i tag che compongono la
grafica della pagina web, è presente l’istruzione:
<include src="/view/Login.zul"></include>
la quale non solo richiama automaticamente il file Login.zul incluso nella directory view
del progetto includendolo interamente nella finestra corrente del browser, ma è
indipendente dal percorso generato nel web server dopo il deployment dell’applicazione:
in qualunque percorso o sistema è installato il web container tomcat, il file viene sempre
richiamato in maniera corretta.
Dall’altro lato, il file Login.zul è controllato dalla classe Java LoginBoxController, in cui il
frammento di codice che gestisce la corretta autenticazione dell’utente è:
if (isLogged) {
WebUtil.preparadirectory(user);
Executions.getCurrent().sendRedirect("/view/View.zul");
}
Il quale prepara file e directory personalizzate per l’utente e carica la pagina View.zul con
un redirect del browser. Infine la pagina View richiamata dal corretto login è controllata a
sua volta dalla classe controller BorderLayoutComposer la quale, a seconda della
funzionalità scelta dall’utente, con questo frammento di codice:
87
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
if (item!=null) {
MenuNode node = (MenuNode)item.getValue();
Executions.createComponents(node.getLink(),contentDiv,null);
}
ricava l’URL relativo della pagina .zul scelta dall’utente attraverso node.getLink(), elimina
i componenti presenti e li ricrea sfruttando la nuova pagina web e la funzione
Executions.createComponents(String, Component, Map). Il meccanismo appena descritto
di caricare dinamicamente le pagine web in formato .zul permette una buona scalabilità del
software creato attraverso la modularità con cui si aggiungono o si eliminano pagine web
necessarie al funzionamento dell’applicazione web.
Nel progetto Web Failure Model WSN Generator in particolare le pagine .zul
implementate sono:
Login.zul: Window del login utente;
View.zul: Layout Container di tipo Border dell’applicazione;
Generator.zul: Window che emula graficamente il tool desktop-based;
Model_generated.zul: Floating window del risultato della generazione e compilazione
del modello;
Metrics.zul: Window per la scelta delle metriche da utilizzare nella simulazione;
TopologyDesigner.zul: Window per il disegno della topologia WSN.
Per aumentare la sicurezza del tool web-based, si può impedire l’accesso diretto a queste
pagine da parte dell’utente principalmente in due modi: utilizzando i metodi a disposizione
della classe org.zkoss.zk.ui.Executions oppure sfruttare il più affidabile meccanismo
Spring Security messo a disposizione dal web frame work Spring.
5.5 Il Disegno della Topologia: draw2d
La funzionalità del disegno della topologia da parte dell’utente è stata implementata non
88
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
sfruttando direttamente ZK Framework, ma la libreria zkDiagram della Integrated
Modelling. Il disegno grafico su browser web e soprattutto l’oggetto Canvas di HTML5
non è ancora supportato da ZK, e per questo motivo molti sviluppatori hanno adottato
soluzioni alternative sia per implementare in tempi rapidi queste funzionalità, sia per
sfruttarle nello ZK Framework: ne è un esempio zkDiagram, la quale non è altro che un
porting per ZK della libreria Open-jACOB draw2d di Andreas Herz che, scritta
interamente in JavaScript, permette di disegnare e modificare diagrammi di vari tipi.
Rispetto a draw2d che attualmente è diventata una libreria matura e stabile per disegnare
diagrammi su browser web, zkDiagram è un porting incompleto e per certe funzionalità
instabile della suddetta libreria, in quanto non fornisce al framework ZK tutte le
funzionalità che draw2d possiede in Javascript: non è stato possibile utilizzare
direttamente la libreria JavaScript, poiché tutto ciò che l’utente svolge nel canvas di
draw2d deve essere intercettato da ZK, e il modo più semplice e rapido è utilizzare il
porting. ZK Framework mette comunque a disposizione una metodologia per importare
qualunque libreria scritta in Javascript nei suoi componenti grafici, ma il procedimento è
lungo e tedioso per librerie con molte righe di codice, come draw2d: questo perché
importare una libreria in ZK significa “sdoppiare” lo sviluppo in due parti e in due
linguaggi diversi; da un lato bisogna intercettare i cambiamenti provocati dal client
(libreria Javascript) e notificare al server lo stato attuale dell’applicazione, e dall’altro lato
bisogna modificare la parte della sessione utente che riguarda l’uso della libreria con i
cambiamenti voluti dal framework ZK lato server. Bisogna poi implementare tutte le
funzioni Java che riguardano i get ed i set dei campi della libreria Javascript e sviluppare
dei metodi Java che richiamano metodi JavaScript della libreria su cui fare il porting.
Fortunatamente le funzionalità del porting di draw2d per ZK sono state sufficienti per
realizzare la funzionalità del disegno della topologia, in quanto tutto ciò che lo
sviluppatore WSN ha bisogno come oggetti di disegno sono soltanto nodi e link: in
aggiunta, zkDiagram, anche se mal documentato, è un progetto opensource, ed è quindi
possibile modificare ed arricchire il codice sorgente a seconda di ulteriori funzionalità
richieste dal tool web-based per la simulazione remota di WSN. Allo stato attuale
89
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
quest’applicazione permette di disporre su un workspace di dimensioni personalizzabili
dall’utente dei nodi wireless con proprietà modificabili di coordinate, tecnologie radio e
batteria, routing, sensor board e application. Dopo la disposizione di nodi l’utente può
collegare i link manualmente oppure scegliere un modello di propagazione da una lista (ad
esempio, fixed Radius). Nella creazione dei link, automatica o manuale, viene creato
visualmente una curva che collega i nodi in esame, con una piccola label che indica la
probabilità di perdita di pacchetto.
Nell’utilizzo di ZK Framework si è notato infine come sia efficace l’utilizzo di codice
HTML iniettato nel linguaggio ZUML: nei tag infatti possiamo inserire l’attributo style, il
quale applica uno stile HTML al componente desiderato:
<workspace router="bezier" id="wrsTopology"
style="background:#FFFFFF
url(${c:encodeURL('/images/square_tiled.gif')}) repeat;">
</workspace>
Ad esempio nel codice precedente nella GUI web è stato disposto un componente
workspace di nome wrsTopology, con connessioni di tipo bezier e con stile HTML dotato
di un’immagine (la cui path è ricavata con codice JavaScript) di sfondo con un motivo di
riempimento: questo stile può essere modificato a tempo di esecuzione con codice Java:
if (whatBackground.equals("map_alvin")) {
this.wrsTopology.setStyle("overflow:auto;
background:#FFFFFF url(/WebFAMOGEN/images/alvin-map.jpg)
no-repeat; background-attachment: scroll;");
this.wrsTopology.invalidate();
}
attraverso il metodo set Style si è modificato totalmente lo stile del componente workspace
90
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
e tramite il metodo invalidate() si è forzato un refresh di tutti i componenti grafici della
sessione attuale: con questo piccolo “hack” l’utente può modificare lo sfondo del
workspace su cui disporre i nodi ed i link, scegliendo o caricando sul proprio spazio server
un immagine di una zona reale dove disporre la WSN.
5.6 Esempi di funzionamento
Il capitolo si conclude con i seguenti screenshot del tool implementato, i quali riflettono il
funzionamento descritto nel paragrafo 2.2 dedicato ai casi d’uso:
Fig. 5.2 – Login Page del tool
91
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
Fig. 5.3 – Pagina del Failure Model WSN Generator per la generazione del modello: upload della topologia
Fig. 5.4 – Generazione del modello e download del modello generato
92
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
Fig. 5.5 – Disegno della topologia WSN – Disposizione dei nodi
Fig. 5.6 – Disegno della topologia WSN – Creazione link con modello di propagazione Fixed Radius
93
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
Fig. 5.7 – Wizard per automatizzare il processo di disegno, modellazione e simulazione di una WSN
Fig. 5.8 – Wizard – scelta delle metriche di valutazione per la simulazione di WSN
94
Conclusioni
Il presente lavoro è stato diretto ad approfondire le fasi di generazione automatica di
modelli analitici e a porre le basi per estendere la fase della simulazione del modello
analitico generato. Partendo dal tool di generazione automatica di modelli di fallimento e
dal simulatore mobius, si è implementato un tool di remoting che mette a disposizione
questi strumenti in maniera semplice, rapida e con un carico computazionale esiguo da
parte dell'utente. Ciò nel più ampio disegno diretto a meglio inquadrare la progettazione e
la modellazione delle reti di sensori senza filo nelle varie applicazioni ipotizzabili.
Attraverso questo tool l’utente è in grado con un thin client di inserire o disegnare lo
scenario topologico da modellare, ottenere automaticamente un modello analitico atto ad
incentrarsi sulla dependability del sistema, scegliere le metriche da valutare e scaricare il
risultato ottenuto. Inoltre è in grado di ricavare dalla topologia come viene propagata la
comunicazione tra i vari nodi sensore attraverso un modello manuale, un modello di tipo
fixed radius e di altri modelli implementabili successivamente. Tutto questo via web,
senza installare o configurare nulla e senza avere un calcolatore particolarmente
performante.
Le scelte di progetto nella realizzazione dell'applicazione web sono mirate a rendere il
risultato ottenuto quanto più estensibile possibile. Successivamente, infatti, è possibile
l’aggiunta di altri modelli di propagazione, di altri modelli analitici e di ulteriori metriche
di valutazione che possono essere aggiunti in maniera semplice anche se si tratta di
sfruttare librerie esterne o software di terze parti.
95
Realizzazione di uno strumento web-based per la simulazione remota di WSN
Cap. 5: Implementazione del tool
Al fine di dimostrare quanto affermato è stato aggiunta la funzionalità del disegno della
topologia della rete di sensori, la quale è una funzionalità comoda per il progettista di
WSN e che è stata implementata integrando e adattando una libreria web nel progetto.
La scelta del framework per l'implementazione ha da un lato avvicinato le applicazioni
desktop alle applicazioni web e dall'altro ha offerto una programmazione event-driven e
un linguaggio di markup tali da rendere una bassa curva di apprendimento e tempi di
sviluppo relativamente brevi ed il risultato pratico ottenuto presenta caratteristiche che
giustificano il trend attuale dello sviluppo delle Rich Internet Applications e del
miglioramento che esse apportano al web 2.0.
Le metriche adottate nella scelta delle tecnologie RIA hanno reso il prodotto software
implementato adattabile al fine di ottenerne nuove funzionalità e futuri sviluppi. In
particolare lo sviluppo del tool desktop-based, che può essere arricchito di altri modelli
analitici, può proseguire parallelamente allo sviluppo dell’applicazione web based che
funge da container per nuovi modelli di propagazione, nuove metriche di valutazione,
nuovi software di simulazione e nuovi aggiornamenti dei framework di modellazione e di
simulazione. L’inclusione di una piattaforma software come Spring e di un database come
PostgreSQL, magari gestito da strumenti ORM (Object-relational mapping) come
Hibernate, sarà sicuramente necessaria per l’user managment e per memorizzare i risultati
delle simulazioni.
96
Bibliografia
[1]
Marcello Cinque, Domenico Cotroneo, Catello Di Martino, Stefano Russo.
“Modeling and assessing the Dependability of Wireless Sensor Networks”, 2007.
[2]
Catello di Martino "Resiliency assessment of wireless sensor networks: a holistic
approach", 2009.
[3]
W.H. Sanders, J.F. Meyer. “A unified approach for specifying measures of
performance, dependability, and performability”. In A. Avizienis, J. Kopetz, and
J.Laprie, editors, Dependable Computing for Critical Applications, volume 4 of
Dependable Computing and Fault-Tolerant Systems, 1991.
[4]
Umberto Sannolo, “Generazione automatica di modelli di fallimento per la
simulazione di reti WSN”, 2009.
[5]
D.D. Deavours, G. Clark, T. Courtney, D. Daly, S. Derisavi, J.M. Doyle, W.H.
Sanders, and P.G. Webster. “The Moobius framework and its implementation”
IEEE Transactions on Software Engineering, 28(10):956–969, 2002.
[6]
William H. Sanders and The Board of Trustees of the University of Illinois.
“Mobius, User manual”, 2006.
[7]
Roger S. Pressman. "Principi di Ingegneria del Software", 2007.
[8]
Bruce Eckel, “Thinking in Java”, 2007.
[9]
R. Asleson, N.T. Schutta, “Foundations of Ajax”, 2006
[10]
Potix Corp. “ZK: the developer’s guide”, 2009.
[11]
H. Chen, R. Cheng, "ZK: Ajax Without JavaScript Framework", 2007
97
Sitografia
[s1]
www.mobius.illinois.edu
(Mobius tool homepage)
[s2]
www.adaptivepath.com/ideas/essays/archives/000385.php (Ajax Manifest)
[s3]
www.icefaces.org (IceFaces Homepage)
[s4]
www.openlaszlo.org (Openlaszlo Homepage)
[s5]
www.adobe.com/products/flex/ (Adobe Flex Homepage)
[s6]
download.macromedia.com/pub/flash/whitepapers/richclient.pdf (RIA Manifest)
[s7]
www.themidnightcoders.com/products/weborb-for-java (Web-Orb Homepage)
[s8]
opensource.adobe.com/wiki/display/blazeds/BlazeDS/ (BlazeDS Homepage)
[s9]
echo.nextapp.com/site/ (Echo Framework Homepage)
[s10] www.sencha.com/products/gwt/ (ExtGWT homepage)
[s11] code.google.com/p/smartgwt/ (SmartWGT homepage)
[s12] vaadin.com/home/ (Vaadin Homepage)
[s13] click.apache.org (Apache Click Homepage)
[s14] www.zkoss.org (ZK Framework Homepage)
[s15] www.zkoss.org/community/zkforge.dsp (ZK Forge)
[s16] www.zkoss.org/product/zkspreadsheet.dsp (ZK Spreadsheet)
[s17] docs.zkoss.org/wiki/Behind_The_Scene:_Integrating_Google_Maps
(ZK Small Talk: Integration)
[s18] docs.zkoss.org/wiki/Small_Talks (ZK: Small Talks)
[s19] www.integratedmodelling.org/software/zk/zkdiagram.html (zkDiagram Project)
[s20] www.draw2d.org/draw2d/ (draw2d Homepage)
98
