UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea Progetto di un framework di sviluppo per dispositivi mobili RELATORE Chiar.mo Prof. Stefano Russo CORRELATORE CANDIDATO Ing. Marcello Cinque Domenico Cuccaro Matricola 41/3524 ANNO ACCADEMICO 2006-2007
148
Embed
Progetto di un framework di sviluppo per dispositivi mobili Cuccaro Mimmo.pdf · Progetto di un framework di sviluppo per dispositivi mobili RELATORE Chiar.mo Prof. Stefano Russo
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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 CANDIDATO Ing. Marcello Cinque Domenico Cuccaro Matricola 41/3524
ANNO ACCADEMICO 2006-2007
A mio nonno, esempio di vita,
che da lassù mi guida
Mi siedo e inizio a pensare agli ultimi anni della mia vita, e forse più in là. Gli
eventi, i luoghi e i volti si susseguono nella mia mente e mi accorgo che tante sono le cose
che ho dimenticato, eppure ciascuna di esse fa parte di me: ci sono persone che avrò
incontrato una sola volta nella mia vita, persone di cui non ricordo nemmeno il nome, le
stesse persone di cui, però, ricordo una frase o un gesto di cui ho deciso di “appropriarmi”,
più che nel ricordo, nel mio atteggiamento verso il mondo.
Poi, ci son le persone di sempre, quelle con cui vivo e son cresciuto: la mia famiglia
e la mia fraternità francescana. Mia madre mi ha insegnato cos’è l’amore e il sacrificio che
questo sentimento porta con sè; mio padre mi ha insegnato ad affrontare il mondo perché
egli stesso, a volte, senza un lamento, sembra portarne il peso; mia sorella Luana mi ha
insegnato a preservare e difendere le persone che ami.
Non oso immaginare la mia vita senza la mia fraternità, praticamente tutti i miei
ricordi passano per essa: frati e suore, uomini e donne, ragazzi e ragazze, bambini e
bambine, a ciascuno dei quali devo una carezza, un sorriso, una parola, una preghiera, un
litigio o un rimprovero. La mia fraternità: una famiglia all’ennesima potenza, in tutto.
Nella mia fraternità ho trovato anche chi, capace di perforare la corazza delle mie
paure, mi ha fatto innamorare: la mia piccola Denise che da due anni e mezzo sopporta le
mie ansie e supporta i miei sogni che spesso ci tengono “lontani”.
Per i miei studi universitari, un grazie particolare va al mio correlatore, Marcello
Cinque, e alla sua professionalità che, senza risparmio, ha saputo trasmettermi in questi
mesi dedicati allo sviluppo della tesi: spero di averne fatto tesoro per il mio futuro. Grazie
anche all’ingegner Vincenzo Vecchio che, seppur in poche occasioni, ha saputo
consigliarmi su scelte importanti e pratiche. Un sentito grazie va al professor Stefano
Russo per l’occasione, di studio e professionalità, a cui mi ha offerto la possibilità di
accedere e per avermi insegnato ad attribuire il giusto tempo alla crescita personale.
Voglio ringraziare i miei amici, Flavio e Vittorio, che, seppur in tempi diversi,
hanno condiviso con me questo percorso legato allo sviluppo della tesi.
In ultimo, auguro ai miei amici, di questi anni universitari, tutto il bene possibile e di
concludere i loro studi al più presto. Giovanni, Antonio, Umberto e Peppe: forza!
Indice
I
INDICE
INDICE.............................................................................................................................................................................. I
INTRODUZIONE ......................................................................................................................................................... III
1. APPLICAZIONI EMERGENTI IN AMBIENTI MOBILI...................................................................................... 1
1.1 CONCETTI BASE SUI SISTEMI DISTRIBUITI.................................................................................................................. 1 1.2 MOBILE COMPUTING ................................................................................................................................................. 3 1.3 PROBLEMATICHE RELATIVE AI SISTEMI MOBILI......................................................................................................... 6 1.4 SCENARI APPLICATIVI ............................................................................................................................................... 8 1.5 CONCLUSIONI ......................................................................................................................................................... 12
2. SOLUZIONI MIDDLEWARE PER IL MOBILE COMPUTING ........................................................................... 14
2.1 ASPETTI COMUNI DEI MIDDLEWARE......................................................................................................................... 14 2.2 DIFFERENZE TRA MIDDLEWARE PER SISTEMI TRADIZIONALI E PER SISTEMI MOBILI ................................................. 16 2.3 MIDDLEWARE PER SISTEMI MOBILI........................................................................................................................... 18
2.3.1 Middleware tradizionali adattati al Mobile Computing................................................................................. 18 2.3.2 Middleware creati Ad-Hoc per Mobile Computing........................................................................................ 21
2.4 WEB SERVICES ......................................................................................................................................................... 26 2.5 SOLUZIONI OFFERTE DALLA JAVA COMMUNITY........................................................................................................ 29
2.5.1 Introduzione alla piattaforma J2ME.............................................................................................................. 29 2.5.2 Configuration e Profile .................................................................................................................................. 31 2.5.3 Java RMI ........................................................................................................................................................ 36 2.5.4 J2ME Web Services: JSR-172 e kSOAP......................................................................................................... 39 2.5.5 Jini.................................................................................................................................................................. 43
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.2 Confronto tra le possibili scelte tecnologiche ................................................................................................ 62 3.4.3 Prospettive di mercato ................................................................................................................................... 64
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.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
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
Da un punto di vista sintattico non vi è alcuna differenza fra un oggetto locale ed
uno remoto.
Capitolo 2. Soluzioni Middleware per il mobile computing
37
o Non necessita di un protocollo di definizione dei messaggi: la gestione della
comunicazione tra applicativo locale e remoto è completamente gestita da RMI
senza la necessità di doversi implementare un protocollo proprietario per tale
gestione.
o Utilizzo del paradigma ad oggetti.
Prima dell’introduzione di RMI erano già disponibili soluzioni al problema
dell’esecuzione di parti di codice in remoto, come ad esempio la Remote Procedure Call
(RPC): con questa tecnologia è possibile gestire procedure facenti parte di applicazioni
residenti in remoto rispetto al chiamante. Le RPC sono strettamente legate al concetto di
processo e di procedura e quindi male si inseriscono nel contesto del paradigma ad oggetti.
E’ questo il motivo principale che ha fatto nascere l’esigenza di una tecnologia apposita
per la gestione di oggetti ditribuiti, la quale vede in RMI la soluzione full-Java
completamente Object Oriented.
RMI si basa sull’interazione tra tre entità distinte [25]:
o uno o più server RMI;
o il Java RMI Registry (localizzato sul server);
o uno o più client RMI.
Il server RMI implementa un’interfaccia relativa ad un particolare oggetto RMI e registra
tale oggetto nel Java RMI Registry. Il Java RMI Registry è, semplicemente, un processo
di tipo daemon che tiene traccia di tutti gli oggetti remoti disponibili su un dato server. Il
client RMI effettua una serie di chiamate al registry RMI per ricercare gli oggetti remoti
con cui interagire.
Le modalità con cui un oggetto che si trova su una macchina client riesce ad invocare dei
metodi che sono definiti su un’altra macchina (server) e la gestione delle problematiche
Capitolo 2. Soluzioni Middleware per il mobile computing
38
legate alla comunicazione di rete dipendono da due componenti che nel diagramma
precedente sono denominati Skeleton e Stub.
Figura 2.7 - Meccanismo di funzionamento della tecnologia Java RMI
Dettagliamo il meccanismo utilizzando la medesima numerazione riportata in Figura 2.7:
1. Viene creata sul server una istanza dell’oggetto remoto e passata in forma di stub
al Java RMI registry. Tale stub viene, quindi registrato all’interno del registry
stesso;
2. L’applicazione client richiede al registry RMI una copia dell’oggetto remoto da
utilizzare;
3. Il Java RMI registry restituisce una copia serializzata dello stub al client;
4. L’applicazione client invoca uno dei metodi dell’oggetto remoto utilizzando la
classe “clone” fornita dallo stub;
5. Lo stub richiama lo skeleton che si trova sul server chiedendogli di invocare
sull’oggetto remoto lo stesso metodo che il client ha invocato sullo stub;
6. Lo skeleton invoca il metodo richiesto sull’oggetto remoto;
7. L’invocazione del metodo sull’oggetto remoto restituisce il risultato allo skeleton;
8. Lo skeleton comunica il risultato allo stub sul client;
9. Lo stub fornisce il risultato all’applicazione client iniziale.
Capitolo 2. Soluzioni Middleware per il mobile computing
39
La scelta di utilizzare RMI è consigliabile nel caso in cui si debba implementare una
struttura a oggetti distribuiti full-Java, in maniera semplice e veloce. L’alta semplicità di
RMI si paga a volte nei confronti delle tecnologie concorrenti più sofisticate (e
complicate) che offrono maggiore potenzialità e scalabilità.
Java RMI è una tecnologia nata per ambienti desktop (J2SE) ed estesa, come package
opzionale (OP), al mondo mobile (J2ME) e destinata, come descritto dal documento di
specifica JSR-66, a “sistemi ancor più differenti”, non solo desktop e server, ma anche
piccoli dispositivi mobili, come palmari e PDA.
RMI OP è un sottoinsieme di J2SE RMI che può essere usato sui dispositivi che
supportano la configurazione CDC.
2.5.4 J2ME Web Services: JSR-172 e kSOAP
Vediamo ora il rapporto tra un Web Service ed una applicazione in esecuzione in un
ambiente J2ME. Sebbene tutto sia possibile, è abbastanza difficile che il ruolo di una
applicazione J2ME sia quello di server. In effetti, la piattaforma J2ME nasce per
realizzare ed eseguire piccole applicazioni stand-alone. Inoltre, nel caso della
configurazione CDLC, non è possibile realizzare applicazioni thread, poiché la
piattaforma non riconosce tale paradigma. Per questo motivo è iniziata la
standardizzazione di quelli che sono gli strumenti che un sistema client J2ME può
utilizzare per l’invocazione di Web Services, raccolta sotto il nome di JSR-172 Web
Services on J2ME Platform.
Le API (WSA, J2ME Web Services API) descritte in queste specifiche sono un
sottoinsieme di quelle definite nell’ambiente J2SE, come nel caso di altre API [26].
Si tratta di specifiche, basate sul WS-I Basic Profile 1.0, che hanno lo scopo di
standardizzare quelle che sono le principali caratteristiche di un client per Web Service,
ovvero le invocazione di funzioni remote e il parsing XML.
Capitolo 2. Soluzioni Middleware per il mobile computing
40
L’utilizzo di un dispositivo cellulare o PDA come server di un servizio Web non sarebbe,
almeno con le potenzialità dei sistemi attuali e la limitata connettività, una scelta che trova
attualmente molti riscontri.
Le WSA sono quindi pensate per poter essere eseguite sia per configurazioni CDC che
CDLC. Come accaduto per altre API per l’ambiente J2ME, esse sono state ottenute
attraverso una selezione di quelle che sono le API analoghe disponibili per J2SE.
Le JSR-172 permettono di dotare un dispositivo J2ME delle funzionalità caratteristiche di
un client, ma non di tutte le funzionalità tipiche di un client J2SE: la ricerca di servizi
attraverso la tecnologia UDDI non è una funzionalità prevista da un client che utilizzi le
WSA. Un client potrebbe, inoltre, non solo accedere ad un servizio, ma anche eseguire
operazioni di deploy, undeploy o altre operazioni che definiamo di amministrazione.
Anche queste operazioni per il momento non sono supportate dalle WSA descritte dalle
JSR-172.
Il ruolo delle WSA è permettere, ad un dispositivo J2ME, di poter accedere ed utilizzare
un servizio esposto attraverso un’interfaccia Web Service. Lo scenario principale prevede
un client J2ME che utilizza un particolare servizio remoto a runtime come se fosse locale,
quindi in modo semplice e snello. Analogamente a quanto avviene nel caso J2SE, le WSA
ci dovranno mettere a disposizione uno strumento per generare degli stub che, attraverso
un servizio locale a runtime, ci permetteranno di accedere ad un Web Service in modo
trasparente.
L’architettura di un’applicazione J2ME, che utilizza le WSA, prevede la definizione delle
seguenti componenti [26]:
o applicazione J2ME che intende utilizzare un particolare Web Service;
o uno stub compliant con le JSR-172;
o un servizio a cui lo stub accede a runtime attraverso un’interfaccia che prende il
nome di Service Provider Interface (SPI).
Capitolo 2. Soluzioni Middleware per il mobile computing
41
Il ruolo del Service Provider Interface è quello di astrarre i servizi di gestione della
connessione e codifica dei dati dalla effettiva implementazione, lasciata al particolare
vendor. L’implementazione dei servizi descritti dalla Service Provider Interface prende il
nome di Runtime.
Figura 2.8 - Architettura del J2ME Web Services API
Dalla Figura 2.8 si nota come una particolare applicazione non utilizzi direttamente i
servizi della SPI, ma vi acceda attraverso lo Stub, che viene generato in modo automatico
a partire dal WSDL di un servizio attraverso l’utilizzo di un insieme di tools forniti dal
particolare vendor.
La modalità di accesso alle funzionalità di Runtime attraverso l’utilizzo di un Stub è il
modo più semplice per accedere ad una Web Service attraverso WSA, le quali mettono a
disposizione anche API di più basso livello.
Capitolo 2. Soluzioni Middleware per il mobile computing
42
Oltre agli strumenti per l’invocazione di servizi Web, le WSA forniscono le API per il
parsing di documenti XML.
La Java Community mette a disposizione gli strumenti per utilizzare le specifiche JSR-
172: il Wireless ToolKit (WTK) per CDLC, ora giunto alla versione 2.5, e il Sun Java
ToolKit per CDC, versione 1.0.
In particolare, già dalla versione 2.1, WTK include la funzionalità Stub generator, che a
partire dalla descrizione WSDL del servizio a cui vogliamo accedere, genera in modo
automatico una serie di classi Java che costituiscono lo stub e consentono al client J2ME
di accedere in modo trasparente al servizio
In alternativa alle specifiche JSR-172, possiamo adottare le k-Solution.
Le specifiche JSR-172 si preoccupano di creare un meccanismo veloce per integrare al
client J2ME una serie di classi Java che costituiscono lo stub, grazie al quale l’accesso ai
servizi remoti avviene in modo del tutto trasparente [27].
Con le k-Solution, il client accede al servizio in modo leggermente diverso. In questo caso
il paradigma di accesso al Web Service si basa su un progetto iniziato come open-source
dalla comunità Enhydra.org. Tali librerie sono raggruppate, forse impropriamente, sotto il
nome kSOAP: esse includono non solo le funzioni di impacchettamento tipiche del
protocollo SOAP, ma anche quelle di serialization e parser.
Il profilo MIDP consente la connessione del dispositivo wireless via HTTP e kSOAP
fornisce la classe aggiuntiva org.ksoap.transport.HttpTransport che automatizza il
processo HTTPcall [27] illustrato di seguito:
1. il client compone il messaggio di richiesta con gli opportuni parametri;
2. il client invia la richiesta SOAP all’endpoint del servizio utilizzando il protocollo
HTTP;
3. il server elabora la richiesta e compone il messaggio SOAP di risposta;
4. il server invia la risposta via HTTP, tramite la stessa connessione della richiesta;
5. il client elabora la risposta.
Capitolo 2. Soluzioni Middleware per il mobile computing
43
Con l’uso delle librerie kSOAP – kXML, possiamo saltare la fase di Stub generator
fornita dal tool della Sun WTK. Basta includere tali librerie nel progetto J2ME ed esse
permetteranno l’accesso ai servizi remoti. Questa è la sostanziale differenza con le
specifiche JSR-172: in quest’ultime il client Java accede ad un clone-Java locale del
servizio remoto (lo stub, appunto), mentre in questo caso le librerie kSOAP effettuano il
packing SOAP e il parser direttamente sul descrittore WSDL del servizio remoto. Ciò
rallenta il processo di interrogazione del servizio, ma dona maggiore dinamicità: se varia
l’interfaccia del servizio remoto, le JSR-172 richiedono una nuova generazione dello stub,
oltre che una modifica del client.
2.5.5 Jini
Mentre Java RMI è una tecnologia Java adattata al mobile computing, Jini [28] nasce per
permettere la realizzazione e la distribuzione dei servizi in rete tra dispositivi che spaziano
da minisistemi wireless ai PC, sino ai grandi server, basandosi sulla portabilità del codice
offerta dalla JVM.
Utilizzando protocolli di rete, Jini permette di mettere in comunicazione oggetti differenti
fra loro, dove ognuno mette a disposizione dei servizi per tutti coloro che ne abbiano
necessità.
In una comunità Jini i servizi possono essere dinamicamente aggiunti o tolti, le
applicazioni possono poi ricercare tali servizi ed usarli, senza averne a priori una specifica
conoscenza.
Ad esempio, una stampante, nel momento in cui si connette ad una comunità Jini, prima si
presenterà e poi esporrà la sua interfaccia, contenente per esempio il servizio print. Se
successivamente un frigorifero Jini dovesse aver bisogno di stampare una pagina con dei
dati relativi al proprio funzionamento, sarà sufficiente che vada a ricercare chi nella
comunità mette a disposizione il servizio print e poi richiederne l’esecuzione.
Il concetto più importante all’interno dell’architettura Jini è quello di servizio [29]. Un
servizio è un’entità che può essere usata da una persona, da un programma, o da un altro
Capitolo 2. Soluzioni Middleware per il mobile computing
44
servizio. Un servizio può essere computazione, memoria, un canale di comunicazione, un
dispositivo hardware, o un altro utente. Due esempi dei servizi sono: stampare un
documento e tradurre un documento da un formato ad un altro.
Un sistema Jini deve pensarsi come un sistema di servizi che sono messi insieme per il
compimento di una particolare operazione. I servizi possono usare altri servizi e un client
di un servizio può essere anch’esso un servizio per altri clients.
I servizi sono trovati dal Lookup Service: una tabella contenente le interfacce che
descrivono le funzionalità dei servizi presenti nella comunità Jini. In aggiunta vengono
memorizzate le descrizioni testuali dei vari servizi, in modo da essere maggiormente
comprensibili da un utilizzatore umano.
La comunicazione fra i servizi avviene utilizzando Java RMI.
L’accesso a molti dei servizi nell’ambiente Jini è basato sui leasing [29]. Un leasing è una
concessione di accesso garantito per un certo periodo di tempo. Ogni leasing è negoziato
fra il richiedente e il fornitore del servizio: un servizio è chiesto per un certo periodo;
l’accesso è assegnato per un periodo la cui durata è decisa dall’ambiente Jini sulla base del
periodo richiesto e dello stato dell’ambiente.
2.6 Soluzioni .NET
2.6.1 Panoramica su .NET Framework
Microsoft ha sviluppato .NET [30] come contrapposizione proprietaria al linguaggio Java.
.NET e il suo linguaggio principe, ovvero C#, sono standard ISO riconosciuti.
La sua caratteristica peculiare è di essere indipendente dalla versione operativa di
Windows su cui è installata, e di includere molte funzionalità progettate espressamente per
integrarsi in ambiente internet e garantire il massimo grado di sicurezza e integrità dei
dati.
Capitolo 2. Soluzioni Middleware per il mobile computing
45
La CLR (Common Language Runtime) è un insieme di librerie che, insieme alla classe
di librerie di base denominata FCL (Framework Class Library), è progettata per poter
funzionare con qualsiasi sistema operativo. Il compilatore Just In Time esegue un codice
assembly denominato CIL (Common Intermediate Language). È inoltre possibile:
o accedere a componenti scritti in altri linguaggi;
o quando il sistema operativo sottostante è Microsoft Windows, accedere ai suoi
servizi e alle sue API;
o accedere ai Web Services utilizzando il protocollo SOAP.
La CLI (Common Language Infrastructure) è concepita per essere compatibile con
qualsiasi linguaggio di alto livello orientato agli oggetti, fornendo un unico modello a
oggetti ed una vasta libreria di classi condivisibili.
La CLI, il CIL ed il C# sono simili rispettivamente alla JVM ed al linguaggio Java della
Sun Microsystems, con cui sono in forte concorrenza. Entrambi utilizzano un proprio
bytecode intermedio. Il bytecode di .NET è progettato per essere compilato al momento
dell’esecuzione (Just In Time compilation, detta anche JITting).
Al momento .NET è compatibile soltanto con le piattaforme Windows. Tuttavia, grazie al
progetto Mono di Novell è possibile sviluppare e eseguire client e server application .NET
su piattaforme diverse, non Windows.
2.6.2 .NET Compact Framework
La proposta Microsoft per il mobile è una versione “compatta” della piattaforma .NET.
.NET Compact Framework [31] è un ambiente indipendente dall’hardware che consente
di eseguire programmi su dispositivi quali PDA, cellulari e set-top box. Viene eseguito nel
sistema operativo Microsoft Windows CE e si basa su CLR rigenerato che è stato
progettato per funzionare in modo ottimale quando si eseguono programmi su dispositivi
con risorse limitate. .NET Compact Framework estende la disponibilità di codice gestito e
Capitolo 2. Soluzioni Middleware per il mobile computing
46
di servizi Web XML ai dispositivi mobili e offre vantaggi quali l’indipendenza dai tipi, la
Garbage Collection, la gestione delle eccezioni e la sicurezza.
.NET Compact Framework, che rappresenta un sottoinsieme della libreria di classi .NET
Framework, contiene anche classi appositamente progettate per dispositivi con risorse
limitate ed eredita interamente l’architettura .NET Framework per Common Language
Runtime e l’esecuzione di codice gestito.
.NET Compact Framework è disponibile come componente di sistema operativo in tutti i
dispositivi Microsoft Smart Device, inclusi PocketPC, PocketPC Phone Edition,
Smartphone e altri dispositivi basati su Windows CE.
Architettura
In Figura 2.9, riportata di seguito, viene riepilogata l’architettura della piattaforma .NET
Compact Framework.
Figura 2.9 - Architettura della piattaforma .NET Compact Framework
Windows CE
.NET Compact Framework utilizza il sistema operativo Windows CE per le funzionalità
essenziali e per numerose funzionalità specifiche del dispositivo. Diversi tipi e assembly,
ad esempio, quelli per i Windows Form, le immagini, il disegno e i servizi Web, sono stati
Capitolo 2. Soluzioni Middleware per il mobile computing
47
rigenerati per un’esecuzione efficiente sui dispositivi, anziché copiati dalla versione
completa di .NET Framework.
In .NET Compact Framework sono disponibili i seguenti tipi di interoperabilità con
Windows CE:
o compatibilità con la protezione nativa;
o integrazione completa con i programmi di installazione nativa;
o interoperabilità con il codice nativo mediante l’interoperabilità COM e il richiamo
piattaforma.
Common Language Runtime
Anche Common Language Runtime (CLR) di .NET Compact Framework è stato
rigenerato per consentire l’esecuzione delle risorse vincolate sulla memoria limitata e
l’utilizzo efficiente dell’alimentazione a batteria.
Tra Windows CE e CLR esiste un livello di adattamento piattaforma che consente di
mappare i servizi e le interfacce dei dispositivi necessarie per CLR e per il framework sui
servizi e le interfacce di Windows CE.
Framework
.NET Compact Framework, che rappresenta un sottoinsieme di .NET Framework, contiene
anche funzionalità appositamente progettate per .NET Compact Framework. Offre le
funzionalità e la semplicità che consentono agli sviluppatori di applicazioni per dispositivi
nativi di passare a .NET Framework e agli sviluppatori di applicazioni desktop di passare
ai dispositivi.
Ogni applicazione .NET Compact Framework viene eseguita all’interno di un costrutto di
runtime denominato dominio applicazione, analogo a un processo del sistema operativo.
.NET Compact Framework garantisce che tutte le risorse gestite utilizzate da
un’applicazione in esecuzione vengano liberate o restituite al sistema operativo host al
termine dell’applicazione.
Capitolo 2. Soluzioni Middleware per il mobile computing
48
I domini applicazione offrono numerosi vantaggi caratteristici dei processi, quali
l’isolamento degli errori e livelli elevati di affidabilità e protezione, senza richiedere il
supporto del sistema operativo sottostante. Nell’host di un dominio applicazione,
costituito a propria volta da codice del sistema operativo nativo, viene avviata un’istanza
di CLR. CLR può essere collegato all’host del dominio applicazione in modo statico o
dinamico.
Utilizzo della memoria
Quando è disponibile una quantità di memoria insufficiente, in .NET Compact Framework
vengono automaticamente rilasciate le strutture di dati non richieste dal codice attualmente
in esecuzione. Di conseguenza, il programma può essere eseguito anche in presenza di
memoria limitata. Se l’applicazione richiede una quantità di memoria superiore rispetto a
quella disponibile, l’applicazione viene chiusa correttamente da .NET Compact
Framework e vengono rilasciate tutte le risorse sottostanti.
2.7 Conclusioni
Si chiude qui la panoramica sulle tecnologie middleware analizzate per il mondo mobile
computing. L’aspetto comune di ciascuna tecnologia è la necessità di introdurre nello
sviluppo, e quindi nell’uso, delle applicazioni tool e librerie aggiuntive che garantiscano
trasparenza e dinamicità, anche con aspetti e gradi diversi. Per esempio, la soluzione RMI
garantisce trasparenza all’uso del servizio remoto, ma non al linguaggio e si adatta bene a
soluzioni full-Java, in cui anche il servizio remoto sia implementato in linguaggio Java. Le
soluzioni middleware e Web Services garantiscono trasparenza al linguaggio con
prestazioni diverse.
Particolare attenzione è stata data alle soluzioni Java mobile e, in particolare, al profilo
J2ME MIDP, valido anche nel caso di un dispositivo CDC.
Capitolo 2. Soluzioni Middleware per il mobile computing
49
Altro aspetto comune delle tecnologie analizzate è che esse estendono le funzionalità
mobile solo da un punto di vista client, nel senso che il servizio remoto è in ogni caso
fornito da una macchina fissa, server o quantomeno desktop.
Nel prossimo capitolo focalizzeremo la nostra attenzione sullo scopo reale di questo studio
di tesi, ovvero integrare un framework di servizi su un dispositivo mobile. L’ambizione è
quella di far risiedere il framework sul dispositivo mobile (per esempio, un palmare) con il
compito di facilitare la realizzazione di applicazioni che ne sfruttino i servizi in modo
trasparente.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
50
3. Framework per l’integrazione di servizi in ambienti mobili
3.1 Obiettivi del framework
Nel capitolo precedente abbiamo parlato delle soluzioni middleware per mobile
computing. Implicitamente abbiamo assunto che si trattasse di ambienti nomadici, ovvero
il grosso del carico computazionale relativo al middleware, se non tutto, fosse delegato
alla parte fissa dell’ambiente distribuito, mentre la parte mobile, in senso stretto, svolgesse
funzioni di thin client.
L’ambiente nomadico di riferimento non è stato presentato in senso architetturale:
abbiamo pensato ad un ambiente LAN/WAN senza togliere la possibilità che i servizi
risiedessero su un server remoto accessibile via Internet.
Nell’ambito del progetto “WiFi People – CRONOS”, gli obiettivi richiesti per il
framework vanno oltre lo stato dell’arte attuale:
o si vuole uscire dal sistema necessariamente nomadico e orientarsi ad un sistema
Ad-Hoc, indipendente da qualunque infrastruttura fissa. Per ottenere quanto detto,
è necessario che il framework risieda sul dispositivo mobile ed offra una serie di
servizi.
o Dal punto di vista dell’utenza, il servizio principe fornito dal framework deve
essere l’autoconfigurazione e l’autodistribuzione: un dispositivo mobile che
entra a far parte della rete, “spontaneamente” costituita, deve essere messo in
condizione di poter conoscere e ricevere dal dispositivo mobile più vicino le
applicazioni distribuite sulla rete che usano, appunto, i servizi del framework
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
51
stesso. Lo scopo è che ogni dispositivo mobile (palmari, PDA…), appartenente al
sistema mobile in questione, sia in grado di eseguire le applicazioni così
distribuite. Sarà il framework a farsi carico della distribuizione dei servizi di cui
necessita l’applicazione.
o Dal punto di vista della programmazione, il framework deve rispettare vincoli di
trasparenza tipici di un middleware, garantendo ai programmatori del dispositivo
mobile di poter realizzare applicazioni complesse che accedano a tali servizi.
3.2 Requisiti del framework
Possiamo immaginare il framework diviso in due parti: la parte più interna, costituita dai
servizi, che dovrà soddisfare i requisiti funzionali, e la parte con cui le applicazioni utente
e gli sviluppatori sono direttamente a contatto, ovvero il Framework Core, che sarà
progettato sulla base dei requisiti non funzionali richiesti dal progetto “WiFi People –
CRONOS”.
3.2.1 Requisiti funzionali
Di seguito riportiamo i servizi che il framework deve offrire. Si dia particolare attenzione
all’ultimo servizio, su cui poggia la distribuzione delle applicazioni tra i dispositivi mobili,
rendendo non necessaria la presenza dell’infrastruttura fissa.
Discovery dei servizi
Il servizio permette al dispositivo di scoprire quali servizi sono disponibili sulla rete e
indicarne la disponibilità. Il servizio di discovery permette di accedere ai servizi scelti e ne
consente l’utilizzo. Inoltre la configurazione del dispositivo e la ricerca sono totalmente
automatiche e, quindi, non a carico dell’utente.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
52
VoIP
Si vuole fornire un servizio di telefonia sul protocollo IP. Il dispositivo mobile diviene un
client con la capacità di effettuare e ricevere chiamate attraverso la rete Internet.
Positioning/GPS
Si intende fornire un servizio per la localizzazione del dispositivo mobile in un ambiente
fisico indoor e, attraverso le sue coordinate GPS, in ambiente fisico outdoor.
Per fornire il servizio di positioning è possibile utilizzare indistintamente la tecnologia
Bluetooth oppure la tecnologia Wi-Fi. L’ambiente indoor, nel quale si intende localizzare
la posizione del dispositivo, dovrà essere opportunamente cablata con Access Point Wi-Fi
o Bluetooth.
Il palmare che offre il servizio GPS deve necessariamente essere dotato di un dispositivo
GPS integrato o deve essere in grado di interfacciarsi con un dispositivo GPS esterno.
Sincronizzazione dati
Si vuole fornire un servizio di sincronizzazione di e-mail, contatti ed appuntamenti tra
dispositivi.
Accesso DB
Si intende fornire un servizio per l’accesso ad un generico database remoto di
informazioni. Si prevede una copia parziale del DB in locale di cui garantire la coerenza
con il DB remoto. Tale procedura si attiva indoor in maniera automatica o su richiesta
dell’utente.
Instant Messaging
Si vuole fornire un servizio di messaggistica istantanea e presenza. Il dispositivo mobile
diviene un client in grado di scambiare messaggi real-time con altri dispositivi.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
53
Interfacciamento periferiche esterne
Il servizio in questione intende offrire un’interfaccia standard di comunicazione con
periferiche esterne e non integrate nel dispositivo mobile, come, ad esempio, stampanti
Bluetooth e videocamere wireless.
Gestione canale SMS per notifiche ed alert
Tale servizio intende offrire la possibilità di inviare messaggi di testo SMS al fine di
effettuare delle notifiche e generare degli alert. Per usufruire di tale servizio è necessario
che il dispositivo mobile sia dotato di una scheda GSM o di un modem GPRS.
Video-streaming
Il servizio di video-streaming offre la possibilità di gestire i flussi video da e verso il
dispositivo mobile. Il video-streaming, effettuato anche in multicast, verso altri dispositivi
mobili può avere come sorgente un file video oppure, qualora fosse presente una
telecamera sul dispositivo mobile sorgente, consentire la condivisione delle immagini che
essa riprende.
Distribuzione del framework e discovery di applicazioni
Si intende fornire un meccanismo per cui l’utente può sapere, attraverso il suo dispositivo
mobile, quali applicazioni sono già presenti sui dispositivi appartenenti all’area a cui si è
connesso.
Si intende dare all’utente la possibilità di effettuare il download di tali applicazioni ed,
eventualmente, dei relativi servizi necessari per il corretto funzionamento
dell’applicazione stessa.
Le applicazioni così distribuite possono accedere ai servizi del framework localmente
oppure demandandone l’esecuzione ai dispositivi mobili circostanti.
Qualora il dispositivo mobile possegga una versione più vecchia dell’intero framework o
di una parte dei servizi, può effettuarne l’aggiornamento.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
54
3.2.2 Requisiti non funzionali
Trasparenza dal linguaggio
Si intende l’indipendenza da un qualsiasi linguaggio di programmazione con cui uno
sviluppatore potrà implementare le applicazioni utente che dovranno interagire con il
framework per accedere ai servizi offerti. Ciò prevede l’omogeneizzazione dei dati tramite
il marshalling e unmarshalling dei dati.
Trasparenza dal Sistema Operativo
Si intende l’indipendenza da un particolare sistema operativo che possa trovarsi sul
dispositivo mobile su cui installare il framework. In particolare i sistemi operativi che
vengono presi in considerazione sono Symbian, Linux, Windows Mobile.
Trasparenza alla comunicazione
Si intende garantire la comunicazione tra i framework e i servizi, distribuiti su tutti i
dispositivi mobili, a prescindere dai protocolli di comunicazione adottati dall’infrastruttura
di rete.
Load balancing
Con load balancing si intende la possibilità di distribuire il carico, cioè l’ottimizzazione
dell’utilizzo delle risorse di calcolo tale che si migliorino le performance dei servizi
forniti.
Utilizzo di strumenti open-source
Si vogliono sfruttare componenti open-source presenti sul mercato, in particolare sulla
rete Internet, per la realizzazione dei servizi, descritti in precedenza, che deve fornire il
sistema.
Portabilità dei servizi
Si intende la capacità del sistema e in particolare dei singoli servizi di “migrare” in nuovi
ambienti, cioè su piattaforme diverse, garantendone il corretto funzionamento e utilizzo.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
55
Prestazioni
Inizialmente non daremo peso ai limiti tecnologici imposti dai dispositivi mobili presenti
attualmente sul mercato, puntando ad una prima soluzione intermedia in cui il framework
sia distribuito in parte sui dispositivi mobili stessi e in parte su macchine remote. L’idea è
quella che, con l’introduzione sul mercato di nuovi e più potenti dispositivi mobili, il
framework possa risiedere interamente su quest’ultimi, garantendo prestazioni adeguate
alle applicazioni real-time.
Manutenibilità
E’ importante garantire una facile manutenzione del framework sia nell’ambito delle scelte
tecnologiche per la realizzazione del Framework Core sia dal punto di vista dei servizi.
Operazioni di aggiornamento, tanto del framework quanto della tecnologia, devono poter
essere svolte con semplicità dagli sviluppatori e avvenire in trasparenza rispetto agli utenti
finali.
3.3 Architettura del framework
Il Framework Core si pone come strato intermedio tra i servizi e le applicazioni (Figura
3.1), sia dal punto di vista dello sviluppo di queste ultime, sia dal punto di vista
dell’applicazione utente che, per essere correttamente eseguita, deve accedere a
determinati servizi.
Oltre a permettere l’accesso ai servizi in locale, l’architettura del sistema prevede di
mettere in comunicazione diretta due o più dispositivi mobili, per esempio palmari. Il
framework fornisce l’astrazione necessaria a livello applicazione affinché agli utenti sia
del tutto trasparente la necessità di installare nuovi servizi da integrare nel framework
oppure la necessità di aggiornarne qualche componente.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
56
Figura 3.1 - Architettura del framework: Framework Core e servizi
Un ruolo fondamentale riveste il servizio di Discovery dei servizi. Esso è il servizio che
necessariamente va distribuito tra i palmari che vogliono godere della trasparenza sopra
descritta. Tale servizio, unito a quelli di Aggiornamento framework e Download
framework, costituisce l’insieme dei servizi necessari per la gestione del framework
(indicati in verde in Figura 3.1).
Per esigenze legate alla manutenibilità tutti i servizi saranno scritti in un unico linguaggio
in modo che le competenze richieste per la manutenzione completa siano contenute.
Tuttavia ciò non vincola gli sviluppatori di applicazioni consumer ad adottare lo stesso
linguaggio in cui sono implementati i servizi, grazie alla trasparenza dal linguaggio
garantita dal Framework Core.
Vediamo, di seguito, i possibili scenari in cui il framework può trovarsi ad operare.
Partiamo dalla prima configurazione in cui il framework e i servizi sono totalmente
distribuiti sui dispositivi mobili (Figura 3.2). In questo caso la comunicazione tra i
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
57
dispositivi mobili e/o la collaborazione tra i servizi, presenti su ciascuno di essi, avverrà in
modo diretto senza la necessità di alcuna infrastruttura fissa intermediaria.
Figura 3.2 - Configurazione 1: Deployment del Framework su due dispositivi mobili
Per collaborazione tra i servizi intendiamo che affinché l’applicazione utente sia
correttamente eseguita è necessario avere a disposizione una determinata serie di servizi,
nonché una loro collaborazione diretta.
Per collaborazione tra i dispositivi mobili intendiamo il caso in cui i servizi non siano
tutti presenti sul dispositivo mobile o non eseguibili in locale. Può infatti accadere che
un’applicazione utente in esecuzione su un dispositivo mobile necessiti di un servizio non
presente o non eseguibile nel framework locale. In tal caso, possiamo adottare due strade
affinché l’esecuzione dell’applicazione utente vada comunque a buon fine:
1. il Framework Core si farà carico di eseguire sui dispositivi mobili più vicini una
ricerca del servizio mancante e, una volta trovato, ne effettuiamo il download sul
nostro dispositivo mobile (in Figura 3.3 riportiamo il download di un servizio IM).
Emerge, e risulta necessaria, in tale contesto la portabilità dei servizi richiesta al
framework.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
58
Figura 3.3 - Scenario 1: Download di un servizio mancante
2. Previa un’analoga operazione di ricerca del servizio, il Framework Core chiederà
al dispositivo mobile più vicino di eseguire per noi (esecuzione demandata) il
servizio mancante (in Figura 3.4 riportiamo l’esecuzione demandata di un servizio
IM). Tale contesto va incontro alle esigenze di load balancing, infatti un
dispositivo mobile può avvalersi dell’esecuzione demandata anche nel caso in cui
le risorse a sua disposizione non permettano l’esecuzione del servizio in locale.
Figura 3.4 - Scenario 2: Esecuzione demandata di un servizio mancante
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
59
In quest’ottica vanno fatte delle considerazioni. Percorrere l’una o l’altra via per sopperire
alla mancanza di un servizio in locale non è indifferente; bisogna tener conto sia del tipo
di applicazione utente sia del tipo di servizio. Se l’applicazione utente che richiede il
servizio è fortemente real-time, conviene effettuare il download prima che l’applicazione
sia in esecuzione o al più in fase di caricamento della stessa; così come non avrebbe senso
demandare l’esecuzione del servizio GPS ad un altro dispositivo mobile, a meno che non
ci interessi conoscere le coordinate GPS di quest’ultimo. Allo stesso modo sarebbe
irrealizzabile demandare l’esecuzione di un servizio VoIP il quale ha necessità di riferirsi
a periferiche locali, come microfono e altoparlante.
Considerando anche le ridotte risorse dei dispositivi mobili, in generale l’esecuzione
demandata dei servizi conviene in applicazioni lascamente o non real-time e tali da
richiedere la trasmissione di piccoli pacchetti dati, come nel caso dell’IM dove i dati
trasmessi sono essenzialmente stringhe.
Un ulteriore scenario è l’aggiornamento di un servizio già presente sul dispositivo
mobile locale. A seguito di un’opportuna ricerca del servizio, se ne rileva una versione più
aggiornata su un dispositivo mobile vicino. A questo punto, si esegue una sostituzione
parziale o totale del componente locale con il componente scaricato (in Figura 3.5
riportiamo l’aggiornamento di un servizio IM).
Figura 3.5 - Scenario 3: Aggiornamento di un servizio già presente in locale
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
60
I tre scenari visti in precedenza e le analoghe considerazioni possono riferirsi anche al
caso in cui l’interazione avvenga tra un dispositivo mobile e una macchina server remota
su cui risiede il servizio richiesto, purché il Framework Core risieda comunque sul
dispositivo mobile.
Passiamo ora alla seconda configurazione, questa volta tipica di una soluzione di
nomadic computing. Tale soluzione prevede, infatti, la presenza di un’infrastruttura fissa
(almeno una macchina server) su cui far risiedere il nostro framework e i sottostanti
servizi. L’accesso ai servizi e la comunicazione tra i dispositivi mobili, continuando a
dipendere dal framework, passeranno ora per il server.
Questa configurazione, che solleva il dispositivo mobile dal carico computazionale legato
al framework e ai servizi, ci permette di superare i limiti tecnologici legati ai dispositivi
mobili odierni, ma richiede di garantire la trasparenza ad un livello diverso rispetto a
quanto già descritto: alle trasparenze garantite dal Framework Core, dobbiamo
aggiungere, sul lato client, la trasparenza alla locazione, ovvero le applicazioni devono
essere utilizzate e sviluppate come se i servizi offerti dal framework risiedessero in locale,
a patto di tollerare un certo aumento dei tempi di risposta di ciascun servizio.
Figura 3.6 - Configurazione 2: Deployment del framework su infrastruttura fissa (nomadic computing)
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
61
Volendo mantenere i servizi sul palmare, un’ulteriore soluzione potrebbe essere effettuare
un linking diretto tra client e servizio (es.: Java RMI). Il vantaggio è che recuperiamo in
prestazioni per il dispositivo mobile, ma perdiamo la trasparenza del linguaggio. Per
recuperarla potremmo implementare i servizi in ciascun linguaggio di programmazione e
per ogni piattaforma per cui vogliamo realizzarne il corrispondente client. Lo sforzo per
questo tipo di soluzione è notevole, inoltre la soluzione stessa si mostra poco lungimirante,
nonché difficilmente manutenibile. Si pensi all’aggiornamento di un servizio da parte
dello sviluppatore: oltre a richiedere più competenze, tale soluzione costringe ad
intervenire su più implementazioni dello stesso servizio in linguaggi diversi. In tal caso
risulta anche difficile mantenere una certa coerenza tra tutte le implementazioni possibili.
3.4 Studio di fattibilità
3.4.1 Introduzione
Riportiamo di seguito il documento relativo allo studio di fattibilità.
Lo scopo di questo documento è riportare e riassumere lo studio effettuato sulle possibili
tecnologie da poter utilizzare per la realizzazione del framework, che deve offrire servizi a
client eterogenei (implementati in qualunque linguaggio tipico per applicazioni mobili) su
piattaforme eterogenee (Windows Mobile, Symbian e Linux).
La piattaforma di riferimento iniziale per i nostri dispositivi mobili è Windows Mobile, in
particolare le versioni 5.0 e 6.0.
Il linguaggio di programmazione usato per la realizzazione dei servizi che compongono il
framework è Java, in modo da garantire la portabilità dei nostri servizi.
In precedenza, abbiamo visto che la soluzione nomadica ci permette di superare i limiti
legati alle risorse hardware a disposizione per i dispositivi mobili attualmente diffusi,
come Smartphones e PDA. Nell’ambito di questo studio, proseguiremo il nostro discorso
supponendo che sia possibile adottare anche una soluzione intermedia, dove il framework
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
62
risulterà distribuito tra i dispositivi mobili e un’infrastruttura fissa e, in particolare, una
parte dei servizi saranno residenti sui dispositivi mobili e i restanti su server remoti. Di
conseguenza, sui dispositivi mobili implementeremo i servizi con J2ME, con J2SE i
restanti. In entrambi i casi, utilizzeremo librerie open-source.
Per implementare i client di test e verificare la trasparenza al linguaggio utilizzeremo il
linguaggio C#.
3.4.2 Confronto tra le possibili scelte tecnologiche
Per una rapida comprensione delle caratteristiche delle tecnologie esaminate e per
mostrarne un confronto di facile lettura, è stata realizzata una griglia (griglia di
fattibilità) su cui sono riportati i risultati dello studio effettuato.
Figura 3.7 - Griglia di fattibilità del framework per le tecnlogie esaminate (Nota - SMCD: Si, ma con difficoltà)
Teniamo una breve panoramica su quelli che sono i vantaggi e gli svantaggi di ciascuna
tecnologia che possiamo adottare per lo sviluppo del framework:
Web Services
I vantaggi dei Web Sevices sono la trasparenza rispetto sia al linguaggio di
programmazione che al sistema operativo, mentre gli svantaggi sono legati alle
performance che sono minori di quelle riscontrabili utilizzando approcci alternativi di
distributed computing quali Java RMI, JINI e wireless CORBA. Il problema di fondo dei
Web Services è legato alle scarse risorse che oggi offrono i dispositivi mobili, come i
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
63
palmari. Esse, infatti, non permettono di installare un server, anche di piccole dimensioni,
a cui i client possano chiedere uno dei servizi facente parte del framework.
Java RMI
I vantaggi di utilizzare Java RMI sono la trasparenza rispetto ai sistemi operativi e la
distribuzione del carico su più dispositivi (RMI è nata proprio per consentire a processi
Java distribuiti di comunicare attraverso una rete, rendendo trasparenti al programmatore
quasi tutti i dettagli della comunicazione su rete), con la possibilità di accedere anche a
servizi locali. Inoltre, le prestazioni sono migliori rispetto a quelle dei Web Services. Gli
svantaggi, invece, sono la non completa trasparenza rispetto ai linguaggi di
programmazione, essendo RMI una tecnologia Java. Il problema è soprattutto per la
piattaforma .NET per cui, a differenza del C++, non esiste alcun porting Java.
JINI
Il vantaggio principale di Jini è da attribuire alle sue caratteristiche di scalabilità, proprie
delle tecnologie orientate ai servizi e nate per ben adattarsi ad ogni dispositivo target.
Ecco i motivi della sua elevata manutenibilità. Tuttavia la comunicazione tra i servizi, in
Jini avviene con la tecnologia Java RMI da cui eredita lo svantaggio di non realizzare una
piena trasparenza al linguaggio.
Wireless CORBA
Wireless CORBA presenta molti vantaggi, tra cui la possibilità di distribuire il carico e la
possibilità di accedere localmente ai servizi con prestazioni migliori rispetto alle altre
tecnologie prese in esame. E’ da tenere comunque presente che le prestazioni si abbassano
notevolmente quando il volume dei dati scambiati aumenta sopra i 1024 byte. Questa
tecnologia va, però, esclusa poiché non è utilizzabile sulla piattaforma di riferimento
Windows Mobile.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
64
Protocollo proprietario basato su XML
Il vantaggio di questa scelta si riduce alla possibilità di creare un protocollo di
comunicazione che soddisfi perfettamente i requisiti fissati dal documento di specifica. In
questo modo avremo un elevato grado di manutenibilità grazie alla completa conoscenza
del protocollo progettato ed implementato da noi stessi. Di contro realizzare un nuovo
protocollo comporta tempi di realizzazione molto lunghi e difficoltà di implementazione,
legate anche al fatto di doversi comunque attenere agli standard XML già definiti. Oltre
ciò, è impossibile prevedere le prestazioni garantite dal protocollo che realizzeremo, senza
contare che gli sviluppi della tecnologia in ambito di dispositivi mobili potrebbe far
risultare inutili i nostri sforzi.
3.4.3 Prospettive di mercato
In ultimo è stata fatta una piccola analisi di mercato per catturare le direzioni di mercato
relative alle tecnologie di distributed computing. In particolare, due delle aziende leader
nel settore, la TIBCO e la BEA Weblogic puntano molto sul modello SOA, architettura
orientata ai servizi, che sembra andare per la maggiore anche per aziende minori. La
chiave di tale architettura, ovviamente, è il “servizio”: l’idea è quella di avere molti
servizi, implementati anche in differenti linguaggi e da persone diverse, a cui accedere in
modo tale da poter riutilizzare anche implementazioni di servizi già esistenti. Poiché il
modello SOA trova nei Web Services la sua maggiore implementazione, entrambe le
aziende indicano, appunto, i Web Services come la soluzione da adottare.
In particolare, la TIBCO offre una suite completa di librerie RIA AJAX enterprise-class
per l’implemetazione di applicazioni Web e in particolare Web Services. Ajax è una
tecnica di sviluppo Web per creare applicazioni Web interattive.
Per quanto riguarda la BEA Weblogic prendiamo da loro sito di riferimento una frase
molto esplicita:
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
65
“La BEA Weblogic offre prodotti e servizi che permettono alle aziende di ottenere più
velocemente un time-to-value per le applicazioni critiche di business, utilizzando standard
aperti, Web Service e una Service-Oriented Architecture (SOA)”.
3.5 Conclusioni
Dall’analisi effettuata e seguendo le scelte tecnologiche di TIBCO e BEA Weblogic, la
nostra scelta riguardo la tecnologia da utilizzare è quella dei Web Services. Grazie alla
trasparenza che offrono per l’accesso, remoto o locale, i Web Services si prestano, per loro
natura, ad adattarsi bene all’evoluzione della tecnologia dei dispositivi mobili. Le
aspettative di mercato prevedono che nel prossimo futuro, in particolare, i palmari avranno
risorse sufficienti per poter ospitare il framework di servizi secondo le configurazioni e gli
scenari illustrati precedentemente.
Adottando la soluzione nomadica per la distribuzione del framework, sembrerebbe così di
aver trovato la soluzione definitiva per la sua implementazione (vedi Appendice A). In
realtà, non tutte le configurazioni mostrate in precedenza possono essere adottate
indistintamente.
Si pensi al servizio di Instant Messaging nella soluzione nomadica: fondamentalmente si
tratta di scambiare, attraverso messaggi SOAP, stringhe di testo tra il client C# (sul
palmare) e il Web Service (su macchina server), che quest’ultimo provvederà a gestire e
inoltrare verso il dispositivo mobile destinatario. Lo scambio dei messaggi SOAP sarà
indipendente dall’hardware dei Web Service consumers coinvolti.
Il problema si pone, invece, per quella tipologia di servizi per cui il flusso di dati
scambiati con un altro host (sia esso un dispositivo mobile o una macchina server)
dipende fortemente dalle caratteristiche hardware del dispositivo mobile stesso. In tal caso
è necessario che il servizio e, quindi, il framework risiedano sul dispositivo mobile,
escludendo la soluzione nomadica. Al più potremmo adottare la soluzione intermedia,
per esempio, con la distribuzione del servizio IM su macchina server e del servizio VoIP
direttamente su dispositivo mobile.
Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili
66
Nel seguente capitolo studieremo una soluzione per implementare un servizio VoIP su
palmare. Nell’applicazione VoIP è intrinseco il suo legame con le caratteristiche hardware
del palmare stesso. Si dovrà gestire uno streaming audio che adotta come source il
microfono di un host e come drain le casse di un altro. Lo streaming audio è possibile
sono in presenza di codec opportuni che possono essere compatibili o meno con il palmare
stesso.
Pensare di elaborare uno streaming audio lato Web Service su una macchina server, che
presenta risorse ben più estese di un palmare, va contro la fattibilità del VoIP stesso:
rischieremo di avere un flusso audio che il palmare non può in nessun modo né elaborare
né riconoscere come tale.
Confidando, quindi, nelle prospettive tecnologiche che il mercato dei dispositivi mobili
promette per l’avvenire, passeremo all’implementazione del servizio VoIP direttamente
sul palmare, proiettandoci verso un Web Service su dispositivo mobile.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
67
4. Analisi di un caso di studio: integrazione del servizio VoIP
In questo capitolo tratteremo, in particolare, lo sviluppo e l’integrazione di uno dei servizi
offerti dal nostro framework: il servizio VoIP. Tale servizio ci pone di fronte ad uno studio
interessante, infatti, come già accennato, il VoIP on mobile mostra diversi limiti
tecnologici, volendo esporre il servizio come un Web Service, ma, allo stesso tempo, ci
proietta verso il futuro delle tecnologie mobile.
4.1 Panoramica sulla tecnologia VoIP
Voice over IP (voce tramite protocollo Internet) [32], acronimo VoIP, è la tecnologia che
rende possibile effettuare una conversazione telefonica sfruttando una connessione ad
Internet o un’altra rete che utilizza il protocollo IP (Internet Protocol), anziché utilizzare
esclusivamente la normale linea di trasmissione telefonica (PSTN), permettendo di
eliminare le centrali di commutazione ed economizzare sulla larghezza di banda occupata.
Le conversazioni VoIP possono usare come mezzo trasmissivo una qualsiasi rete basata
sul protocollo IP come una rete privata locale (LAN) all’interno di un edificio o di un
gruppo di edifici o una rete più ampia (WAN), fino alla grande rete pubblica, Internet.
La telefonia via IP permette una maggiore efficienza nell’uso della rete, grazie all’utilizzo
della commutazione di pacchetto che, a differenza della commutazione di circuito, non
assegna staticamente le risorse disponibili durante l’intera durata di una comunicazione
ma ne consente la condivisione con altri sistemi di comunicazione dati, quali testo e video.
Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
68
in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti
collegati sta parlando.
La tecnologia VoIP permette applicazioni impossibili alle tradizionali reti telefoniche
[33]: ad esempio, si può portare il proprio telefono VoIP ovunque sia disponibile una
connessione Internet e ricevere ed effettuare chiamate come se si fosse a casa propria,
rimanendo raggiungibili allo stesso numero. In parallelo con la conversazione telefonica si
possono scambiare flussi video in tempo reale (videoconferenza), possono essere inviati e
ricevuti messaggi o file e si può partecipare a conferenze audio tra più persone in modo
intuitivo ed a costi molto bassi.
Tra i vantaggi del VoIP rispetto alla telefonia tradizionale va annoverato la diffusione a
larga scala di applicazioni come la videoconferenza e la videotelefonia, supportata non
solo dalla significativa riduzione del costo delle comunicazioni a lunga distanza, ma
soprattutto nei vantaggi operativi e di semplificazione delle infrastrutture.
La tecnologia VoIP ha comunque diversi punti deboli che possono rallentare una sua larga
diffusione. Il problema di fondo della tecnologia VoIP è che la rete Internet è una rete best
effort e non dà quindi nessun tipo di garanzia né in termini di ritardo, di perdita e di ordine
sulla ricezione e la ricostruzione dei pacchetti di dati ricevuti. Risulta quindi necessario
assicurare che il flusso audio mantenga la corretta coerenza temporale [33]. Questi
problemi sono sempre meno rilevanti, grazie a tecnologie che permettono di assegnare una
priorità diversa a certi pacchetti dati, garantendo la qualità del servizio (QoS).
Altre problematiche sono quelle relative all’affidabilità: i telefoni tradizionali senza cavo
di alimentazione (la quasi totalità dei telefoni fissi) sono alimentati dalla linea telefonica, e
in caso di black-out continuano a funzionare grazie a batterie e generatori all’interno delle
centrali telefoniche. I telefoni VoIP (apparecchi, simili ad un tradizionale telefono, che si
collegano direttamente ad un router connesso ad Internet) hanno bisogno della corrente
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
69
elettrica per funzionare e non sarebbero quindi disponibili durante un black-out rendendo
impossibile qualsiasi telefonata.
Inoltre le connessioni Internet a “banda larga” possono essere meno affidabili di una linea
telefonica e, se si presentano dei ritardi nell’invio o nella ricezione dei pacchetti o una
perdita degli stessi, la comunicazione vocale viene momentaneamente interrotta. Questi
fenomeni si presentano in modo più evidente quando applicazioni VoIP utilizzano reti
altamente congestionate o le distanze tra i punti finali sono molto lunghe [37].
A questo va aggiunto che i canali di telecomunicazione hanno un’intrinseca limitatezza in
termini di capacità nel trasportare dati, per cui è necessario adottare delle strategie di
codifica. In quest’ottica gli organismi internazionali preposti alla standardizzazione hanno
sviluppato e approvato protocolli sempre più leggeri ed efficaci, emanando opportune
raccomandazioni e definendo i terminali e le componenti tecniche necessarie per la
comunicazione multimediale su diversi tipi di sottoreti.
In particolare i protocolli al momento più utilizzati sono:
H.324, H.320, H.323 e dell’ITU – T, SIP dell’IETF e 3G-324-M del 3GPP.
Molto spesso queste raccomandazioni sono implementate su sistemi non sempre
compatibili e connessi a reti di diverse tipologie come LAN, xDSL (Digital Subscriber
Line), ISDN (Integrated Services Digital Network), linee telefoniche analogiche e linee
wireless.
Nel trasmettere audio e video su reti eterogenee, ad esempio, la connessione tra sorgente e
destinatario può essere stabilita su collegamenti di rete con diverse caratteristiche e
capacità. In questi casi il bit rate del segnale trasmesso deve essere adattato alla banda del
canale, a cui è collegato l’utente finale.
Se la comunicazione avviene tra sistemi che usano protocolli di segnalazione e codec
diversi, c’è anche la necessità di convertire il flusso di bit originario, codificato secondo le
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
70
regole sintattiche di uno standard, in un nuovo bit stream che sia interpretabile dal
ricevitore.
Per fare ciò occorre utilizzare, oltre ai gateway tradizionali, anche nuove apparecchiature
in grado di collegare la rete dati Internet e la rete telefonica tradizionale. Queste
apparecchiature sono note come Internet Telephony Gateway (o Voice Gateway) e sono
solitamente installate presso gli operatori di telefonia via Internet.
I gateway manipolano le trasmissioni vocali convertendole, dalla rete tradizionale, in
forme idonee alla trasmissione su reti a commutazione di pacchetto. Permettono quindi di
terminare sulla rete tradizionale PSTN telefonate che hanno avuto origine sulla rete IP di
un operatore di telefonia via Internet o, viceversa, di rendere accessibile un utente di
telefonia VoIP dalla rete telefonica tradizionale.
In questo ambito, per esempio, si colloca il gateway VoIP PBX open-source Asterisk.
4.2 Protocolli per il VoIP
La tecnologia VoIP richiede due tipologie di protocolli di comunicazione in parallelo [34].
Il primo è per il trasporto dei dati (pacchetti voce su IP): in tal caso, nella grande
maggioranza delle implementazioni di VoIP, viene adottato il protocollo RTP (Real-time
Transport Protocol).
Il secondo protocollo è destinato al controllo della conversazione, ovvero fornisce
meccanismi per instaurare, modificare e terminare una conversazione. In tal caso si
possono adottare diversi protocolli [32] tra cui:
o SIP (Session Initiation Protocol) della IETF;
o H.323 della ITU;
o Skinny Client Control Protocol, protocollo proprietario della Cisco;
o Megaco (conosciuto anche come H.248) e MGCP;
o MiNET, protocollo proprietario della Mitel;
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
71
o Inter Asterisk Xchange (IAX), soppiantato da IAX2, usato dai server PBX
Asterisk open-source e dai relativi software client.
4.2.1 RTP
Il protocollo RTP (Real-Time Protocol) [35] fornisce le funzionalità di trasporto delle
informazioni, in particolare in H.323.
In particolare, RTP consente il trasferimento in tempo reale punto-punto di informazioni
interattive audio, video e dati su reti unicast o multicast: un tipico scenario di utilizzo è la
videoconferenza.
Le funzioni svolte da questo protocollo comprendono la ricostruzione al ricevitore della
corretta sequenza dei pacchetti e della loro posizione nella scala dei tempi, consentendo
quindi la ricostruzione dei sincronismi.
Questo protocollo non permette, nativamente, di sincronizzare più sessioni multimediali
tra di loro in quanto ogni sessione RTP è in grado di trasportare un solo flusso. Questo non
impedisce, tuttavia, il dialogo tra N soggetti, che è anzi supportato nativamente attraverso
lo sfruttamento di un’eventuale tecnologia multicast sulla rete sottostante. Tuttavia in
presenza di più sessioni distinte (ad esempio audio e video) è necessario attivare più
sessioni RTP, ognuna delle quali è identificata da una coppia di indirizzi di livello
trasporto (indirizzo IP e numero di porto), e nel caso di multicast l’indirizzo di
destinazione è comune a tutti i partecipanti.
Utilizzando due sessioni RTP è possibile fare in modo, ad esempio, che alcuni partecipanti
ricevano sia l’audio che il video, mentre altri ricevano solo uno dei due.
L’header di un pacchetto RTP è composto da una parte fissa e un’estensione, utilizzata
per scopi sperimentali. La parte fissa dell’header si articola su 12 byte e contiene i
seguenti campi [35]:
o V (Version): indica la versione di RTP utilizzata;
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
72
o P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di
riempimento non facenti parte del payload. L’ultimo byte di padding contiene il
valore di quanti byte padding sono presenti;
o X (eXtension): se impostato ad uno, indica la presenza di un’estensione
dell’header;
o CC (CSRC Count): è il numero di CSRC (Contributing SouRCes) presenti dopo la
parte fissa dell’header;
o M (Marker): l’interpretazione di questo bit è legata al profilo;
o PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata
staticamente la corrispondenza tra il codice e il formato del payload;
o Numero di sequenza (Sequence Numbers): è incrementato di uno per ogni
pacchetto inviato; può essere utilizzato dal destinatario per accorgersi della perdita
di pacchetti e per ricostruire l’ordine corretto della sequenza;
o Timestamp: riflette l’istante di campionamento del primo ottetto dei dati. L’istante
di campionamento deve essere derivato da un clock che si incrementa
monotonamente e linearmente nel tempo per permettere i controlli di
sincronizzazione e le misure dell’incertezza sugli arrivi dei pacchetti (arrival
jitter);
o SSRC (Synchronization SouRCe): identifica la stazione trasmittente;
o CSRC (Contributing SouRCe): questo campo è opzionale ed è presente solo se un
elemento della rete ha unito in un unico flusso contributi provenienti da diverse
sorgenti; al suo interno sono elencati gli SSRC delle singole stazioni.
In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un codice univoco,
il SSRC, che permette alla stazione stessa di essere univocamente identificata all’interno
della sessione real-time in esame.
RTCP (Real-Time Control Protocol) [35] monitora l’invio dei dati e controlla e identifica
i servizi. Dunque riconosce automaticamente il tipo di compressione utilizzato sulla linea
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
73
e segnala al mittente e al destinatario eventuali problemi riscontrati sulla rete o sulla
stazione di lavoro (identificandone la fonte), tenendo sotto controllo e fornendo feedback
circa la qualità di ricezione e distribuzione dei dati (es.: numero dei pacchetti ricevuti o
persi sul jitter) .
RTCP (RTP Control Protocol) monitora la qualità del servizio e trasporta le informazioni
riguardo ai partecipanti ad una sessione [36]. RTCP è sufficiente per sessioni loosely
controlled, in cui non c’è un reale controllo dei partecipanti e set-up della sessione, e non
è necessario che tutti i requisiti di controllo siano soddisfatti. Da ciò RTP può essere
coadiuvato da un protocollo apposito per la gestione delle sessioni.
Solitamente le applicazioni pongono l’RTP sopra l’UDP per le operazioni di multiplexing
e checksum, anche se può essere usato con altri protocolli di rete e trasporto sottostanti.
I numeri di sequenza che troviamo nel protocollo RTP permettono all’utente che riceve i
dati di ricostruire la sequenza dei pacchetti del mittente. Le conferenze multicast
multimediali non sono però la sua unica capacità. Ad esempio, trovano posto in questo
protocollo la memorizzazione di un flusso dati continuo, le simulazioni interattive
distribuite, le misurazioni e i controlli.
4.2.2 H.323
Il protocollo H.323 [37] è una raccomandazione ITU – T (International
Telecommunications Union – Telecommunication Standardization Sector) che specifica il
modo in cui il traffico multimediale deve essere trasmesso in reti a commutazione di
pacchetto che non prevedono qualità del servizio (in particolare la rete IP). Questo
standard si occupa delle segnalazioni e del controllo delle chiamate, la trasmissione e il
controllo di informazioni multimediali e il controllo di ampiezza di banda nelle conferenze
in tempo reale punto-punto e multipunto.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
74
Figura 4.1 - Una generica infrastruttura H.323
Gli elementi fondamentali di un sistema H.323 sono [37]:
o i terminali, ovvero dispositivi che si interfacciano con gli utenti (es.: PC o
apparecchi telefonici analogici tradizionali). Offrono funzionalità di controllo del
sistema, formattazione di flussi audio/video che devono essere trasmessi, codifica
audio e video (quest’ultima opzionale), supporto di applicazioni (come ad es.:
conferenze audiografiche);
o i gateway, che traducono i vari formati di trasmissione audio, video e dati
connettendo, di fatto, reti di tipo diverso (come la rete IP, la rete telefonica
tradizionale, la rete ISDN, ecc.);
o il gatekeeper, è il componente centrale dell’infrastruttura H.323, nonostante sia
considerato un elemento opzionale. Tra le funzioni svolte da un gatekeeper
troviamo:
fornire un metodo di autenticazione di terminali e gateway;
gestire la banda e l’accounting (ovvero raccogliere gli elementi per fatturare
i servizi erogati);
o MCU (Multipoint Control Unit), si tratta del sistema che permette di estendere la
comunicazione da punto a punto a punto multi-punto. Gestisce conferenze
multipoint tra tre o più terminali. E’ costituito da un MC (Multipoint Controller),
che assicura un livello minimo di comunicazione e da uno o più processori MP
(Multipoint Processor), per l’audio, il video o i dati.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
75
Figura 4.2 - Stack protocollare nel sistema H.323
I protocolli che fanno parte dello standard H.323 si occupano del supporto
dell’ammissione, l’instaurazione, lo stato, il rilascio, la gestione dei mezzi trasmessivi e i
messaggi di gestione della chiamata.
Essi si dividono in due categorie secondo il protocollo di trasporto sul quale si
appoggiano:
o protocolli che si appoggiano su un canale connesso e quindi sicuro quale TCP
(H.225, Q.931, H.245);
o protocolli che si appoggiano su un canale non connesso e quindi “inaffidabile”
quale UDP (RTP, RTCP, RAS).
Un ulteriore classificazione è basata sull’area di controllo:
o segnali di registrazione, ammissione e stato (RAS): forniscono il controllo pre-
chiamata nelle reti basate su gatekeeper H.323;
o segnali di controllo della chiamata: usati per connettere, mantenere e disconnettere
le chiamate fra i terminali;
o controllo e trasmissione sul mezzo trasmissivo: fornisce il canale affidabile H.245
che trasmette i messaggi di controllo del mezzo trasmissivo. Il trasporto utilizza un
flusso UDP inaffidabile.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
76
Le operazioni più importanti nello standard H.323 sono:
o l’attivazione del canale RAS con la conseguente registrazione presso il
Gatekeeper e l’instaurazione di una chiamata. Il canale RAS è un canale di
comunicazione inaffidabile tra i terminali e il gatekeeper. Viene aperto prima che
venga attivato qualsiasi altro canale, e trasporta i messaggi RAS che svolgono le
procedure di registrazione, ammissione, variazione dell’ampiezza di banda, stato e
disconnessione;
o la ricerca del gatekeeper è un processo manuale o automatico utilizzato dai
terminali per identificare il gatekeeper sul quale si devono registrare. Con il
metodo manuale, i terminali vengono configurati con l’indirizzo IP del gatekeeper,
mentre il metodo automatico richiede un meccanismo di ricerca automatica, che
consente ad un terminale, che non conosce il proprio gatekeeper, di trovarlo
tramite l’invio di un messaggio multicast;
o la registrazione è il processo che consente ai gateway, ai terminali e alle unità
MCU di collegarsi ad una zona e fornire al gatekeeper i propri indirizzi IP e alias.
4.2.3 SIP
Il SIP (Session Initiation Protocol) [37] è un protocollo del livello applicazione che nasce
in ambito IETF come alternativa più semplice al sistema H.323, ed è utilizzato per
attivare, gestire e chiudere le sessioni multimediali.
Esso trova applicazione non solo nella telefonia su IP e nei servizi telefonici
supplementari, ma anche nella video-comunicazione, nei giochi interattivi, nella
messaggistica istantanea.
Il protocollo SIP ha fondamentalmente le seguenti funzioni:
o invitare gli utenti a partecipare ad una sessione;
o localizzare gli utenti;
o acquisire le preferenze degli utenti;
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
77
o determinare la capacità degli utenti, cioè le caratteristiche dell’utente in termini di
risorse audio/video e i parametri da usare;
o trasportare una descrizione della sessione;
o instaurare le connessioni di sessione;
o setup della chiamata, cioè la gestione di eventuali modifiche dei parametri di
sessione;
o rilasciare le parti;
o cancellare la sessione in qualunque momento si desideri.
SIP è un protocollo text-based, orientato al Web, simile ad HTTP, con una struttura client-
server. Questa scelta porta anche ad una facilità di integrazione con Internet: poiché gli
indirizzi utilizzati da SIP sono strutturati in maniera identica a quelli di posta elettronica,
l’integrazione nelle pagine Web è intuitivamente identica.
Per instaurare una sessione, avviene un three-way handshaking (Request, Response, Ack -
concettualmente simile a quello che avviene con il protocollo TCP).
Tra le sue caratteristiche peculiari vi è l’idea di inserire l’intelligenza, ove possibile, ai
bordi della rete, lasciando alla rete il suo compito peculiare di smistamento dei messaggi,
ottenendo qui eccellenti caratteristiche di scalabilità.
La suite SIP definisce componenti piccoli e mono-funzionali, in modo da evitare la
duplicazione di funzioni e far sì che siano modulari, a differenza di quello che succede in
H.323 dove per una funzione elementare sono necessarie iterazioni di più protocolli.
Il protocollo SIP, per questioni di semplicità, non specifica la trasmissione dei dati
audio/video (e dati), demandando questo compito al già collaudato protocollo RTP/RTCP.
Per lo stesso motivo non si preoccupa di riservare la banda per una chiamata.
In particolare, SIP può inviare al terminale chiamato/invitato le informazioni necessarie
per l’allocazione di risorse sulla rete: è fortemente integrato, infatti, con il protocollo SDP
(Session Description Protocol), e con RSVP (Resource reSerVation Protocol) [37] che
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
78
hanno il compito di dare una descrizione dettagliata delle risorse necessarie
all’instaurazione della chiamata e di riservarle.
Il protocollo SIP supporta la mobilità ed è dialog-oriented: un dialogo è una relazione
persistente tra entità paritetiche che si scambiano richieste e risposte in un contesto
comune.
Per quanto riguarda l’indirizzamento, lo standard prevede che ogni utente abbia un
indirizzo SIP: dunque l’indirizzo è proprio dell’utente, non del terminale.
Gli indirizzi (le cosiddette SIP URL) hanno la forma del tipo [email protected],
quindi sono simili a indirizzi e-mail. La parte iniziale dell’indirizzo (nomeutente) è il
nome dell’utente o un numero telefonico, la parte finale (dominio.com), può essere il
nome di dominio oppure un indirizzo di rete.
Grazie a questo meccanismo, SIP supporta anche l’interlavoro con la rete telefonica
classica: un indirizzo nella forma [email protected] può indicare la volontà di
raggiungere l’utente telefonico indicato attraverso un gateway tra mondo IP e mondo
telefonico presso l’università Federico II di Napoli (in questo caso si deve indicare,
attraverso il parametro user=phone, che l’identificativo è un numero telefonico).
Passiamo ad analizzare l’architettura SIP: i componenti fondamentali sono gli User Agent
e i server di rete.
Gli User Agent sono applicazioni operanti sul sistema terminale che includono due
componenti [38]:
o User Agent Client: si occupa delle procedure necessarie a far partire una chiamata;
o User Agent Server: riceve le richieste di chiamate in arrivo e restituisce le risposte
dell’utente chiamato.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
79
Figura 4.3 - User Agent Client (UAC) e User Agent Server (UAS) nello scambio di un messaggio INVITE tra un chiamante e due chiamati
Il Proxy Server [37] è un server intermedio; può rispondere direttamente alle richieste
oppure instradarle ad un client, ad un server o ad un ulteriore proxy. Un proxy server
analizza i parametri di instradamento dei messaggi e “nasconde” la reale posizione del
destinatario del messaggio, essendo quest’ultimo indirizzabile con un nome convenzionale
del dominio di appartenenza. Il vantaggio nel suo utilizzo sta nel fatto che al proxy server
può essere delegata in toto la gestione della chiamata, ragion per cui i terminali utente non
devono preoccuparsi di tutte le procedure di segnalazione nella loro interezza.
Il Redirect Server [37] accetta le richieste SIP e invia al client una risposta di redirezione
contenente l’indirizzo del server successivo. Questo tipo di server non accetta chiamate e
non elabora o inoltra le richieste SIP.
Il Location Server [37] implementa un servizio di risoluzione degli indirizzi: è dunque un
database contenente informazioni sull’utente, come il profilo, l’indirizzo IP, l’URL.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
80
Il Registrar Server [37] è un server dedicato o collocato in un proxy. Quando un utente è
iscritto ad un dominio, invia un messaggio di registrazione del suo attuale punto di
ancoraggio alla rete ad un Registrar Server.
Il Multi Conference Unit [37] è un oggetto in grado di realizzare chiamate tra tre o più
persone, con le stesse caratteristiche dell’analogo componente presente in H.323.
Figura 4.4 - Una generica infrastruttura SIP
Un messaggio SIP [37] è una richiesta (attivata dai client) o una risposta (restituita dai
server); la sequenza di una richiesta e una o più risposte è detta transazione SIP: una
transazione è identificabile da un transaction-ID, un identificativo che ne specifica la
sorgente, la destinazione e il numero di sequenza. E’ possibile trasmettere le transazioni
SIP sia in UDP che in TCP.
Ogni messaggio contiene un’intestazione che descrive i dettagli della comunicazione,
specificando il chiamante, il chiamato, il percorso e il tipo di messaggio contenuto in una
chiamata.
I messaggi SIP per il controllo delle chiamate sono in formato testo, molto simili a quelli
usati da HTTP per lo scambio di pagine Web. I messaggi sono di richiesta e di risposta.
Gli UAC inviano messaggi di richiesta. Questi vengono instradati fino a giungere agli
UAS di destinazione i quali spediranno le risposte.
I messaggi di richiesta SIP sono [38]:
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
81
o REGISTER: messaggio inviato da uno User Agent quando vuole registrare presso
un Registrar Server il proprio punto di ancoraggio alla rete;
o BYE: utilizzato per porre fine ad un dialogo SIP;
o CANCEL: per terminare un dialogo se la sessione non ha ancora avuto inizio;
o INVITE: serve ad invitare un utente a partecipare ad una sessione;
o ACK: è un messaggio di riscontro;
o TRYING e RINGING: messaggi provvisori, mantengono i parametri della
richiesta a cui rispondono;
o SUBSCRIBE e NOTIFY: utilizzati per l’e-Presence.
Le risposte, analogamente a HTTP, sono rappresentate da un codice di stato di tre cifre di
cui la prima identifica la tipologia di risposta:
o (1XX) Provisional: la richiesta è stata ricevuta, ma il server la sta ancora
processando;
o (2XX) Success: la richiesta ha avuto successo;
o (3XX) Redirection: la richiesta deve essere smistata ad un nuovo indirizzo;
o (4XX) Request Failure: la richiesta non è andata a buon fine;
o (5XX) Server Failure: il server non riesce a processare la richiesta;
o (6XX) Global Failure: nessun server può elaborare la richiesta.
Ecco un esempio di messaggio INVITE [37]:
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 134.102.18.1 ‘‘//identifica l’originatore della richiesta ‘‘ From: <sip:[email protected]>; tag = 4711 ‘‘//identifica la destinazione logica di una richiesta’’ To: Domenico <sip:[email protected]> ‘‘//è un valore costante che identifica l’invito’’ Call-Id: [email protected] ‘‘//ordina le transazioni (..la prossima richiesta avrà Cseq=50)’’ Cseq: 49 Invite ‘‘//il body consiste in 117 byte ‘‘ Content-Length: 117 ‘‘//tipo di media descritto secondo il protocollo [[SDP]]’’ Content-Type: application /sdp
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
82
Subject: felicitazioni! ‘‘//l’oggetto del messaggio’’ ‘‘//l’indirizzo al quale si desidera ricevere richieste’’ Contact: sip:[email protected]:4050 ‘‘//specifica il protocollo di trasporto, ‘‘ ‘‘//nell’esempio [[User Datagram Protocol|UDP]]’’ transport = udp v = 0 ‘‘//indica la versione in uso’’ ‘‘//l’owner della risorsa con un ID di sessione’’ o = jack 7564657 9823872 IN IP4 134.102.18.1 ‘‘//tipo di rete, la versione del protocollo IP e l’IP stesso ‘‘ c = IN IP4 134.102.18.1 t = 0 0 ‘‘//tempo di start e di stop’’ ‘‘//tipo di media, num. Di porto, protocollo di trasporto e formato ‘‘ m = audio 4754 RTP/AVP 0 a = rtpmap: 0 PCMU/8000 ‘‘//attributi audio\video.. se ce ne fossero ‘‘ s = festa ‘‘//subject della sessione’’
Ulteriori dettagli sul protocollo SIP possono essere trovati nel documento RFC (Request
For Comments) 2543: se ne trova una sua copia online all’indirizzo
http://www.ietf.org/rfc/rfc2543.txt.
4.2.4 IAX
IAX [37] è un acronimo che sta per Inter Asterisk Xchange. È un protocollo utilizzato da
Asterisk, un server PBX open-source della Digium. Si usa per abilitare connessioni VoIP
tra i server Asterisk e tra server e client che utilizzano lo stesso protocollo.
IAX ora è comunemente indicato come IAX2, la seconda versione del protocollo IAX. Il
protocollo originale IAX è obsoleto ed è disapprovato in funzione di IAX2.
Il progetto del protocollo IAX fu basato su vari standard di controllo e trasmissione tra cui
SIP, Media Gateway Control Protocol (MGCP) e RTP. Il protocollo IAX2 fu creato da
Mark Spencer per Asterisk per la gestione delle chiamate VoIP. Esso è un protocollo
robusto e completo rimanendo al contempo semplice. È indipendente dal codec e dal
numero di flussi, quindi può essere usato in teoria per il trasporto di qualunque tipo di dato
(questa caratteristica diventerà utile quando il videotelefono diventerà comune).
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
83
IAX2 utilizza un singolo flusso dati UDP (di solito sulla porta 4569) per comunicare tra i
due sistemi sia per il controllo che per i dati. Il traffico voce è trasmesso in banda
rendendo più semplice per l’IAX2 l’attraversamento di un firewall ed è più probabile che
lavori dietro una rete con NAT (il protocollo SIP invece utilizza un flusso fuori banda
RTP per il trasporto delle informazioni).
Il protocollo IAX2 supporta il trunking per trasportare su un singolo collegamento dati e
segnali per più canali. Quando è attivo il trunking più chiamate sono unite in un singolo
insieme di pacchetti, quindi un singolo datagramma IP può trasportare informazioni
relative a più chiamate riducendo l’effettivo overhead senza creare ritardi addizionali.
Questo è un vantaggio notevole per gli utilizzatori del VoIP dove le intestazioni IP
occupano una grossa percentuale della larghezza di banda.
4.3 QoS e codec
Le reti IP non dispongono di per sé di alcun meccanismo in grado di garantire che i
pacchetti di dati vengano ricevuti nello stesso ordine in cui vengono trasmessi, né alcuna
garanzia relativa in generale alla qualità di servizio. Le attuali applicazioni nel mondo
reale della telefonia VoIP si trovano a dover affrontare problematiche legate a problemi di
latenza (sostanzialmente si deve ridurre il tempo di transito e di elaborazione dei dati
durante le conversazioni) e di integrità dei dati (prevenire perdite e danneggiamenti delle
informazioni contenute nei pacchetti).
Il problema di fondo della tecnologia VoIP è la corretta ricostruzione dei pacchetti di dati
ricevuti [37] [38], tenuto conto del fatto che durante la trasmissione può cambiare la
sequenza dei pacchetti e che alcuni pacchetti possono aver subito perdite o
danneggiamenti delle informazioni contenute, e assicurare così che il flusso audio
mantenga la corretta coerenza temporale. Altro importante problema è mantenere il
tempo di latenza dei pacchetti sufficientemente basso, in modo che l’utente non debba
aspettare troppo tempo prima di ricevere le risposte durante le conversazione.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
84
Riportiamo di seguito alcuni problemi e le relative possibili soluzioni [34]:
o alcuni router possono essere configurati per distinguere via hardware i pacchetti
VoIP dagli altri, ed assegnare di conseguenza ad essi una priorità maggiore;
o è possibile memorizzare in un buffer i pacchetti, per rendere la trasmissione più
asincrona, ma ciò può tradursi in un aumento del tempo di latenza, simile a quello
delle trasmissioni satellitari;
o il gestore della rete dovrebbe garantire una larghezza di banda sufficientemente
ampia, per ridurre il tempo di latenza e le perdite di dati. Tuttavia ciò, mentre è
relativamente facile nelle reti private, è molto più difficile quando si usa Internet
come mezzo trasmissivo;
o con velocità minori di 256 kbit/s possono aversi problemi di jitter (letteralmente:
nervosismo; tecnicamente: errore nella base dei tempi, quando un campione
digitale è convertito in segnale analogico). Infatti, su reti lente, il ritardo di
trasmissione diventa rilevante, e di conseguenza i protocolli di VoIP utilizzano
pacchetti più piccoli della dimensione massima (generalmente 1500 bytes, secondo
MTU). Altri protocolli basati tipicamente su TCP, usano invece normalmente
pacchetti di dimensione massima. Se un pacchetto di una connessione VoIP arriva
al commutatore mentre è in trasmissione un pacchetto di dimensione massima
appartenente ad un’altra connessione, subirà un ritardo importante, e soprattutto
non costante.
La QoS che si può garantire dipende anche dal codec adottato per la trasmissione.
La funzione del codec (Coder/Decoder) è di convertire i segnali analogici in digitale e
viceversa, affinché il segnale audio sia adatto a viaggiare su reti IP [37] [39].
Quando si vuole implementare un servizio VoIP tale che possa interagire anche con la rete
telefonica tradizionale, è necessario adottare nell’implementazione uno o più codec tale
che permettano di effettuare uno streaming audio compatibili con la linea analogica. In
generale, il discorso si estende quando vogliamo chiamare applicativi che non supportano
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
85
il nostro stesso codec: in altre parole, abbiamo bisogno di effettuare una conversione di
formato audio verso un codec comune ai due interlocutori.
I codec generalmente hanno capacità di compressione per salvare la larghezza di banda.
Il vantaggio di utilizzare un codec molto compresso consiste nel minor numero di
pacchetti da inviare (ad esempio un pacchetto può arrivare a “contenere” 1 secondo di
parlato), accompagnato da un minor consumo di banda. Utilizzando un codec meno
compresso, che quindi occupa più banda, invece avremo una maggiore “qualità della
comunicazione”. Ad esempio, si supponga che un pacchetto possa “contenere” 0.2 secondi
di parlato: nel caso in cui vi siano pacchetti “persi per strada” si riesce comunque a capire
il proprio interlocutore. Alcuni codec addirittura “riconoscono” il silenzio ed effettuano
una soppressione dei pacchetti riconosciuti come tali, evitando di trasmetterli sulla rete.
Menzioniamo di seguito (Tabella 4.1) alcuni dei codec più diffusi nelle applicazioni VoIP
[39]:
CODEC BIT RATE
(Kbps) SAMPLING RATE (KHz)
FRAME SIZE
(ms)
iLBC 8 13.3 30
ITU G.711 (alaw/ulaw) 64 8 campionamento
ITU G.722 64 16 campionamento
ITU G.723.1 5.6/6.3 8 30
ITU G.726 16/24/32/40 8 campionamento
ITU G.728 16 8 2.5
ITU G.729 8 8 10
Speex 8/16/32 2.15-24.6/4-44.2 30/34
Tabella 4.1 – Caratteristiche dei codec comunemente usati nelle applicazioni VoIP
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
86
4.4 Soluzioni per il VoIP
Per realizzare delle soluzioni VoIP è chiaro che risulta necessario avere tanto un server
proxy, che tenga traccia dei VoIP device/utenti registrati e ne smisti le telefonate (PBX),
quanto un “telefono” software (softphone) o hardware (telefono VoIP) a disposizione
dell’utente.
Di seguito riporteremo una breve analisi delle soluzioni attualmente presenti sul mercato.
4.4.1 Asterisk
Asterisk [37] [39] è un software open-source sviluppato dalla Digium (www.digium.com)
in ambiente Linux che permette di realizzare a basso costo una soluzione completa di PBX
VoIP, ossia una vera e propria centralina telefonica per uso privato.
Il suo nome, Asterisk, proviene dal mondo Unix e Dos dove rappresenta un cosiddetto
“carattere jolly” (*), cioè la possibilità di rappresentare ogni file.
In modo simile, Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato
telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica
standard, in modo semplice e consistente. Essendo Asterisk un progetto open-source, esso
è rilasciato sotto licenza GNU GPL ed è possibile per tutti accedere al suo contenuto
liberamente.
Asterisk supporta tre protocolli VoIP: IAX (sviluppato specificatamente per Asterisk
stesso), SIP e H.323.
In particolare, Asterisk è un sistema ibrido, poiché utilizza sia la tradizionale tecnologia
TDM (Time-Division Multiplexing) che i protocolli del packet voice (Voice over IP e
Voice over Frame Relay).
Esso si comporta come un PBX completo, supportando virtualmente tutte le caratteristiche
della chiamata convenzionale.
Allo stesso tempo, è un IVR (Interactive Voice Response), cioè offre un servizio di
risposta automatico con operatore virtuale, completamente programmabile.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
87
Alla base del funzionamento di Asterisk ci sono i dialplan (ovvero “piano di chiamata”):
è la parte più interessante della configurazione di Asterisk, ed anche quella che richiede
più tempo. Nel dialplan si definisce cosa deve fare il PBX quando riceve una chiamata,
oppure quando un utente compone un numero.
Per semplificare la configurazione e la gestione di Asterisk esistono diverse versioni,
anche Live CD, che permettono di caricare in un’unica istallazione il sistema operativo e i
software necessari, compresa un’interfaccia grafica (GUI Web Oriented), come
EasyAsterisk. Inoltre, esistono diversi framework che facilitano l’interazione con Asterisk,
soprattutto dal punto di vista amministrativo.
In tal ambito si colloca Asterisk-Java. Si tratta di un progetto, attualmente alla release 0.3,
orientato allo sviluppo di un framework Java utile per dar vita ad applicazioni in grado di
interagire con Asterisk.
L’interazione avviene grazie al supporto delle interfacce Manager API e FastAGI. In
pratica, Asterisk-Java propone un set di classi Java per sfruttare API in grado di impartire
dei comandi ad Asterisk o di conoscere gli eventi generati dal PBX open-source.
Inoltre è possibile utilizzare un canale di comunicazione TCP/IP per operare il controllo
remoto del centralino software tramite la Asterisk Gateway Interface (AGI), di cui il
progetto offre una implementazione in Java e un tutorial sufficientemente esaustivo.
4.4.2 sipXpbx
Il software sipXpbx è un progetto open-source sviluppato dalla Sipfoundry
(http://www.sipfoundry.org/) con l’appoggio della Pingtel (http://www.pingtel.com/). La
gestione evolutiva del software è affidata ad una comunità attiva.
Il software anche in questo caso implementa le funzionalità di un SIP proxy server. Oltre
alle classiche funzioni legate al SIP server, come l’inoltro delle chiamate e la registrazione
degli utenti SipX, offre delle funzionalità avanzate come Voice-mail, Call Park e IVR.
Tramite un’interfaccia Web è possibile provvedere alla configurazione di tutti i servizi.
Il software è scritto in linguaggio C/C++ ed è composto da tre moduli principali:
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
88
o sipX Communications Server: offre i servizi SIP base, ovvero proxy server,
redirect e register;
o sipX Media Server: offre i servizi avanzati come IVR e Voice mail;
o sipX Configuration Server: permette la configurazione del Media Server.
Inoltre questi tre moduli si appoggiano a delle librerie che sono distribuite separatamente,
in particolare SipXtacklib che implementa le istruzioni base per l’instaurazione e la
gestione delle chiamate. Ad esempio, è possibile partendo da questa libreria implementare
un User Agent Client.
Il server può essere statefull o stateless rispetto alle transizioni, rispetto ai dialoghi solo
stateless.
Il software fornisce delle SOAP API per quanto riguarda la configurazione del
Communication server e del Media Server.
Nel caso della funzione statefull abilitata, esiste un file di log degli stati. Non c’è la
possibilità di inviare questa informazione tramite porta TCP, come avviene per Asterisk.
Per implementare funzioni di questo genere è necessario implementarle utilizzando le
librerie a disposizione.
4.4.3 Jabber/XMPP: Openfire, Spark e Asterisk-IM
Jabber è una piattaforma di messagistica istantanea open-source, basata sul protocollo
XMPP (un’estensione del protocollo XML). Offre numerosi servizi nel campo della
messagistica come: la chat fra due o più persone, la possibilità di conoscere la presenza in
rete di qualcuno (e-presence). Non è un client multi-protocollo, ma molti server Jabber
funzionano come gateways per i servizi di IM. La comunità di Jabber è concentrata nella
costruzione di una vera alternativa agli altri servizi di IM, proponendo agli utenti che lo
utilizzeranno la possibilità di:
o avere un software open-source;
o poter creare una rete Jabber privata (dietro a un firewall) o una rete globale e
pubblica;
o comunicare con client di altre reti, come se questi fossero utenti Jabber.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
89
Un’implementazione open-source del protocollo Jabber è OpenFire Server, molto
semplice da installare e amministrare. Usando il client IM/VoIP Spark, realizzato dalla
stessa comunità di Openfire (http://www.igniterealtime.org/), si possono effettuare
telefonate VOIP PC-to-PC. Anche Spark è un progetto Java open-source, esso provvede
ad impacchettare l’audio in un formato coerente con il protocollo XMPP e inoltrarlo al
server Openfire, il quale smisterà i pacchetti verso la giusta destinazione, garantendo il
real-time.
In seno alla stessa comunità è nato Asterisk-IM (componente di integrazione con Asterisk
per Jive’s Jabber/XMPP server); esso è un modulo lato server che permette di lavorare
con qualsiasi client che usi il protocollo XMPP integrando le funzionalità di e-presence
tipiche dell’Instant Messaging e l’attività PBX di un server Asterisk. In pratica, grazie al
plug-in Asterisk-IM, si associa ad un utente registrato presso il server Jabber un device
VoIP che l’utente IM potrà utilizzare per effettuare le sue chiamate.
4.4.4 MjSIP e altre soluzioni open-source Java
Riportiamo di seguito alcune soluzioni open-source Java per il VoIP. Tutte le soluzioni
sono pensate per macchine desktop. Studieremo la possibilità di adattare almeno una di
queste soluzioni ai dispositivi mobili.
MjSip (http://www.mjsip.org/) è un progetto open-source di un SIP stack, realizzato
completamente in Java dall’Università di Parma e dall’Università “Tor Vergata” di Roma.
Questo progetto include le API complete per creare un’applicazione VoIP, basata su
protocollo SIP e RTP. Comprende anche l’implementazione di diversi codec, tra cui
G.711 e PCMU.
MjSIP include tutte le classi e i metodi per creare applicazioni basate su SIP. Esso
implementa i livelli dell’architettura SIP Stack come definito nella specifica RFC 3261 ed
è totalmente conforme allo standard.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
90
In più, include l’implementazione di un’interfaccia per il controllo delle chiamate e di
User Agent.
MjSIP può essere scaricato dal sito di riferimento e comprende, oltre a quanto già detto, un
proxy server fedele al MjSIP Stack.
MjSIP fornisce anche il servizio di IM. Il progetto al momento sembra sospeso; tra le
specifiche dello stesso, sembrano esserci anche le funzioni tipiche della videochiamata.
Del progetto ne esiste anche una corrispondente versioni J2ME per l’IM.
SIP Communicator (http://www.sip-communicator.org/) è un telefono audio/video via
Internet e un instant messanger scritto in Java, in grado di supportare alcuni dei più
popolari protocolli per IM e per il VoIP come SIP, IAX, Jabber, AIM/ICQ, MSN e altri
come Yahoo e IRC.
Il progetto è in pieno sviluppo. La comunità sembra non aver contemplato l’idea di
un’analoga soluzione per il mobile. La comunità OITOS (http://www.oitos.it/) ha fatto una
valutazione del prodotto secondo la quale SIP Communicator sembra ancora essere
lontano da una soluzione ideale.
Jeti (http://jeti.sourceforge.net/) è un progetto Java nato come client Jabber. Esso supporta
le principali funzionalità di chat tra cui il trasferimento file, group chat, emoticons e la
formattazione dei messaggi. Può essere usato come applicativo o come Web applet.
Per Jeti esistono numerosi plug-in, tra cui Jingle che aggiunge al progetto la funzione di
client VoIP. Attualmente, nella versione beta, è stato rilasciato JetiVoip. Come SIP
Communicator, Jeti include i codec jSpeex, ovvero un’implementazione Java del codec
Speex.
4.4.5 Soluzioni e client VoIP per il Mobile
Riportiamo di seguito una panoramica sulle soluzioni più conosciute per il mobile VoIP.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
91
Skype (http://www.skype.com/) è un protocollo chiuso che realizza la fonia VoIP.
L’omonimo programma, già disponibile da tempo per diversi sistemi operativi, è anche
disponibile per PocketPC (Windows Mobile).
Dietro l’acquisto di un credito, Skype permette di chiamare in oltre trenta paesi del mondo
a tariffe vantaggiose, oltre che parlare gratis tra gli utenti Skype nazionali.
Skype supporta anche l’Instant Messaging, fino ad un gruppo chat di cento persone, e le
videochiamate.
iSkoot (http://www.iskoot.com/) è un software che consente di collegare il proprio
telefono cellulare a Skype in modo da poter chiamare sfruttando la tecnologia VoIP.
iSkoot, disponibile a pagamento solo per Windows Mobile, permette di:
o inoltrare le chiamate dal PC al telefono cellulare;
o chiamare i propri contatti dal telefono cellulare
o “spostare” una chiamata dal PC al telefono senza disconnettersi.
Per realizzare questo è necessario ovviamente lasciare il PC acceso, collegato ad Internet e
avere Skype in esecuzione.
Da quando Palm, azienda specializzata nella produzione di palmari, ha introdo il Wi-Fi
nel proprio mondo, sono nate anche soluzioni VoIP per PalmOS, il sistema operativo
distribuito dalla Palm. La software house MantraGroup, specializzata in soluzioni wireless
per computer palmari, ha realizzato mobiVoIP (http://www.mobivoip.net/), la prima
soluzione VoIP specificamente indirizzata ai palmari e agli smartphone basati su PalmOS.
I requisiti per usare mobiVoIP sono, ovviamente, un dispositivo basato su PalmOS in
grado di connettersi a Internet via Bluetooth, Wi-Fi o EV-DO. Gli utenti di mobiVoIP
potranno chiamare qualunque utente mobiVoIP o un qualsiasi telefono fisso direttamente
dal PDA. La tariffazione è basata su un abbonamento mensile con diversi piani tariffari
pensati per il Nord America e altri paesi, tra cui l’Italia.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
92
Fring (http://www.fring.com/) è l’unica soluzione VoIP-IM per cellulari che non sfrutti
qualche forma di callback per offrire chiamate verso utenti. Fring sfrutta un protocollo
proprietario con cui trasporta la chiamata dal client installato sul cellulare ai server Fring,
da cui poi viene convertita per collegarsi alla rete Skype, Gtalk o PSTN. Fring è
disponibile per Symbian OS e Windows Mobile.
Il servizio Gizmo dedicato al mondo dei dispositivi portatili è Gizmo5
(http://gizmo5.com/), un software Java che integra diversi servizi:
o chiamate VoIP verso chiunque, utilizzando il credito del proprio account Gizmo;
o chat con gli utenti dei servizi Gizmo, MSN, AIM, Yahoo e Jabber, tra cui GTalk;
o verificare la presenza online dei propri contatti;
o inviare e ricevere file, anche tra PC e telefono cellulare.
Molto interessante la possibilità di aggiungere come contatto una URI Sip, per poter
chiamare numerazioni IP gratuitamente dal proprio telefono cellulare.
SJphone (http://www.sjlabs.com/) è uno dei software VoIP più noti ed utilizzati, in
particolare è spesso offerto in combinazione con i servizi dei maggiori operatori VoIP. E’
disponibile per i sistemi PDA dotati di PocketPC 2002/2003/2003SE, Windows CE.NET
4.0/4.2/5.0, Windows Mobile 5.0.
SJphone è compatibile con i due principali standard di segnalazione delle chiamate, SIP e
H.323 e funziona quindi con moltissimi operatori VoIP e sistemi IP-PBX. E’ possibile
configurare diversi “servizi” (solitamente legati alla scelta di un operatore) e passare in
modo semplice da uno all’altro. I codec disponibili per la trasmissione del segnale vocale
sono G.711 A/u, GSM, Speex e iLBC.
Minisip (http://www.minisip.org/) è un framework SIP open-source sviluppato durante
una tesi di laurea in Svezia. Supporta voce, video e IM. E’ cross platform e compila anche
su Linux IPAQ e presto sarà disponibile per Windows Mobile.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
93
Minisip effettua le caratteristiche supplementari di sicurezza quali l’autenticazione, la
crittografia e l’integrità reciproche delle chiamate on-going e la crittografia della
segnalazione (SIP sopra TLS, lo standard IETF di SSL).
Passiamo ora al progetto del nostro componente VoIP da integrare nel framework descritto
nel capitolo precedente.
4.5 Progetto del componente VoIP
Nella fase di analisi e nelle varie fasi della progettazione del componente VoIP ci
serviremo dei diagrammi UML.
4.5.1 Analisi dei requisiti
Nella fase di Analisi dei Requisiti vengono individuati e rappresentati i requisiti del
servizio ed evidenziate le funzionalità del servizio stesso. Il prodotto della fase di analisi è
il seguente Diagramma dei Casi d’uso (Figura 4.5).
Lista degli attori
UtenteGenerico: Rappresenta un utente non ancora registrato, privo di account SIP.
UtenteRegistrato: Rappresenta un utente registrato, avente un account SIP.
Lista dei casi d’uso
Registrazione
Login
EffettuaChiamata
AccettaChiamata
TerminaChiamata
Logout
Cancellazione
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
94
Registrazione
Login
EffettuaChiamata
TerminaChiamata
Logout
UtenteGenerico
UtenteRegistrato
AccettaChiamata
Cancellazione
Figura 4.5 - Diagramma dei Casi d’uso
Riportiamo la descrizione dei casi d’uso presenti nel diagramma. Per facilitarne sia la
descrizione che la comprensione, adotteremo una terminologia SIP compliant,
supponendo di aver adottato il protocollo SIP per il controllo della chiamata.
Caso d’uso Registrazione
Nome: Registrazione
Descrizione: Consente la registrazione di un nuovo utente.
Passi del caso d’uso Registrazione:
1. L’UtenteGenerico fornisce i suoi dati personali (nome, cognome, email) al SIP
server presso cui vuole registrarsi (realm);
2. Il SIP server fornisce all’utente lo username e la password (SipURL =
username@realm);
3. Qualora lo preveda, il server può fornire all’utente registrato un numero geografico
(geoNumber) su cui può essere raggiunto dalla rete telefonica tradizionale.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
95
Estensione del caso d’uso Registrazione:
2. Utente già registrato
2.a Ritorno al punto 1
Caso d’uso Login
Nome: Login
Descrizione: Consente l’autenticazione dell’utente presso in SIP server remoto.
Un utente può avere più account SIP: i dati essenziali di ciascun account SIP sono
username, password, realm. Il metodo Login verifica la validità dei dati.
Passi del caso d’uso Login:
1. L’UtenteRegistrato fornisce i dati relativi al suo account (username, password,
realm);
2. Il SIP server apre una sessione con l’utente autenticato e attiva lo User Agent
(UA);
3. L’utente autenticato può accedere alla lista personale utenti.
Estensione del caso d’uso Login:
2. Dati non corretti
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.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
96
Passi del caso d’uso EffettuaChiamata:
1. L’UtenteRegistrato chiede di effettuare una telefonata;
2. Lo stato della chiamata del chiamante passa nello stato OUTGOING_CALL;
3. L’UA dell’utente chiamato accetta la sessione del chiamante;
4. Lo stato del chiamato diventa INCOMING_CALL.
Estensione del caso d’uso EffettuaChiamata:
2. L’utente chiamato non è connesso/non esiste/è occupato in altra conversazione
2.a Il SIP server restituisce al chiamante un messaggio di CANCEL
3. L’utente chiamato rifiuta/non accetta la chiamata (caso d’uso TerminaChiamata)
3.a Il SIP server inoltra il messaggio di BYE all’UA chiamante
4. L’utente chiamante ha chiuso la chiamata
4.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE
Precondizione per il caso d’uso EffettuaChiamata:
L’UtenteRegistrato deve essere autenticato presso il SIP server remoto.
Lo stato della chiamata deve essere IDLE.
Nei casi di estensione 2-3 si noti che, qualora il SIP server lo preveda, può essere attivato,
a seguito del messaggio di CANCEL, il servizio di segreteria telefonica.
Caso d’uso AccettaChiamata
Nome: AccettaChiamata
Descrizione: Consente all’utente chiamato di accettare una telefonata in arrivo.
Passi del caso d’uso AccettaChiamata:
1. L’utente accetta una telefonata in arrivo;
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
97
2. Lo stato della chiamata, sia del chiamato che del chiamante, diventa ONCALL;
3. I due utenti possono parlare.
Estensione del caso d’uso AccettaChiamata:
2. L’utente chiamante ha chiuso la chiamata
2.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE
Precondizione per il caso d’uso AccettaChiamata:
La chiamata del chiamato deve essere nello stato INCOMING_CALL
Caso d’uso TerminaChiamata
Nome: TerminaChiamata
Descrizione: Consente di terminare una chiamata.
Passi del caso d’uso TerminaChiamata:
1. L’UtenteRegistrato termina la chiamata;
2. La chiamata torna nello stato IDLE.
Precondizione per il caso d’uso TerminaChiamata:
La chiamata deve essere in uno stato diverso da IDLE.
Caso d’uso Logout
Nome: Logout
Descrizione: Consente di disconnettersi dal SIP server remoto.
Passi del caso d’uso Logout:
1. L’UtenteRegistrato chiede di disconnettersi;
2. Viene chiusa un’eventuale chiamata che non sia in stato IDLE;
3. L’UtenteRegistrato risulta disconnesso.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
98
Precondizione per il caso d’uso Logout:
L’UtenteRegistrato deve essere connesso.
Caso d’uso Cancellazione
Nome: Cancellazione
Descrizione: Consente di cancellare un utente registrato dal SIP server.
Passi del caso d’uso Registrazione:
1. L’UtenteRegistrato fornisce il suo username e la password al SIP server (realm)
presso cui è registrato;
2. Il SIP server comunica l’avvenuta cancellazione.
Estensione del caso d’uso Registrazione:
2. Utente non registrato
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.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
99
SIP server
mobile device A mobile device B mobile device C
Framework
Componente VoIP
Framework Framework
Componente VoIP Componente VoIP
VoIP client VoIP clientVoIP client
SIP Server
Figura 4.6 - Diagramma di Distribuzione
Package VoIPComponent
A partire dal diagramma dei casi d’uso, l’interfaccia dei metodi per il nostro componente
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
113
/* dichiarazione delle variabili necessarie per il parsing del file account
[…] […]*/
SipStack.init(file); SipProvider sip_provider; if (file != null) sip_provider = new SipProvider(file); else sip_provider = new SipProvider(opt_via_addr,opt_host_port); if (opt_outbound_proxy != null) sip_provider.setOutboundProxy(new SocketAddress(opt_outbound_proxy)); UserAgentProfile user_profile = new UserAgentProfile(file); /* imposta i parametri sulla base di quelli letti dal file
[…] […] */
VoIPclient = new VoIPComp(sip_provider,user_profile); } /* logout */ public void logout(){ if(ra != null | ua != null){ if (ra.isRegistering()) ra.halt(); ra.unregister(); ua.sip_provider.halt(); } exit(); } /* accetta chiamate in arrivo */ public void accettaChiamata(){ printOut("accetta"); if (ua.statusIs(UserAgent.UA_INCOMING_CALL)){ ua.accept(); } } /* termina una chiamata in corso o rifiuta una chiamata in arrivo */ public void terminaChiamata(){ printOut("termina"); if (!ua.statusIs(UserAgent.UA_IDLE)){ ua.hangup(); ua.listen(); } } /* effettua una nuova chiamata */ public void effettuaChiamata(String target_url){ printOut("effettua"); ua.hangup(); ua.printLog("UAC: CHIAMA " + target_url); if (!ua.user_profile.audio && !ua.user_profile.video) ua.printLog("SOLO SQUILLO, NESSUN AUDIO"); ua.call(target_url);
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
114
} /* UA in ascolto */ void run(){ /* Controlli sulle proprietà di user_profile
[…] […] */
listen();
/* Controllo dello stato della chiamata da parte dello UserAgent […] […] */
}
Per una rapida comprensione degli stati e delle relative transizioni, riportiamo il
Diagramma degli Stati (Figura 4.12) relativi alla classe Chiamata. Per il significato degli
stati, si faccia riferimento alla descrizione dei casi d’uso.
loginChiamata in arrivo
effettuaChiamataaccettaChiamata
Chiamata accettata
logout
terminaChiamata
terminaChiamata
terminaChiamata
IDLE INCOMING CALL
OUTGOING CALL ONCALL
Figura 4.12 - Diagramma degli Stati della classe Chiamata
Come si nota dallo pseudocodice, la classe VoIPComp.java costituisce un wrapper dei
metodi offerti dalla classe UserAgent di MjSIP. La classe implementa UserAgentListener,
RegisterAgentListener, delegati, rispettivamente, di gestire le chiamate e la registrazione
presso un SIP server. Si noti la necessità di registrare periodicamente lo User Agent presso
il SIP server.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
115
Lo User Agent è in ascolto degli eventi, gestiti ciascuno attraverso un metodo opportuno,
la cui implementazione resta opzionale.
Una nota sul metodo di Login: ereditando la filosofia di MjSIP, il metodo riceve in
ingresso il nome di un file di testo contente i parametri relativi all’account utente. Il
metodo login effettua il parsing di questo file.
La classe, così come tutto il progetto, tiene traccia degli eventi in un file di log.
L’obiettivo della progettazione, fin qui seguita, è esporre, attraverso il Framework Core, i
metodi del servizio VoIP per consentirne l’uso da parte delle applicazioni utente. Tuttavia
il componente riportato è utilizzabile solo come applicazione stand-alone, a causa dei
limiti tecnologici dei palmari, che non presentano sufficienti risorse per garantire
l’esecuzione, oltre che del servizio VoIP, di un Servlet Container e di un Web Service
Container, similmente a Tomcat e Axis in una soluzione nomadica. Sebbene le comunità
di sviluppo si stiano dimostrando sensibili alla necessità di portare tali tecnologie sui
dispositivi mobili, il limite tecnologico non è stato ancora superato.
4.6.4 Testing
La fase di Testing del componente VoIP è essenzialmente ridotta alla fase di Unit test (o
test di unità); l’Integration test (o test di integrazione) è lasciato agli sviluppi futuri,
laddove il componente sia integrato nel framework di servizi.
Nella fase di Unit Test verifichiamo la validità dei metodi di cui abbiamo progettato i Test
case; si noti che supponiamo l’implementazione dei metodi registrazione e cancellazione
delegata al componente esterno SIP server (provider).
Per implementare i Test case progettati utilizzeremo JUnit (unit test framework per il
linguaggio di programmazione Java). Di seguito riportiamo, per ogni Test case, una
tabella in cui è indicato il metodo che si sta testando, i dati di input al metodo, l’output
atteso e l’output ottenuto.
Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP
116
TC 1 Metodo testato Input Output atteso Output ottenuto