analisi e validazione di algoritmi distribuiti in sistemi...

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

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


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


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


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


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.


• 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.


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


progettazione che in fase di sviluppo. A questo proposito ci viene in aiuto

Neko.

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


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.


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.


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


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


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


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


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.


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


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


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


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-


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.


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.


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


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


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


Figura 4.2: Le classi di Neko incluse nel package 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


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


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


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


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


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.


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,


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


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


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


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


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


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


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.


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.


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


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


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


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.


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.


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


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.


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.


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-


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


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.


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.


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-


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-


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-


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-


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


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-


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:


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

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