Progetto di un framework di sviluppo per dispositivi mobili

Transcript

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
Ing. Marcello Cinque
CANDIDATO
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
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
I
Indice
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
II
Introduzione
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.
III
Introduzione
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.
IV
Introduzione
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.
V
Introduzione
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.
VI
Capitolo 1.
Applicazioni emergenti in ambienti mobili
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]:
1
Capitolo 1.
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).
2
Capitolo 1.
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;
2.
-
Dispositivi special-purpose (digital camera, barcone reader);
-
Microcontrollori, sensori e attuatori presenti nei sistemi di controllo.
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).
3
Capitolo 1.
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.
4
Capitolo 1.
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.
5
Capitolo 1.
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 specialpurpose (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,
6
Capitolo 1.
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.
7
Capitolo 1.
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.
8
Capitolo 1.
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
9
Capitolo 1.
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.
10
Capitolo 1.
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
11
Capitolo 1.
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.
12
Capitolo 1.
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.
13
Capitolo 2.
Soluzioni Middleware per il mobile computing
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].
14
Capitolo 2.
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.
15
Capitolo 2.
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
16
Capitolo 2.
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
Sistemi Distribuiti
Tradizionali
Pesante
(dispositivi fissi
e potenti)
Sincrona
(connessione
permanente)
Sistemi Mobile
Computing
Leggero
(dispositivi mobili
e poco potenti)
Asincrona
(connessione
intermittente)
CONTESTO
Statico
(il MW nasconde i
dettagli sul contesto
di esecuzione)
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].
17
Capitolo 2.
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.
18
Capitolo 2.
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
19
Capitolo 2.
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;
20
Capitolo 2.
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].
21
Capitolo 2.
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
22
Capitolo 2.
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 metaclassi 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.
23
Capitolo 2.
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].
24
Capitolo 2.
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.
25
Capitolo 2.
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-tomachine interaction over a network. It has an interface described in a machineprocessable 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.
26
Capitolo 2.
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.
27
Capitolo 2.
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.
28
Capitolo 2.
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,
29
Capitolo 2.
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
30
Capitolo 2.
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].
31
Capitolo 2.
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);
32
Capitolo 2.
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:
33
Capitolo 2.
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.
34
Capitolo 2.
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.
35
Capitolo 2.
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.
36
Capitolo 2.
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
37
Capitolo 2.
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.
38
Capitolo 2.
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.
39
Capitolo 2.
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).
40
Capitolo 2.
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.
41
Capitolo 2.
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 JSR172: 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.
42
Capitolo 2.
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
43
Capitolo 2.
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.
44
Capitolo 2.
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
45
Capitolo 2.
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
46
Capitolo 2.
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.
47
Capitolo 2.
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.
48
Capitolo 2.
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.
49
Capitolo 3.
Framework per l’integrazione di servizi in ambienti mobili
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
50
Capitolo 3.
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.
51
Capitolo 3.
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.
52
Capitolo 3.
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.
53
Capitolo 3.
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.
54
Capitolo 3.
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.
55
Capitolo 3.
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
56
Capitolo 3.
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.
57
Capitolo 3.
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
58
Capitolo 3.
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
59
Capitolo 3.
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)
60
Capitolo 3.
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
61
Capitolo 3.
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
62
Capitolo 3.
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.
63
Capitolo 3.
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:
64
Capitolo 3.
“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.
65
Capitolo 3.
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.
66
Capitolo 4.
Analisi di un caso studio: integrazione del servizio VoIP
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
67
Capitolo 4.
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
68
Capitolo 4.
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
69
Capitolo 4.
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;
70
Capitolo 4.
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;
71
Capitolo 4.
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
72
Capitolo 4.
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.
73
Capitolo 4.
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.
74
Capitolo 4.
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 prechiamata 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.
75
Capitolo 4.
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;
76
Capitolo 4.
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 clientserver. 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
77
Capitolo 4.
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.
78
Capitolo 4.
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.
79
Capitolo 4.
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]:
80
Capitolo 4.
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
81
Capitolo 4.
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).
82
Capitolo 4.
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.
83
Capitolo 4.
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
84
Capitolo 4.
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 SAMPLING
RATE (KHz)
(Kbps)
FRAME SIZE
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
(ms)
Tabella 4.1 – Caratteristiche dei codec comunemente usati nelle applicazioni VoIP
85
Capitolo 4.
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.
86
Capitolo 4.
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:
87
Capitolo 4.
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.
88
Capitolo 4.
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.
89
Capitolo 4.
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.
90
Capitolo 4.
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.
91
Capitolo 4.
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.
92
Capitolo 4.
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
93
Capitolo 4.
Registrazione
Login
UtenteGenerico
EffettuaChiamata
AccettaChiamata
UtenteRegistrato
TerminaChiamata
Cancellazione
Logout
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.
94
Capitolo 4.
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
2.a
Ritorno al punto 1
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.
95
Capitolo 4.
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;
96
Capitolo 4.
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.
97
Capitolo 4.
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
2.a
Ritorno al punto 1
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.
98
Capitolo 4.
VoIP client
Framework
VoIP client
VoIP client
Framework
Framework
Componente VoIP
Componente VoIP
Componente VoIP
mobile device A
mobile device B
mobile device C
SIP Server
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):
99
Capitolo 4.
Direttorio
UtenteGenerico
: String
- nome
- cognome : String
: String
- email
1..*
1..1
+ registrazione (UtenteGenerico utenteGenerico, String realm)
: UtenteRegistrato
+ cancellazione (String username, String password, String realm) : void
+ set () : void
+ get () : void
UtenteRegistrato
-
username
password
realm
geoNumber
:
:
:
:
UserAgent
0..1
String
String
String
String
1..1
: void
- gestioneEventi ()
+ login (String username, String password, String realm) : void
: void
+ logout ()
1..1
1..1
1..1
Trasporto
Sessione
+ apriCanale ()
: void
+ chiudiCanale () : void
+ apriSessione ()
: void
+ chiudiSessione () : void
Chiamata
- statoChiamata : int
+
+
+
-
effettuaChiamata (String targetSipURL) : void
: void
accettaChiamata ()
: void
terminaChiamata ()
: void
cambiaStato ()
1..1
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
100
Capitolo 4.
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):
101
Capitolo 4.
InterfacciaSIPServer
+ registrazione (UtenteGenerico utenteGenerico)
: UtenteRegistrato
+ cancellazione (String username, String password) : void
+ gestioneEventiSIP ()
: 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.
102
Capitolo 4.
Applicazione utente
Client VoIP
Framework Core
InterfacciaVoIPComponent
+
+
+
+
+
+
+
registrazione (UtenteGenerico utenteGenerico, String realm)
cancellazioneFramework
(String username,
String password, String realm)
Core
login (String username, String password, String realm)
logout ()
effettuaChiamata (String targetSipURL)
accettaChiamata ()
terminaChiamata ()
:
:
:
:
:
:
:
UtenteRegistrato
void
void
void
void
void
void
Package
VoIPComponent
Direttorio
UtenteGenerico
- nome
: String
- cognome : String
- email
: String
1..*
1..1
+ registrazione (UtenteGenerico utenteGenerico, String realm)
: UtenteRegistrato
+ cancellazione (String username, String password, String realm) : void
+ set () : void
+ get () : void
UtenteRegistrato
-
username
password
realm
geoNumber
:
:
:
:
UserAgent
0..1
String
String
String
String
1..1
- gestioneEventi ()
: void
+ login (String username, String password, String realm) : void
+ logout ()
: void
1..1
1..1
1..1
Trasporto
Sessione
+ apriCanale ()
: void
+ chiudiCanale () : void
+ apriSessione ()
: void
+ chiudiSessione () : void
Chiamata
- statoChiamata : int
+
+
+
-
effettuaChiamata (String targetSipURL) : void
accettaChiamata ()
: void
terminaChiamata ()
: void
cambiaStato ()
: void
1..1
InterfacciaSIPServer
+ registrazione (UtenteGenerico utenteGenerico)
: UtenteRegistrato
+ cancellazione (String username, String password) : void
+ gestioneEventiSIP ()
: void
SIPServer
Figura 4.10 - Vista completa del diagramma delle classi
103
Capitolo 4.
FrameworkCoreA
Chiamata A
User Agent A
SIP server
User Agent B
Chiamata B
FrameworkCoreB
utenteRegistratoA
utenteRegistratoB
login
REGISTER
ACK
effettuaChiamata
apriSessione
INVITE
INVITE
TRYING
cambiaStato
apriSessione
RINGING
gestioneEventi
cambiaStato
accettaChiamata
cambiaStato
apriCanale
ACK invite
cambiaStato
apriCanale
gestioneEventi
terminaChiamata
BYE/CANCEL
cambiaStato
gestioneEventi
chiudiCanale
chiudiSessione
ACK bye/cancel
cambiaStato
chiudiCanale
chiudiSessione
gestioneEventi
logout
BYE
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).
104
Capitolo 4.
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
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
Output
ottenuto
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.
105
Capitolo 4.
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.
Test Case
TC 3
TC 4
Input
Output atteso
username, password,
realm
(dati presenti presso il
server realm)
username, password,
realm
(dati non presenti
presso il server realm)
Output
ottenuto
UtenteRegistrato cancellato
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).
Test Case
Input
Output atteso
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
106
Output
ottenuto
Capitolo 4.
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.
Test Case
TC 8
Input
Output atteso
Richiesta disconnessione
Output
ottenuto
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).
Test Case
TC 9
TC 10
TC 11
Input
Output atteso
Richiesta di chiamata a
username@realm
(username@realm valido e
libero)
username@realm
(username non presente su
realm)
username@realm
(username@realm occupato
o realm non trovato)
107
Chiamata username@realm
SQUILLANDO…
UA: REFUSED (Does Not
Exist Anywhere)
UA: NON TROVATO/TIMEOUT
Output
ottenuto
Capitolo 4.
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).
Test Case
Input
Output atteso
Accetta chiamata
TC 12
Output
ottenuto
UA: CONFERMATA/CHIAMATA
AudioLauncher: apertura
audio java.....
UA: chiamata in
ingresso
calee@realm
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).
Test Case
TC 13
Input
Output atteso
UA: CHIUSA
AudioLauncher: chiusura
audio java...
Termina chiamata
108
Output
ottenuto
Capitolo 4.
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
109
Capitolo 4.
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);
110
Capitolo 4.
-
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.
111
Capitolo 4.
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;
112
Capitolo 4.
/* 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);
113
Capitolo 4.
}
/* 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.
logout
Chiamata in arrivo
IDLE
login
INCOMING CALL
terminaChiamata
accettaChiamata
effettuaChiamata
terminaChiamata
terminaChiamata
OUTGOING CALL
ONCALL
Chiamata accettata
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.
114
Capitolo 4.
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.
115
Capitolo 4.
TC 1
Metodo testato
registrazione
Input
nome, cognome,
e-mail, realm
(dati corretti)
Output atteso
Nuovo account SIP
Output ottenuto
Nuovo account SIP
TC 2
Metodo testato
registrazione
Input
nome, cognome,
e-mail, realm
(dati errati)
Output atteso
Nessun nuovo
account SIP
Output ottenuto
Nessun nuovo
account SIP
TC 3
Metodo testato
cancellazione
Input
username, password,
realm
(dati presenti presso il
server realm)
Output atteso
UtenteRegistrato
cancellato
Output ottenuto
UtenteRegistrato
cancellato
TC 4
Metodo testato
cancellazione
Input
username, password,
realm
(dati non presenti
presso il server realm)
Output atteso
UtenteRegistrato non
cancellato
Output ottenuto
UtenteRegistrato
non cancellato
TC 5
Metodo testato
login
Input
username, password,
realm
(dati corretti)
Output atteso
UA:
Registrazione
riuscita:
200 OK
Output ottenuto
UA:
Registrazione
riuscita:
200 OK
TC 6
Metodo testato
login
Input
username, password,
realm
(username, password
non corretti)
Output atteso
UA:
Registrazione
fallita:
401
Unauthorized
Output ottenuto
UA:
Registrazione
fallita:
401
Unauthorized
TC 7
Metodo testato
login
Input
username, password,
realm
(realm non corretto)
116
Output atteso
Output ottenuto
UA:
Registrazione
fallita:
Timeout
UA:
Registrazione
fallita:
Timeout
Capitolo 4.
TC 8
Metodo testato
logout
Input
Output atteso
Richiesta disconnessione
Disconnessione
Output ottenuto
Disconnessione
TC 9
Metodo testato
effettuaChiamata
Input
Output atteso
Chiamata
username@realm
username@realm
(username@realm
SQUILLANDO…
valido e libero)
Output ottenuto
Chiamata
username@realm
SQUILLANDO…
TC 10
Metodo testato
effettuaChiamata
Input
username@realm
(username non presente
su realm)
Output atteso
UA: REFUSED
(Does Not
Exist
Anywhere)
Output ottenuto
UA: REFUSED
(Does Not
Exist
Anywhere)
TC 11
Metodo testato
effettuaChiamata
Input
username@realm
(username@realm
occupato o realm non
trovato)
Output atteso
Output ottenuto
UA: NON
TROVATO/TIMEOUT
UA: NON
TROVATO/TIMEOUT
TC 12
Metodo testato
Input
Accetta chiamata
accettaChiamata
UA: chiamata in
ingresso
calee@realm
Output atteso
Output ottenuto
UA: CONFERMATA/
CHIAMATA
AudioLauncher:
apertura audio
java.....
UA: CONFERMATA/
CHIAMATA
AudioLauncher:
apertura audio
java.....
TC 13
Metodo testato
terminaChiamata
Input
Output atteso
Termina chiamata
UA: CHIUSA
AudioLauncher:
chiusura audio
java...
Output ottenuto
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#.
117
Capitolo 4.
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
118
Figura 4.14 - Chiamata in ingresso da
parte di “Vittorio”
Capitolo 4.
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.
119
Capitolo 4.
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.
120
Capitolo 5.
Conclusioni e sviluppi futuri
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.
121
Capitolo 5.
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.
122
Capitolo 5.
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.
123
Capitolo 5.
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.
124
Appendice
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;
125
Appendice
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’ecommerce 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.
126
Appendice
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.
127
Appendice
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
128
Appendice
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++.
129
Appendice
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/deserializzazione, 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
130
Appendice
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.
131
Appendice
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
132
Appendice
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.
133
Appendice
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.
134
Appendice
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.
135
Bibliografia
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
136
Bibliografia
[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.
137
Bibliografia
<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/>
138

Progetto di un framework di sviluppo per dispositivi mobili

Transcript

Documenti analoghi

Visualizza il PDF dell`indice

Pagina 1 di 1 Funkwerk Enterprise Communications [elmeg IP290

presentazione in formato pdf

Num. 31 del 18-11-2008

Implementazione di un servizio VoIP in ambienti SOA per mobile

draytek vigor 2800vg guida alla configurazione euteliavoip

indice generale

scarica presentazione in formato pdf

Guida breve Italiano

Progetto e sviluppo di un servizio di configurazione per ambienti

Cedam - Il reato aberrante di Dacqui` Giuseppe - Libri