Progetto di un framework di sviluppo per dispositivi mobili Cuccaro Mimmo.pdf · Progetto di un...

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II

Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica

Tesi di Laurea

Progetto di un framework di sviluppo per dispositivi mobili

RELATORE Chiar.mo Prof. Stefano Russo CORRELATORE CANDIDATO Ing. Marcello Cinque Domenico Cuccaro Matricola 41/3524

ANNO ACCADEMICO 2006-2007

A mio nonno, esempio di vita,

che da lassù mi guida

Mi siedo e inizio a pensare agli ultimi anni della mia vita, e forse più in là. Gli

eventi, i luoghi e i volti si susseguono nella mia mente e mi accorgo che tante sono le cose

che ho dimenticato, eppure ciascuna di esse fa parte di me: ci sono persone che avrò

incontrato una sola volta nella mia vita, persone di cui non ricordo nemmeno il nome, le

stesse persone di cui, però, ricordo una frase o un gesto di cui ho deciso di “appropriarmi”,

più che nel ricordo, nel mio atteggiamento verso il mondo.

Poi, ci son le persone di sempre, quelle con cui vivo e son cresciuto: la mia famiglia

e la mia fraternità francescana. Mia madre mi ha insegnato cos’è l’amore e il sacrificio che

questo sentimento porta con sè; mio padre mi ha insegnato ad affrontare il mondo perché

egli stesso, a volte, senza un lamento, sembra portarne il peso; mia sorella Luana mi ha

insegnato a preservare e difendere le persone che ami.

Non oso immaginare la mia vita senza la mia fraternità, praticamente tutti i miei

ricordi passano per essa: frati e suore, uomini e donne, ragazzi e ragazze, bambini e

bambine, a ciascuno dei quali devo una carezza, un sorriso, una parola, una preghiera, un

litigio o un rimprovero. La mia fraternità: una famiglia all’ennesima potenza, in tutto.

Nella mia fraternità ho trovato anche chi, capace di perforare la corazza delle mie

paure, mi ha fatto innamorare: la mia piccola Denise che da due anni e mezzo sopporta le

mie ansie e supporta i miei sogni che spesso ci tengono “lontani”.

Per i miei studi universitari, un grazie particolare va al mio correlatore, Marcello

Cinque, e alla sua professionalità che, senza risparmio, ha saputo trasmettermi in questi

mesi dedicati allo sviluppo della tesi: spero di averne fatto tesoro per il mio futuro. Grazie

anche all’ingegner Vincenzo Vecchio che, seppur in poche occasioni, ha saputo

consigliarmi su scelte importanti e pratiche. Un sentito grazie va al professor Stefano

Russo per l’occasione, di studio e professionalità, a cui mi ha offerto la possibilità di

accedere e per avermi insegnato ad attribuire il giusto tempo alla crescita personale.

Voglio ringraziare i miei amici, Flavio e Vittorio, che, seppur in tempi diversi,

hanno condiviso con me questo percorso legato allo sviluppo della tesi.

In ultimo, auguro ai miei amici, di questi anni universitari, tutto il bene possibile e di

concludere i loro studi al più presto. Giovanni, Antonio, Umberto e Peppe: forza!

Indice

I

INDICE

INDICE.............................................................................................................................................................................. I

INTRODUZIONE ......................................................................................................................................................... III

1. APPLICAZIONI EMERGENTI IN AMBIENTI MOBILI...................................................................................... 1

1.1 CONCETTI BASE SUI SISTEMI DISTRIBUITI.................................................................................................................. 1 1.2 MOBILE COMPUTING ................................................................................................................................................. 3 1.3 PROBLEMATICHE RELATIVE AI SISTEMI MOBILI......................................................................................................... 6 1.4 SCENARI APPLICATIVI ............................................................................................................................................... 8 1.5 CONCLUSIONI ......................................................................................................................................................... 12

2. SOLUZIONI MIDDLEWARE PER IL MOBILE COMPUTING ........................................................................... 14

2.1 ASPETTI COMUNI DEI MIDDLEWARE......................................................................................................................... 14 2.2 DIFFERENZE TRA MIDDLEWARE PER SISTEMI TRADIZIONALI E PER SISTEMI MOBILI ................................................. 16 2.3 MIDDLEWARE PER SISTEMI MOBILI........................................................................................................................... 18

2.3.1 Middleware tradizionali adattati al Mobile Computing................................................................................. 18 2.3.2 Middleware creati Ad-Hoc per Mobile Computing........................................................................................ 21

2.4 WEB SERVICES ......................................................................................................................................................... 26 2.5 SOLUZIONI OFFERTE DALLA JAVA COMMUNITY........................................................................................................ 29

2.5.1 Introduzione alla piattaforma J2ME.............................................................................................................. 29 2.5.2 Configuration e Profile .................................................................................................................................. 31 2.5.3 Java RMI ........................................................................................................................................................ 36 2.5.4 J2ME Web Services: JSR-172 e kSOAP......................................................................................................... 39 2.5.5 Jini.................................................................................................................................................................. 43

2.6 SOLUZIONI .NET..................................................................................................................................................... 44 2.6.1 Panoramica su .NET Framework................................................................................................................... 44 2.6.2 .NET Compact Framework ............................................................................................................................ 45

2.7 CONCLUSIONI ......................................................................................................................................................... 48

3. FRAMEWORK PER L’INTEGRAZIONE DI SERVIZI IN AMBIENTI MOBILI ............................................. 50

3.1 OBIETTIVI DEL FRAMEWORK .................................................................................................................................... 50 3.2 REQUISITI DEL FRAMEWORK .................................................................................................................................... 51

3.2.1 Requisiti funzionali......................................................................................................................................... 51 3.2.2 Requisiti non funzionali.................................................................................................................................. 54

3.3 ARCHITETTURA DEL FRAMEWORK ........................................................................................................................... 55 3.4 STUDIO DI FATTIBILITÀ ........................................................................................................................................... 61

3.4.1 Introduzione ................................................................................................................................................... 61

Indice

II

3.4.2 Confronto tra le possibili scelte tecnologiche ................................................................................................ 62 3.4.3 Prospettive di mercato ................................................................................................................................... 64

3.5 CONCLUSIONI ......................................................................................................................................................... 65

4. ANALISI DI UN CASO DI STUDIO: INTEGRAZIONE DEL SERVIZIO VOIP.............................................. 67

4.1 PANORAMICA SULLA TECNOLOGIA VOIP ................................................................................................................ 67 4.2 PROTOCOLLI PER IL VOIP ....................................................................................................................................... 70

4.2.1 RTP................................................................................................................................................................. 71 4.2.2 H.323.............................................................................................................................................................. 73 4.2.3 SIP.................................................................................................................................................................. 76 4.2.4 IAX ................................................................................................................................................................. 82

4.3 QOS E CODEC .......................................................................................................................................................... 83 4.4 SOLUZIONI PER IL VOIP .......................................................................................................................................... 86

4.4.1 Asterisk........................................................................................................................................................... 86 4.4.2 sipXpbx........................................................................................................................................................... 87 4.4.3 Jabber/XMPP: Openfire, Spark e Asterisk-IM............................................................................................... 88 4.4.4 MjSIP e altre soluzioni open-source Java...................................................................................................... 89 4.4.5 Soluzioni e client VoIP per il Mobile ............................................................................................................. 90

4.5 PROGETTO DEL COMPONENTE VOIP........................................................................................................................ 93 4.5.1 Analisi dei requisiti ........................................................................................................................................ 93 4.5.2 La fase di progettazione ................................................................................................................................. 98 4.5.3 Test Case ...................................................................................................................................................... 104

4.6 NOTA IMPLEMENTATIVA....................................................................................................................................... 109 4.6.1 Mysaifu JVM ................................................................................................................................................ 109 4.6.2 “MjSIP mobile”: studio di fattibilità ........................................................................................................... 110 4.6.3 Implementazione .......................................................................................................................................... 112 4.6.4 Testing.......................................................................................................................................................... 115 4.6.5 Esempio d’uso .............................................................................................................................................. 117

4.7 CONCLUSIONI ....................................................................................................................................................... 119

5. CONCLUSIONI E SVILUPPI FUTURI ................................................................................................................ 121

APPENDICE................................................................................................................................................................. 125

A.3.1 SOLUZIONE WEB SERVICE IN AMBIENTE NOMADICO .......................................................................................... 125 A.3.1.1 Tecnologie Java per i Web Services ......................................................................................................... 125 A.3.1.2 Lato Server................................................................................................................................................ 127 A.3.1.3 Lato Client ................................................................................................................................................ 130

A.3.2 SOLUZIONE E SUOI LIMITI.................................................................................................................................. 132

BIBLIOGRAFIA .......................................................................................................................................................... 136

Introduzione

III

Introduzione

Girava qualche anno fa in televisione uno spot pubblicitario: un uomo in metropolitana,

durante il tragitto da casa verso il suo ufficio, si collega ad Internet con il suo palmare,

controlla l’andamento della borsa, compra-vende azioni, stila un rapporto con un

programma di editing, ne richiede la stampa e, arrivato in un ufficio, prende dalla

stampante il rapporto cartaceo, poi si siede ed esclama: “Anche oggi ho finito il mio

lavoro!”: futuristico allora, oggi verosimile quanto mai.

I sistemi distribuiti e le applicazioni progettate per essi continuano a rimanere importanti

nell’ambito della condivisione di risorse e del lavoro d’ufficio, ma i sistemi mobili e i

servizi sembrano essere il paradigma che guiderà lo sviluppo delle tecnologie del

prossimo futuro.

La crescente diffusione dei dispositivi mobili, dal cellulare al palmare, con prestazioni

crescenti, ha spinto, gli utenti, a “pretendere” sempre di più dai loro dispositivi e, le

aziende, ad investire per rimanere competitive su un mercato crescente: si è passati così

dalla possibilità di effettuare telefonate o inviare SMS su rete GSM, al protocollo

Bluetooth per condividere file e scambiare messaggi, e al Wi-Fi per connettersi ad una rete

LAN e navigare in Internet. Basti pensare, per esempio, che oggi esistono diverse

tipologie di client di messaggistica istantanea e di VoIP (Voice over IP), eseguibili sulla

maggior parte dei palmari di diffusione più comune, con i relativi server che offrono tale

servizio, tanto a macchine desktop quanto ai suddetti dispositivi mobili.

Introduzione

IV

L’obiettivo di ogni nuova tecnologia introdotta è estendere la connettività del dispositivo

mobile e permettere all’utente di accedere a servizi remoti, oltre che la collaborazione con

altri dispositivi mobili (reti Ad-Hoc).

Gli ambienti nomadici, dove una parte dell’infrastruttura è fissa e offre i servizi, e i

middleware pensati per tali ambienti sono largamente diffusi. Si pensi ad un’applicazione

client residente su palmare che “consuma” un servizio remoto; la necessità di rendere

accessibile tale servizio da parte di client mobili di diversa tipologia ha spinto verso lo

sviluppo di middleware più flessibili di quelli comunemente usati per i sistemi distribuiti.

Lo stato dell’arte attuale dei middleware per dispositivi mobili riconosce sopratutto

l’esistenza di middleware per nomadic computing, dove la business logic è demandata

all’infrastruttura fissa.

Tuttavia la velocità con cui si introducono sul mercato dispositivi mobili sempre più

performanti e la diffusione delle reti Wi-Fi, oltre le “piccole” WLAN, ci spinge a pensare

che i dispositivi mobili, nonché le reti da essi costituite, possano avere una vita

indipendente da qualunque altra infrastruttura, similmente ad una rete Ad-Hoc.

In questa direzione spinge soprattutto la necessità di accedere ai servizi in ambienti ostili o

in condizioni di emergenza.

Se è molto sentita la necessità dell’utente di accedere velocemente, ovunque e in modo

trasparente a una determinata gamma di servizi, allora chi è chiamato a sviluppare

applicazioni, anche complesse, per il mobile computing avverte con la stessa forza la

convenienza di avere a disposizione gli strumenti adatti per garantire uno sviluppo veloce

del prodotto finale tale che risponda, in termini di qualità, alle esigenze di mercato. Questo

discorso vale soprattutto considerando che le applicazioni più complesse per il mobile

computing richiedono, oltre all’accesso, anche la collaborazione tra i servizi comunemente

diffusi per i dispositivi mobili.

Il presente lavoro di tesi si colloca, appunto, in questo contesto.

Introduzione

V

L’obiettivo è progettare un framework di servizi destinato a dispositivi mobili. Esso dovrà

rispettare vincoli architetturali legati alle ridotte risorse tipiche dei dispositivi mobili in

modo da poter risiedere sugli stessi. Lo stesso framework dovrà permettere ai dispositivi

di accedere ai servizi, indipendentemente dalla loro locazione, e garantire una piena

collaborazione tra tutti i dispositivi mobili su cui esso stesso risiede. Chiariamo che

intendiamo realizzare una collaborazione tra i dispositivi in termini di servizi, infatti la

progettazione del framework, oltre a garantire quanto detto, include anche lo sviluppo dei

servizi più comuni e distribuiti sui dispositivi mobili odierni; ci riferiamo, per esempio,

alla messaggistica istantanea e al VoIP così come al GPS.

Sulla base di quanto asserito, il presente lavoro di tesi è organizzato come segue.

Nel primo capitolo daremo una panoramica dei concetti base dei sistemi distribuiti per

aprire il discorso circa il mobile computing e le problematiche ad esso relative.

Riporteremo una breve descrizione di alcuni scenari applicativi, già esistenti o auspicabili,

in cui il framework potrebbe trovare applicazione.

Nel secondo capitolo analizzeremo gli aspetti comuni alle architetture middleware.

Terremo una breve panoramica su quelle che sono le soluzioni esistenti di middleware per

il mobile computing, adattate e native. Particolare attenzione dedicheremo alle soluzioni

proposte dalla Java Community e da Microsoft. L’analisi delle tecnologie per i middleware

ci permetterà di scegliere quale soluzione adottare per la progettazione del nostro

framework.

Nel terzo capitolo trattiamo la progettazione del framework, introducendo i requisiti

definiti dal progetto “WiFi People – CRONOS”, nato da una collaborazione tra il

dipartimento di informatica e sistemistica (DIS) dell’Università Federico II di Napoli e

l’azienda “WiFi People”. In particolare, definiremo i servizi a cui il framework deve

fornire accesso. Mostreremo l’architettura scelta per il framework e i possibili contesti e

configurazioni in cui può trovarsi ad operare.

Introduzione

VI

Nel quarto capitolo effettueremo l’analisi di un caso studio, ovvero di uno dei servizi

richiesti dalle specifiche del framework.

Precisamente dedicheremo la nostra attenzione al servizio VoIP. Dopo una breve

panoramica sui protocolli coinvolti nello sviluppo della tecnologia VoIP, concentreremo la

nostra attenzione sulle soluzioni presenti sul mercato come applicazioni stand-alone VoIP

per dispositivi mobili e non.

Ci concentreremo sulla progettazione del componente VoIP, sulle questioni legate alla

distribuzione di un servizio del genere su un dispositivo mobile e, in particolare, nel

contesto del nostro framework.

Infine, nel quinto capitolo, terremo alcune brevi considerazioni circa soluzioni alternative,

in termini tecnologici, per il framework presentato.

Capitolo 1. Applicazioni emergenti in ambienti mobili

1

1. Applicazioni emergenti in ambienti mobili

Prima di descrivere alcuni scenari applicativi relativi ad ambienti mobili, facciamo una

breve panoramica sulle caratteristiche base dei sistemi distribuiti che sono alla base delle

diverse tipologie di sistemi mobili.

1.1 Concetti base sui sistemi distribuiti

Intuitivamente un “sistema distribuito” consiste in una collezione di componenti dislocati

su vari computer connessi attraverso una rete telematica.

“Un sistema distribuito è un sistema i cui componenti, localizzati in computer connessi in

rete, comunicano e coordinano le loro azioni solo attraverso scambio di messaggi” [1].

Da tale definizione emergono ulteriori caratteristiche di un sistema distribuito:

o concorrenza dei componenti;

o assenza di un clock globale, ciò comporta che la sincronizzazione e l’interazione

tra i nodi sia possibili tramite scambio messaggi;

o possibilità di guasti indipendenti dei componenti:

- nei nodi (crash, attacchi, …);

- nel sottosistema di scambio messaggi (ritardi, perdita, attacchi,...).

I parametri che caratterizzano un sistema distribuito e la sua progettazione sono i fattori di

complessità [1]:


2

o Eterogeneità, legata alla varietà e differenza di reti (tecnologie e protocolli), di

sistemi operativi, di hardware (dei server, dei client) e di linguaggi di

programmazione. Da qui nasce l’esigenza di usare un middleware nello sviluppo e

nella messa in opera di un’applicazione destinata a tali sistemi;

o Apertura (openness) caratterizza il livello di complessità col quale servizi e risorse

condivise possono essere resi accessibili a una varietà di clienti, o resi tra essi

interoperanti.

I sistemi aperti richiedono:

- interfacce pubbliche dei componenti;

- standard condivisi;

- il superamento di adeguati test di conformità.

o Sicurezza (security) analizzata sotto tre aspetti:

- confidenzialità (protezione dall’accesso da parte di utenti non autorizzati);

- integrità (protezione dall’alterazione o compromissione di dati e risorse);

- disponibilità (protezione dall’interferenza con i mezzi di accesso alle risorse).

o Concorrenza, in particolare l’accesso a risorse e servizi condivisi deve essere

consentito in maniera virtualmente simultanea a più utenti;

o Trasparenza, legata alle otto forme di trasparenza identificate nell’ISO Reference

Model for Open Distributed Processing (RM-ODP);

o Scalabilità: un sistema è scalabile se resta efficace ed efficiente anche a seguito di

un aumento considerevole di utenti o risorse. A tal proposito si adottano tecniche

di controllo delle prestazioni e dei colli di bottiglia, o tecniche atte a prevenire

l’esaurimento delle risorse rispetto alla crescita del sistema;

o Guasti: i guasti nei sistemi distribuiti sono parziali e, come tali, vanno gestiti con

tecniche in grado di controllare il livello di servizio offerto. Si tratta di tecniche di

individuazione dell’errore (failure detection), masking, tolerance e/o recupero

degli stessi (recovery).


3

1.2 Mobile Computing

I sistemi distribuiti tradizionali sono evoluti negli anni verso nuovi sistemi di elaborazione

e comunicazione: mobile computing, pervasive computing, ubiquitous computing,

nomadic computing, Ad-Hoc computing [2]. Anche se alcune similitudini possono essere

individuate, ognuno di essi ha un’identità ben definita se si guarda ai seguenti aspetti [3]:

1. device, si intende un nodo di rete dotato di capacità di elaborazione autonoma; in

base alle sue proprietà di mobilità spaziale si può classificare in:

o fisso - dispositivi generalmente potenti con grandi quantità di memoria e

processori veloci;

o mobile - dispositivi tipicamente poveri di risorse e con problemi di

alimentazione che implicano la loro limitata disponibilità nel tempo.

Attualmente i dispositivi mobili o portabili sono:

- PDA (Personal Digital Assistant), ovvero i palmari;

- Smartphone, ovvero un dispositivo portatile che abbina funzionalità

di gestione di dati personali e di telefono;

- Dispositivi special-purpose (digital camera, barcone reader);

- Microcontrollori, sensori e attuatori presenti nei sistemi di controllo.

2. embeddedness, si intende il grado di specificità del compito per cui viene progettato

un dispositivo sé il livello di integrazione raggiunto nel costruire il dispositivo che

assolve un determinato compito. In base a questo criterio è possibile distinguere tra

dispositivi:

o general purpose, un dispositivo progettato per rispondere a compiti non

particolarmente specifici (come PDA);

o special purpose, un dispositivo progettato per rispondere a compiti ben

specifici (come microcontrollori, sensori, badges).


4

3. connessione di rete, con questo attributo ci riferiremo alla qualità del collegamento

tra due o più host di rete; essa può essere:

o permanente, tipicamente una connessione di rete permanente è caratterizzata

da un’elevata banda ed un basso rapporto bit su errore (BER – bit error

rate);

o intermittente, tipicamente una connessione di rete intermittente è

caratterizzata da una modesta banda, spesso variabile, ed un BER

influenzato fortemente da agenti esterni.

4. contesto di esecuzione, in letteratura esistono diverse definizioni di contesto. In

questo ambito intenderemo per contesto qualsiasi cosa che possa influenzare il

comportamento di un’applicazione, come risorse interne al dispositivo (stato della

batteria, disponibilità della CPU, disponibilità della memoria, dimensione del

display) o esterne ad esso (larghezza di banda, affidabilità e latenza del canale,

prossimità degli altri dispositivi). Un contesto può essere:

o statico, se le risorse interne ed esterne variano poco o mai;

o dinamico, se le risorse interne ed esterne sono soggette a forti cambiamenti.

I sistemi distribuiti tradizionali sono costituiti da una collezione di dispositivi fissi e

general-purpose connessi tra di loro attraverso una connessione permanente le cui

applicazioni vivono in un contesto di esecuzione statico. Tali sistemi evolvono verso il

mobile computing che presentano caratteristiche di mobilità dei dispositivi.

Il mobile computing è un modello di elaborazione riferito ad un sistema distribuito in cui

vi sia mobilità dell’hardware e presenza di tecnologie di comunicazione senza cavo.

Per mobilità dell’hardware o sistema mobile si intende un sistema distribuito in cui alcuni

nodi attivi dell’elaborazione possono muoversi liberamente nello spazio fisico.


5

In tali contesti si ha il cosiddetto funzionamento “disconnesso” [4], ovvero la

comunicazione è garantita in maniera “intermittente” da tecnologie di comunicazione

senza filo (wireless).

I sistemi mobili si possono dividere in tre categorie [2] [4]:

o I sistemi nomatici (nomadic computing) rappresentano un compromesso tra i

sistemi totalmente fissi e totalmente mobili. Sono generalmente composti da un

insieme di dispositivi mobili general-purpose interconnessi in maniera

intermittente ad un’infrastruttura core con nodi fissi general-purpose (collegati tra

loro attraverso una connessione permanente). Data la natura del sistema, le

applicazioni vivono in un contesto di esecuzione che può essere talvolta statico e

talvolta dinamico. I dispositivi mobili di tali sistemi sono interconnessi tra loro e

alla rete core attraverso dei dispositivi intermedi, noti come Access Point (AP). Il

cambio di AP da parte di un dispositivo mobile è un’operazione nota come

handoff.

o I sistemi Ad-Hoc (mobile Ad-Hoc networks) sono sistemi in cui la rete si

costituisce “spontaneamente” e in maniera wireless tra i dispositivi stessi, a causa

dell’impossibilità o inutilità di affidarsi ad un’infrastruttura fissa. Tali sistemi sono

costituiti da un insieme di dispositivi mobili, tipicamente general-purpose,

connessi tra di loro attraverso un collegamento intermittente le cui applicazioni

vivono in un contesto di esecuzione dinamico. I dispositivi devono godere di

proprietà di autoconfigurazione (ad esempio, nell’instradamento dei pacchetti),

data l’assenza di un’infrastruttura fissa. Un dispositivo di tale sistema può

comunicare direttamente solo con i suoi vicini (i nodi presenti nel raggio di

comunicazione). Più “salti” (hops) tra nodi potrebbero essere richiesti per

attraversare la rete.


6

o Per sistemi Pervasive & Ubiquitous si intende la diffusione di dispositivi

informatici intelligenti, facilmente accessibili e talvolta invisibili (integrati

nell’ambiente), il cui uso semplifica lo svolgimento dei normali compiti di tutti i

giorni. L’utente non ha bisogno di portare dispositivi con sé, in quanto

l’informazione potrà essere accessibile dappertutto e in qualsiasi momento.

Costituiti da un insieme di dispositivi fissi e mobili, per la maggior parte special-

purpose (sensori intelligenti, controllori di elettrodomestici, dispositivi agganciati

alle cartelle cliniche,…) connessi tra loro attraverso collegamenti intermittenti, le

cui applicazioni vivono in un contesto tipicamente dinamico.

1.3 Problematiche relative ai sistemi mobili

L’evoluzione dei sistemi di elaborazione negli ultimi trent’anni ha visto il passaggio

graduale da sistemi di elaborazione monolitici, con grosse capacità di elaborazione, a

sistemi costituiti da più unità, o nodi, con capacità elaborative più o meno ridotte.

L’evoluzione architetturale è sempre stata legata da una corrispondente evoluzione nelle

tecniche di programmazione. A partire dai primi modelli architetturali distribuiti, come il

client-server, la necessità del programmatore era quella di poter accedere e usare i servizi

in remoto, in modo trasparente, come se stesse usando risorse residenti sulla sua

macchina. Al crescere del livello di distribuzione e mobilità corrispondono nuovi

paradigmi di programmazione: Distributed Object, prima, Distributed Component Object,

poi, fino ad un modello di programmazione orientato ai servizi.

Altro aspetto da considerare è il legame esistente, in proporzione inversa, tra il crescente

numero dei nodi costituenti un sistema distribuito e le capacità elaborative degli stessi.

Infatti, se da una parte la tecnologia ci permette di avere macchine general-purpose con

crescenti capacità elaborative, oggi non è difficile trovare sistemi distribuiti costituiti da

nodi con ridotte capacità e special-purpose. Basti pensare alle reti spontanee, wireless,


7

costituite da PC e PDA. Un caso estremo è quello di reti molto estese e fitte, capaci di

vivere anche in ambienti ostili, come le Wireless Sensor Network [5].

Sotto questi aspetti, le problematiche generalmente caratterizzanti un sistema distribuito

sono esaltate quando si affronta lo sviluppo di applicazioni per sistemi mobili.

Le applicazioni dovrebbero essere portabili su diverse piattaforme harware/software e

funzionare su reti eterogenee. Per garantire tale flessibilità è necessario che le applicazioni

progettate per ambienti mobili riescano a tener fronte a caratteristiche di [6]:

o Eterogeneità: i sistemi mobili sono fortemente eterogenei secondo diversi assi:

hardware dei dispositivi, software di base e linguaggi di programmazione,

tecnologie di comunicazione senza filo.

o Adattamento, le applicazioni devono poter essere semplicemente estese a fronte

di cambiamenti nei requisiti funzionali o adattate alle nuove tecnologie emergenti.

o Scalabilità: i sistemi mobili, specialmente i sistemi ubiquitous, sono caratterizzati

dalla presenza di un gran numero di dispositivi. Le soluzioni devono essere pensate

per introdurre un carico che cresca linearmente al crescere del numero di unità di

elaborazione.

o Condivisione di risorse: l’accesso a dati condivisi sensibili richiede la gestione di

transazioni e la garanzia dell’accesso in sicurezza.

o Tolleranza ai guasti: l’abilità di recuperare da condizioni di malfunzionamento

senza pregiudicare il funzionamento dell’intero sistema. Nei sistemi mobili la

problematica è inasprita dalla presenza di collegamenti inaffidabili.

o Gestione delle informazioni di contesto: la dinamicità del contesto richiede

spesso alle applicazioni di reagire a variazioni dello stesso.

o Scarse capacità: lo sviluppo deve portare in conto le ridotte capacità elaborative e

di memoria dei dispositivi mobili rispetto ai dispositivi fissi. Inoltre, è necessario

tenere presente il limitato tempo di vita del dispositivo, dovuto all’alimentazione a

batterie.


8

Di fronte ad uno scenario così vasto ed eterogeneo, su più assi (hardware, software,

connessione), emerge la chiara necessità di avere a disposizione, nello sviluppo di

applicazioni, soluzioni e strumenti che facilitino l’integrazione dei servizi in contesti

applicativi, nuovi o già esistenti.

Le soluzioni sono molteplici e verranno analizzate nel capitolo successivo.

1.4 Scenari applicativi

I dispositivi mobili, e i relativi servizi, trovano larga diffusione nei contesti più disparati,

dall’ufficio ai siti più ostili. Gli scenari applicativi per gli ambienti mobili vanno così

moltiplicandosi. Di seguito ne elenchiamo alcuni.

o Domotica (case intelligenti) [7], il termine è un neologismo nato dalla fusione

delle parole domus (casa, in latino) e informatica e indica l’insieme delle scienze e

delle tecniche mirate alla automazione degli ambienti lavorativi o degli spazi in cui

si vive. Basti pensare a quanti oggetti elettronici riempiono le nostre case, senza

essere connessi tra loro. Aggiungiamo ai comuni elettrodomestici anche uno o più

dispositivi mobili. Lo scenario presenta il limite che ogni oggetto lavora in moto

autonomo, ma il passo successivo all’invasione deve essere quello

dell’interconnessione. Un esempio banale potrebbe essere il forno elettrico che

genera un sms di alert, destinato al nostro palmare, quando ha terminato la cottura.

Allo stesso modo potrebbe agire la lavatrice al termine di un lavaggio. Si pensi ora

ad un’estensione del classico termostato, ovvero ad un sistema centralizzato che

controlli il riscaldamento raccogliendo le temperature misurate da una rete di

sensori wireless, distribuiti opportunamente secondo le diverse fonti di calore. Ciò

potrebbero consentire un risparmio energetico, nonché garantire una temperatura

omogenea in tutto l’ambiente.


9

o Automazione di ufficio, indica comunemente l’insieme del software necessario al

lavoro d’ufficio. Negli ambienti mobile posso avere la necessità di accedere da

dispositivi mobili a dati residenti su un server oppure ad un servizio di stampa. E’

un caso di interfacciamento con periferiche esterne. Il dispositivo mobile deve

essere in grado, da solo o grazie ad un ulteriore servizio di discovery remoto, di

individuare la periferica più congeniale al servizio richiesto, oltre che quella più

vicina.

o Gestione di situazioni di emergenza (comunicazione in un sito disastrato), il

mobile in taluni casi può aiutare le forze di soccorso a tenersi in contatto. Si pensi

ad una squadra di soccorso, costretta a dividersi e chiamata ad intervenire in

condizioni di scarsa visibilità. E’ indispensabile conoscere la posizione degli altri

componenti della squadra. Dotando ciascun membro della squadra di un

dispositivo mobile opportuno, si possono coordinare meglio le azioni di soccorso.

Il mobile può aiutare anche ad individuare velocemente luoghi e persone da

raggiungere qualora siano in possesso di un dispositivo mobile in grado di

segnalare la propria presenza.

o Interventi subacquei o sottomarini, si tratta di un caso simile al precedente i cui i

membri della squadra non possono né vedersi né comunicare via voce. Oltre alla

capacità di individuare i dispositivi mobili della squadra, il dispositivo mobile

potrebbe essere dotato di un servizio di messaggistica istantanea che permetta ai

sub di scambiarsi delle informazioni. Nel caso in cui si tratti di una squadra di

palombari, si potrebbe pensare ad una comunicazione vocale su protocollo IP.

o Gestione e coordinamento del traffico di veicoli, si pensi a località in cui il

traffico automobilistico è estremamente variabile. Più che avere un sistema

semaforico a tempo prefissato una tantum, potrebbe essere utile adottare una

gestione dinamica dei timer del sistema semaforico attraverso una rete di sensori


10

che prendono informazioni, sul traffico in tempo reale, a partire dalle quali,

autonomamente, settano i timer dei semafori. E’ necessaria la sincronizzazione

dati, oltre che l’accesso ad un database.

o Guide su terminali intelligenti, si pensi ad un museo in cui all’ingresso venga

fornito ad ogni gruppo di persone un palmare. Se in tale ambiente è presente un

servizio di positioning, è possibile offrire una guida che fornisce documenti

audio/video riguardante l’opera di fronte alla quale il turista di volta in volta si

ferma. In ambito ospedaliero possiamo avere la stessa applicazione: si pensi al

dottore che passa tra i pazienti con un palmare alla mano. Se in ogni stanza è

presente un sensore che rivela la presenza del palmare e trasferisce verso di esso le

informazioni relative ai ricoverati, memorizzate presso un database centrale, il

dottore avrà sempre i dati aggiornati relativi al paziente. In tal caso, è resa più

semplice anche la manutenzione e l’aggiornamento delle informazioni di tutti i

malati. Il dottore stesso dal suo palmare può modificare le informazioni presenti

nel database centrale.

Dagli scenari applicativi emergono diversi servizi in uso su dispositivi mobili. Il

dispositivo mobile può essere specifico per un certo compito, ma spesso, su dispositivi

general-purpose, si ha la coesistenza, nonché la collaborazione, tra i diversi servizi.

Emerge anche la collaborazione tra diversi dispositivi mobili. Teniamo una breve

panoramica di alcuni servizi comunemente in uso in ambienti mobili:

o Positioning è un servizio per la localizzazione del dispositivo mobile in un

ambiente fisico indoor. Per fornire tale servizio è possibile utilizzare

indistintamente la tecnologia Bluetooth oppure la tecnologia Wireless. L’ambiente

indoor nel quale si intende localizzare la posizione del dispositivo deve essere

opportunamente cablata con Access Point Wireless o Bluetooth.


11

o GPS è un servizio di localizzazione di un dispositivo in un ambiente fisico outdoor

attraverso le sue coordinate GPS. Il dispositivo mobile (solitamente un palmare)

che usa tale servizio deve necessariamente essere dotato di un dispositivo GPS

integrato o deve essere in grado di interfacciarsi con un dispositivo GPS esterno.

Esiste uno standard, NMEA che, in generale, permette interfacciamento tra

apparecchiature digitali, adottato anche da diversi dispositivi GPS.

o Sincronizzazione dati è un servizio di sincronizzazione di email, contatti ed

appuntamenti tra dispositivi. SyncML è il protocollo standard per la

sincronizzazione delle informazioni tra dispositivi.

o Accesso DB è un servizio per l’accesso ad un generico database di informazioni,

residente o esterno al dominio di connessione del nostro nodo mobile.

o VoIP (Voice over IP) è un servizio di telefonia sul protocollo IP. Il dispositivo

mobile diviene un client con la capacità di effettuare e ricevere chiamate attraverso

la rete Internet senza ricorrere a tecnologie GPRS/GSM/UMTS. La tecnologia

VoIP richiede due tipologie di protocolli di comunicazione in parallelo, il primo

riguarda il trasporto dei dati, mentre l’altro protocollo riguarda la codifica della

segnalazione della conversazione, per cui sono possibili diversi protocolli

alternativi.

o IM (Instant Messaging) è un servizio di messaggistica istantanea e presenza. Il

dispositivo mobile diviene un client in grado di scambiare messaggi real-time con

altri dispositivi.

o Interfacciamento periferiche esterne (ad esempio, stampanti Bluetooth) è un

servizio che intende offrire un’interfaccia standard di comunicazione con

periferiche esterne e non integrate nel dispositivo mobile, come ad esempio


12

stampanti Bluetooth e videocamere wireless. Si può pensare di accedere tramite il

proprio dispositivo mobile ad un servizio di video-sorveglianza che, per esempio,

offre la possibilità di monitorare un’area attraverso una videocamera remota.

o Gestione canale SMS per notifiche ed alert è un servizio che intende offrire la

possibilità di inviare messaggi di testo SMS al fine di effettuare delle notifiche e

generare degli alert. Per usufruire di tale servizio è necessario che il dispositivo

mobile sia dotato di una scheda GSM o di un modem GPRS.

1.5 Conclusioni

In questa ottica si inserisce la necessità di creare soluzioni che facilitino l’integrazione dei

servizi già esistenti su terminali fissi con i servizi emergenti del mobile computing.

Per le problematiche sopra esposte, progettare e sviluppare per il mondo del mobile

computing richiede di portare in conto una serie di requisiti non funzionali.

Alcune delle caratteristiche tipiche dei dispositivi mobili possono sembrare sgradite, in

realtà sono necessarie. Si pensi alla connessione intermittente che richiede una gestione

specifica se vogliamo realizzare, per esempio, un’applicazione che acceda alla rete; in

realtà, essa risulta indispensabile al fine di garantire un buon lifetime e preservare le

batterie del dispositivo stesso.

Inoltre, non è difficile pensare che alcuni servizi si estendano dai terminali fissi a quelli

mobili. Per esempio, non è certo possibile gestire un database con DBMS Oracle

facendolo risiedere su un palmare, ma la soluzione può andare in due direzioni:

1. se il database avrà dimensioni contenute, si può ricorrere ad un database più

rudimentale e di facile processazione, come un database testuale;

2. se viceversa è necessario garantire vincoli di integrità in modo stretto, o condividere

le tabelle con più utenti, o le dimensioni non consentono di risiedere sul palmare,

allora sarà necessario far risiedere il database su un server remoto fisso a cui

accedere con le proprie query.


13

La soluzione, per rendere facile l’uso e lo sviluppo di applicativi nel mondo mobile

richiede la presenza di un framework che offra servizi di trasparenza al programmatore,

prima, e all’utente, poi. Esso dovrà rispettare, oltre alle caratteristiche comuni dei

middleware per sistemi distribuiti tradizionali, caratteristiche di adattamento ai contesti

mobili e capacità ulteriori di dinamicità e recupero dell’errore e di guasti.

Inoltre, sarà il framework stesso ad inglobare, gestire e interagire direttamente con i servizi

di cui ha bisogno tanto il semplice utilizzatore quanto lo sviluppatore di applicazioni

complesse. Precisamente, tramite la parte del framework, che possiamo chiamare

Framework Core, potremo accedere ai servizi richiedendone l’esecuzione o la

collaborazione con altri servizi.

Nel mobile computing nessun dispositivo possiamo dire che appartenga ad un dominio

specifico. Si richiede allora al middleware la capacità di rilevare nuovi dispositivi mobili

presenti nel suo dominio di appartenenza e tener traccia di essi, nonché un sistema di

comunicazione in grado di esporre e di far scambiare dati e servizi presenti nel dominio di

cui momentaneamente fanno parte.

Ne parleremo approfonditamente nel capitolo successivo.

Capitolo 2. Soluzioni Middleware per il mobile computing

14

2. Soluzioni Middleware per il mobile computing

Esamineremo qui le caratteristiche comuni alle soluzioni middleware nell’ambito dei

sistemi distribuiti tradizionali e passeremo poi alle soluzioni relative al mondo del mobile

computing, esaminandone differenze e peculiarità.

2.1 Aspetti comuni dei Middleware

Un middleware è uno strato software interposto tra il sistema operativo e le applicazioni

(Figura 2.1), in grado di fornire le astrazioni ed i servizi utili per lo sviluppo di

applicazioni distribuite. Questo strato software permette di risolvere i problemi di

eterogeneità, che nascono dall’utilizzo di diverse macchine hardware, diversi protocolli e

infrastrutture di rete, diversi sistemi operativi e diversi linguaggi di programmazione.

Il middleware si interpone tra i sistemi operativi e le applicazioni, fornendo un’interfaccia

di programmazione di alto livello e nascondendo i servizi del sistema operativo di rete

sottostante, in maniera tale che gli sviluppatori di applicazioni abbiamo una vista

omogenea dei livelli sottostanti [2], similmente come accade con JVM (Java virtual

machine) che, compensando al gap semantico dei diversi linguaggi macchina, cerca di

offrire un livello semantico uniforme agli sviluppatori.

Lo strato middleware offre ai programmatori di applicazioni distribuite librerie di

funzioni, o middleware API (Application Programming Interface), in grado di mascherare

i problemi dovuti all’eterogeneità dei sistemi su rete [9].


15

Figura 2.1 - Middleware nello stack architetturale

Le middleware API si collocano ai livelli “Sessione” e “Presentazione” dello stack

ISO/OSI e semplificano lo sviluppo di applicazioni distribuite sia fornendo un’interfaccia

di programmazione di alto livello sia utilizzando (e nascondendo) i servizi del sistema

operativo di rete sottostante [2] [9].

Il middleware maschera le eterogeneità dei sistemi distribuiti mediante meccanismi di [8]:

o trasparenza del sistema operativo;

o trasparenza del linguaggio di programmazione;

o trasparenza della locazione (location transparency);

o trasparenza della migrazione (migration transparency);

o trasparenza ai guasti (failure transparency);

o trasparenza della replicazione (replication transparency);

o trasparenza delle implementazioni commerciali.


16

2.2 Differenze tra Middleware per sistemi tradizionali e per sistemi mobili

I middleware per ambienti mobili condividono, almeno nella loro parte core, gli stessi

requisiti non funzionali dei sistemi distribuiti tradizionali, anche se alcuni di essi vanno

rivisti in ragione delle variate circostanze in cui ci si trova ad operare.

La scalabilità del sistema deve essere relativa all’abilità di servire un ampio numero di

dispositivi mobili in modo efficiente; l’eterogeneità è complicata dal fatto che sono

presenti differenti collegamenti (o link) di rete (wireless/fissi) e che molte tecnologie e

dispositivi wireless possono coesistere nello stesso ambito di rete. La gestione dei guasti

può dipendere dal tipo di applicazione, ma, in generale, le disconnessioni potrebbero non

essere un malfunzionamento o un’eccezione, bensì un requisito funzionale.

Per ciò che riguarda i requisiti non funzionali alla base dello sviluppo di middleware per

ambienti mobili, essi cambiano rispetto a quelli per ambienti distribuiti tradizionali. In

particolare, i punti di divergenza che spingono nella ricerca di nuove soluzioni risultano

essere [10]:

o Carico computazionale: il tipo di carico computazionale introdotto dai

middleware classici è tipicamente heavy-weight (richiede una grossa quantità di

risorse per fornire servizi alle applicazioni soprastanti), contrariamente al carico

light-weight richiesto dai middleware per ambienti mobili, data la presenza di

dispositivi con capacità limitate.

o Paradigma di comunicazione: i middleware classici assumono, come base per il

loro corretto funzionamento, la presenza di connessioni stabili e permanenti tra i

nodi di rete e di conseguenza adottano un paradigma di comunicazione di tipo

sincrono in cui si richiede accoppiamento temporale tra client e server (ovvero

client e server devono essere contemporaneamente presenti durante la loro

interazione). Viceversa, negli ambienti in cui i dispositivi mobili possono

volontariamente o meno connettersi al sistema e in cui dispongono di scarsa banda,

un paradigma di comunicazione sincrono deve inevitabilmente lasciare posto ad un


17

paradigma di comunicazione asincrono, in cui non è richiesto che client e server

siano connessi simultaneamente.

o Adaptation delle applicazioni: l’adaptation consiste nell’insieme di strategie da

applicare per adattare il comportamento delle applicazioni al contesto di

esecuzione. Diversamente dai sistemi distribuiti tradizionali, i sistemi distribuiti

mobili vivono in un contesto di esecuzione estremamente dinamico: la larghezza di

banda potrebbe non essere stabile, i servizi che sono disponibili in un istante

possono non esserlo l’istante successivo, per cui un approccio di adattamento

context aware, anziché uno application transparent, può essere preferito; con il

primo approccio le informazioni sul contesto di esecuzione, o parte di esso, e le

decisioni da effettuare a valle dei suoi mutamenti sono carico delle applicazioni.

Con il secondo approccio tutte le informazioni circa il contesto sono tenute

nascoste all’interno del middleware e rese trasparenti alle applicazioni.

Possiamo, allora, ricapitolare le caratteristiche dei middleware (MW) per sistemi

distribuiti tradizionali e per i sistemi mobili:

MIDDLEWARE CARICO COMUNICAZIONE CONTESTO

Sistemi Distribuiti Tradizionali

Pesante (dispositivi fissi e potenti)

Sincrona (connessione permanente)

Statico (il MW nasconde i dettagli sul contesto di esecuzione)

Sistemi Mobile Computing

Leggero (dispositivi mobili e poco potenti)

Asincrona (connessione intermittente)

Dinamico (le applicazioni prendono decisioni strategiche)

Tabella 2.1 – Caratteristiche principali dei middleware per sistemi distribuiti tradizionali e per sistemi mobile computing

Esempi di middleware per sistemi distribuiti tradizionali sono:

o Remote Procedure Call - RPC (SunRPC) [11];

o Distributed Objects Middleware – DOM (Sun RMI [12], OMG CORBA [13]);

o Message Oriented Middleware – MOM (IBM MQSeries);

o Transaction Processing – TP (X/Open DTP) [14].


18

2.3 Middleware per sistemi mobili

2.3.1 Middleware tradizionali adattati al Mobile Computing

L’obiettivo è quello di rendere le applicazioni in esecuzione su dispositivi mobili

interoperabili con i sistemi fissi esistenti, tipicamente con riferimento ai sistemi nomadici.

Generalmente per adattare middleware pensati per sistemi distribuiti classici ad ambienti

mobili, si cerca di ridurre il più possibile le “dimensioni” del middleware, in termini di

risorse richieste (memoria, calcolo, banda), introdurre il supporto alle disconnessioni e alla

gestione degli handoff [10] [15].

2.3.1.1 Wireless CORBA

Un esempio di middleware adattato è wireless CORBA (wCORBA). Esso è l’adattamento

della specifica OMG CORBA agli ambienti mobili [16].

Le specifiche OMG wireless CORBA hanno l’intenzione di definire un’evoluzione del

middleware CORBA che possa essere utilizzato per lo sviluppo di applicazioni utente in

situazioni di nomadic computing. Le specifiche di wCORBA pongono in risalto la

soluzione di problemi tipici come la limitazione delle risorse sugli apparati mobili

(memoria e potenza computazionale), la natura discontinua dei collegamenti wireless e

soprattuto la gestione degli handoff.

Ipotizziamo uno scenario in cui su un terminale mobile è in esecuzione un’applicazione

utente CORBA che intende comunicare via ORB con altre applicazioni ubicate su reti

fisse o wireless.


19

Figura 2.2 - I domini ORB e gli oggetti di servizio nell’architettura wCORBA

Il terminale mobile si interconnette con altri elaboratori tramite una rete wireless e può

spostarsi nello spazio attraversando varie zone di copertura del segnale radio. Piuttosto che

ad una suddivisione in celle spaziali, nell’architettura wCORBA si pensa ad una

suddivisione in vari domini ORB, in analogia ai sistemi di telecomunicazione cellulare:

1. Home domain è il dominio amministrativo di riferimento del dispositivo mobile e

ospita l’oggetto di servizio HomeLocationAgent. È qui che viene conservata, e

continuamente aggiornata, l’informazione sulla locazione (variabile nel tempo) del

terminale mobile che, spostandosi, può visitare differenti altri domini. In genere, lo

HomeDomain è costituito dagli ORB ubicati sulla rete fissa;

2. Terminal domain è la parte di infrastruttura residente sul dispositivo mobile. In

tale dominio si trova l’oggetto di servizio Terminal Bridge. Tutte le invocazioni

CORBA passano per un’unica interfaccia di uscita, appunto il Terminal Bridge,

che comunica (via GIOP Tunneling) con la sua controparte fissa, l’Access Bridge,

e, quindi, con gli oggetti di altri domini;

3. Visited domain è il dominio correntemente visitato dal terminale mobile. Per

dominio visitato si intende quello i cui oggetti vengono utilizzati dal terminale


20

mobile. Qui si trova almeno un oggetto di servizio Access Bridge che fornisce agli

oggetti sul terminale mobile la possibilità di accedere agli oggetti degli altri

domini, inoltrando sulla rete fissa le richieste pervenute dal Terminal Bridge. In

genere, anche il Visited Domain è costituito da ORBs ubicati sulla rete fissa.

Il GIOP Tunneling è il modo utilizzato per fornire ad un terminale mobile un canale di

comunicazione da e verso la rete fissa. Il tunnel viene usato per trasmettere i messaggi

GIOP fra il TerminalBridge e l’AccessBridge sopra la rete wireless.

Il Mobile IOR è un particolare Interoperable Object Reference (IOR) capace di

nascondere la mobilità di un oggetto servente ubicato sul terminale mobile a quei client

che ne invocano le operazioni. Il Mobile IOR fornisce ai client la proprietà di “trasparenza

dalla mobilità” in un modo che è esso stesso trasparente all’ORB del client. Di

conseguenza, all’ORB del client sulla rete fissa non è richiesto di implementare le

specifiche wCORBA affinché sia possibile per quel client invocare operazioni

dell’oggetto sul terminale mobile.

2.3.1.2 Alice

Alice (Architecture for Location Independent CORBA Environments) [17] abilita la

comunicazione su canali wireless via IIOP (Internet Inter-ORB Protocol) e aggiunge un

livello di sessione che prevede la connessione dei terminali mobili a dei Mobility Gateway

(proxy per i clienti mobili). L’architettura di Alice permette sia agli oggetti client che agli

oggetti server di risiedere su dispositivi mobili senza affidarsi ad un sistema centralizzato

di registrazione che tenga traccia dei loro movimenti. Allo stesso modo dell’Access Bridge

di wCORBA, per accedere ad una rete IP fissa, su di essa deve essere situato un Mobility

Gateway. In questo modo la comunicazione tra i dispositivi mobili e la rete fissa avviene

comunque via IIOP in modo del tutto trasparente.

L’architettura consiste essenzialmente di tre livelli:

o Il Mobile Layer (ML) è il livello più basso e fornisce il supporto alla mobilità

indipendentemente da CORBA e IIOP;


21

o Lo IIOP Layer implemeta il protocollo IIOP indipendentemente dalla mobilità;

o Lo Swizzling IIOP (S/IIOP) fornisce al livello IIOP il supporto richiesto qualora

l’oggetto server risieda su un terminale mobile.

2.3.1.3 Dolmen

Dolmen [18] usa il concetto di bridging per connettere i dispositivi mobili a reti fisse. In

particolare, Dolmen implementa due half-bridges, uno residente su un terminale mobile e

l’altro su un Access Point noto, uno per ogni dominio mobile presente nella rete fissa.

Questo approccio permette l’indirizzamento dei terminali mobili, oltre a rispondere a

questioni relative alle performance e all’affidabilità.

Dolmen introduce LW-IOP (Light-Weight Inter-ORB Protocol). Si tratta di una versione

“leggera” di IIOP. Il protocollo LW-IOP supporta le stesse funzionalità del protocollo

GIOP, ma il set di messaggi e la loro rappresentazione risulta essere più efficiente.

Le principali caratteristiche del protocollo LW-IOP sono le ridotte dimensioni della

struttura e degli headers dei messaggi rispetto a GIOP, oltre che una codifica più

compatta, al fine di evitare le trasmissioni continue.

Inoltre, LW-IOP effettua:

o il caching dei dati non inviati e particolari schemi di acknoledgement per gestire le

disconnessioni temporanee;

o la gestione dinamica di nomi e locazioni degli host, attraverso un servizio dei

nomi.

2.3.2 Middleware creati Ad-Hoc per Mobile Computing

2.3.2.1 Context-aware middleware

I context-aware middleware si basano sull’idea di fornire alle applicazioni meccanismi di

adattamento al contesto di esecuzione fortemente variabile che caratterizza i sistemi

mobili [19].


22

Il contesto di esecuzione include [2] [19]:

o Locazione: posizione logica (dominio) e fisica (determinata da un sistema di

positioning) del dispositivo;

o Prossimità: posizione relativa di altre risorse (stampanti, DB);

o Caratteristiche di dispositivo: capacità elaborative, periferiche di input (touch

screen, tastiera cellulare);

o Ambiente fisico: livello di luminosità, di rumore, banda di rete;

o Attività utente: a guida di un’automobile, su treno, a teatro, ecc.

Alcuni middleware context-aware si basano sul principio, non nuovo, della reflection [2]

(“Principio che consente ad un programma di accedere, ripensare e modificare la propria

interpretazione” - B. Smith, 1982). Un sistema reflective può modificare sè stesso

attraverso un’ispezione, ovvero un esame del comportamento interno, che deve essere

esposto all’applicazione, ed un adattamento, ovvero il comportamento interno può essere

cambiato aggiungendo nuove caratteristiche o modificando quelle esistenti. Un reflective

middleware incorpora solo le funzionalità di base (dimensioni e carico ridotti); sarà

l’applicazione che monitora e adatta il comportamento del middleware alle proprie

esigenze.

Esempi di context-aware middleware sono OpenORB, OpenCORBA, dynamicTAO che

sono middleware tradizionali estesi con il concetto di reflection (reflective middleware).

OpenORB [19] è un reflective middleware sviluppato dalla Lancaster University. L’idea

di OpenORB è di estendere alla progettazione del middleware il concetto legato al

modello di programmazione a componenti. Nella pratica un’istanza di OpenORB è una

particolare configurazione di componenti, selezionati a tempo di progettazione e

modificati a runtime. La reflection è usata per fornire l’accesso alla piattaforma

sottostante, ovvero la struttura a componenti; ogni componente offre una meta-interfaccia


23

che permette l’accesso al sottostante meta-space, ovvero all’ambiente di supporto per il

componente stesso.

OpenCORBA [19] permette agli utenti di adattare dinamicamente le politiche di

rappresentazione e di esecuzione dell’ORB, visto come un bus software. OpenCORBA

fornisce, a tal scopo, le meta-classi e un protocollo che abiliti l’adattamento delle meta-

classi a run-time, in modo che sia possibile cambiare le proprietà di una classe. Grazie a

questo meccanismo è possibile introdurre una nuova semantica al modello come la

sicurezza e la replicazione.

DynamicTAO [19] costituisce un’estensione del middleware TAO, conforme alla

specifica CORBA, che fa uso del pattern Strategy per incapsulare differenti aspetti della

tecnologia ORB. TAO contiene un file di configurazione sulla base del quale specifica le

strategie che l’ORB userà per implementare aspetti come la concorrenza, il

demultiplexing, lo scheduling e la gestione della connessione. All’inizializzazione

dell’ORB, viene effettuato il parsing di tale file e la strategia selezionata viene caricata.

DynamicTAO, quindi, estende TAO con il supporto alla configurazione on-the-fly per

permettere all’ORB di cambiare strategia senza la necessità di far ripartire la sua

esecuzione. DynamicTAO è un reflective middleware appunto perché permette l’ispezione

e la riconfigurazione della strategia adottata.

Altro esempio è Gaia [2] che definisce il concetto di Active Space, dove servizi, utenti,

dati e locazioni sono rappresentati e manipolati dinamicamente e in coordinazione. L’idea

di tale soluzione è ottenere un sistema in grado di localizzare i dispositivi all’interno di

uno spazio fisico, rilevare spontaneamente quando i nuovi dispositivi vi entrano, ed

adattare il contenuto e il formato delle informazioni alle risorse del dispositivo.


24

2.3.2.2 Data sharing-oriented middleware

I data sharing-oriented middleware [20] offrono il supporto alle disconnected operations,

cercando di massimizzare la disponibilità nell’accesso ai dati attraverso il concetto di

replica.

Le soluzioni esistenti differiscono nel modo in cui viene gestita la consistenza tra le

repliche, ovvero nel modo in cui vengono individuati e risolti i conflitti che avvengono

naturalmente nei sistemi mobili.

Un esempio è CODA [19] che offre l’astrazione di file system distribuito: i dati sono

memorizzati in appositi server distribuiti. Inoltre fornisce la replicazione dei server per la

gestione di eventi di guasto dei nodi di rete e il caching per il supporto alle operazioni

disconnesse. Si basa sulla presenza di un’infrastruttura fissa dove allocare fisicamente i

server.

Un altro è XMiddle [20] che consente ai dispositivi mobili di condividere dati finchè sono

connessi, o di replicare i dati ed effettuare operazioni su di essi, mentre sono disconnessi. I

dati sono organizzati in strutture ad albero. Gli alberi sono, a loro volta, l’unità base di

condivisione e replicazione, infatti i dispositivi mobili possono scambiarsi informazioni

condividendo rami di albero. Essi possono replicare un albero o un ramo di albero a

seconda delle esigenze e le capacità elaborative. Da ciò viene la peculiarità più importante:

non esigono la presenza un’infrastruttura fissa.

2.3.2.3 Tuple space middleware

In ultimo ci sono anche i tuple space middleware (TS) che si basano sul modello dello

spazio di tuple. In questo modello le interazioni tra processi sono tipicamente di tipo

asincrono. Lo spazio delle tuple può essere considerato uno spazio di memoria associativa

(accesso per tipo e contenuto, non per indirizzo) [2].


25

La lettura richiede una tupla-modello (pattern), da confrontare con le tuple presenti nello

spazio. Il modello è tornato di una certa attualità con la moderna tecnologia JavaSpace, su

cui è basata anche la tecnologia Jini.

Un esempio è Lime [2], la versione di Linda per sistemi mobili, uno dei primi sistemi

classificabili come middleware. In Linda la comunicazione tra applicazioni ha luogo

attraverso l’astrazione di uno spazio virtuale di memoria condiviso; due applicazioni

possono sincronizzarsi e scambiarsi dati inserendo/prelevando dati (le tuple) dallo spazio

virtuale.

Il modello TS è adatto per realizzare sistemi Service-Oriented Architecture (SOA).

Nell’ambito dell’informatica, con la locuzione inglese di Service-Oriented Architecture

[21] viene indicata un’architettura software atta a supportare l’uso di servizi Web per

soddisfare le richieste degli utenti così da consentire l’utilizzo delle singole applicazioni

come componenti del processo di business.

Un’architettura SOA è progettata per il collegamento a richiesta di risorse computazionali

(principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti che

possono essere utenti finali o altri servizi. L’OASIS (Organization for the Advancement of

Structured Information Standards) definisce l’architettura SOA così:

Un paradigma per l’organizzazione e l’utilizzazione delle risorse distribuite che possono

essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per

offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti

consistentemente con presupposti e aspettative misurabili.

Anche se esistono molteplici definizioni di SOA, solo il gruppo OASIS ha prodotto una

definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali.


26

I componenti di una piattaforma SOA sono:

o il servente (Service Provider), che offre i servizi e provvede alla loro

registrazione;

o il cliente (Service Consumer), che consuma i servizi e ne fa, eventualmente, la

ricerca;

o il catalogo dei servizi (Service Broker), che espone l’interfaccia dei servizi,

permettendo, da un lato, la ricerca degli stessi, dall’altro, l’aggiunta dei nuovi.

2.4 Web Services

Il modello SOA trova una sua diffusa implementazione nei Web Services (WS).

“A Web service is a software system designed to support interoperable machine-to-

machine interaction over a network. It has an interface described in a machine-

processable format (specifically: WSDL). Other systems interact with the Web service in a

manner prescribed by its description using SOAP messages, typically conveyed using

HTTP with an XML serialization in conjunction with other Web-related standards.”

[W3C Working Group – February 11, 2004]

Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service

(servizio Web) è un sistema software progettato per supportare l’interoperabilità tra

diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service

è quella di offrire un’interfaccia software (descritta in un formato automaticamente

elaborabile quale, ad esempio, il Web Services Description Language - WSDL)

utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le

operazioni descritte nell’interfaccia tramite appositi “messaggi” inclusi in un pacchetto

SOAP: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati

secondo lo standard XML.


27

Proprio grazie all’utilizzo di standard basati su XML tramite un’architettura basata sui

Web Services, le applicazioni software scritte in diversi linguaggi di programmazione e

implementate su diverse piattaforme hardware possono essere utilizzate.

L’interoperabilità si realizza tramite le interfacce che queste applicazioni “espongono”

pubblicamente e mediante l’utilizzo dei “servizi” che mettono a disposizione per lo

scambio di informazioni e l’effettuazione di operazioni complesse (quali, ad esempio, la

realizzazione di processi di business che coinvolgono più aree di una medesima azienda)

sia su reti aziendali come su Internet: la possibilità dell’interoperabilità fra diversi

software (ad esempio, tra Java e Python) e diverse piattaforme hardware (come Windows

e Linux) è resa possibile dall’uso di standard open-source.

Il consorzio OASIS ed il W3C sono i principali responsabili dell’architettura e della

standardizzazione dei Web Services; per migliorare l’interoperabilità tra le diverse

implementazioni dei Web Services, l’organizzazione WS-I sta inoltre sviluppando una

serie di “profili” per meglio definire gli standard coinvolti.

I concetti chiave dei Web Services sono:

o Riuso: un Web Service può essere visto come un componente software riusabile,

sviluppato da un entità per se stessa o a favore di altre entità;

o Interoperabilità, ottenuta attraverso l’uso esteso di XML;

o Componibilità: possono essere facilmente utilizzati, in combinazione l’uno con

l’altro (indipendentemente da chi li fornisce e da dove vengono resi disponibili)

per formare servizi “integrati” e complessi.

L’architettura dei Web Services utilizza specifiche tecnologie, tutte basate su XML:

o UDDI: fornisce ai client un meccanismo di ricerca dei Web Services. Un registro

UDDI è simile ad un “CORBA trader o naming”, o ad un DNS di applicazioni.

o WSDL: definisce i servizi come una collezione di terminali di rete o porte. Ogni

porta è descritta da un indirizzo di rete; gli insiemi di porte definiscono i servizi.


28

o SOAP: fornisce un sistema standard per costruire messaggi di richiesta e le

risposte fornite dai singoli servizi. Sostanzialmente è un sistema per eseguire

chiamate RPC su una rete tramite HTTP.

Figura 2.3 - Architettura dei Web Services

Gli svantaggi legati ai Web Services sono i seguenti:

o attualmente non esistono standard consolidati per applicazioni critiche quali, ad

esempio, le transazioni distribuite;

o le performance legate all’utilizzo dei Web Services possono essere minori di quelle

riscontrabili utilizzando approcci alternativi di distributed computing quali Java

RMI, CORBA, o DCOM;

o l’uso dell’HTTP permette ai Web Services di evitare le misure di sicurezza dei

firewall (le cui regole sono stabilite spesso proprio per evitare le comunicazioni fra

programmi “esterni” ed “interni” al firewall).

Su quest’ultimo punto va fatta una precisazione. Se da un lato i Web Services non

consentono un perfetto controllo della sicurezza, dall’altro hanno guadagnato consensi

visto che, come protocollo di trasporto, possono utilizzare HTTP over TCP sulla porta 80;

tale porta è, normalmente, una delle poche (se non l’unica) lasciata “aperta” dai sistemi

firewall al traffico di entrata ed uscita dall’esterno verso i sistemi aziendali e ciò in quanto

su tale porta transita il traffico HTTP dei Web browser: ciò consente l’utilizzo dei Web

Services senza modifiche sulle configurazioni di sicurezza dell’azienda.


29

La ragione principale per la creazione e l’utilizzo di Web Services è il “disaccoppiamento”

che l’interfaccia standard esposta dal Web Service rende possibile fra il sistema utente ed il

Web Service stesso: modifiche ad una o all’altra delle applicazioni possono essere attuate

in maniera “trasparente” all’interfaccia tra i due sistemi; tale flessibilità consente la

creazione di sistemi software complessi costituiti da componenti svincolati l’uno dall’altro

e consente una forte riusabilità di codice ed applicazioni già sviluppate.

2.5 Soluzioni offerte dalla Java Community

Prima di introdurre le soluzioni proposte per il mondo mobile dalla JCP (Java Community

Process), è necessario fare una breve panoramica sull’evoluzione del mondo Java, nonché

sulla classificazione dei dispositivi mobili che essa adotta.

Il JCP promuove e sostiene lo sviluppo delle nuove specifiche Java (Java Specification

Request, JSR). I JSR sono i documenti che descrivono le specifiche proposte e le

tecnologie da aggiungere alla piattaforma Java, in altre parole di package (API) opzionali

per la JVM (Java Virtual Machine) in uso.

2.5.1 Introduzione alla piattaforma J2ME

La prima versione di Java era prevalentemente dedicata alla realizzazione di applicazioni

desktop in quanto disponeva solamente delle API per la costruzione di GUI e per la

realizzazione delle Applet. Nella versione 1.02 del JDK, le API Java DataBase

Connection (JDBC) per l’accesso ad un DataBase Management System (DBMS) non

esistevano ancora [22]. La JVM era caratterizzata da un elevato utilizzo delle risorse del

particolare sistema operativo; basti pensare alle Abstract Windows Toolkit (AWT) che

permettono di delegare la creazione degli elementi di una interfaccia grafica ai

corrispondenti elementi del particolare sistema operativo con conseguenti notevoli

limitazioni alla tanto invocata portabilità di Java. Un’applicazione realizzata in Java non

doveva solamente poter essere eseguita in JVM che girassero su sistemi operativi diversi,


30

ma doveva anche sempre apparire allo stesso modo su macchine e piattaforme diverse e

quindi possedere uno stesso Look and Feel (L&F). Con il passare degli anni Java passò da

linguaggio per la realizzazione di animazioni sul browser a linguaggio per la creazione di

servizi lato server.

L’introduzione delle servlet ha rappresentato una pietra miliare in tal senso.

Un’applicazione lato server deve possedere caratteristiche molto diverse da quelle di una

applicazione lato client: intanto dovrà favorire aspetti legati alla scalabilità ed affidabilità

rispetto a quelli legati alla realizzazione di interfacce grafiche, e inoltre dovrà prevedere la

definizione di API che permettano l’integrazione con sistemi di altro tipo come DataBase

Management System (DBMS), Message Oriented Middelware (MOM) o sistemi legacy.

E’ nata quindi l’esigenza di una specializzazione degli ambienti in cui una applicazione

Java potesse essere eseguita, che ha portato a una prima classificazione degli ambienti

Java, che prevedesse un confine di demarcazione tra quello che era l’ambiente standard

per la realizzazione di applicazioni desktop (Java 2 Standard Edition, J2SE) e quello per

l’esecuzione di applicazioni server side (Java 2 Enterprise Edition , J2EE).

L’obiettivo originario era dunque quello di poter eseguire applicazioni Java in un

qualunque sistema, ma non tutte le applicazioni sono uguali: alcune richiedono grosse

risorse di CPU, altre grandi quantità di memoria, alcune necessitano di interfacce grafiche

sofisticate mentre in altre sono sufficienti poche righe di un display per l’interazione con

l’utente.

La successiva domanda che ci si pose, soprattutto sulla spinta di un mercato in crescita

costante e progressiva, quasi esponenziale come quello dei dispositivi mobili: “Cosa fare

nel caso di ambienti con risorse limitate, con dimensioni di memoria e capacità di calcolo

ad esempio tipiche di un telefono cellulare o di un Personal Digital Assistant (PDA)?

Come possiamo eseguire un’applicazione Java all’interno di un dispositivo con simili

caratteristiche, in presenza di nuovi fattori vincolanti come il consumo della batteria o le

dimensioni del display?” [22].

Una soluzione consiste nell’eliminare il superfluo. Se volessimo eseguire un’applicazione

Java all’interno di un cellulare non avremmo sicuramente bisogno delle API per le Swing


31

in quanto le capacità grafiche non ne consentirebbero l’utilizzo, come non potremmo

sfruttare tutte le operazioni caratteristiche delle JVM utilizzate per applicazioni J2SE, dal

momento che i sistemi operativi semplificati dei dispositivi mobili non sarebbero in grado

di eseguirli, al di là del fatto che molte di tali applicazioni non avrebbero addirittura senso

in un dispositivo di quelle dimensioni.

Nasce quindi l’esigenza di un nuovo ambiente per le Midlets, le applicazioni Java pensate

Ad-Hoc per dispositivi mobili con capacità notevolmente ridotte rispetto ai desktop o ai

server: tale nuova piattaforma prende il nome di Java 2 Micro Edition (J2ME).

2.5.2 Configuration e Profile

J2ME [22] [23] descrive un insieme di ambienti per la creazione e l’esecuzione di

applicazioni Java in dispositivi di largo consumo. Si tratta di dispositivi spesso molto

diversi tra loro tra cui telefoni cellulari, Personal Digital Assistant (PDA), WebTV ed altri

ancora. Definire un ambiente J2ME significa definire:

o un insieme di JVM, ciascusa delle quali può essere utilizzata all’interno di

dispositivi con caratteristiche e limitazioni diverse;

o un insieme di API che permettano di sfruttare al meglio le caratteristiche del

dispositivo;

o un insieme di strumenti per lo sviluppo ed il deploy delle applicazioni.

Dato l’elevato numero di dispositivi presenti sul mercato, con caratteristiche molto diverse

tra loro, si è sentita la necessità di definire alcuni concetti sulla base dei quali classificare i

dispositivi non più relativamente al loro utilizzo, ma in base alle loro limitazioni in termini

soprattutto di memoria e CPU.

Sono quindi stati introdotti i concetti fondamentali di Configuration e di Profile [23].


32

Figura 2.4 - Configuration e Profile nello stack architetturale J2ME

Notiamo come ciascun dispositivo sia caratterizzato da un proprio sistema operativo che

ne implementa le funzionalità di basso livello. L’implementazione della JVM prevista per

il dispositivo dovrà quindi essere costruita ad un livello immediatamente superiore,

strettamente connesso alle funzioni esposte dal sistema operativo. La maggior parte delle

funzionalità delle JVM di questo tipo si ottengono dalla JVM classica della J2SE

eliminando le operazioni superflue o troppo onerose in termini di risorse. Queste risorse

riguardano principalmente la quantità di memoria disponibile (RAM e ROM) e la potenza

della CPU. Notiamo come queste siano caratteristiche che coinvolgono tutti i dispositivi,

indipendentemente dalla loro funzione. Possiamo dire che si tratta di grandezze che

permettono di classificare in modo orizzontale un certo insieme di dispositivi, a

prescindere da quelle che sono le caratteristiche peculiari o il target specifico di una

determinata categoria di dispositivo.

Una Configuration è la descrizione di un Java Runtime completo per una determinata

categoria di dispositivi con caratteristiche hardware simili. Essa si può considerare

composta dalle seguenti tre parti:

o una JVM in grado di eseguire del bytecode;

o l’implementazione nativa di alcune interfacce per l’interazione con il sistema

operativo su cui la JVM è in esecuzione;

o un insieme di classi core (API) standard.

Al momento, le J2ME definiscono le seguenti due Configuration [23]:

o Connected Device Configuration (CDC);


33

o Connected Limited Device Configuration (CLDC) .

Le specifiche attualmente disponibili sono relative alle versioni CLDC 1.1 (JSR-139) e

CDC 1.1 (JSR-218). Si noti che la principale differenza tra le versioni CDLC 1.0 e CDLC

1.1 è il supporto al floating point.

La CDC riguarda dispositivi che hanno disponibilità di una implementazione completa

della JVM, come definito nel documento JVM Specification 2nd Edition, e possibile

presenza di una interfaccia grafica per l’interazione con l’utente.

A questa categoria appartengono dispositivi quali telefoni abilitati al Web, sistemi di

navigazione, WebTV e molti altri ancora. Notiamo come una delle caratteristiche

fondamentali di questa Configuration sia quella relativa alla possibilità di poter supportare

una implementazione della JVM uguale a quella prevista per la J2SE e precisamente alla

versione 1.3.1. Sebbene tutte le API della J2SE possano essere gestite dalla JVM di questa

Configuration, solamente alcune saranno disponibili per ciascuna implementazione.

La CLDC si riferisce, invece, a dispositivi caratterizzati da scarse risorse elaborative e di

massa, da connettività limitata, spesso intermittente, e da interfaccia grafica ristretta o

addirittura assente.

A questa categoria appartengono dispositivi quali PDA, telefoni cellulari, palmari e molti

altri. Questa Configuration descrive lo strumento base per la scrittura delle Midlets. A

differenza della CDC, la CLDC non può disporre di una JVM completa, per cui si renderà

necessario l’utilizzo di una JVM più semplice, che è stata individuata nella KVM (Kilo

Virtual Machine). E’ importante sottolineare come la CLDC sia un sottoinsieme della

CDC. Questo ha come conseguenza il fatto che una applicazione sviluppata per la CLDC

dovrà necessariamente funzionare anche sulla CDC.

Le relazioni tra la J2SE, la CDC e CLDC [23] è espressa molto bene dalla seguente Figura

2.5:


34

Figura 2.5 - Relazioni tra la piattaforma J2SE e J2ME, CDC e CLDC

Notiamo come la CDC si possa considerare una estensione di un sottoinsieme della J2SE,

dal momento che include alcune nuove classi Ad-Hoc per dispositivi con risorse limitate

non presenti nella J2SE, e come la CLDC si possa considerare invece un sottoinsieme in

senso stretto della CDC.

L’insieme di API, costruite a partire da un minimo comune denominatore quale può essere

una stessa Configuration, che permettono di sfruttare le particolari caratteristiche di uno

specifico dispositivo, definiscono quello che si chiama Profile. Quello di Profile è un

concetto fondamentale in quanto, a livello di implementazione, rappresenta un insieme di

API e di librerie di classi, costruite sopra una determinata Configuration, che permettono

di accedere alle funzionalità caratteristiche di una determinata tipologia di dispositivi.

Normalmente il concetto di Profile risulta strettamente legato a uno specifico segmento di

mercato “verticale”, ma è possibile parlare di Profile anche per importanti gruppi di

applicazioni di un determinato settore che possono girare su dispositivi di tipo diverso:

tutte le applicazioni per dispositivi mobili devono essere scritte per un determinato Profile,

e non per un particolare dispositivo o per una configurazione. Il Profile si può considerare

il contratto tra un’applicazione e un segmento di mercato verticale.


35

Figura 2.6 - Panoramica sulle diverse piattaforme Java, con particolare attenzione agli stack J2ME

Senza addentrarci nei particolari diremo che i Profile attualmente definiti per

configurazione CDC [23] sono i seguenti:

Foundation Profile (JSR-219) definisce il profilo “di base” che:

• fornisce un set di classi minimale (supporto di rete ed I/O);

• non include il supporto per alla grafica o ad altri tipi di GUI.

Personal Basis Profile (JSR-217) definisce il profilo per lo sviluppo di applicazioni

“leggere”. Esso:

• estende il set di classi fornito con il Foundation Profile;

• include il supporto limitato, ovvero non completo, per AWT;

• fornisce supporto a runtime per JavaBeans ed Xlets.

Personal Profile (JSR-216) definisce il profilo per lo sviluppo di applicazioni “complete”.

Tale profilo:

• estende il set di classi fornito con il Personale Profile;

• include il supporto completo per AWT;

• costituisce il punto di migrazione per le tecnologie Java legaci, come IBM PersonalJava.


36

L’unico profilo definito per la configurazione CLDC è Mobile Information Device

Platform (MIDP, JSR-118).

MIDP, in combinazione con CLDC, costituisce l’ambiente di runtime per le applicazioni

Java, su dispositivi come PDA e telefoni cellulari.

MIDP provvede alle funzionalità di base necessarie alle applicazioni mobili quali:

l’interfaccia utente, la connessione di rete, la gestione dei dati sul sistema locale e la

gestione del ciclo di vita del programma.

2.5.3 Java RMI

RMI (Remot Method Invocation) [12] [24] è un’insieme di API potente, ma semplice,

che permette di sviluppare applicazioni distribuite in rete, dove le risorse sono allocate su

macchine diverse e quindi con spazio di indirizzamento diverso fra loro.

I vantaggi dell’uso di RMI sono:

o Maggiore astrazione: con RMI si ottiene in locale una rappresentazione

dell’oggetto remoto (che quindi si trova su una JVM remota) e lo si tratta a tutti gli

effetti come se si trattasse di un elemento locale. E’ RMI che gestisce tale

trasferimento occupandosi della gestione della comunicazione fino al “basso

livello” (socket). Questa astrazione permette di concentrarsi sull’applicazione e

non sui dettagli di comunicazione.

o Maggiore eleganza: una volta ottenuta la rappresentazione dell’oggetto remoto

(detto stub) sulla propria macchina, il codice necessario ad invocare un metodo

remoto è identico a quello utilizzato per un oggetto locale:

nome_oggetto_remoto.nome_metodo(lista_dei_parametri);

Da un punto di vista sintattico non vi è alcuna differenza fra un oggetto locale ed

uno remoto.


37

o Non necessita di un protocollo di definizione dei messaggi: la gestione della

comunicazione tra applicativo locale e remoto è completamente gestita da RMI

senza la necessità di doversi implementare un protocollo proprietario per tale

gestione.

o Utilizzo del paradigma ad oggetti.

Prima dell’introduzione di RMI erano già disponibili soluzioni al problema

dell’esecuzione di parti di codice in remoto, come ad esempio la Remote Procedure Call

(RPC): con questa tecnologia è possibile gestire procedure facenti parte di applicazioni

residenti in remoto rispetto al chiamante. Le RPC sono strettamente legate al concetto di

processo e di procedura e quindi male si inseriscono nel contesto del paradigma ad oggetti.

E’ questo il motivo principale che ha fatto nascere l’esigenza di una tecnologia apposita

per la gestione di oggetti ditribuiti, la quale vede in RMI la soluzione full-Java

completamente Object Oriented.

RMI si basa sull’interazione tra tre entità distinte [25]:

o uno o più server RMI;

o il Java RMI Registry (localizzato sul server);

o uno o più client RMI.

Il server RMI implementa un’interfaccia relativa ad un particolare oggetto RMI e registra

tale oggetto nel Java RMI Registry. Il Java RMI Registry è, semplicemente, un processo

di tipo daemon che tiene traccia di tutti gli oggetti remoti disponibili su un dato server. Il

client RMI effettua una serie di chiamate al registry RMI per ricercare gli oggetti remoti

con cui interagire.

Le modalità con cui un oggetto che si trova su una macchina client riesce ad invocare dei

metodi che sono definiti su un’altra macchina (server) e la gestione delle problematiche


38

legate alla comunicazione di rete dipendono da due componenti che nel diagramma

precedente sono denominati Skeleton e Stub.

Figura 2.7 - Meccanismo di funzionamento della tecnologia Java RMI

Dettagliamo il meccanismo utilizzando la medesima numerazione riportata in Figura 2.7:

1. Viene creata sul server una istanza dell’oggetto remoto e passata in forma di stub

al Java RMI registry. Tale stub viene, quindi registrato all’interno del registry

stesso;

2. L’applicazione client richiede al registry RMI una copia dell’oggetto remoto da

utilizzare;

3. Il Java RMI registry restituisce una copia serializzata dello stub al client;

4. L’applicazione client invoca uno dei metodi dell’oggetto remoto utilizzando la

classe “clone” fornita dallo stub;

5. Lo stub richiama lo skeleton che si trova sul server chiedendogli di invocare

sull’oggetto remoto lo stesso metodo che il client ha invocato sullo stub;

6. Lo skeleton invoca il metodo richiesto sull’oggetto remoto;

7. L’invocazione del metodo sull’oggetto remoto restituisce il risultato allo skeleton;

8. Lo skeleton comunica il risultato allo stub sul client;

9. Lo stub fornisce il risultato all’applicazione client iniziale.


39

La scelta di utilizzare RMI è consigliabile nel caso in cui si debba implementare una

struttura a oggetti distribuiti full-Java, in maniera semplice e veloce. L’alta semplicità di

RMI si paga a volte nei confronti delle tecnologie concorrenti più sofisticate (e

complicate) che offrono maggiore potenzialità e scalabilità.

Java RMI è una tecnologia nata per ambienti desktop (J2SE) ed estesa, come package

opzionale (OP), al mondo mobile (J2ME) e destinata, come descritto dal documento di

specifica JSR-66, a “sistemi ancor più differenti”, non solo desktop e server, ma anche

piccoli dispositivi mobili, come palmari e PDA.

RMI OP è un sottoinsieme di J2SE RMI che può essere usato sui dispositivi che

supportano la configurazione CDC.

2.5.4 J2ME Web Services: JSR-172 e kSOAP

Vediamo ora il rapporto tra un Web Service ed una applicazione in esecuzione in un

ambiente J2ME. Sebbene tutto sia possibile, è abbastanza difficile che il ruolo di una

applicazione J2ME sia quello di server. In effetti, la piattaforma J2ME nasce per

realizzare ed eseguire piccole applicazioni stand-alone. Inoltre, nel caso della

configurazione CDLC, non è possibile realizzare applicazioni thread, poiché la

piattaforma non riconosce tale paradigma. Per questo motivo è iniziata la

standardizzazione di quelli che sono gli strumenti che un sistema client J2ME può

utilizzare per l’invocazione di Web Services, raccolta sotto il nome di JSR-172 Web

Services on J2ME Platform.

Le API (WSA, J2ME Web Services API) descritte in queste specifiche sono un

sottoinsieme di quelle definite nell’ambiente J2SE, come nel caso di altre API [26].

Si tratta di specifiche, basate sul WS-I Basic Profile 1.0, che hanno lo scopo di

standardizzare quelle che sono le principali caratteristiche di un client per Web Service,

ovvero le invocazione di funzioni remote e il parsing XML.


40

L’utilizzo di un dispositivo cellulare o PDA come server di un servizio Web non sarebbe,

almeno con le potenzialità dei sistemi attuali e la limitata connettività, una scelta che trova

attualmente molti riscontri.

Le WSA sono quindi pensate per poter essere eseguite sia per configurazioni CDC che

CDLC. Come accaduto per altre API per l’ambiente J2ME, esse sono state ottenute

attraverso una selezione di quelle che sono le API analoghe disponibili per J2SE.

Le JSR-172 permettono di dotare un dispositivo J2ME delle funzionalità caratteristiche di

un client, ma non di tutte le funzionalità tipiche di un client J2SE: la ricerca di servizi

attraverso la tecnologia UDDI non è una funzionalità prevista da un client che utilizzi le

WSA. Un client potrebbe, inoltre, non solo accedere ad un servizio, ma anche eseguire

operazioni di deploy, undeploy o altre operazioni che definiamo di amministrazione.

Anche queste operazioni per il momento non sono supportate dalle WSA descritte dalle

JSR-172.

Il ruolo delle WSA è permettere, ad un dispositivo J2ME, di poter accedere ed utilizzare

un servizio esposto attraverso un’interfaccia Web Service. Lo scenario principale prevede

un client J2ME che utilizza un particolare servizio remoto a runtime come se fosse locale,

quindi in modo semplice e snello. Analogamente a quanto avviene nel caso J2SE, le WSA

ci dovranno mettere a disposizione uno strumento per generare degli stub che, attraverso

un servizio locale a runtime, ci permetteranno di accedere ad un Web Service in modo

trasparente.

L’architettura di un’applicazione J2ME, che utilizza le WSA, prevede la definizione delle

seguenti componenti [26]:

o applicazione J2ME che intende utilizzare un particolare Web Service;

o uno stub compliant con le JSR-172;

o un servizio a cui lo stub accede a runtime attraverso un’interfaccia che prende il

nome di Service Provider Interface (SPI).


41

Il ruolo del Service Provider Interface è quello di astrarre i servizi di gestione della

connessione e codifica dei dati dalla effettiva implementazione, lasciata al particolare

vendor. L’implementazione dei servizi descritti dalla Service Provider Interface prende il

nome di Runtime.

Figura 2.8 - Architettura del J2ME Web Services API

Dalla Figura 2.8 si nota come una particolare applicazione non utilizzi direttamente i

servizi della SPI, ma vi acceda attraverso lo Stub, che viene generato in modo automatico

a partire dal WSDL di un servizio attraverso l’utilizzo di un insieme di tools forniti dal

particolare vendor.

La modalità di accesso alle funzionalità di Runtime attraverso l’utilizzo di un Stub è il

modo più semplice per accedere ad una Web Service attraverso WSA, le quali mettono a

disposizione anche API di più basso livello.


42

Oltre agli strumenti per l’invocazione di servizi Web, le WSA forniscono le API per il

parsing di documenti XML.

La Java Community mette a disposizione gli strumenti per utilizzare le specifiche JSR-

172: il Wireless ToolKit (WTK) per CDLC, ora giunto alla versione 2.5, e il Sun Java

ToolKit per CDC, versione 1.0.

In particolare, già dalla versione 2.1, WTK include la funzionalità Stub generator, che a

partire dalla descrizione WSDL del servizio a cui vogliamo accedere, genera in modo

automatico una serie di classi Java che costituiscono lo stub e consentono al client J2ME

di accedere in modo trasparente al servizio

In alternativa alle specifiche JSR-172, possiamo adottare le k-Solution.

Le specifiche JSR-172 si preoccupano di creare un meccanismo veloce per integrare al

client J2ME una serie di classi Java che costituiscono lo stub, grazie al quale l’accesso ai

servizi remoti avviene in modo del tutto trasparente [27].

Con le k-Solution, il client accede al servizio in modo leggermente diverso. In questo caso

il paradigma di accesso al Web Service si basa su un progetto iniziato come open-source

dalla comunità Enhydra.org. Tali librerie sono raggruppate, forse impropriamente, sotto il

nome kSOAP: esse includono non solo le funzioni di impacchettamento tipiche del

protocollo SOAP, ma anche quelle di serialization e parser.

Il profilo MIDP consente la connessione del dispositivo wireless via HTTP e kSOAP

fornisce la classe aggiuntiva org.ksoap.transport.HttpTransport che automatizza il

processo HTTPcall [27] illustrato di seguito:

1. il client compone il messaggio di richiesta con gli opportuni parametri;

2. il client invia la richiesta SOAP all’endpoint del servizio utilizzando il protocollo

HTTP;

3. il server elabora la richiesta e compone il messaggio SOAP di risposta;

4. il server invia la risposta via HTTP, tramite la stessa connessione della richiesta;

5. il client elabora la risposta.


43

Con l’uso delle librerie kSOAP – kXML, possiamo saltare la fase di Stub generator

fornita dal tool della Sun WTK. Basta includere tali librerie nel progetto J2ME ed esse

permetteranno l’accesso ai servizi remoti. Questa è la sostanziale differenza con le

specifiche JSR-172: in quest’ultime il client Java accede ad un clone-Java locale del

servizio remoto (lo stub, appunto), mentre in questo caso le librerie kSOAP effettuano il

packing SOAP e il parser direttamente sul descrittore WSDL del servizio remoto. Ciò

rallenta il processo di interrogazione del servizio, ma dona maggiore dinamicità: se varia

l’interfaccia del servizio remoto, le JSR-172 richiedono una nuova generazione dello stub,

oltre che una modifica del client.

2.5.5 Jini

Mentre Java RMI è una tecnologia Java adattata al mobile computing, Jini [28] nasce per

permettere la realizzazione e la distribuzione dei servizi in rete tra dispositivi che spaziano

da minisistemi wireless ai PC, sino ai grandi server, basandosi sulla portabilità del codice

offerta dalla JVM.

Utilizzando protocolli di rete, Jini permette di mettere in comunicazione oggetti differenti

fra loro, dove ognuno mette a disposizione dei servizi per tutti coloro che ne abbiano

necessità.

In una comunità Jini i servizi possono essere dinamicamente aggiunti o tolti, le

applicazioni possono poi ricercare tali servizi ed usarli, senza averne a priori una specifica

conoscenza.

Ad esempio, una stampante, nel momento in cui si connette ad una comunità Jini, prima si

presenterà e poi esporrà la sua interfaccia, contenente per esempio il servizio print. Se

successivamente un frigorifero Jini dovesse aver bisogno di stampare una pagina con dei

dati relativi al proprio funzionamento, sarà sufficiente che vada a ricercare chi nella

comunità mette a disposizione il servizio print e poi richiederne l’esecuzione.

Il concetto più importante all’interno dell’architettura Jini è quello di servizio [29]. Un

servizio è un’entità che può essere usata da una persona, da un programma, o da un altro


44

servizio. Un servizio può essere computazione, memoria, un canale di comunicazione, un

dispositivo hardware, o un altro utente. Due esempi dei servizi sono: stampare un

documento e tradurre un documento da un formato ad un altro.

Un sistema Jini deve pensarsi come un sistema di servizi che sono messi insieme per il

compimento di una particolare operazione. I servizi possono usare altri servizi e un client

di un servizio può essere anch’esso un servizio per altri clients.

I servizi sono trovati dal Lookup Service: una tabella contenente le interfacce che

descrivono le funzionalità dei servizi presenti nella comunità Jini. In aggiunta vengono

memorizzate le descrizioni testuali dei vari servizi, in modo da essere maggiormente

comprensibili da un utilizzatore umano.

La comunicazione fra i servizi avviene utilizzando Java RMI.

L’accesso a molti dei servizi nell’ambiente Jini è basato sui leasing [29]. Un leasing è una

concessione di accesso garantito per un certo periodo di tempo. Ogni leasing è negoziato

fra il richiedente e il fornitore del servizio: un servizio è chiesto per un certo periodo;

l’accesso è assegnato per un periodo la cui durata è decisa dall’ambiente Jini sulla base del

periodo richiesto e dello stato dell’ambiente.

2.6 Soluzioni .NET

2.6.1 Panoramica su .NET Framework

Microsoft ha sviluppato .NET [30] come contrapposizione proprietaria al linguaggio Java.

.NET e il suo linguaggio principe, ovvero C#, sono standard ISO riconosciuti.

La sua caratteristica peculiare è di essere indipendente dalla versione operativa di

Windows su cui è installata, e di includere molte funzionalità progettate espressamente per

integrarsi in ambiente internet e garantire il massimo grado di sicurezza e integrità dei

dati.


45

La CLR (Common Language Runtime) è un insieme di librerie che, insieme alla classe

di librerie di base denominata FCL (Framework Class Library), è progettata per poter

funzionare con qualsiasi sistema operativo. Il compilatore Just In Time esegue un codice

assembly denominato CIL (Common Intermediate Language). È inoltre possibile:

o accedere a componenti scritti in altri linguaggi;

o quando il sistema operativo sottostante è Microsoft Windows, accedere ai suoi

servizi e alle sue API;

o accedere ai Web Services utilizzando il protocollo SOAP.

La CLI (Common Language Infrastructure) è concepita per essere compatibile con

qualsiasi linguaggio di alto livello orientato agli oggetti, fornendo un unico modello a

oggetti ed una vasta libreria di classi condivisibili.

La CLI, il CIL ed il C# sono simili rispettivamente alla JVM ed al linguaggio Java della

Sun Microsystems, con cui sono in forte concorrenza. Entrambi utilizzano un proprio

bytecode intermedio. Il bytecode di .NET è progettato per essere compilato al momento

dell’esecuzione (Just In Time compilation, detta anche JITting).

Al momento .NET è compatibile soltanto con le piattaforme Windows. Tuttavia, grazie al

progetto Mono di Novell è possibile sviluppare e eseguire client e server application .NET

su piattaforme diverse, non Windows.

2.6.2 .NET Compact Framework

La proposta Microsoft per il mobile è una versione “compatta” della piattaforma .NET.

.NET Compact Framework [31] è un ambiente indipendente dall’hardware che consente

di eseguire programmi su dispositivi quali PDA, cellulari e set-top box. Viene eseguito nel

sistema operativo Microsoft Windows CE e si basa su CLR rigenerato che è stato

progettato per funzionare in modo ottimale quando si eseguono programmi su dispositivi

con risorse limitate. .NET Compact Framework estende la disponibilità di codice gestito e


46

di servizi Web XML ai dispositivi mobili e offre vantaggi quali l’indipendenza dai tipi, la

Garbage Collection, la gestione delle eccezioni e la sicurezza.

.NET Compact Framework, che rappresenta un sottoinsieme della libreria di classi .NET

Framework, contiene anche classi appositamente progettate per dispositivi con risorse

limitate ed eredita interamente l’architettura .NET Framework per Common Language

Runtime e l’esecuzione di codice gestito.

.NET Compact Framework è disponibile come componente di sistema operativo in tutti i

dispositivi Microsoft Smart Device, inclusi PocketPC, PocketPC Phone Edition,

Smartphone e altri dispositivi basati su Windows CE.

Architettura

In Figura 2.9, riportata di seguito, viene riepilogata l’architettura della piattaforma .NET

Compact Framework.

Figura 2.9 - Architettura della piattaforma .NET Compact Framework

Windows CE

.NET Compact Framework utilizza il sistema operativo Windows CE per le funzionalità

essenziali e per numerose funzionalità specifiche del dispositivo. Diversi tipi e assembly,

ad esempio, quelli per i Windows Form, le immagini, il disegno e i servizi Web, sono stati


47

rigenerati per un’esecuzione efficiente sui dispositivi, anziché copiati dalla versione

completa di .NET Framework.

In .NET Compact Framework sono disponibili i seguenti tipi di interoperabilità con

Windows CE:

o compatibilità con la protezione nativa;

o integrazione completa con i programmi di installazione nativa;

o interoperabilità con il codice nativo mediante l’interoperabilità COM e il richiamo

piattaforma.

Common Language Runtime

Anche Common Language Runtime (CLR) di .NET Compact Framework è stato

rigenerato per consentire l’esecuzione delle risorse vincolate sulla memoria limitata e

l’utilizzo efficiente dell’alimentazione a batteria.

Tra Windows CE e CLR esiste un livello di adattamento piattaforma che consente di

mappare i servizi e le interfacce dei dispositivi necessarie per CLR e per il framework sui

servizi e le interfacce di Windows CE.

Framework

.NET Compact Framework, che rappresenta un sottoinsieme di .NET Framework, contiene

anche funzionalità appositamente progettate per .NET Compact Framework. Offre le

funzionalità e la semplicità che consentono agli sviluppatori di applicazioni per dispositivi

nativi di passare a .NET Framework e agli sviluppatori di applicazioni desktop di passare

ai dispositivi.

Ogni applicazione .NET Compact Framework viene eseguita all’interno di un costrutto di

runtime denominato dominio applicazione, analogo a un processo del sistema operativo.

.NET Compact Framework garantisce che tutte le risorse gestite utilizzate da

un’applicazione in esecuzione vengano liberate o restituite al sistema operativo host al

termine dell’applicazione.


48

I domini applicazione offrono numerosi vantaggi caratteristici dei processi, quali

l’isolamento degli errori e livelli elevati di affidabilità e protezione, senza richiedere il

supporto del sistema operativo sottostante. Nell’host di un dominio applicazione,

costituito a propria volta da codice del sistema operativo nativo, viene avviata un’istanza

di CLR. CLR può essere collegato all’host del dominio applicazione in modo statico o

dinamico.

Utilizzo della memoria

Quando è disponibile una quantità di memoria insufficiente, in .NET Compact Framework

vengono automaticamente rilasciate le strutture di dati non richieste dal codice attualmente

in esecuzione. Di conseguenza, il programma può essere eseguito anche in presenza di

memoria limitata. Se l’applicazione richiede una quantità di memoria superiore rispetto a

quella disponibile, l’applicazione viene chiusa correttamente da .NET Compact

Framework e vengono rilasciate tutte le risorse sottostanti.

2.7 Conclusioni

Si chiude qui la panoramica sulle tecnologie middleware analizzate per il mondo mobile

computing. L’aspetto comune di ciascuna tecnologia è la necessità di introdurre nello

sviluppo, e quindi nell’uso, delle applicazioni tool e librerie aggiuntive che garantiscano

trasparenza e dinamicità, anche con aspetti e gradi diversi. Per esempio, la soluzione RMI

garantisce trasparenza all’uso del servizio remoto, ma non al linguaggio e si adatta bene a

soluzioni full-Java, in cui anche il servizio remoto sia implementato in linguaggio Java. Le

soluzioni middleware e Web Services garantiscono trasparenza al linguaggio con

prestazioni diverse.

Particolare attenzione è stata data alle soluzioni Java mobile e, in particolare, al profilo

J2ME MIDP, valido anche nel caso di un dispositivo CDC.


49

Altro aspetto comune delle tecnologie analizzate è che esse estendono le funzionalità

mobile solo da un punto di vista client, nel senso che il servizio remoto è in ogni caso

fornito da una macchina fissa, server o quantomeno desktop.

Nel prossimo capitolo focalizzeremo la nostra attenzione sullo scopo reale di questo studio

di tesi, ovvero integrare un framework di servizi su un dispositivo mobile. L’ambizione è

quella di far risiedere il framework sul dispositivo mobile (per esempio, un palmare) con il

compito di facilitare la realizzazione di applicazioni che ne sfruttino i servizi in modo

trasparente.

Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

50

3. Framework per l’integrazione di servizi in ambienti mobili

3.1 Obiettivi del framework

Nel capitolo precedente abbiamo parlato delle soluzioni middleware per mobile

computing. Implicitamente abbiamo assunto che si trattasse di ambienti nomadici, ovvero

il grosso del carico computazionale relativo al middleware, se non tutto, fosse delegato

alla parte fissa dell’ambiente distribuito, mentre la parte mobile, in senso stretto, svolgesse

funzioni di thin client.

L’ambiente nomadico di riferimento non è stato presentato in senso architetturale:

abbiamo pensato ad un ambiente LAN/WAN senza togliere la possibilità che i servizi

risiedessero su un server remoto accessibile via Internet.

Nell’ambito del progetto “WiFi People – CRONOS”, gli obiettivi richiesti per il

framework vanno oltre lo stato dell’arte attuale:

o si vuole uscire dal sistema necessariamente nomadico e orientarsi ad un sistema

Ad-Hoc, indipendente da qualunque infrastruttura fissa. Per ottenere quanto detto,

è necessario che il framework risieda sul dispositivo mobile ed offra una serie di

servizi.

o Dal punto di vista dell’utenza, il servizio principe fornito dal framework deve

essere l’autoconfigurazione e l’autodistribuzione: un dispositivo mobile che

entra a far parte della rete, “spontaneamente” costituita, deve essere messo in

condizione di poter conoscere e ricevere dal dispositivo mobile più vicino le

applicazioni distribuite sulla rete che usano, appunto, i servizi del framework


51

stesso. Lo scopo è che ogni dispositivo mobile (palmari, PDA…), appartenente al

sistema mobile in questione, sia in grado di eseguire le applicazioni così

distribuite. Sarà il framework a farsi carico della distribuizione dei servizi di cui

necessita l’applicazione.

o Dal punto di vista della programmazione, il framework deve rispettare vincoli di

trasparenza tipici di un middleware, garantendo ai programmatori del dispositivo

mobile di poter realizzare applicazioni complesse che accedano a tali servizi.

3.2 Requisiti del framework

Possiamo immaginare il framework diviso in due parti: la parte più interna, costituita dai

servizi, che dovrà soddisfare i requisiti funzionali, e la parte con cui le applicazioni utente

e gli sviluppatori sono direttamente a contatto, ovvero il Framework Core, che sarà

progettato sulla base dei requisiti non funzionali richiesti dal progetto “WiFi People –

CRONOS”.

3.2.1 Requisiti funzionali

Di seguito riportiamo i servizi che il framework deve offrire. Si dia particolare attenzione

all’ultimo servizio, su cui poggia la distribuzione delle applicazioni tra i dispositivi mobili,

rendendo non necessaria la presenza dell’infrastruttura fissa.

Discovery dei servizi

Il servizio permette al dispositivo di scoprire quali servizi sono disponibili sulla rete e

indicarne la disponibilità. Il servizio di discovery permette di accedere ai servizi scelti e ne

consente l’utilizzo. Inoltre la configurazione del dispositivo e la ricerca sono totalmente

automatiche e, quindi, non a carico dell’utente.


52

VoIP

Si vuole fornire un servizio di telefonia sul protocollo IP. Il dispositivo mobile diviene un

client con la capacità di effettuare e ricevere chiamate attraverso la rete Internet.

Positioning/GPS

Si intende fornire un servizio per la localizzazione del dispositivo mobile in un ambiente

fisico indoor e, attraverso le sue coordinate GPS, in ambiente fisico outdoor.

Per fornire il servizio di positioning è possibile utilizzare indistintamente la tecnologia

Bluetooth oppure la tecnologia Wi-Fi. L’ambiente indoor, nel quale si intende localizzare

la posizione del dispositivo, dovrà essere opportunamente cablata con Access Point Wi-Fi

o Bluetooth.

Il palmare che offre il servizio GPS deve necessariamente essere dotato di un dispositivo

GPS integrato o deve essere in grado di interfacciarsi con un dispositivo GPS esterno.

Sincronizzazione dati

Si vuole fornire un servizio di sincronizzazione di e-mail, contatti ed appuntamenti tra

dispositivi.

Accesso DB

Si intende fornire un servizio per l’accesso ad un generico database remoto di

informazioni. Si prevede una copia parziale del DB in locale di cui garantire la coerenza

con il DB remoto. Tale procedura si attiva indoor in maniera automatica o su richiesta

dell’utente.

Instant Messaging

Si vuole fornire un servizio di messaggistica istantanea e presenza. Il dispositivo mobile

diviene un client in grado di scambiare messaggi real-time con altri dispositivi.


53

Interfacciamento periferiche esterne

Il servizio in questione intende offrire un’interfaccia standard di comunicazione con

periferiche esterne e non integrate nel dispositivo mobile, come, ad esempio, stampanti

Bluetooth e videocamere wireless.

Gestione canale SMS per notifiche ed alert

Tale servizio intende offrire la possibilità di inviare messaggi di testo SMS al fine di

effettuare delle notifiche e generare degli alert. Per usufruire di tale servizio è necessario

che il dispositivo mobile sia dotato di una scheda GSM o di un modem GPRS.

Video-streaming

Il servizio di video-streaming offre la possibilità di gestire i flussi video da e verso il

dispositivo mobile. Il video-streaming, effettuato anche in multicast, verso altri dispositivi

mobili può avere come sorgente un file video oppure, qualora fosse presente una

telecamera sul dispositivo mobile sorgente, consentire la condivisione delle immagini che

essa riprende.

Distribuzione del framework e discovery di applicazioni

Si intende fornire un meccanismo per cui l’utente può sapere, attraverso il suo dispositivo

mobile, quali applicazioni sono già presenti sui dispositivi appartenenti all’area a cui si è

connesso.

Si intende dare all’utente la possibilità di effettuare il download di tali applicazioni ed,

eventualmente, dei relativi servizi necessari per il corretto funzionamento

dell’applicazione stessa.

Le applicazioni così distribuite possono accedere ai servizi del framework localmente

oppure demandandone l’esecuzione ai dispositivi mobili circostanti.

Qualora il dispositivo mobile possegga una versione più vecchia dell’intero framework o

di una parte dei servizi, può effettuarne l’aggiornamento.


54

3.2.2 Requisiti non funzionali

Trasparenza dal linguaggio

Si intende l’indipendenza da un qualsiasi linguaggio di programmazione con cui uno

sviluppatore potrà implementare le applicazioni utente che dovranno interagire con il

framework per accedere ai servizi offerti. Ciò prevede l’omogeneizzazione dei dati tramite

il marshalling e unmarshalling dei dati.

Trasparenza dal Sistema Operativo

Si intende l’indipendenza da un particolare sistema operativo che possa trovarsi sul

dispositivo mobile su cui installare il framework. In particolare i sistemi operativi che

vengono presi in considerazione sono Symbian, Linux, Windows Mobile.

Trasparenza alla comunicazione

Si intende garantire la comunicazione tra i framework e i servizi, distribuiti su tutti i

dispositivi mobili, a prescindere dai protocolli di comunicazione adottati dall’infrastruttura

di rete.

Load balancing

Con load balancing si intende la possibilità di distribuire il carico, cioè l’ottimizzazione

dell’utilizzo delle risorse di calcolo tale che si migliorino le performance dei servizi

forniti.

Utilizzo di strumenti open-source

Si vogliono sfruttare componenti open-source presenti sul mercato, in particolare sulla

rete Internet, per la realizzazione dei servizi, descritti in precedenza, che deve fornire il

sistema.

Portabilità dei servizi

Si intende la capacità del sistema e in particolare dei singoli servizi di “migrare” in nuovi

ambienti, cioè su piattaforme diverse, garantendone il corretto funzionamento e utilizzo.


55

Prestazioni

Inizialmente non daremo peso ai limiti tecnologici imposti dai dispositivi mobili presenti

attualmente sul mercato, puntando ad una prima soluzione intermedia in cui il framework

sia distribuito in parte sui dispositivi mobili stessi e in parte su macchine remote. L’idea è

quella che, con l’introduzione sul mercato di nuovi e più potenti dispositivi mobili, il

framework possa risiedere interamente su quest’ultimi, garantendo prestazioni adeguate

alle applicazioni real-time.

Manutenibilità

E’ importante garantire una facile manutenzione del framework sia nell’ambito delle scelte

tecnologiche per la realizzazione del Framework Core sia dal punto di vista dei servizi.

Operazioni di aggiornamento, tanto del framework quanto della tecnologia, devono poter

essere svolte con semplicità dagli sviluppatori e avvenire in trasparenza rispetto agli utenti

finali.

3.3 Architettura del framework

Il Framework Core si pone come strato intermedio tra i servizi e le applicazioni (Figura

3.1), sia dal punto di vista dello sviluppo di queste ultime, sia dal punto di vista

dell’applicazione utente che, per essere correttamente eseguita, deve accedere a

determinati servizi.

Oltre a permettere l’accesso ai servizi in locale, l’architettura del sistema prevede di

mettere in comunicazione diretta due o più dispositivi mobili, per esempio palmari. Il

framework fornisce l’astrazione necessaria a livello applicazione affinché agli utenti sia

del tutto trasparente la necessità di installare nuovi servizi da integrare nel framework

oppure la necessità di aggiornarne qualche componente.


56

Figura 3.1 - Architettura del framework: Framework Core e servizi

Un ruolo fondamentale riveste il servizio di Discovery dei servizi. Esso è il servizio che

necessariamente va distribuito tra i palmari che vogliono godere della trasparenza sopra

descritta. Tale servizio, unito a quelli di Aggiornamento framework e Download

framework, costituisce l’insieme dei servizi necessari per la gestione del framework

(indicati in verde in Figura 3.1).

Per esigenze legate alla manutenibilità tutti i servizi saranno scritti in un unico linguaggio

in modo che le competenze richieste per la manutenzione completa siano contenute.

Tuttavia ciò non vincola gli sviluppatori di applicazioni consumer ad adottare lo stesso

linguaggio in cui sono implementati i servizi, grazie alla trasparenza dal linguaggio

garantita dal Framework Core.

Vediamo, di seguito, i possibili scenari in cui il framework può trovarsi ad operare.

Partiamo dalla prima configurazione in cui il framework e i servizi sono totalmente

distribuiti sui dispositivi mobili (Figura 3.2). In questo caso la comunicazione tra i


57

dispositivi mobili e/o la collaborazione tra i servizi, presenti su ciascuno di essi, avverrà in

modo diretto senza la necessità di alcuna infrastruttura fissa intermediaria.

Figura 3.2 - Configurazione 1: Deployment del Framework su due dispositivi mobili

Per collaborazione tra i servizi intendiamo che affinché l’applicazione utente sia

correttamente eseguita è necessario avere a disposizione una determinata serie di servizi,

nonché una loro collaborazione diretta.

Per collaborazione tra i dispositivi mobili intendiamo il caso in cui i servizi non siano

tutti presenti sul dispositivo mobile o non eseguibili in locale. Può infatti accadere che

un’applicazione utente in esecuzione su un dispositivo mobile necessiti di un servizio non

presente o non eseguibile nel framework locale. In tal caso, possiamo adottare due strade

affinché l’esecuzione dell’applicazione utente vada comunque a buon fine:

1. il Framework Core si farà carico di eseguire sui dispositivi mobili più vicini una

ricerca del servizio mancante e, una volta trovato, ne effettuiamo il download sul

nostro dispositivo mobile (in Figura 3.3 riportiamo il download di un servizio IM).

Emerge, e risulta necessaria, in tale contesto la portabilità dei servizi richiesta al

framework.


58

Figura 3.3 - Scenario 1: Download di un servizio mancante

2. Previa un’analoga operazione di ricerca del servizio, il Framework Core chiederà

al dispositivo mobile più vicino di eseguire per noi (esecuzione demandata) il

servizio mancante (in Figura 3.4 riportiamo l’esecuzione demandata di un servizio

IM). Tale contesto va incontro alle esigenze di load balancing, infatti un

dispositivo mobile può avvalersi dell’esecuzione demandata anche nel caso in cui

le risorse a sua disposizione non permettano l’esecuzione del servizio in locale.

Figura 3.4 - Scenario 2: Esecuzione demandata di un servizio mancante


59

In quest’ottica vanno fatte delle considerazioni. Percorrere l’una o l’altra via per sopperire

alla mancanza di un servizio in locale non è indifferente; bisogna tener conto sia del tipo

di applicazione utente sia del tipo di servizio. Se l’applicazione utente che richiede il

servizio è fortemente real-time, conviene effettuare il download prima che l’applicazione

sia in esecuzione o al più in fase di caricamento della stessa; così come non avrebbe senso

demandare l’esecuzione del servizio GPS ad un altro dispositivo mobile, a meno che non

ci interessi conoscere le coordinate GPS di quest’ultimo. Allo stesso modo sarebbe

irrealizzabile demandare l’esecuzione di un servizio VoIP il quale ha necessità di riferirsi

a periferiche locali, come microfono e altoparlante.

Considerando anche le ridotte risorse dei dispositivi mobili, in generale l’esecuzione

demandata dei servizi conviene in applicazioni lascamente o non real-time e tali da

richiedere la trasmissione di piccoli pacchetti dati, come nel caso dell’IM dove i dati

trasmessi sono essenzialmente stringhe.

Un ulteriore scenario è l’aggiornamento di un servizio già presente sul dispositivo

mobile locale. A seguito di un’opportuna ricerca del servizio, se ne rileva una versione più

aggiornata su un dispositivo mobile vicino. A questo punto, si esegue una sostituzione

parziale o totale del componente locale con il componente scaricato (in Figura 3.5

riportiamo l’aggiornamento di un servizio IM).

Figura 3.5 - Scenario 3: Aggiornamento di un servizio già presente in locale


60

I tre scenari visti in precedenza e le analoghe considerazioni possono riferirsi anche al

caso in cui l’interazione avvenga tra un dispositivo mobile e una macchina server remota

su cui risiede il servizio richiesto, purché il Framework Core risieda comunque sul

dispositivo mobile.

Passiamo ora alla seconda configurazione, questa volta tipica di una soluzione di

nomadic computing. Tale soluzione prevede, infatti, la presenza di un’infrastruttura fissa

(almeno una macchina server) su cui far risiedere il nostro framework e i sottostanti

servizi. L’accesso ai servizi e la comunicazione tra i dispositivi mobili, continuando a

dipendere dal framework, passeranno ora per il server.

Questa configurazione, che solleva il dispositivo mobile dal carico computazionale legato

al framework e ai servizi, ci permette di superare i limiti tecnologici legati ai dispositivi

mobili odierni, ma richiede di garantire la trasparenza ad un livello diverso rispetto a

quanto già descritto: alle trasparenze garantite dal Framework Core, dobbiamo

aggiungere, sul lato client, la trasparenza alla locazione, ovvero le applicazioni devono

essere utilizzate e sviluppate come se i servizi offerti dal framework risiedessero in locale,

a patto di tollerare un certo aumento dei tempi di risposta di ciascun servizio.

Figura 3.6 - Configurazione 2: Deployment del framework su infrastruttura fissa (nomadic computing)


61

Volendo mantenere i servizi sul palmare, un’ulteriore soluzione potrebbe essere effettuare

un linking diretto tra client e servizio (es.: Java RMI). Il vantaggio è che recuperiamo in

prestazioni per il dispositivo mobile, ma perdiamo la trasparenza del linguaggio. Per

recuperarla potremmo implementare i servizi in ciascun linguaggio di programmazione e

per ogni piattaforma per cui vogliamo realizzarne il corrispondente client. Lo sforzo per

questo tipo di soluzione è notevole, inoltre la soluzione stessa si mostra poco lungimirante,

nonché difficilmente manutenibile. Si pensi all’aggiornamento di un servizio da parte

dello sviluppatore: oltre a richiedere più competenze, tale soluzione costringe ad

intervenire su più implementazioni dello stesso servizio in linguaggi diversi. In tal caso

risulta anche difficile mantenere una certa coerenza tra tutte le implementazioni possibili.

3.4 Studio di fattibilità

3.4.1 Introduzione

Riportiamo di seguito il documento relativo allo studio di fattibilità.

Lo scopo di questo documento è riportare e riassumere lo studio effettuato sulle possibili

tecnologie da poter utilizzare per la realizzazione del framework, che deve offrire servizi a

client eterogenei (implementati in qualunque linguaggio tipico per applicazioni mobili) su

piattaforme eterogenee (Windows Mobile, Symbian e Linux).

La piattaforma di riferimento iniziale per i nostri dispositivi mobili è Windows Mobile, in

particolare le versioni 5.0 e 6.0.

Il linguaggio di programmazione usato per la realizzazione dei servizi che compongono il

framework è Java, in modo da garantire la portabilità dei nostri servizi.

In precedenza, abbiamo visto che la soluzione nomadica ci permette di superare i limiti

legati alle risorse hardware a disposizione per i dispositivi mobili attualmente diffusi,

come Smartphones e PDA. Nell’ambito di questo studio, proseguiremo il nostro discorso

supponendo che sia possibile adottare anche una soluzione intermedia, dove il framework


62

risulterà distribuito tra i dispositivi mobili e un’infrastruttura fissa e, in particolare, una

parte dei servizi saranno residenti sui dispositivi mobili e i restanti su server remoti. Di

conseguenza, sui dispositivi mobili implementeremo i servizi con J2ME, con J2SE i

restanti. In entrambi i casi, utilizzeremo librerie open-source.

Per implementare i client di test e verificare la trasparenza al linguaggio utilizzeremo il

linguaggio C#.

3.4.2 Confronto tra le possibili scelte tecnologiche

Per una rapida comprensione delle caratteristiche delle tecnologie esaminate e per

mostrarne un confronto di facile lettura, è stata realizzata una griglia (griglia di

fattibilità) su cui sono riportati i risultati dello studio effettuato.

Figura 3.7 - Griglia di fattibilità del framework per le tecnlogie esaminate (Nota - SMCD: Si, ma con difficoltà)

Teniamo una breve panoramica su quelli che sono i vantaggi e gli svantaggi di ciascuna

tecnologia che possiamo adottare per lo sviluppo del framework:

Web Services

I vantaggi dei Web Sevices sono la trasparenza rispetto sia al linguaggio di

programmazione che al sistema operativo, mentre gli svantaggi sono legati alle

performance che sono minori di quelle riscontrabili utilizzando approcci alternativi di

distributed computing quali Java RMI, JINI e wireless CORBA. Il problema di fondo dei

Web Services è legato alle scarse risorse che oggi offrono i dispositivi mobili, come i


63

palmari. Esse, infatti, non permettono di installare un server, anche di piccole dimensioni,

a cui i client possano chiedere uno dei servizi facente parte del framework.

Java RMI

I vantaggi di utilizzare Java RMI sono la trasparenza rispetto ai sistemi operativi e la

distribuzione del carico su più dispositivi (RMI è nata proprio per consentire a processi

Java distribuiti di comunicare attraverso una rete, rendendo trasparenti al programmatore

quasi tutti i dettagli della comunicazione su rete), con la possibilità di accedere anche a

servizi locali. Inoltre, le prestazioni sono migliori rispetto a quelle dei Web Services. Gli

svantaggi, invece, sono la non completa trasparenza rispetto ai linguaggi di

programmazione, essendo RMI una tecnologia Java. Il problema è soprattutto per la

piattaforma .NET per cui, a differenza del C++, non esiste alcun porting Java.

JINI

Il vantaggio principale di Jini è da attribuire alle sue caratteristiche di scalabilità, proprie

delle tecnologie orientate ai servizi e nate per ben adattarsi ad ogni dispositivo target.

Ecco i motivi della sua elevata manutenibilità. Tuttavia la comunicazione tra i servizi, in

Jini avviene con la tecnologia Java RMI da cui eredita lo svantaggio di non realizzare una

piena trasparenza al linguaggio.

Wireless CORBA

Wireless CORBA presenta molti vantaggi, tra cui la possibilità di distribuire il carico e la

possibilità di accedere localmente ai servizi con prestazioni migliori rispetto alle altre

tecnologie prese in esame. E’ da tenere comunque presente che le prestazioni si abbassano

notevolmente quando il volume dei dati scambiati aumenta sopra i 1024 byte. Questa

tecnologia va, però, esclusa poiché non è utilizzabile sulla piattaforma di riferimento

Windows Mobile.


64

Protocollo proprietario basato su XML

Il vantaggio di questa scelta si riduce alla possibilità di creare un protocollo di

comunicazione che soddisfi perfettamente i requisiti fissati dal documento di specifica. In

questo modo avremo un elevato grado di manutenibilità grazie alla completa conoscenza

del protocollo progettato ed implementato da noi stessi. Di contro realizzare un nuovo

protocollo comporta tempi di realizzazione molto lunghi e difficoltà di implementazione,

legate anche al fatto di doversi comunque attenere agli standard XML già definiti. Oltre

ciò, è impossibile prevedere le prestazioni garantite dal protocollo che realizzeremo, senza

contare che gli sviluppi della tecnologia in ambito di dispositivi mobili potrebbe far

risultare inutili i nostri sforzi.

3.4.3 Prospettive di mercato

In ultimo è stata fatta una piccola analisi di mercato per catturare le direzioni di mercato

relative alle tecnologie di distributed computing. In particolare, due delle aziende leader

nel settore, la TIBCO e la BEA Weblogic puntano molto sul modello SOA, architettura

orientata ai servizi, che sembra andare per la maggiore anche per aziende minori. La

chiave di tale architettura, ovviamente, è il “servizio”: l’idea è quella di avere molti

servizi, implementati anche in differenti linguaggi e da persone diverse, a cui accedere in

modo tale da poter riutilizzare anche implementazioni di servizi già esistenti. Poiché il

modello SOA trova nei Web Services la sua maggiore implementazione, entrambe le

aziende indicano, appunto, i Web Services come la soluzione da adottare.

In particolare, la TIBCO offre una suite completa di librerie RIA AJAX enterprise-class

per l’implemetazione di applicazioni Web e in particolare Web Services. Ajax è una

tecnica di sviluppo Web per creare applicazioni Web interattive.

Per quanto riguarda la BEA Weblogic prendiamo da loro sito di riferimento una frase

molto esplicita:


65

“La BEA Weblogic offre prodotti e servizi che permettono alle aziende di ottenere più

velocemente un time-to-value per le applicazioni critiche di business, utilizzando standard

aperti, Web Service e una Service-Oriented Architecture (SOA)”.

3.5 Conclusioni

Dall’analisi effettuata e seguendo le scelte tecnologiche di TIBCO e BEA Weblogic, la

nostra scelta riguardo la tecnologia da utilizzare è quella dei Web Services. Grazie alla

trasparenza che offrono per l’accesso, remoto o locale, i Web Services si prestano, per loro

natura, ad adattarsi bene all’evoluzione della tecnologia dei dispositivi mobili. Le

aspettative di mercato prevedono che nel prossimo futuro, in particolare, i palmari avranno

risorse sufficienti per poter ospitare il framework di servizi secondo le configurazioni e gli

scenari illustrati precedentemente.

Adottando la soluzione nomadica per la distribuzione del framework, sembrerebbe così di

aver trovato la soluzione definitiva per la sua implementazione (vedi Appendice A). In

realtà, non tutte le configurazioni mostrate in precedenza possono essere adottate

indistintamente.

Si pensi al servizio di Instant Messaging nella soluzione nomadica: fondamentalmente si

tratta di scambiare, attraverso messaggi SOAP, stringhe di testo tra il client C# (sul

palmare) e il Web Service (su macchina server), che quest’ultimo provvederà a gestire e

inoltrare verso il dispositivo mobile destinatario. Lo scambio dei messaggi SOAP sarà

indipendente dall’hardware dei Web Service consumers coinvolti.

Il problema si pone, invece, per quella tipologia di servizi per cui il flusso di dati

scambiati con un altro host (sia esso un dispositivo mobile o una macchina server)

dipende fortemente dalle caratteristiche hardware del dispositivo mobile stesso. In tal caso

è necessario che il servizio e, quindi, il framework risiedano sul dispositivo mobile,

escludendo la soluzione nomadica. Al più potremmo adottare la soluzione intermedia,

per esempio, con la distribuzione del servizio IM su macchina server e del servizio VoIP

direttamente su dispositivo mobile.


66

Nel seguente capitolo studieremo una soluzione per implementare un servizio VoIP su

palmare. Nell’applicazione VoIP è intrinseco il suo legame con le caratteristiche hardware

del palmare stesso. Si dovrà gestire uno streaming audio che adotta come source il

microfono di un host e come drain le casse di un altro. Lo streaming audio è possibile

sono in presenza di codec opportuni che possono essere compatibili o meno con il palmare

stesso.

Pensare di elaborare uno streaming audio lato Web Service su una macchina server, che

presenta risorse ben più estese di un palmare, va contro la fattibilità del VoIP stesso:

rischieremo di avere un flusso audio che il palmare non può in nessun modo né elaborare

né riconoscere come tale.

Confidando, quindi, nelle prospettive tecnologiche che il mercato dei dispositivi mobili

promette per l’avvenire, passeremo all’implementazione del servizio VoIP direttamente

sul palmare, proiettandoci verso un Web Service su dispositivo mobile.

Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

67

4. Analisi di un caso di studio: integrazione del servizio VoIP

In questo capitolo tratteremo, in particolare, lo sviluppo e l’integrazione di uno dei servizi

offerti dal nostro framework: il servizio VoIP. Tale servizio ci pone di fronte ad uno studio

interessante, infatti, come già accennato, il VoIP on mobile mostra diversi limiti

tecnologici, volendo esporre il servizio come un Web Service, ma, allo stesso tempo, ci

proietta verso il futuro delle tecnologie mobile.

4.1 Panoramica sulla tecnologia VoIP

Voice over IP (voce tramite protocollo Internet) [32], acronimo VoIP, è la tecnologia che

rende possibile effettuare una conversazione telefonica sfruttando una connessione ad

Internet o un’altra rete che utilizza il protocollo IP (Internet Protocol), anziché utilizzare

esclusivamente la normale linea di trasmissione telefonica (PSTN), permettendo di

eliminare le centrali di commutazione ed economizzare sulla larghezza di banda occupata.

Le conversazioni VoIP possono usare come mezzo trasmissivo una qualsiasi rete basata

sul protocollo IP come una rete privata locale (LAN) all’interno di un edificio o di un

gruppo di edifici o una rete più ampia (WAN), fino alla grande rete pubblica, Internet.

La telefonia via IP permette una maggiore efficienza nell’uso della rete, grazie all’utilizzo

della commutazione di pacchetto che, a differenza della commutazione di circuito, non

assegna staticamente le risorse disponibili durante l’intera durata di una comunicazione

ma ne consente la condivisione con altri sistemi di comunicazione dati, quali testo e video.

Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati


68

in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti

collegati sta parlando.

La tecnologia VoIP permette applicazioni impossibili alle tradizionali reti telefoniche

[33]: ad esempio, si può portare il proprio telefono VoIP ovunque sia disponibile una

connessione Internet e ricevere ed effettuare chiamate come se si fosse a casa propria,

rimanendo raggiungibili allo stesso numero. In parallelo con la conversazione telefonica si

possono scambiare flussi video in tempo reale (videoconferenza), possono essere inviati e

ricevuti messaggi o file e si può partecipare a conferenze audio tra più persone in modo

intuitivo ed a costi molto bassi.

Tra i vantaggi del VoIP rispetto alla telefonia tradizionale va annoverato la diffusione a

larga scala di applicazioni come la videoconferenza e la videotelefonia, supportata non

solo dalla significativa riduzione del costo delle comunicazioni a lunga distanza, ma

soprattutto nei vantaggi operativi e di semplificazione delle infrastrutture.

La tecnologia VoIP ha comunque diversi punti deboli che possono rallentare una sua larga

diffusione. Il problema di fondo della tecnologia VoIP è che la rete Internet è una rete best

effort e non dà quindi nessun tipo di garanzia né in termini di ritardo, di perdita e di ordine

sulla ricezione e la ricostruzione dei pacchetti di dati ricevuti. Risulta quindi necessario

assicurare che il flusso audio mantenga la corretta coerenza temporale [33]. Questi

problemi sono sempre meno rilevanti, grazie a tecnologie che permettono di assegnare una

priorità diversa a certi pacchetti dati, garantendo la qualità del servizio (QoS).

Altre problematiche sono quelle relative all’affidabilità: i telefoni tradizionali senza cavo

di alimentazione (la quasi totalità dei telefoni fissi) sono alimentati dalla linea telefonica, e

in caso di black-out continuano a funzionare grazie a batterie e generatori all’interno delle

centrali telefoniche. I telefoni VoIP (apparecchi, simili ad un tradizionale telefono, che si

collegano direttamente ad un router connesso ad Internet) hanno bisogno della corrente


69

elettrica per funzionare e non sarebbero quindi disponibili durante un black-out rendendo

impossibile qualsiasi telefonata.

Inoltre le connessioni Internet a “banda larga” possono essere meno affidabili di una linea

telefonica e, se si presentano dei ritardi nell’invio o nella ricezione dei pacchetti o una

perdita degli stessi, la comunicazione vocale viene momentaneamente interrotta. Questi

fenomeni si presentano in modo più evidente quando applicazioni VoIP utilizzano reti

altamente congestionate o le distanze tra i punti finali sono molto lunghe [37].

A questo va aggiunto che i canali di telecomunicazione hanno un’intrinseca limitatezza in

termini di capacità nel trasportare dati, per cui è necessario adottare delle strategie di

codifica. In quest’ottica gli organismi internazionali preposti alla standardizzazione hanno

sviluppato e approvato protocolli sempre più leggeri ed efficaci, emanando opportune

raccomandazioni e definendo i terminali e le componenti tecniche necessarie per la

comunicazione multimediale su diversi tipi di sottoreti.

In particolare i protocolli al momento più utilizzati sono:

H.324, H.320, H.323 e dell’ITU – T, SIP dell’IETF e 3G-324-M del 3GPP.

Molto spesso queste raccomandazioni sono implementate su sistemi non sempre

compatibili e connessi a reti di diverse tipologie come LAN, xDSL (Digital Subscriber

Line), ISDN (Integrated Services Digital Network), linee telefoniche analogiche e linee

wireless.

Nel trasmettere audio e video su reti eterogenee, ad esempio, la connessione tra sorgente e

destinatario può essere stabilita su collegamenti di rete con diverse caratteristiche e

capacità. In questi casi il bit rate del segnale trasmesso deve essere adattato alla banda del

canale, a cui è collegato l’utente finale.

Se la comunicazione avviene tra sistemi che usano protocolli di segnalazione e codec

diversi, c’è anche la necessità di convertire il flusso di bit originario, codificato secondo le


70

regole sintattiche di uno standard, in un nuovo bit stream che sia interpretabile dal

ricevitore.

Per fare ciò occorre utilizzare, oltre ai gateway tradizionali, anche nuove apparecchiature

in grado di collegare la rete dati Internet e la rete telefonica tradizionale. Queste

apparecchiature sono note come Internet Telephony Gateway (o Voice Gateway) e sono

solitamente installate presso gli operatori di telefonia via Internet.

I gateway manipolano le trasmissioni vocali convertendole, dalla rete tradizionale, in

forme idonee alla trasmissione su reti a commutazione di pacchetto. Permettono quindi di

terminare sulla rete tradizionale PSTN telefonate che hanno avuto origine sulla rete IP di

un operatore di telefonia via Internet o, viceversa, di rendere accessibile un utente di

telefonia VoIP dalla rete telefonica tradizionale.

In questo ambito, per esempio, si colloca il gateway VoIP PBX open-source Asterisk.

4.2 Protocolli per il VoIP

La tecnologia VoIP richiede due tipologie di protocolli di comunicazione in parallelo [34].

Il primo è per il trasporto dei dati (pacchetti voce su IP): in tal caso, nella grande

maggioranza delle implementazioni di VoIP, viene adottato il protocollo RTP (Real-time

Transport Protocol).

Il secondo protocollo è destinato al controllo della conversazione, ovvero fornisce

meccanismi per instaurare, modificare e terminare una conversazione. In tal caso si

possono adottare diversi protocolli [32] tra cui:

o SIP (Session Initiation Protocol) della IETF;

o H.323 della ITU;

o Skinny Client Control Protocol, protocollo proprietario della Cisco;

o Megaco (conosciuto anche come H.248) e MGCP;

o MiNET, protocollo proprietario della Mitel;


71

o Inter Asterisk Xchange (IAX), soppiantato da IAX2, usato dai server PBX

Asterisk open-source e dai relativi software client.

4.2.1 RTP

Il protocollo RTP (Real-Time Protocol) [35] fornisce le funzionalità di trasporto delle

informazioni, in particolare in H.323.

In particolare, RTP consente il trasferimento in tempo reale punto-punto di informazioni

interattive audio, video e dati su reti unicast o multicast: un tipico scenario di utilizzo è la

videoconferenza.

Le funzioni svolte da questo protocollo comprendono la ricostruzione al ricevitore della

corretta sequenza dei pacchetti e della loro posizione nella scala dei tempi, consentendo

quindi la ricostruzione dei sincronismi.

Questo protocollo non permette, nativamente, di sincronizzare più sessioni multimediali

tra di loro in quanto ogni sessione RTP è in grado di trasportare un solo flusso. Questo non

impedisce, tuttavia, il dialogo tra N soggetti, che è anzi supportato nativamente attraverso

lo sfruttamento di un’eventuale tecnologia multicast sulla rete sottostante. Tuttavia in

presenza di più sessioni distinte (ad esempio audio e video) è necessario attivare più

sessioni RTP, ognuna delle quali è identificata da una coppia di indirizzi di livello

trasporto (indirizzo IP e numero di porto), e nel caso di multicast l’indirizzo di

destinazione è comune a tutti i partecipanti.

Utilizzando due sessioni RTP è possibile fare in modo, ad esempio, che alcuni partecipanti

ricevano sia l’audio che il video, mentre altri ricevano solo uno dei due.

L’header di un pacchetto RTP è composto da una parte fissa e un’estensione, utilizzata

per scopi sperimentali. La parte fissa dell’header si articola su 12 byte e contiene i

seguenti campi [35]:

o V (Version): indica la versione di RTP utilizzata;


72

o P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di

riempimento non facenti parte del payload. L’ultimo byte di padding contiene il

valore di quanti byte padding sono presenti;

o X (eXtension): se impostato ad uno, indica la presenza di un’estensione

dell’header;

o CC (CSRC Count): è il numero di CSRC (Contributing SouRCes) presenti dopo la

parte fissa dell’header;

o M (Marker): l’interpretazione di questo bit è legata al profilo;

o PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata

staticamente la corrispondenza tra il codice e il formato del payload;

o Numero di sequenza (Sequence Numbers): è incrementato di uno per ogni

pacchetto inviato; può essere utilizzato dal destinatario per accorgersi della perdita

di pacchetti e per ricostruire l’ordine corretto della sequenza;

o Timestamp: riflette l’istante di campionamento del primo ottetto dei dati. L’istante

di campionamento deve essere derivato da un clock che si incrementa

monotonamente e linearmente nel tempo per permettere i controlli di

sincronizzazione e le misure dell’incertezza sugli arrivi dei pacchetti (arrival

jitter);

o SSRC (Synchronization SouRCe): identifica la stazione trasmittente;

o CSRC (Contributing SouRCe): questo campo è opzionale ed è presente solo se un

elemento della rete ha unito in un unico flusso contributi provenienti da diverse

sorgenti; al suo interno sono elencati gli SSRC delle singole stazioni.

In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un codice univoco,

il SSRC, che permette alla stazione stessa di essere univocamente identificata all’interno

della sessione real-time in esame.

RTCP (Real-Time Control Protocol) [35] monitora l’invio dei dati e controlla e identifica

i servizi. Dunque riconosce automaticamente il tipo di compressione utilizzato sulla linea


73

e segnala al mittente e al destinatario eventuali problemi riscontrati sulla rete o sulla

stazione di lavoro (identificandone la fonte), tenendo sotto controllo e fornendo feedback

circa la qualità di ricezione e distribuzione dei dati (es.: numero dei pacchetti ricevuti o

persi sul jitter) .

RTCP (RTP Control Protocol) monitora la qualità del servizio e trasporta le informazioni

riguardo ai partecipanti ad una sessione [36]. RTCP è sufficiente per sessioni loosely

controlled, in cui non c’è un reale controllo dei partecipanti e set-up della sessione, e non

è necessario che tutti i requisiti di controllo siano soddisfatti. Da ciò RTP può essere

coadiuvato da un protocollo apposito per la gestione delle sessioni.

Solitamente le applicazioni pongono l’RTP sopra l’UDP per le operazioni di multiplexing

e checksum, anche se può essere usato con altri protocolli di rete e trasporto sottostanti.

I numeri di sequenza che troviamo nel protocollo RTP permettono all’utente che riceve i

dati di ricostruire la sequenza dei pacchetti del mittente. Le conferenze multicast

multimediali non sono però la sua unica capacità. Ad esempio, trovano posto in questo

protocollo la memorizzazione di un flusso dati continuo, le simulazioni interattive

distribuite, le misurazioni e i controlli.

4.2.2 H.323

Il protocollo H.323 [37] è una raccomandazione ITU – T (International

Telecommunications Union – Telecommunication Standardization Sector) che specifica il

modo in cui il traffico multimediale deve essere trasmesso in reti a commutazione di

pacchetto che non prevedono qualità del servizio (in particolare la rete IP). Questo

standard si occupa delle segnalazioni e del controllo delle chiamate, la trasmissione e il

controllo di informazioni multimediali e il controllo di ampiezza di banda nelle conferenze

in tempo reale punto-punto e multipunto.


74

Figura 4.1 - Una generica infrastruttura H.323

Gli elementi fondamentali di un sistema H.323 sono [37]:

o i terminali, ovvero dispositivi che si interfacciano con gli utenti (es.: PC o

apparecchi telefonici analogici tradizionali). Offrono funzionalità di controllo del

sistema, formattazione di flussi audio/video che devono essere trasmessi, codifica

audio e video (quest’ultima opzionale), supporto di applicazioni (come ad es.:

conferenze audiografiche);

o i gateway, che traducono i vari formati di trasmissione audio, video e dati

connettendo, di fatto, reti di tipo diverso (come la rete IP, la rete telefonica

tradizionale, la rete ISDN, ecc.);

o il gatekeeper, è il componente centrale dell’infrastruttura H.323, nonostante sia

considerato un elemento opzionale. Tra le funzioni svolte da un gatekeeper

troviamo:

fornire un metodo di autenticazione di terminali e gateway;

gestire la banda e l’accounting (ovvero raccogliere gli elementi per fatturare

i servizi erogati);

o MCU (Multipoint Control Unit), si tratta del sistema che permette di estendere la

comunicazione da punto a punto a punto multi-punto. Gestisce conferenze

multipoint tra tre o più terminali. E’ costituito da un MC (Multipoint Controller),

che assicura un livello minimo di comunicazione e da uno o più processori MP

(Multipoint Processor), per l’audio, il video o i dati.


75

Figura 4.2 - Stack protocollare nel sistema H.323

I protocolli che fanno parte dello standard H.323 si occupano del supporto

dell’ammissione, l’instaurazione, lo stato, il rilascio, la gestione dei mezzi trasmessivi e i

messaggi di gestione della chiamata.

Essi si dividono in due categorie secondo il protocollo di trasporto sul quale si

appoggiano:

o protocolli che si appoggiano su un canale connesso e quindi sicuro quale TCP

(H.225, Q.931, H.245);

o protocolli che si appoggiano su un canale non connesso e quindi “inaffidabile”

quale UDP (RTP, RTCP, RAS).

Un ulteriore classificazione è basata sull’area di controllo:

o segnali di registrazione, ammissione e stato (RAS): forniscono il controllo pre-

chiamata nelle reti basate su gatekeeper H.323;

o segnali di controllo della chiamata: usati per connettere, mantenere e disconnettere

le chiamate fra i terminali;

o controllo e trasmissione sul mezzo trasmissivo: fornisce il canale affidabile H.245

che trasmette i messaggi di controllo del mezzo trasmissivo. Il trasporto utilizza un

flusso UDP inaffidabile.


76

Le operazioni più importanti nello standard H.323 sono:

o l’attivazione del canale RAS con la conseguente registrazione presso il

Gatekeeper e l’instaurazione di una chiamata. Il canale RAS è un canale di

comunicazione inaffidabile tra i terminali e il gatekeeper. Viene aperto prima che

venga attivato qualsiasi altro canale, e trasporta i messaggi RAS che svolgono le

procedure di registrazione, ammissione, variazione dell’ampiezza di banda, stato e

disconnessione;

o la ricerca del gatekeeper è un processo manuale o automatico utilizzato dai

terminali per identificare il gatekeeper sul quale si devono registrare. Con il

metodo manuale, i terminali vengono configurati con l’indirizzo IP del gatekeeper,

mentre il metodo automatico richiede un meccanismo di ricerca automatica, che

consente ad un terminale, che non conosce il proprio gatekeeper, di trovarlo

tramite l’invio di un messaggio multicast;

o la registrazione è il processo che consente ai gateway, ai terminali e alle unità

MCU di collegarsi ad una zona e fornire al gatekeeper i propri indirizzi IP e alias.

4.2.3 SIP

Il SIP (Session Initiation Protocol) [37] è un protocollo del livello applicazione che nasce

in ambito IETF come alternativa più semplice al sistema H.323, ed è utilizzato per

attivare, gestire e chiudere le sessioni multimediali.

Esso trova applicazione non solo nella telefonia su IP e nei servizi telefonici

supplementari, ma anche nella video-comunicazione, nei giochi interattivi, nella

messaggistica istantanea.

Il protocollo SIP ha fondamentalmente le seguenti funzioni:

o invitare gli utenti a partecipare ad una sessione;

o localizzare gli utenti;

o acquisire le preferenze degli utenti;


77

o determinare la capacità degli utenti, cioè le caratteristiche dell’utente in termini di

risorse audio/video e i parametri da usare;

o trasportare una descrizione della sessione;

o instaurare le connessioni di sessione;

o setup della chiamata, cioè la gestione di eventuali modifiche dei parametri di

sessione;

o rilasciare le parti;

o cancellare la sessione in qualunque momento si desideri.

SIP è un protocollo text-based, orientato al Web, simile ad HTTP, con una struttura client-

server. Questa scelta porta anche ad una facilità di integrazione con Internet: poiché gli

indirizzi utilizzati da SIP sono strutturati in maniera identica a quelli di posta elettronica,

l’integrazione nelle pagine Web è intuitivamente identica.

Per instaurare una sessione, avviene un three-way handshaking (Request, Response, Ack -

concettualmente simile a quello che avviene con il protocollo TCP).

Tra le sue caratteristiche peculiari vi è l’idea di inserire l’intelligenza, ove possibile, ai

bordi della rete, lasciando alla rete il suo compito peculiare di smistamento dei messaggi,

ottenendo qui eccellenti caratteristiche di scalabilità.

La suite SIP definisce componenti piccoli e mono-funzionali, in modo da evitare la

duplicazione di funzioni e far sì che siano modulari, a differenza di quello che succede in

H.323 dove per una funzione elementare sono necessarie iterazioni di più protocolli.

Il protocollo SIP, per questioni di semplicità, non specifica la trasmissione dei dati

audio/video (e dati), demandando questo compito al già collaudato protocollo RTP/RTCP.

Per lo stesso motivo non si preoccupa di riservare la banda per una chiamata.

In particolare, SIP può inviare al terminale chiamato/invitato le informazioni necessarie

per l’allocazione di risorse sulla rete: è fortemente integrato, infatti, con il protocollo SDP

(Session Description Protocol), e con RSVP (Resource reSerVation Protocol) [37] che


78

hanno il compito di dare una descrizione dettagliata delle risorse necessarie

all’instaurazione della chiamata e di riservarle.

Il protocollo SIP supporta la mobilità ed è dialog-oriented: un dialogo è una relazione

persistente tra entità paritetiche che si scambiano richieste e risposte in un contesto

comune.

Per quanto riguarda l’indirizzamento, lo standard prevede che ogni utente abbia un

indirizzo SIP: dunque l’indirizzo è proprio dell’utente, non del terminale.

Gli indirizzi (le cosiddette SIP URL) hanno la forma del tipo [email protected],

quindi sono simili a indirizzi e-mail. La parte iniziale dell’indirizzo (nomeutente) è il

nome dell’utente o un numero telefonico, la parte finale (dominio.com), può essere il

nome di dominio oppure un indirizzo di rete.

Grazie a questo meccanismo, SIP supporta anche l’interlavoro con la rete telefonica

classica: un indirizzo nella forma [email protected] può indicare la volontà di

raggiungere l’utente telefonico indicato attraverso un gateway tra mondo IP e mondo

telefonico presso l’università Federico II di Napoli (in questo caso si deve indicare,

attraverso il parametro user=phone, che l’identificativo è un numero telefonico).

Passiamo ad analizzare l’architettura SIP: i componenti fondamentali sono gli User Agent

e i server di rete.

Gli User Agent sono applicazioni operanti sul sistema terminale che includono due

componenti [38]:

o User Agent Client: si occupa delle procedure necessarie a far partire una chiamata;

o User Agent Server: riceve le richieste di chiamate in arrivo e restituisce le risposte

dell’utente chiamato.


79

Figura 4.3 - User Agent Client (UAC) e User Agent Server (UAS) nello scambio di un messaggio INVITE tra un chiamante e due chiamati

Il Proxy Server [37] è un server intermedio; può rispondere direttamente alle richieste

oppure instradarle ad un client, ad un server o ad un ulteriore proxy. Un proxy server

analizza i parametri di instradamento dei messaggi e “nasconde” la reale posizione del

destinatario del messaggio, essendo quest’ultimo indirizzabile con un nome convenzionale

del dominio di appartenenza. Il vantaggio nel suo utilizzo sta nel fatto che al proxy server

può essere delegata in toto la gestione della chiamata, ragion per cui i terminali utente non

devono preoccuparsi di tutte le procedure di segnalazione nella loro interezza.

Il Redirect Server [37] accetta le richieste SIP e invia al client una risposta di redirezione

contenente l’indirizzo del server successivo. Questo tipo di server non accetta chiamate e

non elabora o inoltra le richieste SIP.

Il Location Server [37] implementa un servizio di risoluzione degli indirizzi: è dunque un

database contenente informazioni sull’utente, come il profilo, l’indirizzo IP, l’URL.


80

Il Registrar Server [37] è un server dedicato o collocato in un proxy. Quando un utente è

iscritto ad un dominio, invia un messaggio di registrazione del suo attuale punto di

ancoraggio alla rete ad un Registrar Server.

Il Multi Conference Unit [37] è un oggetto in grado di realizzare chiamate tra tre o più

persone, con le stesse caratteristiche dell’analogo componente presente in H.323.

Figura 4.4 - Una generica infrastruttura SIP

Un messaggio SIP [37] è una richiesta (attivata dai client) o una risposta (restituita dai

server); la sequenza di una richiesta e una o più risposte è detta transazione SIP: una

transazione è identificabile da un transaction-ID, un identificativo che ne specifica la

sorgente, la destinazione e il numero di sequenza. E’ possibile trasmettere le transazioni

SIP sia in UDP che in TCP.

Ogni messaggio contiene un’intestazione che descrive i dettagli della comunicazione,

specificando il chiamante, il chiamato, il percorso e il tipo di messaggio contenuto in una

chiamata.

I messaggi SIP per il controllo delle chiamate sono in formato testo, molto simili a quelli

usati da HTTP per lo scambio di pagine Web. I messaggi sono di richiesta e di risposta.

Gli UAC inviano messaggi di richiesta. Questi vengono instradati fino a giungere agli

UAS di destinazione i quali spediranno le risposte.

I messaggi di richiesta SIP sono [38]:


81

o REGISTER: messaggio inviato da uno User Agent quando vuole registrare presso

un Registrar Server il proprio punto di ancoraggio alla rete;

o BYE: utilizzato per porre fine ad un dialogo SIP;

o CANCEL: per terminare un dialogo se la sessione non ha ancora avuto inizio;

o INVITE: serve ad invitare un utente a partecipare ad una sessione;

o ACK: è un messaggio di riscontro;

o TRYING e RINGING: messaggi provvisori, mantengono i parametri della

richiesta a cui rispondono;

o SUBSCRIBE e NOTIFY: utilizzati per l’e-Presence.

Le risposte, analogamente a HTTP, sono rappresentate da un codice di stato di tre cifre di

cui la prima identifica la tipologia di risposta:

o (1XX) Provisional: la richiesta è stata ricevuta, ma il server la sta ancora

processando;

o (2XX) Success: la richiesta ha avuto successo;

o (3XX) Redirection: la richiesta deve essere smistata ad un nuovo indirizzo;

o (4XX) Request Failure: la richiesta non è andata a buon fine;

o (5XX) Server Failure: il server non riesce a processare la richiesta;

o (6XX) Global Failure: nessun server può elaborare la richiesta.

Ecco un esempio di messaggio INVITE [37]:

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 134.102.18.1 ‘‘//identifica l’originatore della richiesta ‘‘ From: <sip:[email protected]>; tag = 4711 ‘‘//identifica la destinazione logica di una richiesta’’ To: Domenico <sip:[email protected]> ‘‘//è un valore costante che identifica l’invito’’ Call-Id: [email protected] ‘‘//ordina le transazioni (..la prossima richiesta avrà Cseq=50)’’ Cseq: 49 Invite ‘‘//il body consiste in 117 byte ‘‘ Content-Length: 117 ‘‘//tipo di media descritto secondo il protocollo [[SDP]]’’ Content-Type: application /sdp


82

Subject: felicitazioni! ‘‘//l’oggetto del messaggio’’ ‘‘//l’indirizzo al quale si desidera ricevere richieste’’ Contact: sip:[email protected]:4050 ‘‘//specifica il protocollo di trasporto, ‘‘ ‘‘//nell’esempio [[User Datagram Protocol|UDP]]’’ transport = udp v = 0 ‘‘//indica la versione in uso’’ ‘‘//l’owner della risorsa con un ID di sessione’’ o = jack 7564657 9823872 IN IP4 134.102.18.1 ‘‘//tipo di rete, la versione del protocollo IP e l’IP stesso ‘‘ c = IN IP4 134.102.18.1 t = 0 0 ‘‘//tempo di start e di stop’’ ‘‘//tipo di media, num. Di porto, protocollo di trasporto e formato ‘‘ m = audio 4754 RTP/AVP 0 a = rtpmap: 0 PCMU/8000 ‘‘//attributi audio\video.. se ce ne fossero ‘‘ s = festa ‘‘//subject della sessione’’

Ulteriori dettagli sul protocollo SIP possono essere trovati nel documento RFC (Request

For Comments) 2543: se ne trova una sua copia online all’indirizzo

http://www.ietf.org/rfc/rfc2543.txt.

4.2.4 IAX

IAX [37] è un acronimo che sta per Inter Asterisk Xchange. È un protocollo utilizzato da

Asterisk, un server PBX open-source della Digium. Si usa per abilitare connessioni VoIP

tra i server Asterisk e tra server e client che utilizzano lo stesso protocollo.

IAX ora è comunemente indicato come IAX2, la seconda versione del protocollo IAX. Il

protocollo originale IAX è obsoleto ed è disapprovato in funzione di IAX2.

Il progetto del protocollo IAX fu basato su vari standard di controllo e trasmissione tra cui

SIP, Media Gateway Control Protocol (MGCP) e RTP. Il protocollo IAX2 fu creato da

Mark Spencer per Asterisk per la gestione delle chiamate VoIP. Esso è un protocollo

robusto e completo rimanendo al contempo semplice. È indipendente dal codec e dal

numero di flussi, quindi può essere usato in teoria per il trasporto di qualunque tipo di dato

(questa caratteristica diventerà utile quando il videotelefono diventerà comune).


83

IAX2 utilizza un singolo flusso dati UDP (di solito sulla porta 4569) per comunicare tra i

due sistemi sia per il controllo che per i dati. Il traffico voce è trasmesso in banda

rendendo più semplice per l’IAX2 l’attraversamento di un firewall ed è più probabile che

lavori dietro una rete con NAT (il protocollo SIP invece utilizza un flusso fuori banda

RTP per il trasporto delle informazioni).

Il protocollo IAX2 supporta il trunking per trasportare su un singolo collegamento dati e

segnali per più canali. Quando è attivo il trunking più chiamate sono unite in un singolo

insieme di pacchetti, quindi un singolo datagramma IP può trasportare informazioni

relative a più chiamate riducendo l’effettivo overhead senza creare ritardi addizionali.

Questo è un vantaggio notevole per gli utilizzatori del VoIP dove le intestazioni IP

occupano una grossa percentuale della larghezza di banda.

4.3 QoS e codec

Le reti IP non dispongono di per sé di alcun meccanismo in grado di garantire che i

pacchetti di dati vengano ricevuti nello stesso ordine in cui vengono trasmessi, né alcuna

garanzia relativa in generale alla qualità di servizio. Le attuali applicazioni nel mondo

reale della telefonia VoIP si trovano a dover affrontare problematiche legate a problemi di

latenza (sostanzialmente si deve ridurre il tempo di transito e di elaborazione dei dati

durante le conversazioni) e di integrità dei dati (prevenire perdite e danneggiamenti delle

informazioni contenute nei pacchetti).

Il problema di fondo della tecnologia VoIP è la corretta ricostruzione dei pacchetti di dati

ricevuti [37] [38], tenuto conto del fatto che durante la trasmissione può cambiare la

sequenza dei pacchetti e che alcuni pacchetti possono aver subito perdite o

danneggiamenti delle informazioni contenute, e assicurare così che il flusso audio

mantenga la corretta coerenza temporale. Altro importante problema è mantenere il

tempo di latenza dei pacchetti sufficientemente basso, in modo che l’utente non debba

aspettare troppo tempo prima di ricevere le risposte durante le conversazione.


84

Riportiamo di seguito alcuni problemi e le relative possibili soluzioni [34]:

o alcuni router possono essere configurati per distinguere via hardware i pacchetti

VoIP dagli altri, ed assegnare di conseguenza ad essi una priorità maggiore;

o è possibile memorizzare in un buffer i pacchetti, per rendere la trasmissione più

asincrona, ma ciò può tradursi in un aumento del tempo di latenza, simile a quello

delle trasmissioni satellitari;

o il gestore della rete dovrebbe garantire una larghezza di banda sufficientemente

ampia, per ridurre il tempo di latenza e le perdite di dati. Tuttavia ciò, mentre è

relativamente facile nelle reti private, è molto più difficile quando si usa Internet

come mezzo trasmissivo;

o con velocità minori di 256 kbit/s possono aversi problemi di jitter (letteralmente:

nervosismo; tecnicamente: errore nella base dei tempi, quando un campione

digitale è convertito in segnale analogico). Infatti, su reti lente, il ritardo di

trasmissione diventa rilevante, e di conseguenza i protocolli di VoIP utilizzano

pacchetti più piccoli della dimensione massima (generalmente 1500 bytes, secondo

MTU). Altri protocolli basati tipicamente su TCP, usano invece normalmente

pacchetti di dimensione massima. Se un pacchetto di una connessione VoIP arriva

al commutatore mentre è in trasmissione un pacchetto di dimensione massima

appartenente ad un’altra connessione, subirà un ritardo importante, e soprattutto

non costante.

La QoS che si può garantire dipende anche dal codec adottato per la trasmissione.

La funzione del codec (Coder/Decoder) è di convertire i segnali analogici in digitale e

viceversa, affinché il segnale audio sia adatto a viaggiare su reti IP [37] [39].

Quando si vuole implementare un servizio VoIP tale che possa interagire anche con la rete

telefonica tradizionale, è necessario adottare nell’implementazione uno o più codec tale

che permettano di effettuare uno streaming audio compatibili con la linea analogica. In

generale, il discorso si estende quando vogliamo chiamare applicativi che non supportano


85

il nostro stesso codec: in altre parole, abbiamo bisogno di effettuare una conversione di

formato audio verso un codec comune ai due interlocutori.

I codec generalmente hanno capacità di compressione per salvare la larghezza di banda.

Il vantaggio di utilizzare un codec molto compresso consiste nel minor numero di

pacchetti da inviare (ad esempio un pacchetto può arrivare a “contenere” 1 secondo di

parlato), accompagnato da un minor consumo di banda. Utilizzando un codec meno

compresso, che quindi occupa più banda, invece avremo una maggiore “qualità della

comunicazione”. Ad esempio, si supponga che un pacchetto possa “contenere” 0.2 secondi

di parlato: nel caso in cui vi siano pacchetti “persi per strada” si riesce comunque a capire

il proprio interlocutore. Alcuni codec addirittura “riconoscono” il silenzio ed effettuano

una soppressione dei pacchetti riconosciuti come tali, evitando di trasmetterli sulla rete.

Menzioniamo di seguito (Tabella 4.1) alcuni dei codec più diffusi nelle applicazioni VoIP

[39]:

CODEC BIT RATE

(Kbps) SAMPLING RATE (KHz)

FRAME SIZE

(ms)

iLBC 8 13.3 30

ITU G.711 (alaw/ulaw) 64 8 campionamento

ITU G.722 64 16 campionamento

ITU G.723.1 5.6/6.3 8 30

ITU G.726 16/24/32/40 8 campionamento

ITU G.728 16 8 2.5

ITU G.729 8 8 10

Speex 8/16/32 2.15-24.6/4-44.2 30/34

Tabella 4.1 – Caratteristiche dei codec comunemente usati nelle applicazioni VoIP


86

4.4 Soluzioni per il VoIP

Per realizzare delle soluzioni VoIP è chiaro che risulta necessario avere tanto un server

proxy, che tenga traccia dei VoIP device/utenti registrati e ne smisti le telefonate (PBX),

quanto un “telefono” software (softphone) o hardware (telefono VoIP) a disposizione

dell’utente.

Di seguito riporteremo una breve analisi delle soluzioni attualmente presenti sul mercato.

4.4.1 Asterisk

Asterisk [37] [39] è un software open-source sviluppato dalla Digium (www.digium.com)

in ambiente Linux che permette di realizzare a basso costo una soluzione completa di PBX

VoIP, ossia una vera e propria centralina telefonica per uso privato.

Il suo nome, Asterisk, proviene dal mondo Unix e Dos dove rappresenta un cosiddetto

“carattere jolly” (*), cioè la possibilità di rappresentare ogni file.

In modo simile, Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato

telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica

standard, in modo semplice e consistente. Essendo Asterisk un progetto open-source, esso

è rilasciato sotto licenza GNU GPL ed è possibile per tutti accedere al suo contenuto

liberamente.

Asterisk supporta tre protocolli VoIP: IAX (sviluppato specificatamente per Asterisk

stesso), SIP e H.323.

In particolare, Asterisk è un sistema ibrido, poiché utilizza sia la tradizionale tecnologia

TDM (Time-Division Multiplexing) che i protocolli del packet voice (Voice over IP e

Voice over Frame Relay).

Esso si comporta come un PBX completo, supportando virtualmente tutte le caratteristiche

della chiamata convenzionale.

Allo stesso tempo, è un IVR (Interactive Voice Response), cioè offre un servizio di

risposta automatico con operatore virtuale, completamente programmabile.


87

Alla base del funzionamento di Asterisk ci sono i dialplan (ovvero “piano di chiamata”):

è la parte più interessante della configurazione di Asterisk, ed anche quella che richiede

più tempo. Nel dialplan si definisce cosa deve fare il PBX quando riceve una chiamata,

oppure quando un utente compone un numero.

Per semplificare la configurazione e la gestione di Asterisk esistono diverse versioni,

anche Live CD, che permettono di caricare in un’unica istallazione il sistema operativo e i

software necessari, compresa un’interfaccia grafica (GUI Web Oriented), come

EasyAsterisk. Inoltre, esistono diversi framework che facilitano l’interazione con Asterisk,

soprattutto dal punto di vista amministrativo.

In tal ambito si colloca Asterisk-Java. Si tratta di un progetto, attualmente alla release 0.3,

orientato allo sviluppo di un framework Java utile per dar vita ad applicazioni in grado di

interagire con Asterisk.

L’interazione avviene grazie al supporto delle interfacce Manager API e FastAGI. In

pratica, Asterisk-Java propone un set di classi Java per sfruttare API in grado di impartire

dei comandi ad Asterisk o di conoscere gli eventi generati dal PBX open-source.

Inoltre è possibile utilizzare un canale di comunicazione TCP/IP per operare il controllo

remoto del centralino software tramite la Asterisk Gateway Interface (AGI), di cui il

progetto offre una implementazione in Java e un tutorial sufficientemente esaustivo.

4.4.2 sipXpbx

Il software sipXpbx è un progetto open-source sviluppato dalla Sipfoundry

(http://www.sipfoundry.org/) con l’appoggio della Pingtel (http://www.pingtel.com/). La

gestione evolutiva del software è affidata ad una comunità attiva.

Il software anche in questo caso implementa le funzionalità di un SIP proxy server. Oltre

alle classiche funzioni legate al SIP server, come l’inoltro delle chiamate e la registrazione

degli utenti SipX, offre delle funzionalità avanzate come Voice-mail, Call Park e IVR.

Tramite un’interfaccia Web è possibile provvedere alla configurazione di tutti i servizi.

Il software è scritto in linguaggio C/C++ ed è composto da tre moduli principali:


88

o sipX Communications Server: offre i servizi SIP base, ovvero proxy server,

redirect e register;

o sipX Media Server: offre i servizi avanzati come IVR e Voice mail;

o sipX Configuration Server: permette la configurazione del Media Server.

Inoltre questi tre moduli si appoggiano a delle librerie che sono distribuite separatamente,

in particolare SipXtacklib che implementa le istruzioni base per l’instaurazione e la

gestione delle chiamate. Ad esempio, è possibile partendo da questa libreria implementare

un User Agent Client.

Il server può essere statefull o stateless rispetto alle transizioni, rispetto ai dialoghi solo

stateless.

Il software fornisce delle SOAP API per quanto riguarda la configurazione del

Communication server e del Media Server.

Nel caso della funzione statefull abilitata, esiste un file di log degli stati. Non c’è la

possibilità di inviare questa informazione tramite porta TCP, come avviene per Asterisk.

Per implementare funzioni di questo genere è necessario implementarle utilizzando le

librerie a disposizione.

4.4.3 Jabber/XMPP: Openfire, Spark e Asterisk-IM

Jabber è una piattaforma di messagistica istantanea open-source, basata sul protocollo

XMPP (un’estensione del protocollo XML). Offre numerosi servizi nel campo della

messagistica come: la chat fra due o più persone, la possibilità di conoscere la presenza in

rete di qualcuno (e-presence). Non è un client multi-protocollo, ma molti server Jabber

funzionano come gateways per i servizi di IM. La comunità di Jabber è concentrata nella

costruzione di una vera alternativa agli altri servizi di IM, proponendo agli utenti che lo

utilizzeranno la possibilità di:

o avere un software open-source;

o poter creare una rete Jabber privata (dietro a un firewall) o una rete globale e

pubblica;

o comunicare con client di altre reti, come se questi fossero utenti Jabber.


89

Un’implementazione open-source del protocollo Jabber è OpenFire Server, molto

semplice da installare e amministrare. Usando il client IM/VoIP Spark, realizzato dalla

stessa comunità di Openfire (http://www.igniterealtime.org/), si possono effettuare

telefonate VOIP PC-to-PC. Anche Spark è un progetto Java open-source, esso provvede

ad impacchettare l’audio in un formato coerente con il protocollo XMPP e inoltrarlo al

server Openfire, il quale smisterà i pacchetti verso la giusta destinazione, garantendo il

real-time.

In seno alla stessa comunità è nato Asterisk-IM (componente di integrazione con Asterisk

per Jive’s Jabber/XMPP server); esso è un modulo lato server che permette di lavorare

con qualsiasi client che usi il protocollo XMPP integrando le funzionalità di e-presence

tipiche dell’Instant Messaging e l’attività PBX di un server Asterisk. In pratica, grazie al

plug-in Asterisk-IM, si associa ad un utente registrato presso il server Jabber un device

VoIP che l’utente IM potrà utilizzare per effettuare le sue chiamate.

4.4.4 MjSIP e altre soluzioni open-source Java

Riportiamo di seguito alcune soluzioni open-source Java per il VoIP. Tutte le soluzioni

sono pensate per macchine desktop. Studieremo la possibilità di adattare almeno una di

queste soluzioni ai dispositivi mobili.

MjSip (http://www.mjsip.org/) è un progetto open-source di un SIP stack, realizzato

completamente in Java dall’Università di Parma e dall’Università “Tor Vergata” di Roma.

Questo progetto include le API complete per creare un’applicazione VoIP, basata su

protocollo SIP e RTP. Comprende anche l’implementazione di diversi codec, tra cui

G.711 e PCMU.

MjSIP include tutte le classi e i metodi per creare applicazioni basate su SIP. Esso

implementa i livelli dell’architettura SIP Stack come definito nella specifica RFC 3261 ed

è totalmente conforme allo standard.


90

In più, include l’implementazione di un’interfaccia per il controllo delle chiamate e di

User Agent.

MjSIP può essere scaricato dal sito di riferimento e comprende, oltre a quanto già detto, un

proxy server fedele al MjSIP Stack.

MjSIP fornisce anche il servizio di IM. Il progetto al momento sembra sospeso; tra le

specifiche dello stesso, sembrano esserci anche le funzioni tipiche della videochiamata.

Del progetto ne esiste anche una corrispondente versioni J2ME per l’IM.

SIP Communicator (http://www.sip-communicator.org/) è un telefono audio/video via

Internet e un instant messanger scritto in Java, in grado di supportare alcuni dei più

popolari protocolli per IM e per il VoIP come SIP, IAX, Jabber, AIM/ICQ, MSN e altri

come Yahoo e IRC.

Il progetto è in pieno sviluppo. La comunità sembra non aver contemplato l’idea di

un’analoga soluzione per il mobile. La comunità OITOS (http://www.oitos.it/) ha fatto una

valutazione del prodotto secondo la quale SIP Communicator sembra ancora essere

lontano da una soluzione ideale.

Jeti (http://jeti.sourceforge.net/) è un progetto Java nato come client Jabber. Esso supporta

le principali funzionalità di chat tra cui il trasferimento file, group chat, emoticons e la

formattazione dei messaggi. Può essere usato come applicativo o come Web applet.

Per Jeti esistono numerosi plug-in, tra cui Jingle che aggiunge al progetto la funzione di

client VoIP. Attualmente, nella versione beta, è stato rilasciato JetiVoip. Come SIP

Communicator, Jeti include i codec jSpeex, ovvero un’implementazione Java del codec

Speex.

4.4.5 Soluzioni e client VoIP per il Mobile

Riportiamo di seguito una panoramica sulle soluzioni più conosciute per il mobile VoIP.


91

Skype (http://www.skype.com/) è un protocollo chiuso che realizza la fonia VoIP.

L’omonimo programma, già disponibile da tempo per diversi sistemi operativi, è anche

disponibile per PocketPC (Windows Mobile).

Dietro l’acquisto di un credito, Skype permette di chiamare in oltre trenta paesi del mondo

a tariffe vantaggiose, oltre che parlare gratis tra gli utenti Skype nazionali.

Skype supporta anche l’Instant Messaging, fino ad un gruppo chat di cento persone, e le

videochiamate.

iSkoot (http://www.iskoot.com/) è un software che consente di collegare il proprio

telefono cellulare a Skype in modo da poter chiamare sfruttando la tecnologia VoIP.

iSkoot, disponibile a pagamento solo per Windows Mobile, permette di:

o inoltrare le chiamate dal PC al telefono cellulare;

o chiamare i propri contatti dal telefono cellulare

o “spostare” una chiamata dal PC al telefono senza disconnettersi.

Per realizzare questo è necessario ovviamente lasciare il PC acceso, collegato ad Internet e

avere Skype in esecuzione.

Da quando Palm, azienda specializzata nella produzione di palmari, ha introdo il Wi-Fi

nel proprio mondo, sono nate anche soluzioni VoIP per PalmOS, il sistema operativo

distribuito dalla Palm. La software house MantraGroup, specializzata in soluzioni wireless

per computer palmari, ha realizzato mobiVoIP (http://www.mobivoip.net/), la prima

soluzione VoIP specificamente indirizzata ai palmari e agli smartphone basati su PalmOS.

I requisiti per usare mobiVoIP sono, ovviamente, un dispositivo basato su PalmOS in

grado di connettersi a Internet via Bluetooth, Wi-Fi o EV-DO. Gli utenti di mobiVoIP

potranno chiamare qualunque utente mobiVoIP o un qualsiasi telefono fisso direttamente

dal PDA. La tariffazione è basata su un abbonamento mensile con diversi piani tariffari

pensati per il Nord America e altri paesi, tra cui l’Italia.


92

Fring (http://www.fring.com/) è l’unica soluzione VoIP-IM per cellulari che non sfrutti

qualche forma di callback per offrire chiamate verso utenti. Fring sfrutta un protocollo

proprietario con cui trasporta la chiamata dal client installato sul cellulare ai server Fring,

da cui poi viene convertita per collegarsi alla rete Skype, Gtalk o PSTN. Fring è

disponibile per Symbian OS e Windows Mobile.

Il servizio Gizmo dedicato al mondo dei dispositivi portatili è Gizmo5

(http://gizmo5.com/), un software Java che integra diversi servizi:

o chiamate VoIP verso chiunque, utilizzando il credito del proprio account Gizmo;

o chat con gli utenti dei servizi Gizmo, MSN, AIM, Yahoo e Jabber, tra cui GTalk;

o verificare la presenza online dei propri contatti;

o inviare e ricevere file, anche tra PC e telefono cellulare.

Molto interessante la possibilità di aggiungere come contatto una URI Sip, per poter

chiamare numerazioni IP gratuitamente dal proprio telefono cellulare.

SJphone (http://www.sjlabs.com/) è uno dei software VoIP più noti ed utilizzati, in

particolare è spesso offerto in combinazione con i servizi dei maggiori operatori VoIP. E’

disponibile per i sistemi PDA dotati di PocketPC 2002/2003/2003SE, Windows CE.NET

4.0/4.2/5.0, Windows Mobile 5.0.

SJphone è compatibile con i due principali standard di segnalazione delle chiamate, SIP e

H.323 e funziona quindi con moltissimi operatori VoIP e sistemi IP-PBX. E’ possibile

configurare diversi “servizi” (solitamente legati alla scelta di un operatore) e passare in

modo semplice da uno all’altro. I codec disponibili per la trasmissione del segnale vocale

sono G.711 A/u, GSM, Speex e iLBC.

Minisip (http://www.minisip.org/) è un framework SIP open-source sviluppato durante

una tesi di laurea in Svezia. Supporta voce, video e IM. E’ cross platform e compila anche

su Linux IPAQ e presto sarà disponibile per Windows Mobile.


93

Minisip effettua le caratteristiche supplementari di sicurezza quali l’autenticazione, la

crittografia e l’integrità reciproche delle chiamate on-going e la crittografia della

segnalazione (SIP sopra TLS, lo standard IETF di SSL).

Passiamo ora al progetto del nostro componente VoIP da integrare nel framework descritto

nel capitolo precedente.

4.5 Progetto del componente VoIP

Nella fase di analisi e nelle varie fasi della progettazione del componente VoIP ci

serviremo dei diagrammi UML.

4.5.1 Analisi dei requisiti

Nella fase di Analisi dei Requisiti vengono individuati e rappresentati i requisiti del

servizio ed evidenziate le funzionalità del servizio stesso. Il prodotto della fase di analisi è

il seguente Diagramma dei Casi d’uso (Figura 4.5).

Lista degli attori

UtenteGenerico: Rappresenta un utente non ancora registrato, privo di account SIP.

UtenteRegistrato: Rappresenta un utente registrato, avente un account SIP.

Lista dei casi d’uso

Registrazione

Login

EffettuaChiamata

AccettaChiamata

TerminaChiamata

Logout

Cancellazione


94

Registrazione

Login

EffettuaChiamata

TerminaChiamata

Logout

UtenteGenerico

UtenteRegistrato

AccettaChiamata

Cancellazione

Figura 4.5 - Diagramma dei Casi d’uso

Riportiamo la descrizione dei casi d’uso presenti nel diagramma. Per facilitarne sia la

descrizione che la comprensione, adotteremo una terminologia SIP compliant,

supponendo di aver adottato il protocollo SIP per il controllo della chiamata.

Caso d’uso Registrazione

Nome: Registrazione

Descrizione: Consente la registrazione di un nuovo utente.

Passi del caso d’uso Registrazione:

1. L’UtenteGenerico fornisce i suoi dati personali (nome, cognome, email) al SIP

server presso cui vuole registrarsi (realm);

2. Il SIP server fornisce all’utente lo username e la password (SipURL =

username@realm);

3. Qualora lo preveda, il server può fornire all’utente registrato un numero geografico

(geoNumber) su cui può essere raggiunto dalla rete telefonica tradizionale.


95

Estensione del caso d’uso Registrazione:

2. Utente già registrato

2.a Ritorno al punto 1

Caso d’uso Login

Nome: Login

Descrizione: Consente l’autenticazione dell’utente presso in SIP server remoto.

Un utente può avere più account SIP: i dati essenziali di ciascun account SIP sono

username, password, realm. Il metodo Login verifica la validità dei dati.

Passi del caso d’uso Login:

1. L’UtenteRegistrato fornisce i dati relativi al suo account (username, password,

realm);

2. Il SIP server apre una sessione con l’utente autenticato e attiva lo User Agent

(UA);

3. L’utente autenticato può accedere alla lista personale utenti.

Estensione del caso d’uso Login:

2. Dati non corretti


Precondizione per il caso d’uso Login:

L’UtenteRegistrato deve essere registrato presso il SIP server (realm).

Caso d’uso EffettuaChiamata

Nome: EffettuaChiamata

Descrizione: Consente ad un utente, autenticato presso un SIP server remoto, di effettuare

una telefonata VoIP.


96

Passi del caso d’uso EffettuaChiamata:

1. L’UtenteRegistrato chiede di effettuare una telefonata;

2. Lo stato della chiamata del chiamante passa nello stato OUTGOING_CALL;

3. L’UA dell’utente chiamato accetta la sessione del chiamante;

4. Lo stato del chiamato diventa INCOMING_CALL.

Estensione del caso d’uso EffettuaChiamata:

2. L’utente chiamato non è connesso/non esiste/è occupato in altra conversazione

2.a Il SIP server restituisce al chiamante un messaggio di CANCEL

3. L’utente chiamato rifiuta/non accetta la chiamata (caso d’uso TerminaChiamata)

3.a Il SIP server inoltra il messaggio di BYE all’UA chiamante

4. L’utente chiamante ha chiuso la chiamata

4.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE

Precondizione per il caso d’uso EffettuaChiamata:

L’UtenteRegistrato deve essere autenticato presso il SIP server remoto.

Lo stato della chiamata deve essere IDLE.

Nei casi di estensione 2-3 si noti che, qualora il SIP server lo preveda, può essere attivato,

a seguito del messaggio di CANCEL, il servizio di segreteria telefonica.

Caso d’uso AccettaChiamata

Nome: AccettaChiamata

Descrizione: Consente all’utente chiamato di accettare una telefonata in arrivo.

Passi del caso d’uso AccettaChiamata:

1. L’utente accetta una telefonata in arrivo;


97

2. Lo stato della chiamata, sia del chiamato che del chiamante, diventa ONCALL;

3. I due utenti possono parlare.

Estensione del caso d’uso AccettaChiamata:

2. L’utente chiamante ha chiuso la chiamata

2.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE

Precondizione per il caso d’uso AccettaChiamata:

La chiamata del chiamato deve essere nello stato INCOMING_CALL

Caso d’uso TerminaChiamata

Nome: TerminaChiamata

Descrizione: Consente di terminare una chiamata.

Passi del caso d’uso TerminaChiamata:

1. L’UtenteRegistrato termina la chiamata;

2. La chiamata torna nello stato IDLE.

Precondizione per il caso d’uso TerminaChiamata:

La chiamata deve essere in uno stato diverso da IDLE.

Caso d’uso Logout

Nome: Logout

Descrizione: Consente di disconnettersi dal SIP server remoto.

Passi del caso d’uso Logout:

1. L’UtenteRegistrato chiede di disconnettersi;

2. Viene chiusa un’eventuale chiamata che non sia in stato IDLE;

3. L’UtenteRegistrato risulta disconnesso.


98

Precondizione per il caso d’uso Logout:

L’UtenteRegistrato deve essere connesso.

Caso d’uso Cancellazione

Nome: Cancellazione

Descrizione: Consente di cancellare un utente registrato dal SIP server.

Passi del caso d’uso Registrazione:

1. L’UtenteRegistrato fornisce il suo username e la password al SIP server (realm)

presso cui è registrato;

2. Il SIP server comunica l’avvenuta cancellazione.

Estensione del caso d’uso Registrazione:

2. Utente non registrato


4.5.2 La fase di progettazione

Iniziamo qui la fase di progettazione del componente VoIP. Tramite il Diagramma di

Distribuzione (Figura 4.6) andiamo a mostrare qual è l’environement in cui si troverà ad

operare. L’obiettivo è far risiedere il componente sul dispositivo mobile. Esso interagirà

con un server remoto di cui utilizzerà i servizi; nella progettazione che segue, supponiamo

che il server sia SIP compliant, compatibilmente a quanto assunto in precedenza per i casi

d’uso.

Il componente VoIP che svilupperemo fa parte del framework di servizi presentato nel

capitolo precedente. Accederemo al framework, e in particolare al servizio VoIP, tramite

un client VoIP che potrà essere implementato non necessariamente in Java, bensì, per

esempio, in C#, secondo il requisito richiesto di trasparenza al linguaggio.

Passiamo ora alla vista delle classi che compongono i package coinvolti.


99

SIP server

mobile device A mobile device B mobile device C

Framework

Componente VoIP

Framework Framework

Componente VoIP Componente VoIP

VoIP client VoIP clientVoIP client

SIP Server

Figura 4.6 - Diagramma di Distribuzione

Package VoIPComponent

A partire dal diagramma dei casi d’uso, l’interfaccia dei metodi per il nostro componente

VoIP sarà la seguente (Figura 4.7):

InterfacciaVoIPComponent

+++++++

registrazione (UtenteGenerico utenteGenerico, String realm)cancellazione (String username, String password, String realm)login (String username, String password, String realm)logout ()effettuaChiamata (String targetSipURL)accettaChiamata ()terminaChiamata ()

: UtenteRegistrato: void: void: void: void: void: void

Figura 4.7 - Interfaccia dei metodi esposti dal componente VoIP

Tale interfaccia, attraverso il framework, permetterà alle applicazioni utente (in particolare

ad un client VoIP) di accedere ai metodi in essa elencati, progettati e sviluppati, sulla base

del seguente Diagramma delle Classi (Figura 4.8):


100

1..1

1..1

1..1

0..1

1..* 1..1

1..1

1..1

UtenteRegistrato

----

usernamepasswordrealmgeoNumber

: String: String: String: String

UtenteGenerico

---

nomecognomeemail

: String: String: String

++

set ()get ()

: void: void

Direttorio

++

registrazione (UtenteGenerico utenteGenerico, String realm)cancellazione (String username, String password, String realm)

: UtenteRegistrato: void

Chiamata

- statoChiamata : int

+++-

effettuaChiamata (String targetSipURL)accettaChiamata ()terminaChiamata ()cambiaStato ()

: void: void: void: void

Sessione

++

apriSessione ()chiudiSessione ()

: void: void

Trasporto

++

apriCanale ()chiudiCanale ()

: void: void

UserAgent

-++

gestioneEventi ()login (String username, String password, String realm)logout ()

: void: void: void

Figura 4.8 - Diagramma delle Classi del componente VoIP

Il package VoIPComponent rappresenta il cuore del componente stesso, distribuito

all’interno del framework su dispositivi mobili.

E’ formato da diverse classi di cui daremo di seguito una breve descrizione.

Classe UtenteGenerico: tale classe rappresenta un utente non ancora registrato al SIP

server, privo di account; non è l’altro che l’attore che compare nel diagramma dei casi

d’uso del paragrafo precedente.

Classe UtenteRegistrato: tale classe rappresenta, invece, un utente già registrato con un

proprio account; è una specializzazione della classe precedente di cui eredita gli attributi.

Gli attributi username, password e realm, specifici di questa classe, servono proprio per

fornire un account unico all’utente registrato. Lo username in particolare sarà parte del

SipURL insieme con realm, che indica l’IP (in alcuni casi include anche la porta di

ascolto) del SIP server. Un utente può avere più account, anche presso SIP server diversi.

Questa classe non è altro che l’attore che compare nel diagramma dei casi d’uso del

paragrafo precedente. L’attributo geoNumber identifica il numero geografico con cui un


101

utente registrato, presso il SIP server, può essere telefonato dalla rete telefonica

tradizionale.

Classe Direttorio: è una classe priva di attributi; essa realizza alcuni metodi necessari per

offrire al utente determinate funzionalità, presenti anche nel diagramma dei casi d’uso,

come la registrazione.

Classe UserAgent: serve per aprire o chiudere una connessione con il SIP server, senza

necessariamente avviare una telefonata con qualche utente. La classe si mette in ascolto di

eventuali telefonate in arrivo e, in generale, si occupa di catturare gli eventi, oltre che di

tener traccia e gestire gli stati della telefonata.

Classe Sessione: rappresenta i metodi base del protocollo SIP; la composizione che lega

questa classe allo User Agent deriva dal fatto che, nel momento in cui viene allocato lo

User Agent, esso apre subito una sessione verso il SIP server.

Classe Trasporto: rappresenta i metodi base del protocollo di trasporto real-time e per la

gestione del canale audio. Tale classe interviene nel momento in cui la telefonata deve

essere instaurata e durante il corso della stessa.

Classe Chiamata: rappresenta la telefonata che si instaura fra due client. Essa è

caratterizzata da uno stato ed è gestita dalla classe UserAgent.

Package SIPServer

Dal punto di vista della nostra progettazione il SIP server è una black box a cui accediamo

tramite i servizi che un SIP server generalmente espone. Mostriamo di seguito la generica

interfaccia di un SIP server (Figura 4.9):


102

InterfacciaSIPServer

+++

registrazione (UtenteGenerico utenteGenerico)cancellazione (String username, String password)gestioneEventiSIP ()

: UtenteRegistrato: void: void

Figura 4.9 - Interfaccia dei metodi offerti dal SIP server

Secondo quanto mostrato nel diagramma di distribuzione, scendiamo ora nel dettaglio,

mostrando l’architettura e l’interazione tra tutti i package coinvolti nel caso del servizio

VoIP.

Un client VoIP, più in generale un’applicazione utente, che voglia usare il componente

VoIP, potrà accedervi grazie al Framework Core che aggiunge all’interfaccia del

componente i requisiti non funzionali già descritti nel precedente capitolo (Figura 4.10).

Passiamo al Diagramma di Sequenza (Figura 4.11) dove si suppone che i due utenti

(utenteRegistratoA e utenteRegistratoB) siano registrati presso un SIP server. Presentiamo

l’esecuzione dei seguenti casi d’uso, così come ordinati sulla linea del tempo:

o Login, che termina con successo, dell’utenteRegistratoA;

o EffettuaChiamata: l’utenteRegistratoA effettua una chiamata verso

l’utenteRegistratoB;

o AccettaChiamata: il destinatario accetta la chiamata e inizia la conversazione;

o TerminaChiamata: l’utenteRegistratoA decide di terminare la chiamata e il

protocollo SIP garantisce che la chiamata sia chiusa anche per l’utenteRegistratoB;

o Logout: l’utenteRegistratoA effettua il logout.

Si noti come, in ciascun scenario, al Framework Core sia demandato di filtrare ogni tipo

di messaggio o richiesta proveniente dall’applicazione utente o, dall’interno, da una delle

classi del componente VoIP, ovvero UserAgent e Chiamata.


103

Framework Core

1..1

1..1

1..1

0..1

Package VoIPComponent

1..* 1..1

1..1

1..1

UtenteRegistrato

----

usernamepasswordrealmgeoNumber

: String: String: String: String

UtenteGenerico

---

nomecognomeemail

: String: String: String

++

set ()get ()

: void: void

Direttorio

++

registrazione (UtenteGenerico utenteGenerico, String realm)cancellazione (String username, String password, String realm)

: UtenteRegistrato: void

Chiamata

- statoChiamata : int

+++-

effettuaChiamata (String targetSipURL)accettaChiamata ()terminaChiamata ()cambiaStato ()

: void: void: void: void

Sessione

++

apriSessione ()chiudiSessione ()

: void: void

Trasporto

++

apriCanale ()chiudiCanale ()

: void: void

SIPServer

UserAgent

-++

gestioneEventi ()login (String username, String password, String realm)logout ()

: void: void: void

InterfacciaSIPServer

+++

registrazione (UtenteGenerico utenteGenerico)cancellazione (String username, String password)gestioneEventiSIP ()

: UtenteRegistrato: void: void

Framework Core

InterfacciaVoIPComponent

+++++++

registrazione (UtenteGenerico utenteGenerico, String realm)cancellazione (String username, String password, String realm)login (String username, String password, String realm)logout ()effettuaChiamata (String targetSipURL)accettaChiamata ()terminaChiamata ()

: UtenteRegistrato: void: void: void: void: void: void

Client VoIP

Applicazione utente

Figura 4.10 - Vista completa del diagramma delle classi


104

ACK

INVITE

INVITE

gestioneEventi

accettaChiamata

cambiaStato

cambiaStato

apriSessione

apriCanale

apriSessione

apriCanale

loginREGISTER

terminaChiamata

gestioneEventi

chiudiSessione

chiudiCanale

cambiaStato

BYE/CANCEL

gestioneEventi

cambiaStato

effettuaChiamata

TRYING

RINGING

cambiaStato

cambiaStato

chiudiSessione

chiudiCanale

ACK invite

ACK bye/cancel

gestioneEventi

logoutBYE

ACK

utenteRegistratoA utenteRegistratoB

SIP serverUser Agent A User Agent BChiamata A Chiamata BFrameworkCoreA FrameworkCoreB

ACK

INVITE

INVITE

gestioneEventi

accettaChiamata

cambiaStato

cambiaStato

apriSessione

apriCanale

apriSessione

apriCanale

loginREGISTER

terminaChiamata

gestioneEventi

chiudiSessione

chiudiCanale

cambiaStato

BYE/CANCEL

gestioneEventi

cambiaStato

effettuaChiamata

TRYING

RINGING

cambiaStato

cambiaStato

chiudiSessione

chiudiCanale

ACK invite

ACK bye/cancel

gestioneEventi

logoutBYE

ACK

Figura 4.11 - Diagramma di Sequenza per i metodi: login, effettuaChiamata, accettaChiamata, terminaChiamata e logout

4.5.3 Test Case

Vengono presentati i Test case relativi alle funzionalità offerte dal componente VoIP,

ovvero dall’interfaccia del package VoIPComponent (InterfacciaVoIPComponent).


105

Lista dei metodi

Registrazione

Cancellazione

Login

Logout

EffettuaChiamata

AccettaChiamata

TerminaChiamata

Test case per metodo Registrazione

Descrizione metodo registrazione: Il metodo riceve in ingresso da un oggetto di classe

UtenteGenerico i dati nome, cognome, email, realm. Fa un controllo su quest’ultimi e

restituisce un oggetto di classe UtenteRegistrato.

Precondizione: Utente non registrato. Postcondizione: Utente registrato.

Test Case Input Output atteso Output ottenuto

TC 1 nome, cognome, e-mail, realm (dati corretti)

username, password, realm (SipURL: username@realm); numero geografico (opzionale)

TC 2 nome, cognome, e-mail, realm (dati errati)

Nessun nuovo account SIP

Nota: l’utente può registrarsi presso un server realm una sola volta; l’indirizzo e-mail

garantisce l’univocità. Per dati errati contempliamo i seguenti casi:

- l’utente ha provato a registrarsi presso un realm non valido;

- l’utente ha provato a registrare la stessa email più di una volta presso lo stesso

realm.


106

Test case per metodo Cancellazione

Descrizione metodo cancellazione: Il metodo permette ad un UtenteRegistrato di

cancellare il proprio profilo SIP dal dialplan del server realm.

Precondizione: Utente registrato. Postcondizione: Utente non registrato.


TC 3

username, password, realm (dati presenti presso il server realm)

UtenteRegistrato cancellato

TC 4

username, password, realm (dati non presenti presso il server realm)

UtenteRegistrato non cancellato

Test case per metodo Login

Descrizione metodo Login: Il metodo viene invocato da un oggetto di classe

UtenteRegistrato. Il metodo Login verifica, presso il server realm, la validità dei dati

username e password che gli vengono forniti.

Precondizione: Utente registrato.

Postcondizione: Utente connesso con chiamata inattiva (stato IDLE).


TC 5 username, password, realm (dati corretti)

UA: Registrazione riuscita: 200 OK

TC 6

username, password, realm (username e password non corretti)

UA: Registrazione fallita: 401 Unauthorized

TC 7 username, password, realm (realm non corretto)

UA: Registrazione fallita: Timeout


107

Test case per metodo Logout

Descrizione metodo Logout: Il metodo viene invocato da un oggetto di classe

UtenteRegistrato per chiudere la sessione. Il metodo chiude la sessione e la chiamata

eventualmente in corso.

Precondizione: Utente connesso.

Postcondizione: Utente disconnesso.


TC 8 Richiesta disconnessione Disconnessione

Test case per metodo EffettuaChiamata

Descrizione metodo EffettuaChiamata: Il metodo viene invocato da un oggetto di classe

UtenteRegistrato per avviare una chiamata.

Precondizione: Utente connesso con chiamata inattiva (stato IDLE).

Postcondizione: Utente connesso con una chiamata in uscita (stato OUTGOING_CALL).


TC 9

Richiesta di chiamata a username@realm (username@realm valido e libero)

Chiamata username@realm SQUILLANDO…

TC 10

Richiesta di chiamata a username@realm (username non presente su realm)

UA: REFUSED (Does Not Exist Anywhere)

TC 11

Richiesta di chiamata a username@realm (username@realm occupato o realm non trovato)

UA: NON TROVATO/TIMEOUT


108

Test case per metodo AccettaChiamata

Descrizione metodo AccettaChiamata: Il metodo viene invocato da un oggetto di classe

UtenteRegistrato per accettare una chiamata in arrivo.

Precondizione: Utente connesso con una chiamata in arrivo (stato INCOMING_CALL).

Postcondizione: Utente connesso con una chiamata in corso (stato ONCALL).


TC 12 Accetta chiamata UA: chiamata in ingresso calee@realm

UA: CONFERMATA/CHIAMATA AudioLauncher: apertura audio java.....

Test case per metodo TerminaChiamata

Descrizione metodo TerminaChiamata: Il metodo permette prima di terminare una

chiamata in corso oppure rifiutare una chiamata in arrivo.

Precondizione: Utente connesso con una chiamata attiva (non stato IDLE).

Postcondizione: Utente connesso con una chiamata inattiva (stato IDLE).


TC 13 Termina chiamata UA: CHIUSA AudioLauncher: chiusura audio java...


109

4.6 Nota implementativa

Tra le varie soluzioni esistenti per il VoIP, prendiamo il considerazione il progetto MjSIP

dell’Università di Parma, rispondente ai requisiti richiesti per il framework. Oltre che

essere un progetto Java open-source, esso è pienamente compliant con la progettazione

esposta nel paragrafo precedente, a meno di alcune scelte implementative.

Riportiamo di seguito il lavoro compiuto per adattare il progetto esistente per macchine

desktop MjSIP su un dispositivo mobile, in particolare su un palmare HP iPAQ con

sistema operativo Windows Mobile 5.0.

4.6.1 Mysaifu JVM

Il primo passo da compiere è trovare una JVM per Windows Mobile tale che sia adatta alla

Configuration CDC del nostro palmare.

Tra le JVM per dispositivi mobili, ci è sembrato opportuno adottare Mysaifu JVM. Si

tratta di un progetto free sotto licenza GPLv2 che risale all’aprile 2005 e ancora in

evoluzione, anche se l’ultima release risale al dicembre 2006.

L’ultima release disponibile è compatibile con i seguenti sistemi operativi:

o Windows Mobile 5.0;

o Windows Mobile 2003 SE (PocketPC 2003 SE);

o Windows Mobile 2003 (PocketPC 2003).

L’installazione di Mysaifu sul palmare è molto semplice.

E’ possibile eseguire la JVM Mysaifu come applicazione in background o per eseguire una

specifica applicazione Java. Mysaifu è una JVM compliant con la J2SE 1.3.

In particolare, essa comprende la quasi totalità delle librerie grafiche AWT e alcuni

package della libreria SWING. Mysaifu JVM, quindi, è Personal Basis Profile compliant;

inoltre presenta numerosi package opzionali, tra cui facciamo notare il package

javax.sound.sampled necessario ai fini della realizzazione di un componente come il


110

nostro, destinato a manipolare streaming audio. Tale package provvede a fornire le

interfacce e i metodi per registrare, manipolare e ascoltare dati di tipo audio.

In particolare, il package javax.sound.sampled non risulta completo, infatti non supporta

tutti i codec presenti nella corrispondente versione per macchine desktop.

Lo stesso autore di Mysaifu sul sito di riferimento annuncia, nel marzo 2006, che la JVM,

a partire dalla release 0.2.2, supporta la classe javax.sound.sampled, tuttavia gli unici

codec supportati restano i PCM (signed) e PCMU (unsigned). Da allora ad oggi, non vi

sono aggiornamenti in proposito.

Conferma di quanto detto viene dal deploy dell’applicazione MjSIP originale sul palmare:

l’applicativo funziona perfettamente finchè lo User Agent non instaura un canale di

streaming audio, ovvero quando inzia una chiamata, dando luogo ad un’eccezione.

Per effettuare uno streaming audio VoIP è necessario avere a disposizione il codec G711

(noto anche come formato Alaw/ulaw), che Mysaifu non riconosce. Dovremo lavorare con

i codec cosiddetti lineari, ovvero PCM, rinunciando alla possibilità di instaurare chiamate

verso la rete telefonica tradizionale.

4.6.2 “MjSIP mobile”: studio di fattibilità

Approfondendo lo studio del progetto MjSIP, dal codice emerge la sua organizzazione in

due macro-package, ciascuno dei quali a sua volta contiene altri package:

o org.zoolu è il package che implementa il SIP stack. E’ responsabile della creazione

e della gestione della connessione al provider SIP, dell’autenticazione, della

sessione SIP, della gestione dei messaggi SIP, della chiamata e del dialogo;

o local è un package, decisamente più piccolo del precedente, contente i seguenti

package:

- local.net: implementa il protocollo RTP come estensione del protocollo

UDP;

- local.ua: implementa lo User Agent (client e server);


111

- local.media: gestisce la parte multimediale della conversazione, ovvero lo

streaming audio e video. In esso è implementata anche la classe G711.java

che gestisce il codec omonimo, ovvero Alaw/ulaw.

Riguardo quest’ultimo package, possiamo affermare che la sua implementazione è stata

lasciata in sospeso dagli autori. Infatti, le classi relative al codec G711 e allo streaming

video sembrano proprie del progetto iniziale degli autori, i quali le hanno lasciate

incomplete e inutilizzate nell’ambito nel progetto VoIP. Le stesse classi di esempio –

grafica e testuale – forniscono il tipico funzionamento della chiamata VoIP e non della

video-chiamata.

Il lavoro svolto per adattare il progetto MjSIP alla Mysaifu JVM, istallata su PocketPC

Windows Mobile, è concentrato soprattutto sul package local.media.

Precisamente le classi che abbiamo reimplementato sono:

o AudioInput.java, riconosce lo streaming audio proveniente dalle rete IP e ne

effettua la riproduzione;

o AudioOutput.java, inoltra verso la rete IP lo streaming audio riconosciuto dal

microfono;

o RtpStreamReceiver.java, gestisce lo streaming RTP in ingresso;

o RtpStreamSender.java, gestisce lo streaming RTP in uscita.

Come si può intuire, la struttura delle classi sopra riportate risulta duale a coppie. In

particolare, le ultime due classi costituiscono dei threads durante tutto il periodo di una

chiamata. È compito della classe local.ua.JAudioLauncher.java istanziare e gestire i due

threads sulla base dello stato della chiamata.

Per garantire la fattibilità di MjSIP mobile dobbiamo superare i limiti legati alla JVM:

Mysaifu non supporta la conversione di formato audio, necessaria affinchè si possa gestire

uno streaming audio in formato Alaw/ulaw.


112

La soluzione è apportare le opportune modifiche alle quattro classi sopra menzionate,

affinché il formato audio trattato sia esclusivamente PCM; possiamo così evitare la

conversione di formato audio.

Tali modifiche ci inducono anche a reimplementare le classi delegate per la gestione dello

streaming RTP in modo tale che siano in grado di trattare uno streaming audio PCM.

Useremo il package local.net per implementare nuovamente le classi

RtpStreamSender.java e RtpStreamReceiver.java.

L’idea di base è creare in ciascun delle due classi un buffer di byte. Tale buffer costituirà il

pacchetto RTP che viaggerà sulla rete durante una chiamata. RtpStreamSender registrerà

in tale buffer l’audio ricevuto dal microfono e lo inoltrerà verso la rete, mentre

RtpStreamReceiver effettuerà la riproduzione dell’audio contenuto nel buffer.

La gestione tramite threads, nell’invio quanto nella ricezione di tali pacchetti, ne garantirà

il flusso continuo, ovvero lo streaming audio.

Si noti che la dimensione del buffer in questione può essere impostata per migliorare la

qualità dello streaming, ma dovrà rispettare i vincoli imposti dall’MTU per la rete

Internet. In particolare, essendo l’header di un pacchetto RTP pari a 12 byte, il payload

audio non potrà superare la dimensione di 1488 byte.

4.6.3 Implementazione

Facendo riferimento al diagramma dei casi d’uso e al diagramma delle classi, di seguito

riportiamo lo pseudocodice relativo al componente VoIP, realizzato secondo quanto

discusso in precedenza:

Classe VoIPComp.java

/* login: prende in ingresso il file account di cui effettua il parsing */

public void login(String file){ if(ua != null) ua.sip_provider.halt(); this.ra = null; this.ua = null;


113

/* dichiarazione delle variabili necessarie per il parsing del file account

[…] […]*/

SipStack.init(file); SipProvider sip_provider; if (file != null) sip_provider = new SipProvider(file); else sip_provider = new SipProvider(opt_via_addr,opt_host_port); if (opt_outbound_proxy != null) sip_provider.setOutboundProxy(new SocketAddress(opt_outbound_proxy)); UserAgentProfile user_profile = new UserAgentProfile(file); /* imposta i parametri sulla base di quelli letti dal file

[…] […] */

VoIPclient = new VoIPComp(sip_provider,user_profile); } /* logout */ public void logout(){ if(ra != null | ua != null){ if (ra.isRegistering()) ra.halt(); ra.unregister(); ua.sip_provider.halt(); } exit(); } /* accetta chiamate in arrivo */ public void accettaChiamata(){ printOut("accetta"); if (ua.statusIs(UserAgent.UA_INCOMING_CALL)){ ua.accept(); } } /* termina una chiamata in corso o rifiuta una chiamata in arrivo */ public void terminaChiamata(){ printOut("termina"); if (!ua.statusIs(UserAgent.UA_IDLE)){ ua.hangup(); ua.listen(); } } /* effettua una nuova chiamata */ public void effettuaChiamata(String target_url){ printOut("effettua"); ua.hangup(); ua.printLog("UAC: CHIAMA " + target_url); if (!ua.user_profile.audio && !ua.user_profile.video) ua.printLog("SOLO SQUILLO, NESSUN AUDIO"); ua.call(target_url);


114

} /* UA in ascolto */ void run(){ /* Controlli sulle proprietà di user_profile

[…] […] */

listen();

/* Controllo dello stato della chiamata da parte dello UserAgent […] […] */

}

Per una rapida comprensione degli stati e delle relative transizioni, riportiamo il

Diagramma degli Stati (Figura 4.12) relativi alla classe Chiamata. Per il significato degli

stati, si faccia riferimento alla descrizione dei casi d’uso.

loginChiamata in arrivo

effettuaChiamataaccettaChiamata

Chiamata accettata

logout

terminaChiamata

terminaChiamata

terminaChiamata

IDLE INCOMING CALL

OUTGOING CALL ONCALL

Figura 4.12 - Diagramma degli Stati della classe Chiamata

Come si nota dallo pseudocodice, la classe VoIPComp.java costituisce un wrapper dei

metodi offerti dalla classe UserAgent di MjSIP. La classe implementa UserAgentListener,

RegisterAgentListener, delegati, rispettivamente, di gestire le chiamate e la registrazione

presso un SIP server. Si noti la necessità di registrare periodicamente lo User Agent presso

il SIP server.


115

Lo User Agent è in ascolto degli eventi, gestiti ciascuno attraverso un metodo opportuno,

la cui implementazione resta opzionale.

Una nota sul metodo di Login: ereditando la filosofia di MjSIP, il metodo riceve in

ingresso il nome di un file di testo contente i parametri relativi all’account utente. Il

metodo login effettua il parsing di questo file.

La classe, così come tutto il progetto, tiene traccia degli eventi in un file di log.

L’obiettivo della progettazione, fin qui seguita, è esporre, attraverso il Framework Core, i

metodi del servizio VoIP per consentirne l’uso da parte delle applicazioni utente. Tuttavia

il componente riportato è utilizzabile solo come applicazione stand-alone, a causa dei

limiti tecnologici dei palmari, che non presentano sufficienti risorse per garantire

l’esecuzione, oltre che del servizio VoIP, di un Servlet Container e di un Web Service

Container, similmente a Tomcat e Axis in una soluzione nomadica. Sebbene le comunità

di sviluppo si stiano dimostrando sensibili alla necessità di portare tali tecnologie sui

dispositivi mobili, il limite tecnologico non è stato ancora superato.

4.6.4 Testing

La fase di Testing del componente VoIP è essenzialmente ridotta alla fase di Unit test (o

test di unità); l’Integration test (o test di integrazione) è lasciato agli sviluppi futuri,

laddove il componente sia integrato nel framework di servizi.

Nella fase di Unit Test verifichiamo la validità dei metodi di cui abbiamo progettato i Test

case; si noti che supponiamo l’implementazione dei metodi registrazione e cancellazione

delegata al componente esterno SIP server (provider).

Per implementare i Test case progettati utilizzeremo JUnit (unit test framework per il

linguaggio di programmazione Java). Di seguito riportiamo, per ogni Test case, una

tabella in cui è indicato il metodo che si sta testando, i dati di input al metodo, l’output

atteso e l’output ottenuto.


116

TC 1 Metodo testato Input Output atteso Output ottenuto

registrazione nome, cognome, e-mail, realm (dati corretti)

Nuovo account SIP Nuovo account SIP


registrazione nome, cognome, e-mail, realm (dati errati)




cancellazione

username, password, realm (dati presenti presso il server realm)




cancellazione

username, password, realm (dati non presenti presso il server realm)




login username, password, realm (dati corretti)




login

username, password, realm (username, password non corretti)



TC 7 Metodo testato Input Output atteso Output ottenuto login

username, password, realm (realm non corretto)




117


logout Richiesta disconnessione Disconnessione Disconnessione


effettuaChiamata

Richiesta di chiamata a username@realm (username@realm valido e libero)




effettuaChiamata

Richiesta di chiamata a username@realm (username non presente su realm)




effettuaChiamata

Richiesta di chiamata a username@realm (username@realm occupato o realm non trovato)




accettaChiamata Accetta chiamata UA: chiamata in ingresso calee@realm

UA: CONFERMATA/ CHIAMATA AudioLauncher: apertura audio java.....

UA: CONFERMATA/ CHIAMATA AudioLauncher: apertura audio java.....


terminaChiamata Termina chiamata UA: CHIUSA AudioLauncher: chiusura audio java...

UA: CHIUSA AudioLauncher: chiusura audio java...

4.6.5 Esempio d’uso

Il componente VoIP realizzato dovrebbe lavorare in background, come tutti i servizi del

framework, fornendo il servizio VoIP ad un applicativo utente scritto, per esempio, in C#.


118

Al momento, secondo quanto già discusso, lo stato della tecnologia non ci permette di

contenere il componente VoIP in un Web Service e permetterne l’uso in locale sul

palmare.

Vogliamo comunque mostrare la possibilità di usare il componente VoIP, come

applicazione stand-alone, per effettuare telefonate dal nostro palmare su cui abbiamo

precedentemente installato la JVM Mysaifu.

Come primo passo, dobbiamo procurarci un account SIP. Lo facciamo presso il provider

Messagenet (www.messagenet.it), basato sull’architettura Asterisk. Precisamente, in

questo caso, il Registrar server è sip.messagenet.it. Esso fornisce all’atto della

registrazione un SipURL (<numero_utente>@ sip.messagenet.it), una password e un

numero geografico con prefisso a scelta tra “02” e “06”.

Messagenet fornisce anche il servizio di segreteria telefonica: all’e-mail fornita all’atto

della registrazione, Messagenet invierà i messaggi vocali lasciati in segreteria.

Le caratteristiche del palmare e della JVM ci consentono di realizzare un applicativo

grafico. Sfruttando il package grafico java.awt, mostriamo di seguito gli screenshots

relativi ai metodi presentati in precedenza:

Figura 4.13 - Operazione di Login andata a buon fine

Figura 4.14 - Chiamata in ingresso da parte di “Vittorio”


119

Figura 4.15 - Il destinatario rifiuta la chiamata

Figura 4.16 - Chiamata in uscita; in attesa che il destinatario risponda

Figura 4.17 - Il destinatario ha risposto alla chiamata

Figura 4.18 - Uno dei due interlocutori ha terminato la chiamata

4.7 Conclusioni

Qui si chiude lo studio di fattibilità del componente VoIP su dispositivo mobile.


120

La soluzione ottenuta sicuramente non ha le stesse potenzialità del progetto MjSIP

iniziale: pur garantendo la compatibilità con lo standard SIP, essa presenta, per quel che

riguarda lo streaming audio, problemi di compabilità con altri applicativi VoIP e la totale

incompatibilità da e verso la rete telefonica tradizionale.

Tuttavia MjSIP mobile garantisce il VoIP e una buona QoS qualora i due interlocutori

usino entrambi MjSIP mobile.

Nel capitolo successivo, esamineremo alcune soluzioni alternative, e lasciate agli sviluppi

futuri, per la realizzazione del framework.

Capitolo 5. Conclusioni e sviluppi futuri

121

5. Conclusioni e sviluppi futuri

In questo lavoro di tesi si è progettato un framework per dispositivi mobili che garantisca

un facile accesso ai più comuni servizi diffusi negli ambienti di mobile computing. Si è

immaginato il framework costituito da due parti: il Framework Core, garante dei requisiti

non funzionali, e i servizi veri e propri, definiti dai requisiti funzionali. Tutto il lavoro è

stato svolto nell’ambito del progetto “WiFi People – CRONOS”.

Nel corso della progettazione, il rispetto dei requisiti dimostra come il framework, con i

servizi integrati, possa essere distribuito tanto in un ambiente totalmente mobile (reti

mobili Ad-Hoc), quanto in un ambiente nomadico.

Diverse sono state le tecnologie studiate per la realizzazione del Framework Core.

Avvalendoci anche delle scelte di mercato di aziende leader nel settore, la scelta

tecnologica è ricaduta sui Web Services.

Il lavoro è proseguito con lo studio di uno dei servizi, ovvero il servizio VoIP.

La progettazione del servizio VoIP mira ad integrare il relativo componente all’interno del

framework di servizi per renderlo disponibile alle applicazioni utente. I limiti tecnologici

dei dispositivi mobili, dei palmari in particolare, impediscono tuttavia di ottenere la

soluzione per reti mobili Ad-Hoc, né tantomeno possiamo pensare di adottare una

soluzione nomadica, poiché incompatibile con il servizio VoIP così come con altri servizi.


122

In tal contesto diventa necessario proseguire negli studi e nella ricerca per permettere

all’intero framework – Framework Core e servizi integrati – di risiedere su un dispositivo

mobile.

Il problema maggior è avere a disposizione un “mini” Web Service Container, ed il

relativo Web Server, tale che possa realizzare sul dispositivo mobile stesso, attraverso la

tecnologia Web Service, lo strato software relativo al Framework Core.

Oltre al mercato che offre dispositivi mobili con risorse computazionali crescenti, buone

possibilità - “mini” - ci vengono offerte dalle comunità di sviluppo sulla traccia delle

grandi compagnie di prodotti per il mobile, come Nokia, Symbian e PalmOS.

Un’interessante soluzione open-source ancora una volta viene dal mondo Java. Si tratta di

Tiny Java Web Server and Servlet Container (TJWS; http://tjws.sourceforge.net/). Esso è

un “mini” Web Server Java, oltre che Servlet Container, equivalente al più popolare

Apache Tomcat per macchine desktop/server. Non esiste ancora, però, un Web Service

Container, simile ad Axis, che permetta la realizzazione completa del Framework Core.

Va tenuto in conto che TJWS funziona bene solo su J9, la JVM con licenza commerciale

rilasciata da IBM. Perdiamo così la caratteristica che il framework sia realizzato con

strumenti open-source.

Possiamo adottare, a questo punto, delle soluzioni alternative nell’ipotesi di portare su

dispositivo mobile l’intero set di servizi previsto.

Senza ricorrere ad alcun Web Server, potremmo permettere alle applicazioni utente di

accedere ai servizi usando le Socket. Tale soluzione richiede uno sforzo maggiore da parte

sia di chi realizza i servizi sia da parte di chi implementa le applicazioni utente. In

particolare, seguendo il pattern Socket, lo sviluppatore del servizio dovrà preoccuparsi di

garantire il marshalling/unmarshalling dei dati scambiati, oltre che il riconoscimento dei

metodi invocati, mentre lo sviluppatore dell’applicazione utente dovrà rispettare i vincoli

imposti dal pattern di programmazione adottato.


123

Ricorrendo, invece, al Servlet Container, potremmo garantire l’accesso ai servizi

attraverso richieste HTTP. Ciò richiede tuttavia di progettare i servizi compatibilmente

alla struttura delle servlet e, al programmatore lato client, di attenersi ad un paradigma di

progettazione ben preciso, dipendente dal protocollo HTTP.

In ciascuna delle soluzioni presentate in precedenza perdiamo uno o più requisiti non

funzionali garantiti dal framework di servizi, così come progettato nell’ambito di questo

lavoro di tesi.

Per conservare tutti i requisiti, potremmo, a questo punto, tornare sulla scelta della

tecnologia da adottare per la realizzazione del framework. Nel corso del lavoro di tesi

abbiamo adottato la tecnologia Web Service, basata sull’architettura SOA. Tuttavia, esiste

un modello architetturale emergente che potrebbe risolvere le problematiche relative alla

mancanza di un Web Service Container per dispositivi mobili: stiamo parlando dei Web

Services REST (REpresentational State Transfer).

La filosofia REST nasce con l’intento di sfruttare totalmente e solamente le potenzialità

del Web: non mira ad adattare la rete al concetto di servizio, così come avviene

nell’architettura SOA, bensì sfrutta il concetto di risorsa, proprio della rete, a cui accede

tramite i pochi metodi offerti dal protocollo HTTP, ovvero PUT, GET, POST e DELETE.

Gli aspetti fondamentali dell’architettura REST sono:

o le risorse, scomposte e organizzate in modo da poter essere gestite in modo

atomico dai metodi del protocollo HTTP. In particolare, ogni metodo accede alle

risorse attraverso una rappresentazione della stessa, compatilmente alla sintassi

URI (Uniform Resource Identifier);

o la comunicazione è stateless, ovvero almeno lato server siamo vincolati a non

mantenere lo stato dell’applicazione. Qualora servisse mantenere lo stato,

l’applicazione client deve farsene carico.


124

In altre parole, con l’architettura REST si realizzano Web Services meno differenti da un

sito Web vero e proprio, poiché si accede ai REST Web Services come un browser accede

alle informazioni tipicamente contenute in una pagina Web.

Per i fini della nostra tesi, ricorrendo alla tecnologia REST e passando ad una filosofia

resource centric nella progettazione dei servizi da integrare, potrebbe bastare avere sul

dispositivo mobile un Web Server come TJWS che risponda a semplici richieste HTTP.

Una riprogettazione in tal senso, tuttavia, potrebbe risultare poco lungimirante a fronte

delle aspettative di un mercato sempre in espansione e innovativo come è, appunto, quello

dei dispositivi mobili.

Appendice

125

Appendice

A.3.1 Soluzione Web Service in ambiente nomadico

Vediamo di seguito una possibile soluzione Web Service in un ambiente nomadico.

Di seguito riportiamo una panoramica sulle tecnologie e metodologie adottate per lo

sviluppo e l’accesso ai servizi offerti dal framework in tale contesto.

A.3.1.1 Tecnologie Java per i Web Services

Java implementa diverse tecnologie per lo sviluppo e l’uso dei Web Services. Ne

riportiamo di seguito una descrizione [40]:

Figura A.3.1 - Le tecnologie Java per lo sviluppo dei Web Services

Queste tecnologie hanno il seguente scopo:

o JAX-M (Java API for XML Messaging) è un’implementazione della messaggistica

SOAP a basso livello;

o SAAJ (SOAP with Attachments API for Java) è un’implementazione del modello

informativo degli elementi di SOAP;

Appendice

126

o JAX-RPC (Java API for XML Remote Procedure Call) fornisce il supporto client e

server allo sviluppo rapido di servizi Web basati su SOAP e WSDL con un

modello di sviluppo simile ad RMI;

o JAXR (Java API for XML Registries) fornisce il supporto a registri di servizi Web

come UDDI e ebXML R.

Nota di riguardo va data a JAXP [41] (API chiamata precedentemente Project X). Vuole

fornire al programmatore i mattoni di base per realizzare applicazioni XML. Più che di

applicazioni si può parlare di un framework di sviluppo basato su servizi e applicazioni.

Le funzionalità di JAXP rappresentano il cosiddetto core per la realizzazione di

applicazioni XML in Java. Questo nucleo di base include:

o la possibilità di utilizzare diversi parser (pluggability);

o API per il parsing (con eventuale validazione) dei documenti;

o DOM API per poter gestire un documento XML come una struttura ad albero.

Sulla base degli elementi forniti da JAXP è possibile costruire dei servizi, ovvero moduli

che forniscono funzionalità troppo specializzate per far parte della core API.

Utilizzando la core API ed eventualmente servizi addizionali si possono sviluppare

applicazioni complete basate su XML come Web-publishing e transazioni per l’e-

commerce business-to-business.

JAXP fornisce anche il supporto per la API SAX attraverso la classe SAXParser. SAX

(Simple API for XML) è un’interfaccia event-driven standard definita dal W3C per

l’elaborazione dei documenti XML.

Dallo stack delle tecnlogie (Figura A.3.1) che Java mette a disposizione per la

realizzazione dei Web Services, emerge che entrambe le API di SUN implementano

SOAP, quindi si potrebbe pensare che l’utilizzo delle due sia indifferente. In realtà non è

così: JAX-M e JAX-RPC non sono una ripetizione della stessa tecnologia con nomi

diversi.

Appendice

127

Per prima cosa, entrambe utilizzano SAAJ come implementazione del modello

informativo di SOAP [40], ma il loro scopo è differente:

o JAX-M fornisce un controllo fine sul messaggio (tramite SAAJ), consentendo di

manipolare ciascun elemento della richiesta ed accedere a qualsiasi elemento della

risposta SOAP. Viene utilizzato in soluzioni di messaggistica, come ad esempio:

l’invio asincrono di informazioni real-time, l’interfacciamento con servizi

strutturati in modo particolare (non standard), collegamento a servizi che hanno

una risposta dinamica (cambia la struttura al variare della richiesta o dei dati

ritornati);

o JAX-RPC implementa invece un generico sistema di RPC su XML; la tecnologia

non è vincolata a SOAP, ma aperta ad eventuali evoluzioni future. E’ invece basata

fortemente su WSDL, che utilizza per implementare la mappatura XML-Java e

viceversa. Con JAX-RPC non è necessario codificare a basso livello, se si dispone

di un WSDL, si possono generare le classi Java che implementano il client ed il

server. La stessa cosa può avvenire a partire da una interfaccia che estende

java.rmi.Remote, in modo similare al funzionamento di RMI e del comando rmic.

JAX-RPC è dunque più indicato per sviluppare applicazioni complesse, con molti servizi,

e per integrare Web Services esistenti e completamente standard, quando non sia

necessario entrare nel dettaglio tecnico della struttura dei messaggi SOAP di richiesta e

risposta. Con JAX-RPC un servizio Web viene acceduto come se fosse un oggetto Java

locale.

A.3.1.2 Lato Server I nostri servizi lato server saranno implementati nel linguaggio Java. La piattaforma di

riferimento, precisamente, è J2SE 1.6 su sistema operativo Windows XP SP2.

L’IDE di sviluppo usato è Eclipse Web Tools Platform (WTP) 3.2.

E’ necessario introdurre una tecnologia che ci permetta di esporre un’applicazione Java

come un Web Service. In particolare, adotteremo per il nostro progetto le tecnologie

JAXP, SAAJ e JAX-RPC.

Appendice

128

Inoltre, nello sviluppo dei servizi la “remotizzazione” degli stessi sarà trasparente al

programmatore, grazie alla tecnologia Java basata sulle Java Server Pages (JSP).

In effetti, con l’introduzione delle JSP, la nostra piattaforma di sviluppo di estende per

essere tipica della J2EE.

Apache Tomcat (http://tomcat.apache.org/)

JSP (letto talvolta come Java Scripting Preprocessor) è una tecnologia Java per lo

sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o

XML. Si basa su un insieme di speciali tag con cui possono essere invocate funzioni

predefinite o codice Java. In aggiunta, permette di creare librerie di nuovi tag che

estendono l’insieme dei tag standard. Le librerie di tag JSP si possono considerare

estensioni indipendenti dalla piattaforma delle funzionalità di un Web server.

JSP è una tecnologia alternativa rispetto a numerosi altri approcci alla generazione di

pagine Web dinamiche, per esempio ASP o la più tradizionale CGI. Differisce da queste

tecnologie non tanto per il tipo di contenuti dinamici che si possono produrre, quanto per

l’architettura interna del software che costituisce l’applicazione Web (e, di conseguenza,

sui tempi di sviluppo, la portabilità, la modificabilità, le prestazioni, e altri aspetti di

qualità del software).

Nel contesto della piattaforma Java, la tecnologia JSP è correlata con quella delle servlet.

All’atto della prima invocazione, le pagine JSP vengono infatti tradotte automaticamente

da un compilatore JSP in servlet. Una pagina JSP può quindi essere vista come una

rappresentazione ad alto livello di un servlet. Per via di questa dipendenza concettuale,

anche l’uso della tecnologia JSP richiede la presenza, sul Web server, di un Servlet

container, oltre che di un server specifico JSP detto motore JSP (che include il

compilatore JSP); in genere, Servlet container e motore JSP sono integrati in un unico

prodotto; per esempio, Apache Tomcat svolge entrambe le funzioni.

Apache Tomcat (o semplicemente Tomcat) è un Servlet container open-source sviluppato

dalla Apache Software Foundation. Implementa le specifiche JSP e Servlet della Sun,

fornendo quindi una piattaforma per l’esecuzione di applicazioni Web sviluppate nel

Appendice

129

linguaggio Java. La sua distribuzione standard include anche le funzionalità di Web server

tradizionale, che corrispondono al prodotto Apache.

In passato, Tomcat era gestito nel contesto del progetto Jakarta, ed era pertanto

identificato con il nome di Jakarta Tomcat; attualmente è oggetto di un progetto

indipendente.

Tomcat è rilasciato sotto licenza Apache Software License, ed è scritto interamente in Java

ed include la tecnologia JAXP; può quindi essere eseguito su qualsiasi architettura su cui

sia installata un JVM.

Una pagina JSP è un documento di testo, scritto con una sintassi specifica, che rappresenta

una pagina Web di contenuto parzialmente o totalmente dinamico. Elaborando la pagina

JSP, il motore JSP produce dinamicamente la pagina HTML finale che verrà presentata

all’utente. La pagina JSP può contenere tre tipi di elementi, a cui corrispondono tre diversi

modi di elaborazione: contenuti statici, direttive e script.

In particolare, i contenuti statici sono porzioni della pagina JSP che devono essere

mantenute integralmente nella pagina Web generata dinamicamente, senza alcuna

elaborazione. Devono pertanto essere scritte nel linguaggio di tag di cui il client può

usufruire direttamente, per esempio HTML (se il client è un browser), WML (se il client è

un cellulare che accede alla pagina in WAP) o XML, come nel nostro caso.

Apache AXIS (http://ws.apache.org/axis/)

Per dotare Tomcat di un Web service engine in grado di esaudire richieste provenienti da

qualsiasi client Web Service, è necessario istallare AXIS [42].

Si tratta di un’API di programmazione e deployment di Web Services che permette di

lavorare ad un livello di astrazione elevato, evitando così di dover maneggiare

direttamente l’envelopement SOAP. Con Axis è possibile, dunque, implementare Web

Services e anche sviluppare client di servizi di terzi. Axis permette lo sviluppo di Web

Service sia in Java che in C++.

Appendice

130

Axis implementa il modello JAX-RPC e supporta anche SAAJ. Non tutto nasce da

Apache, il prodotto iniziale è merito di IBM, che poi decise di regalare al consorzio

Apache tutto il codice. Viene alla luce quindi Apache SOAP e poi la sua evoluzione:

Apache Axis.

Le caratteristiche più importanti del framework sono [42]:

o implementazione SOAP 1.1/1.2;

o supporto JWS (Java Web Services): permette un facile e immediato deploy dei

Web Services;

o supporto serializzazione/de-serializzazione;

o implementazione WSDL;

o utility WSDL2Java e Java2WSDL;

o SOAP Monitor e TCP Monitor: due applicazioni scritte in Java che permettono di

monitorare il traffico SOAP;

o possibilità di usare tre differenti metodi per l’invocazione dei Web Services:

Dynamic Invocation Interface (DII), Stub generato dal WSDL e Dynamic Proxy.

I componenti di Axis sono quindi: un engine per l’elaborazione dei messaggi SOAP,

handler per la gestione dei messaggi, vari meccanismi di deploy, serializzazione/de-

serializzazione, configurazione e di trasporto dei messaggi.

A.3.1.3 Lato Client

Passiamo all’implementazione del client, ovvero del Web Service Consumer. I client

saranno i dispositivi mobili che vogliono “consumare” i Web Services Java. Scegliamo

come riferimento il sistema operativo Windows Mobile 5.0 su PocketPC 2.0, l’equivalente,

dal punto di vista J2ME, di un dispositivo CDC Personal Profile.

Qualunque linguaggio adotteremo per l’implementazione dei Web Service consumer, essi

dovranno essere grado di costruire i messaggi che si vuole spedire al servizio Web e di

analizzare ciò che il servizio Web spedisce al mittente. Scrivere manualmente il codice per

Appendice

131

costruire ed analizzare i messaggi richiede un tempo elevato e la possibilità di commettere

errori è elevata. Una soluzione migliore è quella di includere tale codice in una classe che

consenta il suo riuso. Tale classe prende il nome di proxy class. Esse espongono le stesse

funzionalità del servizio Web che vuole essere utilizzato da un client, in modo

assolutamente indipendente dalla locazione fisica del servizio medesimo. Inoltre, tutti i

dettagli implementativi relativi al marshalling tra i processi viene gestito dalla proxy

class: la chiamata ad un metodo di un servizio Web apparirà al client come la chiamata ad

un metodo locale.

Per la piattaforma Windows Mobile va da sé che il linguaggio che può offrire maggiori

vantaggi è C#, linguaggio principe della piattaforma .NET Compact Framework [31].

In tal caso, le proxy class vengono generate mediante una utilità del framework SDK

denominata Wsdl.exe. Tale eseguibile prende in ingresso un documento WSDL e produce

una proxy class avente l’estensione del linguaggio di implementazione del servizio Web

(nel caso di C#, l’estensione è .cs). Le classi proxy prodotte con la tecnologia Microsoft

espongono una serie di proprietà che consentono una loro personalizzazione:

1. proprietà Url: consente di definire un riferimento ad un altro servizio Web che

espone le medesime funzionalità;

2. proprietà Credentials: consente di fornire le credenziali per l’autenticazione del

consumer. Tra i meccanismi di autenticazione basati sulle credenziali possiamo

annoverare: autenticazione Basic, Kerberos, NTLM e Digest;

3. proprietà Timeout: consente di definire il tempo entro il quale deve essere conclusa

la chiamata ad un metodo del servizio Web;

4. proprietà Proxy: consente di definire i settaggi di un proxy differenti dalle

impostazioni di default;

5. proprietà AllowAutoRedirect: consente, se il valore viene settato a true, di

autorizzare il Web service provider a ridirigere le credenziali del consumer verso

un altro server remoto per completare l’operazione di autenticazione.

Appendice

132

Figura A.3.2 - Stack architetturale della tecnologia .NET

Per il client C#, l’IDE di sviluppo è stato, per le prime prove su macchina desktop, Visual

C# 2005 Express Editino; in un secondo momento, per passare ad un deployment su

PocketPC più veloce, abbiamo usato Microsoft Visual Studio 2005 SDK, comprensivo di

emulatori.

A.3.2 Soluzione e suoi limiti

Vediamo la soluzione lato server.

Supponiamo di aver già configurato correttamente l’ambiente di sviluppo Java (JDK 1.6)

su una macchina desktop Windows XP SP2.

Sulla stessa macchina installiamo il server Tomcat 6.0 e ne configureremo le variabili di

ambiente.

A questo punto possiamo scaricare Axis 1.4 dal sito di Apache. Unzippiamo e copiamo il

tutto nella cartella TOMCAT_HOME/webapps (TOMCAT_HOME è la variabile di

ambiente che indica il path dove abbiamo installato Tomcat).

Faremo riferimento all’host locale (localhost, ovvero 127.0.0.1); nel caso generale

sostituiremo alla parola “localhost” l’indirizzo IP del server remoto su cui risiedono i

nostri servizi. Avviamo Tomcat e puntiamo il browser all’indirizzo

http://localhost:8080/axis. In questa pagina troviamo lo stato dell’installazione di Axis. Se

Appendice

133

manca qualche libreria Java (.jar) ci viene indicato e non dobbiamo fare altro che

procurarle dai siti di riferimento della Sun e copiarle dentro la cartella

TOMCAT_HOME/webapps/axis/WEB-INF/lib.

Le librerie richieste, che vanno inserite nel classpath per lanciare il deployment, sono:

o axis.jar

o jaxrpc.jar

o saaj.jar

o commons-logging.jar

o commons-discovery.jar

o log4j-1.2.8.jar

o xml-apis.jar

o xercesImpl.jar

Si imposta la variabile d’ambiente AXISCLASSPATH che rappresenta i riferimenti alle

librerie .jar che contengono l’implementazione degli standard sui Web Services come

SAAJ e JAX-RPC; si noti l’ultima libreria dove è incluso il parser XML Xerces: Java

include il parser Crimson, ma Apache consiglia Xerces [42]: entrambi funzionano

adeguatamente quindi la scelta è puramente personale.

In alcuni casi potrebbe essere necessario l’uso della libreria activation.jar.

La verifica della corretta integrazione tra Axis e Tomcat si ottiene facendo puntare il

browser http://localhost:8080/axis: dovrebbe comparire la semplice Home Page testuale

di Axis da cui è possibile effettuare alcune operazioni.

Apache AXIS implementa il nuovo standard JWS di Java che permette di effettuare il

deploy di un Web Service in maniera semplice e veloce.

È sufficiente sviluppare la propria classe in Java, testarla, cambiare l’estensione da .java in

.jws e copiare il file .jws nella cartella TOMCAT_HOME/webapps/axis.

Appendice

134

Axis lo tratterà in maniera simile ad una JSP, ossia lo compilerà nella cartella

TOMCAT_HOME/webapps/axis/WEB-INF/jwsClasses e si occuperà dell’interfacciamento

con SOAP mediante la conversione automatica SOAP-JAVA. Tale metodo ha ovviamente

il pregio della semplicità a scapito della flessibilità: è infatti impossibile decidere quali

metodi esporre e specificare conversioni specifiche tra SOAP e JAVA. Un metodo più

flessibile è l’uso dei file WSDD (Web Service Deployment Descriptor), introdotti da Axis.

Un Web Service accessibile è, quindi, una classe Java che espone i propri metodi pubblici

e non-static.

Ora è necessario eseguire il deploy, ovvero rendere disponibile il nostro Web Service

ottenendo il file WSDL descrittore del WS.

Per ottenere questo e verificare la corretta interpretazione e compilazione dei Web

Services, si digiti nel browser: http://localhost:8080/axis/<nome della classe

Java>.jws?wsdl.

Nel browser apparirà il testo relativo al file WSDL. Il testo è di facile lettura e possiamo

individuare qualche tag fondamentale, per esempio:

o wsdl:message: indicano il tipo dei dati scambiati;

o wsdl:portType: il tipo di operazione e i parametri;

o wsdl:bindings: il tipo di protocollo usato;

o wsdl:service: caratteristiche del Web Service come l’indirizzo.

Se il Web Service (il file .jws, Java Web Service) usa altre classi Java, per effettuare il

corretto deployment, è necessario copiare i file di bytecode (.class) relativi a quest’ultime

nella cartella del server Tomcat TOMCAT_HOME/webapps/axis/WEB-INF/classes.

Ora possiamo “consumare” il Web Service.

Ci riferiremo all’IDE Visual Studio 2005 Express Edition, liberamente scaricabile dal sito

della Microsoft. Poiché il dispositivo target resta un PocketPC 2.0 con Windows Mobile

5.0, l’implementazione può passare direttamente attraverso Visual Studio 2005 che

fornisce ulteriori tools per lo sviluppo mobile, come gli emulatori.

Appendice

135

Una volta creato un progetto, in entrambi gli IDE, non è necessario usare a riga di

comando il tool Wsdl.exe, della .NET SDK. Infatti, basta cliccare con il tasto destro del

mouse sul progetto e selezionare la voce “Aggiungi riferimento Web” per avviare la

procedura relativa al comando Wsdl.exe. Ci verrà chiesto l’URL relativo al Web Service

(http://localhost:8080/axis/<nome della classe Java>.jws?wsdl) che dovrà chiaramente

essere attivo in quel momento attraverso il server Tomcat e le librerie Axis. Se l’URL

inserito è corretto, ci verrammo mostrati i metodi a cui possiamo ora accedere. Da questo

momento, i metodi remoti implementati in Java (Web Services Java) possono essere

consumati in piena trasparenza come se fossero dei metodi locali C#.

Ricordiamo che questa non può essere la soluzione definitiva per l’implementazione del

nostro framework: essa è valida solo in ambienti nomadic computing e solo relativamente

alle tipologie di servizi i cui dati trattati non dipendono dall’hardware a disposizione di un

dispositivo mobile.

Bibliografia

136

Bibliografia

[1] Coulouris, Dellimore, Kindberg: Distributed Systems: Concepts and Design. 2005

[2] Mascolo, Capra, Emmerich. Mobile Computing Middleware. Dept. of computer

Science, University College London. 2002

[3] Lyytinen, Yoo. Issues and challenges in Ubiquitous Computing. Communication of

ACM. 2002

[4] Kleinrock. Nomadicity: anytime, anywhere in a disconnected world. J. C. Baltzer

AG Science Publishers. 1996

[5] Akyildiz, Su, Sankarasubramaniam, and E. Cayirci. Wireless sensor networks: a

survey. Computer Networks. 2002

[6] Chakraborty, Perich, Avancha, Joshi. Service Discovery for M-Commerce

Applications. Department of Computer Science and Electrical Engineering –

University of Maryland. 2001

[7] Trisciuoglio. Introduzione alla Domotica. Tecniche Nuove. 2002

[8] Polini. Client/Server, Middleware & surroundings (Abstract). 2001

[9] Umar. Object-Oriented Client/Server Internet Environments. Prentice Hall Inc. 1997

[10] Forman, Zahorjan. The Challenges of Mobile Computing. Computer Science

Department, University of Washington, U.S. 1993.

[11] Srinivasan. RPC: Remote Procedure Call protocol specification version 2. RFC

1831. 1995

[12] Sun Microsystems. Java Remote Method Invocation . Distributed Computing for

Java. White Paper.1998

Bibliografia

137

[13] Object Management Group. The Common Object Request Broker: Architecture and

Specification. 2004. <http://www.omg.org/>.

[14] Bernstein. Transaction Processing Monitors. ACM Communication, Vol.33 No.11.

1990.

[15] Friday. Infrastructure Support for Adaptive Mobile Applications. PhD Thesis,

Computing Department, Lancaster University. 1996.

[16] Object Management Group. Wireless Access and Terminal Mobility in CORBA.

2004. <http://www.omg.org/>.

[17] Alice Web Site. <http://www.dsg.cs.tcd.ie/>.

[18] Liljeberg, Raatikainen, Evans, Furnell, Maumon, Veltkamp, Wind, and Trigila.

Using CORBA to Support Terminal Mobility. IEEE Computer Society Press. 1998.

[19] Grace. Middleware Support for Mobile Computing Applications. PhD First Year

Report. Computing Department, Lancaster University. 2001

[20] Mascolo, Capra, Zachariadis, Emmerich. XMIDDLE: A Data-Sharing Middleware

for Mobile Computing. Personal and Wireless Communications. 2001

[21] OASIS. Reference Model for Service Oriented Architecture 1.0. SOA-RM-CS. 2006

<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm>

[22] Carli. MIDP 2.0: Programmare i cellulari. <http://www.massimocarli.it/>

[23] Russo, Cotroneo. European Master on Critical Networked Systems - Università di

Napoli “Parthenope”. 2007

[24] Rossini. Networking in Java, V puntata: RMI, la teoria. 2000.

<http://www.mokabyte.it/>

[25] Altese. RMI: metodi a distanza. 2006. <http://java.html.it/>

[26] Carli. La piattaforma J2ME ed i Web Services, II parte: le JSR-172. 2005.


[27] Scaramuzza. Web Services et J2ME. 2003. <http://www.javaportal.it/>

[28] The Community Resouce for Jini Tecnology. <http://www.jini.org/>

[29] Zappa. Jini. 2001. <http://www.lucazappa.com/jini/>

[30] Modello di programmazione di .NET Framework. MSDN Library.

Bibliografia

138

<http://msdn2.microsoft.com/it-it/library/default.aspx>

[31] .NET Compact Framework. MSDN Library.

<http://msdn2.microsoft.com/it-it/library/default.aspx>

[32] VoIP. Abstract open solutions. <http://www.abstract.it/chiSiamo/tecnologie/voip>

[33] Saccomani. Voice Over IP. Una introduzione al VoIP nei suoi aspetti tecnici,

economici, di business e regolamentari. <http://www.voipblog.it/>

[34] Wikipedia. Voice Over IP. <http://it.wikipedia.org/wiki/Voice_over_IP>

[35] Asterisk user’s Group Italia. La tecnologia SIP. Voce su IP.

<http://www.asteriskpbx.it/>

[36] Wikipedia. Real-time Transport Protocol.

<http://it.wikipedia.org/wiki/Real-time_Transport_Protocol>

[37] Galletti. Configurazione di un servizio VoIP con Asterisk. Tesi di laurea, università

degli studi di Cassino. 2005

[38] Marzilli. Il protocollo SIP. <http://voip.html.it/>

[39] VoIPForo.com. Codecs. <http://www.voipforo.com/en/codec/codecs.php>

[40] Bigatti. JWS FAQ. 10 Domande e risposte sui Web Service. 2004.


[41] Giovannini. JAXP. Java API for XML Parsing. 2000. <http://www.mokabyte.it/>

[42] Verago. Realizzare un Web Services in pochi minuti con Apache Axis. 2006.

<http://www.siforge.org/articles/>

Progetto di un framework di sviluppo per dispositivi mobili Cuccaro Mimmo.pdf · Progetto di un...

Documents

Transcript of Progetto di un framework di sviluppo per dispositivi mobili Cuccaro Mimmo.pdf · Progetto di un...