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

INDICE

INDICE...... I INTRODUZIONE ...... III 1. APPLICAZIONI EMERGENTI IN AMBIENTI MOBILI...... 1

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

2.1 ASPETTI COMUNI DEI MIDDLEWARE...... 14 2.2 DIFFERENZE TRA MIDDLEWARE PER SISTEMI TRADIZIONALI E PER SISTEMI MOBILI ...... 16 2.3 MIDDLEWARE PER SISTEMI MOBILI...... 18 2.3.1 Middleware tradizionali adattati al Mobile Computing...... 18 2.3.2 Middleware creati Ad-Hoc per Mobile Computing...... 21 2.4 WEB SERVICES ...... 26 2.5 SOLUZIONI OFFERTE DALLA JAVA COMMUNITY...... 29 2.5.1 Introduzione alla piattaforma J2ME...... 29 2.5.2 Configuration e Profile ...... 31 2.5.3 Java RMI...... 36 2.5.4 J2ME Web Services: JSR-172 e kSOAP...... 39 2.5.5 Jini...... 43 2.6 SOLUZIONI .NET...... 44 2.6.1 Panoramica su .NET Framework...... 44 2.6.2 .NET Compact Framework ...... 45 2.7 CONCLUSIONI ...... 48 3. FRAMEWORK PER L’INTEGRAZIONE DI SERVIZI IN AMBIENTI MOBILI ...... 50

3.1 OBIETTIVI DEL FRAMEWORK ...... 50 3.2 REQUISITI DEL FRAMEWORK ...... 51 3.2.1 Requisiti funzionali...... 51 3.2.2 Requisiti non funzionali...... 54 3.3 ARCHITETTURA DEL FRAMEWORK ...... 55 3.4 STUDIO DI FATTIBILITÀ ...... 61 3.4.1 Introduzione ...... 61

I Indice

3.4.2 Confronto tra le possibili scelte tecnologiche...... 62 3.4.3 Prospettive di mercato ...... 64 3.5 CONCLUSIONI ...... 65 4. ANALISI DI UN CASO DI STUDIO: INTEGRAZIONE DEL SERVIZIO VOIP...... 67

4.1 PANORAMICA SULLA TECNOLOGIA VOIP...... 67 4.2 PROTOCOLLI PER IL VOIP ...... 70 4.2.1 RTP...... 71 4.2.2 H.323...... 73 4.2.3 SIP...... 76 4.2.4 IAX ...... 82 4.3 QOS E CODEC...... 83 4.4 SOLUZIONI PER IL VOIP ...... 86 4.4.1 Asterisk...... 86 4.4.2 sipXpbx...... 87 4.4.3 Jabber/XMPP: Openfire, Spark e Asterisk-IM...... 88 4.4.4 MjSIP e altre soluzioni open-source Java...... 89 4.4.5 Soluzioni e client VoIP per il Mobile ...... 90 4.5 PROGETTO DEL COMPONENTE VOIP...... 93 4.5.1 Analisi dei requisiti ...... 93 4.5.2 La fase di progettazione ...... 98 4.5.3 Test Case...... 104 4.6 NOTA IMPLEMENTATIVA ...... 109 4.6.1 Mysaifu JVM ...... 109 4.6.2 “MjSIP mobile”: studio di fattibilità ...... 110 4.6.3 Implementazione ...... 112 4.6.4 Testing...... 115 4.6.5 Esempio d’uso ...... 117 4.7 CONCLUSIONI ...... 119 5. CONCLUSIONI E SVILUPPI FUTURI ...... 121 APPENDICE...... 125

A.3.1 SOLUZIONE WEB SERVICE IN AMBIENTE NOMADICO ...... 125 A.3.1.1 Tecnologie Java per i Web Services ...... 125 A.3.1.2 Lato Server...... 127 A.3.1.3 Lato Client ...... 130 A.3.2 SOLUZIONE E SUOI LIMITI...... 132 BIBLIOGRAFIA ...... 136

II Introduzione

Introduzione

Girava qualche anno fa in televisione uno spot pubblicitario: un uomo in metropolitana, durante il tragitto da casa verso il suo ufficio, si collega ad Internet con il suo palmare, controlla l’andamento della borsa, compra-vende azioni, stila un rapporto con un programma di editing, ne richiede la stampa e, arrivato in un ufficio, prende dalla stampante il rapporto cartaceo, poi si siede ed esclama: “Anche oggi ho finito il mio lavoro!”: futuristico allora, oggi verosimile quanto mai.

I sistemi distribuiti e le applicazioni progettate per essi continuano a rimanere importanti nell’ambito della condivisione di risorse e del lavoro d’ufficio, ma i sistemi mobili e i servizi sembrano essere il paradigma che guiderà lo sviluppo delle tecnologie del prossimo futuro.

La crescente diffusione dei dispositivi mobili, dal cellulare al palmare, con prestazioni crescenti, ha spinto, gli utenti, a “pretendere” sempre di più dai loro dispositivi e, le aziende, ad investire per rimanere competitive su un mercato crescente: si è passati così dalla possibilità di effettuare telefonate o inviare SMS su rete GSM, al protocollo Bluetooth per condividere file e scambiare messaggi, e al Wi-Fi per connettersi ad una rete LAN e navigare in Internet. Basti pensare, per esempio, che oggi esistono diverse tipologie di client di messaggistica istantanea e di VoIP (Voice over IP), eseguibili sulla maggior parte dei palmari di diffusione più comune, con i relativi server che offrono tale servizio, tanto a macchine desktop quanto ai suddetti dispositivi mobili.

III Introduzione

L’obiettivo di ogni nuova tecnologia introdotta è estendere la connettività del dispositivo mobile e permettere all’utente di accedere a servizi remoti, oltre che la collaborazione con altri dispositivi mobili (reti Ad-Hoc).

Gli ambienti nomadici, dove una parte dell’infrastruttura è fissa e offre i servizi, e i middleware pensati per tali ambienti sono largamente diffusi. Si pensi ad un’applicazione client residente su palmare che “consuma” un servizio remoto; la necessità di rendere accessibile tale servizio da parte di client mobili di diversa tipologia ha spinto verso lo sviluppo di middleware più flessibili di quelli comunemente usati per i sistemi distribuiti. Lo stato dell’arte attuale dei middleware per dispositivi mobili riconosce sopratutto l’esistenza di middleware per nomadic computing, dove la business logic è demandata all’infrastruttura fissa. Tuttavia la velocità con cui si introducono sul mercato dispositivi mobili sempre più performanti e la diffusione delle reti Wi-Fi, oltre le “piccole” WLAN, ci spinge a pensare che i dispositivi mobili, nonché le reti da essi costituite, possano avere una vita indipendente da qualunque altra infrastruttura, similmente ad una rete Ad-Hoc. In questa direzione spinge soprattutto la necessità di accedere ai servizi in ambienti ostili o in condizioni di emergenza.

Se è molto sentita la necessità dell’utente di accedere velocemente, ovunque e in modo trasparente a una determinata gamma di servizi, allora chi è chiamato a sviluppare applicazioni, anche complesse, per il mobile computing avverte con la stessa forza la convenienza di avere a disposizione gli strumenti adatti per garantire uno sviluppo veloce del prodotto finale tale che risponda, in termini di qualità, alle esigenze di mercato. Questo discorso vale soprattutto considerando che le applicazioni più complesse per il mobile computing richiedono, oltre all’accesso, anche la collaborazione tra i servizi comunemente diffusi per i dispositivi mobili.

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

IV Introduzione

L’obiettivo è progettare un framework di servizi destinato a dispositivi mobili. Esso dovrà rispettare vincoli architetturali legati alle ridotte risorse tipiche dei dispositivi mobili in modo da poter risiedere sugli stessi. Lo stesso framework dovrà permettere ai dispositivi di accedere ai servizi, indipendentemente dalla loro locazione, e garantire una piena collaborazione tra tutti i dispositivi mobili su cui esso stesso risiede. Chiariamo che intendiamo realizzare una collaborazione tra i dispositivi in termini di servizi, infatti la progettazione del framework, oltre a garantire quanto detto, include anche lo sviluppo dei servizi più comuni e distribuiti sui dispositivi mobili odierni; ci riferiamo, per esempio, alla messaggistica istantanea e al VoIP così come al GPS. Sulla base di quanto asserito, il presente lavoro di tesi è organizzato come segue.

Nel primo capitolo daremo una panoramica dei concetti base dei sistemi distribuiti per aprire il discorso circa il mobile computing e le problematiche ad esso relative. Riporteremo una breve descrizione di alcuni scenari applicativi, già esistenti o auspicabili, in cui il framework potrebbe trovare applicazione.

Nel secondo capitolo analizzeremo gli aspetti comuni alle architetture middleware. Terremo una breve panoramica su quelle che sono le soluzioni esistenti di middleware per il mobile computing, adattate e native. Particolare attenzione dedicheremo alle soluzioni proposte dalla Java Community e da Microsoft. L’analisi delle tecnologie per i middleware ci permetterà di scegliere quale soluzione adottare per la progettazione del nostro framework.

Nel terzo capitolo trattiamo la progettazione del framework, introducendo i requisiti definiti dal progetto “WiFi People – CRONOS”, nato da una collaborazione tra il dipartimento di informatica e sistemistica (DIS) dell’Università Federico II di Napoli e l’azienda “WiFi People”. In particolare, definiremo i servizi a cui il framework deve fornire accesso. Mostreremo l’architettura scelta per il framework e i possibili contesti e configurazioni in cui può trovarsi ad operare.

V Introduzione

Nel quarto capitolo effettueremo l’analisi di un caso studio, ovvero di uno dei servizi richiesti dalle specifiche del framework. Precisamente dedicheremo la nostra attenzione al servizio VoIP. Dopo una breve panoramica sui protocolli coinvolti nello sviluppo della tecnologia VoIP, concentreremo la nostra attenzione sulle soluzioni presenti sul mercato come applicazioni stand-alone VoIP per dispositivi mobili e non. Ci concentreremo sulla progettazione del componente VoIP, sulle questioni legate alla distribuzione di un servizio del genere su un dispositivo mobile e, in particolare, nel contesto del nostro framework.

Infine, nel quinto capitolo, terremo alcune brevi considerazioni circa soluzioni alternative, in termini tecnologici, per il framework presentato.

VI Capitolo 1. Applicazioni emergenti in ambienti mobili

1. Applicazioni emergenti in ambienti mobili

Prima di descrivere alcuni scenari applicativi relativi ad ambienti mobili, facciamo una breve panoramica sulle caratteristiche base dei sistemi distribuiti che sono alla base delle diverse tipologie di sistemi mobili.

1.1 Concetti base sui sistemi distribuiti

Intuitivamente un “sistema distribuito” consiste in una collezione di componenti dislocati su vari computer connessi attraverso una rete telematica.

“Un sistema distribuito è un sistema i cui componenti, localizzati in computer connessi in rete, comunicano e coordinano le loro azioni solo attraverso scambio di messaggi” [1]. Da tale definizione emergono ulteriori caratteristiche di un sistema distribuito:

o concorrenza dei componenti; o assenza di un clock globale, ciò comporta che la sincronizzazione e l’interazione tra i nodi sia possibili tramite scambio messaggi;

o possibilità di guasti indipendenti dei componenti: - nei nodi (crash, attacchi, …); - nel sottosistema di scambio messaggi (ritardi, perdita, attacchi,...).

I parametri che caratterizzano un sistema distribuito e la sua progettazione sono i fattori di complessità [1]:

1 Capitolo 1. Applicazioni emergenti in ambienti mobili

o Eterogeneità, legata alla varietà e differenza di reti (tecnologie e protocolli), di sistemi operativi, di hardware (dei server, dei client) e di linguaggi di programmazione. Da qui nasce l’esigenza di usare un middleware nello sviluppo e nella messa in opera di un’applicazione destinata a tali sistemi;

o Apertura (openness) caratterizza il livello di complessità col quale servizi e risorse condivise possono essere resi accessibili a una varietà di clienti, o resi tra essi interoperanti. I sistemi aperti richiedono: - interfacce pubbliche dei componenti; - standard condivisi; - il superamento di adeguati test di conformità.

o Sicurezza (security) analizzata sotto tre aspetti: - confidenzialità (protezione dall’accesso da parte di utenti non autorizzati); - integrità (protezione dall’alterazione o compromissione di dati e risorse); - disponibilità (protezione dall’interferenza con i mezzi di accesso alle risorse).

o Concorrenza, in particolare l’accesso a risorse e servizi condivisi deve essere consentito in maniera virtualmente simultanea a più utenti;

o Trasparenza, legata alle otto forme di trasparenza identificate nell’ISO Reference Model for Open Distributed Processing (RM-ODP);

o Scalabilità: un sistema è scalabile se resta efficace ed efficiente anche a seguito di un aumento considerevole di utenti o risorse. A tal proposito si adottano tecniche di controllo delle prestazioni e dei colli di bottiglia, o tecniche atte a prevenire l’esaurimento delle risorse rispetto alla crescita del sistema;

o Guasti: i guasti nei sistemi distribuiti sono parziali e, come tali, vanno gestiti con tecniche in grado di controllare il livello di servizio offerto. Si tratta di tecniche di individuazione dell’errore (failure detection), masking, tolerance e/o recupero degli stessi (recovery).

2 Capitolo 1. Applicazioni emergenti in ambienti mobili

1.2 Mobile Computing

I sistemi distribuiti tradizionali sono evoluti negli anni verso nuovi sistemi di elaborazione e comunicazione: mobile computing, pervasive computing, ubiquitous computing, nomadic computing, Ad-Hoc computing [2]. Anche se alcune similitudini possono essere individuate, ognuno di essi ha un’identità ben definita se si guarda ai seguenti aspetti [3]:

1. device, si intende un nodo di rete dotato di capacità di elaborazione autonoma; in base alle sue proprietà di mobilità spaziale si può classificare in:

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

o mobile - dispositivi tipicamente poveri di risorse e con problemi di alimentazione che implicano la loro limitata disponibilità nel tempo. Attualmente i dispositivi mobili o portabili sono: - PDA (Personal Digital Assistant), ovvero i palmari; - Smartphone, ovvero un dispositivo portatile che abbina funzionalità di gestione di dati personali e di telefono; - Dispositivi special-purpose (digital camera, barcone reader); - Microcontrollori, sensori e attuatori presenti nei sistemi di controllo.

2. embeddedness, si intende il grado di specificità del compito per cui viene progettato un dispositivo sé il livello di integrazione raggiunto nel costruire il dispositivo che assolve un determinato compito. In base a questo criterio è possibile distinguere tra dispositivi:

o general purpose, un dispositivo progettato per rispondere a compiti non particolarmente specifici (come PDA);

o special purpose, un dispositivo progettato per rispondere a compiti ben specifici (come microcontrollori, sensori, badges).

3 Capitolo 1. Applicazioni emergenti in ambienti mobili

3. connessione di rete, con questo attributo ci riferiremo alla qualità del collegamento tra due o più host di rete; essa può essere:

o permanente, tipicamente una connessione di rete permanente è caratterizzata da un’elevata banda ed un basso rapporto bit su errore (BER – bit error rate);

o intermittente, tipicamente una connessione di rete intermittente è caratterizzata da una modesta banda, spesso variabile, ed un BER influenzato fortemente da agenti esterni.

4. contesto di esecuzione, in letteratura esistono diverse definizioni di contesto. In questo ambito intenderemo per contesto qualsiasi cosa che possa influenzare il comportamento di un’applicazione, come risorse interne al dispositivo (stato della batteria, disponibilità della CPU, disponibilità della memoria, dimensione del display) o esterne ad esso (larghezza di banda, affidabilità e latenza del canale, prossimità degli altri dispositivi). Un contesto può essere:

o statico, se le risorse interne ed esterne variano poco o mai; o dinamico, se le risorse interne ed esterne sono soggette a forti cambiamenti.

I sistemi distribuiti tradizionali sono costituiti da una collezione di dispositivi fissi e general-purpose connessi tra di loro attraverso una connessione permanente le cui applicazioni vivono in un contesto di esecuzione statico. Tali sistemi evolvono verso il mobile computing che presentano caratteristiche di mobilità dei dispositivi.

Il mobile computing è un modello di elaborazione riferito ad un sistema distribuito in cui vi sia mobilità dell’hardware e presenza di tecnologie di comunicazione senza cavo. Per mobilità dell’hardware o sistema mobile si intende un sistema distribuito in cui alcuni nodi attivi dell’elaborazione possono muoversi liberamente nello spazio fisico.

4 Capitolo 1. Applicazioni emergenti in ambienti mobili

In tali contesti si ha il cosiddetto funzionamento “disconnesso” [4], ovvero la comunicazione è garantita in maniera “intermittente” da tecnologie di comunicazione senza filo (wireless).

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

o I sistemi nomatici (nomadic computing) rappresentano un compromesso tra i sistemi totalmente fissi e totalmente mobili. Sono generalmente composti da un insieme di dispositivi mobili general-purpose interconnessi in maniera intermittente ad un’infrastruttura core con nodi fissi general-purpose (collegati tra loro attraverso una connessione permanente). Data la natura del sistema, le applicazioni vivono in un contesto di esecuzione che può essere talvolta statico e talvolta dinamico. I dispositivi mobili di tali sistemi sono interconnessi tra loro e alla rete core attraverso dei dispositivi intermedi, noti come Access Point (AP). Il cambio di AP da parte di un dispositivo mobile è un’operazione nota come

handoff.

o I sistemi Ad-Hoc (mobile Ad-Hoc networks) sono sistemi in cui la rete si costituisce “spontaneamente” e in maniera wireless tra i dispositivi stessi, a causa dell’impossibilità o inutilità di affidarsi ad un’infrastruttura fissa. Tali sistemi sono costituiti da un insieme di dispositivi mobili, tipicamente general-purpose, connessi tra di loro attraverso un collegamento intermittente le cui applicazioni

vivono in un contesto di esecuzione dinamico. I dispositivi devono godere di proprietà di autoconfigurazione (ad esempio, nell’instradamento dei pacchetti), data l’assenza di un’infrastruttura fissa. Un dispositivo di tale sistema può comunicare direttamente solo con i suoi vicini (i nodi presenti nel raggio di comunicazione). Più “salti” (hops) tra nodi potrebbero essere richiesti per attraversare la rete.

5 Capitolo 1. Applicazioni emergenti in ambienti mobili

o Per sistemi Pervasive & Ubiquitous si intende la diffusione di dispositivi informatici intelligenti, facilmente accessibili e talvolta invisibili (integrati nell’ambiente), il cui uso semplifica lo svolgimento dei normali compiti di tutti i giorni. L’utente non ha bisogno di portare dispositivi con sé, in quanto l’informazione potrà essere accessibile dappertutto e in qualsiasi momento. Costituiti da un insieme di dispositivi fissi e mobili, per la maggior parte special- purpose (sensori intelligenti, controllori di elettrodomestici, dispositivi agganciati alle cartelle cliniche,…) connessi tra loro attraverso collegamenti intermittenti, le cui applicazioni vivono in un contesto tipicamente dinamico.

1.3 Problematiche relative ai sistemi mobili

L’evoluzione dei sistemi di elaborazione negli ultimi trent’anni ha visto il passaggio graduale da sistemi di elaborazione monolitici, con grosse capacità di elaborazione, a sistemi costituiti da più unità, o nodi, con capacità elaborative più o meno ridotte. L’evoluzione architetturale è sempre stata legata da una corrispondente evoluzione nelle tecniche di programmazione. A partire dai primi modelli architetturali distribuiti, come il client-server, la necessità del programmatore era quella di poter accedere e usare i servizi in remoto, in modo trasparente, come se stesse usando risorse residenti sulla sua macchina. Al crescere del livello di distribuzione e mobilità corrispondono nuovi paradigmi di programmazione: Distributed Object, prima, Distributed Component Object,

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

Altro aspetto da considerare è il legame esistente, in proporzione inversa, tra il crescente numero dei nodi costituenti un sistema distribuito e le capacità elaborative degli stessi. Infatti, se da una parte la tecnologia ci permette di avere macchine general-purpose con crescenti capacità elaborative, oggi non è difficile trovare sistemi distribuiti costituiti da nodi con ridotte capacità e special-purpose. Basti pensare alle reti spontanee, wireless,

6 Capitolo 1. Applicazioni emergenti in ambienti mobili

costituite da PC e PDA. Un caso estremo è quello di reti molto estese e fitte, capaci di vivere anche in ambienti ostili, come le Wireless Sensor Network [5].

Sotto questi aspetti, le problematiche generalmente caratterizzanti un sistema distribuito sono esaltate quando si affronta lo sviluppo di applicazioni per sistemi mobili. Le applicazioni dovrebbero essere portabili su diverse piattaforme harware/software e funzionare su reti eterogenee. Per garantire tale flessibilità è necessario che le applicazioni progettate per ambienti mobili riescano a tener fronte a caratteristiche di [6]:

o Eterogeneità: i sistemi mobili sono fortemente eterogenei secondo diversi assi: hardware dei dispositivi, software di base e linguaggi di programmazione, tecnologie di comunicazione senza filo.

o Adattamento, le applicazioni devono poter essere semplicemente estese a fronte di cambiamenti nei requisiti funzionali o adattate alle nuove tecnologie emergenti.

o Scalabilità: i sistemi mobili, specialmente i sistemi ubiquitous, sono caratterizzati dalla presenza di un gran numero di dispositivi. Le soluzioni devono essere pensate per introdurre un carico che cresca linearmente al crescere del numero di unità di elaborazione.

o Condivisione di risorse: l’accesso a dati condivisi sensibili richiede la gestione di transazioni e la garanzia dell’accesso in sicurezza.

o Tolleranza ai guasti: l’abilità di recuperare da condizioni di malfunzionamento senza pregiudicare il funzionamento dell’intero sistema. Nei sistemi mobili la problematica è inasprita dalla presenza di collegamenti inaffidabili.

o Gestione delle informazioni di contesto: la dinamicità del contesto richiede spesso alle applicazioni di reagire a variazioni dello stesso.

o Scarse capacità: lo sviluppo deve portare in conto le ridotte capacità elaborative e di memoria dei dispositivi mobili rispetto ai dispositivi fissi. Inoltre, è necessario tenere presente il limitato tempo di vita del dispositivo, dovuto all’alimentazione a batterie.

7 Capitolo 1. Applicazioni emergenti in ambienti mobili

Di fronte ad uno scenario così vasto ed eterogeneo, su più assi (hardware, software, connessione), emerge la chiara necessità di avere a disposizione, nello sviluppo di applicazioni, soluzioni e strumenti che facilitino l’integrazione dei servizi in contesti applicativi, nuovi o già esistenti. Le soluzioni sono molteplici e verranno analizzate nel capitolo successivo.

1.4 Scenari applicativi

I dispositivi mobili, e i relativi servizi, trovano larga diffusione nei contesti più disparati, dall’ufficio ai siti più ostili. Gli scenari applicativi per gli ambienti mobili vanno così moltiplicandosi. Di seguito ne elenchiamo alcuni.

o Domotica (case intelligenti) [7], il termine è un neologismo nato dalla fusione delle parole domus (casa, in latino) e informatica e indica l’insieme delle scienze e delle tecniche mirate alla automazione degli ambienti lavorativi o degli spazi in cui si vive. Basti pensare a quanti oggetti elettronici riempiono le nostre case, senza essere connessi tra loro. Aggiungiamo ai comuni elettrodomestici anche uno o più dispositivi mobili. Lo scenario presenta il limite che ogni oggetto lavora in moto autonomo, ma il passo successivo all’invasione deve essere quello dell’interconnessione. Un esempio banale potrebbe essere il forno elettrico che genera un sms di alert, destinato al nostro palmare, quando ha terminato la cottura. Allo stesso modo potrebbe agire la lavatrice al termine di un lavaggio. Si pensi ora ad un’estensione del classico termostato, ovvero ad un sistema centralizzato che controlli il riscaldamento raccogliendo le temperature misurate da una rete di sensori wireless, distribuiti opportunamente secondo le diverse fonti di calore. Ciò potrebbero consentire un risparmio energetico, nonché garantire una temperatura omogenea in tutto l’ambiente.

8 Capitolo 1. Applicazioni emergenti in ambienti mobili

o Automazione di ufficio, indica comunemente l’insieme del software necessario al lavoro d’ufficio. Negli ambienti mobile posso avere la necessità di accedere da dispositivi mobili a dati residenti su un server oppure ad un servizio di stampa. E’ un caso di interfacciamento con periferiche esterne. Il dispositivo mobile deve essere in grado, da solo o grazie ad un ulteriore servizio di discovery remoto, di individuare la periferica più congeniale al servizio richiesto, oltre che quella più vicina.

o Gestione di situazioni di emergenza (comunicazione in un sito disastrato), il mobile in taluni casi può aiutare le forze di soccorso a tenersi in contatto. Si pensi ad una squadra di soccorso, costretta a dividersi e chiamata ad intervenire in condizioni di scarsa visibilità. E’ indispensabile conoscere la posizione degli altri componenti della squadra. Dotando ciascun membro della squadra di un dispositivo mobile opportuno, si possono coordinare meglio le azioni di soccorso. Il mobile può aiutare anche ad individuare velocemente luoghi e persone da raggiungere qualora siano in possesso di un dispositivo mobile in grado di segnalare la propria presenza.

o Interventi subacquei o sottomarini, si tratta di un caso simile al precedente i cui i membri della squadra non possono né vedersi né comunicare via voce. Oltre alla capacità di individuare i dispositivi mobili della squadra, il dispositivo mobile potrebbe essere dotato di un servizio di messaggistica istantanea che permetta ai sub di scambiarsi delle informazioni. Nel caso in cui si tratti di una squadra di palombari, si potrebbe pensare ad una comunicazione vocale su protocollo IP.

o Gestione e coordinamento del traffico di veicoli, si pensi a località in cui il traffico automobilistico è estremamente variabile. Più che avere un sistema semaforico a tempo prefissato una tantum, potrebbe essere utile adottare una gestione dinamica dei timer del sistema semaforico attraverso una rete di sensori

9 Capitolo 1. Applicazioni emergenti in ambienti mobili

che prendono informazioni, sul traffico in tempo reale, a partire dalle quali, autonomamente, settano i timer dei semafori. E’ necessaria la sincronizzazione dati, oltre che l’accesso ad un database.

o Guide su terminali intelligenti, si pensi ad un museo in cui all’ingresso venga fornito ad ogni gruppo di persone un palmare. Se in tale ambiente è presente un servizio di positioning, è possibile offrire una guida che fornisce documenti audio/video riguardante l’opera di fronte alla quale il turista di volta in volta si ferma. In ambito ospedaliero possiamo avere la stessa applicazione: si pensi al dottore che passa tra i pazienti con un palmare alla mano. Se in ogni stanza è presente un sensore che rivela la presenza del palmare e trasferisce verso di esso le informazioni relative ai ricoverati, memorizzate presso un database centrale, il dottore avrà sempre i dati aggiornati relativi al paziente. In tal caso, è resa più semplice anche la manutenzione e l’aggiornamento delle informazioni di tutti i malati. Il dottore stesso dal suo palmare può modificare le informazioni presenti nel database centrale.

Dagli scenari applicativi emergono diversi servizi in uso su dispositivi mobili. Il dispositivo mobile può essere specifico per un certo compito, ma spesso, su dispositivi general-purpose, si ha la coesistenza, nonché la collaborazione, tra i diversi servizi. Emerge anche la collaborazione tra diversi dispositivi mobili. Teniamo una breve panoramica di alcuni servizi comunemente in uso in ambienti mobili:

o Positioning è un servizio per la localizzazione del dispositivo mobile in un ambiente fisico indoor. Per fornire tale servizio è possibile utilizzare indistintamente la tecnologia Bluetooth oppure la tecnologia Wireless. L’ambiente indoor nel quale si intende localizzare la posizione del dispositivo deve essere opportunamente cablata con Access Point Wireless o Bluetooth.

10 Capitolo 1. Applicazioni emergenti in ambienti mobili

o GPS è un servizio di localizzazione di un dispositivo in un ambiente fisico outdoor attraverso le sue coordinate GPS. Il dispositivo mobile (solitamente un palmare) che usa tale servizio deve necessariamente essere dotato di un dispositivo GPS integrato o deve essere in grado di interfacciarsi con un dispositivo GPS esterno. Esiste uno standard, NMEA che, in generale, permette interfacciamento tra apparecchiature digitali, adottato anche da diversi dispositivi GPS.

o Sincronizzazione dati è un servizio di sincronizzazione di email, contatti ed appuntamenti tra dispositivi. SyncML è il protocollo standard per la sincronizzazione delle informazioni tra dispositivi.

o Accesso DB è un servizio per l’accesso ad un generico database di informazioni, residente o esterno al dominio di connessione del nostro nodo mobile.

o VoIP (Voice over IP) è un servizio di telefonia sul protocollo IP. Il dispositivo mobile diviene un client con la capacità di effettuare e ricevere chiamate attraverso la rete Internet senza ricorrere a tecnologie GPRS/GSM/UMTS. La tecnologia VoIP richiede due tipologie di protocolli di comunicazione in parallelo, il primo riguarda il trasporto dei dati, mentre l’altro protocollo riguarda la codifica della segnalazione della conversazione, per cui sono possibili diversi protocolli alternativi.

o IM (Instant Messaging) è un servizio di messaggistica istantanea e presenza. Il dispositivo mobile diviene un client in grado di scambiare messaggi real-time con altri dispositivi.

o Interfacciamento periferiche esterne (ad esempio, stampanti Bluetooth) è un servizio che intende offrire un’interfaccia standard di comunicazione con periferiche esterne e non integrate nel dispositivo mobile, come ad esempio

11 Capitolo 1. Applicazioni emergenti in ambienti mobili

stampanti Bluetooth e videocamere wireless. Si può pensare di accedere tramite il proprio dispositivo mobile ad un servizio di video-sorveglianza che, per esempio, offre la possibilità di monitorare un’area attraverso una videocamera remota.

o Gestione canale SMS per notifiche ed alert è un servizio che intende offrire la possibilità di inviare messaggi di testo SMS al fine di effettuare delle notifiche e generare degli alert. Per usufruire di tale servizio è necessario che il dispositivo mobile sia dotato di una scheda GSM o di un modem GPRS.

1.5 Conclusioni

In questa ottica si inserisce la necessità di creare soluzioni che facilitino l’integrazione dei servizi già esistenti su terminali fissi con i servizi emergenti del mobile computing. Per le problematiche sopra esposte, progettare e sviluppare per il mondo del mobile computing richiede di portare in conto una serie di requisiti non funzionali. Alcune delle caratteristiche tipiche dei dispositivi mobili possono sembrare sgradite, in realtà sono necessarie. Si pensi alla connessione intermittente che richiede una gestione specifica se vogliamo realizzare, per esempio, un’applicazione che acceda alla rete; in realtà, essa risulta indispensabile al fine di garantire un buon lifetime e preservare le batterie del dispositivo stesso. Inoltre, non è difficile pensare che alcuni servizi si estendano dai terminali fissi a quelli

mobili. Per esempio, non è certo possibile gestire un database con DBMS Oracle facendolo risiedere su un palmare, ma la soluzione può andare in due direzioni: 1. se il database avrà dimensioni contenute, si può ricorrere ad un database più rudimentale e di facile processazione, come un database testuale; 2. se viceversa è necessario garantire vincoli di integrità in modo stretto, o condividere le tabelle con più utenti, o le dimensioni non consentono di risiedere sul palmare, allora sarà necessario far risiedere il database su un server remoto fisso a cui accedere con le proprie query.

12 Capitolo 1. Applicazioni emergenti in ambienti mobili

La soluzione, per rendere facile l’uso e lo sviluppo di applicativi nel mondo mobile richiede la presenza di un framework che offra servizi di trasparenza al programmatore, prima, e all’utente, poi. Esso dovrà rispettare, oltre alle caratteristiche comuni dei middleware per sistemi distribuiti tradizionali, caratteristiche di adattamento ai contesti mobili e capacità ulteriori di dinamicità e recupero dell’errore e di guasti. Inoltre, sarà il framework stesso ad inglobare, gestire e interagire direttamente con i servizi di cui ha bisogno tanto il semplice utilizzatore quanto lo sviluppatore di applicazioni complesse. Precisamente, tramite la parte del framework, che possiamo chiamare Framework Core, potremo accedere ai servizi richiedendone l’esecuzione o la collaborazione con altri servizi. Nel mobile computing nessun dispositivo possiamo dire che appartenga ad un dominio specifico. Si richiede allora al middleware la capacità di rilevare nuovi dispositivi mobili presenti nel suo dominio di appartenenza e tener traccia di essi, nonché un sistema di comunicazione in grado di esporre e di far scambiare dati e servizi presenti nel dominio di cui momentaneamente fanno parte. Ne parleremo approfonditamente nel capitolo successivo.

13 Capitolo 2. Soluzioni Middleware per il mobile computing

2. Soluzioni Middleware per il mobile computing

Esamineremo qui le caratteristiche comuni alle soluzioni middleware nell’ambito dei sistemi distribuiti tradizionali e passeremo poi alle soluzioni relative al mondo del mobile computing, esaminandone differenze e peculiarità.

2.1 Aspetti comuni dei Middleware

Un middleware è uno strato software interposto tra il sistema operativo e le applicazioni (Figura 2.1), in grado di fornire le astrazioni ed i servizi utili per lo sviluppo di applicazioni distribuite. Questo strato software permette di risolvere i problemi di eterogeneità, che nascono dall’utilizzo di diverse macchine hardware, diversi protocolli e infrastrutture di rete, diversi sistemi operativi e diversi linguaggi di programmazione. Il middleware si interpone tra i sistemi operativi e le applicazioni, fornendo un’interfaccia di programmazione di alto livello e nascondendo i servizi del sistema operativo di rete sottostante, in maniera tale che gli sviluppatori di applicazioni abbiamo una vista omogenea dei livelli sottostanti [2], similmente come accade con JVM (Java virtual machine) che, compensando al gap semantico dei diversi linguaggi macchina, cerca di offrire un livello semantico uniforme agli sviluppatori. Lo strato middleware offre ai programmatori di applicazioni distribuite librerie di funzioni, o middleware API (Application Programming Interface), in grado di mascherare i problemi dovuti all’eterogeneità dei sistemi su rete [9].

14 Capitolo 2. Soluzioni Middleware per il mobile computing

Figura 2.1 - Middleware nello stack architetturale

Le middleware API si collocano ai livelli “Sessione” e “Presentazione” dello stack ISO/OSI e semplificano lo sviluppo di applicazioni distribuite sia fornendo un’interfaccia di programmazione di alto livello sia utilizzando (e nascondendo) i servizi del sistema operativo di rete sottostante [2] [9].

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

o trasparenza del sistema operativo; o trasparenza del linguaggio di programmazione; o trasparenza della locazione (location transparency); o trasparenza della migrazione (migration transparency); o trasparenza ai guasti (failure transparency); o trasparenza della replicazione (replication transparency); o trasparenza delle implementazioni commerciali.

15 Capitolo 2. Soluzioni Middleware per il mobile computing

2.2 Differenze tra Middleware per sistemi tradizionali e per sistemi mobili

I middleware per ambienti mobili condividono, almeno nella loro parte core, gli stessi requisiti non funzionali dei sistemi distribuiti tradizionali, anche se alcuni di essi vanno rivisti in ragione delle variate circostanze in cui ci si trova ad operare. La scalabilità del sistema deve essere relativa all’abilità di servire un ampio numero di dispositivi mobili in modo efficiente; l’eterogeneità è complicata dal fatto che sono presenti differenti collegamenti (o link) di rete (wireless/fissi) e che molte tecnologie e dispositivi wireless possono coesistere nello stesso ambito di rete. La gestione dei guasti può dipendere dal tipo di applicazione, ma, in generale, le disconnessioni potrebbero non essere un malfunzionamento o un’eccezione, bensì un requisito funzionale. Per ciò che riguarda i requisiti non funzionali alla base dello sviluppo di middleware per ambienti mobili, essi cambiano rispetto a quelli per ambienti distribuiti tradizionali. In particolare, i punti di divergenza che spingono nella ricerca di nuove soluzioni risultano essere [10]:

o Carico computazionale: il tipo di carico computazionale introdotto dai middleware classici è tipicamente heavy-weight (richiede una grossa quantità di risorse per fornire servizi alle applicazioni soprastanti), contrariamente al carico light-weight richiesto dai middleware per ambienti mobili, data la presenza di dispositivi con capacità limitate.

o Paradigma di comunicazione: i middleware classici assumono, come base per il loro corretto funzionamento, la presenza di connessioni stabili e permanenti tra i nodi di rete e di conseguenza adottano un paradigma di comunicazione di tipo sincrono in cui si richiede accoppiamento temporale tra client e server (ovvero client e server devono essere contemporaneamente presenti durante la loro interazione). Viceversa, negli ambienti in cui i dispositivi mobili possono volontariamente o meno connettersi al sistema e in cui dispongono di scarsa banda, un paradigma di comunicazione sincrono deve inevitabilmente lasciare posto ad un

16 Capitolo 2. Soluzioni Middleware per il mobile computing

paradigma di comunicazione asincrono, in cui non è richiesto che client e server siano connessi simultaneamente.

o Adaptation delle applicazioni: l’adaptation consiste nell’insieme di strategie da applicare per adattare il comportamento delle applicazioni al contesto di esecuzione. Diversamente dai sistemi distribuiti tradizionali, i sistemi distribuiti mobili vivono in un contesto di esecuzione estremamente dinamico: la larghezza di banda potrebbe non essere stabile, i servizi che sono disponibili in un istante possono non esserlo l’istante successivo, per cui un approccio di adattamento context aware, anziché uno application transparent, può essere preferito; con il primo approccio le informazioni sul contesto di esecuzione, o parte di esso, e le decisioni da effettuare a valle dei suoi mutamenti sono carico delle applicazioni. Con il secondo approccio tutte le informazioni circa il contesto sono tenute nascoste all’interno del middleware e rese trasparenti alle applicazioni.

Possiamo, allora, ricapitolare le caratteristiche dei middleware (MW) per sistemi distribuiti tradizionali e per i sistemi mobili:

MIDDLEWARE CARICO COMUNICAZIONE CONTESTO Statico Pesante Sincrona Sistemi Distribuiti (il MW nasconde i (dispositivi fissi (connessione Tradizionali dettagli sul contesto e potenti) permanente) di esecuzione) Dinamico Leggero Asincrona Sistemi Mobile (le applicazioni (dispositivi mobili (connessione Computing prendono decisioni e poco potenti) intermittente) strategiche) Tabella 2.1 – Caratteristiche principali dei middleware per sistemi distribuiti tradizionali e per sistemi mobile computing

Esempi di middleware per sistemi distribuiti tradizionali sono:

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

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

o Message Oriented Middleware – MOM (IBM MQSeries); o Transaction Processing – TP (X/Open DTP) [14].

17 Capitolo 2. Soluzioni Middleware per il mobile computing

2.3 Middleware per sistemi mobili

2.3.1 Middleware tradizionali adattati al Mobile Computing

L’obiettivo è quello di rendere le applicazioni in esecuzione su dispositivi mobili interoperabili con i sistemi fissi esistenti, tipicamente con riferimento ai sistemi nomadici. Generalmente per adattare middleware pensati per sistemi distribuiti classici ad ambienti mobili, si cerca di ridurre il più possibile le “dimensioni” del middleware, in termini di risorse richieste (memoria, calcolo, banda), introdurre il supporto alle disconnessioni e alla gestione degli handoff [10] [15].

2.3.1.1 Wireless CORBA

Un esempio di middleware adattato è wireless CORBA (wCORBA). Esso è l’adattamento della specifica OMG CORBA agli ambienti mobili [16]. Le specifiche OMG wireless CORBA hanno l’intenzione di definire un’evoluzione del middleware CORBA che possa essere utilizzato per lo sviluppo di applicazioni utente in situazioni di nomadic computing. Le specifiche di wCORBA pongono in risalto la soluzione di problemi tipici come la limitazione delle risorse sugli apparati mobili (memoria e potenza computazionale), la natura discontinua dei collegamenti wireless e soprattuto la gestione degli handoff.

Ipotizziamo uno scenario in cui su un terminale mobile è in esecuzione un’applicazione utente CORBA che intende comunicare via ORB con altre applicazioni ubicate su reti fisse o wireless.

18 Capitolo 2. Soluzioni Middleware per il mobile computing

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

Il terminale mobile si interconnette con altri elaboratori tramite una rete wireless e può spostarsi nello spazio attraversando varie zone di copertura del segnale radio. Piuttosto che ad una suddivisione in celle spaziali, nell’architettura wCORBA si pensa ad una suddivisione in vari domini ORB, in analogia ai sistemi di telecomunicazione cellulare:

1. Home domain è il dominio amministrativo di riferimento del dispositivo mobile e ospita l’oggetto di servizio HomeLocationAgent. È qui che viene conservata, e continuamente aggiornata, l’informazione sulla locazione (variabile nel tempo) del terminale mobile che, spostandosi, può visitare differenti altri domini. In genere, lo HomeDomain è costituito dagli ORB ubicati sulla rete fissa;

2. Terminal domain è la parte di infrastruttura residente sul dispositivo mobile. In tale dominio si trova l’oggetto di servizio Terminal Bridge. Tutte le invocazioni CORBA passano per un’unica interfaccia di uscita, appunto il Terminal Bridge, che comunica (via GIOP Tunneling) con la sua controparte fissa, l’Access Bridge, e, quindi, con gli oggetti di altri domini;

3. Visited domain è il dominio correntemente visitato dal terminale mobile. Per dominio visitato si intende quello i cui oggetti vengono utilizzati dal terminale

19 Capitolo 2. Soluzioni Middleware per il mobile computing

mobile. Qui si trova almeno un oggetto di servizio Access Bridge che fornisce agli oggetti sul terminale mobile la possibilità di accedere agli oggetti degli altri domini, inoltrando sulla rete fissa le richieste pervenute dal Terminal Bridge. In genere, anche il Visited Domain è costituito da ORBs ubicati sulla rete fissa.

Il GIOP Tunneling è il modo utilizzato per fornire ad un terminale mobile un canale di comunicazione da e verso la rete fissa. Il tunnel viene usato per trasmettere i messaggi GIOP fra il TerminalBridge e l’AccessBridge sopra la rete wireless. Il Mobile IOR è un particolare Interoperable Object Reference (IOR) capace di nascondere la mobilità di un oggetto servente ubicato sul terminale mobile a quei client che ne invocano le operazioni. Il Mobile IOR fornisce ai client la proprietà di “trasparenza dalla mobilità” in un modo che è esso stesso trasparente all’ORB del client. Di conseguenza, all’ORB del client sulla rete fissa non è richiesto di implementare le specifiche wCORBA affinché sia possibile per quel client invocare operazioni dell’oggetto sul terminale mobile.

2.3.1.2 Alice

Alice (Architecture for Location Independent CORBA Environments) [17] abilita la comunicazione su canali wireless via IIOP (Internet Inter-ORB Protocol) e aggiunge un livello di sessione che prevede la connessione dei terminali mobili a dei Mobility Gateway (proxy per i clienti mobili). L’architettura di Alice permette sia agli oggetti client che agli oggetti server di risiedere su dispositivi mobili senza affidarsi ad un sistema centralizzato di registrazione che tenga traccia dei loro movimenti. Allo stesso modo dell’Access Bridge di wCORBA, per accedere ad una rete IP fissa, su di essa deve essere situato un Mobility Gateway. In questo modo la comunicazione tra i dispositivi mobili e la rete fissa avviene comunque via IIOP in modo del tutto trasparente. L’architettura consiste essenzialmente di tre livelli:

o Il Mobile Layer (ML) è il livello più basso e fornisce il supporto alla mobilità indipendentemente da CORBA e IIOP;

20 Capitolo 2. Soluzioni Middleware per il mobile computing

o Lo IIOP Layer implemeta il protocollo IIOP indipendentemente dalla mobilità; o Lo Swizzling IIOP (S/IIOP) fornisce al livello IIOP il supporto richiesto qualora l’oggetto server risieda su un terminale mobile.

2.3.1.3 Dolmen

Dolmen [18] usa il concetto di bridging per connettere i dispositivi mobili a reti fisse. In particolare, Dolmen implementa due half-bridges, uno residente su un terminale mobile e l’altro su un Access Point noto, uno per ogni dominio mobile presente nella rete fissa. Questo approccio permette l’indirizzamento dei terminali mobili, oltre a rispondere a questioni relative alle performance e all’affidabilità. Dolmen introduce LW-IOP (Light-Weight Inter-ORB Protocol). Si tratta di una versione “leggera” di IIOP. Il protocollo LW-IOP supporta le stesse funzionalità del protocollo GIOP, ma il set di messaggi e la loro rappresentazione risulta essere più efficiente. Le principali caratteristiche del protocollo LW-IOP sono le ridotte dimensioni della struttura e degli headers dei messaggi rispetto a GIOP, oltre che una codifica più compatta, al fine di evitare le trasmissioni continue. Inoltre, LW-IOP effettua:

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

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

2.3.2 Middleware creati Ad-Hoc per Mobile Computing

2.3.2.1 Context-aware middleware

I context-aware middleware si basano sull’idea di fornire alle applicazioni meccanismi di adattamento al contesto di esecuzione fortemente variabile che caratterizza i sistemi mobili [19].

21 Capitolo 2. Soluzioni Middleware per il mobile computing

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

o Locazione: posizione logica (dominio) e fisica (determinata da un sistema di positioning) del dispositivo;

o Prossimità: posizione relativa di altre risorse (stampanti, DB); o Caratteristiche di dispositivo: capacità elaborative, periferiche di input (touch screen, tastiera cellulare);

o Ambiente fisico: livello di luminosità, di rumore, banda di rete; o Attività utente: a guida di un’automobile, su treno, a teatro, ecc.

Alcuni middleware context-aware si basano sul principio, non nuovo, della reflection [2] (“Principio che consente ad un programma di accedere, ripensare e modificare la propria interpretazione” - B. Smith, 1982). Un sistema reflective può modificare sè stesso attraverso un’ispezione, ovvero un esame del comportamento interno, che deve essere esposto all’applicazione, ed un adattamento, ovvero il comportamento interno può essere cambiato aggiungendo nuove caratteristiche o modificando quelle esistenti. Un reflective middleware incorpora solo le funzionalità di base (dimensioni e carico ridotti); sarà l’applicazione che monitora e adatta il comportamento del middleware alle proprie esigenze.

Esempi di context-aware middleware sono OpenORB, OpenCORBA, dynamicTAO che sono middleware tradizionali estesi con il concetto di reflection (reflective middleware).

OpenORB [19] è un reflective middleware sviluppato dalla Lancaster University. L’idea di OpenORB è di estendere alla progettazione del middleware il concetto legato al modello di programmazione a componenti. Nella pratica un’istanza di OpenORB è una particolare configurazione di componenti, selezionati a tempo di progettazione e modificati a runtime. La reflection è usata per fornire l’accesso alla piattaforma sottostante, ovvero la struttura a componenti; ogni componente offre una meta-interfaccia

22 Capitolo 2. Soluzioni Middleware per il mobile computing

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

OpenCORBA [19] permette agli utenti di adattare dinamicamente le politiche di rappresentazione e di esecuzione dell’ORB, visto come un bus software. OpenCORBA fornisce, a tal scopo, le meta-classi e un protocollo che abiliti l’adattamento delle meta- classi a run-time, in modo che sia possibile cambiare le proprietà di una classe. Grazie a questo meccanismo è possibile introdurre una nuova semantica al modello come la sicurezza e la replicazione.

DynamicTAO [19] costituisce un’estensione del middleware TAO, conforme alla specifica CORBA, che fa uso del pattern Strategy per incapsulare differenti aspetti della tecnologia ORB. TAO contiene un file di configurazione sulla base del quale specifica le strategie che l’ORB userà per implementare aspetti come la concorrenza, il demultiplexing, lo scheduling e la gestione della connessione. All’inizializzazione dell’ORB, viene effettuato il parsing di tale file e la strategia selezionata viene caricata. DynamicTAO, quindi, estende TAO con il supporto alla configurazione on-the-fly per permettere all’ORB di cambiare strategia senza la necessità di far ripartire la sua esecuzione. DynamicTAO è un reflective middleware appunto perché permette l’ispezione e la riconfigurazione della strategia adottata.

Altro esempio è Gaia [2] che definisce il concetto di Active Space, dove servizi, utenti, dati e locazioni sono rappresentati e manipolati dinamicamente e in coordinazione. L’idea di tale soluzione è ottenere un sistema in grado di localizzare i dispositivi all’interno di uno spazio fisico, rilevare spontaneamente quando i nuovi dispositivi vi entrano, ed adattare il contenuto e il formato delle informazioni alle risorse del dispositivo.

23 Capitolo 2. Soluzioni Middleware per il mobile computing

2.3.2.2 Data sharing-oriented middleware

I data sharing-oriented middleware [20] offrono il supporto alle disconnected operations, cercando di massimizzare la disponibilità nell’accesso ai dati attraverso il concetto di replica. Le soluzioni esistenti differiscono nel modo in cui viene gestita la consistenza tra le repliche, ovvero nel modo in cui vengono individuati e risolti i conflitti che avvengono naturalmente nei sistemi mobili.

Un esempio è CODA [19] che offre l’astrazione di file system distribuito: i dati sono memorizzati in appositi server distribuiti. Inoltre fornisce la replicazione dei server per la gestione di eventi di guasto dei nodi di rete e il caching per il supporto alle operazioni disconnesse. Si basa sulla presenza di un’infrastruttura fissa dove allocare fisicamente i server.

Un altro è XMiddle [20] che consente ai dispositivi mobili di condividere dati finchè sono connessi, o di replicare i dati ed effettuare operazioni su di essi, mentre sono disconnessi. I dati sono organizzati in strutture ad albero. Gli alberi sono, a loro volta, l’unità base di condivisione e replicazione, infatti i dispositivi mobili possono scambiarsi informazioni condividendo rami di albero. Essi possono replicare un albero o un ramo di albero a seconda delle esigenze e le capacità elaborative. Da ciò viene la peculiarità più importante: non esigono la presenza un’infrastruttura fissa.

2.3.2.3 Tuple space middleware

In ultimo ci sono anche i tuple space middleware (TS) che si basano sul modello dello spazio di tuple. In questo modello le interazioni tra processi sono tipicamente di tipo asincrono. Lo spazio delle tuple può essere considerato uno spazio di memoria associativa (accesso per tipo e contenuto, non per indirizzo) [2].

24 Capitolo 2. Soluzioni Middleware per il mobile computing

La lettura richiede una tupla-modello (pattern), da confrontare con le tuple presenti nello spazio. Il modello è tornato di una certa attualità con la moderna tecnologia JavaSpace, su cui è basata anche la tecnologia Jini.

Un esempio è Lime [2], la versione di Linda per sistemi mobili, uno dei primi sistemi classificabili come middleware. In Linda la comunicazione tra applicazioni ha luogo attraverso l’astrazione di uno spazio virtuale di memoria condiviso; due applicazioni possono sincronizzarsi e scambiarsi dati inserendo/prelevando dati (le tuple) dallo spazio virtuale.

Il modello TS è adatto per realizzare sistemi Service-Oriented Architecture (SOA). Nell’ambito dell’informatica, con la locuzione inglese di Service-Oriented Architecture [21] viene indicata un’architettura software atta a supportare l’uso di servizi Web per soddisfare le richieste degli utenti così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business.

Un’architettura SOA è progettata per il collegamento a richiesta di risorse computazionali (principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti che possono essere utenti finali o altri servizi. L’OASIS (Organization for the Advancement of Structured Information Standards) definisce l’architettura SOA così:

Un paradigma per l’organizzazione e l’utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.

Anche se esistono molteplici definizioni di SOA, solo il gruppo OASIS ha prodotto una definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali.

25 Capitolo 2. Soluzioni Middleware per il mobile computing

I componenti di una piattaforma SOA sono:

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

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

o il catalogo dei servizi (Service Broker), che espone l’interfaccia dei servizi, permettendo, da un lato, la ricerca degli stessi, dall’altro, l’aggiunta dei nuovi.

2.4 Web Services

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

“A Web service is a software system designed to support interoperable machine-to- machine interaction over a network. It has an interface described in a machine- processable format (specifically: WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” [W3C Working Group – February 11, 2004]

Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service (servizio Web) è un sistema software progettato per supportare l’interoperabilità tra

diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è quella di offrire un’interfaccia software (descritta in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language - WSDL) utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le operazioni descritte nell’interfaccia tramite appositi “messaggi” inclusi in un pacchetto SOAP: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML.

26 Capitolo 2. Soluzioni Middleware per il mobile computing

Proprio grazie all’utilizzo di standard basati su XML tramite un’architettura basata sui Web Services, le applicazioni software scritte in diversi linguaggi di programmazione e implementate su diverse piattaforme hardware possono essere utilizzate. L’interoperabilità si realizza tramite le interfacce che queste applicazioni “espongono” pubblicamente e mediante l’utilizzo dei “servizi” che mettono a disposizione per lo scambio di informazioni e l’effettuazione di operazioni complesse (quali, ad esempio, la realizzazione di processi di business che coinvolgono più aree di una medesima azienda) sia su reti aziendali come su Internet: la possibilità dell’interoperabilità fra diversi software (ad esempio, tra Java e Python) e diverse piattaforme hardware (come Windows e Linux) è resa possibile dall’uso di standard open-source.

Il consorzio OASIS ed il W3C sono i principali responsabili dell’architettura e della standardizzazione dei Web Services; per migliorare l’interoperabilità tra le diverse implementazioni dei Web Services, l’organizzazione WS-I sta inoltre sviluppando una serie di “profili” per meglio definire gli standard coinvolti.

I concetti chiave dei Web Services sono:

o Riuso: un Web Service può essere visto come un componente software riusabile, sviluppato da un entità per se stessa o a favore di altre entità;

o Interoperabilità, ottenuta attraverso l’uso esteso di XML; o Componibilità: possono essere facilmente utilizzati, in combinazione l’uno con l’altro (indipendentemente da chi li fornisce e da dove vengono resi disponibili) per formare servizi “integrati” e complessi.

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

o UDDI: fornisce ai client un meccanismo di ricerca dei Web Services. Un registro UDDI è simile ad un “CORBA trader o naming”, o ad un DNS di applicazioni.

o WSDL: definisce i servizi come una collezione di terminali di rete o porte. Ogni porta è descritta da un indirizzo di rete; gli insiemi di porte definiscono i servizi.

27 Capitolo 2. Soluzioni Middleware per il mobile computing

o SOAP: fornisce un sistema standard per costruire messaggi di richiesta e le risposte fornite dai singoli servizi. Sostanzialmente è un sistema per eseguire chiamate RPC su una rete tramite HTTP.

Figura 2.3 - Architettura dei Web Services

Gli svantaggi legati ai Web Services sono i seguenti:

o attualmente non esistono standard consolidati per applicazioni critiche quali, ad esempio, le transazioni distribuite;

o le performance legate all’utilizzo dei Web Services possono essere minori di quelle riscontrabili utilizzando approcci alternativi di distributed computing quali Java RMI, CORBA, o DCOM;

o l’uso dell’HTTP permette ai Web Services di evitare le misure di sicurezza dei firewall (le cui regole sono stabilite spesso proprio per evitare le comunicazioni fra programmi “esterni” ed “interni” al firewall).

Su quest’ultimo punto va fatta una precisazione. Se da un lato i Web Services non consentono un perfetto controllo della sicurezza, dall’altro hanno guadagnato consensi visto che, come protocollo di trasporto, possono utilizzare HTTP over TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l’unica) lasciata “aperta” dai sistemi firewall al traffico di entrata ed uscita dall’esterno verso i sistemi aziendali e ciò in quanto su tale porta transita il traffico HTTP dei Web browser: ciò consente l’utilizzo dei Web Services senza modifiche sulle configurazioni di sicurezza dell’azienda.

28 Capitolo 2. Soluzioni Middleware per il mobile computing

La ragione principale per la creazione e l’utilizzo di Web Services è il “disaccoppiamento” che l’interfaccia standard esposta dal Web Service rende possibile fra il sistema utente ed il Web Service stesso: modifiche ad una o all’altra delle applicazioni possono essere attuate in maniera “trasparente” all’interfaccia tra i due sistemi; tale flessibilità consente la creazione di sistemi software complessi costituiti da componenti svincolati l’uno dall’altro e consente una forte riusabilità di codice ed applicazioni già sviluppate.

2.5 Soluzioni offerte dalla Java Community

Prima di introdurre le soluzioni proposte per il mondo mobile dalla JCP (Java Community Process), è necessario fare una breve panoramica sull’evoluzione del mondo Java, nonché sulla classificazione dei dispositivi mobili che essa adotta. Il JCP promuove e sostiene lo sviluppo delle nuove specifiche Java (Java Specification Request, JSR). I JSR sono i documenti che descrivono le specifiche proposte e le tecnologie da aggiungere alla piattaforma Java, in altre parole di package (API) opzionali per la JVM (Java Virtual Machine) in uso.

2.5.1 Introduzione alla piattaforma J2ME

La prima versione di Java era prevalentemente dedicata alla realizzazione di applicazioni desktop in quanto disponeva solamente delle API per la costruzione di GUI e per la

realizzazione delle Applet. Nella versione 1.02 del JDK, le API Java DataBase Connection (JDBC) per l’accesso ad un DataBase Management System (DBMS) non esistevano ancora [22]. La JVM era caratterizzata da un elevato utilizzo delle risorse del particolare sistema operativo; basti pensare alle Abstract Windows Toolkit (AWT) che permettono di delegare la creazione degli elementi di una interfaccia grafica ai corrispondenti elementi del particolare sistema operativo con conseguenti notevoli limitazioni alla tanto invocata portabilità di Java. Un’applicazione realizzata in Java non doveva solamente poter essere eseguita in JVM che girassero su sistemi operativi diversi,

29 Capitolo 2. Soluzioni Middleware per il mobile computing

ma doveva anche sempre apparire allo stesso modo su macchine e piattaforme diverse e quindi possedere uno stesso Look and Feel (L&F). Con il passare degli anni Java passò da linguaggio per la realizzazione di animazioni sul browser a linguaggio per la creazione di servizi lato server. L’introduzione delle servlet ha rappresentato una pietra miliare in tal senso. Un’applicazione lato server deve possedere caratteristiche molto diverse da quelle di una applicazione lato client: intanto dovrà favorire aspetti legati alla scalabilità ed affidabilità rispetto a quelli legati alla realizzazione di interfacce grafiche, e inoltre dovrà prevedere la definizione di API che permettano l’integrazione con sistemi di altro tipo come DataBase Management System (DBMS), Message Oriented Middelware (MOM) o sistemi legacy. E’ nata quindi l’esigenza di una specializzazione degli ambienti in cui una applicazione Java potesse essere eseguita, che ha portato a una prima classificazione degli ambienti Java, che prevedesse un confine di demarcazione tra quello che era l’ambiente standard per la realizzazione di applicazioni desktop (Java 2 Standard Edition, J2SE) e quello per l’esecuzione di applicazioni server side (Java 2 Enterprise Edition , J2EE). L’obiettivo originario era dunque quello di poter eseguire applicazioni Java in un qualunque sistema, ma non tutte le applicazioni sono uguali: alcune richiedono grosse risorse di CPU, altre grandi quantità di memoria, alcune necessitano di interfacce grafiche sofisticate mentre in altre sono sufficienti poche righe di un display per l’interazione con l’utente. La successiva domanda che ci si pose, soprattutto sulla spinta di un mercato in crescita costante e progressiva, quasi esponenziale come quello dei dispositivi mobili: “Cosa fare nel caso di ambienti con risorse limitate, con dimensioni di memoria e capacità di calcolo ad esempio tipiche di un telefono cellulare o di un Personal Digital Assistant (PDA)? Come possiamo eseguire un’applicazione Java all’interno di un dispositivo con simili caratteristiche, in presenza di nuovi fattori vincolanti come il consumo della batteria o le dimensioni del display?” [22]. Una soluzione consiste nell’eliminare il superfluo. Se volessimo eseguire un’applicazione Java all’interno di un cellulare non avremmo sicuramente bisogno delle API per le Swing

30 Capitolo 2. Soluzioni Middleware per il mobile computing

in quanto le capacità grafiche non ne consentirebbero l’utilizzo, come non potremmo sfruttare tutte le operazioni caratteristiche delle JVM utilizzate per applicazioni J2SE, dal momento che i sistemi operativi semplificati dei dispositivi mobili non sarebbero in grado di eseguirli, al di là del fatto che molte di tali applicazioni non avrebbero addirittura senso in un dispositivo di quelle dimensioni. Nasce quindi l’esigenza di un nuovo ambiente per le Midlets, le applicazioni Java pensate Ad-Hoc per dispositivi mobili con capacità notevolmente ridotte rispetto ai desktop o ai server: tale nuova piattaforma prende il nome di Java 2 Micro Edition (J2ME).

2.5.2 Configuration e Profile

J2ME [22] [23] descrive un insieme di ambienti per la creazione e l’esecuzione di applicazioni Java in dispositivi di largo consumo. Si tratta di dispositivi spesso molto diversi tra loro tra cui telefoni cellulari, Personal Digital Assistant (PDA), WebTV ed altri ancora. Definire un ambiente J2ME significa definire:

o un insieme di JVM, ciascusa delle quali può essere utilizzata all’interno di dispositivi con caratteristiche e limitazioni diverse;

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

o un insieme di strumenti per lo sviluppo ed il deploy delle applicazioni. Dato l’elevato numero di dispositivi presenti sul mercato, con caratteristiche molto diverse tra loro, si è sentita la necessità di definire alcuni concetti sulla base dei quali classificare i

dispositivi non più relativamente al loro utilizzo, ma in base alle loro limitazioni in termini soprattutto di memoria e CPU. Sono quindi stati introdotti i concetti fondamentali di Configuration e di Profile [23].

31 Capitolo 2. Soluzioni Middleware per il mobile computing

Figura 2.4 - Configuration e Profile nello stack architetturale J2ME

Notiamo come ciascun dispositivo sia caratterizzato da un proprio sistema operativo che ne implementa le funzionalità di basso livello. L’implementazione della JVM prevista per il dispositivo dovrà quindi essere costruita ad un livello immediatamente superiore, strettamente connesso alle funzioni esposte dal sistema operativo. La maggior parte delle funzionalità delle JVM di questo tipo si ottengono dalla JVM classica della J2SE eliminando le operazioni superflue o troppo onerose in termini di risorse. Queste risorse riguardano principalmente la quantità di memoria disponibile (RAM e ROM) e la potenza della CPU. Notiamo come queste siano caratteristiche che coinvolgono tutti i dispositivi, indipendentemente dalla loro funzione. Possiamo dire che si tratta di grandezze che permettono di classificare in modo orizzontale un certo insieme di dispositivi, a prescindere da quelle che sono le caratteristiche peculiari o il target specifico di una determinata categoria di dispositivo.

Una Configuration è la descrizione di un Java Runtime completo per una determinata categoria di dispositivi con caratteristiche hardware simili. Essa si può considerare composta dalle seguenti tre parti:

o una JVM in grado di eseguire del bytecode; o l’implementazione nativa di alcune interfacce per l’interazione con il sistema operativo su cui la JVM è in esecuzione;

o un insieme di classi core (API) standard.

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

o Connected Device Configuration (CDC);

32 Capitolo 2. Soluzioni Middleware per il mobile computing

o Connected Limited Device Configuration (CLDC) .

Le specifiche attualmente disponibili sono relative alle versioni CLDC 1.1 (JSR-139) e CDC 1.1 (JSR-218). Si noti che la principale differenza tra le versioni CDLC 1.0 e CDLC 1.1 è il supporto al floating point.

La CDC riguarda dispositivi che hanno disponibilità di una implementazione completa della JVM, come definito nel documento JVM Specification 2nd Edition, e possibile presenza di una interfaccia grafica per l’interazione con l’utente. A questa categoria appartengono dispositivi quali telefoni abilitati al Web, sistemi di navigazione, WebTV e molti altri ancora. Notiamo come una delle caratteristiche fondamentali di questa Configuration sia quella relativa alla possibilità di poter supportare una implementazione della JVM uguale a quella prevista per la J2SE e precisamente alla versione 1.3.1. Sebbene tutte le API della J2SE possano essere gestite dalla JVM di questa Configuration, solamente alcune saranno disponibili per ciascuna implementazione.

La CLDC si riferisce, invece, a dispositivi caratterizzati da scarse risorse elaborative e di massa, da connettività limitata, spesso intermittente, e da interfaccia grafica ristretta o addirittura assente.

A questa categoria appartengono dispositivi quali PDA, telefoni cellulari, palmari e molti altri. Questa Configuration descrive lo strumento base per la scrittura delle Midlets. A differenza della CDC, la CLDC non può disporre di una JVM completa, per cui si renderà necessario l’utilizzo di una JVM più semplice, che è stata individuata nella KVM (Kilo Virtual Machine). E’ importante sottolineare come la CLDC sia un sottoinsieme della CDC. Questo ha come conseguenza il fatto che una applicazione sviluppata per la CLDC dovrà necessariamente funzionare anche sulla CDC. Le relazioni tra la J2SE, la CDC e CLDC [23] è espressa molto bene dalla seguente Figura 2.5:

33 Capitolo 2. Soluzioni Middleware per il mobile computing

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

Notiamo come la CDC si possa considerare una estensione di un sottoinsieme della J2SE, dal momento che include alcune nuove classi Ad-Hoc per dispositivi con risorse limitate non presenti nella J2SE, e come la CLDC si possa considerare invece un sottoinsieme in senso stretto della CDC.

L’insieme di API, costruite a partire da un minimo comune denominatore quale può essere una stessa Configuration, che permettono di sfruttare le particolari caratteristiche di uno specifico dispositivo, definiscono quello che si chiama Profile. Quello di Profile è un concetto fondamentale in quanto, a livello di implementazione, rappresenta un insieme di API e di librerie di classi, costruite sopra una determinata Configuration, che permettono di accedere alle funzionalità caratteristiche di una determinata tipologia di dispositivi. Normalmente il concetto di Profile risulta strettamente legato a uno specifico segmento di mercato “verticale”, ma è possibile parlare di Profile anche per importanti gruppi di applicazioni di un determinato settore che possono girare su dispositivi di tipo diverso: tutte le applicazioni per dispositivi mobili devono essere scritte per un determinato Profile, e non per un particolare dispositivo o per una configurazione. Il Profile si può considerare il contratto tra un’applicazione e un segmento di mercato verticale.

34 Capitolo 2. Soluzioni Middleware per il mobile computing

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

Senza addentrarci nei particolari diremo che i Profile attualmente definiti per configurazione CDC [23] sono i seguenti:

Foundation Profile (JSR-219) definisce il profilo “di base” che: • fornisce un set di classi minimale (supporto di rete ed I/O); • non include il supporto per alla grafica o ad altri tipi di GUI.

Personal Basis Profile (JSR-217) definisce il profilo per lo sviluppo di applicazioni “leggere”. Esso: • estende il set di classi fornito con il Foundation Profile; • include il supporto limitato, ovvero non completo, per AWT; • fornisce supporto a runtime per JavaBeans ed Xlets.

Personal Profile (JSR-216) definisce il profilo per lo sviluppo di applicazioni “complete”. Tale profilo: • estende il set di classi fornito con il Personale Profile; • include il supporto completo per AWT; • costituisce il punto di migrazione per le tecnologie Java legaci, come IBM PersonalJava.

35 Capitolo 2. Soluzioni Middleware per il mobile computing

L’unico profilo definito per la configurazione CLDC è Mobile Information Device Platform (MIDP, JSR-118). MIDP, in combinazione con CLDC, costituisce l’ambiente di runtime per le applicazioni Java, su dispositivi come PDA e telefoni cellulari. MIDP provvede alle funzionalità di base necessarie alle applicazioni mobili quali: l’interfaccia utente, la connessione di rete, la gestione dei dati sul sistema locale e la gestione del ciclo di vita del programma.

2.5.3 Java RMI

RMI (Remot Method Invocation) [12] [24] è un’insieme di API potente, ma semplice, che permette di sviluppare applicazioni distribuite in rete, dove le risorse sono allocate su macchine diverse e quindi con spazio di indirizzamento diverso fra loro. I vantaggi dell’uso di RMI sono:

o Maggiore astrazione: con RMI si ottiene in locale una rappresentazione dell’oggetto remoto (che quindi si trova su una JVM remota) e lo si tratta a tutti gli effetti come se si trattasse di un elemento locale. E’ RMI che gestisce tale trasferimento occupandosi della gestione della comunicazione fino al “basso livello” (socket). Questa astrazione permette di concentrarsi sull’applicazione e non sui dettagli di comunicazione.

o Maggiore eleganza: una volta ottenuta la rappresentazione dell’oggetto remoto (detto stub) sulla propria macchina, il codice necessario ad invocare un metodo remoto è identico a quello utilizzato per un oggetto locale: nome_oggetto_remoto.nome_metodo(lista_dei_parametri); Da un punto di vista sintattico non vi è alcuna differenza fra un oggetto locale ed uno remoto.

36 Capitolo 2. Soluzioni Middleware per il mobile computing

o Non necessita di un protocollo di definizione dei messaggi: la gestione della comunicazione tra applicativo locale e remoto è completamente gestita da RMI senza la necessità di doversi implementare un protocollo proprietario per tale gestione.

o Utilizzo del paradigma ad oggetti.

Prima dell’introduzione di RMI erano già disponibili soluzioni al problema dell’esecuzione di parti di codice in remoto, come ad esempio la Remote Procedure Call (RPC): con questa tecnologia è possibile gestire procedure facenti parte di applicazioni residenti in remoto rispetto al chiamante. Le RPC sono strettamente legate al concetto di processo e di procedura e quindi male si inseriscono nel contesto del paradigma ad oggetti. E’ questo il motivo principale che ha fatto nascere l’esigenza di una tecnologia apposita per la gestione di oggetti ditribuiti, la quale vede in RMI la soluzione full-Java completamente Object Oriented.

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

o uno o più server RMI; o il Java RMI Registry (localizzato sul server); o uno o più client RMI.

Il server RMI implementa un’interfaccia relativa ad un particolare oggetto RMI e registra tale oggetto nel Java RMI Registry. Il Java RMI Registry è, semplicemente, un processo di tipo daemon che tiene traccia di tutti gli oggetti remoti disponibili su un dato server. Il client RMI effettua una serie di chiamate al registry RMI per ricercare gli oggetti remoti con cui interagire. Le modalità con cui un oggetto che si trova su una macchina client riesce ad invocare dei metodi che sono definiti su un’altra macchina (server) e la gestione delle problematiche

37 Capitolo 2. Soluzioni Middleware per il mobile computing

legate alla comunicazione di rete dipendono da due componenti che nel diagramma precedente sono denominati Skeleton e Stub.

Figura 2.7 - Meccanismo di funzionamento della tecnologia Java RMI

Dettagliamo il meccanismo utilizzando la medesima numerazione riportata in Figura 2.7: 1. Viene creata sul server una istanza dell’oggetto remoto e passata in forma di stub al Java RMI registry. Tale stub viene, quindi registrato all’interno del registry stesso; 2. L’applicazione client richiede al registry RMI una copia dell’oggetto remoto da utilizzare; 3. Il Java RMI registry restituisce una copia serializzata dello stub al client; 4. L’applicazione client invoca uno dei metodi dell’oggetto remoto utilizzando la classe “clone” fornita dallo stub; 5. Lo stub richiama lo skeleton che si trova sul server chiedendogli di invocare sull’oggetto remoto lo stesso metodo che il client ha invocato sullo stub; 6. Lo skeleton invoca il metodo richiesto sull’oggetto remoto; 7. L’invocazione del metodo sull’oggetto remoto restituisce il risultato allo skeleton; 8. Lo skeleton comunica il risultato allo stub sul client; 9. Lo stub fornisce il risultato all’applicazione client iniziale.

38 Capitolo 2. Soluzioni Middleware per il mobile computing

La scelta di utilizzare RMI è consigliabile nel caso in cui si debba implementare una struttura a oggetti distribuiti full-Java, in maniera semplice e veloce. L’alta semplicità di RMI si paga a volte nei confronti delle tecnologie concorrenti più sofisticate (e complicate) che offrono maggiore potenzialità e scalabilità.

Java RMI è una tecnologia nata per ambienti desktop (J2SE) ed estesa, come package opzionale (OP), al mondo mobile (J2ME) e destinata, come descritto dal documento di specifica JSR-66, a “sistemi ancor più differenti”, non solo desktop e server, ma anche piccoli dispositivi mobili, come palmari e PDA. RMI OP è un sottoinsieme di J2SE RMI che può essere usato sui dispositivi che supportano la configurazione CDC.

2.5.4 J2ME Web Services: JSR-172 e kSOAP

Vediamo ora il rapporto tra un Web Service ed una applicazione in esecuzione in un ambiente J2ME. Sebbene tutto sia possibile, è abbastanza difficile che il ruolo di una applicazione J2ME sia quello di server. In effetti, la piattaforma J2ME nasce per realizzare ed eseguire piccole applicazioni stand-alone. Inoltre, nel caso della configurazione CDLC, non è possibile realizzare applicazioni thread, poiché la piattaforma non riconosce tale paradigma. Per questo motivo è iniziata la standardizzazione di quelli che sono gli strumenti che un sistema client J2ME può

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

Le API (WSA, J2ME Web Services API) descritte in queste specifiche sono un sottoinsieme di quelle definite nell’ambiente J2SE, come nel caso di altre API [26]. Si tratta di specifiche, basate sul WS-I Basic Profile 1.0, che hanno lo scopo di standardizzare quelle che sono le principali caratteristiche di un client per Web Service, ovvero le invocazione di funzioni remote e il parsing XML.

39 Capitolo 2. Soluzioni Middleware per il mobile computing

L’utilizzo di un dispositivo cellulare o PDA come server di un servizio Web non sarebbe, almeno con le potenzialità dei sistemi attuali e la limitata connettività, una scelta che trova attualmente molti riscontri. Le WSA sono quindi pensate per poter essere eseguite sia per configurazioni CDC che CDLC. Come accaduto per altre API per l’ambiente J2ME, esse sono state ottenute attraverso una selezione di quelle che sono le API analoghe disponibili per J2SE.

Le JSR-172 permettono di dotare un dispositivo J2ME delle funzionalità caratteristiche di un client, ma non di tutte le funzionalità tipiche di un client J2SE: la ricerca di servizi attraverso la tecnologia UDDI non è una funzionalità prevista da un client che utilizzi le WSA. Un client potrebbe, inoltre, non solo accedere ad un servizio, ma anche eseguire operazioni di deploy, undeploy o altre operazioni che definiamo di amministrazione. Anche queste operazioni per il momento non sono supportate dalle WSA descritte dalle JSR-172. Il ruolo delle WSA è permettere, ad un dispositivo J2ME, di poter accedere ed utilizzare un servizio esposto attraverso un’interfaccia Web Service. Lo scenario principale prevede un client J2ME che utilizza un particolare servizio remoto a runtime come se fosse locale, quindi in modo semplice e snello. Analogamente a quanto avviene nel caso J2SE, le WSA ci dovranno mettere a disposizione uno strumento per generare degli stub che, attraverso un servizio locale a runtime, ci permetteranno di accedere ad un Web Service in modo trasparente.

L’architettura di un’applicazione J2ME, che utilizza le WSA, prevede la definizione delle seguenti componenti [26]:

o applicazione J2ME che intende utilizzare un particolare Web Service; o uno stub compliant con le JSR-172; o un servizio a cui lo stub accede a runtime attraverso un’interfaccia che prende il nome di Service Provider Interface (SPI).

40 Capitolo 2. Soluzioni Middleware per il mobile computing

Il ruolo del Service Provider Interface è quello di astrarre i servizi di gestione della connessione e codifica dei dati dalla effettiva implementazione, lasciata al particolare vendor. L’implementazione dei servizi descritti dalla Service Provider Interface prende il nome di Runtime.

Figura 2.8 - Architettura del J2ME Web Services API

Dalla Figura 2.8 si nota come una particolare applicazione non utilizzi direttamente i servizi della SPI, ma vi acceda attraverso lo Stub, che viene generato in modo automatico a partire dal WSDL di un servizio attraverso l’utilizzo di un insieme di tools forniti dal particolare vendor.

La modalità di accesso alle funzionalità di Runtime attraverso l’utilizzo di un Stub è il modo più semplice per accedere ad una Web Service attraverso WSA, le quali mettono a disposizione anche API di più basso livello.

41 Capitolo 2. Soluzioni Middleware per il mobile computing

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.

42 Capitolo 2. Soluzioni Middleware per il mobile computing

Con l’uso delle librerie kSOAP – kXML, possiamo saltare la fase di Stub generator fornita dal tool della Sun WTK. Basta includere tali librerie nel progetto J2ME ed esse permetteranno l’accesso ai servizi remoti. Questa è la sostanziale differenza con le specifiche JSR-172: in quest’ultime il client Java accede ad un clone-Java locale del servizio remoto (lo stub, appunto), mentre in questo caso le librerie kSOAP effettuano il packing SOAP e il parser direttamente sul descrittore WSDL del servizio remoto. Ciò rallenta il processo di interrogazione del servizio, ma dona maggiore dinamicità: se varia l’interfaccia del servizio remoto, le JSR-172 richiedono una nuova generazione dello stub, oltre che una modifica del client.

2.5.5 Jini

Mentre Java RMI è una tecnologia Java adattata al mobile computing, Jini [28] nasce per permettere la realizzazione e la distribuzione dei servizi in rete tra dispositivi che spaziano da minisistemi wireless ai PC, sino ai grandi server, basandosi sulla portabilità del codice offerta dalla JVM. Utilizzando protocolli di rete, Jini permette di mettere in comunicazione oggetti differenti fra loro, dove ognuno mette a disposizione dei servizi per tutti coloro che ne abbiano necessità. In una comunità Jini i servizi possono essere dinamicamente aggiunti o tolti, le applicazioni possono poi ricercare tali servizi ed usarli, senza averne a priori una specifica conoscenza.

Ad esempio, una stampante, nel momento in cui si connette ad una comunità Jini, prima si presenterà e poi esporrà la sua interfaccia, contenente per esempio il servizio print. Se successivamente un frigorifero Jini dovesse aver bisogno di stampare una pagina con dei dati relativi al proprio funzionamento, sarà sufficiente che vada a ricercare chi nella comunità mette a disposizione il servizio print e poi richiederne l’esecuzione.

Il concetto più importante all’interno dell’architettura Jini è quello di servizio [29]. Un servizio è un’entità che può essere usata da una persona, da un programma, o da un altro

43 Capitolo 2. Soluzioni Middleware per il mobile computing

servizio. Un servizio può essere computazione, memoria, un canale di comunicazione, un dispositivo hardware, o un altro utente. Due esempi dei servizi sono: stampare un documento e tradurre un documento da un formato ad un altro. Un sistema Jini deve pensarsi come un sistema di servizi che sono messi insieme per il compimento di una particolare operazione. I servizi possono usare altri servizi e un client di un servizio può essere anch’esso un servizio per altri clients.

I servizi sono trovati dal Lookup Service: una tabella contenente le interfacce che descrivono le funzionalità dei servizi presenti nella comunità Jini. In aggiunta vengono memorizzate le descrizioni testuali dei vari servizi, in modo da essere maggiormente comprensibili da un utilizzatore umano. La comunicazione fra i servizi avviene utilizzando Java RMI. L’accesso a molti dei servizi nell’ambiente Jini è basato sui leasing [29]. Un leasing è una concessione di accesso garantito per un certo periodo di tempo. Ogni leasing è negoziato fra il richiedente e il fornitore del servizio: un servizio è chiesto per un certo periodo; l’accesso è assegnato per un periodo la cui durata è decisa dall’ambiente Jini sulla base del periodo richiesto e dello stato dell’ambiente.

2.6 Soluzioni .NET

2.6.1 Panoramica su .NET Framework

Microsoft ha sviluppato .NET [30] come contrapposizione proprietaria al linguaggio Java. .NET e il suo linguaggio principe, ovvero C#, sono standard ISO riconosciuti. La sua caratteristica peculiare è di essere indipendente dalla versione operativa di Windows su cui è installata, e di includere molte funzionalità progettate espressamente per integrarsi in ambiente internet e garantire il massimo grado di sicurezza e integrità dei dati.

44 Capitolo 2. Soluzioni Middleware per il mobile computing

La CLR (Common Language Runtime) è un insieme di librerie che, insieme alla classe di librerie di base denominata FCL (Framework Class Library), è progettata per poter funzionare con qualsiasi sistema operativo. Il compilatore Just In Time esegue un codice assembly denominato CIL (Common Intermediate Language). È inoltre possibile:

o accedere a componenti scritti in altri linguaggi; o quando il sistema operativo sottostante è Microsoft Windows, accedere ai suoi servizi e alle sue API;

o accedere ai Web Services utilizzando il protocollo SOAP.

La CLI (Common Language Infrastructure) è concepita per essere compatibile con qualsiasi linguaggio di alto livello orientato agli oggetti, fornendo un unico modello a oggetti ed una vasta libreria di classi condivisibili.

La CLI, il CIL ed il C# sono simili rispettivamente alla JVM ed al linguaggio Java della Sun Microsystems, con cui sono in forte concorrenza. Entrambi utilizzano un proprio bytecode intermedio. Il bytecode di .NET è progettato per essere compilato al momento dell’esecuzione (Just In Time compilation, detta anche JITting). Al momento .NET è compatibile soltanto con le piattaforme Windows. Tuttavia, grazie al progetto Mono di Novell è possibile sviluppare e eseguire client e server application .NET su piattaforme diverse, non Windows.

2.6.2 .NET Compact Framework

La proposta Microsoft per il mobile è una versione “compatta” della piattaforma .NET. .NET Compact Framework [31] è un ambiente indipendente dall’hardware che consente di eseguire programmi su dispositivi quali PDA, cellulari e set-top box. Viene eseguito nel sistema operativo Microsoft Windows CE e si basa su CLR rigenerato che è stato progettato per funzionare in modo ottimale quando si eseguono programmi su dispositivi con risorse limitate. .NET Compact Framework estende la disponibilità di codice gestito e

45 Capitolo 2. Soluzioni Middleware per il mobile computing

di servizi Web XML ai dispositivi mobili e offre vantaggi quali l’indipendenza dai tipi, la Garbage Collection, la gestione delle eccezioni e la sicurezza. .NET Compact Framework, che rappresenta un sottoinsieme della libreria di classi .NET Framework, contiene anche classi appositamente progettate per dispositivi con risorse limitate ed eredita interamente l’architettura .NET Framework per Common Language Runtime e l’esecuzione di codice gestito. .NET Compact Framework è disponibile come componente di sistema operativo in tutti i dispositivi Microsoft Smart Device, inclusi PocketPC, PocketPC Phone Edition, Smartphone e altri dispositivi basati su Windows CE.

Architettura

In Figura 2.9, riportata di seguito, viene riepilogata l’architettura della piattaforma .NET Compact Framework.

Figura 2.9 - Architettura della piattaforma .NET Compact Framework

Windows CE

.NET Compact Framework utilizza il sistema operativo Windows CE per le funzionalità essenziali e per numerose funzionalità specifiche del dispositivo. Diversi tipi e assembly, ad esempio, quelli per i Windows Form, le immagini, il disegno e i servizi Web, sono stati

46 Capitolo 2. Soluzioni Middleware per il mobile computing

rigenerati per un’esecuzione efficiente sui dispositivi, anziché copiati dalla versione completa di .NET Framework. In .NET Compact Framework sono disponibili i seguenti tipi di interoperabilità con Windows CE:

o compatibilità con la protezione nativa; o integrazione completa con i programmi di installazione nativa; o interoperabilità con il codice nativo mediante l’interoperabilità COM e il richiamo piattaforma.

Common Language Runtime

Anche Common Language Runtime (CLR) di .NET Compact Framework è stato rigenerato per consentire l’esecuzione delle risorse vincolate sulla memoria limitata e l’utilizzo efficiente dell’alimentazione a batteria. Tra Windows CE e CLR esiste un livello di adattamento piattaforma che consente di mappare i servizi e le interfacce dei dispositivi necessarie per CLR e per il framework sui servizi e le interfacce di Windows CE.

Framework

.NET Compact Framework, che rappresenta un sottoinsieme di .NET Framework, contiene anche funzionalità appositamente progettate per .NET Compact Framework. Offre le

funzionalità e la semplicità che consentono agli sviluppatori di applicazioni per dispositivi nativi di passare a .NET Framework e agli sviluppatori di applicazioni desktop di passare ai dispositivi.

Ogni applicazione .NET Compact Framework viene eseguita all’interno di un costrutto di runtime denominato dominio applicazione, analogo a un processo del sistema operativo. .NET Compact Framework garantisce che tutte le risorse gestite utilizzate da un’applicazione in esecuzione vengano liberate o restituite al sistema operativo host al termine dell’applicazione.

47 Capitolo 2. Soluzioni Middleware per il mobile computing

I domini applicazione offrono numerosi vantaggi caratteristici dei processi, quali l’isolamento degli errori e livelli elevati di affidabilità e protezione, senza richiedere il supporto del sistema operativo sottostante. Nell’host di un dominio applicazione, costituito a propria volta da codice del sistema operativo nativo, viene avviata un’istanza di CLR. CLR può essere collegato all’host del dominio applicazione in modo statico o dinamico.

Utilizzo della memoria

Quando è disponibile una quantità di memoria insufficiente, in .NET Compact Framework vengono automaticamente rilasciate le strutture di dati non richieste dal codice attualmente in esecuzione. Di conseguenza, il programma può essere eseguito anche in presenza di memoria limitata. Se l’applicazione richiede una quantità di memoria superiore rispetto a quella disponibile, l’applicazione viene chiusa correttamente da .NET Compact Framework e vengono rilasciate tutte le risorse sottostanti.

2.7 Conclusioni

Si chiude qui la panoramica sulle tecnologie middleware analizzate per il mondo mobile computing. L’aspetto comune di ciascuna tecnologia è la necessità di introdurre nello sviluppo, e quindi nell’uso, delle applicazioni tool e librerie aggiuntive che garantiscano trasparenza e dinamicità, anche con aspetti e gradi diversi. Per esempio, la soluzione RMI garantisce trasparenza all’uso del servizio remoto, ma non al linguaggio e si adatta bene a soluzioni full-Java, in cui anche il servizio remoto sia implementato in linguaggio Java. Le soluzioni middleware e Web Services garantiscono trasparenza al linguaggio con prestazioni diverse. Particolare attenzione è stata data alle soluzioni Java mobile e, in particolare, al profilo J2ME MIDP, valido anche nel caso di un dispositivo CDC.

48 Capitolo 2. Soluzioni Middleware per il mobile computing

Altro aspetto comune delle tecnologie analizzate è che esse estendono le funzionalità mobile solo da un punto di vista client, nel senso che il servizio remoto è in ogni caso fornito da una macchina fissa, server o quantomeno desktop. Nel prossimo capitolo focalizzeremo la nostra attenzione sullo scopo reale di questo studio di tesi, ovvero integrare un framework di servizi su un dispositivo mobile. L’ambizione è quella di far risiedere il framework sul dispositivo mobile (per esempio, un palmare) con il compito di facilitare la realizzazione di applicazioni che ne sfruttino i servizi in modo trasparente.

49 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

3. Framework per l’integrazione di servizi in ambienti mobili

3.1 Obiettivi del framework

Nel capitolo precedente abbiamo parlato delle soluzioni middleware per mobile computing. Implicitamente abbiamo assunto che si trattasse di ambienti nomadici, ovvero il grosso del carico computazionale relativo al middleware, se non tutto, fosse delegato alla parte fissa dell’ambiente distribuito, mentre la parte mobile, in senso stretto, svolgesse funzioni di thin client. L’ambiente nomadico di riferimento non è stato presentato in senso architetturale: abbiamo pensato ad un ambiente LAN/WAN senza togliere la possibilità che i servizi risiedessero su un server remoto accessibile via Internet. Nell’ambito del progetto “WiFi People – CRONOS”, gli obiettivi richiesti per il framework vanno oltre lo stato dell’arte attuale:

o si vuole uscire dal sistema necessariamente nomadico e orientarsi ad un sistema Ad-Hoc, indipendente da qualunque infrastruttura fissa. Per ottenere quanto detto, è necessario che il framework risieda sul dispositivo mobile ed offra una serie di servizi.

o Dal punto di vista dell’utenza, il servizio principe fornito dal framework deve essere l’autoconfigurazione e l’autodistribuzione: un dispositivo mobile che entra a far parte della rete, “spontaneamente” costituita, deve essere messo in condizione di poter conoscere e ricevere dal dispositivo mobile più vicino le applicazioni distribuite sulla rete che usano, appunto, i servizi del framework

50 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

stesso. Lo scopo è che ogni dispositivo mobile (palmari, PDA…), appartenente al sistema mobile in questione, sia in grado di eseguire le applicazioni così distribuite. Sarà il framework a farsi carico della distribuizione dei servizi di cui necessita l’applicazione.

o Dal punto di vista della programmazione, il framework deve rispettare vincoli di trasparenza tipici di un middleware, garantendo ai programmatori del dispositivo mobile di poter realizzare applicazioni complesse che accedano a tali servizi.

3.2 Requisiti del framework

Possiamo immaginare il framework diviso in due parti: la parte più interna, costituita dai servizi, che dovrà soddisfare i requisiti funzionali, e la parte con cui le applicazioni utente e gli sviluppatori sono direttamente a contatto, ovvero il Framework Core, che sarà progettato sulla base dei requisiti non funzionali richiesti dal progetto “WiFi People – CRONOS”.

3.2.1 Requisiti funzionali

Di seguito riportiamo i servizi che il framework deve offrire. Si dia particolare attenzione all’ultimo servizio, su cui poggia la distribuzione delle applicazioni tra i dispositivi mobili, rendendo non necessaria la presenza dell’infrastruttura fissa.

Discovery dei servizi

Il servizio permette al dispositivo di scoprire quali servizi sono disponibili sulla rete e indicarne la disponibilità. Il servizio di discovery permette di accedere ai servizi scelti e ne consente l’utilizzo. Inoltre la configurazione del dispositivo e la ricerca sono totalmente automatiche e, quindi, non a carico dell’utente.

51 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

VoIP

Si vuole fornire un servizio di telefonia sul protocollo IP. Il dispositivo mobile diviene un client con la capacità di effettuare e ricevere chiamate attraverso la rete Internet.

Positioning/GPS

Si intende fornire un servizio per la localizzazione del dispositivo mobile in un ambiente fisico indoor e, attraverso le sue coordinate GPS, in ambiente fisico outdoor. Per fornire il servizio di positioning è possibile utilizzare indistintamente la tecnologia Bluetooth oppure la tecnologia Wi-Fi. L’ambiente indoor, nel quale si intende localizzare la posizione del dispositivo, dovrà essere opportunamente cablata con Access Point Wi-Fi o Bluetooth. Il palmare che offre il servizio GPS deve necessariamente essere dotato di un dispositivo GPS integrato o deve essere in grado di interfacciarsi con un dispositivo GPS esterno.

Sincronizzazione dati

Si vuole fornire un servizio di sincronizzazione di e-mail, contatti ed appuntamenti tra dispositivi.

Accesso DB

Si intende fornire un servizio per l’accesso ad un generico database remoto di informazioni. Si prevede una copia parziale del DB in locale di cui garantire la coerenza con il DB remoto. Tale procedura si attiva indoor in maniera automatica o su richiesta

dell’utente.

Instant Messaging

Si vuole fornire un servizio di messaggistica istantanea e presenza. Il dispositivo mobile diviene un client in grado di scambiare messaggi real-time con altri dispositivi.

52 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Interfacciamento periferiche esterne

Il servizio in questione intende offrire un’interfaccia standard di comunicazione con periferiche esterne e non integrate nel dispositivo mobile, come, ad esempio, stampanti Bluetooth e videocamere wireless.

Gestione canale SMS per notifiche ed alert

Tale servizio intende offrire la possibilità di inviare messaggi di testo SMS al fine di effettuare delle notifiche e generare degli alert. Per usufruire di tale servizio è necessario che il dispositivo mobile sia dotato di una scheda GSM o di un modem GPRS.

Video-streaming

Il servizio di video-streaming offre la possibilità di gestire i flussi video da e verso il dispositivo mobile. Il video-streaming, effettuato anche in multicast, verso altri dispositivi mobili può avere come sorgente un file video oppure, qualora fosse presente una telecamera sul dispositivo mobile sorgente, consentire la condivisione delle immagini che essa riprende.

Distribuzione del framework e discovery di applicazioni

Si intende fornire un meccanismo per cui l’utente può sapere, attraverso il suo dispositivo mobile, quali applicazioni sono già presenti sui dispositivi appartenenti all’area a cui si è connesso. Si intende dare all’utente la possibilità di effettuare il download di tali applicazioni ed,

eventualmente, dei relativi servizi necessari per il corretto funzionamento dell’applicazione stessa. Le applicazioni così distribuite possono accedere ai servizi del framework localmente oppure demandandone l’esecuzione ai dispositivi mobili circostanti. Qualora il dispositivo mobile possegga una versione più vecchia dell’intero framework o di una parte dei servizi, può effettuarne l’aggiornamento.

53 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

3.2.2 Requisiti non funzionali

Trasparenza dal linguaggio

Si intende l’indipendenza da un qualsiasi linguaggio di programmazione con cui uno sviluppatore potrà implementare le applicazioni utente che dovranno interagire con il framework per accedere ai servizi offerti. Ciò prevede l’omogeneizzazione dei dati tramite il marshalling e unmarshalling dei dati.

Trasparenza dal Sistema Operativo

Si intende l’indipendenza da un particolare sistema operativo che possa trovarsi sul dispositivo mobile su cui installare il framework. In particolare i sistemi operativi che vengono presi in considerazione sono Symbian, Linux, Windows Mobile.

Trasparenza alla comunicazione

Si intende garantire la comunicazione tra i framework e i servizi, distribuiti su tutti i dispositivi mobili, a prescindere dai protocolli di comunicazione adottati dall’infrastruttura di rete.

Load balancing

Con load balancing si intende la possibilità di distribuire il carico, cioè l’ottimizzazione dell’utilizzo delle risorse di calcolo tale che si migliorino le performance dei servizi forniti.

Utilizzo di strumenti open-source

Si vogliono sfruttare componenti open-source presenti sul mercato, in particolare sulla rete Internet, per la realizzazione dei servizi, descritti in precedenza, che deve fornire il sistema.

Portabilità dei servizi

Si intende la capacità del sistema e in particolare dei singoli servizi di “migrare” in nuovi ambienti, cioè su piattaforme diverse, garantendone il corretto funzionamento e utilizzo.

54 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Prestazioni

Inizialmente non daremo peso ai limiti tecnologici imposti dai dispositivi mobili presenti attualmente sul mercato, puntando ad una prima soluzione intermedia in cui il framework sia distribuito in parte sui dispositivi mobili stessi e in parte su macchine remote. L’idea è quella che, con l’introduzione sul mercato di nuovi e più potenti dispositivi mobili, il framework possa risiedere interamente su quest’ultimi, garantendo prestazioni adeguate alle applicazioni real-time.

Manutenibilità

E’ importante garantire una facile manutenzione del framework sia nell’ambito delle scelte tecnologiche per la realizzazione del Framework Core sia dal punto di vista dei servizi. Operazioni di aggiornamento, tanto del framework quanto della tecnologia, devono poter essere svolte con semplicità dagli sviluppatori e avvenire in trasparenza rispetto agli utenti finali.

3.3 Architettura del framework

Il Framework Core si pone come strato intermedio tra i servizi e le applicazioni (Figura 3.1), sia dal punto di vista dello sviluppo di queste ultime, sia dal punto di vista dell’applicazione utente che, per essere correttamente eseguita, deve accedere a determinati servizi.

Oltre a permettere l’accesso ai servizi in locale, l’architettura del sistema prevede di mettere in comunicazione diretta due o più dispositivi mobili, per esempio palmari. Il framework fornisce l’astrazione necessaria a livello applicazione affinché agli utenti sia del tutto trasparente la necessità di installare nuovi servizi da integrare nel framework oppure la necessità di aggiornarne qualche componente.

55 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Figura 3.1 - Architettura del framework: Framework Core e servizi

Un ruolo fondamentale riveste il servizio di Discovery dei servizi. Esso è il servizio che necessariamente va distribuito tra i palmari che vogliono godere della trasparenza sopra descritta. Tale servizio, unito a quelli di Aggiornamento framework e Download framework, costituisce l’insieme dei servizi necessari per la gestione del framework (indicati in verde in Figura 3.1).

Per esigenze legate alla manutenibilità tutti i servizi saranno scritti in un unico linguaggio in modo che le competenze richieste per la manutenzione completa siano contenute. Tuttavia ciò non vincola gli sviluppatori di applicazioni consumer ad adottare lo stesso linguaggio in cui sono implementati i servizi, grazie alla trasparenza dal linguaggio garantita dal Framework Core.

Vediamo, di seguito, i possibili scenari in cui il framework può trovarsi ad operare.

Partiamo dalla prima configurazione in cui il framework e i servizi sono totalmente

distribuiti sui dispositivi mobili (Figura 3.2). In questo caso la comunicazione tra i

56 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

dispositivi mobili e/o la collaborazione tra i servizi, presenti su ciascuno di essi, avverrà in

modo diretto senza la necessità di alcuna infrastruttura fissa intermediaria.

Figura 3.2 - Configurazione 1: Deployment del Framework su due dispositivi mobili

Per collaborazione tra i servizi intendiamo che affinché l’applicazione utente sia

correttamente eseguita è necessario avere a disposizione una determinata serie di servizi,

nonché una loro collaborazione diretta.

Per collaborazione tra i dispositivi mobili intendiamo il caso in cui i servizi non siano

tutti presenti sul dispositivo mobile o non eseguibili in locale. Può infatti accadere che

un’applicazione utente in esecuzione su un dispositivo mobile necessiti di un servizio non

presente o non eseguibile nel framework locale. In tal caso, possiamo adottare due strade

affinché l’esecuzione dell’applicazione utente vada comunque a buon fine:

1. il Framework Core si farà carico di eseguire sui dispositivi mobili più vicini una

ricerca del servizio mancante e, una volta trovato, ne effettuiamo il download sul

nostro dispositivo mobile (in Figura 3.3 riportiamo il download di un servizio IM).

Emerge, e risulta necessaria, in tale contesto la portabilità dei servizi richiesta al

framework.

57 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Figura 3.3 - Scenario 1: Download di un servizio mancante

2. Previa un’analoga operazione di ricerca del servizio, il Framework Core chiederà

al dispositivo mobile più vicino di eseguire per noi (esecuzione demandata) il

servizio mancante (in Figura 3.4 riportiamo l’esecuzione demandata di un servizio

IM). Tale contesto va incontro alle esigenze di load balancing, infatti un

dispositivo mobile può avvalersi dell’esecuzione demandata anche nel caso in cui

le risorse a sua disposizione non permettano l’esecuzione del servizio in locale.

Figura 3.4 - Scenario 2: Esecuzione demandata di un servizio mancante

58 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

In quest’ottica vanno fatte delle considerazioni. Percorrere l’una o l’altra via per sopperire alla mancanza di un servizio in locale non è indifferente; bisogna tener conto sia del tipo di applicazione utente sia del tipo di servizio. Se l’applicazione utente che richiede il servizio è fortemente real-time, conviene effettuare il download prima che l’applicazione sia in esecuzione o al più in fase di caricamento della stessa; così come non avrebbe senso demandare l’esecuzione del servizio GPS ad un altro dispositivo mobile, a meno che non ci interessi conoscere le coordinate GPS di quest’ultimo. Allo stesso modo sarebbe irrealizzabile demandare l’esecuzione di un servizio VoIP il quale ha necessità di riferirsi a periferiche locali, come microfono e altoparlante. Considerando anche le ridotte risorse dei dispositivi mobili, in generale l’esecuzione demandata dei servizi conviene in applicazioni lascamente o non real-time e tali da richiedere la trasmissione di piccoli pacchetti dati, come nel caso dell’IM dove i dati trasmessi sono essenzialmente stringhe. Un ulteriore scenario è l’aggiornamento di un servizio già presente sul dispositivo mobile locale. A seguito di un’opportuna ricerca del servizio, se ne rileva una versione più aggiornata su un dispositivo mobile vicino. A questo punto, si esegue una sostituzione parziale o totale del componente locale con il componente scaricato (in Figura 3.5 riportiamo l’aggiornamento di un servizio IM).

Figura 3.5 - Scenario 3: Aggiornamento di un servizio già presente in locale

59 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

I tre scenari visti in precedenza e le analoghe considerazioni possono riferirsi anche al caso in cui l’interazione avvenga tra un dispositivo mobile e una macchina server remota su cui risiede il servizio richiesto, purché il Framework Core risieda comunque sul dispositivo mobile. Passiamo ora alla seconda configurazione, questa volta tipica di una soluzione di nomadic computing. Tale soluzione prevede, infatti, la presenza di un’infrastruttura fissa (almeno una macchina server) su cui far risiedere il nostro framework e i sottostanti servizi. L’accesso ai servizi e la comunicazione tra i dispositivi mobili, continuando a dipendere dal framework, passeranno ora per il server. Questa configurazione, che solleva il dispositivo mobile dal carico computazionale legato al framework e ai servizi, ci permette di superare i limiti tecnologici legati ai dispositivi mobili odierni, ma richiede di garantire la trasparenza ad un livello diverso rispetto a quanto già descritto: alle trasparenze garantite dal Framework Core, dobbiamo aggiungere, sul lato client, la trasparenza alla locazione, ovvero le applicazioni devono essere utilizzate e sviluppate come se i servizi offerti dal framework risiedessero in locale, a patto di tollerare un certo aumento dei tempi di risposta di ciascun servizio.

Figura 3.6 - Configurazione 2: Deployment del framework su infrastruttura fissa (nomadic computing)

60 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Volendo mantenere i servizi sul palmare, un’ulteriore soluzione potrebbe essere effettuare un linking diretto tra client e servizio (es.: Java RMI). Il vantaggio è che recuperiamo in prestazioni per il dispositivo mobile, ma perdiamo la trasparenza del linguaggio. Per recuperarla potremmo implementare i servizi in ciascun linguaggio di programmazione e per ogni piattaforma per cui vogliamo realizzarne il corrispondente client. Lo sforzo per questo tipo di soluzione è notevole, inoltre la soluzione stessa si mostra poco lungimirante, nonché difficilmente manutenibile. Si pensi all’aggiornamento di un servizio da parte dello sviluppatore: oltre a richiedere più competenze, tale soluzione costringe ad intervenire su più implementazioni dello stesso servizio in linguaggi diversi. In tal caso risulta anche difficile mantenere una certa coerenza tra tutte le implementazioni possibili.

3.4 Studio di fattibilità

3.4.1 Introduzione

Riportiamo di seguito il documento relativo allo studio di fattibilità. Lo scopo di questo documento è riportare e riassumere lo studio effettuato sulle possibili tecnologie da poter utilizzare per la realizzazione del framework, che deve offrire servizi a client eterogenei (implementati in qualunque linguaggio tipico per applicazioni mobili) su piattaforme eterogenee (Windows Mobile, Symbian e Linux).

La piattaforma di riferimento iniziale per i nostri dispositivi mobili è Windows Mobile, in particolare le versioni 5.0 e 6.0. Il linguaggio di programmazione usato per la realizzazione dei servizi che compongono il framework è Java, in modo da garantire la portabilità dei nostri servizi. In precedenza, abbiamo visto che la soluzione nomadica ci permette di superare i limiti legati alle risorse hardware a disposizione per i dispositivi mobili attualmente diffusi, come Smartphones e PDA. Nell’ambito di questo studio, proseguiremo il nostro discorso supponendo che sia possibile adottare anche una soluzione intermedia, dove il framework

61 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

risulterà distribuito tra i dispositivi mobili e un’infrastruttura fissa e, in particolare, una parte dei servizi saranno residenti sui dispositivi mobili e i restanti su server remoti. Di conseguenza, sui dispositivi mobili implementeremo i servizi con J2ME, con J2SE i restanti. In entrambi i casi, utilizzeremo librerie open-source. Per implementare i client di test e verificare la trasparenza al linguaggio utilizzeremo il linguaggio C#.

3.4.2 Confronto tra le possibili scelte tecnologiche

Per una rapida comprensione delle caratteristiche delle tecnologie esaminate e per mostrarne un confronto di facile lettura, è stata realizzata una griglia (griglia di fattibilità) su cui sono riportati i risultati dello studio effettuato.

Figura 3.7 - Griglia di fattibilità del framework per le tecnlogie esaminate (Nota - SMCD: Si, ma con difficoltà)

Teniamo una breve panoramica su quelli che sono i vantaggi e gli svantaggi di ciascuna tecnologia che possiamo adottare per lo sviluppo del framework:

Web Services

I vantaggi dei Web Sevices sono la trasparenza rispetto sia al linguaggio di programmazione che al sistema operativo, mentre gli svantaggi sono legati alle performance che sono minori di quelle riscontrabili utilizzando approcci alternativi di distributed computing quali Java RMI, JINI e wireless CORBA. Il problema di fondo dei Web Services è legato alle scarse risorse che oggi offrono i dispositivi mobili, come i

62 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

palmari. Esse, infatti, non permettono di installare un server, anche di piccole dimensioni, a cui i client possano chiedere uno dei servizi facente parte del framework.

Java RMI

I vantaggi di utilizzare Java RMI sono la trasparenza rispetto ai sistemi operativi e la distribuzione del carico su più dispositivi (RMI è nata proprio per consentire a processi Java distribuiti di comunicare attraverso una rete, rendendo trasparenti al programmatore quasi tutti i dettagli della comunicazione su rete), con la possibilità di accedere anche a servizi locali. Inoltre, le prestazioni sono migliori rispetto a quelle dei Web Services. Gli svantaggi, invece, sono la non completa trasparenza rispetto ai linguaggi di programmazione, essendo RMI una tecnologia Java. Il problema è soprattutto per la piattaforma .NET per cui, a differenza del C++, non esiste alcun porting Java.

JINI

Il vantaggio principale di Jini è da attribuire alle sue caratteristiche di scalabilità, proprie delle tecnologie orientate ai servizi e nate per ben adattarsi ad ogni dispositivo target. Ecco i motivi della sua elevata manutenibilità. Tuttavia la comunicazione tra i servizi, in Jini avviene con la tecnologia Java RMI da cui eredita lo svantaggio di non realizzare una piena trasparenza al linguaggio.

Wireless CORBA

Wireless CORBA presenta molti vantaggi, tra cui la possibilità di distribuire il carico e la possibilità di accedere localmente ai servizi con prestazioni migliori rispetto alle altre tecnologie prese in esame. E’ da tenere comunque presente che le prestazioni si abbassano notevolmente quando il volume dei dati scambiati aumenta sopra i 1024 byte. Questa tecnologia va, però, esclusa poiché non è utilizzabile sulla piattaforma di riferimento Windows Mobile.

63 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Protocollo proprietario basato su XML

Il vantaggio di questa scelta si riduce alla possibilità di creare un protocollo di comunicazione che soddisfi perfettamente i requisiti fissati dal documento di specifica. In questo modo avremo un elevato grado di manutenibilità grazie alla completa conoscenza del protocollo progettato ed implementato da noi stessi. Di contro realizzare un nuovo protocollo comporta tempi di realizzazione molto lunghi e difficoltà di implementazione, legate anche al fatto di doversi comunque attenere agli standard XML già definiti. Oltre ciò, è impossibile prevedere le prestazioni garantite dal protocollo che realizzeremo, senza contare che gli sviluppi della tecnologia in ambito di dispositivi mobili potrebbe far risultare inutili i nostri sforzi.

3.4.3 Prospettive di mercato

In ultimo è stata fatta una piccola analisi di mercato per catturare le direzioni di mercato relative alle tecnologie di distributed computing. In particolare, due delle aziende leader nel settore, la TIBCO e la BEA Weblogic puntano molto sul modello SOA, architettura orientata ai servizi, che sembra andare per la maggiore anche per aziende minori. La chiave di tale architettura, ovviamente, è il “servizio”: l’idea è quella di avere molti servizi, implementati anche in differenti linguaggi e da persone diverse, a cui accedere in modo tale da poter riutilizzare anche implementazioni di servizi già esistenti. Poiché il modello SOA trova nei Web Services la sua maggiore implementazione, entrambe le aziende indicano, appunto, i Web Services come la soluzione da adottare.

In particolare, la TIBCO offre una suite completa di librerie RIA AJAX enterprise-class per l’implemetazione di applicazioni Web e in particolare Web Services. Ajax è una tecnica di sviluppo Web per creare applicazioni Web interattive.

Per quanto riguarda la BEA Weblogic prendiamo da loro sito di riferimento una frase molto esplicita:

64 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

“La BEA Weblogic offre prodotti e servizi che permettono alle aziende di ottenere più velocemente un time-to-value per le applicazioni critiche di business, utilizzando standard aperti, Web Service e una Service-Oriented Architecture (SOA)”.

3.5 Conclusioni

Dall’analisi effettuata e seguendo le scelte tecnologiche di TIBCO e BEA Weblogic, la nostra scelta riguardo la tecnologia da utilizzare è quella dei Web Services. Grazie alla trasparenza che offrono per l’accesso, remoto o locale, i Web Services si prestano, per loro natura, ad adattarsi bene all’evoluzione della tecnologia dei dispositivi mobili. Le aspettative di mercato prevedono che nel prossimo futuro, in particolare, i palmari avranno risorse sufficienti per poter ospitare il framework di servizi secondo le configurazioni e gli scenari illustrati precedentemente. Adottando la soluzione nomadica per la distribuzione del framework, sembrerebbe così di aver trovato la soluzione definitiva per la sua implementazione (vedi Appendice A). In realtà, non tutte le configurazioni mostrate in precedenza possono essere adottate indistintamente. Si pensi al servizio di Instant Messaging nella soluzione nomadica: fondamentalmente si tratta di scambiare, attraverso messaggi SOAP, stringhe di testo tra il client C# (sul palmare) e il Web Service (su macchina server), che quest’ultimo provvederà a gestire e inoltrare verso il dispositivo mobile destinatario. Lo scambio dei messaggi SOAP sarà indipendente dall’hardware dei Web Service consumers coinvolti. Il problema si pone, invece, per quella tipologia di servizi per cui il flusso di dati scambiati con un altro host (sia esso un dispositivo mobile o una macchina server) dipende fortemente dalle caratteristiche hardware del dispositivo mobile stesso. In tal caso è necessario che il servizio e, quindi, il framework risiedano sul dispositivo mobile, escludendo la soluzione nomadica. Al più potremmo adottare la soluzione intermedia, per esempio, con la distribuzione del servizio IM su macchina server e del servizio VoIP direttamente su dispositivo mobile.

65 Capitolo 3. Framework per l’integrazione di servizi in ambienti mobili

Nel seguente capitolo studieremo una soluzione per implementare un servizio VoIP su palmare. Nell’applicazione VoIP è intrinseco il suo legame con le caratteristiche hardware del palmare stesso. Si dovrà gestire uno streaming audio che adotta come source il microfono di un host e come drain le casse di un altro. Lo streaming audio è possibile sono in presenza di codec opportuni che possono essere compatibili o meno con il palmare stesso. Pensare di elaborare uno streaming audio lato Web Service su una macchina server, che presenta risorse ben più estese di un palmare, va contro la fattibilità del VoIP stesso: rischieremo di avere un flusso audio che il palmare non può in nessun modo né elaborare né riconoscere come tale. Confidando, quindi, nelle prospettive tecnologiche che il mercato dei dispositivi mobili promette per l’avvenire, passeremo all’implementazione del servizio VoIP direttamente sul palmare, proiettandoci verso un Web Service su dispositivo mobile.

66 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

4. Analisi di un caso di studio: integrazione del servizio VoIP

In questo capitolo tratteremo, in particolare, lo sviluppo e l’integrazione di uno dei servizi offerti dal nostro framework: il servizio VoIP. Tale servizio ci pone di fronte ad uno studio interessante, infatti, come già accennato, il VoIP on mobile mostra diversi limiti tecnologici, volendo esporre il servizio come un Web Service, ma, allo stesso tempo, ci proietta verso il futuro delle tecnologie mobile.

4.1 Panoramica sulla tecnologia VoIP

Voice over IP (voce tramite protocollo Internet) [32], acronimo VoIP, è la tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione ad Internet o un’altra rete che utilizza il protocollo IP (Internet Protocol), anziché utilizzare esclusivamente la normale linea di trasmissione telefonica (PSTN), permettendo di eliminare le centrali di commutazione ed economizzare sulla larghezza di banda occupata.

Le conversazioni VoIP possono usare come mezzo trasmissivo una qualsiasi rete basata sul protocollo IP come una rete privata locale (LAN) all’interno di un edificio o di un gruppo di edifici o una rete più ampia (WAN), fino alla grande rete pubblica, Internet. La telefonia via IP permette una maggiore efficienza nell’uso della rete, grazie all’utilizzo della commutazione di pacchetto che, a differenza della commutazione di circuito, non assegna staticamente le risorse disponibili durante l’intera durata di una comunicazione ma ne consente la condivisione con altri sistemi di comunicazione dati, quali testo e video. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati

67 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati sta parlando.

La tecnologia VoIP permette applicazioni impossibili alle tradizionali reti telefoniche [33]: ad esempio, si può portare il proprio telefono VoIP ovunque sia disponibile una connessione Internet e ricevere ed effettuare chiamate come se si fosse a casa propria, rimanendo raggiungibili allo stesso numero. In parallelo con la conversazione telefonica si possono scambiare flussi video in tempo reale (videoconferenza), possono essere inviati e ricevuti messaggi o file e si può partecipare a conferenze audio tra più persone in modo intuitivo ed a costi molto bassi.

Tra i vantaggi del VoIP rispetto alla telefonia tradizionale va annoverato la diffusione a larga scala di applicazioni come la videoconferenza e la videotelefonia, supportata non solo dalla significativa riduzione del costo delle comunicazioni a lunga distanza, ma soprattutto nei vantaggi operativi e di semplificazione delle infrastrutture.

La tecnologia VoIP ha comunque diversi punti deboli che possono rallentare una sua larga diffusione. Il problema di fondo della tecnologia VoIP è che la rete Internet è una rete best effort e non dà quindi nessun tipo di garanzia né in termini di ritardo, di perdita e di ordine sulla ricezione e la ricostruzione dei pacchetti di dati ricevuti. Risulta quindi necessario assicurare che il flusso audio mantenga la corretta coerenza temporale [33]. Questi problemi sono sempre meno rilevanti, grazie a tecnologie che permettono di assegnare una priorità diversa a certi pacchetti dati, garantendo la qualità del servizio (QoS).

Altre problematiche sono quelle relative all’affidabilità: i telefoni tradizionali senza cavo di alimentazione (la quasi totalità dei telefoni fissi) sono alimentati dalla linea telefonica, e in caso di black-out continuano a funzionare grazie a batterie e generatori all’interno delle centrali telefoniche. I telefoni VoIP (apparecchi, simili ad un tradizionale telefono, che si collegano direttamente ad un router connesso ad Internet) hanno bisogno della corrente

68 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

elettrica per funzionare e non sarebbero quindi disponibili durante un black-out rendendo impossibile qualsiasi telefonata.

Inoltre le connessioni Internet a “banda larga” possono essere meno affidabili di una linea telefonica e, se si presentano dei ritardi nell’invio o nella ricezione dei pacchetti o una perdita degli stessi, la comunicazione vocale viene momentaneamente interrotta. Questi fenomeni si presentano in modo più evidente quando applicazioni VoIP utilizzano reti altamente congestionate o le distanze tra i punti finali sono molto lunghe [37].

A questo va aggiunto che i canali di telecomunicazione hanno un’intrinseca limitatezza in termini di capacità nel trasportare dati, per cui è necessario adottare delle strategie di codifica. In quest’ottica gli organismi internazionali preposti alla standardizzazione hanno sviluppato e approvato protocolli sempre più leggeri ed efficaci, emanando opportune raccomandazioni e definendo i terminali e le componenti tecniche necessarie per la comunicazione multimediale su diversi tipi di sottoreti. In particolare i protocolli al momento più utilizzati sono: H.324, H.320, H.323 e dell’ITU – T, SIP dell’IETF e 3G-324-M del 3GPP. Molto spesso queste raccomandazioni sono implementate su sistemi non sempre compatibili e connessi a reti di diverse tipologie come LAN, xDSL (Digital Subscriber Line), ISDN (Integrated Services Digital Network), linee telefoniche analogiche e linee wireless.

Nel trasmettere audio e video su reti eterogenee, ad esempio, la connessione tra sorgente e destinatario può essere stabilita su collegamenti di rete con diverse caratteristiche e capacità. In questi casi il bit rate del segnale trasmesso deve essere adattato alla banda del canale, a cui è collegato l’utente finale. Se la comunicazione avviene tra sistemi che usano protocolli di segnalazione e codec diversi, c’è anche la necessità di convertire il flusso di bit originario, codificato secondo le

69 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

regole sintattiche di uno standard, in un nuovo bit stream che sia interpretabile dal ricevitore. Per fare ciò occorre utilizzare, oltre ai gateway tradizionali, anche nuove apparecchiature in grado di collegare la rete dati Internet e la rete telefonica tradizionale. Queste apparecchiature sono note come Internet Telephony Gateway (o Voice Gateway) e sono solitamente installate presso gli operatori di telefonia via Internet. I gateway manipolano le trasmissioni vocali convertendole, dalla rete tradizionale, in forme idonee alla trasmissione su reti a commutazione di pacchetto. Permettono quindi di terminare sulla rete tradizionale PSTN telefonate che hanno avuto origine sulla rete IP di un operatore di telefonia via Internet o, viceversa, di rendere accessibile un utente di telefonia VoIP dalla rete telefonica tradizionale. In questo ambito, per esempio, si colloca il gateway VoIP PBX open-source Asterisk.

4.2 Protocolli per il VoIP

La tecnologia VoIP richiede due tipologie di protocolli di comunicazione in parallelo [34].

Il primo è per il trasporto dei dati (pacchetti voce su IP): in tal caso, nella grande maggioranza delle implementazioni di VoIP, viene adottato il protocollo RTP (Real-time Transport Protocol).

Il secondo protocollo è destinato al controllo della conversazione, ovvero fornisce

meccanismi per instaurare, modificare e terminare una conversazione. In tal caso si possono adottare diversi protocolli [32] tra cui:

o SIP (Session Initiation Protocol) della IETF; o H.323 della ITU; o Skinny Client Control Protocol, protocollo proprietario della Cisco; o Megaco (conosciuto anche come H.248) e MGCP; o MiNET, protocollo proprietario della Mitel;

70 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

o Inter Asterisk Xchange (IAX), soppiantato da IAX2, usato dai server PBX Asterisk open-source e dai relativi software client.

4.2.1 RTP

Il protocollo RTP (Real-Time Protocol) [35] fornisce le funzionalità di trasporto delle informazioni, in particolare in H.323. In particolare, RTP consente il trasferimento in tempo reale punto-punto di informazioni interattive audio, video e dati su reti unicast o multicast: un tipico scenario di utilizzo è la videoconferenza. Le funzioni svolte da questo protocollo comprendono la ricostruzione al ricevitore della corretta sequenza dei pacchetti e della loro posizione nella scala dei tempi, consentendo quindi la ricostruzione dei sincronismi. Questo protocollo non permette, nativamente, di sincronizzare più sessioni multimediali tra di loro in quanto ogni sessione RTP è in grado di trasportare un solo flusso. Questo non impedisce, tuttavia, il dialogo tra N soggetti, che è anzi supportato nativamente attraverso lo sfruttamento di un’eventuale tecnologia multicast sulla rete sottostante. Tuttavia in presenza di più sessioni distinte (ad esempio audio e video) è necessario attivare più sessioni RTP, ognuna delle quali è identificata da una coppia di indirizzi di livello trasporto (indirizzo IP e numero di porto), e nel caso di multicast l’indirizzo di destinazione è comune a tutti i partecipanti. Utilizzando due sessioni RTP è possibile fare in modo, ad esempio, che alcuni partecipanti ricevano sia l’audio che il video, mentre altri ricevano solo uno dei due.

L’header di un pacchetto RTP è composto da una parte fissa e un’estensione, utilizzata per scopi sperimentali. La parte fissa dell’header si articola su 12 byte e contiene i seguenti campi [35]:

o V (Version): indica la versione di RTP utilizzata;

71 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

o P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di riempimento non facenti parte del payload. L’ultimo byte di padding contiene il valore di quanti byte padding sono presenti;

o X (eXtension): se impostato ad uno, indica la presenza di un’estensione dell’header;

o CC (CSRC Count): è il numero di CSRC (Contributing SouRCes) presenti dopo la parte fissa dell’header;

o M (Marker): l’interpretazione di questo bit è legata al profilo; o PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata staticamente la corrispondenza tra il codice e il formato del payload;

o Numero di sequenza (Sequence Numbers): è incrementato di uno per ogni pacchetto inviato; può essere utilizzato dal destinatario per accorgersi della perdita di pacchetti e per ricostruire l’ordine corretto della sequenza;

o Timestamp: riflette l’istante di campionamento del primo ottetto dei dati. L’istante di campionamento deve essere derivato da un clock che si incrementa monotonamente e linearmente nel tempo per permettere i controlli di sincronizzazione e le misure dell’incertezza sugli arrivi dei pacchetti (arrival jitter);

o SSRC (Synchronization SouRCe): identifica la stazione trasmittente; o CSRC (Contributing SouRCe): questo campo è opzionale ed è presente solo se un elemento della rete ha unito in un unico flusso contributi provenienti da diverse sorgenti; al suo interno sono elencati gli SSRC delle singole stazioni.

In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un codice univoco, il SSRC, che permette alla stazione stessa di essere univocamente identificata all’interno della sessione real-time in esame.

RTCP (Real-Time Control Protocol) [35] monitora l’invio dei dati e controlla e identifica i servizi. Dunque riconosce automaticamente il tipo di compressione utilizzato sulla linea

72 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

e segnala al mittente e al destinatario eventuali problemi riscontrati sulla rete o sulla stazione di lavoro (identificandone la fonte), tenendo sotto controllo e fornendo feedback circa la qualità di ricezione e distribuzione dei dati (es.: numero dei pacchetti ricevuti o persi sul jitter) . RTCP (RTP Control Protocol) monitora la qualità del servizio e trasporta le informazioni riguardo ai partecipanti ad una sessione [36]. RTCP è sufficiente per sessioni loosely controlled, in cui non c’è un reale controllo dei partecipanti e set-up della sessione, e non è necessario che tutti i requisiti di controllo siano soddisfatti. Da ciò RTP può essere coadiuvato da un protocollo apposito per la gestione delle sessioni.

Solitamente le applicazioni pongono l’RTP sopra l’UDP per le operazioni di multiplexing e checksum, anche se può essere usato con altri protocolli di rete e trasporto sottostanti.

I numeri di sequenza che troviamo nel protocollo RTP permettono all’utente che riceve i dati di ricostruire la sequenza dei pacchetti del mittente. Le conferenze multicast multimediali non sono però la sua unica capacità. Ad esempio, trovano posto in questo protocollo la memorizzazione di un flusso dati continuo, le simulazioni interattive distribuite, le misurazioni e i controlli.

4.2.2 H.323

Il protocollo H.323 [37] è una raccomandazione ITU – T (International Telecommunications Union – Telecommunication Standardization Sector) che specifica il modo in cui il traffico multimediale deve essere trasmesso in reti a commutazione di pacchetto che non prevedono qualità del servizio (in particolare la rete IP). Questo standard si occupa delle segnalazioni e del controllo delle chiamate, la trasmissione e il controllo di informazioni multimediali e il controllo di ampiezza di banda nelle conferenze in tempo reale punto-punto e multipunto.

73 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Figura 4.1 - Una generica infrastruttura H.323

Gli elementi fondamentali di un sistema H.323 sono [37]:

o i terminali, ovvero dispositivi che si interfacciano con gli utenti (es.: PC o apparecchi telefonici analogici tradizionali). Offrono funzionalità di controllo del sistema, formattazione di flussi audio/video che devono essere trasmessi, codifica audio e video (quest’ultima opzionale), supporto di applicazioni (come ad es.: conferenze audiografiche);

o i gateway, che traducono i vari formati di trasmissione audio, video e dati connettendo, di fatto, reti di tipo diverso (come la rete IP, la rete telefonica tradizionale, la rete ISDN, ecc.);

o il gatekeeper, è il componente centrale dell’infrastruttura H.323, nonostante sia considerato un elemento opzionale. Tra le funzioni svolte da un gatekeeper troviamo: ƒ fornire un metodo di autenticazione di terminali e gateway; ƒ gestire la banda e l’accounting (ovvero raccogliere gli elementi per fatturare i servizi erogati);

o MCU (Multipoint Control Unit), si tratta del sistema che permette di estendere la comunicazione da punto a punto a punto multi-punto. Gestisce conferenze multipoint tra tre o più terminali. E’ costituito da un MC (Multipoint Controller), che assicura un livello minimo di comunicazione e da uno o più processori MP (Multipoint Processor), per l’audio, il video o i dati.

74 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

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.

75 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Le operazioni più importanti nello standard H.323 sono:

o l’attivazione del canale RAS con la conseguente registrazione presso il Gatekeeper e l’instaurazione di una chiamata. Il canale RAS è un canale di comunicazione inaffidabile tra i terminali e il gatekeeper. Viene aperto prima che venga attivato qualsiasi altro canale, e trasporta i messaggi RAS che svolgono le procedure di registrazione, ammissione, variazione dell’ampiezza di banda, stato e disconnessione;

o la ricerca del gatekeeper è un processo manuale o automatico utilizzato dai terminali per identificare il gatekeeper sul quale si devono registrare. Con il metodo manuale, i terminali vengono configurati con l’indirizzo IP del gatekeeper, mentre il metodo automatico richiede un meccanismo di ricerca automatica, che consente ad un terminale, che non conosce il proprio gatekeeper, di trovarlo tramite l’invio di un messaggio multicast;

o la registrazione è il processo che consente ai gateway, ai terminali e alle unità MCU di collegarsi ad una zona e fornire al gatekeeper i propri indirizzi IP e alias.

4.2.3 SIP

Il SIP (Session Initiation Protocol) [37] è un protocollo del livello applicazione che nasce in ambito IETF come alternativa più semplice al sistema H.323, ed è utilizzato per attivare, gestire e chiudere le sessioni multimediali. Esso trova applicazione non solo nella telefonia su IP e nei servizi telefonici supplementari, ma anche nella video-comunicazione, nei giochi interattivi, nella messaggistica istantanea. Il protocollo SIP ha fondamentalmente le seguenti funzioni:

o invitare gli utenti a partecipare ad una sessione; o localizzare gli utenti; o acquisire le preferenze degli utenti;

76 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

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

77 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

hanno il compito di dare una descrizione dettagliata delle risorse necessarie all’instaurazione della chiamata e di riservarle. Il protocollo SIP supporta la mobilità ed è dialog-oriented: un dialogo è una relazione persistente tra entità paritetiche che si scambiano richieste e risposte in un contesto comune.

Per quanto riguarda l’indirizzamento, lo standard prevede che ogni utente abbia un indirizzo SIP: dunque l’indirizzo è proprio dell’utente, non del terminale. Gli indirizzi (le cosiddette SIP URL) hanno la forma del tipo [email protected], quindi sono simili a indirizzi e-mail. La parte iniziale dell’indirizzo (nomeutente) è il nome dell’utente o un numero telefonico, la parte finale (dominio.com), può essere il nome di dominio oppure un indirizzo di rete. Grazie a questo meccanismo, SIP supporta anche l’interlavoro con la rete telefonica classica: un indirizzo nella forma [email protected] può indicare la volontà di raggiungere l’utente telefonico indicato attraverso un gateway tra mondo IP e mondo telefonico presso l’università Federico II di Napoli (in questo caso si deve indicare, attraverso il parametro user=phone, che l’identificativo è un numero telefonico).

Passiamo ad analizzare l’architettura SIP: i componenti fondamentali sono gli User Agent e i server di rete.

Gli User Agent sono applicazioni operanti sul sistema terminale che includono due componenti [38]:

o User Agent Client: si occupa delle procedure necessarie a far partire una chiamata; o User Agent Server: riceve le richieste di chiamate in arrivo e restituisce le risposte dell’utente chiamato.

78 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Figura 4.3 - User Agent Client (UAC) e User Agent Server (UAS) nello scambio di un messaggio INVITE tra un chiamante e due chiamati

Il Proxy Server [37] è un server intermedio; può rispondere direttamente alle richieste oppure instradarle ad un client, ad un server o ad un ulteriore proxy. Un proxy server analizza i parametri di instradamento dei messaggi e “nasconde” la reale posizione del destinatario del messaggio, essendo quest’ultimo indirizzabile con un nome convenzionale del dominio di appartenenza. Il vantaggio nel suo utilizzo sta nel fatto che al proxy server può essere delegata in toto la gestione della chiamata, ragion per cui i terminali utente non

devono preoccuparsi di tutte le procedure di segnalazione nella loro interezza.

Il Redirect Server [37] accetta le richieste SIP e invia al client una risposta di redirezione contenente l’indirizzo del server successivo. Questo tipo di server non accetta chiamate e non elabora o inoltra le richieste SIP.

Il Location Server [37] implementa un servizio di risoluzione degli indirizzi: è dunque un database contenente informazioni sull’utente, come il profilo, l’indirizzo IP, l’URL.

79 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Il Registrar Server [37] è un server dedicato o collocato in un proxy. Quando un utente è iscritto ad un dominio, invia un messaggio di registrazione del suo attuale punto di ancoraggio alla rete ad un Registrar Server.

Il Multi Conference Unit [37] è un oggetto in grado di realizzare chiamate tra tre o più persone, con le stesse caratteristiche dell’analogo componente presente in H.323.

Figura 4.4 - Una generica infrastruttura SIP

Un messaggio SIP [37] è una richiesta (attivata dai client) o una risposta (restituita dai server); la sequenza di una richiesta e una o più risposte è detta transazione SIP: una transazione è identificabile da un transaction-ID, un identificativo che ne specifica la sorgente, la destinazione e il numero di sequenza. E’ possibile trasmettere le transazioni SIP sia in UDP che in TCP.

Ogni messaggio contiene un’intestazione che descrive i dettagli della comunicazione, specificando il chiamante, il chiamato, il percorso e il tipo di messaggio contenuto in una chiamata. I messaggi SIP per il controllo delle chiamate sono in formato testo, molto simili a quelli usati da HTTP per lo scambio di pagine Web. I messaggi sono di richiesta e di risposta. Gli UAC inviano messaggi di richiesta. Questi vengono instradati fino a giungere agli UAS di destinazione i quali spediranno le risposte. I messaggi di richiesta SIP sono [38]:

80 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

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: ; tag = 4711

‘‘//identifica la destinazione logica di una richiesta’’ To: Domenico

‘‘//è un valore costante che identifica l’invito’’ Call-Id: [email protected]

‘‘//ordina le transazioni (..la prossima richiesta avrà Cseq=50)’’ Cseq: 49 Invite

‘‘//il body consiste in 117 byte ‘‘ Content-Length: 117

‘‘//tipo di media descritto secondo il protocollo [[SDP]]’’ Content-Type: application /sdp

81 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Subject: felicitazioni! ‘‘//l’oggetto del messaggio’’

‘‘//l’indirizzo al quale si desidera ricevere richieste’’ Contact: sip:[email protected]:4050

‘‘//specifica il protocollo di trasporto, ‘‘ ‘‘//nell’esempio [[User Datagram Protocol|UDP]]’’ transport = udp

v = 0 ‘‘//indica la versione in uso’’

‘‘//l’owner della risorsa con un ID di sessione’’ o = jack 7564657 9823872 IN IP4 134.102.18.1

‘‘//tipo di rete, la versione del protocollo IP e l’IP stesso ‘‘ c = IN IP4 134.102.18.1

t = 0 0 ‘‘//tempo di start e di stop’’

‘‘//tipo di media, num. Di porto, protocollo di trasporto e formato ‘‘ m = audio 4754 RTP/AVP 0

a = rtpmap: 0 PCMU/8000 ‘‘//attributi audio\video.. se ce ne fossero ‘‘

s = festa ‘‘//subject della sessione’’

Ulteriori dettagli sul protocollo SIP possono essere trovati nel documento RFC (Request For Comments) 2543: se ne trova una sua copia online all’indirizzo http://www.ietf.org/rfc/rfc2543.txt.

4.2.4 IAX

IAX [37] è un acronimo che sta per Inter Asterisk Xchange. È un protocollo utilizzato da Asterisk, un server PBX open-source della Digium. Si usa per abilitare connessioni VoIP tra i server Asterisk e tra server e client che utilizzano lo stesso protocollo.

IAX ora è comunemente indicato come IAX2, la seconda versione del protocollo IAX. Il protocollo originale IAX è obsoleto ed è disapprovato in funzione di IAX2. Il progetto del protocollo IAX fu basato su vari standard di controllo e trasmissione tra cui SIP, Media Gateway Control Protocol (MGCP) e RTP. Il protocollo IAX2 fu creato da Mark Spencer per Asterisk per la gestione delle chiamate VoIP. Esso è un protocollo robusto e completo rimanendo al contempo semplice. È indipendente dal codec e dal numero di flussi, quindi può essere usato in teoria per il trasporto di qualunque tipo di dato (questa caratteristica diventerà utile quando il videotelefono diventerà comune).

82 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

IAX2 utilizza un singolo flusso dati UDP (di solito sulla porta 4569) per comunicare tra i due sistemi sia per il controllo che per i dati. Il traffico voce è trasmesso in banda rendendo più semplice per l’IAX2 l’attraversamento di un firewall ed è più probabile che lavori dietro una rete con NAT (il protocollo SIP invece utilizza un flusso fuori banda RTP per il trasporto delle informazioni). Il protocollo IAX2 supporta il trunking per trasportare su un singolo collegamento dati e segnali per più canali. Quando è attivo il trunking più chiamate sono unite in un singolo insieme di pacchetti, quindi un singolo datagramma IP può trasportare informazioni relative a più chiamate riducendo l’effettivo overhead senza creare ritardi addizionali. Questo è un vantaggio notevole per gli utilizzatori del VoIP dove le intestazioni IP occupano una grossa percentuale della larghezza di banda.

4.3 QoS e codec

Le reti IP non dispongono di per sé di alcun meccanismo in grado di garantire che i pacchetti di dati vengano ricevuti nello stesso ordine in cui vengono trasmessi, né alcuna garanzia relativa in generale alla qualità di servizio. Le attuali applicazioni nel mondo reale della telefonia VoIP si trovano a dover affrontare problematiche legate a problemi di latenza (sostanzialmente si deve ridurre il tempo di transito e di elaborazione dei dati durante le conversazioni) e di integrità dei dati (prevenire perdite e danneggiamenti delle informazioni contenute nei pacchetti).

Il problema di fondo della tecnologia VoIP è la corretta ricostruzione dei pacchetti di dati ricevuti [37] [38], tenuto conto del fatto che durante la trasmissione può cambiare la sequenza dei pacchetti e che alcuni pacchetti possono aver subito perdite o danneggiamenti delle informazioni contenute, e assicurare così che il flusso audio mantenga la corretta coerenza temporale. Altro importante problema è mantenere il tempo di latenza dei pacchetti sufficientemente basso, in modo che l’utente non debba aspettare troppo tempo prima di ricevere le risposte durante le conversazione.

83 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Riportiamo di seguito alcuni problemi e le relative possibili soluzioni [34]:

o alcuni router possono essere configurati per distinguere via hardware i pacchetti VoIP dagli altri, ed assegnare di conseguenza ad essi una priorità maggiore;

o è possibile memorizzare in un buffer i pacchetti, per rendere la trasmissione più asincrona, ma ciò può tradursi in un aumento del tempo di latenza, simile a quello delle trasmissioni satellitari;

o il gestore della rete dovrebbe garantire una larghezza di banda sufficientemente ampia, per ridurre il tempo di latenza e le perdite di dati. Tuttavia ciò, mentre è relativamente facile nelle reti private, è molto più difficile quando si usa Internet come mezzo trasmissivo;

o con velocità minori di 256 kbit/s possono aversi problemi di jitter (letteralmente: nervosismo; tecnicamente: errore nella base dei tempi, quando un campione digitale è convertito in segnale analogico). Infatti, su reti lente, il ritardo di trasmissione diventa rilevante, e di conseguenza i protocolli di VoIP utilizzano pacchetti più piccoli della dimensione massima (generalmente 1500 bytes, secondo MTU). Altri protocolli basati tipicamente su TCP, usano invece normalmente pacchetti di dimensione massima. Se un pacchetto di una connessione VoIP arriva al commutatore mentre è in trasmissione un pacchetto di dimensione massima appartenente ad un’altra connessione, subirà un ritardo importante, e soprattutto non costante.

La QoS che si può garantire dipende anche dal codec adottato per la trasmissione. La funzione del codec (Coder/Decoder) è di convertire i segnali analogici in digitale e viceversa, affinché il segnale audio sia adatto a viaggiare su reti IP [37] [39]. Quando si vuole implementare un servizio VoIP tale che possa interagire anche con la rete telefonica tradizionale, è necessario adottare nell’implementazione uno o più codec tale che permettano di effettuare uno streaming audio compatibili con la linea analogica. In generale, il discorso si estende quando vogliamo chiamare applicativi che non supportano

84 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

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]:

BIT RATE SAMPLING FRAME SIZE CODEC (Kbps) RATE (KHz) (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.230/34 Tabella 4.1 – Caratteristiche dei codec comunemente usati nelle applicazioni VoIP

85 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

4.4 Soluzioni per il VoIP

Per realizzare delle soluzioni VoIP è chiaro che risulta necessario avere tanto un server proxy, che tenga traccia dei VoIP device/utenti registrati e ne smisti le telefonate (PBX), quanto un “telefono” software (softphone) o hardware (telefono VoIP) a disposizione dell’utente. Di seguito riporteremo una breve analisi delle soluzioni attualmente presenti sul mercato.

4.4.1 Asterisk

Asterisk [37] [39] è un software open-source sviluppato dalla Digium (www.digium.com) in ambiente Linux che permette di realizzare a basso costo una soluzione completa di PBX VoIP, ossia una vera e propria centralina telefonica per uso privato. Il suo nome, Asterisk, proviene dal mondo Unix e Dos dove rappresenta un cosiddetto “carattere jolly” (*), cioè la possibilità di rappresentare ogni file. In modo simile, Asterisk è stato progettato per interfacciare qualsiasi tipo di apparato telefonico standard (sia hardware che software) con qualsiasi applicazione telefonica standard, in modo semplice e consistente. Essendo Asterisk un progetto open-source, esso è rilasciato sotto licenza GNU GPL ed è possibile per tutti accedere al suo contenuto liberamente. Asterisk supporta tre protocolli VoIP: IAX (sviluppato specificatamente per Asterisk stesso), SIP e H.323. In particolare, Asterisk è un sistema ibrido, poiché utilizza sia la tradizionale tecnologia TDM (Time-Division Multiplexing) che i protocolli del packet voice (Voice over IP e Voice over Frame Relay). Esso si comporta come un PBX completo, supportando virtualmente tutte le caratteristiche della chiamata convenzionale. Allo stesso tempo, è un IVR (Interactive Voice Response), cioè offre un servizio di risposta automatico con operatore virtuale, completamente programmabile.

86 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Alla base del funzionamento di Asterisk ci sono i dialplan (ovvero “piano di chiamata”): è la parte più interessante della configurazione di Asterisk, ed anche quella che richiede più tempo. Nel dialplan si definisce cosa deve fare il PBX quando riceve una chiamata, oppure quando un utente compone un numero. Per semplificare la configurazione e la gestione di Asterisk esistono diverse versioni, anche Live CD, che permettono di caricare in un’unica istallazione il sistema operativo e i software necessari, compresa un’interfaccia grafica (GUI Web Oriented), come EasyAsterisk. Inoltre, esistono diversi framework che facilitano l’interazione con Asterisk, soprattutto dal punto di vista amministrativo.

In tal ambito si colloca Asterisk-Java. Si tratta di un progetto, attualmente alla release 0.3, orientato allo sviluppo di un framework Java utile per dar vita ad applicazioni in grado di interagire con Asterisk. L’interazione avviene grazie al supporto delle interfacce Manager API e FastAGI. In pratica, Asterisk-Java propone un set di classi Java per sfruttare API in grado di impartire dei comandi ad Asterisk o di conoscere gli eventi generati dal PBX open-source. Inoltre è possibile utilizzare un canale di comunicazione TCP/IP per operare il controllo remoto del centralino software tramite la Asterisk Gateway Interface (AGI), di cui il progetto offre una implementazione in Java e un tutorial sufficientemente esaustivo.

4.4.2 sipXpbx

Il software sipXpbx è un progetto open-source sviluppato dalla Sipfoundry (http://www.sipfoundry.org/) con l’appoggio della Pingtel (http://www.pingtel.com/). La gestione evolutiva del software è affidata ad una comunità attiva. Il software anche in questo caso implementa le funzionalità di un SIP proxy server. Oltre alle classiche funzioni legate al SIP server, come l’inoltro delle chiamate e la registrazione degli utenti SipX, offre delle funzionalità avanzate come Voice-mail, Call Park e IVR. Tramite un’interfaccia Web è possibile provvedere alla configurazione di tutti i servizi. Il software è scritto in linguaggio C/C++ ed è composto da tre moduli principali:

87 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

o sipX Communications Server: offre i servizi SIP base, ovvero proxy server, redirect e register;

o sipX Media Server: offre i servizi avanzati come IVR e Voice mail; o sipX Configuration Server: permette la configurazione del Media Server. Inoltre questi tre moduli si appoggiano a delle librerie che sono distribuite separatamente, in particolare SipXtacklib che implementa le istruzioni base per l’instaurazione e la gestione delle chiamate. Ad esempio, è possibile partendo da questa libreria implementare un User Agent Client. Il server può essere statefull o stateless rispetto alle transizioni, rispetto ai dialoghi solo stateless. Il software fornisce delle SOAP API per quanto riguarda la configurazione del Communication server e del Media Server. Nel caso della funzione statefull abilitata, esiste un file di log degli stati. Non c’è la possibilità di inviare questa informazione tramite porta TCP, come avviene per Asterisk. Per implementare funzioni di questo genere è necessario implementarle utilizzando le librerie a disposizione.

4.4.3 Jabber/XMPP: Openfire, Spark e Asterisk-IM

Jabber è una piattaforma di messagistica istantanea open-source, basata sul protocollo XMPP (un’estensione del protocollo XML). Offre numerosi servizi nel campo della messagistica come: la chat fra due o più persone, la possibilità di conoscere la presenza in rete di qualcuno (e-presence). Non è un client multi-protocollo, ma molti server Jabber funzionano come gateways per i servizi di IM. La comunità di Jabber è concentrata nella costruzione di una vera alternativa agli altri servizi di IM, proponendo agli utenti che lo utilizzeranno la possibilità di:

o avere un software open-source; o poter creare una rete Jabber privata (dietro a un firewall) o una rete globale e pubblica;

o comunicare con client di altre reti, come se questi fossero utenti Jabber.

88 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Un’implementazione open-source del protocollo Jabber è OpenFire Server, molto semplice da installare e amministrare. Usando il client IM/VoIP Spark, realizzato dalla stessa comunità di Openfire (http://www.igniterealtime.org/), si possono effettuare telefonate VOIP PC-to-PC. Anche Spark è un progetto Java open-source, esso provvede ad impacchettare l’audio in un formato coerente con il protocollo XMPP e inoltrarlo al server Openfire, il quale smisterà i pacchetti verso la giusta destinazione, garantendo il real-time. In seno alla stessa comunità è nato Asterisk-IM (componente di integrazione con Asterisk per Jive’s Jabber/XMPP server); esso è un modulo lato server che permette di lavorare con qualsiasi client che usi il protocollo XMPP integrando le funzionalità di e-presence tipiche dell’Instant Messaging e l’attività PBX di un server Asterisk. In pratica, grazie al plug-in Asterisk-IM, si associa ad un utente registrato presso il server Jabber un device VoIP che l’utente IM potrà utilizzare per effettuare le sue chiamate.

4.4.4 MjSIP e altre soluzioni open-source Java

Riportiamo di seguito alcune soluzioni open-source Java per il VoIP. Tutte le soluzioni sono pensate per macchine desktop. Studieremo la possibilità di adattare almeno una di queste soluzioni ai dispositivi mobili.

MjSip (http://www.mjsip.org/) è un progetto open-source di un SIP stack, realizzato completamente in Java dall’Università di Parma e dall’Università “Tor Vergata” di Roma. Questo progetto include le API complete per creare un’applicazione VoIP, basata su protocollo SIP e RTP. Comprende anche l’implementazione di diversi codec, tra cui G.711 e PCMU. MjSIP include tutte le classi e i metodi per creare applicazioni basate su SIP. Esso implementa i livelli dell’architettura SIP Stack come definito nella specifica RFC 3261 ed è totalmente conforme allo standard.

89 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

In più, include l’implementazione di un’interfaccia per il controllo delle chiamate e di User Agent. MjSIP può essere scaricato dal sito di riferimento e comprende, oltre a quanto già detto, un proxy server fedele al MjSIP Stack. MjSIP fornisce anche il servizio di IM. Il progetto al momento sembra sospeso; tra le specifiche dello stesso, sembrano esserci anche le funzioni tipiche della videochiamata.

Del progetto ne esiste anche una corrispondente versioni J2ME per l’IM.

SIP Communicator (http://www.sip-communicator.org/) è un telefono audio/video via Internet e un instant messanger scritto in Java, in grado di supportare alcuni dei più popolari protocolli per IM e per il VoIP come SIP, IAX, Jabber, AIM/ICQ, MSN e altri come Yahoo e IRC. Il progetto è in pieno sviluppo. La comunità sembra non aver contemplato l’idea di

un’analoga soluzione per il mobile. La comunità OITOS (http://www.oitos.it/) ha fatto una valutazione del prodotto secondo la quale SIP Communicator sembra ancora essere lontano da una soluzione ideale.

Jeti (http://jeti.sourceforge.net/) è un progetto Java nato come client Jabber. Esso supporta le principali funzionalità di chat tra cui il trasferimento file, group chat, emoticons e la formattazione dei messaggi. Può essere usato come applicativo o come Web applet. Per Jeti esistono numerosi plug-in, tra cui Jingle che aggiunge al progetto la funzione di

client VoIP. Attualmente, nella versione beta, è stato rilasciato JetiVoip. Come SIP Communicator, Jeti include i codec jSpeex, ovvero un’implementazione Java del codec Speex.

4.4.5 Soluzioni e client VoIP per il Mobile

Riportiamo di seguito una panoramica sulle soluzioni più conosciute per il mobile VoIP.

90 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Skype (http://www.skype.com/) è un protocollo chiuso che realizza la fonia VoIP. L’omonimo programma, già disponibile da tempo per diversi sistemi operativi, è anche disponibile per PocketPC (Windows Mobile). Dietro l’acquisto di un credito, Skype permette di chiamare in oltre trenta paesi del mondo a tariffe vantaggiose, oltre che parlare gratis tra gli utenti Skype nazionali. Skype supporta anche l’Instant Messaging, fino ad un gruppo chat di cento persone, e le videochiamate.

iSkoot (http://www.iskoot.com/) è un software che consente di collegare il proprio telefono cellulare a Skype in modo da poter chiamare sfruttando la tecnologia VoIP. iSkoot, disponibile a pagamento solo per Windows Mobile, permette di:

o inoltrare le chiamate dal PC al telefono cellulare; o chiamare i propri contatti dal telefono cellulare o “spostare” una chiamata dal PC al telefono senza disconnettersi. Per realizzare questo è necessario ovviamente lasciare il PC acceso, collegato ad Internet e avere Skype in esecuzione.

Da quando Palm, azienda specializzata nella produzione di palmari, ha introdo il Wi-Fi nel proprio mondo, sono nate anche soluzioni VoIP per PalmOS, il sistema operativo distribuito dalla Palm. La software house MantraGroup, specializzata in soluzioni wireless

per computer palmari, ha realizzato mobiVoIP (http://www.mobivoip.net/), la prima

soluzione VoIP specificamente indirizzata ai palmari e agli smartphone basati su PalmOS. I requisiti per usare mobiVoIP sono, ovviamente, un dispositivo basato su PalmOS in grado di connettersi a Internet via Bluetooth, Wi-Fi o EV-DO. Gli utenti di mobiVoIP potranno chiamare qualunque utente mobiVoIP o un qualsiasi telefono fisso direttamente dal PDA. La tariffazione è basata su un abbonamento mensile con diversi piani tariffari pensati per il Nord America e altri paesi, tra cui l’Italia.

91 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Fring (http://www.fring.com/) è l’unica soluzione VoIP-IM per cellulari che non sfrutti qualche forma di callback per offrire chiamate verso utenti. Fring sfrutta un protocollo proprietario con cui trasporta la chiamata dal client installato sul cellulare ai server Fring, da cui poi viene convertita per collegarsi alla rete Skype, Gtalk o PSTN. Fring è disponibile per Symbian OS e Windows Mobile.

Il servizio Gizmo dedicato al mondo dei dispositivi portatili è Gizmo5 (http://gizmo5.com/), un software Java che integra diversi servizi:

o chiamate VoIP verso chiunque, utilizzando il credito del proprio account Gizmo; o chat con gli utenti dei servizi Gizmo, MSN, AIM, Yahoo e Jabber, tra cui GTalk; o verificare la presenza online dei propri contatti; o inviare e ricevere file, anche tra PC e telefono cellulare. Molto interessante la possibilità di aggiungere come contatto una URI Sip, per poter chiamare numerazioni IP gratuitamente dal proprio telefono cellulare.

SJphone (http://www.sjlabs.com/) è uno dei software VoIP più noti ed utilizzati, in particolare è spesso offerto in combinazione con i servizi dei maggiori operatori VoIP. E’ disponibile per i sistemi PDA dotati di PocketPC 2002/2003/2003SE, Windows CE.NET 4.0/4.2/5.0, Windows Mobile 5.0. SJphone è compatibile con i due principali standard di segnalazione delle chiamate, SIP e H.323 e funziona quindi con moltissimi operatori VoIP e sistemi IP-PBX. E’ possibile

configurare diversi “servizi” (solitamente legati alla scelta di un operatore) e passare in modo semplice da uno all’altro. I codec disponibili per la trasmissione del segnale vocale sono G.711 A/u, GSM, Speex e iLBC.

Minisip (http://www.minisip.org/) è un framework SIP open-source sviluppato durante una tesi di laurea in Svezia. Supporta voce, video e IM. E’ cross platform e compila anche su Linux IPAQ e presto sarà disponibile per Windows Mobile.

92 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Minisip effettua le caratteristiche supplementari di sicurezza quali l’autenticazione, la crittografia e l’integrità reciproche delle chiamate on-going e la crittografia della segnalazione (SIP sopra TLS, lo standard IETF di SSL).

Passiamo ora al progetto del nostro componente VoIP da integrare nel framework descritto nel capitolo precedente.

4.5 Progetto del componente VoIP

Nella fase di analisi e nelle varie fasi della progettazione del componente VoIP ci serviremo dei diagrammi UML.

4.5.1 Analisi dei requisiti

Nella fase di Analisi dei Requisiti vengono individuati e rappresentati i requisiti del servizio ed evidenziate le funzionalità del servizio stesso. Il prodotto della fase di analisi è il seguente Diagramma dei Casi d’uso (Figura 4.5).

Lista degli attori UtenteGenerico: Rappresenta un utente non ancora registrato, privo di account SIP. UtenteRegistrato: Rappresenta un utente registrato, avente un account SIP.

Lista dei casi d’uso

Registrazione

Login

EffettuaChiamata

AccettaChiamata

TerminaChiamata

Logout

Cancellazione

93 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Registrazione

Login

UtenteGenerico EffettuaChiamata

AccettaChiamata

UtenteRegistrato

TerminaChiamata

Cancellazione

Logout

Figura 4.5 - Diagramma dei Casi d’uso

Riportiamo la descrizione dei casi d’uso presenti nel diagramma. Per facilitarne sia la descrizione che la comprensione, adotteremo una terminologia SIP compliant, supponendo di aver adottato il protocollo SIP per il controllo della chiamata.

Caso d’uso Registrazione

Nome: Registrazione

Descrizione: Consente la registrazione di un nuovo utente.

Passi del caso d’uso Registrazione:

1. L’UtenteGenerico fornisce i suoi dati personali (nome, cognome, email) al SIP server presso cui vuole registrarsi (realm);

2. Il SIP server fornisce all’utente lo username e la password (SipURL = username@realm);

3. Qualora lo preveda, il server può fornire all’utente registrato un numero geografico (geoNumber) su cui può essere raggiunto dalla rete telefonica tradizionale.

94 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Estensione del caso d’uso Registrazione:

2. Utente già registrato 2.a Ritorno al punto 1

Caso d’uso Login

Nome: Login

Descrizione: Consente l’autenticazione dell’utente presso in SIP server remoto.

Un utente può avere più account SIP: i dati essenziali di ciascun account SIP sono username, password, realm. Il metodo Login verifica la validità dei dati.

Passi del caso d’uso Login:

1. L’UtenteRegistrato fornisce i dati relativi al suo account (username, password, realm);

2. Il SIP server apre una sessione con l’utente autenticato e attiva lo User Agent (UA);

3. L’utente autenticato può accedere alla lista personale utenti.

Estensione del caso d’uso Login:

2. Dati non corretti

2.a Ritorno al punto 1

Precondizione per il caso d’uso Login:

L’UtenteRegistrato deve essere registrato presso il SIP server (realm).

Caso d’uso EffettuaChiamata

Nome: EffettuaChiamata

Descrizione: Consente ad un utente, autenticato presso un SIP server remoto, di effettuare una telefonata VoIP.

95 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Passi del caso d’uso EffettuaChiamata:

1. L’UtenteRegistrato chiede di effettuare una telefonata;

2. Lo stato della chiamata del chiamante passa nello stato OUTGOING_CALL;

3. L’UA dell’utente chiamato accetta la sessione del chiamante;

4. Lo stato del chiamato diventa INCOMING_CALL.

Estensione del caso d’uso EffettuaChiamata: 2. L’utente chiamato non è connesso/non esiste/è occupato in altra conversazione 2.a Il SIP server restituisce al chiamante un messaggio di CANCEL

3. L’utente chiamato rifiuta/non accetta la chiamata (caso d’uso TerminaChiamata) 3.a Il SIP server inoltra il messaggio di BYE all’UA chiamante

4. L’utente chiamante ha chiuso la chiamata 4.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE

Precondizione per il caso d’uso EffettuaChiamata:

L’UtenteRegistrato deve essere autenticato presso il SIP server remoto.

Lo stato della chiamata deve essere IDLE.

Nei casi di estensione 2-3 si noti che, qualora il SIP server lo preveda, può essere attivato, a seguito del messaggio di CANCEL, il servizio di segreteria telefonica.

Caso d’uso AccettaChiamata

Nome: AccettaChiamata

Descrizione: Consente all’utente chiamato di accettare una telefonata in arrivo.

Passi del caso d’uso AccettaChiamata:

1. L’utente accetta una telefonata in arrivo;

96 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

2. Lo stato della chiamata, sia del chiamato che del chiamante, diventa ONCALL; 3. I due utenti possono parlare.

Estensione del caso d’uso AccettaChiamata: 2. L’utente chiamante ha chiuso la chiamata 2.a Il SIP server restituisce al chiamato un messaggio di CANCEL/BYE

Precondizione per il caso d’uso AccettaChiamata:

La chiamata del chiamato deve essere nello stato INCOMING_CALL

Caso d’uso TerminaChiamata

Nome: TerminaChiamata

Descrizione: Consente di terminare una chiamata.

Passi del caso d’uso TerminaChiamata:

1. L’UtenteRegistrato termina la chiamata;

2. La chiamata torna nello stato IDLE.

Precondizione per il caso d’uso TerminaChiamata:

La chiamata deve essere in uno stato diverso da IDLE.

Caso d’uso Logout

Nome: Logout

Descrizione: Consente di disconnettersi dal SIP server remoto.

Passi del caso d’uso Logout:

1. L’UtenteRegistrato chiede di disconnettersi; 2. Viene chiusa un’eventuale chiamata che non sia in stato IDLE; 3. L’UtenteRegistrato risulta disconnesso.

97 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Precondizione per il caso d’uso Logout:

L’UtenteRegistrato deve essere connesso.

Caso d’uso Cancellazione

Nome: Cancellazione

Descrizione: Consente di cancellare un utente registrato dal SIP server.

Passi del caso d’uso Registrazione:

1. L’UtenteRegistrato fornisce il suo username e la password al SIP server (realm) presso cui è registrato;

2. Il SIP server comunica l’avvenuta cancellazione.

Estensione del caso d’uso Registrazione:

2. Utente non registrato 2.a Ritorno al punto 1

4.5.2 La fase di progettazione

Iniziamo qui la fase di progettazione del componente VoIP. Tramite il Diagramma di Distribuzione (Figura 4.6) andiamo a mostrare qual è l’environement in cui si troverà ad operare. L’obiettivo è far risiedere il componente sul dispositivo mobile. Esso interagirà con un server remoto di cui utilizzerà i servizi; nella progettazione che segue, supponiamo che il server sia SIP compliant, compatibilmente a quanto assunto in precedenza per i casi d’uso. Il componente VoIP che svilupperemo fa parte del framework di servizi presentato nel capitolo precedente. Accederemo al framework, e in particolare al servizio VoIP, tramite un client VoIP che potrà essere implementato non necessariamente in Java, bensì, per esempio, in C#, secondo il requisito richiesto di trasparenza al linguaggio. Passiamo ora alla vista delle classi che compongono i package coinvolti.

98 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

VoIP client VoIP client VoIP client

Framework Framework Framework

Componente VoIP Componente VoIP Componente VoIP

mobile device A mobile device B mobile device C

SIP SIPServer server

Figura 4.6 - Diagramma di Distribuzione

Package VoIPComponent A partire dal diagramma dei casi d’uso, l’interfaccia dei metodi per il nostro componente VoIP sarà la seguente (Figura 4.7):

InterfacciaVoIPComponent

+ registrazione (UtenteGenerico utenteGenerico, String realm) : UtenteRegistrato + cancellazione (String username, String password, String realm) : void + login (String username, String password, String realm) : void + logout () : void + effettuaChiamata (String targetSipURL) : void + accettaChiamata () : void + terminaChiamata () : void Figura 4.7 - Interfaccia dei metodi esposti dal componente VoIP

Tale interfaccia, attraverso il framework, permetterà alle applicazioni utente (in particolare ad un client VoIP) di accedere ai metodi in essa elencati, progettati e sviluppati, sulla base del seguente Diagramma delle Classi (Figura 4.8):

99 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

UtenteGenerico Direttorio

- nome : String 1..* 1..1 - cognome : String + registrazione (UtenteGenerico utenteGenerico, String realm) : UtenteRegistrato - email : String + cancellazione (String username, String password, String realm) : void + se t () : void + get () : void

UtenteRegistrato UserAgent 0..1 - username : String - password : String 1..1 - gestioneEventi () : void - realm : String + login (String username, String password, String realm) : void - geoNumber : String + logout () : void

1..1 1..1

Chiamata 1..1 1..1

- statoChiamata : int Trasporto Sessione + effettuaChiamata (String targetSipURL) : void + accettaChiamata () : void + terminaChiamata () : void + apriCanale () : void + apriSessione () : void - cambiaStato () : void + chiudiCanale () : void + chiudiSessione () : void

Figura 4.8 - Diagramma delle Classi del componente VoIP

Il package VoIPComponent rappresenta il cuore del componente stesso, distribuito all’interno del framework su dispositivi mobili. E’ formato da diverse classi di cui daremo di seguito una breve descrizione.

Classe UtenteGenerico: tale classe rappresenta un utente non ancora registrato al SIP server, privo di account; non è l’altro che l’attore che compare nel diagramma dei casi d’uso del paragrafo precedente.

Classe UtenteRegistrato: tale classe rappresenta, invece, un utente già registrato con un proprio account; è una specializzazione della classe precedente di cui eredita gli attributi. Gli attributi username, password e realm, specifici di questa classe, servono proprio per fornire un account unico all’utente registrato. Lo username in particolare sarà parte del SipURL insieme con realm, che indica l’IP (in alcuni casi include anche la porta di ascolto) del SIP server. Un utente può avere più account, anche presso SIP server diversi. Questa classe non è altro che l’attore che compare nel diagramma dei casi d’uso del paragrafo precedente. L’attributo geoNumber identifica il numero geografico con cui un

100 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

utente registrato, presso il SIP server, può essere telefonato dalla rete telefonica tradizionale.

Classe Direttorio: è una classe priva di attributi; essa realizza alcuni metodi necessari per offrire al utente determinate funzionalità, presenti anche nel diagramma dei casi d’uso, come la registrazione.

Classe UserAgent: serve per aprire o chiudere una connessione con il SIP server, senza necessariamente avviare una telefonata con qualche utente. La classe si mette in ascolto di eventuali telefonate in arrivo e, in generale, si occupa di catturare gli eventi, oltre che di tener traccia e gestire gli stati della telefonata.

Classe Sessione: rappresenta i metodi base del protocollo SIP; la composizione che lega questa classe allo User Agent deriva dal fatto che, nel momento in cui viene allocato lo User Agent, esso apre subito una sessione verso il SIP server.

Classe Trasporto: rappresenta i metodi base del protocollo di trasporto real-time e per la gestione del canale audio. Tale classe interviene nel momento in cui la telefonata deve essere instaurata e durante il corso della stessa.

Classe Chiamata: rappresenta la telefonata che si instaura fra due client. Essa è caratterizzata da uno stato ed è gestita dalla classe UserAgent.

Package SIPServer Dal punto di vista della nostra progettazione il SIP server è una black box a cui accediamo tramite i servizi che un SIP server generalmente espone. Mostriamo di seguito la generica interfaccia di un SIP server (Figura 4.9):

101 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

InterfacciaSIPServer

+ registrazione (UtenteGenerico utenteGenerico) : UtenteRegistrato + cancellazione (String username, String password) : void + gestioneEventiSIP () : void Figura 4.9 - Interfaccia dei metodi offerti dal SIP server

Secondo quanto mostrato nel diagramma di distribuzione, scendiamo ora nel dettaglio, mostrando l’architettura e l’interazione tra tutti i package coinvolti nel caso del servizio VoIP. Un client VoIP, più in generale un’applicazione utente, che voglia usare il componente VoIP, potrà accedervi grazie al Framework Core che aggiunge all’interfaccia del componente i requisiti non funzionali già descritti nel precedente capitolo (Figura 4.10).

Passiamo al Diagramma di Sequenza (Figura 4.11) dove si suppone che i due utenti (utenteRegistratoA e utenteRegistratoB) siano registrati presso un SIP server. Presentiamo l’esecuzione dei seguenti casi d’uso, così come ordinati sulla linea del tempo:

o Login, che termina con successo, dell’utenteRegistratoA; o EffettuaChiamata: l’utenteRegistratoA effettua una chiamata verso l’utenteRegistratoB;

o AccettaChiamata: il destinatario accetta la chiamata e inizia la conversazione; o TerminaChiamata: l’utenteRegistratoA decide di terminare la chiamata e il protocollo SIP garantisce che la chiamata sia chiusa anche per l’utenteRegistratoB;

o Logout: l’utenteRegistratoA effettua il logout.

Si noti come, in ciascun scenario, al Framework Core sia demandato di filtrare ogni tipo di messaggio o richiesta proveniente dall’applicazione utente o, dall’interno, da una delle classi del componente VoIP, ovvero UserAgent e Chiamata.

102 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Applicazione utente

Client VoIP

Framework Core

InterfacciaVoIPComponent

+ registrazione (UtenteGenerico utenteGenerico, String realm) : UtenteRegistrato + cancellazioneFramework (String username, Core String password, String realm) : void + login (String username, String password, String realm) : void + logout () : void + effettuaChiamata (String targetSipURL) : void + accettaChiamata () : void + terminaChiamata () : void

Package VoIPComponent

UtenteGenerico Direttorio - nome : String 1..* 1..1 - cognome : String + registrazione (UtenteGenerico utenteGenerico, String realm) : UtenteRegistrato - email : String + cancellazione (String username, String password, String realm) : void + se t () : void + get () : void

UtenteRegistrato UserAgent 0..1 - username : String - password : String 1..1 - gestioneEventi () : void - realm : String + login (String username, String password, String realm) : void - geoNumber : String + logout () : void

1..1 1..1

Chiamata 1..1 1..1

- statoChiamata : int Trasporto Sessione + effettuaChiamata (String targetSipURL) : void + accettaChiamata () : void + terminaChiamata () : void + apriCanale () : void + apriSessione () : void - cambiaStato () : void + chiudiCanale () : void + chiudiSessione () : void

InterfacciaSIPServer

+ registrazione (UtenteGenerico utenteGenerico) : UtenteRegistrato + cancellazione (String username, String password) : void + gestioneEventiSIP () : void

SIPServer

Figura 4.10 - Vista completa del diagramma delle classi

103 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

FrameworkCoreA Chiamata A User Agent A SIP server User Agent B Chiamata B FrameworkCoreB

utenteRegistratoA utenteRegistratoB login REGISTER

ACK

effettuaChiamata a p ri Se ssi o n e INVITE

INVITE

TRYING cambiaStato

a p ri S e ssi o n e RINGING cambiaStato gestioneEventi

accettaChiamata

cambiaStato apriCanale ACK invite cambiaStato

apriCanale

gestioneEventi

terminaChiamata BYE/CANCEL cambiaStato

gestioneEventi

chiudiCanale

ch i u d i S e ssi o n e ACK bye/cancel

cambiaStato

chiudiCanale

chiudiSessione

gestioneEventi

logout BYE

ACK

Figura 4.11 - Diagramma di Sequenza per i metodi: login, effettuaChiamata, accettaChiamata, terminaChiamata e logout

4.5.3 Test Case

Vengono presentati i Test case relativi alle funzionalità offerte dal componente VoIP, ovvero dall’interfaccia del package VoIPComponent (InterfacciaVoIPComponent).

104 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Lista dei metodi

Registrazione

Cancellazione

Login

Logout

EffettuaChiamata

AccettaChiamata

TerminaChiamata

Test case per metodo Registrazione Descrizione metodo registrazione: Il metodo riceve in ingresso da un oggetto di classe UtenteGenerico i dati nome, cognome, email, realm. Fa un controllo su quest’ultimi e restituisce un oggetto di classe UtenteRegistrato.

Precondizione: Utente non registrato. Postcondizione: Utente registrato.

Output Test Case Input Output atteso ottenuto

nome, cognome, e-mail, username, password, realm TC 1 realm (SipURL: username@realm); (dati corretti) numero geografico (opzionale)

nome, cognome, e-mail, TC 2 realm Nessun nuovo account SIP (dati errati)

Nota: l’utente può registrarsi presso un server realm una sola volta; l’indirizzo e-mail garantisce l’univocità. Per dati errati contempliamo i seguenti casi: - l’utente ha provato a registrarsi presso un realm non valido; - l’utente ha provato a registrare la stessa email più di una volta presso lo stesso realm.

105 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Test case per metodo Cancellazione Descrizione metodo cancellazione: Il metodo permette ad un UtenteRegistrato di cancellare il proprio profilo SIP dal dialplan del server realm.

Precondizione: Utente registrato. Postcondizione: Utente non registrato.

Output Test Case Input Output atteso ottenuto username, password, realm TC 3 UtenteRegistrato cancellato (dati presenti presso il server realm) username, password, realm TC 4 UtenteRegistrato non cancellato (dati non presenti presso il server realm)

Test case per metodo Login Descrizione metodo Login: Il metodo viene invocato da un oggetto di classe UtenteRegistrato. Il metodo Login verifica, presso il server realm, la validità dei dati username e password che gli vengono forniti.

Precondizione: Utente registrato. Postcondizione: Utente connesso con chiamata inattiva (stato IDLE).

Output Test Case Input Output atteso ottenuto username, password, UA: Registrazione riuscita: TC 5 realm 200 OK (dati corretti) username, password, realm TC 6 UA: Registrazione fallita: (username e password 401 Unauthorized non corretti) username, password, UA: Registrazione fallita: TC 7 realm Timeout (realm non corretto)

106 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Test case per metodo Logout Descrizione metodo Logout: Il metodo viene invocato da un oggetto di classe UtenteRegistrato per chiudere la sessione. Il metodo chiude la sessione e la chiamata eventualmente in corso.

Precondizione: Utente connesso. Postcondizione: Utente disconnesso.

Output Test Case Input Output atteso ottenuto

TC 8 Richiesta disconnessione Disconnessione

Test case per metodo EffettuaChiamata Descrizione metodo EffettuaChiamata: Il metodo viene invocato da un oggetto di classe UtenteRegistrato per avviare una chiamata.

Precondizione: Utente connesso con chiamata inattiva (stato IDLE). Postcondizione: Utente connesso con una chiamata in uscita (stato OUTGOING_CALL).

Output Test Case Input Output atteso ottenuto Richiesta di chiamata a username@realm TC 9 Chiamata username@realm (username@realm valido e SQUILLANDO… libero) Richiesta di chiamata a username@realm TC 10 UA: REFUSED (Does Not (username non presente su Exist Anywhere) realm) Richiesta di chiamata a username@realm TC 11 UA: NON TROVATO/TIMEOUT (username@realm occupato o realm non trovato)

107 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Test case per metodo AccettaChiamata Descrizione metodo AccettaChiamata: Il metodo viene invocato da un oggetto di classe UtenteRegistrato per accettare una chiamata in arrivo.

Precondizione: Utente connesso con una chiamata in arrivo (stato INCOMING_CALL). Postcondizione: Utente connesso con una chiamata in corso (stato ONCALL).

Output Test Case Input Output atteso ottenuto Accetta chiamata UA: CONFERMATA/CHIAMATA TC 12 UA: chiamata in AudioLauncher: apertura ingresso audio java..... calee@realm

Test case per metodo TerminaChiamata Descrizione metodo TerminaChiamata: Il metodo permette prima di terminare una chiamata in corso oppure rifiutare una chiamata in arrivo.

Precondizione: Utente connesso con una chiamata attiva (non stato IDLE). Postcondizione: Utente connesso con una chiamata inattiva (stato IDLE).

Output Test Case Input Output atteso ottenuto UA: CHIUSA TC 13 Termina chiamata AudioLauncher: chiusura audio java...

108 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

4.6 Nota implementativa

Tra le varie soluzioni esistenti per il VoIP, prendiamo il considerazione il progetto MjSIP dell’Università di Parma, rispondente ai requisiti richiesti per il framework. Oltre che essere un progetto Java open-source, esso è pienamente compliant con la progettazione esposta nel paragrafo precedente, a meno di alcune scelte implementative. Riportiamo di seguito il lavoro compiuto per adattare il progetto esistente per macchine desktop MjSIP su un dispositivo mobile, in particolare su un palmare HP iPAQ con sistema operativo Windows Mobile 5.0.

4.6.1 Mysaifu JVM

Il primo passo da compiere è trovare una JVM per Windows Mobile tale che sia adatta alla Configuration CDC del nostro palmare. Tra le JVM per dispositivi mobili, ci è sembrato opportuno adottare Mysaifu JVM. Si tratta di un progetto free sotto licenza GPLv2 che risale all’aprile 2005 e ancora in evoluzione, anche se l’ultima release risale al dicembre 2006.

L’ultima release disponibile è compatibile con i seguenti sistemi operativi:

o Windows Mobile 5.0; o Windows Mobile 2003 SE (PocketPC 2003 SE); o Windows Mobile 2003 (PocketPC 2003).

L’installazione di Mysaifu sul palmare è molto semplice. E’ possibile eseguire la JVM Mysaifu come applicazione in background o per eseguire una specifica applicazione Java. Mysaifu è una JVM compliant con la J2SE 1.3. In particolare, essa comprende la quasi totalità delle librerie grafiche AWT e alcuni package della libreria SWING. Mysaifu JVM, quindi, è Personal Basis Profile compliant; inoltre presenta numerosi package opzionali, tra cui facciamo notare il package javax.sound.sampled necessario ai fini della realizzazione di un componente come il

109 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

nostro, destinato a manipolare streaming audio. Tale package provvede a fornire le interfacce e i metodi per registrare, manipolare e ascoltare dati di tipo audio. In particolare, il package javax.sound.sampled non risulta completo, infatti non supporta tutti i codec presenti nella corrispondente versione per macchine desktop. Lo stesso autore di Mysaifu sul sito di riferimento annuncia, nel marzo 2006, che la JVM, a partire dalla release 0.2.2, supporta la classe javax.sound.sampled, tuttavia gli unici codec supportati restano i PCM (signed) e PCMU (unsigned). Da allora ad oggi, non vi sono aggiornamenti in proposito. Conferma di quanto detto viene dal deploy dell’applicazione MjSIP originale sul palmare: l’applicativo funziona perfettamente finchè lo User Agent non instaura un canale di streaming audio, ovvero quando inzia una chiamata, dando luogo ad un’eccezione. Per effettuare uno streaming audio VoIP è necessario avere a disposizione il codec G711 (noto anche come formato Alaw/ulaw), che Mysaifu non riconosce. Dovremo lavorare con i codec cosiddetti lineari, ovvero PCM, rinunciando alla possibilità di instaurare chiamate verso la rete telefonica tradizionale.

4.6.2 “MjSIP mobile”: studio di fattibilità

Approfondendo lo studio del progetto MjSIP, dal codice emerge la sua organizzazione in due macro-package, ciascuno dei quali a sua volta contiene altri package:

o org.zoolu è il package che implementa il SIP stack. E’ responsabile della creazione e della gestione della connessione al provider SIP, dell’autenticazione, della sessione SIP, della gestione dei messaggi SIP, della chiamata e del dialogo;

o local è un package, decisamente più piccolo del precedente, contente i seguenti package: - local.net: implementa il protocollo RTP come estensione del protocollo UDP; - local.ua: implementa lo User Agent (client e server);

110 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

- local.media: gestisce la parte multimediale della conversazione, ovvero lo streaming audio e video. In esso è implementata anche la classe G711.java che gestisce il codec omonimo, ovvero Alaw/ulaw.

Riguardo quest’ultimo package, possiamo affermare che la sua implementazione è stata lasciata in sospeso dagli autori. Infatti, le classi relative al codec G711 e allo streaming video sembrano proprie del progetto iniziale degli autori, i quali le hanno lasciate incomplete e inutilizzate nell’ambito nel progetto VoIP. Le stesse classi di esempio – grafica e testuale – forniscono il tipico funzionamento della chiamata VoIP e non della video-chiamata.

Il lavoro svolto per adattare il progetto MjSIP alla Mysaifu JVM, istallata su PocketPC Windows Mobile, è concentrato soprattutto sul package local.media. Precisamente le classi che abbiamo reimplementato sono:

o AudioInput.java, riconosce lo streaming audio proveniente dalle rete IP e ne effettua la riproduzione;

o AudioOutput.java, inoltra verso la rete IP lo streaming audio riconosciuto dal microfono;

o RtpStreamReceiver.java, gestisce lo streaming RTP in ingresso; o RtpStreamSender.java, gestisce lo streaming RTP in uscita.

Come si può intuire, la struttura delle classi sopra riportate risulta duale a coppie. In particolare, le ultime due classi costituiscono dei threads durante tutto il periodo di una chiamata. È compito della classe local.ua.JAudioLauncher.java istanziare e gestire i due threads sulla base dello stato della chiamata. Per garantire la fattibilità di MjSIP mobile dobbiamo superare i limiti legati alla JVM: Mysaifu non supporta la conversione di formato audio, necessaria affinchè si possa gestire uno streaming audio in formato Alaw/ulaw.

111 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

La soluzione è apportare le opportune modifiche alle quattro classi sopra menzionate, affinché il formato audio trattato sia esclusivamente PCM; possiamo così evitare la conversione di formato audio.

Tali modifiche ci inducono anche a reimplementare le classi delegate per la gestione dello streaming RTP in modo tale che siano in grado di trattare uno streaming audio PCM. Useremo il package local.net per implementare nuovamente le classi RtpStreamSender.java e RtpStreamReceiver.java. L’idea di base è creare in ciascun delle due classi un buffer di byte. Tale buffer costituirà il pacchetto RTP che viaggerà sulla rete durante una chiamata. RtpStreamSender registrerà in tale buffer l’audio ricevuto dal microfono e lo inoltrerà verso la rete, mentre RtpStreamReceiver effettuerà la riproduzione dell’audio contenuto nel buffer. La gestione tramite threads, nell’invio quanto nella ricezione di tali pacchetti, ne garantirà il flusso continuo, ovvero lo streaming audio. Si noti che la dimensione del buffer in questione può essere impostata per migliorare la qualità dello streaming, ma dovrà rispettare i vincoli imposti dall’MTU per la rete Internet. In particolare, essendo l’header di un pacchetto RTP pari a 12 byte, il payload audio non potrà superare la dimensione di 1488 byte.

4.6.3 Implementazione

Facendo riferimento al diagramma dei casi d’uso e al diagramma delle classi, di seguito riportiamo lo pseudocodice relativo al componente VoIP, realizzato secondo quanto discusso in precedenza:

Classe VoIPComp.java

/* login: prende in ingresso il file account di cui effettua il parsing */ public void login(String file){ if(ua != null) ua.sip_provider.halt(); this.ra = null; this.ua = null;

112 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

/* dichiarazione delle variabili necessarie per il parsing del file account […] […]*/

SipStack.init(file);

SipProvider sip_provider;

if (file != null) sip_provider = new SipProvider(file); else sip_provider = new SipProvider(opt_via_addr,opt_host_port);

if (opt_outbound_proxy != null) sip_provider.setOutboundProxy(new SocketAddress(opt_outbound_proxy));

UserAgentProfile user_profile = new UserAgentProfile(file);

/* imposta i parametri sulla base di quelli letti dal file […] […] */

VoIPclient = new VoIPComp(sip_provider,user_profile); }

/* logout */ public void logout(){ if(ra != null | ua != null){ if (ra.isRegistering()) ra.halt(); ra.unregister(); ua.sip_provider.halt(); } exit(); }

/* accetta chiamate in arrivo */ public void accettaChiamata(){ printOut("accetta"); if (ua.statusIs(UserAgent.UA_INCOMING_CALL)){ ua.accept(); } }

/* termina una chiamata in corso o rifiuta una chiamata in arrivo */ public void terminaChiamata(){ printOut("termina"); if (!ua.statusIs(UserAgent.UA_IDLE)){ ua.hangup(); ua.listen(); } }

/* effettua una nuova chiamata */ public void effettuaChiamata(String target_url){ printOut("effettua"); ua.hangup(); ua.printLog("UAC: CHIAMA " + target_url); if (!ua.user_profile.audio && !ua.user_profile.video) ua.printLog("SOLO SQUILLO, NESSUN AUDIO"); ua.call(target_url);

113 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

}

/* UA in ascolto */ void run(){ /* Controlli sulle proprietà di user_profile […] […] */

listen(); /* Controllo dello stato della chiamata da parte dello UserAgent […] […] */

}

Per una rapida comprensione degli stati e delle relative transizioni, riportiamo il Diagramma degli Stati (Figura 4.12) relativi alla classe Chiamata. Per il significato degli stati, si faccia riferimento alla descrizione dei casi d’uso.

logout

Chiamata in arrivo login IDLE INCOMING CALL

terminaChiamata

accettaChiamata effettuaChiamata

terminaChiamata

terminaChiamata

OUTGOING CALL ONCALL

Chiamata accettata Figura 4.12 - Diagramma degli Stati della classe Chiamata

Come si nota dallo pseudocodice, la classe VoIPComp.java costituisce un wrapper dei metodi offerti dalla classe UserAgent di MjSIP. La classe implementa UserAgentListener, RegisterAgentListener, delegati, rispettivamente, di gestire le chiamate e la registrazione presso un SIP server. Si noti la necessità di registrare periodicamente lo User Agent presso il SIP server.

114 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Lo User Agent è in ascolto degli eventi, gestiti ciascuno attraverso un metodo opportuno, la cui implementazione resta opzionale. Una nota sul metodo di Login: ereditando la filosofia di MjSIP, il metodo riceve in ingresso il nome di un file di testo contente i parametri relativi all’account utente. Il metodo login effettua il parsing di questo file. La classe, così come tutto il progetto, tiene traccia degli eventi in un file di log.

L’obiettivo della progettazione, fin qui seguita, è esporre, attraverso il Framework Core, i metodi del servizio VoIP per consentirne l’uso da parte delle applicazioni utente. Tuttavia il componente riportato è utilizzabile solo come applicazione stand-alone, a causa dei limiti tecnologici dei palmari, che non presentano sufficienti risorse per garantire l’esecuzione, oltre che del servizio VoIP, di un Servlet Container e di un Web Service Container, similmente a Tomcat e Axis in una soluzione nomadica. Sebbene le comunità di sviluppo si stiano dimostrando sensibili alla necessità di portare tali tecnologie sui dispositivi mobili, il limite tecnologico non è stato ancora superato.

4.6.4 Testing

La fase di Testing del componente VoIP è essenzialmente ridotta alla fase di Unit test (o test di unità); l’Integration test (o test di integrazione) è lasciato agli sviluppi futuri, laddove il componente sia integrato nel framework di servizi. Nella fase di Unit Test verifichiamo la validità dei metodi di cui abbiamo progettato i Test case; si noti che supponiamo l’implementazione dei metodi registrazione e cancellazione delegata al componente esterno SIP server (provider). Per implementare i Test case progettati utilizzeremo JUnit (unit test framework per il linguaggio di programmazione Java). Di seguito riportiamo, per ogni Test case, una tabella in cui è indicato il metodo che si sta testando, i dati di input al metodo, l’output atteso e l’output ottenuto.

115 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

TC 1 Metodo testato Input Output atteso Output ottenuto nome, cognome, registrazione e-mail, realm Nuovo account SIP Nuovo account SIP (dati corretti)

TC 2 Metodo testato Input Output atteso Output ottenuto nome, cognome, Nessun nuovo Nessun nuovo registrazione e-mail, realm account SIP account SIP (dati errati)

TC 3 Metodo testato Input Output atteso Output ottenuto username, password, realm UtenteRegistrato UtenteRegistrato cancellazione (dati presenti presso il cancellato cancellato server realm)

TC 4 Metodo testato Input Output atteso Output ottenuto username, password, realm UtenteRegistrato non UtenteRegistrato cancellazione (dati non presenti cancellato non cancellato presso il server realm)

TC 5 Metodo testato Input Output atteso Output ottenuto username, password, UA: UA: Registrazione Registrazione login realm riuscita: riuscita: (dati corretti) 200 OK 200 OK

TC 6 Metodo testato Input Output atteso Output ottenuto username, password, UA: UA: realm Registrazione Registrazione login fallita: fallita: (username, password 401 401 non corretti) Unauthorized Unauthorized

TC 7 Metodo testato Input Output atteso Output ottenuto username, password, UA: UA: Registrazione Registrazione login realm fallita: fallita: (realm non corretto) Timeout Timeout

116 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

TC 8 Metodo testato Input Output atteso Output ottenuto

logout Richiesta disconnessione Disconnessione Disconnessione

TC 9 Metodo testato Input Output atteso Output ottenuto Richiesta di chiamata a username@realm Chiamata Chiamata effettuaChiamata username@realm username@realm (username@realm SQUILLANDO… SQUILLANDO… valido e libero)

TC 10 Metodo testato Input Output atteso Output ottenuto Richiesta di chiamata a UA: REFUSED UA: REFUSED username@realm effettuaChiamata (Does Not (Does Not (username non presente Exist Exist su realm) Anywhere) Anywhere)

TC 11 Metodo testato Input Output atteso Output ottenuto Richiesta di chiamata a username@realm UA: NON UA: NON effettuaChiamata (username@realm TROVATO/TIMEOUT TROVATO/TIMEOUT occupato o realm non trovato)

TC 12 Metodo testato Input Output atteso Output ottenuto UA: CONFERMATA/ UA: CONFERMATA/ Accetta chiamata CHIAMATA CHIAMATA accettaChiamata UA: chiamata in AudioLauncher: AudioLauncher: ingresso apertura audio apertura audio calee@realm java..... java.....

TC 13 Metodo testato Input Output atteso Output ottenuto UA: CHIUSA UA: CHIUSA AudioLauncher: AudioLauncher: terminaChiamata Termina chiamata chiusura audio chiusura audio java... java...

4.6.5 Esempio d’uso

Il componente VoIP realizzato dovrebbe lavorare in background, come tutti i servizi del framework, fornendo il servizio VoIP ad un applicativo utente scritto, per esempio, in C#.

117 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Al momento, secondo quanto già discusso, lo stato della tecnologia non ci permette di contenere il componente VoIP in un Web Service e permetterne l’uso in locale sul palmare. Vogliamo comunque mostrare la possibilità di usare il componente VoIP, come applicazione stand-alone, per effettuare telefonate dal nostro palmare su cui abbiamo precedentemente installato la JVM Mysaifu. Come primo passo, dobbiamo procurarci un account SIP. Lo facciamo presso il provider Messagenet (www.messagenet.it), basato sull’architettura Asterisk. Precisamente, in questo caso, il Registrar server è sip.messagenet.it. Esso fornisce all’atto della registrazione un SipURL (@ sip.messagenet.it), una password e un numero geografico con prefisso a scelta tra “02” e “06”. Messagenet fornisce anche il servizio di segreteria telefonica: all’e-mail fornita all’atto della registrazione, Messagenet invierà i messaggi vocali lasciati in segreteria. Le caratteristiche del palmare e della JVM ci consentono di realizzare un applicativo grafico. Sfruttando il package grafico java.awt, mostriamo di seguito gli screenshots relativi ai metodi presentati in precedenza:

Figura 4.13 - Operazione di Login andata Figura 4.14 - Chiamata in ingresso da a buon fine parte di “Vittorio”

118 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

Figura 4.15 - Il destinatario rifiuta la Figura 4.16 - Chiamata in uscita; in attesa chiamata che il destinatario risponda

Figura 4.17 - Il destinatario ha risposto Figura 4.18 - Uno dei due interlocutori ha alla chiamata terminato la chiamata

4.7 Conclusioni

Qui si chiude lo studio di fattibilità del componente VoIP su dispositivo mobile.

119 Capitolo 4. Analisi di un caso studio: integrazione del servizio VoIP

La soluzione ottenuta sicuramente non ha le stesse potenzialità del progetto MjSIP iniziale: pur garantendo la compatibilità con lo standard SIP, essa presenta, per quel che riguarda lo streaming audio, problemi di compabilità con altri applicativi VoIP e la totale incompatibilità da e verso la rete telefonica tradizionale. Tuttavia MjSIP mobile garantisce il VoIP e una buona QoS qualora i due interlocutori usino entrambi MjSIP mobile. Nel capitolo successivo, esamineremo alcune soluzioni alternative, e lasciate agli sviluppi futuri, per la realizzazione del framework.

120 Capitolo 5. Conclusioni e sviluppi futuri

5. Conclusioni e sviluppi futuri

In questo lavoro di tesi si è progettato un framework per dispositivi mobili che garantisca un facile accesso ai più comuni servizi diffusi negli ambienti di mobile computing. Si è immaginato il framework costituito da due parti: il Framework Core, garante dei requisiti non funzionali, e i servizi veri e propri, definiti dai requisiti funzionali. Tutto il lavoro è stato svolto nell’ambito del progetto “WiFi People – CRONOS”. Nel corso della progettazione, il rispetto dei requisiti dimostra come il framework, con i servizi integrati, possa essere distribuito tanto in un ambiente totalmente mobile (reti mobili Ad-Hoc), quanto in un ambiente nomadico. Diverse sono state le tecnologie studiate per la realizzazione del Framework Core. Avvalendoci anche delle scelte di mercato di aziende leader nel settore, la scelta tecnologica è ricaduta sui Web Services.

Il lavoro è proseguito con lo studio di uno dei servizi, ovvero il servizio VoIP. La progettazione del servizio VoIP mira ad integrare il relativo componente all’interno del framework di servizi per renderlo disponibile alle applicazioni utente. I limiti tecnologici dei dispositivi mobili, dei palmari in particolare, impediscono tuttavia di ottenere la soluzione per reti mobili Ad-Hoc, né tantomeno possiamo pensare di adottare una soluzione nomadica, poiché incompatibile con il servizio VoIP così come con altri servizi.

121 Capitolo 5. Conclusioni e sviluppi futuri

In tal contesto diventa necessario proseguire negli studi e nella ricerca per permettere all’intero framework – Framework Core e servizi integrati – di risiedere su un dispositivo mobile. Il problema maggior è avere a disposizione un “mini” Web Service Container, ed il relativo Web Server, tale che possa realizzare sul dispositivo mobile stesso, attraverso la tecnologia Web Service, lo strato software relativo al Framework Core. Oltre al mercato che offre dispositivi mobili con risorse computazionali crescenti, buone possibilità - “mini” - ci vengono offerte dalle comunità di sviluppo sulla traccia delle grandi compagnie di prodotti per il mobile, come Nokia, Symbian e PalmOS. Un’interessante soluzione open-source ancora una volta viene dal mondo Java. Si tratta di

Tiny Java Web Server and Servlet Container (TJWS; http://tjws.sourceforge.net/). Esso è un “mini” Web Server Java, oltre che Servlet Container, equivalente al più popolare Apache Tomcat per macchine desktop/server. Non esiste ancora, però, un Web Service Container, simile ad Axis, che permetta la realizzazione completa del Framework Core. Va tenuto in conto che TJWS funziona bene solo su J9, la JVM con licenza commerciale rilasciata da IBM. Perdiamo così la caratteristica che il framework sia realizzato con strumenti open-source.

Possiamo adottare, a questo punto, delle soluzioni alternative nell’ipotesi di portare su dispositivo mobile l’intero set di servizi previsto.

Senza ricorrere ad alcun Web Server, potremmo permettere alle applicazioni utente di accedere ai servizi usando le Socket. Tale soluzione richiede uno sforzo maggiore da parte sia di chi realizza i servizi sia da parte di chi implementa le applicazioni utente. In particolare, seguendo il pattern Socket, lo sviluppatore del servizio dovrà preoccuparsi di garantire il marshalling/unmarshalling dei dati scambiati, oltre che il riconoscimento dei metodi invocati, mentre lo sviluppatore dell’applicazione utente dovrà rispettare i vincoli imposti dal pattern di programmazione adottato.

122 Capitolo 5. Conclusioni e sviluppi futuri

Ricorrendo, invece, al Servlet Container, potremmo garantire l’accesso ai servizi attraverso richieste HTTP. Ciò richiede tuttavia di progettare i servizi compatibilmente alla struttura delle servlet e, al programmatore lato client, di attenersi ad un paradigma di progettazione ben preciso, dipendente dal protocollo HTTP.

In ciascuna delle soluzioni presentate in precedenza perdiamo uno o più requisiti non funzionali garantiti dal framework di servizi, così come progettato nell’ambito di questo lavoro di tesi.

Per conservare tutti i requisiti, potremmo, a questo punto, tornare sulla scelta della tecnologia da adottare per la realizzazione del framework. Nel corso del lavoro di tesi abbiamo adottato la tecnologia Web Service, basata sull’architettura SOA. Tuttavia, esiste un modello architetturale emergente che potrebbe risolvere le problematiche relative alla mancanza di un Web Service Container per dispositivi mobili: stiamo parlando dei Web Services REST (REpresentational State Transfer). La filosofia REST nasce con l’intento di sfruttare totalmente e solamente le potenzialità del Web: non mira ad adattare la rete al concetto di servizio, così come avviene nell’architettura SOA, bensì sfrutta il concetto di risorsa, proprio della rete, a cui accede tramite i pochi metodi offerti dal protocollo HTTP, ovvero PUT, GET, POST e DELETE. Gli aspetti fondamentali dell’architettura REST sono:

o le risorse, scomposte e organizzate in modo da poter essere gestite in modo atomico dai metodi del protocollo HTTP. In particolare, ogni metodo accede alle risorse attraverso una rappresentazione della stessa, compatilmente alla sintassi URI (Uniform Resource Identifier);

o la comunicazione è stateless, ovvero almeno lato server siamo vincolati a non mantenere lo stato dell’applicazione. Qualora servisse mantenere lo stato, l’applicazione client deve farsene carico.

123 Capitolo 5. Conclusioni e sviluppi futuri

In altre parole, con l’architettura REST si realizzano Web Services meno differenti da un sito Web vero e proprio, poiché si accede ai REST Web Services come un browser accede alle informazioni tipicamente contenute in una pagina Web. Per i fini della nostra tesi, ricorrendo alla tecnologia REST e passando ad una filosofia resource centric nella progettazione dei servizi da integrare, potrebbe bastare avere sul dispositivo mobile un Web Server come TJWS che risponda a semplici richieste HTTP.

Una riprogettazione in tal senso, tuttavia, potrebbe risultare poco lungimirante a fronte delle aspettative di un mercato sempre in espansione e innovativo come è, appunto, quello dei dispositivi mobili.

124 Appendice

Appendice

A.3.1 Soluzione Web Service in ambiente nomadico

Vediamo di seguito una possibile soluzione Web Service in un ambiente nomadico. Di seguito riportiamo una panoramica sulle tecnologie e metodologie adottate per lo sviluppo e l’accesso ai servizi offerti dal framework in tale contesto.

A.3.1.1 Tecnologie Java per i Web Services

Java implementa diverse tecnologie per lo sviluppo e l’uso dei Web Services. Ne riportiamo di seguito una descrizione [40]:

Figura A.3.1 - Le tecnologie Java per lo sviluppo dei Web Services

Queste tecnologie hanno il seguente scopo:

o JAX-M (Java API for XML Messaging) è un’implementazione della messaggistica SOAP a basso livello;

o SAAJ (SOAP with Attachments API for Java) è un’implementazione del modello informativo degli elementi di SOAP;

125 Appendice

o JAX-RPC (Java API for XML Remote Procedure Call) fornisce il supporto client e server allo sviluppo rapido di servizi Web basati su SOAP e WSDL con un modello di sviluppo simile ad RMI;

o JAXR (Java API for XML Registries) fornisce il supporto a registri di servizi Web come UDDI e ebXML R.

Nota di riguardo va data a JAXP [41] (API chiamata precedentemente Project X). Vuole fornire al programmatore i mattoni di base per realizzare applicazioni XML. Più che di applicazioni si può parlare di un framework di sviluppo basato su servizi e applicazioni. Le funzionalità di JAXP rappresentano il cosiddetto core per la realizzazione di applicazioni XML in Java. Questo nucleo di base include:

o la possibilità di utilizzare diversi parser (pluggability); o API per il parsing (con eventuale validazione) dei documenti; o DOM API per poter gestire un documento XML come una struttura ad albero. Sulla base degli elementi forniti da JAXP è possibile costruire dei servizi, ovvero moduli che forniscono funzionalità troppo specializzate per far parte della core API. Utilizzando la core API ed eventualmente servizi addizionali si possono sviluppare applicazioni complete basate su XML come Web-publishing e transazioni per l’e- commerce business-to-business. JAXP fornisce anche il supporto per la API SAX attraverso la classe SAXParser. SAX (Simple API for XML) è un’interfaccia event-driven standard definita dal W3C per l’elaborazione dei documenti XML.

Dallo stack delle tecnlogie (Figura A.3.1) che Java mette a disposizione per la realizzazione dei Web Services, emerge che entrambe le API di SUN implementano SOAP, quindi si potrebbe pensare che l’utilizzo delle due sia indifferente. In realtà non è così: JAX-M e JAX-RPC non sono una ripetizione della stessa tecnologia con nomi diversi.

126 Appendice

Per prima cosa, entrambe utilizzano SAAJ come implementazione del modello informativo di SOAP [40], ma il loro scopo è differente:

o JAX-M fornisce un controllo fine sul messaggio (tramite SAAJ), consentendo di manipolare ciascun elemento della richiesta ed accedere a qualsiasi elemento della risposta SOAP. Viene utilizzato in soluzioni di messaggistica, come ad esempio: l’invio asincrono di informazioni real-time, l’interfacciamento con servizi strutturati in modo particolare (non standard), collegamento a servizi che hanno una risposta dinamica (cambia la struttura al variare della richiesta o dei dati ritornati);

o JAX-RPC implementa invece un generico sistema di RPC su XML; la tecnologia non è vincolata a SOAP, ma aperta ad eventuali evoluzioni future. E’ invece basata fortemente su WSDL, che utilizza per implementare la mappatura XML-Java e viceversa. Con JAX-RPC non è necessario codificare a basso livello, se si dispone di un WSDL, si possono generare le classi Java che implementano il client ed il server. La stessa cosa può avvenire a partire da una interfaccia che estende java.rmi.Remote, in modo similare al funzionamento di RMI e del comando rmic.

JAX-RPC è dunque più indicato per sviluppare applicazioni complesse, con molti servizi, e per integrare Web Services esistenti e completamente standard, quando non sia necessario entrare nel dettaglio tecnico della struttura dei messaggi SOAP di richiesta e risposta. Con JAX-RPC un servizio Web viene acceduto come se fosse un oggetto Java locale.

A.3.1.2 Lato Server I nostri servizi lato server saranno implementati nel linguaggio Java. La piattaforma di riferimento, precisamente, è J2SE 1.6 su sistema operativo Windows XP SP2. L’IDE di sviluppo usato è Eclipse Web Tools Platform (WTP) 3.2. E’ necessario introdurre una tecnologia che ci permetta di esporre un’applicazione Java come un Web Service. In particolare, adotteremo per il nostro progetto le tecnologie JAXP, SAAJ e JAX-RPC.

127 Appendice

Inoltre, nello sviluppo dei servizi la “remotizzazione” degli stessi sarà trasparente al programmatore, grazie alla tecnologia Java basata sulle Java Server Pages (JSP). In effetti, con l’introduzione delle JSP, la nostra piattaforma di sviluppo di estende per essere tipica della J2EE.

Apache Tomcat (http://tomcat.apache.org/) JSP (letto talvolta come Java Scripting Preprocessor) è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o XML. Si basa su un insieme di speciali tag con cui possono essere invocate funzioni predefinite o codice Java. In aggiunta, permette di creare librerie di nuovi tag che estendono l’insieme dei tag standard. Le librerie di tag JSP si possono considerare estensioni indipendenti dalla piattaforma delle funzionalità di un Web server. JSP è una tecnologia alternativa rispetto a numerosi altri approcci alla generazione di pagine Web dinamiche, per esempio ASP o la più tradizionale CGI. Differisce da queste tecnologie non tanto per il tipo di contenuti dinamici che si possono produrre, quanto per l’architettura interna del software che costituisce l’applicazione Web (e, di conseguenza, sui tempi di sviluppo, la portabilità, la modificabilità, le prestazioni, e altri aspetti di qualità del software). Nel contesto della piattaforma Java, la tecnologia JSP è correlata con quella delle servlet. All’atto della prima invocazione, le pagine JSP vengono infatti tradotte automaticamente da un compilatore JSP in servlet. Una pagina JSP può quindi essere vista come una rappresentazione ad alto livello di un servlet. Per via di questa dipendenza concettuale, anche l’uso della tecnologia JSP richiede la presenza, sul Web server, di un Servlet container, oltre che di un server specifico JSP detto motore JSP (che include il compilatore JSP); in genere, Servlet container e motore JSP sono integrati in un unico prodotto; per esempio, Apache Tomcat svolge entrambe le funzioni.

Apache Tomcat (o semplicemente Tomcat) è un Servlet container open-source sviluppato dalla Apache Software Foundation. Implementa le specifiche JSP e Servlet della Sun, fornendo quindi una piattaforma per l’esecuzione di applicazioni Web sviluppate nel

128 Appendice

linguaggio Java. La sua distribuzione standard include anche le funzionalità di Web server tradizionale, che corrispondono al prodotto Apache. In passato, Tomcat era gestito nel contesto del progetto Jakarta, ed era pertanto identificato con il nome di Jakarta Tomcat; attualmente è oggetto di un progetto indipendente. Tomcat è rilasciato sotto licenza Apache Software License, ed è scritto interamente in Java ed include la tecnologia JAXP; può quindi essere eseguito su qualsiasi architettura su cui sia installata un JVM.

Una pagina JSP è un documento di testo, scritto con una sintassi specifica, che rappresenta una pagina Web di contenuto parzialmente o totalmente dinamico. Elaborando la pagina JSP, il motore JSP produce dinamicamente la pagina HTML finale che verrà presentata all’utente. La pagina JSP può contenere tre tipi di elementi, a cui corrispondono tre diversi modi di elaborazione: contenuti statici, direttive e script. In particolare, i contenuti statici sono porzioni della pagina JSP che devono essere mantenute integralmente nella pagina Web generata dinamicamente, senza alcuna elaborazione. Devono pertanto essere scritte nel linguaggio di tag di cui il client può usufruire direttamente, per esempio HTML (se il client è un browser), WML (se il client è un cellulare che accede alla pagina in WAP) o XML, come nel nostro caso.

Apache AXIS (http://ws.apache.org/axis/) Per dotare Tomcat di un Web service engine in grado di esaudire richieste provenienti da qualsiasi client Web Service, è necessario istallare AXIS [42]. Si tratta di un’API di programmazione e deployment di Web Services che permette di lavorare ad un livello di astrazione elevato, evitando così di dover maneggiare direttamente l’envelopement SOAP. Con Axis è possibile, dunque, implementare Web Services e anche sviluppare client di servizi di terzi. Axis permette lo sviluppo di Web Service sia in Java che in C++.

129 Appendice

Axis implementa il modello JAX-RPC e supporta anche SAAJ. Non tutto nasce da

Apache, il prodotto iniziale è merito di IBM, che poi decise di regalare al consorzio Apache tutto il codice. Viene alla luce quindi Apache SOAP e poi la sua evoluzione: Apache Axis.

Le caratteristiche più importanti del framework sono [42]:

o implementazione SOAP 1.1/1.2; o supporto JWS (Java Web Services): permette un facile e immediato deploy dei Web Services;

o supporto serializzazione/de-serializzazione; o implementazione WSDL; o utility WSDL2Java e Java2WSDL; o SOAP Monitor e TCP Monitor: due applicazioni scritte in Java che permettono di monitorare il traffico SOAP;

o possibilità di usare tre differenti metodi per l’invocazione dei Web Services: Dynamic Invocation Interface (DII), Stub generato dal WSDL e Dynamic Proxy.

I componenti di Axis sono quindi: un engine per l’elaborazione dei messaggi SOAP, handler per la gestione dei messaggi, vari meccanismi di deploy, serializzazione/de- serializzazione, configurazione e di trasporto dei messaggi.

A.3.1.3 Lato Client

Passiamo all’implementazione del client, ovvero del Web Service Consumer. I client saranno i dispositivi mobili che vogliono “consumare” i Web Services Java. Scegliamo come riferimento il sistema operativo Windows Mobile 5.0 su PocketPC 2.0, l’equivalente, dal punto di vista J2ME, di un dispositivo CDC Personal Profile. Qualunque linguaggio adotteremo per l’implementazione dei Web Service consumer, essi dovranno essere grado di costruire i messaggi che si vuole spedire al servizio Web e di analizzare ciò che il servizio Web spedisce al mittente. Scrivere manualmente il codice per

130 Appendice

costruire ed analizzare i messaggi richiede un tempo elevato e la possibilità di commettere errori è elevata. Una soluzione migliore è quella di includere tale codice in una classe che consenta il suo riuso. Tale classe prende il nome di proxy class. Esse espongono le stesse funzionalità del servizio Web che vuole essere utilizzato da un client, in modo assolutamente indipendente dalla locazione fisica del servizio medesimo. Inoltre, tutti i dettagli implementativi relativi al marshalling tra i processi viene gestito dalla proxy class: la chiamata ad un metodo di un servizio Web apparirà al client come la chiamata ad un metodo locale. Per la piattaforma Windows Mobile va da sé che il linguaggio che può offrire maggiori vantaggi è C#, linguaggio principe della piattaforma .NET Compact Framework [31]. In tal caso, le proxy class vengono generate mediante una utilità del framework SDK denominata Wsdl.exe. Tale eseguibile prende in ingresso un documento WSDL e produce una proxy class avente l’estensione del linguaggio di implementazione del servizio Web (nel caso di C#, l’estensione è .cs). Le classi proxy prodotte con la tecnologia Microsoft espongono una serie di proprietà che consentono una loro personalizzazione: 1. proprietà Url: consente di definire un riferimento ad un altro servizio Web che espone le medesime funzionalità; 2. proprietà Credentials: consente di fornire le credenziali per l’autenticazione del consumer. Tra i meccanismi di autenticazione basati sulle credenziali possiamo annoverare: autenticazione Basic, Kerberos, NTLM e Digest; 3. proprietà Timeout: consente di definire il tempo entro il quale deve essere conclusa la chiamata ad un metodo del servizio Web; 4. proprietà Proxy: consente di definire i settaggi di un proxy differenti dalle impostazioni di default; 5. proprietà AllowAutoRedirect: consente, se il valore viene settato a true, di

autorizzare il Web service provider a ridirigere le credenziali del consumer verso un altro server remoto per completare l’operazione di autenticazione.

131 Appendice

Figura A.3.2 - Stack architetturale della tecnologia .NET

Per il client C#, l’IDE di sviluppo è stato, per le prime prove su macchina desktop, Visual C# 2005 Express Editino; in un secondo momento, per passare ad un deployment su PocketPC più veloce, abbiamo usato Microsoft Visual Studio 2005 SDK, comprensivo di emulatori.

A.3.2 Soluzione e suoi limiti

Vediamo la soluzione lato server. Supponiamo di aver già configurato correttamente l’ambiente di sviluppo Java (JDK 1.6) su una macchina desktop Windows XP SP2.

Sulla stessa macchina installiamo il server Tomcat 6.0 e ne configureremo le variabili di ambiente. A questo punto possiamo scaricare Axis 1.4 dal sito di Apache. Unzippiamo e copiamo il tutto nella cartella TOMCAT_HOME/webapps (TOMCAT_HOME è la variabile di ambiente che indica il path dove abbiamo installato Tomcat). Faremo riferimento all’host locale (localhost, ovvero 127.0.0.1); nel caso generale sostituiremo alla parola “localhost” l’indirizzo IP del server remoto su cui risiedono i nostri servizi. Avviamo Tomcat e puntiamo il browser all’indirizzo

http://localhost:8080/axis. In questa pagina troviamo lo stato dell’installazione di Axis. Se

132 Appendice

manca qualche libreria Java (.jar) ci viene indicato e non dobbiamo fare altro che procurarle dai siti di riferimento della Sun e copiarle dentro la cartella TOMCAT_HOME/webapps/axis/WEB-INF/lib.

Le librerie richieste, che vanno inserite nel classpath per lanciare il deployment, sono:

o axis.jar o jaxrpc.jar o saaj.jar o commons-logging.jar o commons-discovery.jar o log4j-1.2.8.jar o xml-apis.jar o xercesImpl.jar

Si imposta la variabile d’ambiente AXISCLASSPATH che rappresenta i riferimenti alle librerie .jar che contengono l’implementazione degli standard sui Web Services come SAAJ e JAX-RPC; si noti l’ultima libreria dove è incluso il parser XML Xerces: Java include il parser Crimson, ma Apache consiglia Xerces [42]: entrambi funzionano adeguatamente quindi la scelta è puramente personale. In alcuni casi potrebbe essere necessario l’uso della libreria activation.jar. La verifica della corretta integrazione tra Axis e Tomcat si ottiene facendo puntare il browser http://localhost:8080/axis: dovrebbe comparire la semplice Home Page testuale di Axis da cui è possibile effettuare alcune operazioni.

Apache AXIS implementa il nuovo standard JWS di Java che permette di effettuare il deploy di un Web Service in maniera semplice e veloce. È sufficiente sviluppare la propria classe in Java, testarla, cambiare l’estensione da .java in .jws e copiare il file .jws nella cartella TOMCAT_HOME/webapps/axis.

133 Appendice

Axis lo tratterà in maniera simile ad una JSP, ossia lo compilerà nella cartella TOMCAT_HOME/webapps/axis/WEB-INF/jwsClasses e si occuperà dell’interfacciamento con SOAP mediante la conversione automatica SOAP-JAVA. Tale metodo ha ovviamente il pregio della semplicità a scapito della flessibilità: è infatti impossibile decidere quali metodi esporre e specificare conversioni specifiche tra SOAP e JAVA. Un metodo più flessibile è l’uso dei file WSDD (Web Service Deployment Descriptor), introdotti da Axis. Un Web Service accessibile è, quindi, una classe Java che espone i propri metodi pubblici e non-static. Ora è necessario eseguire il deploy, ovvero rendere disponibile il nostro Web Service ottenendo il file WSDL descrittore del WS. Per ottenere questo e verificare la corretta interpretazione e compilazione dei Web Services, si digiti nel browser: http://localhost:8080/axis/

Java>.jws?wsdl. Nel browser apparirà il testo relativo al file WSDL. Il testo è di facile lettura e possiamo individuare qualche tag fondamentale, per esempio:

o wsdl:message: indicano il tipo dei dati scambiati; o wsdl:portType: il tipo di operazione e i parametri; o wsdl:bindings: il tipo di protocollo usato; o wsdl:service: caratteristiche del Web Service come l’indirizzo.

Se il Web Service (il file .jws, Java Web Service) usa altre classi Java, per effettuare il corretto deployment, è necessario copiare i file di bytecode (.class) relativi a quest’ultime nella cartella del server Tomcat TOMCAT_HOME/webapps/axis/WEB-INF/classes.

Ora possiamo “consumare” il Web Service. Ci riferiremo all’IDE Visual Studio 2005 Express Edition, liberamente scaricabile dal sito della Microsoft. Poiché il dispositivo target resta un PocketPC 2.0 con Windows Mobile 5.0, l’implementazione può passare direttamente attraverso Visual Studio 2005 che fornisce ulteriori tools per lo sviluppo mobile, come gli emulatori.

134 Appendice

Una volta creato un progetto, in entrambi gli IDE, non è necessario usare a riga di comando il tool Wsdl.exe, della .NET SDK. Infatti, basta cliccare con il tasto destro del mouse sul progetto e selezionare la voce “Aggiungi riferimento Web” per avviare la procedura relativa al comando Wsdl.exe. Ci verrà chiesto l’URL relativo al Web Service (http://localhost:8080/axis/.jws?wsdl) che dovrà chiaramente essere attivo in quel momento attraverso il server Tomcat e le librerie Axis. Se l’URL inserito è corretto, ci verrammo mostrati i metodi a cui possiamo ora accedere. Da questo momento, i metodi remoti implementati in Java (Web Services Java) possono essere consumati in piena trasparenza come se fossero dei metodi locali C#. Ricordiamo che questa non può essere la soluzione definitiva per l’implementazione del nostro framework: essa è valida solo in ambienti nomadic computing e solo relativamente alle tipologie di servizi i cui dati trattati non dipendono dall’hardware a disposizione di un dispositivo mobile.

135 Bibliografia

Bibliografia

[1] Coulouris, Dellimore, Kindberg: Distributed Systems: Concepts and Design. 2005 [2] Mascolo, Capra, Emmerich. Mobile Computing Middleware. Dept. of computer Science, University College London. 2002 [3] Lyytinen, Yoo. Issues and challenges in Ubiquitous Computing. Communication of ACM. 2002 [4] Kleinrock. Nomadicity: anytime, anywhere in a disconnected world. J. C. Baltzer AG Science Publishers. 1996 [5] Akyildiz, Su, Sankarasubramaniam, and E. Cayirci. Wireless sensor networks: a survey. Computer Networks. 2002 [6] Chakraborty, Perich, Avancha, Joshi. Service Discovery for M-Commerce Applications. Department of Computer Science and Electrical Engineering – University of Maryland. 2001 [7] Trisciuoglio. Introduzione alla Domotica. Tecniche Nuove. 2002 [8] Polini. Client/Server, Middleware & surroundings (Abstract). 2001 [9] Umar. Object-Oriented Client/Server Internet Environments. Prentice Hall Inc. 1997 [10] Forman, Zahorjan. The Challenges of Mobile Computing. Computer Science Department, University of Washington, U.S. 1993. [11] Srinivasan. RPC: Remote Procedure Call protocol specification version 2. RFC 1831. 1995 [12] Sun Microsystems. Java Remote Method Invocation . Distributed Computing for Java. White Paper.1998

136 Bibliografia

[13] Object Management Group. The Common Object Request Broker: Architecture and Specification. 2004. . [14] Bernstein. Transaction Processing Monitors. ACM Communication, Vol.33 No.11. 1990. [15] Friday. Infrastructure Support for Adaptive Mobile Applications. PhD Thesis, Computing Department, Lancaster University. 1996. [16] Object Management Group. Wireless Access and Terminal Mobility in CORBA. 2004. . [17] Alice Web Site. . [18] Liljeberg, Raatikainen, Evans, Furnell, Maumon, Veltkamp, Wind, and Trigila. Using CORBA to Support Terminal Mobility. IEEE Computer Society Press. 1998. [19] Grace. Middleware Support for Mobile Computing Applications. PhD First Year Report. Computing Department, Lancaster University. 2001

[20] Mascolo, Capra, Zachariadis, Emmerich. XMIDDLE: A Data-Sharing Middleware for Mobile Computing. Personal and Wireless Communications. 2001 [21] OASIS. Reference Model for Service Oriented Architecture 1.0. SOA-RM-CS. 2006 [22] Carli. MIDP 2.0: Programmare i cellulari. [23] Russo, Cotroneo. European Master on Critical Networked Systems - Università di Napoli “Parthenope”. 2007 [24] Rossini. Networking in Java, V puntata: RMI, la teoria. 2000.

[25] Altese. RMI: metodi a distanza. 2006. [26] Carli. La piattaforma J2ME ed i Web Services, II parte: le JSR-172. 2005. [27] Scaramuzza. Web Services et J2ME. 2003. [28] The Community Resouce for Jini Tecnology. [29] Zappa. Jini. 2001. [30] Modello di programmazione di .NET Framework. MSDN Library.

137 Bibliografia

[31] .NET Compact Framework. MSDN Library. [32] VoIP. Abstract open solutions. [33] Saccomani. Voice Over IP. Una introduzione al VoIP nei suoi aspetti tecnici, economici, di business e regolamentari. [34] Wikipedia. Voice Over IP. [35] Asterisk user’s Group Italia. La tecnologia SIP. Voce su IP. [36] Wikipedia. Real-time Transport Protocol. [37] Galletti. Configurazione di un servizio VoIP con Asterisk. Tesi di laurea, università degli studi di Cassino. 2005 [38] Marzilli. Il protocollo SIP. [39] VoIPForo.com. Codecs. [40] Bigatti. JWS FAQ. 10 Domande e risposte sui Web Service. 2004. [41] Giovannini. JAXP. Java API for XML Parsing. 2000. [42] Verago. Realizzare un Web Services in pochi minuti con Apache Axis. 2006.

138