analisi e validazione di algoritmi distribuiti in sistemi...
TRANSCRIPT
Universita degli Studi di Firenze
Facolta di Scienze Matematiche Fisiche e Naturali
Corso di Laurea in Informatica
Analisi e Validazione di AlgoritmiDistribuiti in Sistemi con Palmari:
Specifica e Definizione di NekoPDA eAnalisi delle Problematiche del Porting
Anno Accademico 2005-2006
Relatore: Prof. A.Bondavalli Correlatore: Dott. L.Falai
Martina Albini
ii
Prefazione
Oggigiorno il business, l’economia domestica, i trasporti e la vita sociale sono
sempre piu legati all’utilizzo di apparecchiature elettroniche e computer, il cui
progresso e funzionamento dipendono dalle innovazioni nel campo dei sistemi
embedded e dal ”pervasive computing”. Gli oggetti d’uso quotidiano, co-
me telefonini, automobili, elettrodomestici, stanno diventando ”intelligenti”:
possono registrare, memorizzare dati e controllare l’ambiente in cui agiscono,
garantendo sicurezza e affidabilita del sistema stesso. La rapida diffusione
degli oggetti intelligenti nella nostra quotidianita apre nuove prospettive di
sviluppo per una migliore qualita di vita e una maggiore efficienza dei pro-
cessi produttivi. Come scrive Donald A.Norman, promotore del concetto di
informatica pervasiva, nel suo Invisible Computer, ”la tecnologia migliore e
quella che non si vede, perche e tanto semplice da usare da diventare traspa-
rente”. Con questa affermazione Norman sottolinea come la nuova tecnologia
sara legata al concetto di ”invisibile”, ovvero spiega che, con il passare degli
anni, i computer diventeranno sempre piu piccoli, efficienti e userfriendly.
Per questo motivo tutto cio che adesso e ingombrante, pesante e difficile da
usare verra abbandonato a favore delle nuove tecnologie sempre piu piccole
e pervasive.
L’ideologia che sta alla base di questa tesi e proprio quella appena descritta.
Cio che si tentera di fare, infatti, sara di dare vita ad una possibile pro-
iii
iv PREFAZIONE
gettazione di un’applicazione, che attualmente lavora su personal computer,
all’interno di un piccolo dispositivo, come un palmare.
Norman spiega , in un articolo sull’Espresso del 24-10-2003, che il personal
computer diventera uno strumento quotidiano nelle nostre vite, cosı come il
forno o il telefono e per questo motivo dovra essere molto leggero e semplice
da usare.
In seguito mostreremo in che modo, tutto cio che e stato fatto in questa tesi,
e un piccolo passo verso il futuro, in cui la tecnologia diventa sempre piu
efficente, usabile e, al tempo stesso, sempre al nostro servizio.
La tesi e costituita di sei capitoli. Il Cap.1 presenta cosa si intende per siste-
ma distribuito e spiega cos’e la dependability per dare una breve infarinatura
delle terminologie e dei concetti che stanno alla base dell’elaborato.
Nei Cap.2 e Cap.3 si illustrano gli obiettivi di questa tesi, cosa si intende per
framework Neko, la sua architettura e il suo funzionamento. Si descrive in
breve cosa sono i PDA e si chiarisce quali siano i legami che intercorrono tra il
framework e tali dispositivi, estapolando il vero senso di questa tesi. Il Cap.4
descrive la progettazione del package NekoPDA, i motivi e le descrizioni dei
legami che intercorrono tra le varie classi. Nel Cap.5 si mostra con maggior
dettaglio la storia e le caratteristiche fisiche dei palmari, mentre in seguito,
una parte e riservata ad alcune delucidazione sui sistemi operativi dedicati
ai palmari. Successivamente sempre all’interno dello stesso capitolo e stata
fatta un’attenta disamina sulle Java Virtual Machine per PDA presenti sul
mercato e una breve descrizione del DellAxim x51v e del suo SO, Windows
Mobile 5.0.
Il Cap.6 tira le somme di tutta la ricerca e spiega, in seguito alle analisi effet-
tuate, quali siano le Virtual Machine papabili, affinche un’applicazione Neko
possa essere eseguita correttamente su un qualsiasi palamare (in particolare
v
sul DellAxim x51v) e quali sono state le prove fisiche effettuate.
L’appendice infine illustra, in forma di elenco, l’architettura, gia illustrata
in forma grafica, del pacchetto NekoPDA, ovvero di quell’inseme di classi di
Neko che ipoteticamente sarebbero le uniche e indispensabili a risiedere sul
PDA.
vi PREFAZIONE
Indice
Prefazione iii
1 Introduzione 1
1.1 I sistemi distribuiti . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Sistemi sincroni e asincroni . . . . . . . . . . . . . . . . 4
1.2 Dependability . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 I vantaggi di possedere Neko 1.0 su un palmare 13
2.1 La diffusione dei palmari nella quotidianita . . . . . . . . . . . 14
2.2 Le relazioni tra Neko e i PDA . . . . . . . . . . . . . . . . . . 19
3 Che cos’e Neko 21
3.1 La piattaforma Neko . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 L’architettura di Neko . . . . . . . . . . . . . . . . . . 21
3.2 Il Tool NekoStat . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Architettura di NekoStat . . . . . . . . . . . . . . . . . 28
4 Progettazione di NekoPDA 31
4.1 Motivi che portano alla creazione di
NekoPDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Architettura del pacchetto NekoPDA . . . . . . . . . . . . . . 32
vii
viii INDICE
5 PDA, Sistemi Operativi e JVM dedicati 43
5.1 PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 I palmari nella storia . . . . . . . . . . . . . . . . . . . 43
5.1.2 Le caratteristiche fondamentali dei PDAs . . . . . . . . 46
5.2 I sistemi operativi dedicati ai palmari . . . . . . . . . . . . . . 48
5.2.1 Symbian Os . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.3 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.4 Windows Mobile 5.0 . . . . . . . . . . . . . . . . . . . 51
5.3 Alcune parole riguado DellAxim x51v . . . . . . . . . . . . . 54
5.4 La Java Virtual Machine . . . . . . . . . . . . . . . . . . . . . 56
5.4.1 Jeode . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.2 CrEme . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.3 SuperWaba . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4.4 Ewe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.5 Mysaifu . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.6 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . 80
6 Conclusioni 83
A Pacchetto NekoPDA 87
Elenco delle figure
1.1 Gli stati di un servizio . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Catena Guasti Errori e Fallimenti . . . . . . . . . . . . . . . . 8
2.1 Gestione degli appuntamenti per i medici . . . . . . . . . . . . 15
2.2 Gestione delle vendite . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Gestione del traffico . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Architettura Neko . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Layer passivi e layer attivi . . . . . . . . . . . . . . . . . . . . 23
3.3 Il NekoMessage . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Reti reali e simulate . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 L’invio dei messaggi tramite microprotocolli . . . . . . . . . . 27
4.1 I pacchetti di NekoPDA . . . . . . . . . . . . . . . . . . . . . 40
4.2 Le classi di Neko incluse nel package NekoPDA . . . . . . . . 41
5.1 Schermata Principale . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 Schermata durante l’esecuzione . . . . . . . . . . . . . . . . . 75
5.3 Opzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4 Rete composta da PDA slave e PC master . . . . . . . . . . . 78
ix
x ELENCO DELLE FIGURE
Capitolo 1
Introduzione
1.1 I sistemi distribuiti
Ultimamente, con l’avanzamento delle tecnologie, sentiamo sempre piu spes-
so parlare di sistema distributo, ma e bene aver chiaro cosa si intende con
questo termine. Un sistema distribuito e un sistema composto da un insieme
di computer che comunicano tra loro, grazie ad un set comune di protocolli, e
coordinano le loro azioni attraverso lo scambio di messaggi all’interno di una
rete. In un sistema di questo tipo i processori non condividono la memoria
o un clock, bensı ognuno di essi ha una sua memoria. Questa e proprio la
caratteristica che distingue i sistemi distribuiti dai sistemi multiprocessore.
I processori di un multiprocessore, infatti, detti anche saldamente accoppiati,
condividono la memoria e un clock, e la comunicazione avviene normalmente
attraverso la memoria condivisa. I processori di un sistema distribuito, in-
vece, sono chiamati debolmente accoppiati, questo perche la comunicazione
avviene attraverso una rete inaffidabile, con ritardi di trasmissione estrema-
mente variabili e velocita e banda moderate.
1
2 CAPITOLO 1. INTRODUZIONE
I motivi principali della grande diffusione dei sistemi distribuiti sono i se-
guenti:
1. Condivisione delle risorse: Un sistema distribuito permette il gran-
de beneficio della condivisione delle informazioni e delle risorse. Questa
e la strategia che sta alla base di tutti i server e i siti basati su Internet,
e di tutti i server privati basati su reti proprietarie Intranet. Se abbia-
mo siti diversi, con risorse diverse e collegati tra loro, allora qualsiasi
utente di un sito ha la possibilita di accedere alle risorse disponibili su
un altro sito. Questo e stato un grosso passo in avanti ed e anche uno
tra i motivi che ha portato la nascita dei sistemi distribuiti.
2. Accelerazione dei calcoli: Se ci troviamo in un sistema distribuito
costruito da una rete di computer e dobbiamo svolgere un particolare
calcolo, che puo essere suddiviso in piu sottocalcoli eseguibili concor-
rentemente, e possibile distribuire la computazione sui diversi nodi, per
un’esecuzione concorrente ed evitare che il carico di lavoro gravi su una
singola macchina.
3. Affidabilita: E’ una tra le piu importanti capacita di un sistema distri-
buito. Grazie alla sua ridondanza intrinseca, spesso riesce a sopravvi-
vere ad un guasto evitando il fallimanto dell’intero sistema. In pratica,
se un nodo di un sistema distribuito si guasta, i restanti possono poten-
zialmente continuare a lavorare, mantenendo, anche se con una certa
quantita di degrado, il funzionamento del sistema. Questo e dovuto al
fatto che generalemente il guasto di un componente non infuisce sugli
altri appartenenti alla stessa rete e che se il sistema e ridondante, sia
a livello hardware che software, puo continuare a funzionare anche in
seguito ad alcuni guasti.
1.1. I SISTEMI DISTRIBUITI 3
4. Comunicazione: All’interno di un sistema la comunicazione e sem-
plice e veloce.
5. Performance e disponibilita del servizio: Come e ben noto nessun
server puo offrire performance infinite e neppure puo rimanere attivo in
maniera continuativa. Tuttavia un sistema distribuito garantisce molto
spesso, grazie all’uso di molte strategie, come ad esempio le tecniche
di bilanciamento del carico o l’utilizzo di server replicati in parallelo,
l’incremento della performance e della disponibilita del sistema. Uti-
lizzare server replicati in parallelo e una tra le migliori soluzioni che
esistono per evitare che al fallimento di un singolo server corrisponda
anche al fallimento dell’intero sistema.
6. Sistemi scalabili: L’utilizzo di architetture modulari nella costruzione
di un sistema distribuito, permette la realizzazione di sistemi scalabili.
Tuttavia esistono anche alcuni svantaggi di cui dobbiamo tener conto quando
trattiamo con sistemi distribuiti, come:
1. Produzione di software: Fino a pochi anni fa, uno dei piu seri proble-
mi riguardo lo sviluppo dei sistemi distribuiti era dato dalla mancanza
di strumenti software per la realizzazione di applicazioni che potessero
mostrare al mercato l’importanza di tali sistemi. Tuttavia adesso sono
nate nuove metodologie e nuovi linguaggi che permettono sempre piu
la gestione dei sistemi distribuiti. Pensiamo solo al linguaggio JAVA
che permette l’indipendenza del prodotto software, dall’hardware e dal
sistema operativo.
2. Sicurezza: Nel momento in cui un’informazione viene decentralizzata
e abbiamo a che fare con un flusso di informazioni sulla rete, emerge
4 CAPITOLO 1. INTRODUZIONE
sempre il problema della sicurezza. Nei sistemi centralizzati, questo
problema non sussiste poiche la sicurezza e per lo piu un motivo fisico,
legato ai dati locali. Qui invece, dobbiamo affrontare problematiche re-
lative alla sicurezza della comunicazione e sicurezza rispetto ad accessi
indesiderati ai dati attraverso la rete.
1.1.1 Sistemi sincroni e asincroni
I sistemi distribuiti si possono classificare in base a diversi parametri come
il grado di sincronia, la tipologia di fallimenti o la topologia della rete. La
classificazione principale e sicuramente quella tra sisitemi sincroni e asin-
croni.
Per definizione un sistema si dice sincrono, se esiste ed e noto un limite su-
periore sul ritardo di consegna dei messaggi, si conosce il tasso di deviazione
del clock locale di ogni processo rispetto ad un tempo reale ed e nota e
limitata la velocita di elaborazione di ogni processo. Un sistema di questo
tipo permette una facile implementazione dei meccanismi di individuazione
dei fallimenti basati su timeouts, quindi e come se il sistema permettesse un
maggior controllo e un maggiore livello di rilevazione degli errori. Al tempo
stesso tuttavia non e semplice assicurare che queste proprieta siano garantite
su un sistema di grande scala e nel tempo.
Un sistema distribuito si dice asincrono se non ci sono limiti di ritardo sulla
consegna dei messaggi, sulla deviazione dei clock o sul tempo necessario per
eseguire una singola computazione. I vantaggi di questo modello riguardano il
fatto che non c’e bisogno di nessuna assunzione temporale e che la trasporta-
bilita delle applicazioni e sicuramente piu alta. Esiste tuttavia uno svantaggio
molto grosso dovuto al fatto che molti tra i piu importanti problemi, se ipo-
tiziamo un modello di sistema asincrono, non ammettono soluzione ([3]).
1.2. DEPENDABILITY 5
E’ chiaro che se pur il modello sincrono e piu semplice da gestire, quello
asincrono e sicuramente piu realistico. Infatti, come si illustrera in seguito, i
sistemi che tratteremo e anche quelli piu diffusi, sono sostanzialmente delle
reti formate da insiemi di PC che lavorano in maniera asincrona o al massimo
che presentano una sincronia parziale.
1.2 Dependability
Sviluppare del software per sistemi distribuiti non e facile come per i sistemi
centralizzati. Per esempio, pensiamo al fatto che nei sistemi centralizzati gli
eventi seguono un ordine sequenziale ed una logica deterministica. I sistemi
distribuiti, invece, a causa delle continue interazioni tra le componenti del
sistema e a causa della sovrapposizione degli eventi o interleaving, i malfun-
zionamenti della rete sono molto piu difficili da prevedere. Nel corso degli
ultimi anni e nata tuttavia un’intensa attivita di ricerca con lo scopo di for-
nire delle metodologie e degli strumenti per garantire la correttezza di questi
sistemi. In particolare si sono fatti numerosi studi sulla correttezza di un
sistema e sulla capacita di predire per quanto tempo un sistema funzionera
bene, sia in presenza di guasti che in situazioni normali.
Definizione 1 La dependability e la capacita di fornire un servizio su cui
si puo fare affidamento in maniera giustificata.
In altre parole rappresenta una misura di quanta fiducia possiamo riporre,
in maniera giustificata, sul servizio fornito da un sistema. Per servizio for-
nito si intende il comportamento dinamico del sistema percepito dall’utente
tramite l’interfaccia del servizio. Un sistema puo definirsi proprio se rispetta
le specifiche funzionali stabilite e improprio altrimenti. La funzione di un
sistema rappresenta che cosa ci attendiamo dal sistema; la descrizione della
6 CAPITOLO 1. INTRODUZIONE
funzione di un sistema e fornita attraverso la sua specifica funzionale. Il
servizio e detto corretto se realizza la funzione del sistema ([5]). Per fallimen-
to si indica una transizione che porta da uno stato di sistema proprio ad uno
improprio, mentre per ripristino si intende il contrario. Per capire quali sono
Figura 1.1: Gli stati di un servizio
i modi sistematici per costruire sistemi dependable e necessario definire quali
sono gli impedimenti alla dependability, i mezzi per ottenerla e gli attributi.
Gli impedimenti sono le cause potenziali di comportamenti non previsti. I
mezzi sono le tecniche che permettono di ottenere comportamenti corretti,
nonostante il verificarsi degli impedimenti. Gli attributi ci permettono invece
di esprimere e verificare il livello di dependability richiesto ([2]). Mostriamo
adesso piu in dettaglio questi concetti.
Impedimenti alla dependability
In una macchina di Von Neumann, se si rompe il processore l’algoritmo non
puo far altro che arrestarsi. In un sistema distribuito, se si rompe un proces-
sore il sistema continua in parte a lavorare, per cui gli algoritmi distribuiti
potrebbero essere progettati per tollerare una quantita limitata di compor-
tamenti scorretti da parte del sistema. L’errore piu comune e pensare che
1.2. DEPENDABILITY 7
l’hardware, su cui l’algoritmo gira, sia completamente affidabile e quindi che
nel sistema non si verifichi alcun tipo di guasto.
Purtroppo molto spesso ci trovamo davanti a comportamenti scorretti cau-
sati proprio dai processori: a volte possono fermarsi improvvisamente (stop
failures), con o senza avviso, o possono comportarsi in maniera arbitraria
(Bizantine failures). Tutti gli algoritmi che riescono a tollerare quest’ultimo
tipo di guasto hanno una grande importanza perche sono usati per risolvere
problemi di sicurezza.
Il comportamento degli algoritmi distribuiti e spesso abbastanza difficile da
capire a causa della grande incertezza che li caratterizza. Alcune volte, per
esempio, non si conosce il numero di processori nella rete o la topologia del-
la rete stessa, mentre altre volte l’incertezza puo essere dovuta anche alla
sincronia, in quanto si puo non conoscere l’istante in cui l’algoritmo sara ef-
fettivamente lanciato o a che velocita girera.
Tuttavia per capire meglio la propagazione dei guasti e la generazione dei
fallimenti nel sistema si puo descrivere una catena degli impedimenti com-
posta da guasti, errori e fallimenti. Un guasto puo essere fisico, ovvero
dovuto a cause interne come i cortocircuiti, oppure esterne come le condizioni
atmosferiche o gli influssi elettromagnetici. Puo essere causato da fenomeni
accidentali o imprevisti oppure dovuti ad un guasto umano, per esempio pro-
vocato da uno sbaglio nel design del sistema, sia in fase iniziale che durante
l’implementazione. Il guasto non si manifesta fino alla sua attivazione, dopo-
diche si propaga nel sistema coinvolgendo una o piu componenti, provocando
cosı un errore. Quando gli errori arrivano all’interfaccia di servizio e anche
l’utente ne viene a conoscenza, allora proprio in quel momento si verifica un
fallimento. I fallimenti possono essere benigni se le loro conseguenze non
8 CAPITOLO 1. INTRODUZIONE
hanno costi eccessivi rispetto al servizio offerto mentre catastrofici se le con-
seguenze non sono accettabili o da un punto di vista del costo o del danno
provocato all’ambiente ([4]).
Figura 1.2: Catena Guasti Errori e Fallimenti
Gli attributi della dependability
Per poter rappresentare il grado di dependability vengono usati degli attri-
buti come availability, reliability, confidentiality, integrity, maintenability e
la safety, con i seguenti significati ([4]):
• L’availability misura la capacita di un sistema di fornire un servizio
proprio.
• La reliability misura la fornitura continua del servizio offerto.
• La confidentiality e la misura di come il sistema conservi ”privata-
mente” i dati al suo interno e non divulghi informazioni senza autoriz-
zazione.
• L’integrity e la misura che riguarda il livello di mantenimento dei dati
integri nel sistema.
• La maintenability indica la capacita del sistema di ripristinare il
servizio.
1.2. DEPENDABILITY 9
• La safety e la misura dell’occorrenza di eventi catastrofici per l’utente
e l’ambiente, o non catastrofici.
• Il coverage e la misura della probabilita che dato che si e verificato un
guasto, il sistema riesca a tolleralo.
Ovviamente per ogni sistema, in base alle funzioni che deve svolgere, saranno
importanti solo alcune di queste misure. Ad esempio, solitamente l’availabi-
lity e sempre richiesta, mentre tutte le restanti possono interessare o meno.
Tuttavia esistono anche altri attributi come la performance, il costo e la
performability. Con il primo termine si indicano tutte le misure che rap-
presentano come un sistema fornisce un servizio, sia in termini di efficacia
sia di efficienza, mentre con il termine performability si intende quanta ca-
pacita ha un sistema di fornire un servizio degradato in seguito a fallimenti.
La performability e in definitiva una proprieta nata dalla combinazione tra
perfomance e dependability.
Mezzi per ottenere la dependability
I mezzi per garantire la dependability di un sistema sono costituiti da quattro
insiemi di tecniche fondamentali ([4]):
1. Fault Removal: e una tecnica che prevede il rilevamento e la rimozio-
ne dei guasti prima della loro attivazione. Grazie a questa possibilita
si tenta di individuare sia nella fase di sviluppo che nella fase operativa
di rimuovere i bug software o i difetti hardware.
2. Fault Prevention: rappresenta quella serie di tecniche che si occupano
di prevenire tutte le possibili cause di errori, eliminando le condizioni
che rendono l’occorrenza dei guasti piu probabile.
10 CAPITOLO 1. INTRODUZIONE
3. Fault Tolerance: corrisponde a quell’insieme di tecniche per riuscire
a fornire un servizio proprio in presenza di guasti.
4. Fault Forecasting: e una qualunque tecnica utilizzata per prevedere
l’evento di guasti nel sistema che solitamente si basa su valutazioni
qualitative e quantitative del comportamento del sistema.
Validazione
In modo informale, la validazione risponde alla domanda: ”Stiamo costruen-
do il sistema corretto?”. Per poter validare un sistema e importante saper
controllare se tale sistema rispetta o meno le specifiche in modo soddisfacen-
te. Questo aspetto prende nome di processo di validazione.
Validare un sistema distribuito rappresenta un grosso scoglio in termini di
difficolta e per poter raggiungere gli scopi prefissatisi esiste una vera e propria
combinazione di tre metodologie di supporto nello studio dei vari algoritmi.
Si parla infatti di: un approccio analitico tramite il quale vengono misurate
le prestazioni basandosi su un modello parametrico dell’ambiente di esecu-
zione.
Un approccio simulativo grazie al quale la simulazione avviene in un ambien-
te d’esecuzione che solitamente fa uso di un modello stocastico.
E infine un approccio basato sulle misure nel quale l’algoritmo e eseguito in
un ambiente reale in parallelo ad un sistema di monitoraggio che raccoglie
dati e risultati.
L’utilizzo di una singola tecnica puo non essere sufficiente in tutti i casi; in ge-
nerale possono essere utilizzate combinazioni appropriate di queste tecniche
per la specifica, la costruzione e la soluzione del modello. Tuttavia l’analisi e
la valutazione delle prestazioni di algoritmi distribuiti e un’operazione mol-
to difficile poiche molto spesso richiede un sforzo eccessivo sia in termini di
1.2. DEPENDABILITY 11
progettazione che in fase di sviluppo. A questo proposito ci viene in aiuto
Neko.
12 CAPITOLO 1. INTRODUZIONE
Capitolo 2
I vantaggi di possedere Neko
1.0 su un palmare
Lo scopo di questa tesi e di rendere il framework Neko 1.0 alpha 2, realizzato
a Lausanne da Peter Urban e Xavier Defago, portabile su qualsiasi tipo di
piattaforma e in particolare su dispositivi di dimensioni ridotte. Poiche Neko
e uno strumento per la valutazione e l’analisi dei sistemi distribuiti ed in
particolare per quei sistemi con difficolta di disponibilita, affidabilita e sicu-
rezza, ci siamo subito posti una serie di domande.
Prima di tutto ci siamo chiesti se fosse utile e possibile eseguire algoritmi di-
stribuiti su piccoli dispositivi. La risposta e sicuramente si, infatti si possono
trovare numerosi esempi che mostrano i vantaggi di eseguire un determinato
algoritmo su un piccolo dispositivo mobile piuttosto che su un pesante com-
puter di vecchio stampo. Dopodiche si e pensato che Neko 1.0 alpha 2 era
proprio il framework di analisi utile da poter mettere in esecuzione sui piccoli
device e da qui e iniziata la progettazione di NekoPDA.
13
14CAPITOLO 2. I VANTAGGI DI POSSEDERE NEKO 1.0 SU UN PALMARE
2.1 La diffusione dei palmari nella quotidia-
nita
A mano a mano che passano gli anni la diffusione dei palmari si sta facendo
sempre piu invasiva nella vita di tutti i giorni. I PDA non sono piu un ”giocat-
tolo” per manager appassionati di nuove tecnologie e si stanno rapidamente
diffondendo anche tra gli studenti. Nelle scuole americane, ad esempio, il
palmare e utilizzato come uno strumento per migliorare la didattica, stimo-
lare la collaborazione e l’organizzazione degli studenti stessi. Inoltre, i costi
ridotti rispetto ai computer portatili e il costante aumento delle applicazioni,
spesso gratuite, stanno diffondendo ancor di piu l’uso dei PDA all’interno
dell’ambiente scolastico. Non solo, questi dispositivi possono anche rivelarsi
un ottimo strumento per persone disabili oppure per persone con disabilita
cognitive e difficolta di apprendimento.
Non e possibile dimenticarsi di citare un altro importante ambito di applica-
zione dei palmari: la sanita. Come indica l’esito di una indagine compiuta
da Skyscape, una societa che si occupa di studiare applicazioni per l’ambiente
medico con speciale riferimento a quelle per i dispositivi mobili, piu del 50%
dei medici americani usa un PDA. Grazie a questo nuovo strumento si riduce
il tempo speso dai medici in studio davanti al computer desktop e aumenta
quello a disposizione per le visite e la cura dei pazienti. Tra gli altri dati che
emergono dall’indagine si nota anche come i medici ne facciano un uso molto
intenso. L’88% lo impega almeno quattro volte il giorno, ma il 15% lo usa
piu di venticinque volte il giorno per ragioni professionali, nell’ambito delle
prescrizioni, delle referenze e interazione tra medicinali. L’85% dei medici
ammette che l’uso del palmare ha ridotto notevolmente il margine d’errore
2.1. LA DIFFUSIONE DEI PALMARI NELLA QUOTIDIANITA 15
sulle prescrizioni mediche e sui vari documenti e incrementato il numero di
visite che sono in grado di compiere. Inoltre i medici possono utilizzare il
palmare al posto del cercapersone e come GPS nella, sempre difficile, ricerca
dell’ abitazione del paziente durante le visite a domicilio.
Proprio per tutte queste applicazioni e utile poter installare il framework Ne-
ko sul PDA. Grazie a questo strumento e possibile ad esempio effettuare la
validazione sul sistema relativo all’invio e alla ricezione dei messaggi destinati
al medico. Supponiamo che ogni medico possegga un palmare e che voglia
scambiarsi infomazioni utili con l’ufficio o con i colleghi tramite una serie di
brevi messaggi. Neko puo essere usato in questo caso per la validazione del
sistema che si occupa del cercapersone, molto importante per garantire la
reperibilita del medico da parte dei pazienti, dei colleghi e dei tecnici.
Figura 2.1: Gestione degli appuntamenti per i medici
E’ facile capire come anche la figura del commesso si diriga verso l’utilizzo
delle nuove tecnologie. Ogni tipo di commesso che si rispetti, oggi giorno, ha
un PDA alla portata di mano con il quale puo consultare i database centrali
per ricavare informazioni su un prodotto o sulla sua disponibilita in magaz-
zino, incidendo in modo determinante sulla soddisfazione del cliente. Nei
16CAPITOLO 2. I VANTAGGI DI POSSEDERE NEKO 1.0 SU UN PALMARE
supermercati ad esempio, e da molto tempo che si utilizzano palmari speci-
fici per questi scopi. Essi si chiamano PDCU (Portable Data Capture Unit),
sono piccoli computer portatili dotati di una batteria propria e di scanner
per leggere i codici a barra. Sono utilizzati per salvare i dati e informazioni e
si sono rivelati un utile strumento per la pratica del ”controllo prezzi”, grazie
al confronto tra il prezzo indicato sullo scaffale e quello contenuto sul listino
di riferimento, con grande soddisfazione sia degli addetti al controllo, sia dei
i clienti scettici. Tuttavia i PDCU sono stati sorpassati a causa delle ecces-
sive dimensioni e della loro pesantezza. Il palmari di oggi invece sono molto
piu performanti e sono diventati un ”must” per la generazione di dirigenti di
medio e alto livello. Essi infatti hanno dimensioni ridottissime, moltissime
funzionalita e collegamenti wireless a database centrali per l’acquisizione di
informazioni in tempo reale. E’ possibile cosı acquisire sempre informazio-
ni sui prodotti, controllare la quantita di merce disponibile in magazzino,
immettere dati relativi ad oridini speciali, usufruire di funzionalita di cassa
EPoS (Electonic Point of Sale) mobile1 ed eliminazione delle code.
In questo caso il framework Neko puo essere utilizzato per la validazione
del sistema che si occupa dello scambio di messaggi tra il palmare ed il ma-
gazzino. Risulta importante infatti, affiche non si verifichi in alcun caso la
perdita, il furto e la rottura di stock dei prodotti, garantire che la merce in
magazzino e quella in vendita raggiunga il numero previsto. Il compito di
Neko sara proprio quello di garantire che il sistema di gestione non provochi
fallimenti di alcun tipo.
Se scendiamo piu nel particolare, esistono anche alcuni algoritmi piu specifici,
a lungo studiati, per risolvere, ad esempio, il problema del raggiungimento di
1(EPOS) e un sistema che disattiva le etichette elettroniche (o EAS) ogni qual volta
un prodotto viene acquistato.
2.1. LA DIFFUSIONE DEI PALMARI NELLA QUOTIDIANITA 17
Figura 2.2: Gestione delle vendite
soluzioni comuni tra un gruppo di dispositivi. Tra gli esempi piu significativi
ci sono tutti quelli creati per risolvere il problema del consenso oppure tutti
quelli nati a risolvere l’elezione di un leader in un anello.
Tuttavia se il progetto ad esempio fosse quello di gestire il traffico all’interno
di una rete autostradale tramite dispositivi satellitari, Neko sarebbe molto
utile se installato su un palmare. Potrebbe garantire la gestione dell’innesto
dei veicoli in carreggiata oppure assicurare che le informazioni sul traffico
siano perfettamente ricevute, utilizzando tutti i dati inviati dagli altri device
coinvolti.
18CAPITOLO 2. I VANTAGGI DI POSSEDERE NEKO 1.0 SU UN PALMARE
Figura 2.3: Gestione del traffico
Se il problema fosse invece quello della raccolta dei dati, i piccoli device,
all’interno di una rete mista e composta da computer desktop e PDA, po-
trebbero svolgere il ruolo di immagazzinatori temporanei. Una volta raccolte
tutte le informazioni necessarie, potrebbero inviare i risultati ad un device
piu potente e appartenente alla rete, il quale avrebbe il compito di elaborare
i dati per raggiungere i propri scopi.
In questa situazione Neko evrebbe il compito di validare e tastare una simile
collaborazione evitando fallimenti e il blocco del circolo delle informazioni.
Per tutti questi esempi e molte altre applicazioni e utile poter installare il
framework Neko per analizzare, validare ed effettuare simulazioni dei vari
sistemi e dei vari algoritmi distribuiti.
In questa tesi sara effettuata un’analisi di Neko, verranno percepite le parti
essenzali, che ne garantiscono un minimo funzionamento. Saranno poi de-
scritte tutte le scelte effettuate e illustrato in cosa consiste la trasformazione
di Neko: da strumento dedicato ai soli computer desktop, a framework uti-
lizzato nello studio di algoritmi in esecuzione sui piccoli device PDA. E’ da
2.2. LE RELAZIONI TRA NEKO E I PDA 19
notare il fatto che da adesso in poi tratteremo sempre di reti PAN (Personal
Area Network) costituite da dispositivi palmari e da computer desktop. Non
faremo mai riferimento a reti i cui device coinvolti sono soltanto PDA. Que-
sto perche, la maggior parte delle volte, gli obiettivi dei sistemi distribuiti
sono tali da aver sempre bisogno di almeno un computer desktop con grande
disponibilita di memoria e su cui risiede la maggior parte del software.
2.2 Le relazioni tra Neko e i PDA
Lo scopo che si intende raggiungere al termine di questa tesi e quello di
presentare una possibile architettura del framework Neko da installare sul
PDA. Prima di tutto e stato necessario effettuare uno studio di Neko, della
sua architettura e del suo funzionamento. In seguito e stata eseguita una
dettagliata ricerca delle Java Virtual Machine compatibili, sia con le caratte-
ristiche fisiche del palmare che con quelle software. Dopodiche siamo passati
ad un’analisi di fattibilita ed ad una fase di progettazione riguardante le par-
ti di codice del framework necessarie al suo funzionamento su un dispositivo
di disponibilita di memoria ridotta come un palmare. Una volta effettuata
questa fase il nuovo pacchetto, appena costruito, puo essere testato, ovvero
puo essere provato in esecuzione su un piccolo dispositivo. Ovviamente i te-
st effettuati sono riferiti ad esecuzioni applicate al palmare DellAxim x51v
ed anche se non si sono avuti risultati del tutto positivi dal punto di vista
sperimentale, e stato possibile creare in fase progettuale un’architettura del
framework Neko dedicato in futuro ai PDA. Il codice e stato inizialmente
ripulito dalle parti superflue e sono state pensate piccole modifiche al codice
e ulteriori adattamenti per poter cercare di rendere compatibile Neko con il
nuovo supporto.
20CAPITOLO 2. I VANTAGGI DI POSSEDERE NEKO 1.0 SU UN PALMARE
Prima di tutto e stato indispensabile procurarsi un PDA (Personal Digital
Assistants) di ultima generazione, con una sufficiente disponibilita di me-
moria e con installato su di se un sistema operativo abbastanza recente e
piuttosto robusto.
Dopodiche sono state fondamentali numerose ricerche riguardanti il funzio-
namento e le applicazioni inerenti ai palmari di ultima generazione e in parti-
colare riferite al PDA DellAxim x51v, fornito dal Dipartimento di Sistemi e
Informatica dell’Universita di Firenze. Una volta documentati sui vari siste-
mi operativi e sulle Java Virtual Machine dedicate, e stato possibile disegnare
una vera e propria architettura del pacchetto NekoPDA, ovvero un insieme
di classi destinate a risiedere sul palmare.
Durante questa fase di progettazione sono emerse molte difficolta per quanto
riguarda la compatibilita, ma vedremo piu avanti quali sono state le prove
eseguite e i risultati ottenuti.
Il seguente capitolo si occupera invece di descrivere il framework Neko, dare
un breve chiarimento sulla sua architettura e illustarare cos’e e a cosa serve
il tool NekoStat.
Capitolo 3
Che cos’e Neko
3.1 La piattaforma Neko
La piattaforma Neko e un sistema di comunicazione che permette l’esecuzio-
ne, la simulazione e lo studio di algoritmi distribuiti. E’ uno strumento per
la valutazione e l’analisi delle caratteristiche offerte da sistemi distribuiti ed
in particolare e molto utile per quei sistemi con difficolta di disponibilita,
affidabilita e sicurezza. Neko fornisce risultati ottenuti sia da un’analisi si-
mulativa che da un’analisi basata sull’esecuzione reale, garantendo in questo
modo una migliore attendibilita e sicurezza sui risultati ottenuti.
Il prossimo paragrafo mostra piu in dettaglio l’architettura di Neko senza
scendere troppo nei particolari.
3.1.1 L’architettura di Neko
L’architettura di Neko e composta da una parte applicativa e una parte ri-
guardante le reti. A livello applicativo i processi sono numerati e comunicano
utilizzando un’interfaccia di trasmissione ad hoc che funziona nel seguente
modo: da un lato, vi e un processo sorgente, che richiamando la primitiva
21
22 CAPITOLO 3. CHE COS’E NEKO
asincrona Send, invia un messaggio sulla rete. La rete a sua volta ha il com-
pito di consegnarlo al processo destinazione attraverso la primitiva Deliver.
L’applicazione e strutturata a livelli, chiamati layer, e tali strati sono uti-
lizzati dai processi per l’invio e la ricezione dei messaggi. Ogni messaggio
attraversa i layer grazie all’uso delle primitive Send e Deliver, e in partico-
lare Send ha lo scopo di accompagnare i messaggi da un livello piu alto ad
uno piu basso, mentre Deliver al contrario li trasporta verso strati piu alti.
Nella seguente figura si mostra graficamente cosa si intende per ”un’appli-
cazione e strutturata a livelli” e come i messaggi possono attraversare i vari
layer.
Figura 3.1: Architettura Neko
3.1. LA PIATTAFORMA NEKO 23
I Layer
Quando parliamo di layer e necessario distinguere quelli attivi da quelli pas-
sivi. Mentre i layer attivi dispongono di propri thread di controllo, quelli
passivi si limitano a ricevere messaggi. La ricezione puo avvenire dai livelli
sottostanti, e in questo caso il layer dovra occuparsi di inoltrare i messaggi
ai livelli superiori, oppure se i messaggi arrivano dai livelli superiori il layer
fara in modo di inoltrarli a quelli inferiori.
Nei layer attivi invece quando un livello sottostante riceve un messaggio da
una Deliver, questo lo inserisce in una coda FIFO (First In First Out).
Quando il thread di controllo e in esecuzione e possibile eseguire la primi-
tiva Receive che preleva un nuovo messaggio dalla coda e al tempo stesso,
essendo bloccante, se non ci sono messaggi in coda, pone il thread in attesa.
Tuttavia esiste anche una primitiva Receive con timeout non bloccante e
un metodo Deliver diverso da quello standard che puo essere richiamato dai
layer sottostanti proprio come avviene nei layer passivi. La figura riportata
qui sotto presenta in modo grafico la differenza tra un layer attivo e uno
passivo.
Figura 3.2: Layer passivi e layer attivi
24 CAPITOLO 3. CHE COS’E NEKO
I NekoProcess
Un’altro elemento fondamentale nell’architettura del framework sono gli og-
getti NekoProcess. Ogni processo ha associato un oggetto NekoProcess che
ha il compito di mantenere informazioni utili come: l’indirizzo di rete del pc
su cui risiede il processo e il tempo locale, l’ID numerico associato al proces-
so stesso e l’implementazione dei servizi di utilita come il log dei messaggi
spediti e ricevuti da un processo. Se l’applicazione inoltre utilizza piu reti
in parallelo l’oggetto NekoProcess si occupa che i messaggi siano inviati e
ricevere sulla rete appropriata. Le primitive di comunicazione trasmettono
messaggi con cui i processi Neko comunicano. Questi messaggi, che sono alla
base del funzionamento di Neko, sono oggetti di tipo NekoMessage e sono
caratterizzati da un contenuto e da un’intestazione, la quale comprende gli
indirizzi del processo mittente e destinatario, informazioni riguardanti la rete
e il tipo di messaggio.
Figura 3.3: Il NekoMessage
3.1. LA PIATTAFORMA NEKO 25
Le reti
L’architettura base sulla quale Neko lavora e una rete che puo essere reale o
simulata. Per quanto riguardano le reti reali, Neko prevede alcune reti gia
sviluppate sulla base di socket Java o su specifiche librerie come TCPNet-
work, UDPNetwork, PMNetwork, MulticastNetwork ed EnsambleNetwork.
Per quanto concerne le reti simulate, Neko possiede alcuni modelli semplifi-
cati di reti originali gia predefinite senza considerare i fenomeni complessi.
In ogni caso la prima fase per un’applicazione Neko e caratterizzata da una
parte di configurazione che avviene mediante un singolo file contenente tutte
le informazioni utili per istanziare i vari processi.
Nel caso di un’esecuzione reale in gioco abbiamo un processo master, che
coordina l’esecuzione, e m-1 processi slave. Il processo master prende in
input un file di configurazione contenente tutte le informazioni sull’indirizza-
mento dei processi slave e in base alla rete di cui fa uso l’esperimento (TCP,
UDP, INDIRIZZO IP:PORTA ecc..) gli indirizzi da associare cambiano. Il
compito del master e quindi di contattare gli slave e fornire le informazioni
utili per il loro avvio. Inoltre, per non dover riattivare i singoli processi sla-
ve ad ogni nuova esecuzione di applicazione, sono presenti appositi processi,
sempre in esecuzione, sugli host che vogliamo utilizzare come slave. Questi
processi sono chiamati slave factories e il loro scopo e quello di stare in attesa
per eventuali comunicazioni da parte di un master Neko al fine di istanziare
ed eseguire un nuovo slave.
Nel caso di una simulazione lo startup e piu semplice poiche i singoli processi
sono eseguiti sotto forma di differenti thread in esecuzione all’interno della
stessa Java Virtual Machine. Lo shutdown per la terminazione dell’appli-
cazione invece, non e altro che una funzione che puo essere richiamata da
qualunque processo, e porta alla terminazione di tutti i processi che fanno
26 CAPITOLO 3. CHE COS’E NEKO
parte dell’applicazione.
Figura 3.4: Reti reali e simulate
I Microprotocolli
Nell’ultima versione di Neko appare anche una nuova struttura: i micropro-
tocolli. Essi sono stati sviluppati usando un oggetto che implementa l’inter-
faccia Protocol e la maggior parte di loro estende la classe ProtocolImpl.
Sono contenuti all’interno dei processi e si differenziano tra loro grazie al
proprio identificatore univoco. Questo significa che i microprotocolli, pur
essendo univoci all’interno di uno stesso processo, non necessariamente lo
sono all’interno dell’applicazione Neko. Gli identificatori sono costruiti dalla
classe AbstractId e sono usati sia per la diagnostica dei messaggi che per la
comunicazione con microprotocolli di altri processi.
La vita di ogni microprotocollo consta delle seguenti fasi:
1. prima avviene la chiamata al costruttore
2. dopodiche si procede con la chiamata ai metodi di settaggio
3.1. LA PIATTAFORMA NEKO 27
Figura 3.5: L’invio dei messaggi tramite microprotocolli
3. una volta chiamati e terminati i settaggi, il microprotocollo e costruito e
si procede ad invocare il metodo launch, che registra il microprotocollo
nel contenitore.
4. infine sono chiamati gli altri metodi (questa fase deve essere fatta
necessariamente dopo aver completato il punto tre.
I microprotocolli, appartenenti a processi differenti, comunicano tra loro in-
vocando il metodo SenderInterface.send(NekoMessage) sul microproto-
collo destinatario nel processo mittente. Per questo motivo e necessario che
il mittente specifichi, nei campi di NekoMessage, l’indirizzo\i del processo\i
destinazione, l’id del microprotocollo di destinazione, il tipo di messaggio e
il suo contenuto. Il funzionamento viene mostrato graficamente in figura 3.5.
In definitiva Neko simula e studia il comportamento di un algoritmo in pre-
senza di particolari condizioni come la perdita di messaggi, i ritardi di tra-
smissione, la congestione, il sovraccarico ecc.. Al fianco di questa piattaforma
esiste un pacchetto chiamato NekoStat che estende Neko in modo da sem-
plificare le fasi di progettazione, quelle di testing e l’analisi degli algoritmi
distribuiti. Nella seguente sezione si descrive questo pacchetto in modo piu
dettagliato mostrandone le caratteristiche e l’utilita.
28 CAPITOLO 3. CHE COS’E NEKO
3.2 Il Tool NekoStat
Neko al termine della simulazione o dell’esecuzione reale restitutisce un file
di log e l’utente puo decidere se analizzare e interpretare direttamente que-
sto file, ricavandosi le informazioni opportune, oppure utilizzare il pacchetto
NekoStat. Effettuare la prima analisi non e la strada migliore in quanto
prima di tutto opera in modalita off-line, in secondo luogo e molto difficile
ricostruire la vita di ogni processo e per ultimo, ma non meno importante,
l’utente deve realizzare meccanismi ad hoc per il calcolo delle misure.
Grazie al tool NekoStat, che estende la versione di Neko 0.9, e possibile invece
effettuare, oltre all’interpretazione dei file di log, una valutazione quantitati-
va delle applicazioni che girano su Neko, sia che si tratti di simulazioni, che
di esecuzioni reali. In entrambi i casi tuttavia occorre inserire alcune chiama-
te all’interno dell’implementazione per poter registrare in fase di esecuzione
gli eventi che interessano. L’approccio NekoStat permette di effettuare le
valutazioni in maniera automatica, infatti opera in modalita off-line per le
esecuzioni reali, mentre lavora in parallelo per l’analisi delle simulazioni.
NekoStat prevede la stessa interfaccia sia per lo studio di algoritmi in si-
mulazione, che per l’esecuzione di eventi reali e nel prossimo paragrafo si
individueranno le peculiarita piu importanti della sua architettura.
3.2.1 Architettura di NekoStat
La struttura che vi e alla base di NekoStat e la medesima di Neko, l’unico
aspetto che le differenzia e il fatto che il nuovo tool di analisi possiede frap-
posto tra i layer dell’applicazione e la rete, un layer supplementare e nuove
strutture allo scopo di campionare i risultati dei vari algoritmi eseguiti. E’
composta essenzialmente da cinque componenti che sono approfondite qui di
3.2. IL TOOL NEKOSTAT 29
seguito.
• StatLogger e un’interfaccia unica per tutti i processi e ha due funzioni
distinte: nel caso di simulazioni ha il ruolo di ricevere tutti gli eventi,
richiamare lo StatHandler per la gestione degli eventi e controllare se
la simulazione puo essere interrotta, ovvero se si e raggiunto un grado
di confidenza ottimale. Nel caso di una esecuzione reale, StatLogger
si occupa di raccogliere per ogni processo gli eventi da inviare al ma-
ster al terminine dell’esecuzione. Inoltre, poiche il suo comportamento
e molto diverso nel caso si tratti di una simulazione o di un evento
reale, l’implementazione vera e propria e il delinearsi dei sui compiti
vengono esplicate nelle classi StatLoggerSim, per le simulazioni, Sta-
tLoggerSlave e StatLoggerMaster rispettivamente per il master e
per gli slave nelle esecuzioni reali.
• Event non e altro che il contenitore delle informazioni riguardanti gli
eventi del sistema. Infatti ogni evento e composto da un identificatore
ovvero un numero che lo rappresenta, da un tempo (simulato o reale) ov-
vero il periodo in cui l’evento si e verificato, da una descrizione e dal
contenuto rappresentato da un vero e proprio oggetto Java utilizzato
per l’inivio di informazioni tra componenti.
• StatHendler ha l’incarico di gestire gli eventi per annoverare tutte le
misure di particolare interesse. Ovviamente deve essere realizzato dal-
l’utente poiche dipende molto dal tipo di applicazione e dalle misure che
si intende estrarre per l’analisi. Per questo motivo e necessario seguire
una traccia comune nell’implementazione di tale classe e che sia com-
patibile con il resto del codice. E’ necessario implementare il metodo
30 CAPITOLO 3. CHE COS’E NEKO
handle ed e possibile definire le condizioni richieste per interrompere
la simulazione implentando il metodo shouldStop.
• StatInitializer ha il compito di costruire l’architettura di NekoStat
inizializzando i layer e altri oggetti.
• StatLayer si occupa di gestire i messaggi di controllo alla fase fina-
le dell’esperimento. Come StatLogger ha due comportamenti diversi:
nella fase di simulazione, al momento dell’arrivo di un messaggio di
terminazione, attiva la procedura di estrazione dei risultati dallo Sta-
tHandler e termina la simulazione. Nella fase di esecuzione invece, una
volta che lo StatLayer del processo master ha ricevuto il messaggio
di terminazione, invia un messaggio agli StatLayer di tutti i proces-
si Slave in modo da poter iniziare la procedura di invio degli eventi
registrati. Tale procedura d’invio non avviene in blocco bensı gra-
zie al layer ListFragmenter vengono bufferizzati e inviati in maniera
frammentata.
Capitolo 4
Progettazione di NekoPDA
4.1 Motivi che portano alla creazione di
NekoPDA
NekoPDA e il nome che e stato attibuito a quell’insieme di classi, appartenen-
ti al framework Neko, destinate ad essere eseguite su qualsiasi PDA. I motivi
che hanno portato alla creazione di questo package sono dovuti al fatto che
il framework Neko, per le sue analisi e valutazioni, sia uno strumento molto
utile nella validazione di algoritmi usati nell’ambito di sistemi distribuiti.
Per validazione di un algoritmo si intende quel processo che una volta appli-
cato ci consente di essere sicuri del fatto che il nostro algoritmo si comporti
proprio come dovrebbe. Consta di un’insieme di operazioni attraverso le quali
si giudica lo scarto esistente tra, gli obiettivi definiti in sede di progettazione
e i risultati effettivamente conseguiti.
L’idea che sta alla base di tutta la fase di progettazione e quella di ipotizzare
la realizzazione di una rete PAN (Personal Area Network), che permettere
la comunicazione tra dispositivi di diverso tipo, tra PDA e PC. Una rete di
31
32 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
questo tipo puo essere utilizzata per collegare tra di loro piu PDA e un PC,
all’interno dei quali e in esecuzione qualsiasi tipo di applicazione. Supponia-
mo che un algoritmo distribuito sia eseguito sulla rete e che si voglia sapere se
il comportamento previsto dalla progettazione rispecchia l’andamento reale
della rete. Per poter fare un’analisi di questo tipo c’e bisogno di un potente
framework per la validazione di sistemi distribuiti. Come abbiamo illustrato
in precedenza, Neko effettua proprio questo tipo di valutazioni su reti in cui
vi partecipano esclusivamente Computer Desktop. Adesso verra mostrato co-
me Neko sia stato ”ripulito” e come si sia ottenuto un framework piu leggero
e adatto a device meno potenti come i PDA.
4.2 Architettura del pacchetto NekoPDA
Eseguiamo adesso un analisi di quali siano le parti da estrapolare da Neko
e progettiamo una possibile architettura del framework, affinche in futuro
possa essere eseguito anche su device con risorse limitate. La costruzione del
package NekoPDA ha come radice la classe Slave e si ramifica in tre fasi.
Come gia accennato in precedenza, e stata fatta la scelta di includere nel
progetto solo le classi che implementano la parte slave, per rendere meno
pesante il lavoro che il palmare deve svolgere. Infatti al PDA non verra mai
affidato un ruolo di master, che e sicuramente piu indicato ad un computer
desktop. Una volta delineato il primo piccolo pacchetto, per ampliare le
funzionalita, e possibile aggiungere la parte del generatore di slave chiamata
ServerFactory ed una minima parte di NekoStat, necessaria al master per
poter fare un’analisi statistica dei risultati.
4.2. ARCHITETTURA DEL PACCHETTO NEKOPDA 33
Fase prima
La classe perno di tutto il package e Slave . Questa e in attesa di con-
nessioni da parte del master, il quale inviera informazioni utili per la fase
di configurazione. Per questo motivo, strettamente necessaria all’inizio del-
le comunicazioni tra slave e master e la classe Config, utilizzata per poter
leggere le configurazioni inviate dal master. Una volta terminata la fase di
riconoscimento lo slave richiede la classe NekoInitializer che, per inizializzare
l’applicazione, necessita delle seguenti classi del pacchetto Util: Exception-
Handler, LauncherCatchingExceptions, tutto il pacchetto org.apache.java.util
e NekoLogger. Quest’ultima classe e usata per effettuare il log dei messaggi
di uno specifico sistema o di un componente dell’applicazione e tutte le appli-
cazioni Neko, sia reali che simulate, devono usarla al posto di quella fornita
da java.util.logging.logger.
In seguito all’inizializzazione dell’applicazione, viene fatto partire un thread
che esegue il metodo run di NekoCommSystem. Questa classe contiene fun-
zionalita generiche e necessita di AbstractID, classe base per gli identificatori
dei microprotocolli, e MessageTypeConst, contentente tutti i tipi di messag-
gi che si possono inviare (da NekoCommSystem e utilizzata con la variabile
SHUTDOWN). Insieme alla classe identificatrice di messaggi c’e bisogno di
un’altro insieme di metodi che provvedono ad associare il tipo di messaggio
sottoforma di intero al suo vero nome. L’insieme di queste conversioni danno
luogo alla classe MessageType.
Anche NekoMessage e tra le classi portanti del pacchetto, infatti genera i
messaggi che tutti i processi si inviano tra loro, contententi informazioni
utili, come l’indirizzo del processo mittente, del processo destinatario, la ti-
pologia di rete usata, il tipo di messaggio e il contenuto. Un messaggio Neko
34 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
puo essere inviato sia in unicast che in broadcast, basta che sia specifica-
to. NekoMessage e richesta da un gran numero di altre classi di Neko come
ProcessReceiver e ProcessSender. Entrambi sono microprotocolli, infatti ri-
chiedono ProtocolImpl, ma mentre la prima ha il compito di intercettare tutti
i messaggi entranti in un processo, la seconda intercetta tutti quelli che esco-
no da un processo e gli associa, prima dell’invio, un identificatore univoco
del mittente. Entrambi richiedono NekoMessageEvent che ha il compito di
memorizzare il messaggio come se fosse un evento. Un NekoMessageEvent
e usato dal meccanismo di logging per immagazzinare e formattare il mes-
saggio. Con il termine formattare si intende assegnare a tutti i messaggi le
stesse caratteristiche e le seguenti proprieta:
• l’intero messaggio ha questa forma: destinazione+IdProcesso
+tipoMessaggio
• tutti i messaggi utilizzano uno stesso lessico:
– il formato ASCII
– l’uso di caratteri stampabili
– ogni voce deve risiedere su una sola linea
– tutti i commenti iniziano con il simbolo #
Anche NekoSystem deve necessariamente far parte di NekoPDA perche con-
tiene generiche funzionalita che per distinguere la parte di esecuzione reale
dalla parte simulata. Infatti tra le tanti classi che la richiedono distinguiamo
NekoProcess e NekoThread. Come gia accennato in precedenza, ogni proces-
so che compone un’applicazione distribuita Neko ha associato un oggetto di
tipo NekoProcess. Esso mantiene informazioni utili come l’indirizzo di rete
del PC che ospita il processo, l’identificatore numerico associato al processo
4.2. ARCHITETTURA DEL PACCHETTO NEKOPDA 35
stesso e implementa il log dei messaggi spediti e ricevuti da un processo.
Nell’esecuzione reale, ogni processo e un host diverso e ha una composizione
di protocolli associati che implementano l’applicazione Neko. Anche la clas-
se NekoThread e necessaria per il package poiche e utilizzata per istanziare
nuovi thread che possono essere simulati o eseguiti. Ovviamente chi la usa
non ha bisogno di sapere se si tratta di un tread in esecuzione o meno, ci
pensera NekoSystem a distinguere le due parti all’occorrenza.
Tra le classi piu importanti nella gestione della rete c’e Connections che
rappresenta l’insieme delle connessioni stabilite tra i processi del sistema.
Questa leggendo le linee opportune nel file di configurazione, crea una rap-
presentazione matriciale in booleani della rete, in cui il valore true indica
che deve essere stabilita una connessione tra i due processi. La richiede una
sola classe: TCPNetwork la quale ha il compito di istanziare collegamenti
end-to-end usando il protocollo tcp.
Parallelamente a queste, ma altrettanto indispensabile c’e CommNetwork.
Grazie dal metodo Init() inizializza la rete usando la configurazione e la
classe ControlNetwork. Di questa infatti utilizza i metodi send() e receiver()
per poter scambiare informazioni di inizializzazione riguardanti la rete. Inol-
tre ha il compito di ricevere tutti i messaggi inviati dal metodo Init() degli
altri processi, facendo distinzione tra quelli appartenenti alla stessa rete o a
reti diverse. Una volta che la chiamata al metodo e terminata, viene chia-
mato startDelivering() per sapere se il messaggio puo essere consegnato
o meno.
Analizziamo adesso una serie di interfacce indispensabili al minimo funzio-
namento di Neko. Partiamo dall’interfaccia Protocol, colei che tutti i mi-
36 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
croprotocolli devono implementare per poter rispettare una serie di conven-
zioni. Essa richiama il metodo launch(), una sola volta al momento del
set-up ed e richiamata da ProtocolImpl, SenderInterface, ReceiverInterfa-
ce, Dispatcher e NetworkInitLayer. La prima e la classe base che tutti i
microprotocolli devono estendere, le successive due rappresentano l’interfac-
cia utilizzata per inviare e gestire la ricezione dei messaggi, mentre Dispat-
cher e il microprotocollo usato per inviare messaggi di tipo NekoMessage
entranti, ai microprotocolli superiori. L’oggetto Dispatcher richiama il me-
todo ReceiverInterface.deliver(NekoMessage) per ricevere il messaggio
e controlla, tramite il metodo deliver(), il tipo di messaggio, richiamando
cosı il metodo opportuno.
Tra le interfacce piu importanti si puo riconoscere NekoThreadInterface, usa-
ta da alcune classi per permettere il multithread concorrenziale e FailureDe-
tectorInterface, utilizzata dal FailureDetector. Per poterla utilizzare, bisogna
implementarla e crearne un’istanza in ogni processo. I layer FailureDetector
e Heartbeat cooperano ad implementare la funzione di failure detector (o
rilevatore di fallimenti).
Con failure detector si indica quella tecnica per rilevare fallimenti per crash
e ogni processo monitorato spedisce continuamente messaggi di tipo heartbeat
per mostrare il suo stato attivo e funzionante. Il suo funzionamento in Neko
e di questo tipo: gli Heartbeat layers, ogni secondo, inviano messaggi di tipo
heartbeat e il layer FailureDetector sospetta di un processo p ogni qual volta
che non riceve piu messaggi heartbeat entro due secondi e quindi dubita che
tale processo sia fallito. Il layer di rilevamento mantiene una lista con tutti
i processi sospettati e manda messaggi di tipo Neko, contenenti le notifiche
dei sospettati, al coordinatore, il quale provvedera a riassegnare il task al
processo fallito.
4.2. ARCHITETTURA DEL PACCHETTO NEKOPDA 37
Per quanto riguarda i thread in Neko c’e bisogno della classe WrappingNeko-
Thread. Questa serve quando il thread corrente non e un NekoThread, e quin-
di per evitare che qualche parte dell’applicazione Neko possa creare e usare
istanze di tipo java.lang.thread direttamente, invece che di neko.NekoThread.
Inoltre si aggiunge anche NekoLoggerRecord che permette di registrare il tem-
po di simulazione, di esecuzione reale, il nome del thread ceato e il processo
che l’ha creato.
Anche altre classi sono state inserite nel pacchetto NekoPDA ma sono di
utilita a queste appena descritte.
Fase seconda
La seconda fase e stata effettuata in seguito alla scelta di inserire la Server-
Factory, ovvero un meccanismo automatico di generazione degli slaves. La
ServerFactory si pone, in attesa su una porta, di una connessione da parte
del master. Quest’ultimo si connette alla ServeFactory inviandogli una ri-
chiesta di creazione di un nuovo slave, la quale sara processata dalla classe
ServerFactoryWorker.
ServerFactoryWorker, dopo aver processato la richiesta e costruito l’apposito
comando con le varie opzioni e i giusti argomenti, lancia la classe StartServer-
Main la quale si occupa di riconoscere le eventuali opzioni passate, control-
lare che siano corrette e di richiamare la classe StartServer. Questa manda
in esecuzione lo slave e dopodiche continua la sua esecuzione soddisface-
ndo le richieste avute da ServerFactory mediante le classi StartServerP2 e
StartServerP3.
38 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
Fase terza
L’ultima parte del pacchetto e rappresentato da un piccolo insieme di classi
di NekoStat, ovvero solo quella necessaria al master per poter fare un’analisi
statistica dei risultati. Prima di tutto e stato necessario inserire la classe
StatInitializer che ha il compito di preparare l’architettura NekoStat, ovvero
predispone i layer e altri oggetti utili all’utente. Questa richiede Logging-
StatHandler utile per effettuare il debugging dell’applicazione e la quale a
sua volta necessita di StatHandler. Quest’ultima classe ha il compito di ge-
stire i singoli eventi definiti per il sistema in esame. Ogni StatHandler deve
implementare il metodo handle(Event), nel quale l’utente definisce come ge-
stire i vari tipi di eventi utili per poter ricavare le giuste quantita di interesse.
Al pacchetto NekoPDA e necessario inserire anche la classe Event, contenito-
re delle informazioni sugli eventi che avvengono nel sistema distribuito. Ogni
evento e caratterizzato da un identificatore, un tempo (simulato o reale), una
descrizione e un contenuto. Legata ad Event c’e la classe EventCollector che
colleziona gli eventi per ogni processo sulla rete reale durante l’esecuzione
distribuita. Al termine di ogni applicazione NekoStat, gli EventCollector dei
singoli processi vengono inviati al processo master, il quale ha il compito di
gestire tutta la collezione per poter effettuare le analisi statistiche.
Anche StatLogger e importante per NekoPDA perche ha molti compiti sia
per la fase di simulazione che per quella di esecuzione reale. In simulazione
riceve gli eventi dei processi, richiama la funzione di gestione degli eventi e
controlla se la simulazione puo essere interrotta, mentre in esecuzione reale
si occupa, insieme ad EventCollector, della raccolta degli eventi dei singoli
processi. Questa classe e realizzata utilizzando il pattern Singleton, per
4.2. ARCHITETTURA DEL PACCHETTO NEKOPDA 39
far si che tutti i layer appartenenti allo stesso processo utilizzino lo stesso
oggetto. Inoltre, poiche il funzionamento di StatLogger e molto diverso nel
caso si tratti di una simulazione o di una esecuzione, e costruita come un’in-
terfaccia, che verra implementata poi da StatLoggerSim (per le simulazioni),
StatLoggerMaster (per il master nelle esecuzioni reali) e StatLoggerSlave (per
gli slave nelle esecuzioni reali). Poiche StatLoggerMaster e utilizzata solo se
l’ID del processo corrisponde al master, e possibile anche evitare di inserirla
nel package. Infatti, come si e gia detto, su un PDA non risiedera mai un
processo master e quindi si potrebbe eliminare tale classe e di conseguenza
anche ogni chimata derivante da StatInitializer e StatLayer. Un discorso si-
mile e riservato anche per StatLoggerSim, la quale e utilizzata solo se siamo
in ambiente simulato. E’ ovvio che le esecuzioni che ci interessano sono sola-
mente quelle reali e quindi si puo anche pensare di non inserirla in NekoPDA.
Infine per la gestione dei messaggi di controllo di NekoStat durante la fase
di terminazione dell’analisi, c’e bisogno di StatLayer, ovvero di quel layer
che raccoglie tutte le informazioni, in esecuzione reale, per il master e per lo
slave, e di ListFragmenter che permette l’invio al master dell’EventCollector
in maniera bufferizzata. Il mittente invia la lista suddivisa in frammenti, per
garantire buone prestazioni, e d’altro canto il ricevente riassembla il tutto
ricreando il messaggio.
Il package cosi creato consiste di un vero e proprio gruppo di classi risultanti
da questa approfondita cernita all’interno del pacchetto Neko. Nella figura
4.2 si mostrano, tutti i pacchetti Neko e, per far capire la consistenza del-
la selezione effettuata, si sono evideziate le classi Neko che fanno parte del
nuovo pacchetto NekoPDA. Nella prima parte della figura si mostrano tutti
pacchetti Neko, rappresentati da una o piu file di ”mattoncini” e differenzia-
ti l’uno dall’altro per nome. Ogni pacchetto al suo interno possiede tutte le
40 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
classi di cui e composto. L’ultima parte della figura indica i restanti pacchetti
di Neko che non contengono alcuna classe indispensabile per il porting di su
PDA e che quindi non sono stati utilizzati.
Inoltre per una migliore visualizzazione dei pacchetti e delle classi utilizzate
si mostra schematizzazione di figura 4.1:
Figura 4.1: I pacchetti di NekoPDA
4.2. ARCHITETTURA DEL PACCHETTO NEKOPDA 41
Figura 4.2: Le classi di Neko incluse nel package NekoPDA
42 CAPITOLO 4. PROGETTAZIONE DI NEKOPDA
Capitolo 5
PDA, Sistemi Operativi e JVM
dedicati
5.1 PDA
5.1.1 I palmari nella storia
Un Personal Digital Assistants, generalmente chiamato PDAs e un computer
con dimensioni ridotte dotato di uno schermo Touch Screen tramite il quale
si puo accedere alle varie funzionalita. Fu concepito inizialmente come una
semplice agenda elettronica e conteneva un calendario per gestire e pianificare
gli appuntamenti, una rubrica per accedere in modo rapido alle informazioni
dei contatti, un promemoria e una calcolatrice che consentiva in qualsiasi
momento di effettuare operazioni matematiche fondamentali e conversioni.
Il primo dispositivo, risalente al 1997, padre di tutti i palmari, e Newton,
della Apple. Questo e stato il primo device capace di elaborare informazio-
ni, creare documenti e in particolare fu il primo apparecchio il cui hardware
cercava di leggere e riconoscere la scrittura di un essere umano. Il program-
43
44 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
ma rivoluzionario che permetteva questa ”magia” si chiamava Graffiti e fu
una vera e propria rivoluzione che aprı le porte all’evoluzione di tutti i PDA
successivi.
Due anni dopo comparve il PALM OS, ma le prime versioni non ebbero molto
successo, in quanto non riuscivano ad essere abbastanza robusti e neppure la
portabilita aveva una leggerezza ed efficienza tale da essere competitivo. Il
2002 ha portato l’avvento dei computer portatili che si sono fatti sempre piu
piccoli, iniziando a prendere il posto dei vecchi desktop e respingendo sempre
piu l’avvento del palmare. Uno dei motivi di tale ritardo e stato proprio il
massiccio diffondersi dei pc portatili. Dopodiche, tra il 2003 e il 2004 i PDA
hanno tentato di diffondersi, attraverso uno degli apparecchi piu usato negli
ultimi anni, il cellulare. Molti palmari hanno iniziato a essere utilizzati come
cellulare e soprattutto come navigatori per auto. Tuttavia ancora una volta
non hanno avuto un grande successo poiche TOM TOM ha realizzato tutto cio
che gli utenti potessero desiderare in fatto di navigatori per auto. Nel corso
degli ultimi due anni sono stati comunque apportati numerosi miglioramenti
e ampliamenti delle funzionalita.
I palmari attualmente sono cambiati, si sono trasformati. Hanno subito
l’attacco dei mini-PC, dei portatili dall’alto e dei telefonini dal basso. Per
questo motivo hanno dovuto reinventare se stessi con lettori MP3, moduli
GSM, GPS ed altro ancora.
Adesso sono tutti dotati della capacita di collegarsi e sincronizzare dati con i
personal computer, sia con un collegamento a infrarossi che con una connes-
sione seriale/USB. Alcuni possiedono la nuova tecnologia bluetooth tramite
la quale possono collegarsi anche a dispositivi esterni come telefoni cellulari
o GPS. E possibile anche installare programmi appositamente creati al fine
di aggiungere nuove funzionalita come fogli elettronici, client di posta elet-
5.1. PDA 45
tronica, giochi, riproduttori MP3 ecc.
Gli aspetti positivi di un palmare sono quelli di poter usufruire delle sue
funzionalita in qualsiasi luogo, in quanto le dimensioni limitate e la batteria
propria lo permettono. Quindi e sempre possibile utilizzare il palmare come
navigatore satellitare, strumento di intrattenimento, Game Boy Advance o
mini-Divx player.
I PDAs tuttavia inizialmente hanno dovuto risolvere molti problemi come
la memoria limitata, i processori poco potenti, il surriscaldamento delle bat-
terie e gli schermi di dimensioni molto ridotte. Sebbene adesso tutte queste
difficolta siano state superate i palmari possiedono ancora il limite della me-
moria RAM disponibile, in quanto con il passare del tempo le applicazioni
per i palmari si fanno sempre piu complesse e piu pesanti. Per aggirare tale
problema, da principio si e fatto uso delle memory card, ma quando la ri-
chiesta di spazio su disco si e fatta piu consistente, si sono sviluppati palmari
di ultima generazione che contengono un hard disk al loro interno e la cui
memoria disponibile e maggiore di 128MB. Poiche il palmare e sempre piu
chiamato ad essere un surrogato temporaneo delle funzioni estese del PC di
casa, il concentrato di funzionalita a cui in futuro sara sempre piu difficile
rinunciare e a mano a mano piu ampio, e per questo motivo questa tecnologia
e sempre in continua evoluzione.
Parallelamente allo sviluppo dei palmari per il commercio di massa, esistono
PDA specializzati molto costosi, la cui creazione e indirizzata alla risolu-
zione di problemi specifici e destinata alla creazione di macchine dedicate per
un mercato ristretto. Ad esempio un palmare che sappia fare delle rilevazioni
di qualunque genere (del catastale, alla misurazione di polveri sottili, raccolta
dati tramite sensori, etc..) deve essere dotato di caratteristiche molto simili
46 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
ad un vero e proprio PC e di un buon software che consenta ottimizzazioni di
tempi e costi, mantenendo un alto grado di flessibilita e mobilita. In questa
tesi faremo riferimento in particolare ai palmari di ultima generazione, atti a
supportare programmi di analisi e a vivere all’interno di una rete composta
di piccoli device e PC.
5.1.2 Le caratteristiche fondamentali dei PDAs
I sistemi operativi dedicati ai palmari sono suddivisi principalmente in tre
grandi categorie: l’insieme degli adattamenti di Windows tra cui la versione
piu recente e Windows Mobile 5.0, l’insieme dell’Os Symbian piu indirizzato
al settore degli SmartPhone e i PalmOS. I piu diffusi in assoluto sono PalmOS
e Windows Mobile, chiamati anche PocketPC oppure Windows HandHeld.
In ogni caso in termini di funzionalita le due tipologie sono equivalenti e com-
prendono funzionalita di base come Agenda, Impegni, Rubrica, Blocco Note,
Calcolatrice e Posta elettronica. C’e da notare pero che Windows Mobile, a
differenza di PalmOS, e un sistema piu completo sia per quanto riguarda l’a-
spetto multimediale, molto piu evoluto, sia per il fatto che essendo prodotto
dalla Microsoft e compatibile con i principali programmi di Office.
I PDAs si differenziano, oltre che per i sistemi operativi, per la capacita
di memoria, che incide sulle prestazioni e per le caratteristiche fisiche dello
schermo come le dimensioni, i colori e la risoluzione. Dall’uscita del primo
PDA della Apple, Newton MessagePad, questo settore ha visto nel tempo
una grande crescita di funzionalita e capacita dell’hardware; da processori a
16 MHz, 128 Kbyte di Ram e schermi monocromatici si e passati alle Cpu a
400MHz, 128 Mbyte e schermi transriflettivi a 65.000 colori. Lo schermo di un
palmare attualmente occupa dal 70% all’80% della superficie e la dimensione
standard si misura in pollici e si attesta intorno ai 3.5”. La risoluzione viene
5.1. PDA 47
misurata in pixel e varia da una dimensione base di 160×160 fino a 640×480.
I PDA non dispongono di un vero e proprio disco rigido, bensı il siste-
ma operativo insieme a tutto il resto delle informazioni sono contenuti nella
memoria. Per memoria si intende una parte di sistema suddivisa in tre par-
ti: una memoria Flash Rom, utilizzata dal sistema operativo, un’altra a
disposizione dell’utente e una memoria Ram, utilizzata come appoggio dai
programmi in esecuzione.
In totale la memoria puo essere inferiore a 32MB, oppure variare da 32MB
a 63MB, da 64MB a 127MB oppure superare i 128MB. Il metodo di input
prevede l’utilizzo di uno stilo e l’immissione dei dati avviene o tramite ta-
stiera virtuale o tramite due tipi di riconoscimento di scrittura: elaborato o
manuale.
Per quanto riguarda l’autonomia invece essa varia da palmare a palmare ma
la durata media dipende dal tipo di utilizzo, dalla potenza del processore,
dalla risoluzione e dal numero di colori dello schermo.
Una volta individuate le caratteristiche fisiche dei palmari e prima di
passare a descrivere in dettaglio i componenti software analizzati, e necessario
far notare che sono moltissime le opzioni offerte dal mercato per sviluppare
software su PDA. Per questo motivo o si e costretti a programmare dopo aver
compiuto delle scelte preponderanti per un modello rispetto che per un altro,
oppure si decide di scrivere codice in modo che sia compatibile sui principali
sistemi operativi per palmari.
Nella sezione successiva verra effettuata una panoramica sui sistemi operativi
dedicati ai palamri e in particolare verra descritto il nuovo sistema operativo,
Windows Mobile 5.0. Questo SO e stato approfondito con piu attenzione
48 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
degli altri in quanto e installato sul PDA DellAxim x51v, e quindi e stato
necessario sviscerare ogni sua peculiarita al fine di comprendere a pieno le
sue possibilita e i suoi limiti.
5.2 I sistemi operativi dedicati ai palmari
5.2.1 Symbian Os
Il sistema operativo Symbian e stato progettato inizialmente per i telefoni
cellulari. Il suo sviluppo e curato dalla Symbian Ltd, una societa per la for-
nitura di software in licenza che fornisce il sistema operativo per numerosi
telefoni cellulari. Symbian OS, erede del sistema operativo EPOC, creato
dalla Psion, non e open suorce bensı il codice sorgente e fornito esclusiva-
mente dai produttori dei dispositivi mobili che lo supportano. Tuttavia la
documentazione relativa alle API e disponibile pubblicamente, dunque chiun-
que voglia sviluppare software per Symbian puo farlo.
Come altri sistemi operativi dispone di funzionalita di multithreading, mul-
titasking e protezione della memoria. Proprio sulla memoria sono stati indi-
rizzati gli sforzi dei produttori, infatti mediante tecniche specifiche gli errori
dovuti ad una cattiva gestione della memoria sono molto rari. Il funziona-
mento di Symbian e basato su eventi e la CPU e automaticamente disabilitata
quando non vi siano eventi attivi: il corretto uso di questa tecnica aiuta ad
assicurare alle batterie una durata maggiore.
Il Symbian, come gli altri sistemi operativi fornisce le procedure e i servizi
che stanno alla base del funzionamento del software applicativo. Ad esem-
pio, grazie ai protocolli di comunicazione e alle routine di gestione dei file,
qualunque software per la gesitone delle e-mail, puo interagire con un utente
attraverso il display e puo permettere il download dei messaggi nella casella
5.2. I SISTEMI OPERATIVI DEDICATI AI PALMARI 49
di posta in arrivo del telefono cellulare, tramite una rete mobile o un accesso
WiFi.
La Nokia ha adottato il Symbian come propria scelta strategica per i sistemi
operativi dedicati agli smartphone e dichiara che sono molti i vantaggi che lo
contraddistinguono. Prima di tutto possiede un’ampia scelta di applicazioni
disponibili sia per telefoni cellulari che per palmari. Permette connettivita di
tipo GSM, GPRS, CDMA, WCDMA, WiFi e Bluetooth. Le sue applicazioni
sono sviluppate in linguaggi come Java e C++.
5.2.2 Palm OS
Palm Os e uno tra i software per palmari piu diffusi al mondo ed e stato
progettato specificatamente per soddisfare le esigenze di palmari e smart-
phone. Le motivazioni di questo grande successo sono dovute al fatto che
offre i principali strumenti che tutti ricercano in un prodotto compatto ma
estremamente efficiente. E’ stato progettato principalmente per poter per-
mettere a tutti gli utenti di eseguire in modo facile e veloce le operazioni
piu comuni. I possessori di un Palm OS possono muoversi tra finestre di
dialogo, menu nidificati e barre di scorrimento in modo molto semplice. E’
possibile controllare gli appuntamenti del giorno premendo un solo pulsante,
inserire una nuova riunione con un semplice tocco e inviare biglietti da visita
eseguendo un paio di semplicissime azioni. Palm OS offre una scelta tra mi-
gliaia di programmi disponibili online, che includono database e programmi
di elaborazione testi, mappe e traduttori automatici, libri elettronici e giochi.
Le versioni attualmente in commercio sono Palm OS 5, Palm OS Garnet e
Palm OS Cobalt 6.1. Palm OS 5 e disponibile da diversi anni, mentre Palm
OS Garnet e una versione ottimizzata piu recente che fornisce alcune fun-
zionalita aggiuntive. Essa include il supporto standard di un’ampia gamma
50 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
di risoluzioni dello schermo e di numerose tecnologie di connessione wireless
tra cui Bluetooth. Fornisce inoltre funzionalita multimediali avanzate, una
suite di efficaci funzioni di sicurezza e il supporto di un gran numero di lin-
gue. Palm OS Cobalt 6.1 invece e il sistema operativo piu innovativo della
serie. E’ progettato sin dall’inizio per sviluppare nuove classi di smartpho-
ne e di altri dispositivi wireless, preservando allo stesso tempo la semplicita
d’uso molto richiesta dagli utenti. Gli aspetti che principalmete lo differen-
ziano dalle altre versioni sono il fatto che possiede un’architettura scalabile
e modulare, che e completamente multithreading e multitasking, che la sua
architettura di comunicazione e basata su STREAMS e che presenta un set
esteso di tool di sviluppo per la creazione di applicazioni ARM native in am-
biente PACE (Palm Application Compatibility Environment) per garantire
la compatibilita a ritroso con le versioni precedenti di Palm OS.
5.2.3 Linux
Grazie alla sua flessibilita, alla disponibilita del codice sorgente e al suo
basso costo, diversi produttori hanno inserito Linux nei loro handheld. Se
da un lato Windows e stato ”smagrito” per adattarsi ai palmari, creando
versioni (come Windows CE), che non sono esattamente Windows ma una
sua versione riveduta, corretta e soprattutto ridotta, dall’altro lato per Linux
non e stato cosı. Linux non ha una versione ridotta o limitata, ma e stato
installato sui alcuni palmari nella versione standard 2.4.x, rimanendo cosı
compatibile con la maggior parte dei suoi programmi per le versioni per
Server e Desktop.
Se i programmi per Windows non girano sulle sue versioni ridotte, ma devono
per lo piu essere adattati o riscritti ad hoc per essere eseguiti, in Linux,
memoria permettendo, tutti i programmi per la versione standard possono
5.2. I SISTEMI OPERATIVI DEDICATI AI PALMARI 51
essere ricompilati e fatti girare su un palmare. Questo beneficio e legato ad
una serie di fattori. Prima di tutto perche Linux richiede da sempre meno
risorse di altri sistemi operativi per girare. Pensiamo che un palmare oggi
puo addirittura arrivare a 128 Kbyte di Ram e che gia anni fa Linux veniva
installato su computer con 4 Mb di Ram.
Inoltre il software Linux e da sempre aperto, fornito in sorgente, e quindi
”abituato” ad adattarsi agli ambienti piu disparati. Non dimentichiamo che
quasi tutto il software Linux in realta e generico software Unix, portabile,
che gira anche su altri sistemi Unix come Solaris o FreeBSD, e molto spesso
compila senza problemi pure in un ambiente ostile come Windows NT. Di
conseguenza, utilizzare Linux come sistema operativo per dispositivi embed-
ded non e assolutamente una cattiva idea, anzi offre l’opportunita di portare,
con pochi sforzi, moltissimi tipi di programmi, gratuiti e ad alto livello, in
un palmare.
Diversi produttori hanno fatto utilizzo di Linux, con differenti risultati. Uno
tra i piu importanti successi e stato raggiunto dalla Sharp, che ha lanciato
con successo sul mercato Zaurus SL-5500, un palmare con Linux, Java e molti
programmi.
5.2.4 Windows Mobile 5.0
Windows Mobile 5.0, in fase di evoluzione chiamato Windows Mobile 2005, e
uno degli ultimi sistemi operativi ridotti basati sull’ultima versione di Win-
dows CE (Windows CE 5.0) e apporta un numero cospicuo di funzionalita,
nuove API (Application Programming Interface) e molto altro ancora.
Creato per operare su piccoli dispositivi possiede un’interfaccia molto simile
a quella di Windows e i predecessori Microsoft piu recenti di questo sistema
sono stati Windows Mobile 2003 rilasciato in tre versioni distinte e Windows
52 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Mobile 2003 SE(Second Edition). Le tre versioni di cui si e appena accen-
nato sono, rispettivamente in ordine di creazione, Windows Mobile 2003 per
Pocket PC, Windows Mobile 2003 per Pocket PC Phone Edition simile alla
precedente ma progettata esclusivamente per Pocket PC dotati di funziona-
lita di telefono cellulare e infine Windows Mobile 2003 per Smartphone che,
pur avendo molte somiglianze con i Pocket PC, e una piattaforma diversa,
che richiede programmi applicativi in modo specifico. Quest’ultima versio-
ne infatti ha le peculiarita di non supportare l’uso di touch screen, di avere
una risoluzione dello schermo minore, di richiedere sempre la presenza di una
classica tastiera telefonica e l’utilizzo di comandi disposti in modo da poter
essere usati con una mano sola.
Per quanto riguardano invece le novita che sono state introdotte successiva-
mente con l’arrivo di Windows Mobile 2003 SE(Second Edition) si parla della
creazione di schermi impostabili in modo portrait (verticale) e landscape
(orizzontale), che non era disponibile per la versione Smartphone. Inoltre vi
e stato aggiunto l’accesso Wi-Fi in modalita protetta e il programma PIE
(Pocket Internet Explorer), con l’aggiunta di poter visualizzare il testo delle
pagine su una colonna e facilitare cosı la lettura e l’operazione di scroll ver-
ticale.
Windows Mobile 2005 nasce dall’evoluzione dei sistemi operativi sopra citati
ed e stata sviluppata seguendo tre scopi:
1. Migliorare la produttivita
2. Migliorare la multimedialita integrata
3. Rendere possibile la capacita di personalizzare e customizzare da parte
degli utenti e degli operatori.
5.2. I SISTEMI OPERATIVI DEDICATI AI PALMARI 53
Le novita introdotte con questa nuova versione riguardano i seguenti
ambiti:
• Nuove tecnologie
• Supporto di rete
• Semplicita di utilizzo
Tramite Windows Mobile 5.0, i palmari adesso, possiedono la capacita
di leggere tastiere QWERTY, supportare funzioni ”push-to-talk”, i servizi
di videochiamata, videoconferenza e nel caso in cui la batteria si esaurisce i
dati verranno registati in memoria come accade per i cellulari. E’ disponibi-
le una versione particolare del classico Windows Media Player, denominata
Media Player 10 Mobile, che consente agli utenti di accedere a un repertorio
molto vasto di contenuti digitali protetti, che e in grado di sincronizzare in
automatico musica, immagini e registrazioni TV create con il Media Center
e rendendo cosı tutti i dispositivi basati su questa nuova versione in grado
di competere con gli IPod. Sono inclusi miglioramenti anche alla suite Po-
cket Office con nuove funzionalita per le versioni mobile di Word e Excel e
la comparsa di una versione leggera di PowerPoint, PowerPoint Mobile, che
permette a coloro che vogliono farlo di visualizzare le proprie presentazioni
anche in viaggio.
La sicurezza e un altro punto fondamentale che ha visto dei miglioramenti
con la creazione della nuova versione del sistema operativo mobile. I recenti
allarmi di virus in grado di colpire tali dispositivi hanno imposto la creazione
di nuove misure di controllo e l’accesso a reti esterne tramite Bluetooth e
Wi-Fi ha evidenziato il bisogno di una protezione piu avanzata e controlla-
ta nel tempo. Quindi in aggiunta alle caratteristiche di sicurezza di base,
54 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
quali l’autorizzazione Bluetooth e la crittografia end-to-end su rete provata
virtuale, e stato sottoposto a un testing approfondito secondo i criteri del
”threat-modelling” soddisfacendo i requisiti richesti dal programma Micro-
soft Trustworthy Computing.
Al pari degli attuali dispositivi Smartphone sono presenti anche le Soft keys,
ovvero dei ”tasti” usati per scegliere le opzioni dal menu sullo schermo. So-
litamente cliccando su una Soft key viene attivata la funzione descritta nella
parte corrispondente del display. Queste hanno lo scopo di ottimizzare e ve-
locizzare l’utilizzo delle applicazioni con la modalita di navigazione tramite
tastiera senza utilizzare il pennino. Inoltre i vari produttori possono perso-
nalizzare, tramite l’aggiunta di codice, l’uso di tali Soft keys.
E’ disponibile anche la versione 4.0 di ActiveSync, tool che permette la sin-
cronizzazione tra dispositivi portatili e notebook usando Bluetooth o cavo
USB.
John Jackson, capo analista dello Yankee Groups, precisa alcuni detta-
gli sulle nuove caratteristiche del prodotto: ‘I miglioramenti apportati nella
nuova versione di Windows Mobile - spiega Jackson - consentono agli ope-
ratori di reti wireless e ai produttori di dispositivi mobili di fornire prodotti
e servizi personalizzati e differenziati, rispondendo al contempo all’esigenza
espressa dal mercato di soluzioni affidabili, scalabili e sicure’.
5.3 Alcune parole riguado DellAxim x51v
Il device utilizzato per testare il pacchetto NekoPDA e un palmare di ultima
generazione fornito dall’Universita degli Studi di Firenze. Si tratta di un
5.3. ALCUNE PAROLE RIGUADO DELLAXIM X51V 55
DellAxim x51v con processore Intel PXA270 di velocita 624MHz, una RAM
di 64MB, una ROM la cui verisione e A01 e la cui capacita e di 256MB.
Vi risiede un sistema operativo Windows Mobile v5.0, ed e dotato di una
porta per dispositivi GPS. Come ormai tutti i piccoli dispositivi portatili,
anche il DellAxim x51v possiede la tecnologia bluetooth e infrarossi e come
un Personal Computer qualunque ha integrati in se una scheda di rete LAN
e una Wireless WLAN. E possibile creare connessioni modem, Ethetnet e
VPN, dove per VPN si intende una rete privata virtuale creata utilizzando
cavi pubblici per connettere i nodi.
Per quanto riguarda la sincronizzazione l’Axim utilizza Microsoft Active Sync
4.0, grazie al quale e possibile trasferire file e dati tra il palmare e il computer,
caricare driver e programmi. Per quanto riguarda la semplice sincronizza-
zione Active Sync confronta i dati del palmare con quelli sul computer ed
entrambi vengono aggiornati con le informazioni piu recenti. Con questa
applicazione e possibile mantenere aggiornati i dati di Microsoft Pocket Ou-
tlook sincronizzando il palmare con i dati di Microsoft Outlook sul computer
e sincronizzare tutti i file Microsoft Word e Excel. Grazie a Microsoft Active
Sync e stato possibile copiare i file dal palmare al computer e viceversa, con-
trollare quando avviene la sincronizzazione (se mantenere la sincronizzazione
continua o attivarla solo su comando) oppure selezionare il tipo e la quantita
dei dati che si vuole sincronizzare.
I creatori di DellAxim x51v hanno pensato anche alla sicurezza e a questo
proposito risulta installato il programma Odyssey Client. Questa e un’appli-
cazione che controlla l’accesso e la protezione della LAN senza fili(WLAN),
infatti ne controlla l’autenticazione e la connessione assicurandosi che solo
56 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
gli utenti autorizzati possano accedervi.
5.4 La Java Virtual Machine
Per far funzionare la maggior parte delle applicazioni Java e inevitabile dover
installare, a prescindere dal dispositivo di cui facciamo uso, una Java Virtual
Machine (JVM). Una JVM a una macchina che esegue file in bytecode deri-
vati dalla compilazione dei sorgenti Java. Non e altro che una specifica creata
dalla Sun Microsystems e qualsiasi sistema che si comporti in modo coerente
con questa specifica si puo considerare un’implementazione particolare della
JVM. Per questo sono state create versioni sia libere che commerciali per
quasi tutti i sistemi operativi moderni. Esistono anche implementazioni che
operano in contesti hardware/software particolari come telefoni cellulari o
nel nostro caso su palmari.
L’architettura della macchina virtuale Java puo essere cosı suddivisa:
1. Un set di istruzioni per i bytecode
2. Un gruppo di registri
3. Uno stack
4. Un’area di heap su cui opera la routine di garbage collection
5. Un’area per la memorizzazione dei metodi
Il codice sorgente viene compilato in bytecode e memorizzato in file con
estensione .class. Per compilare tale codice si usa una specie di compila-
tore che traduce il codice sorgente in bytecode e prende il nome di Javac. Il
codice, a causa del formato, non puo essere eseguito direttamente ma deve
essere interpretato su ciascun computer. Per questo motivo il si dice che il
5.4. LA JAVA VIRTUAL MACHINE 57
codice Java e estremamente portabile e flessibile.
I registri della JVM sono molto simili ai registri che si trovano in un com-
puter reale, essi contengono lo stato in cui si trova la macchina durante le
operazioni, influiscono sul funzionamento di quest’ultima e vengono aggior-
nati in seguito all’esecuzione del bytecode.
Lo stack e alla base del funzionamento della JVM, infatti viene utilizzato per
passare i parametri ai bytecode e ai metodi, e per ricevere i risultati derivati
da questi ultimi. Lo stak e composto da frame e ognuno possiede tre aree
(che potrebbero essere anche vuote):
• Le variabili locali per la chiamata al metodo
• L’ambiente di esecuzione del metodo stesso
• Lo stack degli operandi
L’area di heap e quella parte della memoria nella quale vengono allocati gli
oggetti, o istanze, appena create. Grazie a Java, la quale rimuove automa-
ticamente dallo heap gli oggetti non piu utilizzati, tramite un meccanismo
di garbage collection, i programmatori non devono e non possono liberare
la memoria allocata per un oggetto quando quest’ultimo ha esaurito la sua
funzione.
Infine l’area di memorizzazione dei metodi e quella zona che contiene le
tabelle dei simboli necessari per il link dinamico, informazioni di debug ag-
giuntive, ambienti di sviluppo da associare all’implementazione di qualsiasi
metodo e i bytecode di Java che implementano tutti i metodi presenti nel
sistema.
Fino a pochi anni fa la piattaforma Java richiedeva un spazio abbastanza
abbastanza elevato sia dal punto di vista delle risorse computazionali che di
58 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
occupazione di memoria. Attualmente pero sono stati fatti molti passi avanti
nell’implementazione e la Sun, per esempio, ha creato nuove specifiche per
Virtual Machine adatte a dispositivi embedded come telefoni cellulari, pal-
mari ecc.. Tali JVM vengono chiamate KVM, dove la ”K” sta per kilobyte,
ed indica che l’occupazione di memoria e dell’ordine di centinaia di KB. Tutte
queste innovazioni hanno portato allo sviluppo di molte macchine per am-
bienti che presentano risorse limitate come palmari e piccoli dispositivi.
Le ultime versioni di JVM e quelle progettate con lo scopo di girare su pic-
coli dispositivi possiedono efficaci metodi per ridurre il consumo di CPU, tra
i quali il metodo HotSpot che permette la precompilazione del bytecode al
fine di avere alcune parti gia tradotte in linguaggio macchina e pronte per
essere eseguite quando necessario. In questo modo lo sforzo computazionale
per i dispositivi che le supportano si e alleggerito e tutto cio ha permesso
la diffusione, non solo delle nuove versioni di JVM, ma anche dei palmari e
SmartPhone con tale supporto.
A questo punto e stato possibile fare una netta distinzione per le Java Virtual
Machine dedicate a piccoli dispositivi. Esistono infatti due tipologie che dif-
feriscono l’una dall’altra per la piattaforma su cui si basano: la piattaforma
Java 2 Standard Edition (J2SE) oppure la Java 2 Micro Edition (J2ME).
La maggior parte di queste macchine sono state create per i primi dispositivi
embedded e quindi sono verisioni molto ridotte e si basano sulla J2ME. Tut-
tavia con il migliorarsi delle tecnologie stanno nascendo molte Java Virtual
Machine che, pur basandosi su una piattaforma piu completa come la J2SE,
sono adatte a device come palmari. Attualmente purtroppo esistono ancora
molti problemi di incompatibilita tra le macchine virtuali e i piccoli device
5.4. LA JAVA VIRTUAL MACHINE 59
causati principalmente dal rapido sviluppo di queste nuove tecnologie e dalla
scarsa documentazione al riguardo.
Introduciamo adesso una panoramica su come e stata effettuata la ricerca
di macchine virtuali Java compatibili con il nostro palmare DellAxim x51v
andando in particolare a mostrare tutte le JVM testate che si basano sulla
piattaforma J2ME e sulla J2SE.
La Java 2 Micro Edition e una piattaforma dedicata ad apparecchi
con risorse limitate e a questo scopo la Sun, a differenza delle versioni J2SE
o della J2EE, ha fornito solo poche implementazioni binarie gratuite. E’ co-
stituita da configurazioni, profili e pacchetti opzionali.
La configurazione e una specifica che riguarda la virtual machine e un in-
sieme di librerie che forniscono le API. Attualmente ne esistono ben due:
la CDLC (Connected Limited Device Configuration) e la CDC (Connected
Device Configuration).
I profili complementano la configurazione aggiungendo specifiche API per
generare un ambiente runtime completo per applicazioni di una specifica
categoria di dispositivi. I pacchetti opzionali, come si capisce dal nome, e-
stendono la piattaforma J2ME aggiungendo funzionalita non disponibili nella
versione standard.
Le Java Virtual Machine piu diffuse per dispositivi embedded che si basano
sulla J2ME sono: Jeode, CrEme, Ewe, SuperWaba. Queste possono sud-
dividersi ulteriormente in macchine che offrono un ambiente Java-compliant
oppure un ambiente Java-based. Ovvero nel primo caso ci riferiamo ad un
60 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
ambiente conforme allo standard Java della Sun, mentre nel secondo ci riferia-
mo ad un ambiente il cui linguaggio ha una sintassi Java ma le cui API sono
completamente ridefinite e potenzialmente incompatibili con le API standard
di Java. In seguito si propone l’analisi piu approfondita di Jeode e CrEme,
come Java-compliant, e di SuperWaba e Ewe, come Java-based. Iniziamo cosı
col descrivere la piattaforma Jeode.
5.4.1 Jeode
La piattaforma Jeode e prodotta dalla Insigna. La prima versione conforme
alle specifiche della Sun era stata creata solo e soltanto per i sistemi basati
su WindowsCE. Attualmente invece la Jeode PDA Edition, certificata dalla
specifica Personal Java 1.2 della Sun, fornisce un ambiente di sviluppo e
alcuni tool che aiutano il programmatore nell’implementazione e nella confi-
gurazione delle proprie applicazioni.
Compatibilita
La Jeode runtime e disponibile per molti processori come x68, MIPS, ARM,
Hitachi e PowerPC ed e supportata dai sistemi operativi WindowsCE, Win-
dowsNT Embedded, Itron, PocketPC, Linux e VxWorks. Al fine permettere
il caricamento e l’esecuzione delle applet Java e stata integrata anche nei
browser per PocketPC, WindowsCE e WindowsNT Embedded.
Peculiarita
Le caratteristiche fondamentali che la differenziano dalle altre piattaforme
riguardano la macchina virtuale che ha il nome di Jeode Embedded Virtual
5.4. LA JAVA VIRTUAL MACHINE 61
Machine (EVM). La EVM grazie ad una particolare tecnica di generazione
del codice nativo, ad un’implementazione concorrente della garbage collec-
tion e all’implementazione completa dei thread, ottimizza le prestazioni delle
applicazioni. Inoltre implementa una tecnologia chiamata Adaptive Dyna-
mic Compilation(ADC) che permette di compilare dinamicamente il codice
ritenuto piu critico per i programmi in esecuzione. L’ADC prende l’idea dal-
la compilazione Just In Time (JIT), ma differisce da essa in quanto richiede
meno memoria e non fa uso di memoria virtuale. Per le parti di codice non
critiche la traduzione e realizzata mediante interpretazione e dopodiche la
macchina virtuale determina i segmenti di codice che occorrono piu frequen-
temente, li compila e li memorizza in un buffer di memoria.
Tra le caratteristiche piu utili di Jeode, ai fini di un possibile uso di Neko
sul device, c’e il fatto che, secondo le specifiche supporta completamente i
thread, le eccezioni e i tipi di dati double e long. Inoltre per il protocollo
Input/Output si avvale di TCP/IP e UDP, e supporta anche socket API.
Usabilita
Affinche un applicazione possa essere eseguita da una Virtual Machine Jeode
e necessario come per ogni piattaforma Java disporre di un ambiente di svi-
luppo come la JDK ovvero un vero e proprio corredo di sviluppo Java. Una
volta creato un file contenente il codice sorgente che utilizza solo e soltanto
le API messe a disposizione dall’ambiente, questo viene compilato attraverso
il compilatore e viene creato un link per l’esecuzione dell’applicazione sulla
macchina virtuale. L’ultimo passo e quello di installare l’archivio ”jar” creato
dalla compilazione sul palmare e a questo punto l’applicazione puo eseguire
i suoi compiti.
Infine le librerie che Jeode utilizza e che costituiscono le API sono quelle
62 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
definite nella specifica Personal Java 1.2. Tra le piu usate si trovano la ja-
va.lang, la java.util, la java.io, la java.net, la java.util.zip per la compressione
e la decomposizione dei dati, la java.lang.reflect, la java.math, la java.text
che consente la conversione di numeri, data e ora, la java.security per la crit-
tazione e la computazione di firme digitali e la java.awt (Abstract Windows
Toolkit).
Le API di Jeode
Le librerie utilizzate dalla piattaforma, costituenti le API, sono quelle defi-
nite nella specifica Personal Java 1.2. Nella tabella che segue sono elencate
quelle piu usate e quindi piu importanti.
Le prove fatte
Sono state effettuate alcune prove al fine di poter utilizzare la JVM
JeodeEsmertec 1.0 sul DellAxim x51v ma tutte hanno avuto esito negativo,
in quanto si presenta un errore di incompatibilita di versione. Per questo mo-
tivo non sono state possibili altre prove in quanto il probelma si e presentato
troppo a monte.
5.4. LA JAVA VIRTUAL MACHINE 63
java.lang Fornisce le classi core del linguaggio Java
java.util Contiene classi di utilita.
java.io Classi base per l’I/O.
java.net Fornisce un’infrastruttura flessibile
per il networking.
java.util.zip Classi per la compressione e
la decomposizione dei dati.
java.lang.reflect Consente ai programmi Java di ispezionare
e manipolare oggetti a runtime.
java.math Fornisce i tipi long, float e double.
java.text Consente la conversione di numeri, data e ora.
java.rmi Remote Method Invocation.
java.security Contiene le classi per la crittazione e
la computazione di firme digitali.
java.sql Fornisce le classi per la gestione delle
interrogazioni ai database.
java.applet Supporto per l’implementazione delle applet Java.
java.awt Abstract Windows Toolkit.
5.4.2 CrEme
La piattaforma CrEme, prodotta dalla NSICom, possiede una macchina vir-
tuale Java sviluppata per i sistemi operativi real-time. Il runtime di CrEme e
basato sulla J2ME con configurazione CDC e tra i profili aggiuntivi possiede
il Foundation Profile e il Personal Profile.
Proprio come Jeode, CrEme fornisce un vero e proprio ambiente di sviluppo
fornendo in aggiunta alla macchina virtuale un insieme di tool che aiutano il
programmatore durante lo sviluppo del proprio software applicativo.
64 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Compatibilita
CrEme e compatibile con vari tipi di processore tra cui x86, MIPS, ARM,
SH3, XSCALE e PowerPC e con i sistemi operativi WindowsCE, PocketPC
e WindowsCE.net.
Peculiarita
Gli aspetti che caratterizzano la Java Virtual Machine CrEme si riferiscono
alla tecnica di generazione del codice nativo basata sulla tecnologia Just In
Time, all’implementazione asincrona della garbage collection e all’implemen-
tazione dei thread secondo il modello chiamato blue threads.
Innanzi tutto e doveroso precisare che un compilatore Just In Time permet-
te un tipo di compilazione particolare, conosciuta come traduzione dinamica
con la quale e possibile aumentare le performance dei sistemi di programma-
zione che, come Java, traducono il bytecode nel codice nativo in fase di
run-time. Una macchina virtuale che usa questa tecnologia ha incorporato
in se un JIT compiler, cioe un compilatore interno che al momento del lan-
cio traduce al volo il programma bytecode in linguaggio macchina. Grazie
a questo sistema CreMe puo ridurre la compilazione alle porzioni di codice
piu rilevanti all’interno dei metodi e se pur aggiunge circa 100-200 KB di
memoria comporta comunque un significativo aumento delle prestazioni.
La gestione dei thread prevede l’incapsulamento di tutti i thread Java nella
Virtual Machine. Questo significa che non esiste piu una corrispondanza tra
i thread del sistema operativo e i thread Java, per cui la gestione e la sche-
dulazione di quest’ultimi e a carico della macchina virtuale. In piu CreMe
schedulando senza prelazione e usando il polling, ovvero interrogando perio-
dicamente un timer, conferisce alla virtual machine la caratteistica di essere
piu compatta e piu semplice in quanto tutto e frazionato secondo istanti di
5.4. LA JAVA VIRTUAL MACHINE 65
tempo determinati; per questo motivo non sono stati necessari meccanismi
di protezione del codice.
Usabilita
I passi al fine di installare e far funzionare un’applicazione Java utilizzando
come virtual machine CreMe sono identici a quelli gia mostrati per Jeode.
Anche le librerie sono tutte quelle di cui fa anche uso Jeode, e quindi so-
no conformi alla specifica definita dalla Personal Java 1.2, con l’eccezione
dell’aggiunta del pacchetto opzionale javax.swing.
Le prove effettuate
Le semplici istruzioni di installazione richieste sono state eseguite alla lettera,
ma la JVM sembra proprio che non sia compatibile con il palmare a dispo-
sizione. L’errore che appare a video al momento in cui si tenta di installare
CrEme e CrE-ME411 ARMCE50 PPC non e un’applicazione Pocket PC
valida. Consultando numerosi forum, uno dei quali http://usga.rulesguide
.com/support.shtml, e risultato che, anche dalle prove di altri utenti, ta-
le versione di CrEme non e compatibile proprio con il modello a nostra
disposizione(DellAxim x51v).
5.4.3 SuperWaba
Rispetto alle precedenti Java Virtual Machine e una piattaforma open-source
che puo funzionare sia con PalmOS che con PocketPC. Il nome deriva dal
fatto che si tratta di una versione ampliata dell’originario ”Waba” creato
dalla WabaSoft che ha iniziato il progetto. Una volta che Waba fu rilasciato
66 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
al pubblico sotto licenza, il progetto fu proseguito da un gruppo di pro-
grammatori brasiliani che hanno dato origine a SuperWaba. L’idea di questa
piattaforma e quella di realizzare una virtual machine ridotta rispetto alla
originale Java Virtual Machine. Originariamente e nata soltanto per picco-
le applicazioni come cellulari, poi si e sviluppata dirigendosi sempre piu al
mercato dei PDAs.
SuperWaba definisce un linguaggio, una macchina virtuale, un formato per i
file class e un insieme di classi base. La sintassi del linguaggio e di tipo Java
ma sfortunatamente le API di cui fa uso non hanno alcuna relazione con le
standard di Java, anzi non implementa alcuna delle specifiche della Personal
Java 1.2. Tutto cio puo sembrare un freno alla diffusione di SuperWaba, ma
va anche tenuto conto che anche le API di J2ME derivano da un processo
di riduzione delle API standard di Java. Inoltre e inevitabile una qualsiasi
riduzione a causa delle caratteristiche limitate dei piccoli dispositivi, sarebbe
impensabile usufruire JVM dedicate a computer desktop per PDA. Tuttavia
sono molte le ragioni per cui SuperWaba ha una grande diffusione, a parti-
re dal fatto che la piattaforma e stata rilasciata con licenza GNU e quindi
permette di sviluppare applicazioni per fini commerciali.
Compatibilita
SuperWaba ha aderito al concetto slogan della Sun ”write once, run
anywhere” (scrivi una volta ed esegui dovunque), infatti tale piattaforma e
stata concepita per poter essere usata su dispositivi basati su PalmOS, su
quelli basati su WindowsCE, su emulatori di computer desktop e sui web
browser grazie alle applet.
Tuttavia pur essendo compatibile con moltissimi tipi di palmare come anche il
DellAxim x5, in seguito a numerosi tentativi, si e riscontrato che non lo e per
5.4. LA JAVA VIRTUAL MACHINE 67
il DellAxim x51v. Ovviamente gli sforzi fatti per rendere questa piattaforma
il piu portabile possibile sono stati grandi ma essendo un settore in continuo
sviluppo e quasi impossibile poterla rendere universalmente compatibile.
Peculiarita
La caratteristica piu rilevante nei confronti delle altre Java Virtual Machine
riguarda l’implementazione semplificata dei thread. Tali thread non hanno
prelazione, non sono concorrenti e prevedono un solo metodo run piu semplice
e veloce che viene invocato tutte le volte che il sistema e in un stato di Idle.
A questo proposito run, per essere il piu semplice e veloce possibile, non
prevede piu al suo interno un ciclo infinito.
Usabilita
Per poter avviare un’applicazione tramite SuperWaba e necessario predispor-
re di un ambiente di sviluppo Java (JDK) installato, tramite il quale, da file
.java contenenti del codice, permette la creazione dei rispettivi file .class.
Una volta presente la piattaforma si puo installare il kit gratuitamente scari-
cato dal sito http://www.superwaba.com.br contenente l’installer, un’ampia
documentazione riguardante le API messe a disposizione dall’ambiente e la
licenza d’uso.
Una volta ottenuto il codice java dell’applicazione che si desidera eseguire, si
procede alla compilazione e all’esecuzione del programma Warp fornito nel
kit. Prima di tutto bisogna notare che il codice si basa su delle API specifiche
fornite esclusivamente dall’ambiente e archiviate nel file ”SuperWaba.pdb”.
Una volta eseguita la compilazione si genera un file .pdb rappresentante un
archivio, che e anche il file vero e proprio da installare sul palmare.
68 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Per finire, al fine di facilitare il testing della applicazione e il processo di
realizzazione, e anche possibile installare un emulatore sul proprio computer.
Le API di SuperWaba
Le API base sono fornite dall’ambiente SuperWaba sono archiviate in
”SuperWaba.pdb” e sotto sono riportate le piu importanti.
java.lang Fornisce alcune delle classi
del pacchetto originale
java.lang e di queste
possiede solo un sottoinsieme dei metodi.
waba.fx Contiene classi per i fonts,
classi goometriche e classi per la
gestione delle immagini e dei suoni.
waba.io Classi base per l’I/O.
waba.sys Contiene le classi che si interfacciano con le
caratteristiche del Sistema Operativo sottostante
e le classi per la conversione degli oggetti.
waba.ui Rappresenta uno dei package piu importanti,
contiene tutti gli oggetti e i controlli per
la creazione delle interfacce utente.
waba.util Classi di utilita per la gestione delle date
e la generazione dei numeri casuali.
Contiene inoltre gli oggetti per le strutture di dati.
Nel caso in cui ci fosse bisogno di usare classi che non sono contenute nei
package di default, e necessario installare dei package di estensione corri-
spondenti alle classi utilizzare.
5.4. LA JAVA VIRTUAL MACHINE 69
Le prove effettuate
Le prove eseguite anche in questo caso hanno dato esito negativo. L’installa-
zione del programma in questo caso va buon fine e la versione di SuperWaba
5.61 per Pocket PC al momento dell’avvio mostra una schermata azzurra
di benvenuto e avverte che tale Virtual Machine e installata e pronta per
lavorare. Tuttavia non permette di effettuare alcuna azione di esecuzione file
come dovrebbe, per questo motivo non e compatibile con DellAxim x51v.
5.4.4 Ewe
Ewe come SuperWaba e una piattaforma open-source che e riconosciuta come
compatibile con una vasta gamma di dispositivi palmari e non. Essa propo-
ne un pacchetto contenente una virtual machine interpretata e un insieme
di classi. Il linguaggio che essa definisce ha una sintassi Java ma la virtual
machine non usa le librerie standard, bensı delle proprie librerie. La sostan-
ziale differenza che contraddistingue Ewe da SuperWaba sta nel fatto che,
pur non definendo librerie conformi alle specifiche standard Java, Ewe ha
focalizzato l’attenzione sul riutilizzo del codice. In particolare ha pensato al
processo di migrazione delle applicazioni Java in applicazioni Ewe ed infatti
per convertire un programma Java in uno Ewe, spesso e sufficiente sostituire
i package Java con i package Ewe e aggiungere o modificare poche linee del
codice dell’applicazione.
Compatibilita
Sono diverse le categorie dei sistemi che teoricamente sono compatibili per
la piattaforma Ewe tra cui i dispositivi i PocketPC (fino a PocketPC2003),
gli MS SmartPhone, i Casio BE-300, gli HandHeldPC Pro e tutti i Linux
70 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Desktop e Windows Desktop. Tuttavia la piattaforma e in via di sviluppo
e la compatibilita si sta espandendo a una vasta gamma sempre piu ampia
di device. Attualmente non abbiamo alcuna notizia sulla compatibilita con
Windows Mobile 2005.
Peculiarita
Gli aspetti implementativi piu caratteristici riguardano sempre l’implemen-
tazione dei thread che in questo caso non consentono prelazione e non suppor-
tano alcun tipo di concorrenza. Anche se il sistema operativo sottostante la
virtual machine supporta il multithreading, il runtime consente l’esecuzione
di uno ed un solo thread per volta.
Usabilita
E’ necessario prima di tutto un compilatore Java, che utilizzando le librerie
standard, genera bytecode. Dopodiche si installa sul proprio computer desk-
top la Ewe virtual machine, reperibile dal sito ufficiale http://www.ewesoft.com,
che ha lo scopo di eseguire un’applicazione Jewel.ewe e quindi produrre un
file eseguibile. Questo file rappresenta l’archivio delle classi dell’utente.
I passi che portano all’installazione di questa virtual machine sono i seguenti:
1. Esecuzione del Launcher, in grado di creare collegamenti alle applica-
zioni e di mostrarli su di un pannello.
2. Una volta che si e in possesso del codice Java sorgente, rispettoso delle
API messe a disposizione dall’ambiente, si puo installare la macchina
virtuale sul proprio computer desktop. Essa avra il compito di eseguire
l’applicazione Jewel.exe che produce i file eseguibili.
5.4. LA JAVA VIRTUAL MACHINE 71
3. Dopodiche si puo effettuare la compilazione del file sorgente attraverso
un compilatore Java, generando i file eseguibili destinati al palmare.
4. Dopo aver creato l’eseguibile, che e un file .ewe, e possibile installarlo
sul PDA ed eseguirlo cliccando semplicemente su di esso.
Le prove fatte
La versione piu recente, e quindi piu facilemente compatibile, e
Ewe-PocketPC2003.arm.CAB. Per installarla basta disporre di un collega-
mento activeSync e mandare in esecuzione, da postazione fissa, il file
Ewe-PocketPC-v1.30.zip. Il PDA risponde positivamente caricando cor-
rettamente l’applicazione nel dispositivo ma avverte allo stesso tempo che
tuttavia potrebbe non essere visualizzato correttamente in quanto progettato
per una versione precedente del software Windows.
Le API di Ewe
Le API base sono fornite dall’ambiente Ewe e le piu importanti sono sono
riportate qui sotto.
72 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
ewe.data Fornisce alcune delle classi per il
trattamento dei dati.
ewe.database Fornisce un’implementazione indipendente
dal dispositivo
di un database.
ewe.io Fornisce le librerie di I/O (molte classi si
rispecchiano nella java.io).
ewe.math Fornisce il supporto per i tipi BigInteger e BigDecimal.
ewe.net Fornisce il supporto alla comunicazione TCP/IP in modo
molto simile al package java.net.
ewe.reflect Fornisce il supporto per la Java Reflection.
ewe.security Fornisce il supporto per la crittazione simmatrica
e a chiave pubblica.
ewe.sys Classi di sistemi, tra cui l’implementazione
del testo formattato.
ewe.util Classi di utilita.
ewe.util.zip Per il supporto dei file Zip.
java.lang Questo pacchetto contiene alcune delle classi
del packaga java.lang, e di queste possiede un solo
sottoinsieme dei metodi.
5.4.5 Mysaifu
Mysaifu e una delle rarissime Java Virtual Machine per dispositivi embedded
che si basa sulla Java 2 Standard Edition (J2SE). Ufficialmente questa
piattaforma e free, grazie al progetto GNU e ufficialmente disponibile e com-
patibile per dispositivi che operano con Windows Mobile 2003, Windows
Mobile 2003 Second Edition e Windows Mobile 5.0 per PocketPC. La versio-
5.4. LA JAVA VIRTUAL MACHINE 73
ne piu recente su cui si e basata la ricerca e Mysaifu 0.3.1 e qui di seguito
verranno mostrati gli approfondimenti effettuati e le caratteristiche peculiari
di tale JVM.
Installazione
L’installazione e semplicissima e prevede di copiare il file CAB (jvm.ARM.CAB)
nella cartella My Documents del PDA e di ”tappare” tale file sul Touch
Screen. In questo modo il programma verra installato dentro la directory
\Program Files \Mysaifu.
Usabilita
Per iniziare ad usare Mysaifu basta andare nella cartella ’’Programmi’’ e
cliccare sull’icona ’’Mysaifu JVM’’. Quello che si presenta a video e una
interfaccia come in Fig. 5.1 sulla sinistra. Qui e possibile scegliere il file class
o jar da eseguire. La box di scelta, quando il programma e in esecuzione, e
oscurata e sara possibile fare una nuova ricerca al termine di tale attivita. Il
”button” Execute se cliccato esegue il file prescelto mentre Option prevede
una serie di opzioni da scegliere come mostra l’immagine a destra di figura 5.1.
In Command line arguments vengono inseriti gli argomenti per l’appli-
cazione Java da eseguire, nel CLASSPATH e posto il percorso, che di default
e \My Documents, e in Current directory c’e l’indirizzo della directory
corrente che di default e la root directory.
Le schede in basso indicano che vi sono altre opzioni da personalizzare. Un
esempio e la quantita di memoria (Max heap size) che di default e 2 MB
ma e possibile estenderla fino ad un massimo di 1024MB. La Properties
page permette di mostrare, aggiungere e cancellare le proprieta di sistema
74 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Figura 5.1: Schermata Principale
mentre la Verifier page, grazie ad una check box, si puo selezionare On
per abilitare il verificatore dei file class oppure Off per disabilitarlo.
Quando Mysaifu JVM e in esecuzione sullo schermo appare la schermata ri-
portata In figura 5.2.
Se vogliamo stoppare l’esecuzione dobbiamo cliccare su Exit, se invece
vogliamo che sia presente la console sullo schermo dobbiamo cliccare Show
console..
Tra le opzioni da scegliere esiste una box contenente la lista aggiornata dei
processi in esecuzione. Se si vuole stoppare un processo basta premere Exit,
se si vuole invece aggiornare la lista e necessario fare ”tap” su Refresh.
Tutte queste opzioni possono essere modificate anche da linea di comando
nel seguente formato jvm.exe [options] classname [arg1, arg2, ...]
e possono essere usate le opzioni di figura 5.3.
5.4. LA JAVA VIRTUAL MACHINE 75
Figura 5.2: Schermata durante l’esecuzione
Bugs
Mysaifu e una JVM in evoluzione, per questo motivo sono ancora molti i
bugs da risolvere. La documentazione fornita dal sito ufficiale riguardo i
bugs e molto scarsa e gli autori del software invitano gli utenti ad informarli
se riscontrano qualche problema. Tuttavia le informazioni ricavate aiutano
sicuramente il programmatore a conoscere questi ”difetti” e ad evitare di
incorrere ad inutili errori.
Si elencano di seguito alcuni tra i piu importanti bugs di Mysaifu:
• In primis non tutte le funzioni JNI sono implementate. Ricordiamo
sempre che la tecnologia JNI (Java Native Interface) e colei che consente
ad un’applicazione Java di invocare metodi scritti in linguaggio C. In al-
tre parole non e altro che un’interfaccia appositamente studiata per l’in-
serimento del codice nativo ed e parte integrante del JDK preservando
in questo modo la portabilita del codice su qualsiasi piattaforma.
76 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
Figura 5.3: Opzioni
• Esistono molte classi che fanno uso di librerie GNU e sono tuttavia
poche le classi che sono state testate sotto la JVM.
• I package java.awt, java.lang, java.lang.ref, java.nio.channels,
java.net e java.util sono stati sottoposti a modifiche e quindi prima
di farne uso e bene controllare sulla documentazione.
Le prove fatte
Gli esperimenti eseguiti hanno portato a ritenete che Mysaifu e la Java Vir-
tual Machine che cercavamo. Sebbene si basi su librerie GNU, ha soddi-
sfatto le nostre esigenze in quanto ha risposto positivamente al processo di
installazione e all’esecuzione delle parti di codice necessarie per far eseguire
simulazioni ed esperimenti Neko.
Inizialmente e stato possibile testare la validita e l’efficienza di Mysaifu gra-
5.4. LA JAVA VIRTUAL MACHINE 77
zie all’esecuzione di piccoli esempi costruiti ad hoc. E’ molto utile rendersi
conto gia inizialmente, oltre a tutto cio che si legge nelle specifiche, di cosa la
JVM e e di cosa non e in grado di eseguire. E’ stata provata dalla semplice
stampa a video del messaggio ”Hello World”, all’esecuzione di una serie di
scambio di messaggi tra un client ed un server costruiti precisamente per l’e-
sperimento stesso. Per effettuare tali prove fisicamente e stato indipensabile
solo il cavo USB di collegamento tra la postazione del PDA e il computer.
Inoltre per prendere piu dimestichezza con le funzionalita del DellAxim e
stato testato l’utilizzo dei thread, che funzionano correttamente, ed e sta-
to anche realizzato un primo prototipo di workspace Java comprensivo delle
classi Neko da portare sul PDA.
A questo scopo sono state estrapolate le parti necessarie al funzionamento
di un singolo slave, riunite in un package Java e compilate per creare un file
.class. Dopodiche, a partire dall’appena citato file .class, si sono generati un
file MANIFEST.MF, con al suo interno il percorso per arrivare alla classe con-
tenente il main, e tramite il comando [jar cmf MANIFEST.MF nomeFile.jar
nomeFile 1.class ... nomeFile n.class], dal prompt dei comandi, un
equivalente file .jar. Il file cosı creato, grazie al programma di sincronizzazio-
ne del palmare, e stato salvato all’interno del PDA e, tramite alcune semplici
operazioni spiegate in precedenza, eseguito dalla Java Virtual Machine resi-
dente (Mysaifu).
Per eseguire il file .jar sul DellAxim x51v e stato necessario aprire My-
saifu, scegliere il file desiderato, settare il Bootclasspath con il percorso
\Programmi\Mysaify\jre\lib\rt.jar e porre la voce Max heap size con una
quantita a piacere che dipende da quanta memoria si intende usare per l’ese-
78 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
cuzione del processo. Una volta impostati tutti questi parametri, e possibile
lanciare l’esecuzione. Se durante il procedimento di settaggio non si sono
fatti errori, si aprira una nuova finestra con su scritto Ready on port. Que-
sto significa che lo slave e in funzione ovvero e in attesa che il master venga
lanciato e gli invii indicazioni utili.
L’intero framework Neko tuttavia e solitamente testato all’interno di reti le
cui dimensioni sono maggiori di soli due nodi. Per questo motivo il proce-
dimento per lanciare lo slave precedentemente descritto, puo essere ripetuto
per tutti i palmari che appartengono alla rete. Ovviamente e possibile creare
solo due tipologie di rete, quella tramite cavo USB e quella Wi-Fi, poiche a
differenza delle tecnologie bluetooth e IrDA, per entrare in rete c’e bisogno
di un indirizzo IP. Come e gia stato detto, quando lo slave e lanciato, rimane
Figura 5.4: Rete composta da PDA slave e PC master
in attesa che il master dia le sue istruzioni. A questo punto per stabilire un
collegamento e necessario lanciare il master da un pc con qualsiasi sistema
operativo (Windows o Mac o Linux) e i passi da eseguire sono i seguenti:
1. Modificare il file di configurazione dell’algoritmo che si desidera ese-
5.4. LA JAVA VIRTUAL MACHINE 79
guire. In particolare dove sono dichiarati gli indirizzi degli slave deve
essere inserito l’indirizzo ip del palmare e separato dal simbolo ”:” la
porta su cui si mette in ascolto, che di default e 8632.
2. Dopodiche da linea di comando si esegue l’istruzione java lse.neko.Main
nome file di config. In questo modo il master e lanciato e puo
comunicare con gli slave in rete.
Le prove sul DellAxim
Procedendo come sopra descritto il package e stato testato sul DellAxim e in
particolare eseguito dall’unica Java Virtual Machine compatibile e abbastan-
za potente da supportare Neko: Mysaifu. Questa JVM pur essendo molto
robusta e pur basandosi sulla Java 2 Standard Edition (J2SE), e in continua
via di sviluppo e presenta alcuni bugs.
La prima versione scaricata, Mysaifu 0.2.7, presentava, durante la compilazio-
ne, un errore di ”Heap error”, ed esso appariva ogni qual volta che incontrava
la chiamata System.out.print(’’\n’’). Non e stato facile rendersi conto
che il problema dipendeva da tutte le linee di codice contenenti un siffatto
comando, tuttavia con la versione 0.2.8 questo bug e stato corretto e non e
stato piu riscontrato.
Risolto questo problema si e presentato immediatamente un nuovo impedi-
mento. Poiche per lanciare sul palmare una nuova JVM, e necessario il co-
mando jvm.exe [options] classname [arg1, arg2, ...], per far que-
sto nel codice java si e utilizzato la chiamata ”exec(String)”, dove String
e una stringa contenente il comando. Inizialmente si presentava un errore
proprio su questo metodo. Successivamente e stato scoperto che il comando
non doveva contenere spazi, quindi per aggirare il problema si e utilizzato
il metodo ”exec(String[])” dove all’interno dell’array di stringhe era situ-
80 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
ato il comando nel seguente modo: la prima posizione doveva contenere il
percorso ”\\Program Files\\Mysaifu JVM\\jre\\bin\\jvm.exe ”, la seconda
”-jar” e la terza ”PFile.jar”, dove PFile rappresenta il nome del file. Allo
stesso modo, ogni stringa dell’array doveva essere priva di spazi e si e dun-
que aggirato il problema creando una nuova cartella il cui percorso assoluto
non contenesse spazi. Tuttavia alle nuove cartelle non possiamo accederci
direttamente dalla ricerca dei file in MySaifu ma bisogna inserire a mano la
destinazione.
In definitiva, pur non avendo riscontrato inesattezze di compatibilita nel co-
dice, l’esito di questo esperimento non e stato positivo. Mysaifu infatti rileva
un errore causato da un thread in esecuzione sullo slave, ma non mostra alcu-
na indicazione su quale possa essere il thread che ha causato questa eccezione
rimane praticamente un mistero irrisolto.
5.4.6 Conclusioni
Dopo un’attenta analisi delle possibili JVM e la creazione di un pacchetto di
Neko destinato in futuro ai PDA si tirano le somme e si illustrano le conclu-
sioni a cui siamo giunti.
Innanzi quando si parla di compatibilita con Java si fa riferimento, in questo
contesto, alla quantita di modifiche che e necessario apportare al codice sor-
gente, concepito per essere eseguito sul runtime Java standard, affinche esso
possa essere eseguito anche su macchine virtuali per i dispositivi mobili.
Per quanto riguarda le macchine virtuali java-compliant, come Jeode e CrE-
me, poiche offrono le stesse API, la compatibilita rispetto a java si puo rite-
nere quasi completa, a patto che nel codice di partenza siano state utilizzate
classi supportate dagli ambienti di esecuzione delle PDA virtual machine.
Per questo motivo sono le JVM piu papabili, nel nostro caso, in quanto il
5.4. LA JAVA VIRTUAL MACHINE 81
codice di Neko non dovrebbe essere neppure modificato ma solo scremato
delle parti superflue. Tuttavia Jeode oltre ad essere a pagamento e anche
una JVM morta, in quanto l’Insigna non rilascia piu versioni, mentre CrEme
pur avendo tutti i requisiti in regola risulta non compatibile proprio con il
DellAxim x51v.
Tutto un’altro discorso riguarda le macchine virtuali java-based, esse infatti
non implementano alcuna libreria java standard, per cui seppure il linguaggio
di programmazione per lo sviluppo delle applicazioni ha una sintassi java, e
sempre necessaria una modifica del codice sorgente. Tra le macchine java-
based fanno parte Ewe e SuperWaba, ma pur appartenedo allo stesso insieme,
sono profondamente diverse nei riguardi della compatibilita con Java. Su-
perWaba necessita di una vera e propria ristrutturazione del codice, infatti
per poterne usufruire e necessario estendere una classe, MainWindow, che e
l’equivalente del metodo main di Java. Ewe, invece, pur non definendo libre-
rie conformi alle specifiche Java standard, ha dedicato particolare attenzione
al processo di migrazione delle applicazioni Java in applicazioni Ewe. Per
questo motivo per convertire il programma Neko in Java in uno di tipo Ewe,
sarebbe stato sufficiente sostituire i package Java con i package Ewe e aggiun-
gere, o modificare, alcune parti di codice non compatibili nell’applicazione.
Tuttavia Ewe risulta compatibile solo fino ai PocketPC 2003 e in entrambi
i casi, sia SuperWaba che Ewe, hanno un forte impedimento per poter far
funzionare Neko sul PDA, oltre al grande problema della compatibilita. Esse
infatti permettono di utilizzare thread che non consentono prelazione e non
supportano alcun tipo di concorrenza. Per il funzionameto di Neko, questo e
un impedimento insormontabile che porta a ritenere Ewe e SuperWaba ina-
datte al nostro scopo.
Quindi si puo concludere che nessuna tra queste JVM, basate sulla piatta-
82 CAPITOLO 5. PDA, SISTEMI OPERATIVI E JVM DEDICATI
forma J2ME, e compatibile o usufruibile al fine di testare Neko sul DellAxim
x51v e che l’unica Java Virtual Machine ad esserlo e Mysaifu, basata sulla
J2SE.
Capitolo 6
Conclusioni
I piccoli dispositivi mobili come i PDAs stanno sempre piu entrando a far
parte della vita quotidiana di ognuno di noi, dal semplice commesso al me-
dico, dal manager a sistemi come automobili, ecc.. E quindi giusto pensare
che questi device possano essere utilizzati in un sistema distribuito sul quale
e importante poter effettuare delle analisi qualitative e quantitative. Uno
strumento presente sul mercato che offre la possibilita di valutare sistemi e
algoritmi distributi e Neko e la sua estensione NekoStat. Si e cosı pensa-
to di poter, dopo aver analizzato sia le caratteristice dei palmari, delle jvm
disponibili e il funzionamento di Neko, ”ripulire” quest’ultimo per poterne
usufruire sui PDA.
Come gia sappiamo i palmari stanno acquisendo delle potenzialita sempre
maggiori, tuttavia sussistono ancora dei limiti di memoria e velocita di e-
secuzione che richiedono la presenza, nel sistema distribuito, di device piu
potenti per la configurazione di tutta l’applicazione distribuita e la successiva
raccolta ed elaborazione dei dati.
Per questo motivo e stato deciso, dall’analisi di Neko, che la parte relativa
83
84 CAPITOLO 6. CONCLUSIONI
alla configurazione delle applicazioni distribuite (Master) non e necessaria al
package, poiche risulta piu adatta a dispositivi con maggiori potenzialita di
un semplice PDA. Escluso le classi relative al Master, si e tenuto di conto
delle restanti, dividendole per funzionalita. Infatti prima si e analizzato il piu
piccolo sottoinsieme di classi che dovra essere posto sul PDA per svolgere la
semplice funzione di Slave. Dopodiche quest’insieme e stato arricchito con le
classi che permettono al PDA di compiere le funzioni di generatore di Slave e
quindi e stata aggiunta la ServerFactory e tutte le sue classi annesse. Infine,
per poter raccogliere i risultati utili al Master per l’analisi statistica dell’ap-
plicazione distribuita, sono state inserite le classi necessarie alla raccolta dati
del tool NekoStat.
D’altro canto, per poter vedere realmente in funzione il pacchetto su un
palmare, si sono dovute fare alcune analisi riguardanti lo stato attuale della
tecnologia per il supporto di NekoPDA.
Per quanto riguarda lo studio dei sistemi operativi legati ai dispositivi em-
bedded, si puo concludere che ne esistono principalmente quattro: Symbian
Os, Palm OS, Linux e Windows Mobile 5.0. Quest’ultimo e uno tra i piu
innovativi, ma non ancora largamente diffuso come il Simbian Os per il cel-
lulari e gli smartphone. Per quanto riguarda il SO Linux per palmari, non
abbiamo ancora grandi risultati, ma sembra proprio che in futuro potremo
aspettarci molte sorprese.
Dallo studio riguardante le JVM invece si e potuto notare che lo sviluppo del
linguaggio Java, come uno tra i piu importanti linguaggi di programmazio-
ne, accompagnato dall’evoluzione e dal conseguente sviluppo nel mercato dei
dispositivi palmari, ha ampliato l’interesse riguardo l’uso di Java sui piccoli
dispositivi. Attualmente la tecnologia propone una vasta gamma di tipi di
85
Java Virtual Machine per dispositivi embedded, tuttavia le continue novita
che il mercato propone non sempre garantiscono la compatibilita con le ver-
sioni precedenti o con tutta una gamma di dispositivi diversi tra loro. Inoltre
si puo ritenere quasi impossibile garantire che le JVM dedicate a computer
desktop, con il piu grande insieme di funzionalita all’avanguardia, siano adat-
ti anche per piccoli dispositivi. Per questo motivivo e necessario scendere a
dei compromessi. Non e possibile eleggere una macchina virtuale principe in
assoluto tra le J2ME, che sia compatibile con tutti i dispositivi fisici e che
garantisca l’insieme di funzionalita piu ampio. E’ possibile tuttavia fare una
scelta in termini relativi, in base ai requisiti dei dispositivi e all’uso che si
vuole fare con tali dispositivi.
Tra le JVM piu importanti che sono state analizzate ricordiamo Jeode, Su-
perWaba, Ewe, CrEme e MySaifu. Con Jeode e CrEme, pur essendo ritenute
le uniche due JVM piu adatte per le proprie funzionalita, i problemi di com-
patibilita si sono rivelati insormontabili, in quanto neppure l’installazione ha
avuto successo. Con MySaifu invece e stato possibile almeno interfacciarsi
ed effettuare una serie di piccole prove. Tuttavia pur avendo un dispositivo
di ultima generazione, per una serie di motivi, non e stato possibile effettu-
re esperimenti fisici su quanto e stato progettato. Sicuramente il DellAxim
e uno tra i piu potenti device PDA in circolazione ed e anche uno dei piu
sofisticati, ma proprio per questo motivo anche tra i meno compatibili. Nel
momento in cui comparira sul mercato una JVM piu funzionale e ripetuta-
mente consolidata in grado di supportare la J2SE sara possibile installare il
pacchetto NekoPDA come progettato sui palmari.
86 CAPITOLO 6. CONCLUSIONI
Appendice A
Pacchetto NekoPDA
Qui di seguito si riporta un elenco esplicativo di tutti i pacchetti e di tutte
le classi che teoricamente potrebbero essere eseguite su un qualsiasi PDA.
Al pacchetto lse.neko appartengono le classi:
87
88 APPENDICE A. PACCHETTO NEKOPDA
AbstractId ActiveReceiver
Dispatcher EventTypeConst
HierarchicalId MessageTypes
MessageTypeConst NekoInitializer
NekoMessage NekoMessageEvent
NekoMessageQueue NekoObject
NekoObjectInterface NekoProcess
NekoProcessInitializer NekoSystem
NekoThread NekoThreadInterface
NekoThreadStaticInterface ProcessReceiver
ProcessSender Protocol
ProtocolImpl PullInterface
PullNetworkInterface PullProtocol
ReceiverInterface SenderInterface
UnexpectedMessageException
Al pacchetto lse.neko.comm:
CommNetwork Config
Deserializer NekoCommObject
NekoCommThread NekoCommThreadStatic
NekoCommSystem NetworkInitLayer
JavaSerializer JavaDeserializer
JavaSerializerFactory
ServerFactoryWorker ShutdownInterface
Slave WrappingNekoThread
Al pacchetto org.apache.java.util:
89
ConfigurationsRepository ExtendedProperties
Al pacchetto lse.neko.util:
ExceptionHandler GUID
IntHolder LauncherCatchingExceptions
MySystem ObjectBuffer
ObservableInteger SerializableIterator
SparseArrayList Timer
TimerTask Util
Al pacchetto lse.neko.util.logging:
NekoLogger NekoLogManagerInitializer
NekoLogRecord
Al pacchetto lse.neko.networks:
QueueSizeObservable ReceiveBlockable
Al pacchetto lse.neko.networks.comm:
ChannelInterface Connection
ControlNetwork ServerSocketInterface
SocketFactoryInterface TCPChannel
TCPNetwork TCPSocketFactory
TCPServerSocket
Al pacchetto lse.neko.stat:
90 APPENDICE A. PACCHETTO NEKOPDA
Event EventCollector
LoggingStatHandler StatHandler
StatInitializer StatLayer
StatListener StatLogger
StatLoggerMaster StatLoggerSim
StatLoggerSlave StatProtocol
Al pacchetto lse.neko.failureDetectors:
FailureDetector FailureDetectorInterface
FailureDetectorListener
Heartbeat
Al pacchetto lse.neko.layers:
ListFragmenter SimpleClockSynchronizer
SimpleClockSynchronizerSlave ShutdownStack
Le nuove classi aggiunte sono:
Getopt LongOpt
StartServer StartServerMain
StartServerP2 StartServerP3
Ringraziamenti
Desidero ringraziare tutta la mia famiglia, e in particolare la mia coinquilina
preferita: mamma Lucia. La mia compagna di studio e di sventure Vanja,
tutta la sua famiglia insieme agli involtini della Maria e alle mie amiche da
una vita Pizzy e Ginni. Ringrazio tutti gli amici di’PES per avermi fatto
compagnia e sopportato tutti i giorni, in particolare il Giuntini per avermi
portato a Tirrenia tutta l’estate, i Chiti perche va sempre a hasa perche bufa,
i’Testori perche e da sempre innamorato di me e io lo penso sempre, Lapo
perche ogni tanto uno deve fare delle scelte, lo Sdelci perche e logico, Sergio
perche ha fatto una tesi esagerata e l’omino della lego che ormai e diventato
Re della foresta.
Ringrazio i’Marmugi perche e un grande amico, i’Giaco perche e il piu buono
e bravo di tutti e quella peste di’Berti con i suoi tanti hobby. Ringrazio Tom-
maso e in particolar modo la Barbara che pur essendo di bollicine e troppo
vicino a via Francesca e la meglio in assoluto.
Ringrazio il Prof. Bondavalli e il Dr.Falai che mi sono sempre stati vicini
e mi hanno aiutato nel duro lavoro. Infine ringrazio tutti coloro che non sono
stati citati ma che mi hanno voluto bene e mi sono stati vicini in tutti questi
anni.
91
92 APPENDICE A. PACCHETTO NEKOPDA
Bibliografia
[1] Donald A.Norman Invisible Computer,1998, Cambridge MA, MIT Press
[2] L. Falai: Metodologie e strumenti per l’analisi quantitativa sperimentale
e simulativa di algoritmi distribuiti, Tesi di laurea, Universita degli Studi
di Firenze (2004)
[3] A. Bondavalli, L. Falai,Lucidi delle lezioni e seminari del corso
Affidabilita dei Sistemi di Elaborazione, Universita di Firenze
[4] A. Bondavalli, Lucidi delle lezioni del corso Modellistica e Simulazione,
Universita di Firenze
[5] A. Avizienis, J. Laprie, B. Randell. Fundamental Concepts of
Dependability. Research Report N01145, LAAS-CNRS, Apr. 2001.
[6] F.Esposito: Analisi e valutazione di macchina virtuali Java per disposi-
tivi mobili, Tesi Laurea, Facolta di Ingegneria, Universita degli studi di
Napoli Federico II
[7] JAVA 2 Platform, Standard Edition, ver. 1.5.0 - API Specification,
http://java.sun.com/j2se/1.5.0/docs/api
[8] msdn: http://msdn2.microsoft.com
[9] Smartphone e PocketPC Magazine: http://www.pocketpcmag.com
93
94 BIBLIOGRAFIA
[10] Java Sun Developer Network (SDN): http://developers.sun.com
[11] MysaifuJVM: http://www2s.biglobe.ne.jp
[12] Insigna: www.insignia.com
[13] EWE: www.ewesoft.com
[14] Superwaba: www.superwaba.com
[15] PalmSource: http://www.palmsource.com
[16] JavaDocs J2ME: http://www.wmlscript.it
[17] CrEme: http://www.nsicom.com/, NSI Group.
[18] J2ME http://java.sun.com/j2me/, Sun Microsystems