Integrazione di un servizio di messagistica in un ... Bellucci Flavio.pdf · me, mi manchi un po’! E poi Chiara, la mia fidanzata, che mi ha sempre sostenuto in ogni momento e mi

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II

Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica

Tesi di Laurea

Integrazione di un servizio di messaggistica in un framework di sviluppo per dispositivi mobili

RELATORE Ch.mo Prof. Stefano Russo CORRELATORE CANDIDATO Ing. Marcello Cinque Flavio Bellucci

Matr. 041/3572

ANNO ACCADEMICO 2006-2007

La prima persona che devo e voglio ringraziare è sicuramente la mia mamma per questo

importante traguardo. Mi è stata sempre vicina in ogni momento, sostenendomi sempre e

aiutandomi tantissimo per tutta la vita fino ad oggi, questa laurea è anche un po’ tua!!

Ti voglio bene mamma!

Naturalmente ringrazio anche il mio papà e mia sorella Alessandra. Anche loro non mi

hanno fatto mai mancare il loro sostegno e mi hanno sopportato soprattutto nei periodi di

maggior stress. Anche a voi grazie!

Poi voglio ringraziare tutti i miei amici in particolare Beo, Chiatto, MarioD’Alessio e

Gennaro Tognozzi che mi è stato sempre vicino e mi ha sempre aiutato. Grazie Preside’!

Uno speciale ringraziamento a Peppe il nero, Giowax e lo zio (Umberto) con cui ho

condiviso gli anni dell’università. Senza di loro non avrei superato tutti gli esami, quante

ne abbiamo passate tra tante risate!!! Non mollate!

Naturalmente non posso non ringraziare il guru (Mimmo) con cui non solo ho condiviso

gli anni di studi universitari ma anche il periodo di lavoro della tesi, senza di te

probabilmente non sarei riuscito a completarlo. E’ stata dura ma ce l’abbiamo fatta!!!!

Ringrazio il prof. Russo per l’opportunità dataci e Marcello per averci guidati durante lo

sviluppo della tesi, senza di te ci saremmo già persi.

In ultimo, ma non per importanza, voglio ringraziare due persone a me molto care:

Genny sempre pronto a starmi accanto anche nei momenti brutti, i suoi consigli sono

sempre preziosi. Grazie soprattutto quando mi sei stato ad ascoltare nei momenti tristi che

sono capitati da quando ci conosciamo. Anche se ora sei in Olanda, sei sempre vicino a

me, mi manchi un po’!

E poi Chiara, la mia fidanzata, che mi ha sempre sostenuto in ogni momento e mi ha

sopportato e mi sopporta ancora. Grazie per starmi accanto, la tua presenza è

importantissima per me, senza di te non saprei davvero come fare!

- 2 -

Indice Indice .......................................................................................................................................... - 3 - Introduzione ............................................................................................................................... - 5 - Capitolo 1: Soluzioni middleware per ambienti mobili ............................................................. - 8 -

1.1 Mobile Computing........................................................................................................ - 8 - 1.1.1 Introduzione ai sistemi distribuiti mobili............................................................... - 8 - 1.1.2 I dispositivi mobili .................................................................................................. - 9 - 1.1.3 Classificazione dei sistemi mobili ........................................................................ - 10 - 1.1.4 Problematiche relative ai sistemi mobili.............................................................. - 11 -

1.2 Scenari applicativi ...................................................................................................... - 14 - 1.2.1 Domotica o Casa intelligente ............................................................................... - 14 - 1.2.2 e-Health ................................................................................................................ - 17 - 1.2.3 Altri scenari .......................................................................................................... - 19 -

1.3 I Middleware............................................................................................................... - 22 - 1.3.1 Introduzione ai middleware e loro proprietà....................................................... - 22 - 1.3.2 Differenze tra middleware per sistemi tradizionali e per sistemi mobili ............. - 23 - 1.3.3 Middleware per sistemi mobili ............................................................................. - 25 -

Capitolo 2: Un’infrastruttura per l’integrazione di servizi in ambienti mobili ....................... - 30 -

2.1 Introduzione................................................................................................................ - 30 - 2.2 Specifica dei requisiti ................................................................................................. - 31 -

2.2.1 Scopo del sistema.................................................................................................. - 31 - 2.2.2 Requisiti funzionali .............................................................................................. - 31 - 2.2.3 Requisiti non funzionali ...................................................................................... - 34 -

2.3 Progettazione del Framework ................................................................................... - 36 - 2.3.1 Architettura del Framework ................................................................................ - 36 - 2.3.2 Deployment Diagram ........................................................................................... - 38 -

2.4 Studio delle tecnologie per la realizzazione del Framework Core......................... - 42 - 2.4.1 Tecnologie middleware prese in esame ............................................................... - 42 - 2.4.2 Griglia di fattibilità ............................................................................................... - 51 - 2.4.3 Vantaggi e Svantaggi delle tecnologie ................................................................. - 52 -

Capitolo 3: Progettazione del servizio IM ............................................................................... - 55 -

3.1 Che cos’è un Instant Messaging ................................................................................ - 55 - 3.1.1 Struttura di un sistema di messaggistica istantanea ........................................... - 56 -

3.2 Descrizione del servizio IM........................................................................................ - 57 - 3.3 La fase di analisi ......................................................................................................... - 57 -

- 3 -

3.3.3 Diagramma dei casi d’uso.................................................................................... - 57 - 3.4 La Fase di progettazione ............................................................................................ - 64 -

3.4.1 Architettura del componente IM.......................................................................... - 64 - 3.4.2 Diagramma delle classi ........................................................................................ - 65 - 3.4.3 Diagramma delle sequenze .................................................................................. - 70 - 3.4.4 Diagramma delle collaborazioni.......................................................................... - 72 - 3.4.5 Test Case ............................................................................................................... - 73 -

Capitolo 4: Implementazione del servizio IM .......................................................................... - 78 -

4.1 Scelta delle tecnologie................................................................................................. - 78 - 4.1.1 Protocollo.............................................................................................................. - 79 - 4.1.2 Server .................................................................................................................... - 79 - 4.1.3 Altre scelte tecnologiche....................................................................................... - 80 -

4.2 Implementazione e funzionamento classi ................................................................. - 81 - 4.2.1 Classe Connessione .............................................................................................. - 82 - 4.2.2 Classe Conversazione ........................................................................................... - 84 - 4.2.3 Pubblicazione classi come Web Services ............................................................. - 87 -

4.3 Testing ......................................................................................................................... - 91 - 4.4 Esempio di funzionamento ........................................................................................ - 95 -

Capitolo 5: Conclusioni e sviluppi futuri ............................................................................... - 105 - Appendice A: Il protocollo Jabber ......................................................................................... - 108 -

A.1 Caratteristiche e funzionamento di Jabber............................................................. - 108 - A.2 Il server jabber Openfire .......................................................................................... - 114 -

Appendice B: WS-Notification ............................................................................................... - 115 -

B.1 Introduzione ............................................................................................................... - 115 - B.2 Le architetture publish/subscribe ............................................................................ - 116 - B.3 Le entità WS-Notification ......................................................................................... - 117 - B.4 Evoluzione dello standard WS-Notification ............................................................ - 119 -

Appendice C: Note implementative ........................................................................................ - 122 -

C.1 Installazione di Axis .................................................................................................. - 122 - Bibliografia ............................................................................................................................ - 125 -

- 4 -

Introduzione

Lo sviluppo sempre maggiore delle reti wireless ha portato alla grande diffusione di

dispositivi mobili (palmari, smartphone, ecc) che permettono di usufruire di servizi quali

Instant messaging, VoIP, Video streaming, accesso a una banca di dati, ecc, anche al di

fuori della propria abitazione o del posto di lavoro. Le persone possono, così, in un

qualunque momento e luogo accedere a tali servizi sia per scopi di divertimento e di svago

sia per motivi di lavoro. Altri servizi (es. gestione canale SMS per notifiche ed alert, GPS,

positioning, ecc) possono essere utilizzati anche per migliorare l’ambiente domestico e dei

luoghi di lavoro come ospedali e musei, o facilitare il lavoro di alcune classi di lavoratori.

Quindi, nascono scenari in cui ognuno tramite dispositivi mobili accede a tali servizi. Da

qui si ha l’evoluzione dei sistemi distribuiti tradizionali a sistemi mobili (mobile

computing) in cui i componenti (nodi) sono collegati tramite tecnologia wireless e si

possono muovere liberamente nello spazio fisico.

Oggi, ci sono molte tecnologie che permettono di accedere ad applicazioni eterogenee

sviluppate da diverse parti che offrono tali servizi; queste tecnologie sono i middleware.

Anche i middleware si sono dovuti evolvere per venire incontro alle nuove esigenze degli

ambienti mobili in cui molte delle problematiche classiche dei sistemi distribuiti

tradizionali sono cambiate; oltre all’eterogeneità hardware e software, per gli ambienti

mobili si parla di connessione intermittente e di presenza di dispositivi con capacità

limitate in termini di elaborazione e memoria.

- 5 -

Introduzione

I middleware permettono di risolvere le problematiche legate al mobile computing, ma

non offrono direttamente librerie per poter sviluppare quei servizi, prima accennati, che

oggi si stanno diffondendo negli ambienti mobili.

Nasce, quindi, l’idea di realizzare un’infrastruttura (framework) software che offra già

delle librerie per realizzare servizi quali Instant messaging, VoIP, GPS, ecc, avendo allo

stesso tempo proprietà middleware per mascherare i problemi dovuti all’eterogeneità dei

sistemi mobili. L’obiettivo finale è quello di fornire agli sviluppatori un framework che

permetta di realizzare servizi per dispositivi mobili senza doversi preoccupare né di

problemi di mobile computing né di implementare i servizi da zero.

Scopo di questa tesi è la definizione dell’architettura del framework, definendo i requisiti

funzionali, cioè i servizi che devono essere offerti, e i requisiti non funzionali. Si andranno

anche a studiare le diverse tecnologie middleware tra quelle oggi sviluppate, scegliendo la

più adatta per realizzare il framework core, lo strato intermedio tra le applicazioni utenti e

i servizi offerti dal framework stesso. In ultimo, si presenterà lo sviluppo di uno dei

servizi, verrà mostrata la fase di progettazione e le scelte implementative con le relative

motivazioni che hanno portato alla realizzazione del servizio.

Il presente lavoro di tesi, coerentemente con quanto affermato prima, è diviso nei seguenti

capitoli:

Nel primo capitolo si introducono i sistemi mobili con le loro peculiarità, classificandoli e

presentando le relative problematiche. Poi vengono presentati gli scenari applicativi, in cui

operano i sistemi mobili, evidenziando come alcuni servizi vengono utilizzati nei diversi

contesti. Si conclude il capitolo trattando i middleware, mostrando la differenza tra i

middleware per sistemi distribuiti tradizionali e per sistemi mobili, e in particolare ci si

soffermerà sui middleware per ambienti mobili.

Nel secondo capitolo si espongono le motivazioni che hanno portato a decidere di

realizzare il framework. Si riporta la specifica dei requisiti di quest’ultimo, elencando e

descrivendo i servizi che faranno parte del framework quando sarà ultimato. Si descrive,

poi, l’architettura del framework, mostrando i diversi scenari di funzionamento. In ultimo,

si riportano i risultati dello studio di fattibilità per la scelta della tecnologia middleware da

- 6 -

Introduzione

utilizzare per realizzare il core del framework con una breve descrizione delle tecnologie

esaminate.

Nel terzo capitolo si tratta, in maniera dettagliata, la progettazione di un singolo servizio

facente parte del framework, in particolare un servizio di messaggistica istantanea,

descrivendo brevemente cosa si intende per servizio di messaggistica istantanea. Si

riportano i diversi diagrammi UML che sono stati realizzati nel corso dello sviluppo del

servizio come il diagramma dei casi, il diagramma delle classi e altri, concludendo con la

progettazione dei test case per i metodi del servizio che si interfacciano con l’utente.

Nel quarto capitolo, invece, si riportano le scelte implementative, in particolare si descrive

il funzionamento di due delle più importanti classi implementate e come pubblicare una

classe Java come Web Services tramite il tool Axis. Poi si riportano i risultati della fase di

testing e si mostra un esempio di funzionamento di una applicazione per dispositivi mobili

che sfrutta il servizio di messaggistica istantanea realizzato.

Si conclude la tesi con un ultimo capitolo in cui si espongono i possibili sviluppi futuri del

framework e come quest’ultimo possa essere migliorato ancora.

- 7 -

Capitolo 1

Soluzioni middleware per ambienti mobili

1.1 Mobile Computing 1.1.1 Introduzione ai sistemi distribuiti mobili

I sistemi distribuiti, intuitivamente, si possono definire come una collezione di componenti

software distribuiti su più nodi di elaborazione connessi attraverso una rete telematica.

Una definizione più formale può essere la seguente:

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.

(G. Coulouris et al.)

Oggi sempre più i componenti, facenti parte di un sistema distribuito, sono collegati

tramite tecnologia wireless. Questi componenti mobili possono connettersi ripetutamente

alla rete, e disconnettersi, indipendentemente dalla loro locazione. Tale scenario

informatico, definito dall’insieme di queste infrastrutture e dal software che permette di

utilizzarle, viene definito come mobile computing. Pertanto si può definire il mobile

computing come un modello di elaborazione riferito ad un sistema distribuito in cui vi sia

mobilità dell’hardware e presenza di tecnologie di comunicazione senza cavo. Oltre alla

mobilità dei componenti la caratteristica principale di tali sistemi è la comunicazione,

garantita da tecnologie di comunicazione senza filo, in maniera “intermittente” cioè

- 8 -

Capitolo 1 Soluzioni middleware per ambienti mobili

caratterizzata da una modesta banda, spesso variabile, ed un Bit Error Rate (BER)

influenzato fortemente da agenti esterni, tutto ciò comporta delle problematiche nuove

rispetto ai sistemi distribuiti classici in cui i componenti sono fissi e il collegamento alla

rete è sempre presente a meno di guasti e la comunicazione è permanente cioè

caratterizzata da un’elevata banda ed un basso BER.

1.1.2 I dispositivi mobili

I dispositivi (o device) sono una singola unità del sistema distribuito dotato di capacità

elaborativa. Essi si possono classificare in base alle proprietà di mobilità spaziale:

Fisso: dispositivi generalmente potenti e alimentati dalla rete elettrica con grandi

quantità di memoria e processori veloci;

Mobile: tipicamente dotati di scarse capacità elaborative e problemi di

alimentazione che inficiano la loro disponibilità nel tempo.

Oppure si possono classificare secondo la loro specificità (embeddedness) cioè il grado di

specificità del compito per cui viene progettato un dispositivo nonché il livello di

integrazione raggiunto nel costruire il dispositivo che assolve il determinato compito:

General-purpose: un dispositivo è general-purpose quando non è progettato per

rispondere a compiti specifici (PDA, laptop, PC …);

Special-purpose: un dispositivo è special-purpose quando è progettato per

rispondere a compiti specifici (microcontrollori, sensori, badges …).

Attualmente i dispositivi mobili o portabili sono:

- 9 -


PDA (Personal Digital Assistant) cioè i palmari;

Smartphone cioè un dispositivo portatile che abbina funzionalità di gestione di dati

personali e di telefono;

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

Microcontrollori, sensori e attuatori presenti nei sistemi di controllo.

1.1.3 Classificazione dei sistemi mobili

I sistemi mobili si possono dividere in tre categorie:

I sistemi Nomadici (Nomadic Computing): rappresentano un compromesso tra i

sistemi totalmente fissi e totalmente mobili; 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”.

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. Costituiti da un

insieme di dispositivi mobili, tipicamente general-purpose, connessi tra di loro

- 10 -


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.

I sistemi Pervasive & Ubiquitous: 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 se, 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. Le Wireless Sensor

Network sono un esempio di sistema pervasive & ubiquitous.

1.1.4 Problematiche relative ai sistemi mobili

Ci sono diverse problematiche connesse allo sviluppo di applicazioni per sistemi mobili.

Tra le più importanti, si annoverano:

Eterogeneità: i sistemi mobili sono fortemente eterogenei secondo diversi aspetti:

hardware dei dispositivi, che spaziano dai Supercomputer con molte risorse

hardware a disposizione fino ai palmari con poche risorse hardware a

disposizione;

- 11 -


software di base, in particolare i sistemi operativi che si differenziano tra

quelli specifici e più adatti per le macchine server aventi a disposizione

grandi risorse fino ad arrivare ai sistemi operativi utilizzati sui palmari o

anche su cellulari che hanno poche risorse in termini di capacità elaborativa

e memoria disponibile;

linguaggi di programmazione, che variano da quelli tradizionali per le

applicazioni gestionali come il Cobol, a quelli per le applicazioni

matematiche come il Fortran oppure ancora a quelli orientati agli oggetti

come il C++, Java e altri;

protocolli di rete e le infrastrutture di rete poiché si hanno diverse tecnologie

di interconnessione per i dispositivi come le reti WLAN (wireless local area

network) o le reti wireless che hanno differenti capacità e usano diversi

protocolli.

Un altro aspetto che si deve considerare, per quanto riguarda l’eterogeneità dei sistemi

distribuiti, è che , oggi, c’è la tendenza a riutilizzare sempre più componenti o elementi

software preesistenti già sviluppati in passato ed integrarli tra loro; o ancora integrare

applicazioni commerciali (COTS) di diverse aziende o cercare di utilizzare ancora sistemi

datati che però continuano a fornire i loro servizi..

Adattamento: le applicazioni devono poter essere semplicemente estese a fronte di

cambiamenti nei requisiti funzionali o adattate alle nuove tecnologie emergenti.

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

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

- 12 -


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

elaborazione.

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

transazioni e la garanzia dell’accesso in sicurezza.

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.

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

alle applicazioni di reagire a variazioni dello stesso.

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.

- 13 -


1.2 Scenari applicativi

I sistemi mobili sono caratterizzati da un elevato grado di mobilità e dinamicità e vedono

sempre più la presenza di dispositivi specializzati per l’ambiente in cui operano. Essi sono

rivolti a scenari in cui le persone portano con sé i propri PDA (Personal Digital Assistant)

e wearable computer, ed interagiscono con l’ambiente “intelligente” circostante. Nei

seguenti sottoparagrafi si descrivono alcuni esempi in cui è applicato il mobile computing.

1.2.1 Domotica o Casa intelligente

Con "casa intelligente" si indica un ambiente domestico opportunamente progettato e

tecnologicamente attrezzato al fine di rendere più agevoli le attività all'interno

dell'abitazione (quali accensione luci, attivazione e comando elettrodomestici, gestione

climatizzazione, apertura di porte e finestre, ecc.), di aumentarne la sicurezza (controllo

anti-intrusione, fughe di gas, incendi, allagamenti, ecc.) e di consentire la connessione a

distanza con servizi di assistenza (tele-soccorso, tele-assistenza, tele-monitoraggio, ecc.).

Ad un livello superiore si parla di "building automation" o "automazione degli edifici".

L'edificio intelligente, con il supporto delle nuove tecnologie, permette la gestione

coordinata, integrata e computerizzata degli impianti tecnologici (climatizzazione,

distribuzione acqua, gas ed energia, impianti di sicurezza), delle reti informatiche e delle

reti di comunicazione, allo scopo di migliorare la flessibilità di gestione, il comfort, la

sicurezza, il risparmio energetico degli immobili e per migliorare la qualità dell'abitare e

del lavorare all'interno degli edifici.

Con l'espressione "casa intelligente", allora, si definisce l'integrazione di diversi dispositivi

per il controllo automatizzato di apparati domestici, di sensori di misurazione dello stato

dell'ambiente, di funzioni intelligenti di supporto e di sistemi telecomunicativi per

l'accesso alle funzioni da remoto o per l'assistenza a distanza. Quindi, lo scopo ultimo di

un sistema della domotica è il controllo totale di tutti i servizi e la possibilità di realizzare

- 14 -


nuove operazioni complesse, possibili solo nel caso in cui diversi sistemi semplici siano

connessi e controllati in modo intelligente.

Le aree di automazione possibili in una casa sono:

1. Gestione dell'ambiente (microclima e requisiti energetici),

2. Gestione degli apparecchi,

3. Comunicazione e informazione,

4. Sicurezza.

Ogni area è, a sua volta, suddivisa in sottoaree specifiche del settore, ad esempio:

La gestione degli apparecchi domestici si suddivide:

lavatrice e asciugatrice,

lavastoviglie,

frigoriferi e congelatori,

cucine e forni,

apparecchi idrosanitari, sauna, idromassaggio.

Il settore dei cosiddetti elettrodomestici “bianchi” è quello in maggior evoluzione, grazie

alla massiccia introduzione di componenti elettronici che ne consentono il miglioramento

delle prestazioni, delle funzionalità, e dell'affidabilità. Ad esempio una lavatrice o una

lavastoviglie potrebbe generare un sms di alert, inviato direttamente al dispositivo mobile

per avvertire che il lavaggio è terminato; in maniera simile si potrebbero comportare un

forno, inviando un sms di alert per avvertire la fine di una cottura.

Invece, la comunicazione e informazione si suddivide:

telefono analogico o VoIP,

segreteria telefonica,

- 15 -


citofono o videocitofono,

fax,

comunicazioni interne (telefoniche o citofoniche),

accesso Internet a banda larga (DSL, fibra ottica, ecc.),

trasmissione dati per controllo remoto, anche via SMS,

informazioni e svago con sistemi audio-video (televisori, radio, dvd player, cd

player, mp3 player, ricevitore satellitare, pay tv, ecc.).

In un sistema domotico integrato rientra poi la gestione delle comunicazioni entranti e

uscenti dalla casa. Le chiamate telefoniche o citofoniche, interne o esterne, sono

automaticamente, e non indistintamente, indirizzate ai giusti apparecchi.

Avendo un collegamento ad Internet a banda larga, si potrebbe telefonare utilizzando

direttamente il dispositivo mobile tramite chiamata VoIP (Voice over IP) per tutta la casa,

spostandosi da una camera e l’altra, senza dover pagare alcun operatore telefonico.

Un sistema di gestione delle sorgenti audio-video permette la loro diffusione nei vari

ambienti dell'abitazione in base alle richieste dell'utente. Trasformando tramite un

interfacciamento con le periferiche audio-video, come la televisione, il proprio dispositivo

mobile in un telecomando così da comandare con un unico dispositivo le diverse

periferiche come il video registratore o il lettore DVD.

In ultimo anche la sicurezza si suddivide:

gestione accessi,

protezione antifurto, antintrusione, antirapina, perimetrale,

protezione antincendio, antiallagamento, da fumo o fughe di gas,

videocontrollo ambientale locale e a distanza,

telesoccorso e tele-assistenza di persone sole, anziane, disabili o ammalate.

- 16 -

http://it.wikipedia.org/wiki/Dvd

http://it.wikipedia.org/w/index.php?title=Antintrusione&action=edit

http://it.wikipedia.org/w/index.php?title=Videocontrollo&action=edit

http://it.wikipedia.org/wiki/Teleassistenza


In quest'ultima categoria rientrano funzioni particolarmente richieste dall'utenza. La

sicurezza si compone di “security”, ovvero sicurezza contro intrusioni non autorizzate o

rapine e di “safety”, ovvero sicurezza globale della casa contro fughe di gas, incendi,

allagamenti o altri eventi dannosi.

In caso di allarme, il sistema domotico, oltre ad intervenire con opportune azioni locali di

segnalazione ed intervento, tramite un invio di sms di alert, collegato con apparecchi

trasmissivi (linea telefonica, cellulare gsm, ponte radio, Internet) provvede a segnalare a

distanza l'accaduto e a richiedere l'eventuale intervento dei vigili del fuoco, della polizia,

ecc..

Se presenti delle telecamere a circuito chiuso o videocitofoni sarà possibile tramite video

streaming visualizzare sul proprio dispositivo mobile o su appositi monitor le immagini

riprese in diversi punti dell'abitazione e del giardino. Le riprese video saranno visibili da

remoto via Internet alle persone autorizzate, oppure, in caso di allarme, saranno inviate, in

automatico, come immagini a indirizzi e-mail o, come MMS, a numeri di cellulare

prestabiliti.

1.2.2 e-Health

e-Health (scritto anche ehealth) è un termine relativamente recente utilizzato per indicare

la pratica dell'healthcare attraverso il supporto di strumenti informatici, personale

specializzato e tecniche di comunicazione medico-paziente. L’e-Health è quindi il

complesso delle risorse, soluzioni e tecnologie informatiche di rete applicate alla salute ed

alla sanità.

Con tale termine si indicano diverse applicazioni, per esempio:

Electronical Media Records: permette una comunicazione semplice dei dati del

paziente tra le diverse figure professionali. Ad esempio tramite un accesso a una

banca dati (database – DB), che raccoglie tutte le cartelle cliniche dei pazienti

- 17 -

http://it.wikipedia.org/wiki/Gsm


ricoverati in un ospedale, un medico con il suo dispositivo mobile può accedere in

un qualsiasi momento alla cartella clinica desiderata per consultarla o aggiornarla.

Telemedicine: E’ l'insieme di tecniche mediche ed informatiche che permettono la

cura di un paziente a distanza o più in generale di fornire servizi sanitari a distanza.

Nell'ambito della diagnostica clinica, è possibile per un medico effettuare la

diagnosi su un paziente che non è fisicamente nello stesso posto del medico,

attraverso la trasmissione a distanza di dati prodotti da strumenti diagnostici. La

second opinion medica è una delle applicazioni più comuni nell'ambito della

telemedicina, essa consiste nel fornire una opinione clinica a distanza supportata da

dati acquisiti inviati ad un medico remoto che li analizza e li referta producendo di

fatto una seconda valutazione clinica su un paziente. Questo può avvenire tramite

una chiamata VoIP o uno scambio di messaggi tramite messaggistica istantanea tra

il medico che ha richiesto una second opinion e il medico remoto che gliela

fornisce. La classificazione più comune della telemedicina è effettuata a partire dal

settore medico al quale viene applicata: telepatologia (branca della telemedicina

che prevede il trasferimento di immagini digitali macroscopiche e microscopiche a

scopo diagnostico o educativo mediante la tecnologia informatica), teleradiologia,

telecardiologia, teledermatologia, teleriabilitazione (erogazione di servizi

riabilitativi attraverso le reti di telecomunicazione ed internet).

Evidence Based Medicine: comporta un sistema in grado di fornire informazioni

circa l'appropriato trattamento delle condizioni cliniche di un paziente. Un

professionista dell'healthcare può controllare se le sue diagnosi sono conformi alle

ricerche scientifiche accedendo, tramite dispositivo mobile, ad un database in cui

sono raccolte informazioni di medicina.

- 18 -


Consumer Health Informatics: è stata definita quella branca dell'informazione

medica che si occupa di analizzare i bisogni dei consumatori e rendere accessibili

gli studi e gli sviluppi nel campo della medicina.

Virtual healthcare teams: è composto da professionisti dell'healthcare che

collaborano fra loro e condividono le informazioni sui pazienti attraverso l'utilizzo

di apparecchiature digitali.

1.2.3 Altri scenari

Oltre alla casa intelligente e al e-Health, ci sono altri campi di utilizzo del mobile

computing:

Negli aeroporti è necessario movimentare e rintracciare merci e bagagli, effettuare

ispezioni e controlli, oltre che reagire a eventi diversi in tempo reale. La soluzioni

di mobile computing in tempo reale permette di gestire un aeroporto a intenso

traffico riducendo i costi di gestione e aumentando la sicurezza. I vantaggi sono

diversi come ridurre le lunghe code di check-in grazie ai dispositivi mobili che

snelliscono le operazioni di imbarco dei passeggeri oppure seguire il percorso dei

bagagli grazie a scanner di codici a barre e portali RFId (Radio Frequency

Identification - la tecnologia basata su onde radio che rende possibile

l'identificazione e la tracciabilità di prodotti e di altri elementi) evitando di perdere

il bagaglio o caricarlo su un aereo sbagliato.

In situazioni di emergenza una squadra di pompieri, costretta ad intervenire in

condizioni di scarsa visibilità come un edificio di grandi dimensioni in fiamme o

anche un bosco in cui è stato appiccato un incendio, può conoscere la posizione dei

singoli componenti della squadra, tramite positionig o GPS, dotando ciascun

- 19 -


membro di un dispositivo mobile opportuno, così da coordinare meglio le azioni

di soccorso. Oppure si può individuare velocemente una persona da soccorrere

qualora sia in possesso di un dispositivo mobile in grado di segnalare la propria

presenza tramite GPS.

Nei musei, le attuali audio-guide basate su informazioni pre-registrate potrebbero

essere sostituite da guide virtuali. L’utente, tramite un servizio di positioning, può

ottenere sul suo dispositivo mobile informazioni audio/video correlate alla

posizione dell'utente stesso. Quest'ultimo può chiedere maggiori informazioni

attraverso comandi vocali o spostarsi all'interno del museo e ricevere nuova

informazione dipendente dalla sua posizione. Similmente anche nelle città d’arte

un utente, tramite GPS, potrebbero ottenere sul suo dispositivo mobile

informazioni storiche dettagliate sulle opere come statue, fontane e palazzi storici

semplicemente avvicinandosi alle diverse opere evitando ingombranti guide

cartacee. I dispositivi mobili potrebbero in questo modo ricevere informazione

sempre più legate al contesto e i luoghi, dal canto loro, potrebbero iniziare a

parlare e raccontare la loro storia.

Ancora un altro scenario in cui possono essere applicate soluzioni di mobile

computing, è il miglioramento del lavoro dei vigili urbani. Si immagini di fornire

ad ogni pattuglia un dispositivo mobile (es. un palmare) con cui i vigili possono

effettuare le dovute sanzioni tramite un’applicazione opportuna, decidendo o no di

stampare la multa tramite una stampante collegata con bluetooth al palmare situata

in auto (caso di interfacciamento con periferiche esterne). Inoltre, tornando in

caserma, il palmare automaticamente, collegandosi al database, in cui sono

raccolte tutte le informazioni relative alle sanzioni effettuate, può aggiornarlo

inserendo le nuove sanzioni effettuate (caso di accesso ad un DB).

- 20 -


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, come

Positioning, GPS, Instant messaging, VoIP, Accesso DB, Interfacciamento con periferiche

esterne, Gestione canale SMS per notifiche ed alert, Video streaming.

In conclusione si evince la necessità di creare soluzioni che facilitino l’integrazione dei

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

considerando anche le diverse problematiche, precedentemente analizzate, degli ambienti

mobili. Inoltre, non è difficile pensare che alcuni servizi si estendono dai terminali fissi a

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

Nel mobile computing nessun dispositivo si può 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.

- 21 -


1.3 I Middleware 1.3.1 Introduzione ai middleware e loro proprietà

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

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 abbiano una vista

omogenea dei livelli sottostanti.

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.

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

trasparenza del sistema operativo,

trasparenza del linguaggio di programmazione,

trasparenza della locazione (location transparency),

trasparenza della migrazione (migration transparency),

trasparenza ai guasti (failure transparency),

trasparenza della replicazione (replication transparency),

trasparenza delle implementazioni commerciali,

- 22 -


1.3.2 Differenze tra middleware per sistemi tradizionali e per sistemi mobili

A un middleware per ambienti distribuiti tradizionali è richiesto che i meccanismi di

trasparenza introdotti rispondano a requisiti non funzionali quali scalabilità, eterogeneità,

gestione dei guasti, apertura e condivisione delle informazioni. 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 varie

circostanze in cui ci si trovano 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 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:

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.

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

- 23 -


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, un paradigma di comunicazione

sincrono deve inevitabilmente lasciare posto ad un paradigma di comunicazione

asincrono, in cui non è richiesto che client e server siano connessi

simultaneamente.

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 per sistemi distribuiti

tradizionali e per i sistemi mobili:

MIDDLEWARE CARICO COMUNICAZIONE CONTESTO

Sistemi Distribuiti Tradizionali

Pesante (dispositivi

fissi e potenti)

Sincrona (connessione permanente)

Statico (il MW nasconde i dettagli sul contesto

di esecuzione)

Sistemi Mobile Computing

Leggero (dispositivi

mobili e poco potenti)

Asincrona (connessione intermittente)

Dinamico (le applicazioni prendono decisioni

strategiche)

Tabella 1.1 - Caratteristiche dei middleware per sistemi distribuiti tradizionali e per i sistemi mobili

- 24 -


Esempi di middleware per sistemi distribuiti tradizionali sono:

Remote Procedure Call - RPC (SunRPC),

Distributed Objects Middleware – DOM (Sun RMI, OMG CORBA),

Message Oriented Middleware – MOM (IBM MQSeries),

Transaction Processing – TP (X/Open DTP).

1.3.3 Middleware per sistemi mobili

Ci sono due possibili strade per realizzare un middleware per ambienti mobili:

1. Middleware tradizionali applicati ai sistemi mobili;

2. Middleware per sistemi mobili:

a. Context-aware middleware,

b. Data sharing-oriented middleware,

c. Tuple space middleware.

La prima strada consiste nell’adattare i middleware per i sistemi distribuiti tradizionali agli

ambienti di 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 tradizionali ad

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

termini di risorse richieste (memoria, calcolo, banda), e di introdurre il supporto alle

disconnessioni e alla gestione degli handoff.

- 25 -


Tra i middleware object-oriented applicati ai sistemi mobili, è sicuramente un esempio

rilevante wireless CORBA (wCORBA) [1]. Esso è l’adattamento di CORBA (Common

Object Request Broker Architecture) dell’ OMG (Object Management Group) agli

ambienti con accesso wireless e terminali mobili. I principi di progetto basilari sono stati

la trasparenza e la semplicità degli ORB (intermediario di richiesta ad un oggetto, Object

Request Broker) destinati ai dispositivi mobili. La trasparenza consiste nel nascondere agli

ORB preesistenti, e quindi non mobili, la presenza dei meccanismi per la gestione della

mobilità introdotti negli ORB per terminali mobili. In questo modo gli ORB non mobili

non debbono implementare nuove funzionalità per interoperare con gli oggetti CORBA

eseguiti sui terminali mobili. La semplicità è necessaria al fine di non sovraccaricare i

dispositivi mobili, ed è ottenuta fornendo alle applicazioni CORBA un insieme minimo di

funzionalità. In analogia ai sistemi di telecomunicazione cellulare, la specifica wireless

CORBA introduce tre domini:

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

Contiene lo Home Location Agent, che tiene traccia della locazione del terminale.

2) Terminal domain: la parte di infrastruttura residente sul dispositivo mobile. Tutte

le invocazioni CORBA passano per un’unica interfaccia di uscita, il Terminal

Bridge, che comunica con la sua controparte fissa, l’Access Bridge.

3) Visited domain: contiene l’Access Bridge, che inoltra sulla rete fissa le richieste

pervenute dal Terminal Bridge.

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.

Il contesto di esecuzione include:

- 26 -


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

positioning) del dispositivo;

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

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

screen, tastiera cellulare);

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

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

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

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

propria interpretazione - B. Smith, 1982).

Un sistema reflective può modificare se stesso attraverso due meccanismi:

Ispezione: un esame del comportamento interno, che deve essere esposto

all’applicazione.

Adattamento: il comportamento interno può essere cambiato aggiungendo nuove

caratteristiche o modificando le esistenti.

Un reflective middleware incorpora solo le funzionalità di base (dimensioni e carico

ridotti): è l’applicazione che monitora e adatta il comportamento del middleware alle

proprie esigenze.

Esempi di context-aware middleware sono OpenORB [2], OpenCORBA [3], dynamicTAO

[4] che sono middleware tradizionali estesi con il concetto di reflection. Altro esempio è

Gaia [5] che definisce il concetto di Active Space, dove servizi, utenti, dati e locazioni

- 27 -


sono rappresentati e manipolati dinamicamente e in coordinazione. L’idea di tale

soluzione è 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.

I data sharing-oriented middleware, invece, offrono il supporto alle “disconnected

operations” (operazioni su dati durante un periodo di disconnessione dalla rete) [6],

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, e cioè, nel modo in cui vengono individuati e risolti i conflitti che avvengono

naturalmente nei sistemi mobili.

Un esempio è Coda File System [7] 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 [8] che consente ai dispositivi mobili di condividere dati mentre

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. Non c’è infrastruttura fissa:

sistemi ad hoc.

In ultimo ci sono anche i tuple space middleware 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 ad accesso per

tipo e contenuto, non per indirizzo. La lettura richiede una tupla-modello (pattern), da

confrontare con le tuple presenti nello spazio. Un esempio è Linda [9], uno dei primi

- 28 -


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.

Oltre ai middleware di diverse tipologie che sono stati presentati in questo paragrafo, non

si possono non menzionare anche i Web Services (WS) [10], che hanno caratteristiche, che

si descriveranno nel capitolo successivo, differenti dai middleware fino adesso presentati.

Anche loro, però, ed è questa la caratteristica più importante, offrono livelli di trasparenza

rispetto al problema dell’eterogeneità e di locazione.

- 29 -

Capitolo 2

Un'infrastruttura per l'integrazione di servizi in ambienti mobili 2.1 Introduzione

Nel capitolo precedente sono stati introdotti i sistemi mobili e le loro problematiche, i

diversi scenari applicativi e le tecnologie, oggi a disposizione, per poter sviluppare

applicazioni mobili distribuite.

Dagli scenari applicativi è emersa, allora, l’esigenza di avere un’infrastruttura software

che permetta di poter sviluppare applicazioni per sistemi mobili, che offrano uno o più

servizi come ( VoIP o Instant messaging), in maniera semplice, immediata e trasparente.

Lo scopo di tale infrastruttura è che lo sviluppatore di applicazioni non deve preoccuparsi

di problemi legati alla eterogeneità o altre problematiche del mobile computing, e ha a

disposizione già tutte le librerie per sviluppare dei servizi per dispositivi mobili come il

VoIP, il GPS, l’Instant messaging, ecc.

Inoltre il framework deve avere anche un servizio di autoconfigurazione ed

autodeployment. 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 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 del deployment dei servizi di cui necessita l’applicazione.

- 30 -

Capitolo 2 Un’infrastruttura per l’integrazione di servizi in ambienti mobili

L’obiettivo finale è quello di avere un framework che risieda sul dispositivo mobile (es.

palmare) con il compito di facilitare la realizzazione di applicazioni che ne sfruttino i

servizi in modo trasparente.

Lo sviluppo e la progettazione di tale infrastruttura (Progetto CRONOS) avviene tramite la

collaborazione dell’Università degli studi di Napoli Federico II, in particolare del DIS

(dipartimento di informatica e sistemistica della facoltà di ingegneria), e l’azienda Wi-Fi

People, operante nel settore dell’informatica.

Di seguito si riporta la descrizione sia dei requisiti funzionali che dei requisisti non

funzionali, dell’infrastruttura (o anche detta framework), presa dal documento di specifica

dei requisiti (DSR) approvato da entrambi le parti.

2.2 Specifica dei requisiti 2.2.1 Scopo del sistema

Il sistema deve fornire un insieme di servizi organizzati in un framework così da

permettere lo sviluppo di applicazioni per dispositivi mobili.

I diversi servizi rappresentano i requisiti funzionali del sistema che, nel secondo punto,

andremo ad elencare e descrivere.

2.2.2 Requisiti funzionali

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.

- 31 -


Discovery dei servizi:

Il servizio permette al dispositivo di scoprire quali servizi sono disponibili sulla rete e

indicarne la disponibilità. Ovviamente 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.

GPS / Positioning:

Si intende fornire un servizio per la localizzazione del dispositivo mobile in un ambiente

fisico indoor e in un ambiente fisico outdoor attraverso le sue coordinate GPS. Per fornire

la localizzazione indoor è possibile utilizzare indistintamente la tecnologia Bluetooth

oppure la tecnologia WIFI. L’ambiente indoor, nel quale si intende localizzare la

posizione del dispositivo, dovrà essere opportunamente cablata con Access Point WIFI o

Bluetooth. Invece, per fornire la localizzazione outdoor il palmare che offre tale servizio

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.

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

- 32 -


tecnologia Voip richiede due tipologie di protocolli di comunicazione in parallelo, uno è

per il trasporto dei dati (pacchetti voce su rete IP) e si utilizza il protocollo RTP. L’altro

protocollo riguarda la codifica della segnalazione della conversazione e sono possibili

diversi protocolli alternativi:

SIP (Session Initiation Protocol) della IETF;

H.323 della ITU;

IAX, (soppiantato da IAX2) usato dai server Asterisk open source PBX e dai

relativi software client;

XMPP, inizialmente pensato per l'Instant Messaging ed esteso a funzioni Voip

grazie al modulo Jingle.

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 prevede che un utente, attraverso un dispositivo mobile, si connetta ad un server

remoto o ad un altro dispositivo e che riceva da esso un flusso video proveniente

direttamente da una videocamera, come ad esempio una webcam installata sul proprio

dispositivo o posta nella propria stanza, laboratorio, etc…, o da un file memorizzato su

disco.

- 33 -


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.

2.2.3 Requisiti non funzionali

Trasparenza dal linguaggio:

Si intende l’indipendenza da un qualsiasi linguaggio di programmazione con cui sono

implementati i componenti software che devono interagire con il framework. Ciò prevede

la omogeneizzazione dei dati tramite il marshalling e unmarshalling dei dati.

Trasparenza dal Sistema Operativo (SO):

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 le applicazioni utente e i servizi a prescindere dai

protocolli di rete e dalle infrastrutture di rete utilizzate

- 34 -


Load balancing:

Con load balancing si intende la possibilità di distribuire il carico, cioè l'ottimizzazione

dell’utilizzo delle risorse di calcolo in modo 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, 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.

Prestazioni:

Inizialmente non si darà peso ai limiti tecnologici imposti dai dispositivi mobili presenti

attualmente sul mercato, puntando ad una prima soluzione 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à:

Si intende la capacità del framework, in particolare dei servizi, di essere modificato, cioè

di subire operazioni di manutenzione evolutiva e/o correttiva in maniera semplice ed

immediata. Le modifiche, quindi, prevedono correzioni, miglioramenti o adattamenti del

framework e dei suoi servizi per cambiamenti nell’ambiente operativo, nei requisiti e nelle

specifiche.

- 35 -


2.3 Progettazione del Framework

2.3.1 Architettura del Framework

Il framework sarà formato da un insieme di componenti, ognuno rappresentante un

servizio. I componenti sono indipendenti tra loro, ciò vuol dire che un utente ha la facoltà

di scegliere solo i servizi che gli interessano realmente senza dover installare sul proprio

dispositivo l’intero framework così da non occupare in memoria più spazio del dovuto.

Figura 2.1 – Architettura Framework

I componenti evidenziati in verde (figura 2.1) rappresentano le funzionalità di gestione del

framework, quali il discovery, l’aggiornamento del framework o di una parte di esso e il

download del framework o solo della parte di interesse per l’utente.

I componenti evidenziati in azzurro (figura 2.1) rappresentano, invece le altre funzionalità,

cioè i servizi veri e propri, quali Instant messaging, VoIP, GPS, ecc. Quest’ultimi offrono

delle API per poter sviluppare una propria applicazione o integrare il servizio con

un’applicazione già esistente, oppure possono essere utilizzati direttamente per avere

l’esecuzione del servizio stesso.

- 36 -


Anche l’implementazione stessa dei singoli servizi è indipendente dagli altri, ogni

componente può essere implementato una volta utilizzando un unico determinato

linguaggio di programmazione, poi sarà compito del framework core rendere accessibile a

una qualsiasi applicazione i diversi servizi implementati, risolvendo i problemi di

eterogeneità tra l’applicazione ed i componenti. Questa scelta viene incontro anche al

requisito di manutenibilità di tutto il framework, perché un’operazione di manutenzione

non deve essere eseguita su diverse implementazioni di uno stesso componente in

linguaggi diversi riducendo così la durata del lavoro di manutenzione, ed evitando anche

eventuali differenze tra due diverse implementazioni.

Un’applicazione, implementata in qualsiasi linguaggio di programmazione, come mostrato

in figura 2.1, può, allora, usufruire dei servizi del framework, accedendo al servizio

tramite il framework core che funge da middleware vero e proprio.

- 37 -


2.3.2 Deployment Diagram

Una volta completato, il framework verrà installato direttamente su un dispositivo mobile

(es. palmare). La comunicazione tra i due dispositivi equipaggiati entrambi del framework

sarà diretta senza la necessità di alcuna infrastruttura fissa intermediaria, come è

rappresentato in figura 2.2:

Figura 2.2 – Comunicazione diretta tra due framework

Oltre allo scenario applicativo sopra descritto, ci sono altri scenari che si possono venire a

creare.

- 38 -


Si pensi a due utenti con i loro dispositivi su cui è installato il framework che vogliono

comunicare tra loro con il servizio di Instant messaging (IM), ma uno dei due (dispositivo

mobile B in figura 2.3) ha una versione più vecchia dell’altro (dispositivo mobile A in

figura 2.3). Allora, prima di instaurare la comunicazione tramite IM, l’utente del

dispositivo mobile B può decidere di aggiornare la versione del suo servizio di IM,

scaricando gli aggiornamenti direttamente dal dispositivo mobile A dell’altro utente

(figura 2.3).

Figura 2.3 – Aggiornamento del servizio IM

n altro possibile scenario è quello in cui uno dei due utenti non ha proprio alcuna U

versione del servizio IM, pur avendo il framework installato sul suo dispositivo

(dispositivo mobile B in figura 2.4). Allora può decidere di scaricare il servizio di Instant

messaging, sempre dal dispositivo mobile A dell’altro utente (figura 2.4).

- 39 -


Figura 2.4 – Download del servizio IM

Un ultimo possibile scenario prevede che l’utente che non ha sul suo dispositivo il servizio

di Instant messaging (dispositivo mobile A in figura 2.5), può decidere di sfruttare come

server l’altro dispositivo (dispositivo mobile B in figura 2.5) demandando l’esecuzione del

componente IM senza dover scaricare sul suo dispositivo il componente stesso, ma

usufruendo ugualmente del servizio (figura 2.5).

Figura 2.5 – Esecuzione demandata del servizio IM

- 40 -


Con i diversi scenari applicatavi presentati in precedenza, si è dimostrato come il

framework, oltre ai requisiti funzionali, rispetti anche i diversi requisiti non funzionali

come la portabilità dei servizi (figura 2.4 – un servizio può essere scaricato se non

presente sul dispositivo), il load balancing (figura 2.5 – l’esecuzione di un servizio può

essere demandata a un altro dispositivo) o la manutenibilità (figura 2.3 – si può aggiornare

un servizio se è una vecchia versione).

Un’altra possibilità di deployment è quella di installare l’intero framework su un server

remoto e sui dispositivi mobili i client per accedere ai servizi offerti dal framework. Ciò

permette anche a quei dispositivi mobili, non ancora con le necessarie risorse hardware per

sostenere il carico computazionale legato al framework e ai servizi, di usufruire

ugualmente dei servizi del framework (figura 2.6).

Figura 2.6 – Framework installato su un server

Volendo mantenere i servizi sul palmare, un’ulteriore soluzione potrebbe essere effettuare

un linking diretto tra client e servizio. Il vantaggio è che si recupera in prestazioni per il

dispositivo mobile, ma si perde la trasparenza del linguaggio. Per recuperarla si può

- 41 -


implementare i servizi in ciascun linguaggio di programmazione e per ogni piattaforma

per cui si vuole realizzare il corrispondente client. Lo sforzo per questo tipo di soluzione è

notevole, inoltre la soluzione stessa si mostra poco lungimirante, nonché difficilmente

manutenibile. Poiché tale soluzione costringe ad intervenire su più implementazioni in

linguaggi diversi dello stesso servizio su cui si vuole modificare. In tal caso risulta anche

difficile mantenere una certa coerenza tra tutte le implementazioni possibili. 2.4 Studio delle tecnologie per la realizzazione del Framework Core In questo paragrafo si riportano e si riassumono i risultati di uno studio di fattibilità sulle

possibili tecnologie da poter utilizzare per la realizzazione del framework core. Per una

più veloce comprensione delle caratteristiche delle tecnologie esaminate e farne un

confronto rapido, è stata realizzata una griglia (griglia di fattibilità) su cui sono riportati i

risultati dello studio di fattibilità.

2.4.1 Tecnologie middleware prese in esame

Il framework core è quello strato intermedio tra i servizi e le applicazioni sia per lo

sviluppo di quest’ultime che per l’accesso ai servizi da parte dell’utente, per cui deve

essere implementato utilizzando tecnologie middleware per risolvere i problemi di

eterogeneità che si possono presentare.

Le tecnologie esaminate sono state scelte perché sono tecnologie affermate e di sicuro

affidamento come Java RMI [11], wireless CORBA e Web Services SOA cioè con

architettura orientata ai servizi, inoltre è stata esaminata anche un nuova tecnologia

emergente, ritenuta molto interessante, Web Services REST [12], ed infine si è anche

- 42 -


valutato la possibilità di realizzare una propria tecnologia, un Protocollo proprietario

basato su XML.

I criteri con cui sono state esaminate le diverse tecnologie sono i requisiti non funzionali,

descritti in precedenza, che deve avere il framework: trasparenza dal linguaggio di

programmazione e dal SO, manutenibilità, possibilità di distribuire il carico (load

balancing) e le prestazioni che offrono.

Di seguito si descrivono brevemente le tecnologie prese in esame per la realizzazione del

framework core:

Web Sevices:

I Web Services (WS) sono un insieme di servizi distribuiti che forniscono informazioni ad

altre applicazioni e/o utenti attraverso Internet.

La definizione del W3C per i Web Services è la seguente:

A Web service is a software system desiged 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)

[Un Web Service è un’applicazione software identificata da un URI (Uniform Resource

Identifier), le cui interfacce pubbliche e collegamenti sono definiti e descritti come

documenti XML, in un formato comprensibile alla macchina (specificatamente WSDL). La

sua definizione può essere ricercata da altri agenti software situati su una rete, i quali

possono interagire direttamente con il Web Service, con le modalità specificate nella sua

definizione, utilizzando messaggi basati su XML (SOAP), scambiati attraverso protocolli

Internet (tipicamente HTTP)].

- 43 -


I Web Services permettono di far dialogare sistemi eterogenei, distribuiti e multi-

linguaggio: macchine differenti, che offrono funzioni implementate con tecnologie

diverse, che si trovano su reti distinte, gestite da aziende o persone concorrenti. Un WS è

quindi un componente modulare, autodescritto (self-contained) ed autocontenuto (self-

describing) che può essere pubblicato, individuato e invocato sul Web consentendo lo

sviluppo di applicazioni tramite composizione di sistemi eterogenei.

Le caratteristiche dei Web Services sono:

Riuso: un WS può essere visto come un componente software riusabile, sviluppato

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

Riuso dell’infrastruttura: per lo scambio di messaggi si utilizza SOAP che fa uso

di HTTP, grazie al quale si ottiene anche il vantaggio di permettere ai messaggi

SOAP di passare attraverso sistemi di filtraggio del traffico sulla rete, quali

firewall.

Interoperabilità: ottenuta attraverso l’uso esteso di XML;

Componibilità;

Indipendenza dalla piattaforma: i Web Services possono, infatti, comunicare fra

loro anche se si trovano su piattaforme differenti.

Indipendenza dall’implementazione del servizio: l’interfaccia che un Web Service

presenta sulla rete è indipendente dal software che implementa tale servizio. In

futuro tale implementazione potrà essere sostituita o migliorata senza che

l’interfaccia subisca modifiche e quindi senza che dall’esterno (da parte di altri

utenti o servizi sulla rete) si noti il cambiamento.

- 44 -


Inoltre sempre più spesso essi sono integrati nei framework di sviluppo (J2ME Web

Services (JSR 172) [13], Microsoft .NET compact framework [14]) per i sistemi mobili.

I Web Services possono essere realizzati ed utilizzati secondo diversi stili architetturali. Le

tre architetture più comuni sono:

Remote Procedure Call (RPC),

Service Oriented Architecture (SOA),

REpresentational State Transfer (REST).

In particolare i WS che utilizzano uno stile basato su chiamate remote di procedure (RPC)

presentano un'interfaccia distribuita per l'invocazione di metodi o procedure. I WS di

questo tipo hanno il difetto di “mappare” i servizi direttamente su funzioni o metodi del

linguaggio che realizza l'agente software: modificando l'agente cambia anche il servizio.

I WS basati su RPC sono proibiti dalla WS-I (Web Services Interoperability

Organization), e sebbene siano stati i primi WS realizzati adesso non dovrebbero essere

più implementati.

I WS con architettura orientata ai servizi risolvono i problemi di accoppiamento fra

servizio ed agente software concentrandosi sull'interfaccia e non sui dettagli di

implementazione. I WS SOA comunicano scambiando messaggi invece di richieste di

procedure.

I WS che adottano una architettura REST hanno l'interfaccia ristretta alle sole operazioni

permesse dal protocollo HTTP 1.1. L'interazione non avviene per mezzo di chiamate di

- 45 -


procedure o invio di messaggi, ma scambiando rappresentazioni dello stato delle risorse.

Si approfondiranno i WS realizzati tramite questa architettura più avanti.

L’ architettura dei WS SOA è divisa in tre blocchi, tutti basati su XML (eXtensible

Markup Language – meta linguaggio per la specifica di linguaggi di markup):

Figura 2.7 – WS stack

UDDI (Universal Description Discovery Integration): è la tecnologia che permette la

pubblicazione e l’individuazione dei servizi all’interno della rete. Fornisce ai client un

meccanismo di ricerca dei WS. Un registro UDDI è simile ad un “CORBA trader o

naming”, o ad un DNS di applicazioni.

WSDL (Web Service Description Language): è il linguaggio che descrive (in XML)

l’interfaccia di un Web Service, specificando i servizi che offre, le operazioni possibili e le

modalità di interazione.

SOAP (Simple Object Access Protocol): è un protocollo per lo scambio di messaggi basati

su XML. Fornisce un sistema standard per costruire messaggi di richiesta e le risposte

fornite dai singoli servizi.

- 46 -


Java RMI:

Java RMI è una tecnologia che consente ad applicazioni Java distribuite di comunicare

attraverso una rete. Questa tecnologia include una API (application programming

interface) il cui scopo esplicito è quello di rendere trasparenti al programmatore quasi tutti

i dettagli della comunicazione su rete. Essa consente infatti di invocare un metodo di un

oggetto remoto (cioè appartenente a un diverso processo, potenzialmente su una diversa

macchina) quasi come se tale oggetto fosse "locale" (ovvero appartenente allo stesso

processo in cui viene eseguita l'invocazione). In questo senso, la tecnologia RMI può

essere ricondotta, da un punto di vista concettuale, all'idea di chiamata di procedura

remota riformulata per il paradigma object-oriented (in cui, appunto, le procedure sono

sostituite da metodi).

L'utilizzo di un meccanismo di invocazione remota di metodi in un sistema object-oriented

comporta notevoli vantaggi di omogeneità e simmetria nel progetto, poiché consente di

modellare le interazioni fra processi distribuiti usando lo stesso strumento concettuale che

si utilizza per rappresentare le interazioni fra i diversi oggetti di una applicazione, ovvero

la chiamata di metodo. Per contro, meccanismi di comunicazione fra processi remoti più

primitivi (come lo scambio messaggi) rappresentano una forma di interazione "estranea" al

paradigma object-oriented.

Wireless CORBA:

CORBA (Common Object Request Broker Architecture) è uno standard sviluppato da

OMG (Object Management Group) per permettere la comunicazione fra componenti

indipendentemente dalla loro distribuzione sui diversi nodi della rete o dal linguaggio di

programmazione con cui siano stati sviluppati.

Esso facilita lo sviluppo di sistemi distribuiti fornendo:

- 47 -


una infrastruttura per permettere la comunicazione fra oggetti in un sistema

distribuito,

un set di servizi utili,

un supporto che permette ad applicazioni, implementate usando vari linguaggi, di

interoperare.

I vari componenti comunicano attraverso il broker che può essere visto come

l'intermediario. I componenti sono "presentati" al broker attraverso la scrittura di

un'interfaccia nel linguaggio IDL (Interface Definition Language). Quest’ultimo è un

linguaggio strutturato ad oggetti che permette la definizione degli oggetti che vengono

utilizzati per l’integrazione tra i vari componenti; in altre parole permette la definizione di

moduli, interfacce (parti dichiarative delle classi), operazioni (metodi) e tipi di dati

indipendentemente dal linguaggio di programmazione che si andrà ad utilizzare per

l’implementazione.

Funzionalità simili messe a disposizione da CORBA, sono quelle ottenibili anche da Java

RMI descritta in precedenza. La differenza sta nel fatto che Java RMI può essere applicato

solo ad oggetti e componenti Java, mentre l’intento di CORBA è di far cooperare oggetti

(remoti) implementati in linguaggi differenti.

Wireless CORBA è l’adattamento della specifica OMG CORBA agli ambienti mobili. In

analogia ai sistemi di telecomunicazione cellulare, introduce tre domini:

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

Contiene l’ Home Location Agent, che tiene traccia della locazione del terminale.

2) Terminal domain: la parte di infrastruttura residente sul dispositivo mobile. Tutte

le invocazioni CORBA passano per un’unica interfaccia di uscita, il Terminal

Bridge, che comunica con la sua controparte fissa, l’Access Bridge.

- 48 -


3) Visited domain: contiene l’Access Bridge, che inoltra sulla rete fissa le richieste

pervenute dal Terminal Bridge.

REST WS:

In precedenza è stato introdotto il modello di architettura REST per i Web Services, di

seguito verrà presentato tale modello architetturale con le sue caratteristiche.

REST è l’acronimo che sta per REpresentational State Transfer. Fu teorizzato per la

prima volta nel 2000 da un dottorando dell’università di Irvine, California. La prima idea

di REST fu messa a punto nel 1994 nella forma di una serie di vincoli architetturali

derivanti dallo studio della maggior parte degli elementi costituenti il web e la loro

interazione. C’è da precisare che il modello architetturale REST non è uno standard o un

singolo protocollo. Esso infatti rappresenta solamente una guida, uno scheda di

riferimento, per realizzare dei sistemi web ben formulati, non descrive nulla riguardo la

realizzazione di WS.

Il primo aspetto fondamentale dell’architettura REST riguarda la separazione delle

funzioni all’interno di vari elementi. Questo concetto è uno dei più importanti principi

della progettazione e può essere visto come la scomposizione di un problema in

sottoproblemi più semplici.

Le funzioni e lo stato dell'applicazione sono divisi in risorse, quest’ultime sono accessibili

con una sintassi uniforme (URI). Tutte le risorse vengono manipolate tramite

rappresentazioni e non direttamente; le operazioni possibili sulle rappresentazioni delle

risorse sono un numero ristretto e ben definite. Infatti, REST limita le operazioni sulle

rappresentazioni delle risorse ai quattro metodi HTTP principali:

1. HTTP PUT → Create (SQL INSERT)

2. HTTP GET → Retrieve (SQL SELECT)

3. HTTP POST → Update (SQL UPDATE)

- 49 -


4. HTTP DELETE → Delete (SQL DELETE)

(è possibile aggiungere estensioni se necessario, come permesso da HTTP/1.1).

Come per i comandi SQL (operazioni di CRUD – Create, Retrive, Update, Delete) le

operazioni HTTP sono atomiche.

Il secondo aspetto fondamentale riguarda il mantenimento dello stato della

comunicazione. Secondo REST la comunicazione deve essere rigorosamente stateless

(senza stato), ogni messaggio dovrebbe contenere tutto lo stato dell'applicazione. Questo

vincolo limita solo il lato server, mentre il client di fatto può mantenere lo stato della

comunicazione. Una scelta di questo tipo può essere realizzata facendo in modo che i

messaggi scambiati contengano tutte le informazioni necessarie alla propria comprensione.

Ciò porterebbe a focalizzare l’attenzione su una tipologia di messaggi basata su XML. Un

altro importante vincolo del modello REST riguarda le specifiche sulle interfacce. REST,

infatti, separa l’oggetto dell’intestazione dalla sua effettiva implementazione mediante

l’utilizzo di una serie di interfacce generiche. L’architettura REST enfatizza l’importanza

di suddividere il sistema a livelli organizzati secondo una struttura gerarchica. Ogni livello

è fatto in modo che gli elementi che ne fanno parte siano in grado di vedere solo il livello

con il quale dovranno interagire. In particolar modo ogni livello usa i servizi del livello

che si trova sotto di lui e a sua volta fornisce servizi al livello che si trova sopra di lui.

Questo vincolo serve per imporre un limite superiore alla complessità del sistema generale

e a favorire l’indipendenza dei vari livelli. L’ultimo vincolo introdotto da REST riguarda

l’estendibilità. Esso implica che un sistema debba essere capace di poter estendere le

proprie funzionalità mediante il download di script aggiuntivi. In questo modo è possibile

garantire la realizzazione del sistema in tempi brevi dotando i componenti della minima

dotazione software. Successivamente i vari componenti potranno essere estesi a seconda

della necessità del sistema di cui fanno parte.

- 50 -


Un WS che abbraccia i principi REST è detto RESTful, mentre un WS che implementi una

interfaccia in XML con metodi http senza seguire i principi dell'architettura è detto

RESTlike o semplicemente REST.

La differenza con la architettura SOA è: SOA è service centric, cioè si comunica con un

server che realizza un servizio, mentre REST è resource centric, cioè si comunica

direttamente ad una (rappresentazione della) risorsa del servizio senza dover

necessariamente passare da un punto d'ingresso prestabilito. In conclusione, l’architettura

SOA è utile per portare un'applicazione già pronta sul web, specie se object-oriented, con

l’architettura REST, invece si realizzano WS meno differenti da un sito web proprio

perché si accede a un REST Web Services come un browser accede alle informazioni

tipicamente contenute in una pagina web.

2.4.2 Griglia di fattibilità

Sulle colonne della griglia (asse parametri) sono stati messi i requisiti non funzionali

(descritti nel DSR) del framework. Invece, sulle righe (asse tecnologico) sono state messe

le tecnologie (descritte brevemente in precedenza) con cui realizzare il framework core.

Figura 2.8 – Griglia di fattibilità

Nota - SMCD: Si, ma con difficoltà.

- 51 -


2.4.3 Vantaggi e Svantaggi delle tecnologie

Web Services:

I vantaggi dei Web Sevices sono la trasparenza rispetto sia al linguaggio di

programmazione che al SO, mentre gli svantaggi sono legati alle performance che sono

minori di quelle riscontrabili utilizzando approcci alternativi di distributed computing

quali Java RMI e Wireless CORBA. Il problema di fondo dei Web Services è legato alle

scarse risorse che oggi offrono i dispositivi mobili, come i palmari. Esse, infatti, non

permettono di installare un server, anche di piccole dimensioni, a cui i client possono

chiedere uno dei servizi facente parte del framework. Tale problematica viene risolta

installando su un server il framework e sui i dispositivi mobili i client per accedere ai

servizi; questi ultimi sono applicazioni che occupano poco spazio in memoria e hanno

bisogno di ridotte capacità elaborative per la loro esecuzione.

Java RMI:

I vantaggi di utilizzare Java RMI sono la trasparenza rispetto ai SO 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 open-source.

- 52 -


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 sui sistemi operativi di riferimento

Windows Mobile.

REST WS:

I vantaggi in termini di trasparenza rispetto sia al linguaggio di programmazione che al SO

sono gli stessi dei Web Services con architettura orientata ai servizi. La differenza più

importante nel realizzare i WS con una architettura REST, invece di quella classica con

l’uso di SOAP, è nelle prestazioni, che risultano migliori; ma aumentano le difficoltà di

implementazione dei servizi.

Protocollo proprietario basato su XML:

Il vantaggio principale di questa scelta è la possibilità di creare un protocollo di

comunicazione che si adatti perfettamente alle nostre esigenze senza ricorrere ad altre

tecnologie sviluppate per altre situazioni. Anche la manutenibilità risulterebbe più agevole

avendo la completa conoscenza del protocollo progettato ed implementato da noi stessi. Di

contro realizzare un nuovo protocollo da zero comporta molto tempo e grandi difficoltà di

implementazione, senza essere sicuri delle future prestazioni che si potrebbero ottenere.

In ultimo è stata fatta anche una piccola analisi di mercato, andando a catturare le direzioni

di mercato, per quanto riguarda la tecnologia di distributed computing, di due delle

aziende leader nel settore: la TIBCO e la BEA WebLogic [15] [16] [17].

- 53 -


Entrambe le aziende, e non solo, puntano molto sulla SOA (Service Oriented

Architecture), architettura orientata ai servizi, che sembra andare per la maggiore. In tale

architettura la parola chiave, ovviamente, è 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. Quindi, la

tecnologia base di tale architettura sono i Web Services verso cui puntano entrambe le

aziende.

Alla fine, è stato deciso di utilizzare come tecnologia, i Web Services. Questo perché i WS

rispettano, sicuramente di più dell’altre tecnologie esaminate, i requisiti imposti al

progetto (trasparenza dal linguaggio di programmazione, trasparenza dal SO, possibilità di

distribuire il carico, portabilità dei servizi, manutenibilità e utilizzo di strumenti open-

source); inoltre anche il mercato è indirizzato su l’utilizzo di questa tecnologia come

emerso dall’analisi di mercato. Per quanto riguarda le prestazioni che sicuramente non

vanno trascurate, è stato fatto un ragionamento prospettico: con i futuri dispositivi mobili,

aventi sempre più risorse hardware, le prestazioni da che oggi sono limitate, cominceranno

ad aumentare di pari passo con la sempre maggiore disponibilità di risorse hardware.

- 54 -

Capitolo 3

Progettazione del servizio IM

In questo terzo capitolo, si descrivono tutte le fasi di sviluppo, dall’analisi fino alla

progettazione, e le relative problematiche affrontate di un particolare servizio del

framework, il servizio di instant messaging. La scelta è ricaduta su questo servizio per la

sua semplicità, così da potersi concentrare maggiormente sulle problematiche del

framework core.

3.1 Che cos’è un Instant Messaging

Un sistema di messaggistica istantanea (in lingua inglese instant messaging) è un sistema

di comunicazione solitamente peer-to-peer (P2P) per computer, che consente di scambiare

in tempo reale, fra utenti di due computer connessi in rete, frasi e brevi testi: è in pratica la

moderna versione del vecchio servizio talk di UNIX. Anche se in linea di principio la

comunicazione in un sistema di messaggistica istantanea avviene tra nodi equivalenti

(peer, appunto), generalmente tali sistemi vengono realizzati tipicamente con tecnologia

client-server per problemi di grandezza del sistema stesso e per problemi di sicurezza.

È differente dalla e-mail perché lo scambio è istantaneo, ed è più evoluto del suo

predecessore perché le frasi compaiono istantaneamente e non lettera per lettera. Inoltre,

spesso vengono offerti anche altri servizi oltre al semplice invio di messaggi.

- 55 -

Capitolo 3 Progettazione del servizio IM

3.1.1 Struttura di un sistema di messaggistica istantanea

Sostanzialmente, un moderno sistema di instant messaging consiste in un programma

server centrale, che gira su una macchina apposita, a cui si collegano i programmi client su

ciascun computer collegato in rete: il server tiene traccia di quali computer e quali utenti

sono connessi al sistema e gestisce le comunicazioni fra i vari programmi client. Per

motivi di sicurezza, ai vari client non viene in generale fornito l'indirizzo di rete del

corrispondente con cui sono in comunicazione, tuttavia per motivi di efficienza, durante lo

scambio di file oppure di flussi streaming (audio e video in tempo reale fra client) il server

comunica a ciascun client l'indirizzo di rete dell'altro per permettere ai due di scambiarsi i

dati direttamente senza farli passare per il server. Quello che realmente caratterizza gli

instant messaging da altre applicazioni di text messaging è il fatto che venga utilizzato un

indicatore di "presenza", che permette agli utenti di conoscere la disponibilità on-line di un

appartenente al sistema. Usare un programma di instant messaging è come condurre una

conversazione a distanza mediante una digitazione reciproca di un testo. Alcune

applicazioni di instant messaging (come ICQ – “I Seek You”) danno inoltre la possibilità di

usufruire di un servizio analogo agli SMS: se un utente contattato non è connesso in quel

momento, il server lo memorizza per alcune ore e lo recapita all'utente chiamato appena

questi si connette, se lo fa entro il tempo limite. I software di instant messaging si sono

diffusi rapidamente e i maggiori, come ICQ, MSN, Google Talk e Yahoo Messenger,

raccolgono ormai la maggior parte degli utenti. L'instant messaging si è diffuso

dappertutto, e ogni applicazione ha il suo specifico protocollo, consentendo così agli utenti

di eseguire simultaneamente diverse applicazioni disponibili su diversi network. Alcuni

esempi di protocolli di messaggistica istantanea sono OSCAR usato da AIM (AOL Instant

Messenger) e da ICQ, Jabber ( o XMPP - Extensible Messaging and Presence Protocol),

.NET Messenger Service, e Yahoo! Messenger.

- 56 -

http://it.wikipedia.org/wiki/Server

http://it.wikipedia.org/wiki/Server

http://it.wikipedia.org/wiki/Client

http://it.wikipedia.org/wiki/ICQ

http://it.wikipedia.org/w/index.php?title=OSCAR_protocol&action=edit

http://it.wikipedia.org/w/index.php?title=OSCAR_protocol&action=edit

http://it.wikipedia.org/wiki/Jabber

http://it.wikipedia.org/w/index.php?title=.NET_Messenger_Service&action=edit

http://it.wikipedia.org/wiki/Yahoo%21_Messenger


3.2 Descrizione del servizio IM

Di seguito si riporta la descrizione del servizio di messaggistica istantanea che deve

fornire il framework

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.

3.3 La fase di analisi In questa fase vengono individuati e rappresentati i requisiti del servizio ed evidenziate le

funzionalità del servizio. Sarà adottato UML (Unified Modeling Language), un linguaggio

di modellazione e specifica basato sul paradigma object-oriented, sia in questa fase che

nella successiva di progettazione. Il risultato della fase di analisi è il diagramma dei casi

d’uso (figura 3.1).

3.3.3 Diagramma dei casi d’uso

Nel diagramma ci sono due attori (rappresentati dall’icona di un omino stilizzato) che

rappresentano due tipologie di utenti che possono interagire con il sistema, un utente

generico e un utente registrato, il primo è una generalizzazione del secondo. Essi possono

dare inizio alla sequenza di uno o più casi d’uso (rappresentati da un’elisse). Ogni caso

d’uso rappresenta una funzionalità che il sistema mette a disposizione; ad esempio il caso

d’uso Registrazione rappresenta la funzione di registrazione, cioè quella operazione che

permette all’utente di ottenere un account (UserID e Password). Alcuni casi d’uso, come

Connessione, includono un altro caso d’uso, in particolare ListaUtenti, ciò vuol dire che

quest’ultimo è sempre utilizzato per aumentare il comportamento del caso d’uso base, in

questo caso Connessione.

- 57 -


<<include>>

<<include>>

<<include>>

<<include>>

UtenteGenerico

UtenteRegistrato

Registrazione

Connessione

Disconnessione

InvioMessaggio

RicezioneMessaggioChiusuraConversazione

AperturaConversazione

ListaUtenti

Cancellazione

Figura 3.1 - Diagramma dei casi d’uso

Di seguito si riporta la descrizione di ogni caso d’uso presente nel diagramma dei casi

d’uso (figura 3.1).

Attore UtenteGenerico: Rappresenta un utente non ancora registrato, privo di account

Attore UtenteRegistrato: Rappresenta un utente registrato, avente un account

- 58 -


Caso d’uso Registrazione:

Nome: Registrazione

Descrizione: Consente la registrazione di un nuovo utente

Scenario principale caso d’uso Registrazione:

1. L'UtenteGenerico fornisce i suoi dati personali (Nome, Cognome, E-mail), un userID e

una Password

2. Il sistema controlla che l’utente non sia già registrato

3. Il sistema controlla che l’userID non si ha già in uso

4. Il sistema registra l’utente associandogli l’userID e la Password scelti da quest’ultimo

Estensioni caso d’uso Registrazione:

2. Utente già registrato

2.a Ritorno al punto 1

3. userID già presente


Caso d’uso Connessione:

Nome: Connessione

Descrizione: Consente di connettersi

Scenario principale caso d’uso Connessione:

1. L’UtenteRegistrato chiede di connettersi e fornisce il suo userID e Password

2. Il sistema verifica la validità dei dati

3. Il sistema permette la connessione all'utente identificato

4. Il sistema verifica la possibilità di accedere alla rete

5. Il sistema visualizza la lista degli utenti in linea

- 59 -


Estensioni caso d’uso Connessione:

2. Dati non corretti


4. Non c’è l’accesso alla rete

4.a Fallimento

Precondizione caso d’uso Connessione:

L’UtenteRegistrato deve essere registrato

Caso d’uso AperturaConversazione:

Nome: AperturaConversazione

Descrizione: Consente ad un utente connesso di iniziare una conversazione con un altro

utente in linea

Scenario principale caso d’uso AperturaConversazione:

1. L’UtenteRegistrato chiede l’apertura di una conversazione con uno degli utenti in linea

visualizzati nella lista utenti

2. Il sistema instaura la conversazione

3. I due utenti, tra cui è stata aperta la conversazione, iniziano a scambiarsi i messaggi

Precondizione caso d’uso AperturaConversazione:

L’UtenteRegistrato deve essere connesso

Caso d’uso InvioMessaggio:

Nome: InvioMessaggio

Descrizione: Consente l’invio di un messaggio

- 60 -


Scenario principale caso d’uso InvioMessaggio:

1. L’utente(mittente) scrive il messaggio

2. L’utente(mittente) invia il messaggio

3. Il sistema prende in consegna il messaggio inviato e si preoccupa di farlo recapitare al

destinatario

Estensioni caso d’uso InvioMessaggio:

3. Il sistema perde il messaggio inviato

3.a Fallimento

Precondizione caso d’uso InvioMessaggio:

L’UtenteRegistrato deve aver aperto una conversazione con l’utente ricevente il

messaggio

Caso d’uso RicezioneMessaggio:

Nome: RicezioneMessaggio

Descrizione: Consente la ricezione di un messaggio

Scenario principale caso d’uso RicezioneMessaggio:

1. Il sistema recapita il messaggio al utente(ricevente)

2. L’utente(ricevente) riceve il messaggio inviatogli

Precondizione caso d’uso RicezioneMessaggio:

L’UtenteRegistrato deve aver aperto una conversazione con l’utente mittente del

messaggio

- 61 -


Caso d’uso ChiusuraConversazione:

Nome: ChiusuraConversazione

Descrizione: Consente di chiudere una conversazione aperta in precedenza

Scenario principale caso d’uso ChiusuraConversazione:

1. L’UtenteRegistrato decide di chiudere la conversazione

Precondizione caso d’uso ChiusuraConversazione:

L’ UtenteRegistrato deve aver aperto la conversazione che si vuole chiudere

Caso d’uso Disconnessione:

Nome: Disconnessione

Descrizione: Consente di disconnettersi

Scenario principale caso d’uso Disconnessione:

1. L’UtenteRegistrato decide di disconnettersi

2. Il sistema cancella l’utente dalla lista di quelli in linea e chiude le conversazioni aperte

in precedenza

Precondizione caso d’uso Disconnessione:

L’ UtenteRegistrato deve essere connesso

Caso d’uso ListaUtenti:

Nome: ListaUtenti

Descrizione: Consente di visualizzare la lista degli utenti in linea al momento della

connessione o quando si decide di aprire una conversazione

- 62 -


Scenario principale caso d’uso ListaUtenti:

1. L’UtenteRegistrato chiede la lista utenti

2. Il sistema visualizza la lista degli altri utenti che sono in linea al momento della

connessione del utente

Precondizione caso d’uso ListaUtenti:

L’ UtenteRegistrato deve essere connesso

Caso d’uso Cancellazione

Nome: Cancellazione

Descrizione: Consente la cancellazione dal sistema di un utente registrato

Scenario principale caso d’uso Cancellazione:

1. L’UtenteRegistrato fornisce il suo userID e Password

2. Il sistema verifica la validità dei dati e identifica l’utente

3. L’UtenteRegistrato chiede la sua cancellazione

4. Il sistema cancella l’utente

Estensioni caso d’uso Cancellazione:

2. Dati non corretti

2.a Ritorna al punto 1

Precondizione caso d’uso Cancellazione

L’UtenteRegistrato deve essere registrato

- 63 -


3.4 La Fase di progettazione

In questa fase viene presentata prima l’architettura del componente che fornisce il servizio

IM con i due possibili scenari di funzionamento tramite un deployment diagram, poi le

classi progettate attraverso il diagramma delle classi.

3.4.1 Architettura del componente IM

In linea con la architettura del framework di cui fa parte, il componente IM può essere

installato direttamente su un dispositivo mobile e quindi avere una comunicazione peer-to-

peer fra due dispositivi (figura 3.2).

Dispositivo mobile A

Applicazione utente

Framework

Dispositivo mobile B

Applicazione utente

Framework

Componente IMComponente IM

Figura 3.2 – Comunicazione peer-to-peer

Oppure installare su una macchina remota un server di messaggistica istantanea e il

framework con il componente IM; in questo caso il server si occupa di tenere traccia dei

client connessi e della comunicazione tra loro. I client, invece, sono installati su i

dispositivi mobili e hanno il compito di interfacciarsi con l’utente (figura 3.3).

- 64 -


Server IM

Framework

Applicazione utente C++

Client IM

Applicazione utente C#

Client IM

Applicazione utente Java

Client IM

Componente IM

Figura 3.3 – Comunicazione client-server

3.4.2 Diagramma delle classi

Si inizia a descrivere l’interfaccia del componente (figura 3.4).

igura 3.4 - InterfacciaIMClient

’interfaccia InterfacciaIMClient raccoglie tutti i metodi delle diverse classi del package

per creare una propria applicazione personalizzata.

InterfacciaIMClient

++++++++

registrazione (UtenteRegistrato utenteRegistrato)cancellazione ()apriConnessione ()chiudiConnessione ()apriConversazione ()inviaMessaggio (Messaggio messaggio)chiudiConversazione ()notificaRicezione ()

: UtenteRegistrato: void: void: void: String: void: void: Messaggio

F

L

IMClient che servono al utente per interfacciarsi con l’applicazione. Tali metodi non sono

altro che le funzionalità, individuate durante la fase di analisi nel diagramma dei casi

d’uso, che il servizio di IM deve offrire. Questi metodi possono essere direttamente

utilizzati da un utente per usufruire del servizio di instant messaging o da uno sviluppatore

- 65 -


Il componente è diviso in due package: IMClient (figura 3.5) e IMServer (figura 3.6).

package IMClient rappresenta, ovviamente, il lato client e il cuore del componente

Il

stesso.

Figura 3.5 - Package IMClient

1..* 1..1

1..*

1..1

1..1

1..1

0..10..*

0..1

0..1

0..1

0..*

0..*

0..1

UtenteGenerico

---

nomecognomeemail

: String: String: String

++

set ()get ()

: void: void

UtenteRegistrato

--

userIDpassword

: String: String

Connessione

- server : String

++

apriConnessione ()chiudiConnessione ()

: void: void

ListaUtenti

++

modificaLista (ListaUtenti listaUtenti)visualizzaLista ()

: ListaUtenti: void

Conversazione

- conversazioneID : String

++++

apriConversazione ()chiudiConversazione ()inviaMessaggio (Messaggio messaggio)notificaRicezione ()

: String: void: void: Messaggio

Buffer

--

dimensioneMaxtimeout

: int: int

+++

inserisci (Messaggio messaggio)elimina ()svuota ()

: void: Messaggio: void

Messaggio

----

mittentericeventeintestazionebody

: UtenteRegistrato: UtenteRegistrato: String: String

++

scriviMessaggio ()modificaMessaggio ()

: Messaggio: Messaggio

Direttorio

++

registrazione (UtenteRegistrato utenteRegistrato)cancellazione ()

: UtenteRegistrato: void

- 66 -


E’ formato dalle seguenti classi:

se rappresenta un utente non ancora registratosi, privo di

ccount; non è altro che l’attore che compare nel diagramma dei casi d’uso del paragrafo

teRegistrato: tale classe rappresenta, invece, un utente già registrato con un

roprio account; è una specializzazione della classe precedente di cui eredita gli attributi.

na classe priva di attributi ma serve per realizzare alcuni metodi

ecessari per offrire al utente determinate funzionalità, presenti anche nel diagramma dei

ire o chiudere una connessione con il server, senza però

ecessariamente aprire una conversazione con qualche utente. Il metodo apriConnessione

e una o più

onversazione, permette di inviare e ricevere i messaggi. Per il suo corretto funzionamento

essaggio che viene scambiato fra due client. Non è

lo il testo scritto da un utente per un altro (rappresentato dal attributo body) ma è

l’insieme delle informazioni più il testo vero e proprio che servono per recapitare

Classe UtenteGenerico: tale clas

a

precedente.

Classe Uten

p

Gli attributi userID e password, specifici di questa classe, servono proprio per fornire un

account unico al utente registrato.

Questa classe non è altro che l’attore che compare nel diagramma dei casi d’uso del

paragrafo precedente.

Classe Direttorio: è u

n

casi d’uso, come la registrazione.

Classe Connessione: serve per apr

n

non solo serve per aprire praticamente la connessione con il server ma

contemporaneamente anche per effettuare l’identificazione del utente stesso.

Classe Conversazione: è il cuore del package serve per aprire o chiuder

c

ha bisogno della classe Messaggio.

Classe Messaggio: rappresenta il m

so

- 67 -


correttamente il messaggio. Gli attributi intestazione, mittente e ricevente contengono

proprio queste informazioni di “servizio”.

Classe Buffer: è una classe di appoggio per la classe Conversazione utile per gestire la

ricezione e l’invio dei messaggi per ogni conversazione aperta. Permette di conservare i

essaggi non ancora inviati o non ancora ricevuti quando c’è una congestione della rete.

.

uesto perché si è pensato che una volta connesso, l’utente potesse essere contatto o

nome stesso. La progettazione di tale package non è stata approfondita

oiché si è optato per utilizzare un server open-source già sviluppato, questo per

m

Classe ListaUtenti: questa classe rappresenta sia la lista dei contatti di un utente che la

lista degli utenti in linea al momento del ingresso del nuovo utente connesso nel servizio

Q

contattare chiunque in linea senza obbligare un utente ad aggiungere ogni volta un nuovo

contatto alla lista.

Il package IMServer (figura 3.6), invece, rappresenta il server di instant messaging, come

lascia intendere il

p

abbreviare i tempi di sviluppo del intero componente e per focalizzarsi meglio sull’altro

package.

GestioneConversazione

- elencoConversazioniAperte : Conversazione[]

+++

apriConversazioneServer ()chiudiConversazioneServer ()inviaMessaggioServer (Messaggio messaggio)

: conversazioneID: void: void

GestioneConnessione

- listaConnessioni : Connessione[]

++

instauraConnessione ()terminaConnessione ()

: Connessione: void

GestioneListaUtenti

BufferServer

Figura 3.6 - Package IMServer

Vista completa diagramma delle classi: (pagina successiva - figura 3.7)

- 68 -

Figura 3.7 – Diagramma classi completo

Package IMClient

Package IMServer

Applicazione utente Framework Core

1..* 1..1

1..*

1..1

1..1

1..1

0..10..*

0..1

0..1

0..1

0..*

0..*

0..1

UtenteGenerico

---

nomecognomeemail

: String: String: String

++

set ()get ()

: void: void

UtenteRegistrato

--

userIDpassword

: String: String

Direttorio

++

registrazione (UtenteRegistrato utenteRegistrato)cancellazione ()

: UtenteRegistrato: void

Connessione

- server : String

++

apriConnessione ()chiudiConnessione ()

: void: void

ListaUtenti

++

modificaLista (ListaUtenti listaUtenti)visualizzaLista ()

: ListaUtenti: void

Conversazione

- conversazioneID : String

++++

apriConversazione ()chiudiConversazione ()inviaMessaggio (Messaggio messaggio)notificaRicezione ()

: String: void: void: Messaggio

Buffer

--

dimensioneMaxtimeout

: int: int

+++

inserisci (Messaggio messaggio)elimina ()svuota ()

: void: Messaggio: void

Messaggio

----

mittentericeventeintestazionebody

: UtenteRegistrato: UtenteRegistrato: String: String

++

scriviMessaggio ()modificaMessaggio ()

: Messaggio: Messaggio

InterfacciaIMClient

+ registrazione (UtenteRegistrato utenteRegistrat+++++++

o)cancellazione ()apriConnessione ()chiudiConnessione ()apriConversazione ()inviaMessaggio (Messaggio messaggio)chiudiConversazione ()notificaRicezione ()

: UtenteRegistrato: void: void: void: String: void: void: Messaggio

GestioneConversazione

- elencoConversazioniAperte : Conversazione[]

+++

apriConversazioneServer ()chiudiConversazioneServer ()inviaMessaggioServer (Messaggio messaggio)

: conversazioneID: void: void

GestioneConnessione

- listaConnessioni : Connessione[]

++

instauraConnessione ()terminaConnessione ()

: Connessione: void

GestioneListaUtenti

BufferServer

- 69 -

Capitolo3 Progettazione del servizio IM

3.4.3 Diagramma delle sequenze

Il diagramma delle sequenze (figura 3.8) che si riporta, illustra l’esecuzione dei seguenti

casi d’uso:

AperturaConversazione

InvioMessaggio

RicezioneMessaggio

ChiusuraConversazione

In tale diagramma si suppone che i due utenti (UtenteRegistratoA e UtenteRegistratoB),

che si scambiano i messaggi, si siano precedentemente già connessi. Lo scenario

rappresenta l’UtenteRegistratoA che apre una conversazione con l’UtenteRegistratoB,

scrive e invia un messaggio a quest’ultimo. L’UtenteRegistratoB riceve il messaggio e

risponde al mittente, il quale dopo la ricezione del messaggio di risposta, decide di

chiudere la conversazione.

- 70 -


Figura 3.8 – Diagramma delle sequenze

UtenteR

egistr

scriviMessaggio

apriConversazione

inviaMessaggio

inviaMessaggioS

erver

InviaMessaggio

notificaRicezione

scriviMessaggio

inviaMessaggio

inviaMssaggioS

ervere

inviaMessaggi

notificaRicezione

chiudiConvers

atoA

o

azione

apriConversazioneS

erver

chiersazi

rudiC

onvoneS

erve

Messaggio A

Conversazione A

Gesti

onvoneC

ersazioneC

onverszione B

aM

essaggio B

UtenteR

egistratoB

Framew

ork AFram

ework B

scriviMessaggio

apriConversazione

inviaMessaggio

inviaMessaggioS

notificaRicezione

scriviMessaggio

inviaMessaggio

e

inviaMessaggi

notificaRicezione

chiudiConvers

apriConversazioneS

iersazi

r

azione

chudiC

onv

erver

InviaMessaggio

inviaMssaggioS

erver

o erver

oneServe

- 71 -


3.4.4 Diagramma delle collaborazioni

oni tra gli oggetti del

Figura 3.10 – Diagramma delle collaborazioni 2

Per gli altri casi d’uso che non compaiono nel diagramma delle sequenze, si realizzano dei

diagrammi delle collaborazioni che evidenziano ancora le interazi

sistema ma non rispetto al trascorrere del tempo, come fanno i diagrammi delle sequenze,

bensì evidenziando meglio i legami presenti tra i vari oggetti.

Connessione


Disconnessione

6: visualizzaLista

5: modificaLista

4: notificaConnessione3: creaConnessione

1: apriConnessione 2: apriConnessione

UtenteRegistrato

Connessione ListaUtenti

GestioneConnessione

Framework Core

3: terminaConnessione

4: modificaLista1: chiudiConnessione 2: chiudiConnessione

UtenteRegistrato

ConnessioneFramework Core

GestioneConnessione

ListaUtenti

- 72 -


Registrazione

.4.5 Test Case

u vengono presentati dei test case progettati per testare le funzionalità

sterne del servizio, cioè le funzionalità visibili all’utente e definite dai requisiti e dalle

chiudiConnessione

priConversazione

inviaMessaggio

1: registrazione 2: registrazione

DirettorioFramework Core

UtenteGenerico


3

In q esto paragrafo

e

specifiche del software. In altre parole si effettuano dei test sui metodi dell’interfaccia

InterfacciaIMCLient che sono quelli che vengono utilizzati direttamente dal client.

Lista dei metodi:

registrazione

cancellazione

apriConnessione

a

chiudiConversazione

notificaRicezione

- 73 -


Test case per metodo registrazione

Descrizione metodo registrazione: Il metodo riceve in ingresso da un oggetto di classe

UtenteGenerico i pa i e

restituisce un oggetto di cl

recondizione: Utente non registrato. Postcondizione: Utente registrato.

OUTPUT ATTESO OUTPUT OTTENUTO

:

rametri userID e password. Fa un controllo su quest’ultim

asse UtenteRegistrato.

P

TEST CASE

INPUT

TC 1 userID e password corretti Utente registrato TC 2 userID e password errati Parametri errati, utente non

registrato

Tabella 3.1 - Test case per metodo registrazione

Nota: Per parametri (userID e password) errati si intende che sono già in uso, uno dei due

o entrambi, da altri utenti di tipo UtenteRegistrato.

Test case per metodo cancellazione:

o cancellazione: Il metodo cancella l’oggetto UtenteRegistrato da cui è

uesta maniera non c’è la possibilità che gli utenti possano essere

tente registrato. Postcondizione: Utente non registrato.

TEST CASE

INPUT OUTPUT ATTESO OUTPUT OTTENUTO

Descrizione metod

stato invocato, in q

cancellati da altri.

Precondizione: U

TC 3 userID e password corretti Utente cancellato TC 4 userID e password errati Impossibile cancellare utente

Tabella 3.2 - Test case per metodo cancellazione

- 74 -


Test case per metodo apriConnessione:

escrizione metodo apriConnessione: Il metodo viene invocato da un oggetto di classe

OTTENUTO

D

UtenteRegistrato, né controlla userID e password se il controllo ha esito positivo connette

l’utente, modifica la lista degli utenti in linea (cioè l’oggetto di classe ListaUtenti) e la

visualizza al nuovo utente connesso.

Precondizione: Utente registrato. Postcondizione: Utente connesso.

TEST CASE

INPUT OUTPUT ATTESO OUTPUT

TC 5 userID e password corretti Connessione aperta e ListaUte ti naggiornata e visualizzata

TC 6 userID e password errati dentificato, userID o Utente non iPassword errati

Tabella 3.3 - Test case per metodo apriConnessione

Test case per metodo chiudiConnessione:

Descrizione metodo chiudiConnessione: Il metodo viene invocato da un oggetto di classe

tenteRegistrato per chiudere la connessione. Il metodo chiude la connessione e tutte le

Postcondizione: Utente disconnesso.

TEST INPUT OUTPUT ATTESO OUTPUT OTTENUTO

U

conversazioni ancora aperte dell’utente e cancella l’utente dalla lista degli utenti in linea.

Precondizione: Utente connesso.

CASE TC 7 Richiesta disconnessione Disconnessione

Tabella 3.4 - Test ca onnession

se per metodo chiudiC e

- 75 -


est case per metodo apriConversazione:

escrizione metodo apriConversazione: Il metodo viene invocato da un oggetto di classe

recondizione: Utente connesso.

a.

ESO OUT NUTO

T

D

UtenteRegistrato per aprire una conversazione con un utente connesso visualizzato nella

lista degli utenti in linea. Il metodo apre con l’utente selezionato la conversazione e

assegna a quest’ultima un identificativo conversazioneID.

P

Postcondizione: Utente connesso con una nuova conversazione apert

TEST CASE

INPUT OUTPUT ATT PUT OTTE

TC 8 Richiesta apertura conversazione Conversazione aperta

Tabella 3.5 - Test ca

Test case per metod

Il metodo viene invocato da un oggetto di

lasse UtenteRegistrato per chiudere una conversazione precedentemente aperta.

CASE T OTTENUTO

se per metodo apriConversazione

o chiudiConversazione:

Descrizione metodo chiudiConversazione:

c

Precondizione: Utente connesso e almeno una conversazione aperta.

Postcondizione: Utente connesso e conversazione chiusa.

TEST INPUT OUTPUT ATTESO OUTPU

TC 9 Richiesta chiusura conversazione Conversazione chiusa

Tabella 3.6 - Test case C

per metodo chiudi onversazione

- 76 -


Test case per metodo invioMessaggio:

escrizione metodo invioMessaggio: Il metodo permette prima di scrivere un messaggio,

e aperta.

CASE ATTESO OUTPUT OTTENUTO

D

richiamando autonomamente il metodo scriviMessaggio della classe Messaggio, e poi

inviarlo al destinatario.

Precondizione: Utente connesso e almeno una conversazion

TEST INPUT OUTPUT

TC 10 Invio messaggio Messaggio inviato correttamente

Tabella 3.7 - Test case per metodo invioMessaggio

T se per

escrizione metodo notificaRicezione: Il metodo viene invocato alla apertura di una

ttesa di ricevere uno o più messaggi

TEST CASE


est ca metodo notificaRicezione:

D

conversazione automaticamente e si mette in a

Precondizione: Utente connesso e almeno una conversazione aperta.

TC 11 Invio messaggio Ricezione messaggio

Tabella 3.8 - Test case per metodo notificaRicezione

- 77 -

Capitolo 4

Implementazione del servizio IM

si descrive la fase di

plementazione con le relative problematiche tecniche, mostrando anche parti di codice

più significativo.

S ia il e iche utilizzate per

l’implementazione d

ome architettura iniziale di funzionamento del servizio IM, presentata nel capitolo

esenza di un server di instant messaging su una

acchina remota su cui è installato anche il framework. La scelta è ricaduta su questa

questo

voro di tesi.

.1 Scelta delle tecnologie L a dell f elte tecnologiche, per

esempio obbliga a d tanea.

er implementare i servizi, è stato scelto come linguaggio di programmazione Java (link:

ttp://java.sun.com/) per soddisfare il requisito di portabilità del framework di cui il

rvizio IM fa parte. In particolare è stato utilizzato Java Development Kit (JDK); come

ol di sviluppo, invece, Eclipse (link: http://www.eclipse.org/).

Terminata la progettazione del servizio IM, in questo quarto capitolo

im

i iniz capitolo pres ntando le diverse soluzioni tecnolog

el framework e del servizio IM.

C

precedente, è stata scelta quella con la pr

m

architettura perché risulta la più semplice da realizzare e per aggirare i problemi legati alle

scarse risorse hardware dei dispositivi mobili che si avevano a disposizione per

la

4

a scelt ’architettura di unzionamento ha influito su alcune sc

over scegliere un server di messaggistica istan

P

h

se

to

- 78 -

Capitolo 4 Implementazione del servizio IM

4.1.1 Protocollo

Come protocollo di messaggistica istantanea è stato scelto Jabber ( o XMPP - Extensible

Messaging and Presence Protocol altro nome con cui spesso è identificato Jabber - link

ufficiale del progetto: http://www.jabber.org/).

La scelta è ricaduta su Jabber per la sua caratteristica unica che consente agli utenti di

eti che usano altri protocolli, per esempio un utente Jabber può comunicare

crosoft o altri client. Inoltre, Jabber è

specifiche tecniche e tutta la documentazione

no disponibili liberamente. E’ sicuro: supporta SSL (Secure Sockets Layer) offrendo

dice A.

stallare e amministrare, e possiede numerose funzioni (è possibile scaricare

merose plugin gratuitamente dal sito che ne aumentano le funzionalità). Infatti è

enti al momento collegati, cancellare un utente o

earne uno nuovo, dare o meno l'autorizzazione (attraverso la creazione di una password)

accedere a r

con un utente che usa Windows Messenger della Mi

anche un protocollo libero ed estensibile, le

so

quindi la possibilità di far viaggiare i dati su di un protocollo criptato, al riparo da

eventuali "sguardi indiscreti". Le caratteristiche e il funzionamento di Jabber sono

descritte nell’appen

4.1.2 Server

Come server è stato scelto Openfire

(link: http://www.igniterealtime.org/projects/openfire/index.jsp).

La scelta è ricaduta sul server Openfire della Jive Software poiché è risultato molto

semplice da in

nu

possibile controllare quali sono gli ut

cr

ad un client di collegarsi al server, scegliere le porte da utilizzare nelle connessioni tra

client e server o tra due server, ecc.

Inoltre, permette di scegliere se utilizzare un database esterno, o di utilizzare un database

integrato (cioè che non ha bisogno di essere creato manualmente).

- 79 -


4.1.3 Altre scelte tecnologiche

Per l’implementazione delle classi del servizio, si è utilizzato la libreria open-source

://www.igniterealtime.org/projects/smack/index.jsp).

mack è una libreria scritta dalla community Jive Software (stessa che ha realizzato il

potente, sia molto semplice da usare. Si

ivello di astrazione elevato, evitando così di dover maneggiare

irettamente l’envelope SOAP. E come web container, invece, si è scelto Apache Tomcat

semplicemente Tomcat - link: http://tomcat.apache.org/). Infatti è un web container

ppato dalla Apache Software Foundation, che implementa le specifiche

P e Servlet di Sun Microsystems, fornendo quindi una piattaforma per l'esecuzione di

ggio Java.

Smack API (link: http

S

server Openfire che si è deciso di utilizzare per il nostro servizio), che permette di scrivere

molto semplicemente un client XMPP (client di instant messaging che comunica tramite

protocollo Jabber). Questa libreria è sia molto

propone infatti come API ad alto livello, permettendo di essere più rapidi

nell’implementazione delle classi, ma consente anche di scendere ad un livello più basso.

Per quanto riguarda l’implementazione del framework core, ricordando che nel secondo

capitolo era stata fatta la scelta di utilizzare i WS SOA come tecnologia middleware per

realizzarlo, si è scelto come tool per il deploy dei Web Services Axis (link:

http://ws.apache.org/axis/). Si tratta di un Web Services container open-source che

permette di lavorare ad un l

d

(o

open-source svilu

JS

applicazioni Web sviluppate nel lingua

In ultimo, si è lavorato su una macchina con CPU processore Pentium 4 Intel 3.00 Ghz

con 512 MB di RAM su cui è installato Windows XP professional ver. 2002 service pack

2 collegata ad Internet.

- 80 -


4.2 Implementazione e funzionamento classi Delle classi progettate sono state implementate le seguenti classi: UtenteGenerico,

sazione, Direttorio, ListaUtenti.

a classe Messaggio non è stata implementata, ma si è utilizzato la classe Message fornita

’utilizzo dei WS come tecnologia middleware ha fatto nascere il problema di come

si devono realizzare WS con visibilità di

ssion, per far ciò si hanno due possibilità:

i come WS in Axis, attraverso un file WSDD (Web Services

Deployment Descriptor - paragrafo 4.2.3);

UtenteRegistrato, Connessione, Conver

L

dalla libreria Smack; tale classe per come è stata implementata corrispondeva già alla

nostra classe Messaggio progettata.

Delle classi implementate solo i metodi di tre classi, Conversazione, Direttorio e

ListaUtenti, sono stati pubblicati come Web Services, i metodi della classe Connessione,

che pure sono presenti nell’interfaccia del componente IM, non sono stati direttamente

pubblicati, ma vengono comunque esposti dato che le classi Conversazione, Direttorio e

ListaUtenti sono classi figlie della classe Connessione, ereditando quindi sia gli attributi

che i metodi.

L

mantenere lo stato degli oggetti istanziati tra un’esecuzione e l’altra dei metodi delle

classi. Generalmente le chiamate di un WS sono stateless (senza stato) ovvero non

presuppongono il mantenimento di informazioni sullo stato del servizio tra una chiamata e

l’altra. Per essere più chiari si potrebbe pensare al funzionamento di un carrello elettronico

(es. carrello di Amazon): durante la fase di acquisto dell’utente, il carrello deve mantenere

traccia degli articoli scelti mentre l’utente passa da una pagina web all’altra. Altrimenti,

cambiando pagina web, gli articoli precedentemente inseriti nel carrello andrebbero persi

annullando le scelte dell’utente. Per risolvere questa problematica in maniera tale che il

ciclo di vita di un oggetto istanziato non duri solo il tempo di esecuzione di un metodo ma

la durata intera dell’esecuzione dell’applicazione,

se

1. Usare oggetti static nelle classi implementate;

2. Esporre le class

- 81 -


Di queste tre soluzioni è stata scelta la prima che si esporrà nel prossimo paragrafo, la

conda nel paragrafo 4.2.3.

’ stata scelta la prima soluzione per rendere il servizio indipendente dal Web Services

oluzione più semplice da

ercorrere.

to alle altre.

se

E

container (Axis) usato in questo progetto e perché è sembrata la s

p

In particolare si andrà a descrivere in maniera dettagliata il funzionamento di solo due

classi Connessione e Conversazione, che sono di maggior interesse rispet

4.2.1 Classe Connessione

La prima classe, che si analizza nel dettaglio, è la classe Connessione (codice sorgente:

Connessione.java).

Tale classe ha due attributi:

1. public static Vector<XMPPConnection> connessioni

2. private static int posizioneConnessione

Il primo è un contenitore di oggetti di tipo XMPPConnection che è una classe fornita dalla

libreria Smack per aprire una connessione XMPP con un qualsiasi server Jabber. Il Vector

connessioni è static perché, per la problematica descritta in precedenza, non deve essere

legato ad alcuna particolare istanza di un oggetto della classe per il corretto funzionamento

dei client.

Il secondo attributo è un indice che indica la posizione di un elemento del Vector

connessioni, anche esso è static per non essere legato a nessuna istanza.

- 82 -


La

1. g Username, String Password,

Connessione(int indice)

al

ostruttore i parametri NomeServer che indica il nome del server con cui si vuole

onnettere, e Port che indica la porta per la connessione (di default è la 5222).

creato l’oggetto connection di tipo XMPPConnection,

assando al costruttore config; utilizzando il metodo connect sull’oggetto connection si

ggetto connection, passandogli i parametri Username e Password,

utente viene identificato. A questo punto l’oggetto connection creato viene aggiunto nel

entato di uno il valore di posizioneConnessione, il cui valore

ggiornato viene restituito dal metodo.

L’o osì da poter essere

riut z l’apertura di una conversazione,

r poterlo rintracciare nel Vector verrà utilizzato il valore di posizioneConnessioni,

tesso valore. Inoltre c’è bisogno di un Vector perché ogni utente abbia, quando

classe Connessione ha due metodi:

public int apriConnessione(Strin

String NomeServer, int Port)

2. public void chiudi

Il primo metodo permette di aprire una connessione con un server dopo aver effettuato il

login.

Tale metodo così funziona: viene creato un oggetto config di tipo

ConnectionConfiguration, tipo fornito sempre dalla libreria Smack, passando

c

c

Tramite questo oggetto viene

p

apre materialmente la connessione con il server. Di seguito tramite il metodo login,

sempre utilizzato sull’o

l’

Vector connessioni e increm

a

ggetto connection viene aggiunto nel Vector connessioni c

iliz ato per altre operazioni come la disconnessione o

pe

restituito dal metodo apriConnessioni.

Quest’ultimo viene richiamato tramite WS, che, come spiegato in precedenza, non

istanziano un oggetto della classe Connessione, allora per tener traccia delle connessioni

degli utenti l’oggetto connection è static così da mantenere durante l’intera esecuzione

sempre lo s

apre una connessione con il server, il suo oggetto connection. Se si usasse un unico

- 83 -


oggetto connection e non un Vector avremmo problemi di funzionamento del servizio, per

sempio messaggi recapitati a utente sbagliati.

secondo metodo, invece, permette di chiudere la connessione correttamente. Se la

niera corretta, risulterebbe che l’utente è ancora

onnesso per il server, quando ciò non è più vero.

Si v n

connes isconnesssione, tramite il metodo get, proprio

dell metro indice che ne indica la

osizione esatta.

so.

la classe

attributi, oltre hai due che eredita dalla classe

g> userJIDs

e

Il

connessione non fosse chiusa in ma

c

eda il funzio amento di tale metodo: viene recuperato l’oggetto connection dal Vector

sioni dell’utente che ha chiesto la d

a classi di tipo Vector, passandogli il valore del para

p

Recuperato l’oggetto connection, per chiudere la connessione, si usa il metodo disconnect

su di es

4.2.2 Classe Conversazione

La classe Conversazione (codice sorgente: Conversazione.java) estende

Connessione, ciò vuol dire che eredita da quest’ultima sia i suoi attributi sia i suoi metodi.

Oltre ad ereditare dalla classe Connessione, la classe Conversazione implementa

l’interfaccia MesssageListener, che è una interfaccia fornita dalla libreria Smack, in

particolare deve essere implementato il metodo dell’interfaccia processMessage che serve

per la ricezione dei messaggi.

La classe Conversazione ha cinque

Connessione:

1. public static Vector<Chat> chats

2. public static Vector<Strin

3. public static HashMap<String,String> BodyMessages

4. public static HashMap<String,String> flags

5. private static int posizioneConversazione

- 84 -


Il primo attributo è un contenitore di oggetti di tipo Chat che è una classe fornita dalla

libreria Smack che rappresenta una conversazione Jabber aperta; anche il secondo

attributo è un contenitore, ma di stringhe. Il terzo attributo come il quarto è un contenitore

l Vector chats.

ma solo la durata di esecuzione di un singolo metodo richiamato.

Conversazione si andranno a spiegare il funzionamento dei seguenti metodi

he compaiono nell’interfaccia del servizio IM:

1. public int apriConversazione(int indiceConnessione, String

onsente di aprire una conversazione:

zioneConversazione++;

3. Chat chat = connection.getChatManager().createChat(UserJID, new

di stringhe basato su una tabella hash dove un singolo elemento viene identificato da una

chiave alfanumerica e non da un indice numerico come per i Vector. Il quinto attributo è

un indice che indica la posizione di un elemento de

Tutti questi attributi sono static per lo stesso problema descritto per la classe Connessione:

non devono essere legati ad alcuna istanza della classe Conversazione, questo perché i WS

non istanziano un oggetto della classe il cui ciclo di vita duri tutta l’esecuzione

dell’applicazione,

Della classe

c

UserJID)

2. public void inviaMessaggio(String Messaggio, int

indiceConversazione)

3. public String ricezioneMessaggio(String UserJID)

Il metodo apriConversazione c

1. XMPPConnection connection = connessioni.get(indiceConnessione);

2. posi

Conversazione());

4. chats.add(chat);

5. return posizioneConversazione;

- 85 -


Vie la connessione aperta in

recedenza dall’utente (linea 1). Viene incrementato di uno il valore di

del oggetto chat,

, Message.Type.chat);

msg.setBody(Messaggio);

4. essage(msg);

Viene rJIDs la stringa userJID rappresentante il Jabber ID

dell o un oggetto msg del

po Message, che è una classe fornita dalla libreria Smack, e settato il Body con la stringa

are (linea 2). Viene

cuperato dal Vector chats l’oggetto chat (linea 3). Si è utilizza il metodo sendMessage

per in

recap

Il met

ne recuperato l’oggetto connection che rappresenta

p

indiceConversazione (linea 2). Si crea l’oggetto chat di tipo Chat, che è una classe fornita

dalla libreria Smack (linea 3). Si passa al metodo createChat, un oggetto di tipo

Conversazione perchè la creazione di un oggetto della classe Chat prevede un oggetto di

una classe che implementa il metodo processMessage, e nel nostro caso tale classe è

proprio Conversazione. L’ oggetto chat viene aggiunto al Vector chats (linea 4). Il valore

di indiceConversazione, che rappresenta proprio la posizione nel Vector

viene restituito alla fine della sua esecuzione dal metodo apriConversazione e servirà per

recuperare l’oggetto chat dal Vector chats per eseguire l’invio di un messaggio nella

corretta conversazione tra quelle aperte (linea 5).

Il metodo invioMessaggio permette di inviare messaggi:

1. String userJID = (String) userJIDs.get(indiceConversazione);

2. Message msg = new Message(userJID

3. Chat chat = (Chat) chats.get(indiceConversazione);

chat.sendM

recuperato dal Vector use

’utente a cui si vuole inviare il messaggio (linea 1). Viene creat

ti

Messaggio che rappresenta ciò che l’utente realmente vuole invi

re

viare definitivamente il messaggio contenente tutte le informazioni per essere

itato correttamente (linea 4).

odo ricezioneMessaggio permette di ricevere i messaggi:

- 86 -


1. String BodyMessage = BodyMessages.get(UserJID);

3. return BodyMessage;

. deployment dinamico attraverso l’uso di file .jws,

2.

In p etodo:

critto il file Conversazione.java, si copia tale file nella seguente cartella

i tali file. Si avvia Tomcat e si va al seguente link:

2. flags.put(UserJID,"0");

Viene recuperato dal HashMap BodyMessages il messaggio (linea 1). Il valore del flag,

che indica la ricezione del messaggio, viene modificato per indicare che il messaggio è

stato ricevuto (linea 2). La stringa BodyMessage viene restituita dal metodo

ricezioneMessaggio per la lettura del messaggio ricevuto da parte dell’utente (linea 3).

4.2.3 Pubblicazione classi come Web Services

Si illustra, ora, come esporre le classi come Web Services. In Axis vi sono due metodi per

effettuare il deployment di un servizio:

1

deployment statico attraverso l’uso di deployment descriptor.

articolare verrà esposta la classe Conversazione attraverso il primo m

S

<TOMCAT_HOME>\webapps\axis. Si cambia l’estensione del file da .java a .jws, si

copia nella cartella <TOMCAT_HOME>\webapps\axis\WEB-INF\classes il file

Connessione.class precedentemente compilato e nella cartella

<TOMCAT_HOME>\webapps\axis\WEB-INF\lib i file jar della libreria Smack. Questo

perchè la classe Conversazione che si vuole esporre come WS estende la classe

Connessione e utilizza delle classi della libreria Smack e dato che Axis compila la classe

che si vuole esporre, ha bisogno d

- 87 -


http://localhost:8080/axis/Conversazione.jws; così facendo si è generato il nostro web

rvices, il file Conversazione.class compilato da Axis si trova nella cartella

<TOM

In pra l file, compilarlo e posizionare attorno ad esso un

wrapp ate SOAP dirette verso il servizio

invocazioni di metodi Java.

ppure cliccare sul comando Click to see the WSDL.

può essere utilizzata solo nei casi di web service molto semplici. Inoltre tale soluzione

se

CAT_HOME>\webapps\axis\WEB-INF\jwsClasses.

tica ciò che Axis fa è localizzare i

er, cioè una sorta di filtro, che converte le chiam

in

Per vedere il WSDL generato da Axis per la nostra classe Conversazione (figura 4.1) o si

può andare direttamente al seguente link:

http://localhost:8080/axis/Conversazione.jws?wsdl

o

Figura 4.1 – WSDL della classe Conversazione

Questa soluzione rappresenta un meccanismo di deployment facile ed immediato, ma che

- 88 -


presenta alcuni inconvenienti come ad esempio il fatto di non poter specificare quali

metodi devono essere esposti e quali invece non devono esserlo. Altro svantaggio è quello

di non poter definire un mapping dei tipi SOAP/Java personalizzato. Nel caso invece di

Web Services più complessi o nel caso in cui le caratteristiche della soluzione appena vista

non siano adeguate per l’applicazione, vi è il secondo metodo di deployment di Axis.

nt e verrà fatto per la classe semplice SalutoWS.

D) all’interno dei quali sono inserite le

formazioni relative al servizio di cui si vuole fare il deployment. I file .wsdd permettono

ne in rete del servizio. Un esempio di

le .wsdd realizzato per la classe SalutoWS è il seguente:

deployment

xmlns="http://xml.apache.org/axis/wsdd/"

xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<service name="SalutoWS" provider="java:RPC">

<parameter name="className" value="miopackage.SalutoWS"/>

<parameter name="allowedMethods" value="saluto"/>

<parameter name="scope" value="Request"/>

</service>

</deployment>

All’interno dell’elemento deployment, che riporta i namespace a cui si fa riferimento, si

trova l’elemento service che specifica le informazioni relative al servizio di cui si vuole

fare il deployment. E’ da notare ciò che è stato inserito all’interno dei tag

<service></services>. L’attributo name rappresenta il nome che si vuole assegnare al

servizio e che servirà a o provider è stato

Nel progetto è stato sempre utilizzato per esporre le classi come Web Services, il metodo

sopra descritto proprio per la sua semplicità; di seguito per completezza si descrive anche

il secondo metodo di deployme

Questo secondo metodo utilizza dei particolari file xml di deployment chiamati Web

Services Deployment Descriptor (WSD

in

di specificare molte più cose riguardo all’esposizio

fi

<

d identificarlo univocamente. L’attribut

- 89 -


valorizzato con java:RPC che indica ad Axis di pubblicare il servizio secondo un

meccanismo RPC. Di seguito si trova una sezione composta da tre tag <parameter>. Il

primo indica il nome (comprensivo di package) della classe implementata. Il secondo

descrive i metodi della suddetta classe che si vuole esporre (nel nostro caso l’unico

metodo implementato). Il terzo definisce il ciclo di vita della classe che in questo caso

viene istanziata, utilizzata e distrutta ad ogni richiesta (altri valori possibili sono

Application e Session). Questa è una delle possibili soluzioni accennate in precedenza per

e.axis.client.AdminClient deploy.wsdd

ponibile si deve utilizzare lo stesso

utilizzare il seguente

che.axis.client.AdminClient undeploy.wsdd

a lista di tutti i servizi disponibili può essere ottenuta dalla prima pagina di Axis

risolvere il problema del mantenimento dello stato delle classi, infatti, assegnando a tale

parametro valore session, lo stato delle classi viene mantenuto per tutta la durata della

sessione.

Una volta creato il file .wsdd, che si chiamerà ad esempio deploy.wsdd, si deve per prima

cosa copiare il package contenente le classi che realizzano il web service nella directory

<TOMCAT_HOME>\webapps\axis\WEB-INF\classes e, successivamente, da tale

posizione eseguire l’operazione di deployment utilizzando un apposito tool di Axis da

linea di comando:

java org.apach

A questo punto il servizio è disponibile.

Nel caso in cui si voglia rendere tale servizio non dis

tool con un file di undeployment, ad esempio undeploy.wsdd, e

comando:

java org.apa

L

cliccando sul link List, in cui compare il nostro servizio SalutoWS (figura 4.2).

- 90 -


Figura 4.2 – Lista dei Web Services disponibili

4.3 Testing

La fase di testing del componente IM è stata divisa in due attività:

Unit test (o test di unità),

Integration test (o test di integrazione),

nella prima attività sono provati singolarmente tutti i metodi che fanno parte

ettato i test case (presentati nel

ttoparagrafo Test Case del terzo capitolo).

dell’interfaccia del componente IM di cui si è già prog

so

- 91 -


La seconda attività, invece, permette di verificare che le diverse unità (metodi

dell’interfaccia), testate in precedenza singolarmente, integrate tra loro, funzionino in

maniera corretta cioè che tutta l’applicazione costruita funzioni correttamente.

Per implementare gli unit test, si utilizzerà il JUnit (unit test framework per il linguaggio

di programmazione Java). Di seguito si riporta per ogni test case (o TC) una tabella in cui

è indicato il metodo che si sta testando, i dati di input al metodo, l’output atteso e l’output

ottenuto sia per gli unit test che per l’integration test.

TC 1:

METODO TESTATO


registrazione UserID e password corretti

Nuovo account Nuovo account

Tabella 4.1 – Test Case 1

TC 2:

UT OUTPUT ATTESO OUTPUT OTTENUTO

METODO TESTATO

INP

registrazione UserID e Nessun nuovo account Nessun nuovo account password errati


:

METODO INPUT OUTPUT OUTPUT OTTENUTO

TC 3

TESTATO ATTESO cancellazione UserID e password di

un utente registrato Utente cancellato

Utente cancellato


- 92 -


TC 4:

METODO INPUT OUTPUT ATTESO OUTPUT OTTENUTO TESTATO cancellazione UserID e password Nessuna Nessuna cancellazione

di un utente non registrato

cancellazione


TC 5:

METODO

ATO INPUT OUTPUT

ATTESO OUTPUT OTTENUTO UNIT TEST

OUTPUT OTTENUTO INTEGRATION TEST TEST

apriConnessione UserID e password

tti

Connessione aperta, login effelista contatti visu

Connessione aperta, login effettuato e lista contatti

t

Connessione aperta, login effettuato e lista

atti visualizzata (cambio schermata)

corre ttuato e visualizza

alizzata

a cont


TC 6:

METODO INPUT OUTPUT A

OUTPUT OTTENUTO EST

OUTPUT OTTENUTO GRATION TEST

TESTATO TTESO UNIT T INTEapriConnessione UserID e

rd Nessuna coaperta, login non effettualista contatti non visualizzata

Nessuna connessione aperta,

contatti non visualizzata

Nessuna connessione rta, login non

effettuato e lista contatti non visualizzata (schermata errore visualizzata)

passwoerrati

nnessione login non effettuato e lista ape

to e

Ta est C

bella 4.6 – T ase 6

- 93 -


TC 7:

METODO TESTATO

INPUT OUATTESO

UOTTENUTO UNIT T

T OTTENUTO

RATION TEST

TPUT OUTP T OUTPU

EST INTEG

chiudiConnessio esta disconnessione

Disconnessione Disconnessione Disconnessione effettuata (cambio schermata)

ne Richieffettuata effettuata


T

METODO TESTATO T

C 8:

INPUT OUTPUT ATTESO

OUTPUT OTTENUTO UNIT TES

OUTPUT OTTENUTO INTEGRATION TEST

apriConversazione JID utente

ne Conversazione aperta

rta (cambio schermata)

Conversazioaperta

Conversazione ape


TC 9:

METODO TESTATO

INPUT OUTPTTE

TPUT UT OUA SO OTTENUTO

UNIT TEST


chiudiConversazione ichiestchiusuraconversazione

chiusa R a

Converchiusa

sazione Conversazione Conversazione chiusa

chermata) (cambio s


TC 10:

METODO TESTATO

INPUT OUTPUT ATTESO

OUTPUT OTTENUTO UNIT TEST


invioMessaggio Messaggio Messaggio inviato

Messaggio inviato Messaggio inviato (stampa a video del messaggio)


- 94 -


TC 11:

METODO TESTATO

I OUTATTE

TPUT O IT TE

OU ENUTO INT EST

NPUT PUT SO

OUUN

OTTENUTST

TPUT OTTEGRATION T

notificaRicezione Messaggio inviato

Messaggio ricevuto

Messaggio Me(sta video del mes

ricevuto ssaggio ricevuto mpa asaggio)


Esempio di funzionamento

Si è deciso di impl e u er di zzan

della piattaf

Il client C# non è he erfaccia semplice che perm il

servizio di instant messaging.

plementazione del client, la ricezione dei messaggi è stata realizzata tramite un

olling (verifica ciclica): ogni volta che viene aperta una conversazione, si attiva un timer

che ogni secondo controlla se è stat un n saggio. Questa soluzione non

è sicuramente la più efficiente, anche se la più sem é porta u co

di risorse dato che il client è sempre in er. Per ovviare a tale

inconveniente si potrebbe realizzare la ricezione dei messaggi tram ifica: ogni

qualvolta viene ricevuto un messaggio, questo viene notificato al client. Tale soluzione

può essere realizzata tramite WS-Notification [18].

Il client è stato implementato per palmari con sistema operativo Windows Mobile 5.0 per

assecondare anche le richieste

4.4

ementar n client p spositivi mobili, utili do il linguaggio C#

orma .NET.

altro c un’int molto ette di utilizzare

Nell’im

p

o ricevuto uovo mes

plice, poich no piccolo spre

ascolto tramite il tim

ite not

dell’azienda Wi-Fi People.

- 95 -


Per fare partire l’applicazione bisogna cliccare una volta su IMJWTest, così facendo si fa

artire l’esecuzione del client di prova (figura 4.3):

p

Figura 4.3 – Esecuzione client

- 96 -


La schermata iniziale permette di entrare nell’applicazione premendo il pulsante IMJabber

(figura 4.4), invece premendo il pulsante Esci si esce dall’applicazione e si ritorna alla

Figura 4.4 – Schermata iniziale

situazione di partenza (figura 4.3):

- 97 -


Figura 4.5 - Login

A questo punto, l’applicazione permette all’utente di identificarsi, inserendo l’username e

la password e cliccando il pulsante Login (figura 4.5):

- 98 -


Se l’identificazione ha successo, compare una nuova schermata (figura 4.6), in cui si trova

la lista dei contatti e tre pulsanti più una casella di testo.

Figura 4

.6 – Lista contatti

- 99 -


L’utente può decidere di entrare nella schermata di gestione dei contatti (figura 4.7)

premendo il pulsante Gest.Contatti, in cui può cancellare o aggiungere un nuovo contatto.

remendo, invece, il pulsante Logout, si disconnette ed esce dall’applicazione tornando

lla schermata di figura 4.4.

Figura 4.7 – Gestione contatti

P

a

- 100 -


L’utente per aprire una conversazione, ha due possibilità (figura 4.6):

1. scrivere il JID (Jabber ID) della persona con cui vuole comunicare nella apposita

casella contrassegnata dall’etichetta Contatto e premere il pulsante Apri;

. oppure evidenziare nella lista dei contatti quello con cui vuole aprire la

conversazione e premere un qualsiasi pulsante di input del dispositivo mobilie.

Una volta aperta una conversazione, compare la seguente schermata (figura 4.8):

Figura 4.8 – Conversazione aperta

2

- 101 -


In alto è indicato l’utente con cui si è aperto la conversazione (nella figura mostrata è

avio@localhost), e ci sono due pulsanti e due caselle di testo. Nella casella di testo in cui

p

Figura 4.9 – Scambio messaggi 1

fl

com are la scritta “Inizio Conversazione!” viene mostrata l’intera conversazione, cioè tutti

i messaggi scambiati (figura 4.9).

- 102 -


Ogni messaggio è preceduto dal suo autore così da rendere più leggibile l’intera

conversazione (figura 4.10).

Figura 4.10 – Scambio messaggi 2

- 103 -


Nell’altra, invece, l’utente può scrivere il messaggio e inviarlo premendo il pulsante Invio

4.6.

Figura 4.11 – Scrittura e invio messaggio

(figura 4.11). Con il pulsante Chiudi, la conversazione viene chiusa e si ritorna alla

schermata mostrata in figura

- 104 -

Capitolo 5

Conclusioni e sviluppi futuri Nella seguente tesi è stato presentato la progettazione di un framework di servizi per

dispositivi mobili ed in particolare la progettazione ed implementazione del servizio di

messaggistica istantanea. Si è analizzato le possibili tecnologie middleware per la

realizzazione del core del framework, scegliendo, infine, i Web Services con architettura

orientata ai servizi come tecnologia di comunicazione tra i servizi e le applicazioni. In

seguito è stato progettato ed implementato il servizio del framework di messaggistica

istantanea. Per testarlo è stato realizzato un client per dispositivi mobili.

L’implementazione del client è risultata molto semplice e immediata grazie soprattutto a

come il servizio era stato progettato ed ai WS come tecnologia middleware utilizzata.

Questo ha avvalorato la scelta dei WS per realizzare il framework core e dimostrato come

il framework abbia , i suoi obiettivi: facilitare lo

iluppo di applicazioni per dispositivi mobili senza doversi preoccupare di problemi di

obile computing e di implementazione dei servizi.

el realizzare il servizio IM e nel testarlo su un palmare è sorta l’impossibilità, al

omento, di poter installare sul dispositivo mobile l’intero servizio per problemi legati

le risorse hardware degli odierni dispositivi mobili. Il problema consiste nella mancanza

i web container e di WS container, come il server Tomcat e il tool Axis utilizzati su

acchina fissa, per dispositivi mobili; questo perché, oggi, sicuramente tali dispositivi non

anno le necessarie risorse elaborative e di memoria per sostenere tali carichi. Per cui

abbiamo installato il servizio su una macchina remota, mentre sul palmare un client per

mostrato la sua utilità centrando, per ora

sv

m

N

m

al

d

m

h

- 105 -

Capitolo 5 Conclusioni e sviluppi futuri

accedere al servizio di messaggistica istantanea. Per poter installare il componente IM su

un palmare e anche l’intero framework quando completato, bisogna attendere l’evoluzione

dei dispositivi mobili, cosa tenuta in conto al momento di scegliere i web services come

tecnologia middleware dato che i dispositivi mobili sono in continuo e veloce evolversi.

La soluzione di deployment adottata per il servizio di messaggistica istantanea, può essere

che per gli altri servizi del framework man mano che vengano realizzati,

oIP, per cui il flusso di dati scambiati con un altro

ost (sia esso un dispositivo mobile o una macchina server) dipende fortemente dalle

ratteristiche hardware del dispositivo mobile stesso. In tal caso è necessario che il

itivo mobile, si potrebbe utilizzare,

adottata an

escluso, però, per quei servizi, come il V

h

ca

servizio e, quindi, il framework risiedano sul dispositivo mobile. Questo perché in una

applicazione VoIP è intrinseco il suo legame con le caratteristiche hardware del palmare

stesso. Si dovrà gestire uno streaming audio che ha come source il microfono di un host e

come drain le casse di un altro. Lo streaming audio è possibile solo in presenza di codec

opportuni che possono essere compatibili o meno con il palmare stesso. Pensare di

elaborare uno streaming audio lato Web Services 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.

E’ opportuno segnalare che durante le ultime settimane di lavoro, è stato trovato in

Internet, un primo esempio di web server, implementato in Java, per dispositivi mobili

TJWS (Tiny Java Web Server - http://tjws.sourceforge.net:80/). Allora, per poter

cominciare ad installare il framework su un dispos

come tecnologia middleware di comunicazione tra i servizi del framework e le

applicazioni, i Web Services con architettura REST. Questo perché con tale tecnologia si

realizzano WS meno differenti da un sito web, poiché si accede a un REST Web Services

come un browser accede alle informazioni tipicamente contenute in una pagina web, per

cui non occorre un WS container , come Axis, per realizzare il wrapper che converte le

chiamate SOAP dirette verso il servizio in invocazioni di metodo Java, rendendo il

servizio eseguibile anche per il palmare.

- 106 -

Capitolo 5 Conclusioni e sviluppi futuri

Al momento, oltre il servizio messaggistica istantanea, solo un altro servizio è stato

progettato e implementato, il VoIP, per cui vanno sviluppati anche gli altri servizi del

framework che sono stati presentati nel secondo capitolo.

Il servizio IM, progettato e implementato in questo lavoro di tesi, può essere migliorato

aggiungendo altre funzionalità, tipiche delle odierne applicazioni di instant messaging,

come la possibilità di inviare e ricevere file. Ciò potrebbe essere fatto progettando una

nuova classe che si occupa dello scambio di file integrandola all’interno del servizio. I

metodi di tale classe, utilizzati dal utente, andrebbero esposti come Web Services così

come è stato fatto per i metodi delle altre classi.

- 107 -

Appendice A

Il p

aggistica istantanea e presenza basato su

ML. Il software basato su Jabber è diffuso su migliaia di server disseminati su Internet

è usato da oltre dieci milioni di persone in tutto il mondo.

.1 Caratteristiche e funzionamento di Jabber

remie Miller iniziò il progetto nel 1998; il suo primo rilascio pubblico principale

avvenne nel marzo 2000. Il prodotto principale del progetto è jabberd, un server al quale i

client Jabber si connettono per rendere possibile la conversazione. Questo server può

creare una rete Jabber privata (dietro a un firewall, ad esempio), o può far parte di una rete

Jabber globale e pubblica. Le caratteristiche principali di Jabber sono la natura distribuita

del sistema di messaggistica e l'uso dello streaming XML.

Una caratteristica unica del sistema Jabber è quella dei transport, anche conosciuti come

gateway o agenti, che consentono agli utenti di accedere a reti che usano altri protocolli,

come AIM e ICQ (usando il protocollo OSCAR), MSN Messenger e Windows Messenger

(usando il Servizio Messenger .NET), Yahoo! Messenger, SMS o Email.

A differenza dei client multiprotocollo come Trillian o Pidgin, Jabber fornisce questo

accesso a livello di server, comunicando per mezzo di servizi speciali gateway che girano

su un computer remoto.

Ogni utente Jabber può registrarsi con uno di questi gateway fornendo le informazioni

necessarie per accedere alla specifica rete, potendo quindi comunicare con utenti di quella

rotocollo Jabber Jabber è un insieme di protocolli aperti di mess

X

ed

A

Je

- 108 -

Appendice A Il protocollo Jabber

rete come se fossero utenti Jabber. Questo significa che qualsiasi client che supporta il

protocollo Jabber può essere usato per accedere ad una qualsiasi rete per la quale esista un

gateway, senza il bisogno di programmare il supporto al protocollo della nuova rete nel

client.

siddetti di base sono stati adottati dall'IETF (Internet Engineering Task

PP (Extensible Messaging and Presence Protocol ), altro nome

n cui spesso è identificato Jabber, e coprono:

Internazionalizzazione

'XMPP costituisce l'insieme dei protocolli di Instant Messaging sviluppati dalla XMPP

er (per esempio

[email protected]). La politica e le funzioni disponibili agli utenti

I protocolli co

Force) con il nome di XM

co

La tecnologia base di Streaming XML

Sicurezza

L

Standards Foundation (XSF, ex-JSF (Jabber Software Foundation)), che costituiscono il

cuore di Jabber e che l'IETF ha scelto di adottare con le Request for Comments (RFC):

RFC 3920: Il nucleo della tecnologia basata su XML e che comprende il supporto

all’internazionalizzazione e della sicurezza.

RFC 3921: Descrive le funzioni di base di IM quali, per esempio, la contact list e

la gestione delle subscriptions.

Nel sistema di Jabber, gli utenti si iscrivono a uno dei tanti serv

jabber.org), ottenendo un identificatore univoco (JID - Jabber ID) che assomiglia a un

indirizzo di posta elettronica (per esempio, l'utente Flavio registrato presso jabber.org,

viene identificato da flav

dipendono dall'amministrazione di quel server particolare; in questo rientra anche la

procedura particolare per recuperare la password in caso di smarrimento della stessa.

- 109 -


L’architettura di IM basata su XMPP è molto simile al più usato (e testato) sistema di

messaggistica esistente: l’e-mail; ci sono importanti differente ma il pensare a Jabber

come ad una ‘e-mail istantanea’ non è molto lontano dalla realtà.

ediamo con un esempio di chiarire il funzionamento della piattaforma e per farlo

un server che supporta IM con tecnologia

MPP (server Jabber), ha un suo JID. Poiché Giulietta appartiene alla famiglia dei

Cap capuleti.com. Similmente Romeo avrà un

suo JID del tipo [email protected].

Appena Giulietta esegue un log in sul server capuleti.com è in grado di inviare messaggi al

o amato; per essere più precisi accade nel momento in cui Giulietta esegue il suo client

na

onnessione al server montecchi.com (sempre che non sia già stata aperta).

Ipo

server viene indirizzato al server XMPP di

ontecchi.com.

Tal

dirige a da Romeo che con il suo palmare attende sotto al

alcone.

V

scomodiamo Romeo e Giulietta nella famosa scenda del balcone.

Giulietta non manda un messaggio direttamente a Romeo (sarebbe una comunicazione

peer to peer), Giulietta possiede un account su

X

uleti ha registrato il suo JID come giulietta@

su

IM sul suo laptop mentre è sul balcone.

A questo punto Giulietta invia un messaggio a [email protected]; il messaggio viene

a questo punto preso in consegna dal server capuleti.com che a sua volta apre u

c

tizzando che i parenti delle due famiglie non abbiano disabilitato la connessione fra i

delle due famiglie il messaggio di Giulietta

m

e server verifica che il messaggio è stato indirizzato ad un account di nome Romeo e lo

l client aperto in quel momento

b

Finalmente il messaggio appare sullo schermo del dispositivo di Romeo che appena lo

legge sospira.

La figura è semplice e familiare in quanto può benissimo rappresentare anche

l’architettura della posta elettronica; sia le comunicazioni via e-mail che tramite XMPP

sono possibili grazie ad una rete distribuita di server che utilizza un protocollo comune.

- 110 -


Clienti specifici si connettono ai server per ricevere messaggi da altri utenti e per spedirne

i consegna è possibile in

o meno di un utente è

ato su DNS e schemi URI riconosciuti in maniera

r come invece

onnessione diretta, per esempio per effettuare uno scambio di files, ma

te server e client utilizzano un socket sulla porta TCP 5222 (per le

sione è sempre attiva per tutta la durata della sessione del client con il

spedito al nostro client se siamo connessi; se non lo siamo invece il server si occupa (se

ad altri sullo stesso server o ogni altro server connesso alla rete.

La differenza principale fra l’e-mail ed i server Jabber però sta nel fatto che questi ultimi

consegnano i messaggi praticamente in tempo reale. Questo tipo d

quanto i server nel network Jabber sanno quando un utente è online come lo sanno i

contatti registrati da ciascun utente. Il sapere la disponibilità

chiamata ‘presenza’ e costituisce la chiave che permette l’istantaneità della consegna dei

messaggi.

La tecnologia di Jabber combina le caratteristiche classiche di un sistema di IM con tre

importanti caratteristiche:

1. Utilizza un set di protocolli standard, aperti e documentati.

2. Tali protocolli sono XML.

3. Gli utenti possiedono un JID bas

simile alle e-mail (user@host).

Jabber utilizza una tecnologia di tipo client-server, non di tipo peer-to-pee

altri sistemi di IM fanno (Skype per esempio). Questo implica che tutti i dati scambiati fra

due utenti passano attraverso almeno un server Jabber (in realtà i clienti possono negoziare

ed ottenere una c

questo può essere fatto sempre e comunque previa negoziazione con il server).

Nonostante nulla vieti che messaggi XMPP viaggino attraverso qualsiasi porta TCP,

solitamen

comunicazioni server-to-server invece viene utilizzata la porta 5269).

Questa connes

server e questo implica che il client può fare a meno di richiedere messaggi al server come

invece occorre fare periodicamente con le e-mail.

Quando il server riceve un messaggio a noi indirizzato questo viene immediatamente

- 111 -


opportunamente configurato) di memorizzare i messaggi che riceviamo per poterceli

consegnare non appena effettuiamo la connessione.

Grazie al fatto che queste tecnologie utilizzano protocolli aperti chiunque può

implementarle all’interno delle proprie applicazioni e questo ha portato alla realizzazione

di un notevole numero di applicazioni Jabber (sia server che client) sia commerciali che

open source.

Nel momento in cui un client si connette ad un server, apre uno stream XML dal client al

server ed il server a sua volta risponde con uno stream XML verso il client; perciò ogni

ne utilizzando questi stream nella forma di piccoli elementi di

ML (stanza) come, per esempio, il seguente messaggio da Giulietta a Romeo:

<m i.com'to='[email protected]'>

<bo

</mess

ai client; le uniche

t TCP.

sessione implica la creazione di due stream XML.

Ogni comunicazione avvie

X

essagefrom='giulietta@capulet

dy>Oh Romeo, Romeo, sei tu Romeo?</body>

age>

Se nella maggior parte di casi questi Jabber stanza sono così semplici, il formato XML

può comunque essere esteso utilizzando XML namespaces e namespaces customizzati per

applicazioni particolari. Questa peculiarità rende Jabber una potente piattaforma per il

trasferimento di ogni tipo di dato strutturato come chiamate di tipo SOAP, XML-RPC,

syndication via RSS o grafica vettoriale.

Uno dei criteri di progettazione della piattaforma Jabber includeva la possibilità di

realizzare client semplici da scrivere (semplici, per esempio, come una connessione telnet)

e per questo l’architettura della piattaforma impone poche restrizioni

cose che questi devono fare:

Comunicare con il server utilizzando socke

Effettuare parsing ed interpretare ‘stanze’ XML passate attraverso stream XML.

Gestire i data type base di Jabber: message; presence e iq.

- 112 -


L’obiettivo in Jabber è quello di spostare complessità dal client al server; da qui la relativa

facilità con cui è possibile scrivere client (come dimostra l’ampia varietà di soluzioni oggi

di concentrarsi sull’aspetto dell’interfaccia utente.

ntificata da un id univoco, il JID, che

Devono essere facili da ricordare per gli utenti.

uali un dominio, il nodo e la risorsa

i nel seguente formato: [nodo@]dominio[/risorsa].

zionale, ed afferisce ad un nodo. Permette di

a.

ota:

presente) e la possibilità di aggiungere funzionalità senza dover necessariamente

aggiornare il client.

In pratica molte delle funzioni di basso livello del client sono gestite dalle Jabber Client

Library permettendo agli sviluppatori

All’interno del network di server Jabber sono coinvolte differenti ‘entità’ che devono

comunicare una con l’altra; queste entità possono essere server, gateway, stanze di utenti o

singoli utenti ed ognuna di essere deve essere ide

deve possedere le seguenti caratteristiche:

Flessibili per poter essere inserite in altre piattaforme IM.

Ogni JID contiene una serie di elementi q

definit

Il dominio è l’identificativo primario; rappresenta il server Jabber al quale l’entità si

connette; è obbligatorio e da solo rappresenta comunque un JID valido.

Il nodo è un identificativo secondario e rappresenta l’utente; tutti i nodi vivono all’interno

di uno specifico dominio.

La risorsa è un terzo identificativo, op

identificare singole risorse che si riferiscono al medesimo nodo. Le risorse permettono al

singolo utente di mantenere diverse connessioni simultanee allo stesso server Jabber, un

esempio potrebbero essere i seguenti JID: [email protected]/balcone,

[email protected]/camer

n ricordiamo che sul sito ufficiale di Jabber si trova una lista dei server, che possono

esse

http

re utilizzati, alla seguente pagina:

://www.jabber.org/software/servers.shtml

- 113 -


A.2 Il server jabber Openfire

Sul sito di Openfire c’è un download di file di installazione (openfire_3_3_2.exe); una

volta eseguita l’installazione, comparirà un wizard che permette di settare a proprio

e:

er, e possono

utilizzata per sempre

essi i due clients;

0 e 9091 vengono utilizzate per consentire l'accesso al server da

piacimento il server, come la scelta della password per l’amministratore o la scelta del

datebase, attraverso il comando launch Admin, diventando così amministratori del server.

Una volta effettuato il login, appare una schermata che consente di controllare le proprietà

del server e l'ambiente in cui lavora. Ovviamente, a seconda del tipo di comunicazione che

avviene, verrà utilizzata una porta different

la porta 5222 viene utilizzata per connessioni standard tra client e serv

o meno essere criptate, mentre la porta 5223 viene

connessioni tra client e server, ma il server usa il metodo SSL per la criptare i dati

(non viene utilizzato quindi un protocollo XMPP);

la porta 5269, invece, viene utilizzata per connessioni tra server, affinchè sia

possibile instaurare un collegamento tra i server su cui sono conn

infine, le porte 909

parte dell'amministratore (la prima porta non ha un accesso sicuro a differenza

della seconda).

Nota: si ricorda che sul sito ufficiale di Jabber, è possibile trovare una lista dei server, che

possono essere utilizzati, al seguente link: http://www.jabber.org/software/servers.shtml

- 114 -

Appendice B

WS-Notification

S-Notification è uno standard che definisce un approccio basato su Web Services

fond

sono im

Compu

Hewlet

e specifiche dello standard comprendono:

processo di notifica e la messaggistica relativa alla presenza di un eventuale

i requisiti operazionali che devono soddisfare tutti gli elementi coinvolti nel

un modello per la descrizione delle topics.

B.1 Introduzione

W

ato su un paradigma publish/subscribe basato su topics. I promotori dello standard

portanti industrie nel settore della tecnologia, quali IBM, Akamai Technologies,

ter Associates International, SAP AG, Fujitsu Laboratories of Europe, Globus,

t-Packard, Sonic Software, TIBCO Software.

L

la messaggistica che deve essere scambiata tra i fornitori dei servizi coinvolti nel

servizio, che funga da server centralizzato e che consenta la pubblicazione di

servizi e messaggi;

processo di notifica;

- 115 -

Appendice B WS-Notification

Tramite WS-Notification risulta quindi possibile la costruzione di un sistema scalabile

indipendente dalla piattaforma costituito da nodi autonomi che si scambiano tra loro

messaggi in maniera asincrona.

Nel proseguo dell’appendice verrà fatta una breve introduzione sui concetti di paradigma

publish/subscribe e verranno infine elencate tutte le entità che compongono lo standard.

publish/subscribe

2. Subscribers

I primi

di inter

coloro l loro interesse a ricevere particolari messaggi e li ricevono dal

essaging system non appena essi vengono pubblicati.

I maggiori vantaggi derivati dall’uso di questo paradigma sono:

istema: che consente la realizzazione di

semplici subscribers come unità di lavoro atomiche e isolate, che non necessitano

di un meccanismo di comunicazione tra di loro. Analogamente lo stesso vale per i

publishers;

B.2 Le architetture

Le architetture publish/subscribe sono un esempio di sistema distribuito basato sull’invio

di messaggi asincrono allo scopo di offrire miglior scalabilità e dinamicità alla tipologia

della rete.

Il paradigma publish/subscribe è composto da due particolari entità:

1. Publishers

sono i componenti che inviano i messaggi associandoli a uno specifico argomento

esse (detto topic) o inviandoli direttamente agli appositi ricevitori; i secondi sono

i quali comunicano i

m

la mancanza di obbligo di sincronismo nel s

- 116 -


il disaccoppiamento tra publishers e subscribers: con il paradigma

publish/subscribe è il concetto di topic a ottenere il focus maggiore. Publishers e

ta

caratteristica è contrapposta, ad esempio, alle architetture client-server, che

mantengono un forte accoppiamento tra le due parti. Infatti, ad esempio, un client

non può inviare un messaggio al server se il processo dedicato nel server non è

de nelle architetture tradizionali client-server. L’aggiunta di subscribers inoltre

ti la suddivisione su

diverse CPUs delle operazioni da effettuare all’avvento di un determinato evento.

.3 Le entità WS-Notification

Topic: l’argomento di interesse al quale viene associata ogni sottoscrizione.

ri è necessario inviare un

messaggio di notifica. Questa entità in altre architetture publish/subscribe viene

ediante relazioni di tipo “is a”. Tali relazioni implicano che la notifica

subscibers possono essere completamente ignoranti sulla tipologia della rete,

continuando a operare normalmente indipendentemente dal resto. Ques

attivo;

il miglioramento della scalabilità del sistema: sia i publishers che i subscribers

possono essere facilmente aggiunti al sistema senza intaccarne le prestazioni, come

acca

può essere sfruttata per politiche di load balancing riguardan

B

Le specifiche WS-Notification definiscono tutte le entità che prendono parte al processo di

notifica; di queste le principali sono:

Tramite essa è possibile determinare a quali sottoscritto

identificata dal nome subject.

Topic Tree: la struttura che identifica un insieme di Topics organizzate in maniera

gerarchica m

- 117 -


di una Topic di livello basso nel Topic Tree comporti implicitamente la notifica

entare funzionalità come la gestione delle sottoscrizioni, per questo essi

sono spesso associati a NotificationBrokers che svolgono per loro tale funzione.

generata, ed inviare il messaggio solo a quest’ultimi.

a service requestor inviando richieste di

sottoscrizione a uno o più NotificationProducers. Un Subscriber non è tenuto a

enti, quali, ad esempio, i NotificationConsumers.

NotificationBroker: il Web Service che implementa sia l’interfaccia

della Topic “padre” in maniera ricorsiva fino al raggiungimento della radice

dell’albero.

Publisher: l’entità che invia i messaggi di notifica. Il suo compito principale è

quello di monitorare particolari situazioni, al fine di ravvisare l’accadimento di

determinati eventi, e di trasformare tali eventi in messaggi di notifica conformi allo

standard WS-Notification. Un Publisher non è tenuto ad essere un Web Service e a

implem

NotificationProducer: il Web Service che implementa l’omonima interfaccia

NotificatioProducer e che supporta una o più Topics. Il suo compito è registrare le

sottoscrizioni agli eventi e, al momento di inviare un messaggio di notifica,

scandire l’intera lista dei sottoscrittori, al fine di trovare quelli associati alla Topic

Subscriber: l’entità che funge d

ricevere messaggi di notifica, di conseguenza viene sfruttato per richiedere servizi

che usufruiranno altri compon

NotificationConsumer: il Web Service che implementa l’omonima interfaccia

NotificationConsumer. Esso ha la funzione di inviare richieste di sottoscrizione e

ricevere i messaggi di notifica dai NotificationProducers.

NotificationProducer che quella NotificationConsumer. Il suo compito è quello di

fare da intermediario tra richiedenti e fornitori di servizio, che nelle

- 118 -


implementazioni WS-Notification classiche sono rispettivamente

NotificationConsumer e Publisher. Avendo il ruolo di intermediario un

NotificationBroker offre anche funzionalità addizionali. Consente infatti ai

generatori di notifiche di essere semplici Publisher offrendo esso stesso le

B.4 E

WS

specific

usando

In princ

2.

di un server centrale (NotificationBroker) per la gestione e la pubblicazione delle

3. e l’organizzazione degli

eventi di interesse in Topics e Topic Trees.

funzionalità di NotificationProducer, può inoltre essere sfruttato dai

NotificationConsumer come finder service per tutte le Topics, oppurepuò offrire

anonimato tra richiedenti e fornitori di servizi, ecc.

voluzione dello standard WS-Notification

-Notification nasce nel marzo 2004 come una famiglia di white papers correlati e

he che definiscono un approccio standard basato su Web Services alla notifica

un’architettura publish/subscribe basata su topics.

ipio lo standard era basato su tre white papers:

1. WS-BaseNotification 1.0: specifica delle operazioni base di notifica e

sottoscrizione ad eventi;

WS-BrokeredNotification 1.0: specifica riguardante architetture centralizzate dotate

sottoscrizioni e delle notifiche;

WS-Topics 1.0: specifica incentrata sulla strutturazione

- 119 -


Oltre a

Service

Notific

Allo st

fase di

distribu

di mod ggiunta di nuove primitive e la

odifica di quelle esistenti rendendole quindi non retrocompatibili con le versioni

recedenti.

e principali variazioni presenti nella versione 1.3 sono le seguenti:

ione che non tiene conto della

normale sintassi XML associata a tali messaggi.

Modifica della sintassi del messaggi Subscribe con l’aggiunta del tag Filter che ha

(dal nome della Topic, a particolari condizioni che

devono avvenire nel NotificationConsumer, a particolari tipi di messaggio di

Realizzazione di un meccanismo di “Pull-Style Notification” e delle procedure per

iche in un qualsiasi

istante di tempo. Questa strategia può risultare di intralcio in particolari situazioni,

ad esempio se il consumer è protetto da firewall. E’ stato quindi realizzato un

sistema tramite il quale le notifiche vengono inviae non più al consumer, ma a un

i white papers sono stati pubblicati anche i documenti WSDL riguardanti i Web

s coinvolti nell’architettura, quali NotificationConsumer, NotificationProducer e

ationBroker.

ato attuale i white papers WS-BaseNotification e WS-BrokeredNotification sono in

public review presso il consorzio OASIS. La fase di public review ha portato alla

zione delle versioni 1.3 di tali withe papers. Tale versione comporta l’introduzione

ifiche sostanziali al protocollo che comprendono l’a

m

p

L

Le notifiche possono essere inviate anche in modo “raw”, cioè seguendo un

metodo non standard specifico per ogni applicaz

lo scopo di inglobare al suo interno tutte le condizioni sotto le quali avviene la

registrazione dell’evento

notifica, ecc.). Tali funzionalità erano adottabili, con modalità leggermente diverse,

nella vecchia versione mediante l’utilizzo dei tag Precondition e Selector.

la sua gestione. Nell’architettura classica (push-style) il NotificationConsumer

doveva restare costantemente in ascolto per ricevere notif

- 120 -


particolare gestore detto PullPoint che sarà controllato poi dal

NotificationConsumer o a intervalli regolari o secondo la discrezione dell’utente.

Un’analogia può essere fatta con i protocolli per la gestione della posta elettronica

pito di aggiornare la data di scadenza della sottoscrizione e Unsubscribe, con

il compito di annullare una sottoscrizione effettuata. L’assenza delle procedura

versioni precedenti la

1.3.

IBM no

già agg a pensare che le specifiche 1.3

iverranno ben presto ufficiali. Parallelamente alla creazione di WS-Notification, IBM ha

real

protoco

per la r

del tutt

Notific

risulta

er queste caratteristiche WS-Eventing è stata usata per realizzazione del

Not

WS-Ev

sistema

SMTP (push-style) e POP3 (pullstyle). Analogamente al POP3 un PullPoint ha

implementate procedure tramite le quali il NotificationConsumer può ricevere e

eliminare i messaggi in esso contenuti.

Aggiunta di nuove procedure per la gestione delle sottoscrizioni come Renew, con

il com

Unsubscribe è la più grave lacuna del protocollo nelle sue

n ha ancora rilasciato dei white papers ufficiali conformi alle specifiche 1.3 ma ha

iornato i propri documenti WSDL e ciò lasci

d

izzato nell’agosto del 2004 (cinque mesi dopo la pubblicazione di WS-Notification) il

llo WS-Eventing. Le specifiche WS-Eventing definiscono un approccio standard

ealizzazione di un’architettura publish/subscribe basata su Web Services in maniera

o simile a quella proposta dal white paper WS-BaseNotification dello standard WS-

ation. La principale differenza tra le due specifiche sta nel fatto che WS-Eventing

più semplice e completa della precedente.

P

ificationBroker WSMG al posto di WS-BaseNotification, nonostante le specifiche

enting non includessero la possibilità di utilizzo di un NotificationBroker nel

.

- 121 -

Appendice C

Note implementative

In ques

lavoro

Per il s

installa acchina, con CPU processore Pentium 4 Intel 3.00 Ghz con 512 MB di

AM su cui è installato Windows XP professional ver. 2002 service pack 2, la versione di

e sono state memorizzate.

to capitolo è stata fatta la scelta di utilizzare come web container Tomcat, in

articolare la versione 6.0, e come Web Services tool Axis, in particolare la versione 1.4,

di seguito si spiega brevemente come installare Axis.

ta sezione vengono riportati le versioni dei strumenti software utilizzati in questo

di tesi.

erver Openfire si rimanda all’appendice A, paragrafo A.2; in particolare è stato

to su una m

R

Openfire 3.3.2, l’ultima versione disponibile (giugno 2007). Inoltre tale server è

disponibile anche per ambienti Linux e Mac.

Come versione di Java è stata utilizzata la versione 6 con il relativo JDK 6.0, invece come

versione di Eclipse la 3.2, in particolare wtp-all-in-one-sdk-R-1.5.3.

Mentre la versione della libreria Smack API utilizzata è la 3.0.4.

In particolare dal sito (link: http://www.igniterealtime.org/projects/smack/index.jsp) è

possibile scaricare un archivio contente quattro jar (archivi java), quest’ultimi contengono

le classi che sono state utilizzate nell’implementazione del servizio IM e vanno inseriti nel

progetto come librerie indicandone il percorso dov

C.1 Installazione di Axis

Nel quar

p

- 122 -

Appendice C Note implementative

Dopo aver installato Tomcat, dal sito ufficiale di Axis si scarica il file di installazione,

all’interno di questo, oltre alla documentazione, esempi, etc., è presente la cartella axis

(sotto la cartella webapps) che contiene tutte le risorse necessarie al funzionamento di

Axis. Essa va inserita nel Servlet Engine di cui si dispone cioè il nostro Tomcat installato.

In questo caso, dunque, la cartella va copiata sotto la webapps di Tomcat. In questo modo

nostro server di un Web service engine in grado di esaudire richieste

lient WS. Per controllare la corretta installazione di Axis, una

olta avviato Tomcat, tramite browser si va al seguente link http://localhost:8080/axis/ e

utti i pacchetti necessari al suo corretto funzionamento (figura c.1).

igura c.1 – Homepage di Axis

si è dotato il

provenienti da qualsiasi c

v

se la pagina viene visualizzata significa che Axis è presente ma si deve controllare che

siano presenti t

F

Sulla prima pagina di Axis si possono notare alcuni link il primo dei quali è Validation.

Facendo click su di esso ci viene restituita una pagina chiamata Axis Happiness Page che

riporta i risultati dell’analisi della configurazione di Axis (Figura c.2). Vengono riportati i

- 123 -

Appendice C Note implementative

componenti necessari ed opzionali al funzionamento di Axis ed il path ai relativi pacchetti

nel caso in cui siano stati trovati.

Figura c.2 - Pagina di validazione di Axis (Axis Happiness Page)

ponenti necessari devono ovviamente essere tutti presenti, poichè senza di essi Axis

non funzionerà correttamente. I componenti opzionali devono essere presenti solo nei casi

in cui le applicazioni sviluppate ne facciano uso.

I pacchetti mancanti, nel caso ve ne siano, devono essere inseriti nella directo

<TOMCAT_HOME>\webapps\axis\WEB-INF\lib; riavviando Tomcat tali pacc

vengono rilevati automaticamente e ciò può essere verificato semplicemente ricaricando la

I com

ry

hetti

pagina di validazione di Axis (A otifica della mancanza dei

acchetti è presentata da Axis assieme ai link alle pagine web dove questi possono essere

xis Happiness Page). La n

p

trovati e scaricati.

- 124 -

Bibliografia

[1]

[2]

[3] 99

[4]

[5]

[6] James J. Kistler and M. Satyanarayanan, Disconnected Operation in the Coda File

System, 1997

inda, ACM transactions 1985

.NET Framework Developer Center,

http://msdn2.microsoft.com/it-it/netframework/default.aspx

Object Management Group (OMG), Wireless Access and Terminal Mobility in

CORBA

The Community OpenORB Project, http://openorb.sourceforge.net/

Thomas Ledoux, OpenCORBA: A Reflective Open Broker. Reflection'

Springer-Verlag, LNCS 1616 Saint-Malo, France, July 1999

The dynamicTAO Reflective ORB, http://srg.cs.uiuc.edu/2k/dynamicTAO/

GAIA Homepage, http://choices.cs.uiuc.edu/gaia/

[7] Coda File System Web Site, http://www.coda.cs.cmu.edu/

[8] XMIDDLE Project Homepage, http://xmiddle.sourceforge.net/

[9] David Gelernter, Generative Communication in L

[10] World Wide Web consortium home page, http://www.w3.org/

[11] Java Remote Method Invocation (RMI) home page,

http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

[12] Richardson, Leonard & Ruby, Sam, RESTful Web Services, O'Reilly Publishers 2007

[13] J2ME Web Services APIs (WSA), JSR 172 home page,

http://java.sun.com/products/wsa/

[14]

- 125 -

Bibliografia

[15] Sito ufficiale della azienda TIBCO, http://www.tibco.com/

[16] Sito ufficiale della azienda BEA WebLogic, http://it.bea.com/prodotti/weblogic/

[17] Carlo Forlani (Value Team) Web Services: SOA e produttività, aprile 2006

[18] Web Service Notification protocol,

http://www-128.ibm.com/developerworks/library/specification/ws-notification/

- 126 -

Documents

Integrazione di un servizio di messagistica in un ... Bellucci Flavio.pdf · me, mi manchi un po’! E poi Chiara, la mia fidanzata, che mi ha sempre sostenuto in ogni momento e mi