Smart City E-R

ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA

FACOLTA’ DI INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA INFORMATICA

Dipartimento di Informatica — Scienza e Ingegneria

TESI DI LAUREA

in Reti di calcolatori

Infrastruttura di supporto a servizi partecipativi per dispositivi mobili in

scenari Smart City

CANDIDATO RELATORE: Altobelli Andrea Chiar.mo Prof. Ing. Antonio Corradi

CORRELATORE/CORRELATORI

Dott. Nicola Mezzetti Ing. Luca Foschini

Anno Accademico 2011/2012

Sessione III

Introduzione

Il nuovo modello di città evoluta, o Smart City, si propone come esempio di sviluppo a tendere per le metropoli del futuro per affrontare e coniugare le sfide della crescita economica, della sostenibilità ambientale e sociale, dell’innovazione tecnologica e scientifica. Oltre a principi quali lo sviluppo delle infrastrutture ICT e della mobilità, l’economia della conoscenza, l’elevata qualità della vita e l’efficienza energetica, un aspetto fondamentale della Smart City è rappresentato dalla strategia di governance trasparente, aperta e inclusiva, che stimola la partecipazione dei cittadini trasformandoli da attori passivi a protagonisti e fautori delle dinamiche di sviluppo urbano. Le tecnologie ICT rappresentano importanti strumenti per l’incentivazione della partecipazione dei cittadini, e combinate ai principi dell’open data danno luogo a servizi partecipativi di nuova generazione per favorire la collaborazione e il coordinamento diretto tra gli individui stessi, nella direzione del modello di cittadino intelligente della Smart City.

I dispositivi mobili, quali smarphone e tablet, rappresentano un potente strumento a supporto dei servizi partecipativi, fornendi una connettività ubiqua e pervasiva permettendo la fruizione dei servizi in ogni luogo e in ogni momento. Questi dispositivi sono anche dotati di una vasta gamma di sensori integrati, da sistemi di posizionamento a microfono, accelerometro, fotocamera, giroscopio, che permettono la rilevazione dello stato dell’utente e dell’ambiente circostante, trasformando gli utenti in una enorme rete pervasiva di rilevazione dispiegata su tutto il territorio urbano.

La combinazione sinergica del filone del mobile sensing con la componente partecipativa che caratterizza la Smart City rappresenta un elemento di forte innovatività con molteplici ambiti d’applicazione, che possono andare dalla raccolta dei dati per la costruzione di indicatori ambientali a sistemi di segnalazione delle criticità del territorio. Uno degli scenari di maggiore interesse e che prenderemo come riferimento è quello della sicurezza e del soccorso in situazioni di emergenza, in cui la collaborazione e il coordinamento tra gli individui della comunità possono dare un contributo decisivo nelle operazioni di soccorso. La criticità dello scenario richiede la presenza di una piattaforma che supporti in modo adeguato l’interazione e il coordinamento tra gli utenti. Ci poniamo quindi l’obiettivo di realizzare un’infrastruttura di supporto a servizi partecipativi per dispositivi mobili, capace di

Infrastruttura di supporto a scenari Smart City

4

raccogliere le informazioni provenienti dagli utenti per attuare processi partecipativi che coinvolgano non solo gli organi delle amministrazioni pubbliche ma anche e soprattutto gli altri cittadini, proponendosi come piattaforma di promozione dell’interazione e della collaborazione degli individui all’interno della comunità. Pur prendendo inizialmente come riferimento lo scenario dell’emergency, il nostro obiettivo è ottenere una soluzione generale applicabile ad un qualsiasi scenario partecipativo.

A tal fine procederemo dapprima, nel corso del Capitolo 1, a enunciare i principi che caratterizzano il modello Smart City, ponendo particolare attenzione sull’aspetto partecipativo e analizzando alcuni esempi di servizi ritenuti particolarmente significativi. In seguito, nel Capitolo 2 esamineremo lo scenario dei dispositivi mobili, in quanto caratterizzato da elementi peculiari legati alla mobilità degli utenti e alla natura wireless della comunicazione. Nel Capitolo 3 entreremo nel merito delle piattaforme e dei sistemi operativi più diffusi nello scenario dei dispositivi mobili, ponendo particolare attenzione sulla piattaforma Android, che oltre ad ampio supporto ai sensori e ad una elevata diffusione nel mercato offre importanti caratteristiche di apertura e portabilità. Il Capitolo 4 sarà invece improntato al confronto delle piattaforme indirizzate all’ambito delle applicazioni enterprise, particolari classi di applicazioni destinati ad ambiti aziendali che devono affrontare particolari sfide di scalabilità e interoperabilità e garantire al tempo stesso numerosi servizi e funzionalità di supporto. In particolare, scenderemo nel dettaglio del framework Spring, caratterizzato da un approccio a container leggero e un approccio particolarmente flessibile per lo sviluppo delle applicazioni. Nel Capitolo 5 entreremo nel cuore della trattazione descrivendo nel dettaglio l’architettura e le funzionalità dell’infrastruttura di supporto che abbiamo realizzato. Infine, il Capitolo 6 sarà orientato allo sviluppo di un caso concreto di applicazione, basata sull’infrastruttura di supporto del capitolo precedente, all’interno dello scenario dell’emergency. Questo ci permetterà di valutare l’impatto dell’infrastruttura sia in merito al processo di sviluppo dei servizi partecipativi, sia per quanto riguarda le prestazioni e gli eventuali colli di bottiglia che caratterizzano il sistema.

Indice

Introduzione.. ...................................................................................... 1

Indice……… ...................................................................................... 5

1 - Smart City e servizi partecipativi ............................................... 9

1.1 - Definizione di Smart City ................................................................... 11

1.2 - Smart City e Digital City .................................................................... 13

1.3 - Infrastruttura tecnologica .................................................................... 14

1.3.1 Internet of Things ........................................................................... 14

1.3.2 Cloud Computing ........................................................................... 15

1.4 - Servizi partecipativi ............................................................................ 16

1.4.1 Dall’e-government alla governance ............................................... 17

1.4.2 Open government ........................................................................... 19

1.4.3 Il ruolo dei dispositivi mobili ......................................................... 21

1.4.4 Esempi di servizi partecipativi ....................................................... 22

1.5 - Conclusioni ......................................................................................... 25

2 - Sistemi mobili e mobile sensing ............................................... 27

2.1 - Generalità ............................................................................................ 29

2.1.1 Servizi e applicazioni mobile ......................................................... 29

2.1.2 L’ambiente mobile ......................................................................... 30

2.1.3 Mobilità .......................................................................................... 31


6

2.2 - Comunicazione wireless ..................................................................... 31

2.2.1 Reti cellulari ................................................................................... 32

2.2.2 Wireless LAN ................................................................................ 34

2.2.3 Wireless MAN ............................................................................... 35

2.2.4 Personal Area Network .................................................................. 35

2.2.5 Confronto ....................................................................................... 36

2.3 - Mobile messaging .............................................................................. 37

2.3.1 Concetti generali ............................................................................ 37

2.3.2 Java Message Service .................................................................... 42

2.3.3 XMPP ............................................................................................ 44

2.3.4 Web Services ................................................................................. 45

2.3.5 Il Web e REST ............................................................................... 48

2.4 - Mobile sensing ................................................................................... 52

2.4.1 Sensori ........................................................................................... 53

2.4.2 Scale di sensing .............................................................................. 56

2.4.3 Paradigmi di sensing ...................................................................... 57

2.4.4 Architetture di sensing ................................................................... 58

2.4.5 Location Awareness ....................................................................... 63

2.5 - Conclusioni ......................................................................................... 67

3 - Piattaforme per dispositivi mobili ............................................ 69

3.1 - Piattaforme software ........................................................................... 70

3.1.1 Java ME ......................................................................................... 71

3.1.2 Symbian OS ................................................................................... 73

3.1.3 iOS ................................................................................................. 74

3.1.4 Windows Mobile & Windows 8 .................................................... 76

3.1.5 Flash Lite ....................................................................................... 78

3.1.6 Android .......................................................................................... 79

3.1.7 Confronto ....................................................................................... 81

3.2 - La piattaforma Android ...................................................................... 83

3.2.1 Caratteristiche ................................................................................ 84


7

3.2.2 Principi applicativi ......................................................................... 86

3.2.3 Posizione e sensori ......................................................................... 97

3.3 - Conclusioni ....................................................................................... 109

4 - Piattaforme per applicazioni enterprise .................................. 111

4.1 - Generalità .......................................................................................... 113

4.1.1 Evoluzione delle applicazioni enterprise ..................................... 113

4.1.2 Il modello three-tier ..................................................................... 115

4.1.3 Componenti e container ............................................................... 116

4.2 - Piattaforme enterprise ....................................................................... 117

4.2.1 Microsoft .NET ............................................................................ 118

4.2.2 Java Enterprise Edition ................................................................ 121

4.2.3 Spring ........................................................................................... 125

4.2.4 Confronto ..................................................................................... 130

4.3 - Il framework Spring .......................................................................... 132

4.3.1 Container e IoC ............................................................................ 132

4.3.2 AOP in Spring .............................................................................. 147

4.3.3 Livello dei dati ............................................................................. 159

4.3.4 Spring MVC ................................................................................. 167

4.4 - Conclusioni ....................................................................................... 182

5 - Infrastruttura di supporto a servizi partecipativi ..................... 185

5.1 - Scenario di riferimento ..................................................................... 186

5.1.1 Esempi di servizi .......................................................................... 186

5.1.2 Elementi comuni .......................................................................... 188

5.1.3 La piattaforma .............................................................................. 191

5.1.4 Obiettivi ....................................................................................... 192

5.2 - Il sistema complessivo ...................................................................... 194

5.2.1 Funzionalità generali .................................................................... 194

5.2.2 Architettura .................................................................................. 196

5.3 - Client ................................................................................................ 198

5.3.1 Sensing ......................................................................................... 199


8

5.3.2 Architettura .................................................................................. 200

5.3.3 SensorClient e ContextClient ...................................................... 202

5.3.4 SensingController e ContextController ....................................... 206

5.3.5 FeatureExtractor .......................................................................... 207

5.3.6 UploadController ......................................................................... 208

5.3.7 Cycle Optimization e Low Battery Mode .................................... 209

5.3.8 LocalRepository ........................................................................... 212

5.3.9 Configurazione degli intent ......................................................... 212

5.4 - Server ................................................................................................ 215

5.4.1 Presentation Layer ....................................................................... 217

5.4.2 Business Layer ............................................................................. 219

5.4.3 PersistenceLayer .......................................................................... 231

5.5 - Conclusioni ....................................................................................... 232

6 - Il caso di Emergency Alert ..................................................... 233

6.1 - Caratteristiche del servizio ............................................................... 234

6.1.1 Tipi di Alert ................................................................................. 235

6.1.2 Sensing ......................................................................................... 236

6.2 - Implementazione .............................................................................. 237

6.2.1 Alert ............................................................................................. 238

6.2.2 Client ............................................................................................ 239

6.2.3 Server ........................................................................................... 255

6.3 - Risultati sperimentali ........................................................................ 265

6.3.1 Client ............................................................................................ 265

6.3.2 Server ........................................................................................... 268

6.4 - Conclusioni ....................................................................................... 270

Conclusioni… ................................................................................. 273

Bibliografia.. ................................................................................... 275

1 - Smart City e servizi partecipativi

Fin dagli albori della civiltà umana, e con l’abbandono delle abitudini nomadi, l’uomo ha cominciato a strutturare la sua vita all’interno di comunità, organizzate secondo ben precise regole sociali e urbanistiche. La disponibilità di risorse naturali, come fiumi o pianure agricole, o la predisposizione all’attività artigianale e commerciale, erano le forze trainanti che spingevano le comunità a insediarsi in un territorio piuttosto che in un altro. Con il passare dei secoli i processi di civilizzazione e urbanizzazione hanno portato allo sviluppo di centri urbani sempre più complessi ed evoluti: partendo dai primi centri rurali, passando per le polis greche e i comuni rinascimentali, per giungere, attraverso la crescita vertiginosa portata delle rivoluzioni industriali, alle metropoli e megalopoli odierne, caratterizzate da milioni di abitanti e estensioni nell’ordine di migliaia di kilometri. Basti pensare che se nel 1800 la percentuale di popolazione mondiale che viveva in città si aggirava intorno al 2%, già nel 1950 era salita al 30%. Nel 2011 il resoconto delle Nazioni Unite sull’urbanizzazione rileva una percentuale di oltre il 50% della popolazione residente nei centri urbani, corrispondente a 3,3 Mld di persone, e stima che salirà al 60% entro il 2013. Il 10% dell’intera popolazione urbana, inoltre, è concentrato in 21 megalopoli, ognuna con oltre 10 milioni di abitanti, e nel 2015 saranno ben 60 città a superare gli 8 milioni [ONU11].

La storia evidenzia come l’organizzazione in centri urbani costituisca un modello di successo per la vita sociale dell’uomo. I benefici sono molteplici: un migliore utilizzo delle risorse naturali, la specializzazione delle attività dei cittadini, l’incentivazione dello sviluppo economico e culturale, costituendo la città uno snodo per commerci e finanza e il fulcro dell’accrescimento e dello scambio della conoscenza. Allo stesso tempo però con l’aumentare della dimensione e della densità dei centri urbani, è necessario realizzare sistemi sempre più complessi per gestire


10

l’approvvigionamento di cibo, energia e acqua, il traffico urbano, i servizi amministrativi, i rifiuti, la popolazione stessa e così via. Non a caso nell’immaginario comune il concetto di metropoli è spesso associato a un ambiente affollato, caotico, frenetico, trafficato, inquinato e a volte anche pericoloso. Dati alla mano, il 45% del consumo energetico mondiale e il 50% dell’inquinamento atmosferico provengono dai centri urbani [CAR12].

In questo quadro il concetto di “Smart City”, e in particolare l’aggettivo “Smart”, si riferisce alla soluzione delle problematiche legate agli agglomerati urbani attraverso soluzioni efficienti e, per l'appunto, intelligenti, permettendo quindi alle moderne città di crescere attraverso il miglioramento quantitativo e qualitativo della produttività. Requisito fondamentale per raggiungere tale obiettivo consiste nel potenziamento e nell’utilizzo dell’infrastruttura ICT per l’orchestrazione e l’armonizzazione delle dinamiche urbane.

È importante considerare che le prestazioni urbane, oggigiorno, non dipendono esclusivamente dalle infrastrutture materiali della città (il cosiddetto “capitale fisico”), ma anche, e sempre di più, dalla disponibilità e dalla qualità dell’infrastruttura sociale e di comunicazione delle conoscenze, ciò che è denominato “capitale sociale e umano”, e che costituisce una componente altrettanto determinante per la competitività urbana. In questo contesto il concetto di “città intelligente” è stato introdotto come strumento strategico per comprendere i moderni fattori produttivi in un quadro comune e, in particolare, per sottolineare l’importanza che le Tecnologie dell’Informazione e della Comunicazione (ICT) hanno avuto negli ultimi 20 anni per migliorare il profilo competitivo della città, in tutti i suoi aspetti. Vedremo, infatti, che la Smart City coinvolge molteplici aspetti, sia economici che sociali, sia tecnologici che umani, in una visione completa e integrata orientata allo sviluppo e alla creazione di competitività in maniera sostenibile, ed in cui le ICT rappresentano uno strumento per migliorare la qualità della vita dei cittadini in tutti i suoi aspetti. La “smartness” di una città è data, oltre che dalle infrastrutture tecnologiche e dall’economia, da un’impronta ambientale ecologica, da una popolazione consapevole e partecipe nella vita pubblica, da un sistema di trasporti innovativo, da un contesto vivibile e culturale, ed infine da un modello gestionale dinamico, aperto e collaborativo che sappia utilizzare al meglio le risorse della città per sostenere le sfide del futuro.

I cittadini della Smart City, individui non solo istruiti, ma anche creativi, dinamici, digitalizzati e responsabilizzati, ne rappresentano la spina dorsale, sia nel ruolo di oggetti che di soggetti del processo di sviluppo urbano. Per interpretare al meglio la visione della Smart City, ed evitare di trasformarla in una corsa cieca al dispiegamento di infrastrutture ad alta tecnologia, la partecipazione civica e l’intelligenza collettiva sono risorse indispensabili che devono essere opportunamente valorizzate. I servizi di tipo partecipativo rappresentano una risposta a questa necessità, costituendo al tempo stesso un punto d’incontro tra il cittadino e l’amministrazione e un perno di coesione sociale per la comunità stessa. Non solo, in una Smart City connessa, che abilita l’accesso ubiquo a Internet e dove le persone interagiscono liberamente attraverso i social network, la connettività rappresenta un dono incredibile per gli individui, che aumenta il loro potere come agenti del


11

cambiamento e li aiuta a coordinarsi in modo intelligente per cogliere le sfide collettive del futuro.

Nel corso della trattazione procederemo quindi a delineare il concetto di Smart City in tutte le sue sfaccettature, riportando inoltre esempi concreti utili a comprendere un’immagine che risulta spesso vaga e retorica. Dopodiché, ci soffermeremo sull’aspetto partecipativo che la contraddistingue, e sugli strumenti offerti dalle ICT che permettono di concretizzare questo modello.

1.1 - Definizione di Smart City Negli ultimi anni il concetto di Smart City è stato molto in voga sia all’interno

dell’ambiente politico che di quello ICT, e troviamo in letteratura diverse versioni della definizione di Smart City, spesso non tutte congruenti tra loro. Gli autori di [SUL11], ad esempio, danno una descrizione del concetto di Smart City prevalentemente improntata sull’ICT, definendola come il risultato dell’applicazione delle tecnologie di nuova generazione alla vita di tutti i giorni, integrando sensori e dispositivi in ospedali, rete energetica, strade, edifici etc. Altri studi invece, come quello degli autori di [GLA06], mettono in risalto la relazione tra la crescita urbana e il suo capitale umano. Altre volte invece il termine Smart City è usato, anziché secondo un approccio olistico per descrivere una città con certe caratteristiche, per etichettare un particolare aspetto in cui una città eccelle, che può variare dall’afferenza a un particolare distretto IT all’educazione dei cittadini. Il termine viene così usato nel campo economico con riferimento all’industria “intelligente”, specialmente se si tratta di distretti tecnologici, oppure per porre l’accento sul grado d’istruzione dei suoi abitanti, con riferimento al rapporto tra i dipartimenti amministrativi e i cittadini, per indicare l’utilizzo delle moderne tecnologie nella vita urbana di tutti i giorni, o ancora per l’elevata sostenibilità energetica e ambientale.

Per fare ordine in questo scenario così variegato possiamo fare riferimento a un progetto condotto dal Centro di Scienza Regionale di Vienna [GIF07] che ha esplorato le diverse interpretazioni individuando sei dimensioni principali, riassunte in Figura 1, secondo cui misurare il grado di sviluppo delle cosiddette Smart City: economia, mobilità, ambiente, cittadini, qualità della vita e amministrazione. La “Smart Economy” include fattori riguardanti tutte le sfere della competitività come innovazione, imprenditorialità, marchi, produttività e flessibilità del mercato del lavoro così come l’integrazione con il mercato nazionale e internazionale. La Smart City rappresenta un ambiente fortemente competitivo e la sua economia è basata su settori tecnologici all’avanguardia. Per “Smart People” non s’intende solo il livello di qualifica e d’istruzione dei cittadini, ma anche la qualità delle interazioni sociali sotto gli aspetti dell’integrazione e della vita pubblica, l’apertura verso l’ambiente esterno, una ritrovata consapevolezza e partecipazione nella vita pubblica, la pacifica convivenza tra le diverse comunità. Gli abitanti della città intelligente sono responsabilizzati e partecipi, e la Smart City riconosce loro un ruolo di primo piano. La “Smart Governance” comprende sia aspetti riguardanti la partecipazione politica e i servizi per il cittadino, sia il funzionamento e l’efficienza dell’amministrazione pubblica, nonché la presenza di un orizzonte amministrativo e strategico a lungo


12

termine che guidi in modo intelligente le politiche di sviluppo a breve termine. “Smart Mobility” significa un sistema di trasporto pubblico sostenibile e moderno, con soluzioni avanzate di mobility management per una migliore vivibilità, info-mobilità per gestire gli spostamenti dei cittadini, così come la disponibilità di un’infrastruttura tecnologica di Informazione e Telecomunicazione. Lo “Smart Enviroment” è rappresentato dalla riduzione delle emissioni attraverso l’ottimizzazione del traffico e delle emissioni industriali, la promozione dello sviluppo sostenibile aumentando la raccolta differenziata e riducendo l’ammontare dei rifiuti, la gestione efficiente delle risorse e la tutela del verde urbano, nonché il recupero delle aree dismesse. Lo “Smart Living”, infine, racchiude vari aspetti della qualità della vita come cultura, salute, sicurezza, abitabilità, turismo, e fa riferimento in generale alla vivibilità della città. La Smart City costituisce un ambiente culturalmente attivo e stimolante, che promuove ad esempio la propria immagine turistica e valorizza la sua storia e identità tramite strumenti tecnologici e innovativi, rendendo il proprio patrimonio culturale accessibile in rete e creando percorsi e mappe tematiche della città.

Figura 1 - Dimensioni di valutazione di una Smart City

In conformità a questi principi, gli autori di [CAR09] hanno formulato una definizione largamente accettata e diffusa, definendo una città “intelligente” quando “gli investimenti in capitale, umano e sociale, e nell’infrastruttura di comunicazione, tradizionale (trasporti) e moderna (ICT), alimentano una crescita economica sostenibile e un’elevata qualità della vita, con un’efficiente gestione delle risorse naturali e attraverso un’amministrazione partecipata”.


13

Tale definizione mostra sì l’importanza dello sviluppo dell’infrastruttura ICT e della crescita economica, ma evidenzia anche e soprattutto il ruolo del capitale umano e sociale, mirando a ottenere il coinvolgimento collettivo dei cittadini nei servizi pubblici e affiancandovi il requisito di sostenibilità dello sviluppo urbano. La Smart City rappresenta quindi un concetto complesso che raccoglie in modo organico molteplici fattori interdipendenti, oltrepassando i soli aspetti tecnologici ed economici e distinguendosi dal mero stereotipo della città digitale.

1.2 - Smart City e Digital City Come già accennato, spesso si commette l’errore di ridurre il concetto di Smart

City a quello di una città con una solida ed evoluta infrastruttura ICT mentre, come abbiamo evidenziato, la definizione più accettata è ben più ampia e coinvolge congiuntamente capitale fisico, sociale e intellettuale. Ebbene questa è la sostanziale differenza che intercorre tra i concetti di Smart City e Digital City.

Come spiegano gli autori di [ISH00], infatti, il concetto di Digital City fa riferimento a una comunità urbana connessa che combina un’infrastruttura di comunicazione a banda larga, un’infrastruttura di elaborazione di tipo service-oriented basata su standard industriali aperti, e una gamma di servizi volti a soddisfare le necessità dell’amministrazione e dei suoi impiegati, cittadini, e imprese. Altro requisito fondamentale della Digital City è la presenza di un’infrastruttura wireless capillare e su larga scala che si appoggia alla rete cablata a banda larga. La Digital City è inoltre dotata, secondo gli autori di [SUL11], di un’estesa rete di sensori disseminata negli spazi urbani, e fa riferimento a una serie di tecnologie d’informazione di localizzazione come il Sistema di Posizionamento Globale (Global Positioning System, GPS) e il Sistema Informativo Geografico (Geographic Information System, GIS), cioè un sistema in grado di catturare, immagazzinare, manipolare, analizzare, gestire e rappresentare dati di tipo geografico. Storicamente, a seguito del fenomeno di liberalizzazione del settore delle telecomunicazioni e la crescita dei servizi Internet che ha contraddistinto gli anni ’90, il concetto di città digitale è stato associato principalmente alle opere di cablaggio delle zone urbane con le infrastrutture di rete, processo che si è sviluppato di pari passo al proliferare dei ripetitori di telefonia mobile e Wi-Fi, e alla realizzazione da parte dei comuni delle reti civiche, le prime iniziative telematiche promosse dalle pubbliche amministrazioni.

La Smart City invece, come evidenziato dagli autori di [MOS01], è il risultato della combinazione della Digital City con una “società della conoscenza”, in cui sono valorizzati il sapere e la creatività, e il capitale sociale e umano sono considerati come la risorsa più preziosa. Ancora, secondo Kominos e Sefertzi [KOM09], la Smart City sviluppa sulla base della Digital City un’infrastruttura di servizi intelligenti per trasformare la vita dei cittadini in modo significativo e fondamentale, piuttosto che incrementale. Secondo gli autori di [CHE11], inoltre, la Smart City enfatizza, rispetto alla Digital City, la sostenibilità e l’armoniosità dello sviluppo urbano, e realizza un livello più alto dei servizi amministrativi attraverso la gestione intelligente dei processi, l’interconnessione continua dei servizi e la partecipazione dei cittadini.


14

In conclusione, come evidenziato da [KOM02], se tutte le Smart City sono anche Digital City, non è vero il contrario: l’abilità della Digital City è nell’erogazione di servizi tramite la comunicazione digitale, la Smart City è invece caratterizzata da una capacità di problem solving e usa quindi le tecnologie d’informazione per trasformare la vita dei cittadini. Ad esempio, un’amministrazione cittadina che offre via rete dei servizi prima disponibili offline rappresenta un tipico caso di Digital City, mentre un’organizzazione/ente che crea un nuovo servizio usando uno spazio digitale di consultazione e collaborazione online tra i cittadini incarna gli ideali della Smart City, in quanto coinvolge i cittadini per contribuire allo sviluppo della comunità sfruttando l’intelligenza collettiva. Procediamo quindi a descrivere più in dettaglio quali sono le caratteristiche che la contraddistinguono.

1.3 - Infrastruttura tecnologica Seppure non ne costituisca l’unico elemento caratterizzante, la componente

tecnologica è sicuramente un mattone fondamentale della Smart City. Il suo concetto di sviluppo sostenibile basato sui temi dell’economia, della sanità, dell’educazione, dell’energia, della sicurezza e dei servizi pubblici è profondamente e intrinsecamente legato a una complessa infrastruttura tecnologica che agisce da supporto. La tecnologia rappresenta uno strumento indispensabile per mettere in atto le politiche intelligenti.

Alla base della Smart City troviamo sicuramente un’estesa infrastruttura di rete interconnessa, a banda larga, che combina connessione via cavo, fibra ottica e wireless, e che copre in modo capillare il territorio urbano, offrendo ai cittadini e alle organizzazioni un’elevata connettività, sia tramite terminali fissi sia da dispositivi mobili. In secondo luogo, l’arricchimento degli spazi fisici e delle infrastrutture cittadine con una rete di dispositivi integrati e intelligenti, fatta di sensori e attuatori, consente di ottenere in tempo reale importanti informazioni sul territorio urbano. Terzo, potenti ed efficienti piattaforme di elaborazione e di archiviazione che permettano di processare la grande quantità d’informazioni generata, sulla base delle quali realizzare i servizi della città intelligente [SCH11].

I principi fondamentali di questa infrastruttura sono rappresentati, oltre che dall’ubiquità della connettività, da importanti elementi tecnologici quali Internet of Things e Cloud Computing. Procederemo quindi ad analizzare brevemente questi concetti, che non rappresentano l’obbiettivo della nostra trattazione, per chiarirne il ruolo all’interno del sistema Smart City.

1.3.1 Internet of Things Per Internet of Things (IoT), letteralmente “Internet delle Cose”, si intende

l’estensione della rete agli oggetti reali di tutti i giorni. Fino ad ora abbiamo assistito a quello che può essere definito un Internet dei contenuti, cioè in cui le informazioni che viaggiano nella rete sono generati dall’azione di un utente, più o meno volontaria. Tutti i dati che viaggiano all’interno della rete sono il frutto dell’iniziativa umana,


15

secondo quello che potremmo chiamare l’internet delle persone, o Internet of People (IoP).

Tuttavia, attraverso l’integrazione all’interno degli oggetti della vita quotidiana, dagli elettrodomestici, al cibo, al sistema energetico e d’illuminazione, agli abiti, di sensori e tag elettronici, è possibile estendere la rete formando un’infrastruttura globale in cui gli oggetti fisici hanno degli alter-ego virtuali con una propria identità e degli attributi misurabili. Abbiamo così degli oggetti intelligenti e connessi, capaci di comunicare, tramite opportune interfacce e protocolli idi comunicazione, tra di loro e con la rete, che immettono dati all’interno della rete e rappresentano il ponte tra il mondo fisico e quello virtuale.

All’interno della Smart City l’IoT ha un fortissimo impatto: l’integrazione di reti di sensori e di dispositivi all’interno dello spazio fisico della città permette di abilitare una intelligenza spaziale, cioè la capacità di collezionare ed elaborare in tempo reale informazioni geo-localizzate provenienti da tutto il territorio, con cui costruire indicatori ambientali e comportamentali che permettono di conoscere, gestire e prevedere le dinamiche urbane e mettere in atto comportamenti e strategie intelligenti [TAN10]. Tuttavia, l’elevatissimo numero di oggetti presenti all’interno della rete genera un enorme flusso di dati, la cui gestione richiede piattaforme di elaborazione potenti, scalabili e flessibili. Il Cloud Coumputing rappresenta la risposta a questa necessità.

1.3.2 Cloud Computing Il Cloud Computing, che può essere tradotto nell’equivalente italiano “nuvola

informatica”, rappresenta, più che una tecnologia, un nuovo paradigma per l’elaborazione distribuita, che integra concetti già precedentemente noti quali virtualizzazione e pooling delle risorse, utilizzandole per erogare come servizio, attraverso la rete Internet, capacità di calcolo e di archiviazione. Orientato all’insegna dei principi di scalabilità e gestione efficiente e dinamica delle risorse, permette di offrire sotto forma di servizio applicativi software (Software as a Service, SaaS), piattaforme per ospitare ogni tipo applicazione (Platform as a Service, PaaS), o infrastrutture di calcolo (Infrastructure as a Service, IaaS), personalizzate e modellate sulla base delle specifiche necessità del cliente. Il complesso sistema responsabile di queste funzionalità può essere incapsulato all’interno di un’entità astratta, il Cloud, che offre al cliente differenti livelli di servizio. Ne conseguono notevoli vantaggi in termini di riduzione dei costi e flessibilità, giacché elimina la necessità per i clienti di installare e gestire direttamente complesse infrastrutture informatiche, offrendo la possibilità di usufruirne on demand in base alle reali necessità [MOG12].

Nell’ambito della Smart City, gli autori di [SHA11] prevedono che, mentre in un momento iniziale le amministrazioni faranno ricorso principalmente a cloud commerciali, si assisterà successivamente allo sviluppo da parte delle amministrazioni di G-cloud, cioè Government-cloud, grandi cloud urbani che contribuiranno alla riduzione dei costi dell’IT e forniranno le piattaforme computazionali e la capacità di elaborazione per ospitare i servizi della città intelligente. Tramite il cloud sarà possibile quindi il mantenimento dei servizi anche in periodi di austerity, grazie alla


16

notevole flessibilità e la riduzione dei costi fissi, e il sostegno, in modo incrementale, dei settori emergenti della città nell’ambito dei servizi ICT.

1.4 - Servizi partecipativi Il concetto di “smartness” non ha una prospettiva orientata esclusivamente alla

tecnologia. Come descritto nelle sezioni precedenti, una delle risorse più importanti della Smart City è rappresentata dai cittadini stessi. La città intelligente, infatti, è composta innanzitutto da cittadini intelligenti, che rappresentano al tempo stesso i fruitori ed i fautori di servizi, opportunità, benefici e politiche messe in atto dalla Smart City, e che sanno utilizzare la tecnologia a vantaggio proprio e di tutta la comunità. Le nuove tecnologie e i nuovi media rappresentano solo degli strumenti per promuovere la crescita nel cittadino di una prospettiva civica, e la PA riveste un ruolo determinante nel mettere a disposizione dei cittadini questi strumenti.

Durante lo Smart City Exibithion 2012, Pablo Sanchez Chillón, urbanista e ricercatore sul campo Smart City, considerato il pioniere in questo campo in terra spagnola, definisce la ricetta per la crescita degli spazi urbani come basata sul modello del “Cityzentrism”, che considera i cittadini come il fulcro, la “spina dorsale” dello spazio urbano. Il concetto di “Cityzentrism” evidenzia la necessità di porre il cittadino al centro di ogni progetto della Smart City, e di coinvolgerlo in modo attivo, secondo un processo bottom-up che parte dai cittadini stessi per giungere alle amministrazioni, tenendo presente però che, nel contesto odierno in cui le persone scambiano informazioni sulle arene digitali, lo spazio per la mobilitazione civica deve mutare di conseguenza, e basarsi sui nuovi mezzi di comunicazione per incrementare il raggio di utenti. Nella città intelligente, che fornisce l’accesso ubiquo alla rete, e dove i social network favoriscono l’interazione tra le persone, il ruolo dei cittadini si arricchisce, trasformandoli in agenti attivi del cambiamento e della crescita della città stessa [CHI12].

Lo strumento partecipativo ha una duplice funzione. La prima, quella più immediata, è la capacità di raccogliere informazioni sul contesto locale, verificando l’esito delle politiche attuate e permettendo eventualmente di correggerle. Si tratta quindi di un’azione a posteriori e può essere utilizzata quindi per legittimare una strategia. L’altra funzione invece, che meglio incarna gli ideali di Smart City, prevede di coinvolgere la comunità locale con un ruolo attivo e costruttivo nel processo di sperimentazione e costruzione delle politiche della città, secondo una pratica di co-design partecipato. Si tratta di un percorso che parte dal presupposto dell’open-data e, facendo affidamento sulla capacità e sulla creatività degli individui, cerca di catturare intelligenza collettiva e conoscenza, intuizione e innovazione presenti all’interno della città.

Per promuovere la partecipazione dei cittadini, e renderli protagonisti del processo di sviluppo urbano, le infrastrutture ICT costituiscono un potente strumento tramite cui costruire un dialogo diretto con gli individui, con un’interazione multicanale e multi contenuto. Soprattutto i dispositivi mobili di ultima generazione, quali sono gli smartphone e i tablet, permettono agli utenti la fruizione pervasiva della


17

città intelligente, e la classificazione di contenuti e informazioni in base alla loro posizione, costruendo così una mappa aggregata del territorio urbano. In questo modo i processi partecipativi generano una grande quantità di dati, che deve essere elaborata e interpretata in modo intelligente, e combinata con quelli prodotti dalla città stessa tramite le proprie infrastrutture ICT, quali ad esempio le reti di sensori disseminate sul territorio.

I processi partecipativi che hanno luogo tramite le infrastrutture ICT rientrano all’interno dello scenario dell’e-government (dall’acronimo inglese “e” iniziale di electronic e government, letteralmente governo elettronico) cioè dell’insieme di soluzioni tecnologiche pensate per la pubblica amministrazione, siano esse destinate al miglioramento dei processi interni (back-office) o rivolte verso i cittadini (front-office). All’interno del contesto della Smart City il concetto di e-government, e in generale di government, è affiancato e ricontestualizzato in quello di governance, un concetto di respiro più ampio, fondamentale per caratterizzare la Smart City, che fa riferimento alla strategia a lungo termine perseguita dall’amministrazione in cui si inseriscono le singole azioni di government, e per la quale la partecipazione ed i cittadini giocano un ruolo di primo piano. Vedremo di seguito come nel corso del tempo l’e-Government si sia trasformato evolvendo verso gli scenari partecipativi.

1.4.1 Dall’e-government alla governance A partire dagli anni ’90 si è progressivamente assistito al miglioramento dei

rapporti tra le amministrazioni pubbliche e i cittadini. Da una pubblica amministrazione lontana e distaccata dai cittadini, si è passati inizialmente a un rapporto in cui i cittadini svolgono il ruolo di utenti delle pubbliche amministrazioni. Questo processo ha avuto luogo sia tramite la semplificazione amministrativa dei rapporti cittadini-pubblica amministrazione e sia tramite le ICT, offrendo la possibilità di operare online tramite servizi telematici piuttosto che recarsi presso gli uffici pubblici, e ha interessato sia strumenti direttamente visibili all’utente, come il portale del cittadino o la carta d’identità elettronica, e sia la riorganizzazione dei processi amministrativi interni con modalità telematiche.

Tuttavia, i processi dell’e-government non sono limitati solo all’informatizzazione dei servizi erogati e alla realizzazione di un’amministrazione digitale, finalizzata alla semplificazione e alla trasparenza, ma si estendono verso un nuovo modo di amministrare, orientato allo scambio dei flussi informativi, e trasformano i tradizionali apparati amministrativi e le istituzioni in reti di organizzazioni interconnesse tra loro, con i cittadini e con le imprese. Questo nuovo modello organizzativo abilita un’elevato livello di interazione tra gli attori, affiancando così al concetto di e-government quello di e-governance, con il quale si fa riferimento all’applicazione degli strumenti ICT ai modelli dell’azione pubblica in un contesto di trasparenza e partecipazione alle decisioni del management pubblico [NOT05].

Il termine governance risale intorno agli anni ‘80, contestualmente alla crisi della tradizionale amministrazione locale, con le sue regole e procedure stabilite e la sua forma gerarchica per livelli. Con il termine si vuole intendere un nuovo modo di agire delle amministrazioni pubbliche in quanto capaci di assumere un orizzonte


18

strategico a lungo termine, con una accezione particolare ai processi decisionali cui sono coinvolti una molteplicità di soggetti pubblici e privati [PRO05]. Nel contesto odierno il termine fa riferimento ai processi di risoluzione dei problemi che coinvolgono collettivamente la comunità, in cui le azioni del governo rispondono alle necessità dei cittadini e li sostengono. Una buona governance è quindi basata sulla centralità e sulla responsabilizzazione dei cittadini, ed è capace di creare una visione condivisa sulle strategie di sviluppo applicando lo strumento della partecipazione piuttosto che della gerarchia. L’organizzazione pubblica non è più concepita come una struttura piramidale che pone gli organi di governo al vertice, ma piuttosto secondo un’organizzazione orizzontale che vede coinvolti una molteplicità di attori quali i cittadini, le imprese e le pubbliche amministrazioni [ACE].

Il processo di evoluzione di questo modello si riflette direttamente sulle modalità con cui le amministrazioni si interfacciano nello scenario digitale. Uno studio condotto dal progetto di ricerca European Smart City [SMA09], promosso dall’Unione Europea, ha tracciato l’evoluzione dei portali di e-government forniti dalle amministrazioni cittadini nel corso del tempo, individuando principalmente quattro fasi. La prima fase, risalente agli anni ’90 e alla fase pionieristica delle implementazioni pilota, in cui sono semplicemente fornite informazioni riguardanti i servizi, disponibili esclusivamente offline. Nella seconda fase emerge una prima forma di interazione: i portali permettono agli utenti di entrare in contatto con il materiale ospitato dal sito e interagire con esso. La terza fase è invece caratterizzata dal supporto alla transazione. I portali offrono servizi web-based, che permettono di portare a termine le procedure amministrative, e incrementano i parametri di personalizzazione per soddisfare le necessità dell’utente. La fase finale rappresenta quella della partecipazione, in cui i portali permettono ai cittadini di contribuire alle decisioni riguardo lo sviluppo futuro dei servizi online. Il passaggio attraverso queste diverse fasi vede quindi il ruolo del cittadino cambiare da utente passivo a partecipativo. Il grafico in Figura 2 rappresenta la trasformazione della semplice presenza online (le prime due fasi) prima in e-government (terza fase) e poi in e-governance (quarta fase) tramite due curve di apprendimento, dalla caratteristica forma a “S”, che rappresentano il grado di diffusione della tecnologia all’interno dell’amministrazione. Il diagramma mostra inoltre come i requisiti d’interoperabilità e di apertura precedano quelli di elaborazione dei dati e di gestione della conoscenza, ed evidenzia l’elevato grado di maturità necessario ai servizi di e-government per essere classificati come “smart”.


19

Figura 2 - Evoluzione dei portali di e-government.

Tramite la forte spinta partecipativa la governance della Smart City si impegna quindi a interpretare le necessità dei cittadini, coinvolgendoli direttamente nel processo decisionale, per mettere in atto strategie di sviluppo all’insegna dei principi dell’innovazione e della sostenibilità capaci di generare competitività. L’infrastruttura ICT garantisce inoltre gli strumenti per raggiungere in modo capillare i cittadini e permette un’interazione bidirezionale in cui gli utenti contribuiscono con i propri contenuti all’arricchimento della piattaforma cittadina e ne traggono beneficio sia direttamente, usufruendo dei servizi innovativi messi a disposizione dalla Smart City, e sia indirettamente, tramite il miglioramento della qualità della vita che lo sviluppo della città comporta. Si tratta di un processo che, basandosi sull’intelligenza collettiva della comunità e sulle interconnessioni sociali tra i cittadini, richiama la filosofia del Web 2.0 e il fenomeno del social networking, e che prende il nome di Open Government.

1.4.2 Open government Tim O’Reilly, fondatore della nota casa editrice O’Reilly Media, conia nel 2005

il termine “Web 2.0” [ORE05] per indicare la profonda trasformazione che stava attraversando, e attraversa tuttora, la piattaforma web in quegli anni, e per sottolineare la sostanziale differenza che lo contraddistingue dal web classico, il cosiddetto “Web 1.0”. Se nella concezione tradizionale del web l’utente è fruitore passivo, che può esclusivamente visionare contenuti statici, nel “Web 2.0” questa prospettiva è ribaltata, in quanto si trasforma nel costruttore attivo e nel generatore dei contenuti che costituiscono il web stesso. Il nuovo web è caratterizzato dalla condivisione interattiva delle informazioni, dall’interoperabilità, dalle interfacce user-friendly per facilitare l’interazione dell’utente col sistema, e infine dalla collaborazione, tra i sistemi


20

software e tra gli utenti, per la costruzione del web stesso. Altro concetto essenziale alla base del Web 2.0 è l’intelligenza collettiva, il cosidetto “crowdsourcing”, cioè la capacità di risoluzione dei problemi e di generazione di conoscenza a partire dall’interazione di individui appartenenti ad una “folla” (dall’inglese “crowd”). In questo senso gli utenti generano contenuti sul web che sono a loro volta integrati da altri utenti, secondo un processo di miglioramento continuo basato appunto sulla “saggezza della folla”. Ancora una volta, è l’utente a fornire il valore aggiunto, e all’aumentare del numero di utenti coinvolti aumenta il valore dei servizi. Infine, elemento fondamentale del web 2.0 è rappresentato dalla socialità. Servizi quali i social network (Facebook), Blog e Microblog (Twitter è un esempio di microblog) costituiscono enormi piattaforme di interazione, all’interno delle quali i legami tra gli utenti contribuiscono alla disseminazione e alla veicolazione delle informazioni e dei contenuti.

Nello scenario dell’e-government inoltre si aggiunge un altro elemento fondamentale: l’Open Data, cioè la disponibilità dei dati pubblici in formati accessibili e interoperabili, predisposti alla fruizione e all’elaborazione, liberamente accessibili a tutti sul web. L’Open Data promuove quindi il principio di trasparenza della PA, rendendo l’amministrazione più aperta e affidabile. Tutti questi elementi sono determinanti e indispensabili per la nuova concezione di e-government, orientato alla partecipazione, che promuove lo sviluppo di una città costruita dai cittadini stessi sfruttando l’intelligenza collettiva, e che agisce da piattaforma di scambio di contenuti in continua evoluzione.

Michele Vianello, attivo sostenitore dello scenario Smart City e direttore generale del Vega Parco Scientifico e Tecnologico di Venezia, dove lavora a diversi progetti di ricerca e sviluppo ICT, definisce la città intelligente “un luogo dove le persone hanno a disposizione in modo diffuso, condividendola e implementandola, la conoscenza” [VIA12]. E afferma che la conoscenza è il prodotto delle attività degli individui in rete: quando utilizzano Twitter o Facebook per parlare della loro città, o caricano un video su Youtube, o contribuiscono alla stesura di una voce su Wikipedia, generano conoscenza. Così la città intelligente diventa il luogo dove i cittadini usano consapevolmente le infrastrutture ICT per attingere e generare conoscenza condivisa. Vianello parla inoltre della città intelligente come un “social cloud”, una piattaforma di crowdsourcing che mette in relazione dati provenienti da fonti diverse per creare valore aggiunto, dove ad esempio i dati sensoriali rilevati tramite smartphone sono mescolati ai dati cartografici, per poi essere ulteriormente arricchiti con i commenti provenienti dai social network.

Il nuovo contesto partecipativo rappresenta per la pubblica amministrazione una sfida impegnativa, che necessita un cambiamento radicale verso una visione trasparente e collaborativa. È necessario inoltre creare una comunità online pervasiva, secondo la visione sociale tipica dei social network e dei social media in cui tutto viene scritto, filmato, registrato e poi condiviso, che stimoli la collaborazione e la cooperazione dei singoli soggetti coinvolti nella creazione di un valore condiviso. Naturalmente un approccio di questo tipo richiede che i cittadini della Smart City siano in grado confrontarsi con i nuovi canali messi a disposizione dall’amministrazione, sia in termini di abilità nel relazionarsi con le tecnologie


21

d’informazione e comunicazione, sia in termini di mentalità responsabilizzata e partecipativa. Sono necessari quelli che potremmo in breve definire dei “Cittadini 2.0”, o anche degli “Smart Citizen”.

Ricapitolando, possiamo caratterizzare il nuovo modello di e-government proposto dalla Smart City, rinominato da alcuni open government facendo riferimento al principio di Open Data, secondo le seguenti caratteristiche:

1. Trasparenza: la trasparenza favorisce la responsabilizzazione del cittadino, poiché gli fornisce le informazioni sull’attività dell’amministrazione, rendendola più controllata, aperta e affidabile;

2. Partecipazione: i cittadini devono essere partecipi delle scelte decisionali dell’azione amministrativa al fine di migliorare le qualità delle decisioni dell’amministrazione, anche grazie al ricorso delle ICT.

3. Collaborazione: è necessario ripensare i modelli organizzativi al fine di garantire la costante collaborazione dei cittadini nelle attività della pubblica amministrazione, attraverso il supporto degli strumenti offerti dal Web 2.0.

Riteniamo inoltre che, nella visione proposta di comunità pervasiva connessa e partecipata, i dispositivi mobili quali smartphone e tablet presentino un potenziale molto elevato, in quanto permettono agli utenti di interagire con la piattaforma Smart City continuamente ed in qualunque punto si trovino, e procederemo quindi con l’analisi degli scenari concernenti l’utilizzo di questa tecnologia nel campo dell’e-government.

1.4.3 Il ruolo dei dispositivi mobili Nello scenario dei servizi partecipativi i dispositivi mobili giocano un ruolo

fondamentale come tecnologia abilitante. Tramite i dispositivi mobili, non solo è possibile l’accesso ubiquo degli utenti ai servizi offerti dalla città intelligente, ma i cittadini si trasformano in generatori di contenuti dislocati all’interno del territorio urbano, a formare una rete sociale pervasiva e abilitando così forme di partecipazione innovative.

I dispositivi mobili non sono nuovi nello scenario dell’e-government. Il termine “mobile-government”, abbreviato “m-government”, risale al lontano 2003 e sta a indicare l’estensione dell’e-government ai dispositivi mobili, e cioè l’insieme di servizi amministrativi resi possibili solo tramite questa tecnologia. Tuttavia, fino alla recente diffusione di smartphone e tablet, l’ambito del m-government era limitato a pochi casi applicativi, principalmente basati sull’invio di SMS. Naturalmente lo sviluppo dei dispositivi mobili moderni quali smartphone e tablet ha sconvolto questo scenario, date le grandissime potenzialità e la miriade di possibilità offerte da queste piattaforme computazionali.

La strategia generale delle pubbliche amministrazioni di fronte a questo fenomeno è stata improntata ai principi di Open Data, intelligenza collettiva e partecipazione: prima di tutto l’impegno alla produzione e alla condivisione in modo interoperabile e aperto delle informazioni a disposizione dell’infrastruttura della Smart City, dall’altra l’istituzione di grandi contest per la realizzazione di applicazioni per


22

dispositivi mobili, delle sessioni di brainstorming collettive aperte a tutti. Si tratta delle cosiddette civic hackathons, dove la parola “hackathon”, a volte sostituita dai sinonimi “hack day” o “hack fest” sta a indicare un evento in cui individui con competenze nell’ambito dello sviluppo di software collaborano intensivamente a un progetto incentrato su uno specifico focus. Ne sono un esempio il BigApps di New York, sicuramente uno dei più rilevanti e, in territorio italiano “Apps For Italy 2012” a livello nazionale, il progetto “TAPPER – Top Apps per l’Emilia-Romagna” a Bologna, e “Let Your App Be” a Roma. Altra iniziativa degna di nota è quella del governo federale statunitense, che già nel 2009 aveva creato un market-place governativo per le applicazioni in ambito PA, il sito “apps.gov”. Nel dicembre 2012, però, il sito è stato notevolmente ridimensionato anche a causa di problemi di gestibilità e fruibilità, dato l’elevato numero e l’eterogeneità delle applicazioni presenti [WIL12].

Nonostante ciò, una ricerca dell’IDC Government Insights, società specializzata in ricerche di mercato proprio per il settore pubblico, prevede per il 2013 il vero boom delle applicazioni mobili in ambito PA [SLA12]. Il potenziale della tecnologia mobile nel settore dell’e-government è rilevato anche dalla ricerca di mercato “m-Government in Europe: Services for Citizens and Opportunities for the Mobile Industry” condotta da Frost & Sillivan, secondo cui l’ambito applicativo del m-government si rivelerà trainante per il settore mobile. L’analisi prende in considerazione per l’appunto lo spostamento verso un modello partecipativo di amministrazione pubblica, e fa in particolare riferimento al contesto europeo dove la penetrazione della tecnologia mobile raggiunge in alcuni paesi, come l’Italia, il 100% [CAR11].

La tecnologia mobile presenta evidenti vantaggi, poiché consente di creare un canale di comunicazione diretto con il singolo individuo, coinvolgendolo attivamente, e permette forme di fruizione di servizi e di creazione di contenuti innovative, a maggior ragione in un paese come l’Italia, che si pone tra i primi al mondo per diffusione dei dispositivi mobili, con circa 32 milioni di smartphone nel 2012 e la previsione di crescita a 50 milioni nel 2015 [ANS12]. Permettendo l’accesso ubiquo alla rete, il fenomeno dei dispositivi mobili ha dato vita a nuove pratiche e nuovi usi sociali che devono essere opportunamente valorizzate e sfruttate dalle pubbliche amministrazioni come mezzo per l’erogazione di servizi multicanale e orientati al cittadino.

Alla luce delle potenzialità evidenziate da questa tecnologia, e considerando che gli aspetti tecnologici relativi allo scenario mobile saranno trattati nel Capitolo 2, vogliamo ora presentare alcuni casi concreti di soluzioni, afferenti all’ambito del m-government e orientate a scenari di tipo partecipativo e collaborativo, che sono state dispiegate in diverse città di tutto il globo.

1.4.4 Esempi di servizi partecipativi Dopo aver enunciato i principi e le potenzialità che contraddistinguono il

contesto dell’e-government orientato alla partecipazione del cittadino, vogliamo ora presentare una serie di casi reali ritenuti particolarmente significativi e caratterizzanti. Abbiamo quindi effettuato un’analisi dello scenario delle applicazioni partecipative, prendendo in considerazione città considerate “intelligenti” appartenenti sia al contesto


23

europeo che statunitense. L’estrema varietà di soluzioni presenti rende tuttavia difficile creare una categorizzazione esaustiva delle tipologie di servizio esistenti, anche perché s’incorrerebbe nell’errore di creare un rigido incasellamento in uno scenario ancora in fase di evoluzione e pertanto molto mutevole. Preferiamo pertanto presentare alcuni esempi ritenuti significativi, ognuno dei quali si differenzia per particolari caratteristiche in merito alla modalità di coinvolgimento del cittadino e alla finalità del processo partecipativo.

È bene precisare inoltre che molte di queste soluzioni rientrano nell’ambito dell’area di ricerca del cosiddetto sensing partecipativo, che consiste cioè nell’utilizzo di sensori quali microfono, fotocamera, GPS, e accelerometro, presenti su dispositivi mobili che possono essere sia gli smartphone dei cittadini sia dispositivi hardware realizzati ad-hoc in dotazione agli utenti, per raccogliere rilevazioni sull’ambiente circostante l’utente, e aggregarle a livello di comunità per elaborare informazioni su larga scala. Tuttavia, nell’ambito di questa sezione ci limiteremo ad analizzare prettamente l’aspetto funzionale del sensing partecipativo, al fine di coglierne le potenzialità applicative all’interno scenario dell’e-government, rimandando al capitolo successivo l’analisi dettagliata degli aspetti tecnologici.

1.4.4.1 E-‐part Si tratta di una piattaforma web che permette la segnalazione di criticità come

ad esempio manto stradale dissestato, segnaletica mancante, rifiuti abbandonati o cassonetti pieni, e altri disservizi legati al territorio urbano. Permette di documentare le segnalazioni con immagini, oltre che con descrizioni testuali, e di associarle a una posizione geografica per far sì che sia possibile localizzare il punto esatto in cui è registrato il disservizio. Sono gestite diverse tipologie di segnalazione, ognuna delle quali fa riferimento a una particolare categoria di problematica (es. dissesto stradale, problemi idrici, barriere architettoniche etc.). Oltre ad essere accessibile via web, è fornita inoltre un’applicazione per dispositivi mobili, in cui l’immagine e la posizione che documentano la segnalazione sono catturate con i sensori del dispositivo, rispettivamente la fotocamera e il GPS.

È importante tenere in considerazione che il servizio è sviluppato, gestito, ed erogato da un’azienda privata, e che le amministrazioni accedono al servizio come entità assolutamente esterne (tant’è che devono registrarsi per usufruirne). È il gestore della piattaforma che s’impegna a ridirigere le segnalazioni verso le autorità competenti, cioè le amministrazioni. Il basso livello d’integrazione e di accoppiamento con le autorità si riflette nel fatto che non vi è nessuna garanzia sull’intervento delle autorità competenti in merito alle segnalazioni. Come altro esempio di servizio di questo genere segnaliamo l’applicazione Decoro Urbano.

1.4.4.2 Fix my street Si tratta di un servizio molto simile al caso precedente, giacché permette di

segnalare problematiche riguardanti il territorio urbano quali dissesti nel manto stradale, malfunzionamenti nel sistema d’illuminazione pubblico, graffiti, etc. Ciò che differenzia FixMyStreet dal caso precedente, rendendola degna di nota, sta nel fatto che è stata sviluppata contestualmente a un progetto della cittadina di Edimburgo, in


24

Inghilterra. Ne consegue una forte integrazione tra il servizio e l’amministrazione locale, e quindi un elevato impegno e una maggiore garanzia d’intervento da parte di quest’ultima. Infatti, gli utenti ricevono sempre almeno una risposta dall’amministrazione, e sono notificati non appena la criticità è risolta. Da contro, per FixMyStreet non è ancora stata sviluppata un’applicazione per dispositivi mobili.

Facendo riferimento al territorio italiano, il comune di Venezia ha sviluppato il servizio IRIS che, nonostante sia ancora in versione beta, vanta già più di diecimila segnalazioni risolte, a testimonianza del maggiore livello di coinvolgimento da parte dell’amministrazione che contraddistingue questa tipologia di applicazioni. Paradossalmente, anche per IRIS non è ancora disponibile un’applicazione per dispositivi mobili.

1.4.4.3 ImproveSF ImproveSF, la cui sigla sta per “Improve San Francisco”, letteralmente

“migliora San Francisco”, è una piattaforma online realizzata dalla famosa città americana con l’obiettivo di risolvere le sfide cittadine attraverso la capacità di problem-solving dell’intera comunità.

Il funzionamento della piattaforma è strutturato secondo una precisa sequenza di passi. Alla base vi è la creazione, da parte di un’organizzazione o di una comunità, di creare un progetto su una tematica riguardante l’area urbana, che può essere un risultato da raggiungere o un aspetto da migliorare. Rispetto ai casi precedenti si tratta quindi di argomenti di respiro più ampio, come ad esempio il miglioramento della sicurezza stradale. All’interno del progetto sono poi creati diversi topic a cui i singoli cittadini possono contribuire con le proprie idee, documentandole anche con foto. Il processo si conclude quando i “community leader”, cioè i responsabili del progetto, vagliano le idee presentate e la implementano. Si tratta quindi di un servizio di condivisione delle idee, una piattaforma di crowdsourcing partecipativa orientata alla risoluzione delle problematiche urbane che coinvolge i cittadini nei processi decisionali della città.

Un’altra iniziativa in questo senso è rappresentata da Participatory Chinatown, sviluppato all’interno di un progetto di pianificazione per il quartiere Chinatown di Boston. Si tratta sostanzialmente di una piattaforma di video-gaming online in tre dimensioni, che permette ai cittadini di impersonare il ruolo di uno dei 15 personaggi del gioco con l’obiettivo di completare un incarico assegnato, come trovare lavoro o un posto per socializzare. Attraverso l’esperienza di gioco l’utente può confrontarsi e sensibilizzarsi rispetto a una serie di problematiche che gli sono sottoposte, come ad esempio le differenze linguistiche, e che costituiscono l’argomento di sviluppo urbano su cui l’amministrazione intende ottenere il contributo dei cittadini. Ciò permette quindi la partecipazione dei cittadini alla discussione dei temi d’interesse in maniera più consapevole e responsabilizzata.

1.4.4.4 Smart Citizen “Smart Citizen”, progetto realizzato dal centro di ricerca Fab Lab Barcelona, e

attualmente in via di sperimentazione all’interno della città spagnola, rappresenta una


25

piattaforma su scala metropolitana per il sensing partecipativo. Tramite lo “Smart Citizen Kit”, una scheda elettronica basata sulla piattaforma hardware open-source Arduino ed equipaggiata con sensori per misurare qualità dell’aria, temperatura, suoni, umidità e luminosità, ogni cittadino può trasformarsi in un “sensore mobile” divenendo parte integrante di una rete disseminata in tutto il territorio urbano. I dati rilevati dai sensori, geolocalizzati, sono poi inviati via wireless alla piattaforma, dove sono elaborati per costruire indicatori ambientali che contribuiscono a guidare lo sviluppo cittadino.

Come nel caso di ImproveSF, il contributo degli utenti non è utilizzato per indirizzare un intervento a breve termine. Tuttavia, trattandosi di dati sensoriali, è possibile estrarre numerose informazioni aggregando i dati in chiave collaborativa e construendo quindi una mappa della conoscenza, sulla base della quale indirizzare i processi decisionali e gli sforzi di miglioramento della vivibilità urbana, quali ad esempio la creazione di aree verdi o lo smistamento del traffico.

1.4.4.5 WeGo Il progetto “WeGo” si sviluppa all’interno dell’iniziativa Amsterdam Smart

City, e fa in particolare riferimento al piano per la mobilità sostenibile della capitale olandese. WeGo è una piattaforma di car-sharing che permette ai chi non possiede un’auto di noleggiarla da un proprietario che si trova all’interno dello stesso quartiere, per un periodo limitato all’arco di una giornata. Sfrutta quindi la sovra-capacità del mercato privato delle automobili per fornire un mezzo di trasporto conveniente a chi non lo possiede e aiutare i proprietari di automobili a ridurre i costi di mantenimento dei veicoli stessi, il tutto in maniera comoda per gli utenti e sostenibile per l’ambiente in quanto le transazioni avvengono all’interno di una stessa località di residenza. La piattaforma si occupa di abilitare questo modello di condivisione e collaborazione fornendo la garanzia e la tecnologia per rendere le transazioni semplici, sicure, affidabili e convenienti.

Riteniamo questo caso particolarmente interessante poiché presenta, in aggiunta ai precedenti, l’elemento di collaborazione diretta tra i cittadini. In tutti i casi analizzati prima l’interazione dei cittadini, sia essa costituita dall’invio di una segnalazione, di dati sensoriali o di proposte di miglioramento, era diretta verso l’amministrazione, un’entità centrale che si occupava di gestire opportunamente il contributo del singolo individuo. Nel caso di WeGo, invece, questa entità centrale esiste solo in funzione di supporto e di garante delle interazioni, che s’instaurano invece direttamente tra gli utenti stessi. In questo modo i cittadini possono organizzarsi e collaborare mettendo in atto in prima persona comportamenti intelligenti, realizzando così nel modo più compiuto l’ideale del cittadino “intelligente” della Smart City.

1.5 - Conclusioni Abbiamo visto come la Smart City non consista solo nel dispiegamento di

soluzioni tecnologiche innovative, ma sia costituita in modo imprescindibile anche dal suo capitale sociale, una rete di conoscenza e d’interazione che promuove il flusso


26

d’idee tra gli individui e le istituzioni e l’innovazione continua. I cittadini stessi rappresentano quindi una risorsa fondamentale per la Smart City, che deve impegnarsi nel valorizzarli, coinvolgendoli all’interno dei processi decisionali che guidano lo sviluppo della città intelligente. In questo senso gli strumenti di e-government hanno seguito un processo evolutivo orientato alla partecipazione, ricalcando il percorso del Web 2.0 con i principi di socialità, intelligenza collettiva, e il ribaltamento del ruolo dell’utente da fruitore passivo a creatore attivo. Questo processo ha portato alla nascita dell’open government, un modello di e-government basato sui principi di trasparenza, collaborazione e partecipazione. All’interno di questo modello i dispositivi mobili giocano un ruolo fondamentale poiché abilitano un ampio spettro di servizi di stampo partecipativo, che stanno emergendo nelle città intelligenti di tutto il mondo. Si tratta di piattaforme altamente innovative che, elaborando il contributo dei cittadini e promuovendone la collaborazione, permettono la piena realizzazione del modello Smart Citizen.

2 - Sistemi mobili e mobile sensing

L’ambito applicativo del mobile computing risale originariamente alla nascita dei telefoni portatili, dispositivi per definizione non vincolati a una particolare posizione fisica, ma inizialmente caratterizzati da notevoli limitazioni in termini di potenza di elaborazione e capacità di comunicazione. È piuttosto con l’avvento dei palmari, e ancora di più con gli smartphone e i tablet, che il mobile computing rivela le sue reali potenzialità, permettendo una varietà infinita di servizi e applicazioni innovative che l’utente può fruire in qualunque momento, luogo, e perfino in movimento. Per questi motivi i dispositivi mobili hanno cambiato le abitudini e la vita delle persone, registrando un notevole successo e una grandissima diffusione. Basti pensare che se nel 1991 la penetrazione media a livello mondiale del settore mobile era pari allo 0.4%, nel 2010 questa arriva al 91% (dati Royal Pingdom) [RUS12]. Inoltre, nel corso del tempo si sono trasformati da dispositivi con funzionalità abbastanza limitate, come il poter effettuare telefonate e inviare brevi messaggi testuali, a vere e proprie piattaforme di elaborazione, con potenza di calcolo quasi equiparabile a quelle dei desktop computer, quali sono gli smartphone odierni. Proprio questi ultimi, gli smartphone, rappresentano un’innovazione radicale nell’ambito del mobile tanto che, secondo i dati dell’International Data Corporation, nel secondo trimestre 2011 i volumi di vendita in Europa hanno raggiunto i 21,8 milioni di unità, superando i cosiddetti “featured phone”, cioè i tradizionali telefoni cellulari [GIA11]. Non solo, Juniper Research prevede che nel 2015 i volumi di vendita degli smartphone di fascia bassa raggiungeranno a livello mondiale i 185 milioni di unità, con prezzi medi che scenderanno dagli attuali 150 a circa 80 dollari [COX11].

Il successo registrato da questo tipo di dispositivi è indubbiamente legato alle possibilità e funzionalità avanzate offerte da un dispositivo così piccolo e compatto da entrare in tasca ed essere comodamente trasportato ovunque. Tali funzionalità sono permesse dalla disponibilità di un hardware con performance sempre crescenti: processori più potenti, display con maggiore risoluzione, diversi sistemi di connettività


28

e per finire una vasta gamma di sensori integrati quali GPS, bussola, accelerometro, microfono e così via. Su una piattaforma di elaborazione di questo genere è possibile costruire un vasto spettro di applicazioni molto attrattive che vanno dalla navigazione Internet tramite browser, alla riproduzione di dati multimediali, alle applicazioni di realtà aumentata, al social networking, alle applicazioni geo-localizzate, e altre ancora.

Se da un lato questi dispositivi offrono notevoli potenzialità e vantaggi, dall’altro gli scenari che caratterizzano il mobile computing presentano alcune criticità che devono essere opportunamente affrontate e gestite per rendere la fruizione delle applicazioni soddisfacente. Consideriamo ad esempio le particolari forme d’interazione uomo-macchina (schermi ridotti, dispositivi di input lenti e/o imprecisi), la limitatezza di banda rispetto alle infrastrutture fisse e le possibili interferenze di trasmissione, i problemi di consumo e non meno importante la necessità di garantire adeguata sicurezza in ambienti pubblici e affollati. La stessa modalità di fruizione dei contenuti e delle applicazioni è radicalmente diversa. Il contesto di utilizzo dei dispositivi desktop vede l’utente accedere da una comoda postazione di lavoro e concentrarsi sulle attività da svolgere con l’obiettivo e la necessità di trarne il maggior contenuto informativo possibile. Un utente mobile invece molto probabilmente utilizza il dispositivo distrattamente, mentre si sta muovendo o svolgendo altre attività, in un ambiente affollato e dispersivo, con un’elevata probabilità di essere interrotto da una telefonata o da una mail, e preferisce di conseguenza ottenere informazioni puntuali e contestuali. Tutte queste criticità devono essere opportunamente affrontante per realizzare sistemi efficienti, funzionali e usabili.

Lo studio dei temi della mobilità e della connettività ubiqua precede l’avvento di tablet e smartphone, e ha portato all’esplorazione di scenari con caratteristiche molto simili a quelle del mobile computing e con diverse arre di sovrapposizione. In particolare, gli ambiti dell’ubiquitous computing e del pervasive computing fanno riferimento all’integrazione dei sistemi di elaborazione all’interno dell’ambiente fisico e degli oggetti di vita quotidiana. La necessità di integrare tra loro i diversi dispositivi e di adattare i contenuti ai diversi scenari di fruizione permettono di fronteggiare l’estrema eterogeneità che contraddistingue lo scenario dei dispositivi mobili. D’altra parte, il mobile computing affronta anche altre sfide legate principalmente alla mobilità come ad esempio la capacità di mantenere attive le sessioni in atto durante uno spostamento. Un modo per distinguere facilmente queste due aree è considerare che se l’obiettivo del mobile computing è offrire contenuti “in qualunque luogo e momento”, l’ubiquitous e il pervasive computing mirano ad assistere l’utente “sempre e dappertutto” [SAH03]. Un altro ambito ritenuto di notevole interesse è rappresentato dal mobile sensing. I dispositivi mobili sono infatti equipaggiati con un notevole numero di sensori che li rendono capaci di effettuare rilevazioni sull’utente e sull’ambiente che lo circonda, aprendo nuovi e interessanti scenari. Sfruttando le informazioni rilevate dai sensori e dalle altre informazioni che ne caratterizzano il contesto di esecuzione, è possibile inoltre progettare logiche che si adattano all’ambiente che caratterizza l’utente, secondo il paradigma della context-awareness.

Nel corso del capitolo procederemo inizialmente a delineare le caratteristiche generali che contraddistinguono lo scenario del mobile computing. In seguito presenteremo le tecnologie di connessione wireless usate in ambito mobile più diffuse


29

al giorno d’oggi. Vedremo poi come la mobilità introduca alcune problematiche rispetto alla comunicazione in rete tradizionale e analizzeremo alcune soluzioni che sono state adottate per risolverle. In merito alla comunicazione i dispositivi mobili richiedono particolari caratteristiche di disaccoppiamento per l’accesso alla rete e ai servizi Internet. I sistemi di messaging rappresentano una risposta a queste necessità, e analizzeremo quindi le caratteristiche di questi sistemi ed alcuni esempi ritenuti particolarmente interessanti. Per queste sezioni del capitolo si faccia riferimento alle fonti [TAR09] [GAR12] e [ZHE05]

Infine, procederemo ad esplorare lo scenario del mobile sensing, sia descrivendo i sensori hardware a disposizione sia effettuando uno studio dello stato dell’arte e delle soluzioni che sono state sviluppate nell’ambito della ricerca. Entreremo poi nel merito dei servizi location-based e dei sistemi e delle tecnologie di posizionamento disponibili.

2.1 - Generalità Il fenomeno Smart Phone, come discusso dagli autori di [ABO05], rappresenta

uno dei mezzi tramite il quale si è più concretizzato il paradigma dell’ubiquitous computing: costituiscono dei compagni quasi inseparabili di una significativa percentuale della popolazione mondiale, sempre accesi e sempre connessi. Per questi diposistivi, i miglioramenti tecnologici quali durata della batteria, copertura di rete, prestazioni del processore, e le sempre maggiori funzionalità della piattaforma nel suo complesso, forniscono nuove importanti opportunità per l’implementazione di servizi su questi dispositivi.

Tuttavia, se da una parte lo scenario dei dispositivi mobili offre un ampio spettro di possibilità, dall’altra è caratterizzato da alcune criticità che devono essere opportunamente considerate.

2.1.1 Servizi e applicazioni mobile È possibile caratterizzare le applicazioni e i servizi in ambito mobile

distinguendo quattro diverse generazioni. In questo modo sarà possibile analizzare l’evoluzione dello scenario delle applicazioni in ambito mobile e identificare i trend significativi.

La nascita dei dispositivi mobili risale agli anni ‘80 con i primi cellulari. Questi dispositivi non supportavano alcun tipo di applicazione, ma fornivano esclusivamente i servizi di conversazione vocale. La prima generazione di applicazioni e servizi mobili, introdotta intorno al 1991, era strettamente legata ad aspetti tecnologici: lo sviluppo della tecnologia Short Messages Service (SMS) e la possibilità quindi di scambio di dati fu un evento molto importante nel percorso verso i servizi mobili.

La seconda generazione di applicazioni mobili è rappresentata dai browser built-in, basati principalmente sul protocollo Wireless Application Protocol (WAP). Questa seconda generazione è caratterizzata inoltre dall’introduzione, intorno al 2001, di un nuovo servizio di messaggistica che supportava messaggi con contenuto


30

multimediale, chiamato Multimedia Messaging Service (MMS). La tecnologia MMS permetteva agli utenti di comporre messaggi che includevano immagini, contenuti audio e video.

La terza generazione di applicazioni, di cui stiamo assistendo allo sviluppo, è supportata da un ambiente molto più sofisticato rispetto ai semplici servizi di messaggistica e browsing elementare che contraddistinguevano la generazione precedente. In questo caso, infatti, le applicazioni sono costruite sulla base di una piattaforma che offre molteplici servizi complessi quali supporto alla localizzazione, adattamento dei contenuti, archiviazione, caching, etc. Sono esempi di queste piattaforme J2ME, Android, iOS per iPhone, o Windows Mobile. I dispositivi che appartengono a questa categoria sono quindi detti smart phone in quanto capaci di supportare applicazioni e servizi più complessi.

Secondo alcuni, gli smartphone possono essere considerati il risultato della congiunzione della sfera dei telefoni cellulari con quella dei PDA (Personal Digital Assistance). Mentre la caratteristica peculiare dei primi è la capacità di connettività, i secondi possono essere considerati dei calcolatori di dimensioni e capacità computazionali ridotte che integrano funzionalità di gestione delle informazioni personali (calendario, agenda, fogli di lavoro etc.). Lo sviluppo di funzionalità sempre più avanzate da parte dei PDA, e l’integrazione delle capacità di connettività mutuate dalla sfera della telefonia mobile, hanno dato origine alla classe di dispositivi oggi denominati smart phone.

Un browser web che è stato adattato o creato per dispositivi mobili è tipicamente chiamato un micro-browser nel caso in cui l’insieme di funzionalità offerte è considerevolmente ristretto, a causa delle limitazioni imposte dal dispositivo in merito alla potenza di elaborazione e alle capacitò di visualizzazione. Oggigiorno un elevato numero di dispositivi mobili presenti sul mercato supportano web browser con funzionalità avanzate quali CSS 2.1, JavaScript e Asynchronous Javascript (AJAX). Si assiste quindi ad una convergenza di due scenari prima separati: quello delle telecomunicazioni wireless e quello della rete Internet.

La quarta generazione di applicazioni non è ancora nata, ma sulla base dei recenti progetti delle comunità di ricerca e di standardizzazione è possibile ipotizzare approssimativamente le caratteristiche attese: connettività continua, comunicazione multi-modale, reti cooperative, e uso adattativo delle interfacce di rete e dei mezzi fisici di comunicazione possono essere importanti proprietà dei futuri sistemi mobili.

2.1.2 L’ambiente mobile L’ambiente dei dispositivi mobili è caratterizzato da notevoli differenze rispetto

a quello delle reti fisse, che generalmente si contraddistingue per una bassa latenza, maggiore larghezza di banda, e in generale maggiore affidabilità nella comunicazione. L’ambiente mobile è invece soggetto a frequenti disconnessioni e problemi di raggiungibilità di rete che è necessario tenere in considerazione. In aggiunta, i dispositivi mobili hanno tipicamente una batteria limitata, capacità di elaborazione e memoria inferiori, e molteplici interfacce di comunicazione che devono essere opportunamente utilizzate.


31

Le capacità e le limitazioni del dispositivo dettano i vincoli su come e quali servizi l’utente è in grado di accedere, e quali tipologie di contenuti gli sono fornite. Sostanzialmente è possibile dividere le capacità di un dispositivo in tre gruppi: capacità di elaborazione, di visualizzazione, e di comunicazione. Le caratteristiche di elaborazione definiscono la tipologia di risorse che il dispositivo mette a disposizione per fornire servizi. Alcuni dispositivi sono in grado di agire solo come interfacce verso l’utente di servizi che sono ospitati all’interno della rete, come nel caso dei web browser, mentre altri dispositivi più potenti potrebbero eseguire loro stessi i servizi o parte di essi. La capacità di visualizzazione determina il modo in cui il servizio è mostrato all’utente finale. Ad esempio, uno smartphone ha capacità inferiori di visualizzare immagini e video rispetto a un tablet. Con capacità di comunicazione indichiamo invece l’insieme di interfacce di rete e di standard supportati dal dispositivo. Sul mercato esistono infatti numerosi standard, da quelli della famiglia IEEE 802 come il Wi-Fi a quelli tipici della telefonia mobile come l’UMTS, passando gli standard di comunicazione a corto raggio quali Bluetooth o ZigBee. Ognuno di questi standard offre una banda di ampiezza diversa, e da questa dipende fortemente la natura dei servizi e dei contenuti di cui l’utente può fruire agevolmente.

2.1.3 Mobilità L’elemento più caratterizzante del mobile computing è, per definizione, la

mobilità. I dispositivi connessi tramite una rete wireless non sono stazionari e possono muoversi da una rete a un’altra. Ciò può costituire un problema nel caso in cui l’utente stia svolgendo delle operazioni cui è associata una sessione, come ad esempio una telefonata, poiché le operazioni di disconnessione da una rete e la riconnessione all’altra potrebbero compromettere il normale svolgimento delle operazioni e provocare la perdita delle informazioni di sessione. Per ovviare a questo tipo di situazioni è necessario ricorrere a particolari protocolli che offrano il supporto necessario sia sul dispositivo sia nell’infrastruttura di rete. In generale, è detta terminal mobility la capacità di mantenere attiva una sessione mentre il dispositivo si sposta da una rete all’altra. La terminal mobility non è l’unico tipo di mobilità. Secondo la user mobility, ad esempio, l’utente deve poter fruire degli stessi servizi indipendentemente dal luogo, dal tempo e dal dispositivo che sta utilizzando, mentre la logical mobility fa riferimento a cambiamenti riguardanti attributi dell’utente quali il contesto o le sue preferenze.

La terminal mobility è resa possibile fondamentalmente dalla disponibilità di tecnologie di connettività wireless. Procederemo quindi di seguito a presentare diverse tecnologie molto diffuse nell’ambito dei dispositivi mobili.

2.2 - Comunicazione wireless Il termine wireless fa riferimento alla comunicazione tra dispositivi elettronici

che non fa uso di cavi, generalmente basata su onde radio e in rari casi su infrarossi. Alla base di tutte le comunicazioni wireless c’è lo spettro elettromagnetico, che comprende le diverse bande frequenziali usate per la comunicazione wireless. Le onde


32

radio appartengono a una porzione relativamente bassa dello spettro elettromagnetico, e sono largamente usate per la comunicazione in ambienti interni ed esterni. Hanno il vantaggio di essere omnidirezionali e di poter viaggiare per lunghe distanze, ma soffrono sono soggette a interferenze da altri dispositivi elettrici.

Possiamo distinguere sostanzialmente due diverse forme di comunicazione wireless, quelle storicamente legate alla telefonia mobile, che sono basate su tecnologie a lungo raggio e permettono elevati livelli di mobilità, e quelle mutuate dal mondo delle reti in ambito personal computer, quali LAN, MAN e PAN, che utilizzano tecnologie di raggio più corto. Le Personal Area Network (PAN) forniscono la connettività tra un gruppo di dispositivi molto vicini tra loro, ad esempio nel caso in cui l’utente desideri collegare tra di loro una serie di dispositivi a lui vicini. Le Wireless Local Area Network (o Wi-Fi) forniscono invece connettività di rete all’interno di un’area più grande ma comunque circoscritta quale può essere un edificio, aggiungendo quindi una qualche forma di supporto alla terminal mobility. Infine, le Wireless Metropolitan Area Network (MAN) sono una tipologia di rete che si estende sull’intero territorio metropolitano.

2.2.1 Reti cellulari Le reti cellulari rappresentano l’insieme di standard e tecnologie sviluppate

storicamente nell’ambito della telefonia mobile. Il termine cellulare fa riferimento al fatto che, non essendo tecnicamente possibile coprire un intero territorio con vasto bacino di utenza con una singola stazione radio, si ricorre al frazionamento del territorio da coprire in celle, o unità elementari di ricetrasmissione, con una propria stazione radio a potenza ridotta. Ogni cella utilizza un diverso insieme di frequenze, non usate dalle celle adiacenti. Questa organizzazione, schematizzata in Figura 3, permette il riuso delle frequenze in celle non adiacenti. All’interno di ogni cella troviamo una stazione di ricetrasmissione, detta Base Station (BS), che comunica direttamente con i dispositivi mobili. Ogni dispositivo mobile fa riferimento, in ogni momento, a un'unica stazione di trasmissione, in funzione della cella in cui si trova.

Figura 3 - Organizzazione a celle delle reti cellulari.

Nel momento in cui un dispositivo mobile esce fisicamente dalla cella in cui si trovava, la BS rileva l’attenuazione del segnale verso il dispositivo e innesca una procedura di ricerca tra le BS adiacenti di quella che sta ricevendo il segnale più potente dal dispositivo, a cui quest’ultimo andrà a collegarsi. Tale procedura di


33

passaggio da una BS ad un’altra è chiamata handoff o anche handover, e deve tenere conto di eventuali operazioni in corso sul dispositivo, come ad esempio una telefonata, che devono essere gestite opportunamente.

Le tecnologie di rete cellulare sono solitamente divise in generazioni. La prima generazione faceva riferimento a tecnologie analogiche ed è stata attualmente dismessa in molte aree del pianeta. La seconda generazione fu la prima tecnologia digitale e, come era accaduto per la prima tecnologia, differenti aree del globo adottarono tecnologie diverse. In Europa, dove la prima generazione era stata frammentata da un paese all’altro, la seconda generazione porto all’adozione di uno standard unico per tutto il continente, chiamato GSM. In modo duale, gli Stati Uniti adottarono una tecnologia digitale frammentata tra i diversi stati, mentre la tecnologia analogica di prima generazione era stata unificata.

Le reti cellulari di attuali appartengono alla terza generazione. A differenza della seconda generazione, che era a commutazione di circuito, le reti di terza generazione si sono spostate verso la commutazione di pacchetto, un approccio più scalabile usato tipicamente per il traffico di dati e tradizionalmente non per il traffico telefonico. Due differenti organi di standardizzazione, 3GPP e 3GPP2, proposero differenti standard tecnologici per questa terza generazione, rispettivamente UMTS (Universal Mobile Telecommunication System) e CDMA2000. La seconda generazione era basata, per quanto riguarda l’accesso al mezzo di comunicazione, principalmente su FDMA (Frequency Division Multiple Access) o TDMA (Time Division Multiple Access), che fanno riferimento rispettivamente alla trasmissione su una specifica frequenza o in uno specifico intervallo di tempo. La terza generazione invece utilizza per l’accesso al mezzo fisico la tecnica CDMA (Code Division Multiple Access), in cui ogni dispositivo trasmette il suo segnale usando una sua specifica codifica. In questo modo i dispositivi possono trasmettere sulla stessa frequenza e nello stesso intervallo di tempo senza causare conflitti, dando luogo ad un migliore utilizzo della banda disponibile.

Nonostante siano indicate come generazioni, le tecnologie utilizzate all’interno di ognuna delle generazioni non sono così statiche come la terminologia potrebbe far intendere. Già nella seconda generazione, caratterizzata dalla tecnologia GSM, ci sono state tecnologie chiamate generazioni 2.5 e 2.75, per indicare che le tecnologie utilizzate fornivano significativi miglioramenti in caratteristiche come larghezza di banda o latenza, pur mantenendo compatibilità con la tecnologia di riferimento.

La tecnologia di generazione 2.5 è chiamata General Packet Radio Service (GPRS), e aveva il vantaggio di permettere l’accesso alla rete Internet, che è a commutazione di pacchetto, nonostante la tecnologia GSM fosse completamente basata sulla commutazione di circuito. Un ulteriore sviluppo, chiamato Enhanced Data rates for GSM Evolution (EDGE), aumentava la velocità di trasferimento del GPRS ed è indicata come generazione 2.75 data la sua appartenenza alla famiglia GSM. In modo analogo, dalla tecnologia UMTS ha avuto origine una generazione 3.5, una tecnologia chiamata Hish Speed Packet Access (HSPA), che offre una velocità di trasferimento superiore.


34

La quarta generazione, ancora in fase di sviluppo, si muove nella direzione di una comunicazione basata su protocollo di rete IP. Nonostante la terza generazione supporti già la commutazione di pacchetto ed è compatibile con il protocollo IP, la quarta generazione presenterà una maggiore integrazione con il protocollo. Un esempio di tecnologia di quarta generazione è la Long Term Evolution (LTE), proposta da 3GPP. Nonostante si collochi formalmente ancora nel segmento Pre-4G, in quanto concepita come tecnologia di collegamento tra la terza e la quarta generazione, è stata presentata nel mercato come tecnologia 4G ed è attualmente in fase di diffusione in tutto il mondo come la più veloce tecnologia di rete cellulare disponibile.

2.2.2 Wireless LAN Una Local Area Network (LAN) è formata da un insieme di nodi che

condividono tutti la stessa rete fisica. Una LAN si trova tipicamente ai margini della rete Internet, con host connessi ad una LAN, ed in cui è presente un router a sua volta connesso con la rete Internet. In aggiunta ad una normale LAN, una Wireless LAN (WLAN) permette agli host di connettersi senza l’aiuto di fili, purché si trovino all’interno del raggio di copertura del segnale radio.

Dal punto di vista della standardizzazione, la maggior parte degli standard LAN appartiene alla famiglia IEEE 802, proposta dall’associazione Institute of Electrical and Electronics Engineers, di cui più famosi gruppi di standard sono l’802.3, per le reti LAN Ethernet, e l’802.11, per le Wireless LAN. Ai giorni d’oggi lo standard WLAN è tipicamente chiamato WiFi. Gli standard primari per il WiFi appartengono all’insieme 802.11, con le versioni a, b e g che permettono velocità di trasferimento dagli 11 Mbps ai 45 Mbps, e la versione n che vanta velocità fino ai 600 Mbps.

Per quanto riguarda l’accesso alla rete Internet, il WiFi non deve essere considerato in competizione con le reti cellulari, ma piuttosto una tecnologia complementare. Il raggio effettivo di copertura in condizioni di uso comune, infatti, è talmente ridotto da non permetterne un uso diffuso in condizioni di mobilità, specialmente se confrontate con le velocità di movimento supportate dalle reti cellulari. L’approccio più sensato e accettato, invece, prevede l’uso delle reti cellulari per la mobilità negli ambienti esterni, e il passaggio al WiFi quando, ad esempio entrando in un edificio, la mobilità è più limitata, al fine di beneficiare della maggiore velocità di trasferimento.

In aggiunta alla modalità “ad infrastruttura” tipicamente usata per l’accesso alla rete Internet, il WiFi supporta inoltre una modalità “ad-hoc” che, a differenza della precedente, non prevede una stazione centrale di configurazione e coordinamento. Una volta che tutti i dispositivi sono stati configurati per usare lo stesso canale WiFi e lo stesso prefisso di rete nei loro indirizzi, possono comunicare tra di loro senza intermediari. Una rete Questo tipo di interazione offre notevole potenziale all’interno delle applicazioni di stampo sociale, dato che permette ad esempio a due persone che si incontrano di collegarsi tra loro e condividere dati. Le due differenti modalità sono rappresentate in Figura 4.


35

Figura 4 - WLAN in modalità a) infrastruttura e b) ad hoc.

2.2.3 Wireless MAN In posizione intermedia tra la tecnologia WiFi e le reti cellulari troviamo la

tecnologia Wireless MAN, anche chiamata Worldwide Interoperability for Microwave Access (WiMAX). Fa riferimento allo standard IEEE 802.16. Nonostante le aspettative iniziali fossero decisamente promettenti (fino a 50 km di copertura), i test sperimentali hanno rivelato prestazioni decisamente inferiori, circa qualche chilometro, che si riducevano a poche centinaia di metri in assenza di visibilità ottica.

2.2.4 Personal Area Network Le Personal Area Network (PAN) sono concepite per connessioni a corto raggio

tra i dispositivi vicini a un singolo utente, non necessariamente di sua proprietà.

Il Bluetooth è una tecnologia per la comunicazione wireless basata su piconet: reti di piccole dimensioni, al massimo da otto nodi, costituite da un nodo master e diversi nodi subordinati. Si tratta di un’organizzazione che richiama l’obiettivo originario per cui questa tecnologia era stata progettata: collegare vari dispositivi periferici, gli slave, ad un computer, il master, senza il fastidio comportato dalla proliferazione di cavi. Tuttavia, essendo comunque una tecnologia di connessione general-purpose, il suo utilizzo non è limitato al caso del computer e delle sue periferiche, ed è ampiamente utilizzato per le comunicazioni a corto raggio tra dispositivi, anche grazie ai bassi consumi energetici e alla maggiore disponibilità rispetto al WiFi nei dispositivi di piccole dimensioni.

Interessante funzionalità del Bluetooth è il Service Discovery Protocol (SDP). Grazie a questo protocollo, un dispositivo non ha bisogno di conoscere a priori l’indirizzo del dispositivo con cui vuole comunicare, in quanto può effettuare una ricerca prima dei dispositivi presenti nell’area circostante, e poi dei servizi presenti su uno dei dispositivi trovati per individuare il servizio desiderato. Tale operazione di ricerca, sia del dispositivo che del servizio, viene appunto chiamata discovery. I servizi sono tipicamente di carattere generale, come ad esempio il trasferimento di file, ma è possibile usare servizi appositamente creati per denotare un’applicazione specifica, permettendo così a diverse istanze di un’unica applicazione residenti su dispositivi differenti di comunicare tra loro.


36

Altra tecnologia degna di nota in ambito di PAN è ZigBee, che sfrutta frequenze più basse rispetto al Bluetooth, normalmente assegnate per scopi industriali, scientifici e medici. Rispetto al Bluetooth ha il vantaggio di essere più semplice, economica e con un consumo energetico bassissimo, ma di contro ha una velocità di trasferimento più bassa, caratteristiche che la rendono più adatta a scenari embedded come applicazioni industriali, reti di sensori, domotica, etc.

Gli standard di riferimento per le tecnologie Bluetooth e ZigBee sono rispettivamente 802.15.1 e 802.15.4.

2.2.5 Confronto Le diverse tecnologie di comunicazione wireless non sono direttamente

comparabili tra loro essendo progettate per scenari differenti. Ad ogni modo, un confronto delle caratteristiche di ognuna di esse permette di mostrare il tipo di performance che un’applicazione può aspettarsi in ognuno degli scenari di riferimento.

La considerazione che le reti cellulari siano caratterizzate da maggiore lentezza e latenza è sempre meno corretta man mano che le tecnologie di terza e quarta generazione si diffondono. Tuttavia l’uso del WiFi quando disponibile è comunque la politica più corretta. Confrontare il Bluetooth con le altre tecnologie, a parte in WiFi in modalità ad-hoc e ZigBee, è poco sensato, non essendo concepito per l’accesso alla rete. Detto questo, la Figura 5 mette a confronto le diverse tecnologie in termini di raggio di copertura e velocità di trasferimento.

Figura 5 - Confrontro tra le diverse tecnologie di connettività wireless

Dal punto di vista energetico, le tecnologie UMTS e WiFi hanno approssimativamente lo stesso consumo, di circa 1 Watt, ma dato che il WiFi ha una la velocità di trasferimento maggiore, il trasferimento di una stessa quantità di dati richiederà minore energia. La tecnologia ZigBee invece è quella con consumo inferiore, pari circa 1 mW.


37

2.3 - Mobile messaging Come abbiamo detto più volte nel corso di questo capitolo, lo scenario dei

dispositivi mobili è caratterizzato da un’elevata dinamicità e instabilità, sia per quanto riguarda la posizione da cui gli utenti accedono alla rete, sia nella loro effettiva raggiungibilità. Sono, infatti, frequenti le disconnessioni dei nodi, a causa ad esempio di problemi di copertura di rete in un’area specifica, e la comunicazione wireless comporta spesso errori e problemi nella comunicazione.

In questo scenario è importante mantenere il massimo grado di disaccoppiamento nella comunicazione e nell’interazione tra componenti distribuiti che risiedono su nodi mobili. Per questo motivo è ampiamente riconosciuto il valore del paradigma a scambio di messaggi nello scenario dei dispositivi mobili, date le sue caratteristiche di flessibilità e asincronicità. In [TAR09], ad esempio, si parla addirittura di “comunicazione middleware mobile” facendo implicitamente riferimento al modello a scambio di messaggi.

In questo paragrafo illustreremo quindi il modello generale di comunicazione che caratterizza questo tipo di sistemi, che chiameremo anche sistemi di messaging, mostrando come si combina con i requisiti e le sfide presentate dalla mobilità. Esamineremo inoltre alcuni sistemi esistenti e diverse tecnologie emergenti ritenute particolarmente interessanti.

2.3.1 Concetti generali In questa trattazione parleremo di sistemi di mobile messaging facendo

riferimento a sistemi in cui il modello a scambio di messaggi è realizzato sopra il livello di trasporto. Lo scambio di messaggi rappresenta quindi una funzione di livello applicativo nel caso della suite di protocolli Internet, mentre nello stack OSI interessa allo stesso tempo i livelli di sessione, presentazione e applicativo.

Procediamo con la definizione delle componenti fondamentali che ogni sistema a scambio di messaggio deve definire.

2.3.1.1 Componenti fondamentali Un sistema a scambio di messaggi consiste di diversi elementi che combinati tra

loro determinano la struttura del sistema complessivo.

Primo elemento fondamentale è sicuramente l’architettura complessiva, che determina come è organizzato il sistema. In secondo luogo un sistema di messaging deve definire la sintassi dei messaggi, e le modalità con cui è codificato e decodificato per la trasmissione. Terzo, il protocollo applicativo utilizzato per scambiare i messaggi, che determina le modalità di interazione tra i partecipanti. Infine il locator, cioè l’indirizzo che identifica un partecipante e permette di inviargli messaggi.

Alcune volte sintassi e locator sono inglobati all’interno del concetto di protocollo tuttavia nel panorama odierno spesso è possibile individuare diverse


38

opzioni per ognuno dei tre elementi ed è possibile scegliergli singolarmente e combinarli nella definizione del sistema.

La mostra come i componenti descritti si combinano tra loro a formare il sistema di messaging completo. Il mittente interroga un componente detto resolver per ottenere una rappresentazione del locator utilizzabile per la trasmissione del messaggio. Il messaggio è costruito dal mittente e poi instradato usando il protocollo di messaging.

Figura 6 - Generica architettura di messaging.

2.3.1.1.1 - Architettura

L’architettura del sistema rappresenta l’elemento più determinante per il sistema stesso, e consiste di un insieme di componenti di sistema e delle interazioni tra essi. Uno dei principi più importanti per la progettazione dell’architettura è il concetto di loose coupling. Nei sistemi distribuiti ciò si traduce nella possibilità di sostituire individualmente i componenti senza la necessità di ridefinire l’intero sistema, ed è ottenuta facendo affidamento su protocolli e formati aperti e standardizzati, che permettono una maggiore libertà nella scelta dei componenti coinvolti garantendo comunque interoperabilità.

Un’importante caratteristica dell’architettura è se questa si limiti esclusivamente una comunicazione end-to-end o se preveda l’uso di mediatori di tipo applicativo. In generale consideriamo lo scambio di messaggi come una funzionalità di livello applicativo, la comunicazione tra due applicazioni che eseguono su host remoti. Nel primo schema però i due nodi mittente e ricevente sono gli unici a essere coinvolti a livello applicativo, mentre nei nodi intermedi i livelli sottostanti (in particolare quello di rete) si occupano del routing per la consegna dei messaggi al destinatario. In alcuni casi è auspicabile che i nodi intermedi agiscano attivamente come mediatori, con meccanismi che vanno oltre il normale routing di rete. Per questo è possibile necessario espandere lo schema della comunicazione end-to-end coinvolgendo funzionalità applicative anche nei nodi intermedi. In questo modo otteniamo un’architettura distribuita generale, che consiste di diversi componenti che comunicano tra loro con connessioni applicative, formando una rete di livello applicativo sovrapposta alla reale rete fisica, come mostrato in Figura 7.


39

Figura 7 - Architettura con mediatori.

In questo modo i nodi intermedi possono aggiungere funzionalità applicative che vanno oltre il semplice routing di rete, come ad esempio nel caso dei sistemi store-and-forward, in cui in nodi intermedi provvedono, nel caso in cui il prossimo nodo non sia al momento raggiungibile, a salvare in memoria persistente i dati per inviarli quando il nodo torna disponibile. Questi sistemi introducono un maggiore disaccoppiamento tra mittente e ricevente, che non devono essere contemporaneamente presenti, poiché il messaggio è memorizzato all’interno del sistema. Sono quindi particolarmente adatti nello scenario mobile, in quanto non richiedono ai nodi mobili di sincronizzare il loro accesso in rete.

2.3.1.1.2 - Sintassi dei messaggi

Il sistema deve gestire inoltre le operazioni di marshaling e unmarshaling dei messaggi. Con marshaling s’intende il processo di trasformazione della rappresentazione presente in memoria di un oggetto in un formato adatto all’archiviazione o alla trasmissione sulla rete, mentre con unmarshaling intendiamo l’operazione di trasformazione inversa.

Ci sono diversi metodi con cui questo può essere realizzato. Il metodo più semplice prevede che l’applicazione stessa fornisca le funzioni di marshaling e unmarshaling per ogni tipo di dato che deve essere usato nei messaggi. L’onere di gestire queste operazioni è quindi completamente a carico delle applicazioni. Un metodo più automatico è basato sull’uso di Interface Description Language (IDL), cioè linguaggi tramite cui definire la struttura dei dati che è possibile usare nei messaggi. A partire dall’IDL è poi possibile generare automaticamente il codice che esegue le operazioni di marshaling e unmarshaling. Infine nei linguaggi più dinamici, che permettono l’ispezione a tempo di esecuzione degli oggetti senza conoscerne la struttura, con le cosiddette tecniche di reflection o introspezione, è possibile realizzare meccanismi assolutamente automatici che però hanno un carico computazionale maggiore rispetto ai precedenti.

Esistono alcuni formati molto popolari per la rappresentazione di dati strutturati. Principalmente è possibile distinguere quelli che utilizzano un formato testuale da quelli che usano una rappresentazione binaria delle informazioni. Entrambi presentano vantaggi e svantaggi. Nel passato, quando banda della rete e potenza computazionale rappresentavano delle risorse molto limitate, erano prediletti i formati binari per la loro compattezza e per la migliore velocità di elaborazione che ne risultava. Al giorno d’oggi, data la grande capacità delle reti e l’elevata potenza dei calcolatori, sono preferiti i formati testuali che permettono una maggiore maneggevolezza in fase di sviluppo e sperimentazione, essendo più semplice la


40

creazione e la lettura delle strutture dati da parte dell’uomo. I formati binari possono inoltre presentare criticità relative ai formati interni di rappresentazione utilizzati dalle macchine che possono risultare incompatibili.

Nell’ambito dei formati testuali, negli anni passati si è assistito alla grande diffusione del formato eXtensible Markup Language (XML). Si tratta di un linguaggio di markup che permette di strutturare le informazioni tramite elementi detti tag, all’interno dei quali racchiudere i contenuti. È inoltre estensibile poiché permette all’utente la definizione di nuovi tag. Tuttavia si tratta di uno standard pensato originariamente per la rappresentazione di documenti, e presenta quindi il difetto di includere un ampio bagaglio di caratteristiche e funzionalità che risultano superflue nell’ambito della strutturazione dei messaggi. Per questo motivo si sta registrando un graduale passaggio ad un altro formato, il JavaScript Object Notation (JSON). È caratterizzato da una sintassi molto semplice, capace fondamentalmente di rappresentare solo pochi tipi di dati primitivi, e usa array e dizionari per rappresentare strutture più complesse, seguendo la sintassi con cui sono rappresentate nel linguaggio di programmazione JavaScript.

2.3.1.2 Protocolli In modo analogo a tutti i protocolli, ritroviamo il concetto di un messaggio che

contiene sia un insieme di metadati, gestiti dal protocollo, e un payload, che rappresenta il contenuto vero e proprio del messaggio, e che auspicabilmente è trattato in modo assolutamente opaco dal protocollo, cioè senza essere consapevole del suo contenuto.

Un pattern ricorrente nei protocolli la struttura di tipo header-body, in cui l’header che contiene i metadati consiste di un insieme di campi definiti come coppie chiave-valore. La specifica generale definisce precisamente la struttura e il confinamento di questi attributi, in modo da permettere l’estrazione delle informazioni anche ad applicazioni che non riconoscono tutti i campi. Fornisce quindi notevole estensibilità al protocollo, permettendo di implementare nuove caratteristiche conservando la compatibilità con le vecchie versioni.

In aggiunta ai metadati, i protocolli di messaging definiscono anche le tipologie di messaggi che possono essere inviate dai diversi partecipanti. In particolare, oltre ai messaggi con payload, principalmente utilizzati per veicolare dati, possiamo trovare diversi messaggi per la gestione delle connessioni. In alcuni protocolli di messaging questa è delegata direttamente al livello di trasporto: l’apertura di una connessione a livello di trasporto equivale anche all’apertura di una connessione a livello applicativo, e lo stesso vale per la chiusura della connessione. Tuttavia in nello scenario della mobilità la gestione della connessione necessita di un approccio diverso, poiché il livello di trasporto non offre le stesse garanzie del caso tradizionale. Ad esempio, il cambio di indirizzo IP causerà il malfunzionamento di tutte le connessioni TCP attive. Le connessioni a livello di trasporto devono essere quindi utilizzate solo quando è necessario inviare dati piuttosto che per mantenere l’identità di una sessione.

Un interessante approccio ai protocolli di messaging è rappresentato dal protocollo Multipurpose Internet Mail Extensions (MIME). Nasce come protocollo per


41

le email con messaggi formati da caratteri a 8-bit e allegati in forma binaria ed è poi esteso per essere più generale e completo. Prevede header che indicano il tipo di contenuto presente nel messaggio, incluso il tipo di codifica dei caratteri.

2.3.1.2.1 - Locator

Il locator ha lo scopo di identificare univocamente il destinatario di un messaggio. Mentre a livello di rete e di trasporto il locator è rappresentato dall’indirizzo di rete stesso, a cui si aggiunge la porta nel livello di trasporto, a livello applicativo è possibile utilizzare entità arbitrariamente complesse.

Nelle applicazioni Internet è comune utilizzare gli stessi nomi DNS come parte del locator, come avviene per gli indirizzi email o gli URL HTTP, che includono il nome dell’host. Si tratta di rappresentazioni strettamente legate all’indirizzo di rete, tant’è che molti sistemi supportano l’indicazione dello stesso indirizzo IP al posto del nome di dominio. Tuttavia questi locator aggiungono diverse informazioni aggiuntive rispetto al livello di trasporto, come ad esempio il percorso della risorsa nel caso di HTTP.

Alcuni sistemi utilizzano invece altre rappresentazioni, che permettono di ottenere una maggiore astrazione dalla tecnologia sottostante e una maggiore flessibilità, poiché consentono l’utilizzo di diversi protocolli di trasporto. Tuttavia la convergenza di tutte le reti verso il protocollo IP questa capacità tende a passare in secondo piano. Così come la sintassi dei messaggi si è spinta verso XML e JSON, il trend in ambito di locator è rappresentato dagli URI, spesso utilizzando schemi appositamente definiti. Si tratta di locator trasparenti, che hanno il vantaggio di poter essere facilmente gestiti dall’uomo. In contrapposizione ai locator trasparenti troviamo quelli opachi, come nel sistema CORBA. L’idea di base è che il locator non debba essere in alcun modo esaminato o manipolato esplicitamente dall’applicazione, e solo il sistema sottostante deve essere in grado di estrarne le informazioni. Da una parte questo permette maggiore estensibilità, aggiungendo nuove funzionalità in modo trasparente, dall’altra rende necessaria la presenza di un servizio di supporto per la gestione dei locator.

2.3.1.2.2 - Pattern di messaging

L’interazione tra i partecipanti di una comunicazione basata su scambio di messaggi può avvenire secondo diversi schemi, rappresentati in Figura 8. Sorvolando sulla comunicazione one-way, che è banale, possiamo distinguere tra 3 diversi pattern di base: request-response, subscribe-notify, e conversation. Il pattern request-response, più semplice, prevede l’invio di un messaggio di richiesta da parte di un partecipante mittente a un partecipante destinatario. Il destinatario invia poi con un messaggio di risposta. Nel subscribe-notify invece, il mittente invia un messaggio che ha lo scopo d comunicare l’interesse a essere notificato riguardo un particolare evento. L’altro partecipante quindi invierà in messaggio ogni volta che tale evento si verifica. Il terzo pattern invece prevede che i partecipanti comunicano alternandosi nell’invio dei messaggi, e si distingue da un request-response ripetuto in quanto c’è un collegamento tra tutti i messaggi consecutivi.


42

È importante fare una netta distinzione tra il pattern di comunicazione usato a livello di trasporto e quello usato dal sistema basato su messaggi. Il fatto che il livello di trasporto sia basato su connessione o meno, e che sia affidabile o meno, non preclude dalla realizzazione di garanzie di affidabilità o di pattern bidirezionali a livello applicativo. Nel caso di protocolli connessi è necessario fare una netta distinzione tra le entità applicative e i ruoli che queste entità assumono a livello di trasporto. A livello di trasporto le entità possono avere il ruolo di initiator, la parte attiva che inizia la connessione, o di listener, la parte passiva che attende per l’instaurarsi della connessione. Intenderemo invece client e server come entità applicative indipendenti dall’entità presente a livello di trasporto. Nel caso di publish-subscribe, ad esempio, il server è rappresentato dal partecipante in attesa delle registrazioni. Se ipotizziamo che le notifiche siano inviate, a livello di trasporto, su connessioni differenti da quelle della registrazione, sarà il server a giocare il ruolo di initiator e il client di listener.

Figura 8 – Pattern di messaging.

Un’importante distinzione nella modalità di comunicazione è se si tratti di comunicazione sincrona o asincrona. Nella comunicazione sincrona il mittente rimarrà bloccato in attesa di una risposta dall’altro partecipante, mentre nella comunicazione asincrona continuerà ad eseguire venendo notificato quando riceve la risposta. L’implementazione del pattern asincrono può avvenire tramite la tecnica del polling o del callback. Nel primo è il mittente a prendersi l’onere di verificare, tramite un oggetto detto promise, l’arrivo della risposta. Nel callback invece il mittente fornisce una funzione che implementa una determinata specifica e che viene invocata dal sistema di messaging quando viene ricevuta la risposta.

2.3.2 Java Message Service Java Message Service (JMS) è parte integrante della specifica Java Enterprise

Edition (JavaEE) e definisce un insieme di API generiche e standard per la realizzazione di sistemi a scambio di messaggi. Trattandosi solo di una specifica non fornisce alcuna implementazione concreta di sistema, lasciando spazio a molte possibilità di implementazione.

JMS propone sia un modello di comunicazione punto-punto, attraverso entità dette queue, che rappresentano le code di messaggi, sia un modello di tipo publish/subscribe, basate su entità dette topic su cui è possibile pubblicare messaggi


43

che verranno ricevuti da molteplici destinatari, come rappresentato in Figura 9. Il sistema gestisce diversi livelli di affidabilità, precisamente exactly-once, cioè ogni messaggio è consegnato esattamente un’unica volta, e only-once, cioè ogni messaggio p consegnato al massimo una volta.

La comunicazione punto-punto prevede la consegna del messaggio a un unico destinatario. Il messaggio è indirizzato a una specifica coda da cui il destinatario provvede a estrarlo. Ogni messaggio è consumato un'unica volta, e contestualmente a quest’operazione il sistema si occupa di inviare il messaggio conferma al componente che gestisce la coda. Grazie a questo modello non ci sono dipendenze temporali tra mittente e destinatario, l’unico requisito è l’esistenza della coda. Inoltre l’invio e la ricezione di un insieme di messaggi può essere raggruppato all’interno di transazioni. Se la transazione fallisce viene eseguito il rollback del sistema.

Nel modello publish/subscribe il produttore indirizza i messaggi verso uno specifico topic. Il messaggio è poi consegnato a tutti i consumatori che si sono registrati presso il topic. Il produttore e i consumatori sono assolutamente anonimi. Il modello inoltre introduce dipendenza temporale tra produttori e consumatori, poiché i consumatori devono essere attivi per poter ricevere i messaggi. In alternativa è possibile creare anche registrazioni persistenti, o durable subscription, che eliminano questa dipendenza tramite un meccanismo analogo a quello del modello point-to-point. Le durable subscription accettano messaggi inviati da un produttore che non è al momento attivo, ma possono avere solo un consumatore attivo per volta.

Figura 9 - Panoramica della comunicazione JMS basata su queue e topic.

Il sistema JMS permette la ricezione dei messaggi sia in modo sincrono che asincrono. I messaggi sincroni sono consegnati tramite il opportuno metodo di ricezione receive, bloccante finché non arriva un messaggio. Per poter ricevere messaggi asincroni invece il consumatore deve creare un opportuno oggetto, detto message listener, che incapsula la logica di gestione del messaggio, e che viene invocato dal sistema al momento della ricezione. I messaggi prevedono un header, costituito da un insieme di campi, alcuni dei quali opzionali e specifici per l’applicazione, e un corpo, che può essere di diversi tipi: Map, Object, Stream, Text e Bytes. Un messaggio Map contiene un insieme di coppie nome/valore, dove i nomi sono stringhe e i valori sono tipi primitivi Java. Un messaggio Object contiene un


44

oggetto Java serializzabile. Un messaggio di tipo Stream è una sequenza di tipi primitivi Java. Un messaggio di tipo Text è rappresentato da una stringa e può essere usato per inviare e ricevere messaggi in formato XML. Messaggi di tipo Byte sono sequenze di byte.

I messaggi inviati all’interno di una stessa sessione (individuata da un opportuno oggetto Session) godono della proprietà di in-order delivery. Gli acknowledgment sono generati automaticamente nella modalità basata su transazione. Se invece non è utilizzato il supporto transazionale ci sono tre possibili opzioni di acknowledgment: lazy, che tollera i messaggi duplicati, automatic, che prevede l’invio automatico non appena il messaggio è consumato, e client-side, che prevede l’invio esplicito da parte del consumatore.

Infine, il sistema non offre supporto il bilanciamento di carico, la tolleranza ai guasti, l’amministrazione e la sicurezza.

2.3.3 XMPP L’Extensible Messaging and Presence Protocol (XMPP), basato sul protocollo

Jabber, è pensato per i sistemi di messaggistica istantanea. Tramite un meccanismo estensibile, come dice il nome stesso, permette di supportare diversi schemi d’interazione basati su messaggi tra cui publish/subscribe, messaggi di presenza e aggiornamenti di stato, allarmi, negoziazione di parametri, discovery dei servizi. Gestisce una modalità di interazione di tipo sincrono, e sta diventando sempre più popolare all’interno di social network come Google, Twitter e Facebook.

Inoltre, può essere implementato sia seguendo un modello di interazione client-server che peer-to-peer. Nel caso base, un client si collega ad un server XMPP e apre una sessione di comunicazione con quest’ultimo. Dopo una fase iniziale di negoziazione dei parametri della connessione, il client e il server si scambiano dati in formato XML, detti stanza (dall’inglese “strofa”), sulla connessione. Se il client invia una stanza ad un’entità che non si trova nel suo stesso dominio, il server si occupa di negoziare la connessione con il server responsabile del dominio di interesse. Il messaggio è quindi inviato al server esterno per essere consegnato al destinatario. In Figura 10 è mostrata una panoramica del protocollo e dei modelli d’interazione.

Figura 10 - Panoramica del protocollo XMPP.

Il protocollo definisce tre formati di stanza, ognuno con una differente semantica: message, presence e Info/Query. Il primo rappresenta un messaggio


45

testuale unidirezionale inviato da un’entità ad un’altra. La presence stanza è la base per i meccanismi di broadcast o publish/subscrive. Molteplici utenti possono riceverli. Infine l’Info/Query stanza segue un meccanismo di tipo request/response.

Un server XMPP è responsabile della gestione dei flussi di dati trasmessi nel formato XML. Tipicamente questi flussi usano connessioni TCP di lunga durata, e le stanza costituiscono gli elementi radice del documento XML. Da questo punto di vista XMPP si basa sull’interpretazione incrementale del flusso di dati XML. Molti server di messaggistica istantanea basati su XMPP forniscono inoltre diversi servizi aggiuntivi come la gestione della sessione, il salvataggio persistente dei contatti e la gestione di liste nere di utenti.

XMPP rappresenta un interessante candidato per la comunicazione in ambito mobile data la sua popolarità. Tuttavia, XMPP non è stato progettato per le reti mobili e presenta alcune problematiche. Una delle maggiori limitazioni è legata all’uso di una connessione TCP che rimane aperta per tutta la durata di una sessione. Altra limitazione è rappresentata dal fatto che, dopo ogni disconnessione, è necessario ristabilire da capo una nuova sessione, effettuando nuovamente il processo di negoziazione e generando quindi un significativo overhead di comunicazione. Ciò è strettamente legato all’uso del formato XML, che introduce sia un overhead di elaborazione, legato all’interpretazione, sia di comunicazione. Per questo motivo sono state sviluppate alcune soluzioni, basate su sistema Android, che utilizzano formato binario anziché XML, ed eliminano la necessità di creare una nuova sessione ad ogni riconnessione.

2.3.4 Web Services In generale, i Web Service rappresentano sistemi software progettati per

garantire, tramite l’utilizzo di standard aperti, l’interoperabilità tra diversi elaboratori posti in rete, permettendo la fruizione reciproca dei servizi offerti. Data la loro profonda integrazione con la rete Web, procederemo con una breve introduzione a questo. Dopodiché ci concentreremo sul protocollo SOAP, al fine di analizzarne il modello basato sullo scambio di messaggi.

2.3.4.1 Introduzione al Web Con il termine World Wide Web (o abbreviato Web) si fa riferimento a una

grande piattaforma globale fatta di applicazioni, servizi, documenti e altre risorse, interconnesse tra loro e accessibili tramite Internet. I principi secondo cui si sviluppa sono quelli di semplicità, modularità, decentralizzazione e robustezza, e mira a supportare in modo flessibile la pubblicazione di risorse nella rete Internet e interconnetterle tra loro. È basato fondamentalmente su tre standard principali: il concetto di URL, il protocollo HTTP e l’HTML.

Gli Uniform Resource Locator (URL) sono utilizzati per riferire le risorse e sono classi particolari di URI. Un Uniform Resource Identifier (URI), è una stringa che identifica univocamente una risorsa generica all’interno del Web, e si classificano in URL, che oltre ad identificare la risorsa descrive i metodi di acceso ad essa, o un


46

URN (Uniform Resource Name) che identifica una risorsa mediante un nome in un particolare dominio.

L’Hyper Text Transfer Protocol (HTTP) è un protocollo request/response tra un’entità client ed un server. Il client crea una richiesta HTTP, tipicamente tramite un browser web, e la invia al server. Il server che gestisce le risorse alla ricezione della richiesta invia una risposta che può essere costituita dalla risorsa richiesta o da un messaggio di stato. Sono possibili diversi metodi di richiesta, tra cui i più importanti sono il metodo GET, che è usato per ottenere il contenuto della risorsa indicata come URI, e il metodo POST che è usato per inviarei informazioni al server. Il protocollo è di natura stateless, cioè non richiede agli host di mantenere informazioni di sessione tra una richiesta e l’altra. Tipicamente il protocollo HTTP è implementato sulla base del protocollo TCP.

Infine, l’Hyper Text Markup Language (HTML) è un linguaggio di markup basato su XML utilizzato per descrivere i documenti ipertestuali disponibili nel Web.

2.3.4.2 Principi SOA La Service Oriented Architecture (SOA) è un’architettura software dove ogni

funzionalità è strutturata attorno a processi di business e realizzata come servizio interoperabile. Obiettivi primari sono il disaccoppiamento tra i servizi e l’interoperabilità, astraendo dalle tecnologie di realizzazione dei servizi. Ogni funzione utilizzata dai processi di business è rappresentata da un servizio accessibile in rete. L’interoperabilità e il disaccoppiamento permettono la combinazione e il riuso dei servizi per la creazione di nuove applicazioni di business. Principi fondamentali dell’architettura SOA sono quindi il riuso, la modularità, la possibilità di comporre i servizi tra loro, l’interoperabilità tramite l’aderenza a standard aperti. Altro principio molto importante è la definizione di contratti che rappresentano un accordo sull’interfaccia dei servizi, e permettono di astrarre dalla specifica logica di realizzazione, ottenendo un maggiore disaccoppiamento. L’architettura SOA è inoltre pesantemente basata su un modello di comunicazione message-oriented, in quanto i servizi comunicano scambiandosi messaggi, e realizzano così complessi meccanismi di coordinamento.

I Web Service rappresentano uno dei modi di implementare l’architettura SOA, realizzando i blocchi funzionali che la contraddistinguono sulla base dei protocolli Internet, indipendenti dalle piattaforme e dai linguaggi di programmazione. Sono basati principalmente su 3 standard: Simple Object Access Protocol (SOAP) per lo scambio di messaggi, Web Services Descriprion Language (WSDL) per la descrizione delle interfaccie dei servizi, e infine Universal Description Discovery and Integration (UDDI) per la pubblicazione e la ricerca dei servizi. L’architettura Web Service è concepita come fusione di diversi modelli complementari, che rappresentano differenti prospettive di inquadrare lo stesso insieme di standard e tecnologie: message-oriented che focalizza sui messaggi scambiati e sulla loro struttura; service-oriented facendo riferimento ai servizi, a come sono descritti e chi li controlla; resource-oriented, con riferimento all’architettura stessa del Web. Di seguito faremo riferimento alla prospettiva message-oriented e quindi al protocollo SOAP.


47

2.3.4.3 Messaging Nel modello di messaging proposto dai Web Services e dal protocollo SOAP

possiamo distinguere innanzitutto alcune entità quali i sender, cioè i mittenti dei servizi, i receiver, cioè i riceventi (receiver), e gli intermediaries, gli intermediari che si interpongono tra i primi due. Lo schema di interazione è abbastanza semplice: prevede l’invio da parte del mittente di un messaggio, che viene trasportato, attraverso una sequenza di intermediari, fino al ricevitore, che si occupa di invocare il servizio richiesto. Il livello di trasporto sottostante è responsabile di veicolare i messaggi SOAP. Gli intermediari agiscono da router di livello applicativo (facendo riferimento al modello con intermediari descritto nella sezione Errore. L'origine riferimento non è stata trovata.), come rappresentato in Figura 11, in modo trasparente all’applicazione client, che è consapevole solo dell’invocazione del servizio ospitato sul nodo receiver.

Figura 11 - Percorso ed elaborazione dei messaggi SOAP.

I locator utilizzati all’interno dei Web Service e di SOAP sono strettamente legati alla semantica del Web. Formalmente sono utilizzati URI, ma molto spesso si ricorre a URI HTTP, permettendo in questo modo una maggiore conformità con il mondo Web, che si concretizza ad esempio nella possibilità di oltrepassare sistemi di filtraggio quali firewall, le cui regole di sicurezza prevedono tipicamente di scartare tutto ciò che non è traffico HTTP. In SOAP l’entità identificata dal locator è un servizio, che può compiere diverse operazioni su richiesta del cliente. I messaggi SOAP possono essere espressi tramite due stili: documentale o procedurale. Quello documentale, più usato al giorno d’oggi, prevede che il corpo del messaggio sia costituito da un documento XML arbitrario. Nello stile procedurale invece il corpo è sempre espresso tramite XML, ma deve seguire una struttura ben precisa che ricalca lo schema di interazione basato su invocazione di procedura, specificando una ben precisa funzione da eseguire e i suoi argomenti.

La sintassi dei messaggi è espressa, come abbiamo detto, tramite XML. Alcune parti della struttura dei messaggi sono predefinite ma la maggior parte sono lasciate all’applicazione. Il messaggio è rappresentato da un envelope, costituito da un header opzionale e un corpo obbligatorio, come mostrato in Figura 12. Gli elementi all’interno dell’header sono chiamati header block, e SOAP ne definisce alcuni attributi che possono essere usati per controllare l’elaborazione da parte degli intermediari. Ogni blocco inoltre è indirizzato a un preciso SOAP processor, che estrae i blocchi di sua competenza e li elabora, per poi inoltrare il messaggio in avanti.


48

Figura 12 - Struttura di un messaggio SOAP.

SOAP prevede inoltre un protocol binding framewirk, cioè un insieme di regole che definiscono le modalità con cui interfacciare SOAP con i protocolli sottostanti. In questo modo è in grado di appoggiarsi a una molteplicità di protocolli. L’unico protocol binding previsto nella specifica SOAP è per il protocollo HTTP, e utilizza i pattern one-way e request-response per lo scambio dei messaggi. Sono stati proposti binding anche per altri protocolli tra i quali XMPP e SMTP, senza riscuotere però grande successo.

Tuttavia, il modo con cui SOAP utilizza il protocollo HTTP ha generato molto criticismo dalla comunità Web. La base di questa critica sta nel fatto che, pur essendo HTTP è un protocollo applicativo e con una sua precisa semantica, SOAP ignora queste sue caratteristiche utilizzandolo semplicemente come protocollo di trasporto. SOAP, infatti, utilizza esclusivamente il metodo POST del protocollo HTTP, e fa affidamento su propri messaggi di errore piuttosto che sui messaggi di stato HTTP.

2.3.5 Il Web e REST Parallelamente alla crescente popolarità dei Web Services basati su SOAP, un

altro approccio, più vicino ai principi architetturali propri del web, ha riscosso sempre più successo, sulla scia della critica al modello SOAP che utilizzava HTTP come protocollo di trasporto, anziché come protocollo applicativo qual è con diversi tipi di messaggi anziché il solo metodo POST usato da SOAP.

I principi architetturali del moderno web furono delineati da Roy Fielding [FIE00] e furono indicati con il nome di Representational State Transfer (REST). Seppure il web non sia strettamente un sistema di messaging, la sua architettura ha molti punti interessanti che raramente troviamo negli altri sistemi.

2.3.5.1 Architettura REST è definito come uno stile architetturale con alcuni vincoli precisi. Questi

vincoli sono stati delineati da Fielding per dare luogo ad un disegno architetturale che non necessita di eccessiva creatività per la realizzazione, ma piuttosto di particolare attenzione nel soddisfacimento dei vincoli dati.

Innanzitutto, si orienta verso un modello di tipo client-server, la più semplice architettura distribuita, che presenta però i vantaggi di introdurre una netta separazione di responsabilità per quanto riguarda l’archiviazione dei dati, tipicamente affidata al


49

server, e il livello di presentazione, di cui si occupa il client. In secondo luogo, l’interazione tra il client e il server è di tipo stateless, e ogni richiesta contiene tutte le informazioni necessarie per essere servita. Questo promuove sia la scalabilità, dato che il server non deve gestire e mantenere lo stato dell’interazione, sia l’affidabilità, poiché le operazioni di ripristino del sistema sono semplificate. L’efficienza della rete è tuttavia diminuita sotto questo punto di vista, dato che richieste consecutive devono inviare nuovamente informazioni che un server dotato di stato potrebbe invece memorizzare. Per migliorare quest’aspetto, il sistema deve prevedere meccanismi di caching delle risposte inviate dal server, in modo da poter servire le richieste direttamente sul client e evitando di trasmettere le stesse richieste al server. I componenti del sistema supportano inoltre un’interfaccia uniforme (uniform interface), promuovendo in questo modo semplicità e flessibilità al prezzo, ancora, dell’efficienza in rete, dato che un’interfaccia specifica per un componente è di solito più efficiente. Il sistema deve essere inoltre stratificato, e ogni livello appoggiarsi su una ben definita interfaccia esposta dal livello sottostante. In questo modo si migliora il disaccoppiamento tra i componenti a scapito dell’efficienza dato che non è possibile progettare ottimizzazioni che coinvolgano molteplici livelli. Infine, un’architettura RESTful (così sono indicati i sistemi conformi a tutti vincoli) permette di estendere il client con funzionalità prima non previste recuperando codice (code on-demand) dal server. Questo promuove la flessibilità al costo della trasparenza. Si tratta tuttavia di una caratteristica opzionale, che dovrebbe essere usata solo quando assolutamente necessario.

Dal punto di vista architetturale REST è basato sulle risorse. La definizione di una risorsa è volutamente un concetto vago, che permette di includere un qualsiasi tipo di entità, avendo come unico requisito fondamentale quello di avere un nome e di essere identificabile. Gli identificatori sono concepiti come persistenti, che identificano cioè sempre la stessa risorsa, anche nel caso in cui il contenuto di questa risorsa cambi. Ad ogni modo le risorse non sono realmente trasferite, ma piuttosto viene trasferita una rappresentazione della risorsa, appositamente creata per poter essere trasmessa sulla rete. In questo modo una risorsa può avere molteplici rappresentazioni e il sistema può selezionare la più appropriata secondo le circostanze.

Il vincolo di Unifom Interface introduce ulteriori vincoli sull’interfaccia stessa. Innanzitutto, per essere parte del web una risorsa deve avere un identificatore univoco (Identification of resources). Dato che le risorse sono accedute solo tramite rappresentazioni, il loro contenuto è manipolato solo tramite rappresentazioni (Manipulation through resources). Ogni messaggio inoltre deve contenere tutte le informazioni necessarie per essere correttamente compreso ed elaborato (Self-descriptive messages). Infine, anche se l’interazione non ha alcuno stato, un’applicazione distribuita spesso è per sua stessa natura dotata di stato. Questo stato è memorizzato per REST tramite il concetto di collegamento ipertestuale. Le transizioni tra stati sono quindi descritte dai collegamenti ipertestuali nel documento (Hypermedia as the engine of application state).

Il vincolo sui messaggi auto-descrittivi è uno dei più importanti. Esso implica non solo che il messaggio deve descrivere se stesso ma che il ricevente deve essere in grado di comprenderlo, attraverso un linguaggio ben definito per la rappresentazione,


50

una ben definita sintassi per gli identificatori, e un meccanismo per negoziare quale linguaggio è compreso da ognuna delle parti. L’ultimo vincolo, spesso riferito con l’acronimo HATEOAS, è molto importante nella realizzazione di servizi RESTful, in quanto spinge verso la progettazione di servizi esplicitamente focalizzati sulle risorse e sui collegamenti tra di esse. I nuovi stati nelle applicazioni sono definite creando nuove risorse con i collegamenti appropriati. Per questa attenzione alle risorse spesso REST è etichettato come una Resource-Oriented Architecture, in contrapposizione a quella Service-Oriented usata per i servizi basati su SOAP.

Il modo in cui tutti questi vincoli sono messi in gioco è illustrato in Figura 13. In questo caso il client richiede al server risorse appartenenti ad una raccolta di file musicali. Il client richiede la lista delle canzoni, e basandosi su questa, richiede la canzone identificata come 700. Il client crea poi una nuova risorsa per una nuova canzone usando il metodo POST e trasmette il suo contenuto tramite metodo PUT. Infine, il client cancella la canzone appena creata tramite il metodo DELETE. Tutte le operazioni hanno successo, come testimonia il codice di stato 2xx. La risposta di tipo “No Content” indica semplicemente che il messaggio non contiene alcun corpo.

Figura 13 - Esempio di interazione REST.

2.3.5.2 Locator In REST i locator sono rappresentati da URI. Molto comunemente in ambito

web sono utilizzati URI HTTP. Questi sono formati dall’indirizzo, e in alcuni casi dal numero di porta, del server, il percorso della risorsa acceduta, e opzionalmente i parametri della richiesta. Il vantaggio di usare URI HTTP sta nella loro struttura gerarchica.

In questo modo i nomi degli host all’interno di un dominio possono essere assegnati in modo arbitrario dal gestore del dominio stesso, e lo stesso vale per la creazione dei percorsi delle risorse all’interno di un host da parte dell’amministratore dell’host.


51

2.3.5.3 Sintassi La sintassi dei messaggi è definita dal protocollo stesso, l’HTTP. Un messaggio

è quindi costituito da tre parti: una request line, o status line nel caso di messaggio di stato, è posto all’inizio del messaggio e indica il metodo richiesto o lo stato di elaborazione della richiesta; un header, cioè una sequenza di coppie nome-valore; un corpo, rappresentato da un blocco di dati binari, assolutamente opaco al sistema.

L’header contiene tre tipologie di metadati: i resource metadata costituiscono informazioni sulla risorsa, come ad esempio l’istante temporale dell’ultima modifica; i representation metadata sono informazioni sulla rappresentazione scelta per l’interazione, come ad esempio l’indicazione del tipo MIME utilizzato; infine i control metadata contengono informazioni sul messaggio stesso, come ad esempio la possibilità di caching.

2.3.5.4 Protocollo Il protocollo HTTP è stato esplicitamente progettato in accordo ai principi

REST. Come abbiamo detto è infatti un protocollo request-response che supporta semanticamente solo una singola interazione, nel rispetto dei vincoli di assenza di stato.

Ogni richiesta HTTP usa uno specifico metodo di richiesta. Sono previsti otto metodi in tutto ma solo quattro sono d’interesse per l’attuale protocollo. In generale, l’URI indicato nella richiesta specifica la risorsa su cui agisce il metodo. I metodi inoltre assumono un significato leggermente diverso se usati con un’URI che indica una collezione di risorse. Il metodo GET è usato per recuperare (una rappresentazione del) la risorsa identificata dall’URI specificato, o la lista delle risorse nel caso di una collezione. Il metodo PUT permette di memorizzare la rappresentazione fornita come la risorsa identificata dall’URI. Nel caso la risorsa esista già questa viene sostituita. Inoltre nel caso di una collezione è l’intera collezione ad essere sostituita. Il metodo POST prevede di trattare la risorsa selezionata come una collezione, creando un nuovo elemento al suo interno sulla base della rappresentazione fornita. Infine il metodo DELETE permette di rimuovere, a seconda dell’URI, la singola risorsa o l’intera collezione.

Questi metodi permettodo quindi di realizzare il modello Create-Retrieve-Update-Delete (CRUD) propri dell’ambito dell’archiviazione dati. Spesso inoltre il metodo POST è spesso inteso con un’accezione più ampia, in cui la semantica precisa è definita dal server per ogni specifica URI. Questo è anche il motivo per cui SOAP usa il metodo POST, essendo l’unico con una semantica che permette l’invocazione di procedure remote.

Una caratteristica particolare dell’HTTP è la negoziazione dei contenuti, che è integrata all’interno dell’interazione request-response: il client, all’interno della richiesta, indica tutti i tipi di contenuti che può supportare ed il server sceglie un particolare formato in base alle capacità del client. I parametri negoziabili includono anche la rappresentazione (ad es. XML o JSON) o la codifica applicata (ad es. compressione).


52

2.4 - Mobile sensing Oltre a costituire i principali dispositivi mobili per l’elaborazione e la

comunicazione, gli smart phone odierni sono equipaggiati con una vasta gamma di sensori integrati quali GPS, accelerometro, bussola, giroscopio, microfono, fotocamera etc. Ciò permette di utilizzare questi dispositivi come una piattaforma per la raccolta e l’elaborazione di un gran numero di informazioni riguardanti sia l’utente stesso che l’ambiente circostante, aprendo molteplici ed interessanti scenari applicativi negli ambiti più svariati come l’assistenza sanitaria, i social network, la sicurezza, il monitoraggio ambientale o i trasporti, e dando luogo al filone di ricerca che va sotto il nome di mobile sensing [LAN10].

Già diversi anni fa il tema aveva registrato un forte interesse da parte della comunità di ricerca, risultando da subito evidenti le notevoli potenzialità. Ad esempio, gli autori di [SCH99] già nel 1999 avevano ideato un sistema di riconoscimento dell’ambiente circostante all’utente in base alle informazioni rilevate da una serie di sensori collegate ad un PDA. Tuttavia emersero da subito una serie di problematiche di carattere principalmente tecnologico: la capacità di elaborazione limitata era insufficiente per gestire i complessi dati provenienti dai sensori, e ciò impediva la realizzazione di applicazioni scalabili; inoltre i PDA non erano dotati di sensori propri, ma era necessario utilizzare dispositivi esterni realizzati appositamente per il caso applicativo. Questo provocò un momento di stasi per gli studi nel campo del mobile sensing [LAN10].

Con l’avvento dei moderni smartphone tali problematiche possono essere finalmente risolte. Innanzitutto tali dispositivi presentano una serie di sensori già integrati, rappresentando quindi una piattaforma ottimale per le applicazioni in ambito mobile sensing. Il problema computazionale invece può essere affrontato attraverso due aspetti chiave: da una parte la maggiore potenza offerta dai processori, dall’altra la capacità di connettività e disponibilità di banda, che permette di spostare sull’infrastruttura di back-end, la cosiddetta “nuvola” di elaborazione, una parte dell’onere computazionale. Una delle problematiche rimaste ancora aperte è rappresentato dall’eccessivo consumo di energia e la bassa autonomia causata dall’utilizzo prolungato di alcuni sensori. Vi sono stati diversi studi al riguardo, nella maggior parte basati su un’opportuna regolazione della frequenza di campionamento dei dati da parte dei sensori, come ad esempio in [ABD09] riguardo al GPS, o sullo spegnimento selettivo dei sensori quando non necessari, come proposto in [WAN09].

Il mobile sensing può essere per certi versi considerato l’evoluzione del filone rappresentato dai wireless sensor netowrk. Si tratta di un’area di ricerca che investiga sui possibili utilizzi e sulle tecniche adottate all’interno di reti caratterizzate da un’architettura distribuita e costituite da un insieme di dispositivi elettronici autonomi in grado di prelevare dati dall’ambiente circostante e di comunicare tra di loro. In questa accezione possiamo pensare ad un modello di sensing “partecipativo”, in cui i dati raccolti da un singolo utente, piuttosto che essere elaborati e fruiti sul singolo dispositivo, vengono combinati con quelli di un’intera rete di utenti per elaborare complesse informazioni di carattere globale piuttosto he locale. Rispetto al sistema dei


53

wireless sensor network il mobile sensing presenta diversi vantaggi [KAN09] secondo il particolare caso applicativo:

1. I dispositivi mobili possono fornire copertura di sensing anche dove è difficile o impossibile installare una rete di sensori.

2. In molti casi non si ha più necessità di installare una rete di sensori dedicata: la rete di sensori è rappresentata dall’insieme dei dispositivi degli utenti stessi.

3. Si prestano molto bene a quelle applicazioni che richiedono la partecipazione della comunità per realizzare particolari task di sensing.

4. In alcuni casi può risultare più efficiente raccogliere ed elaborare i dati sul dispositivo stesso, inviando in rete solo il risultato dell’elaborazione piuttosto che l’informazione completa e ridondante.

5. Oltre alle informazioni sensoriali, vi sono altre informazioni di contesto quali foto e messaggi, che possono essere inviate insieme ai dati.

Se da una parte sono diversi i vantaggi offerti dal mobile sensing rispetto alle wireless sensor network, è necessario osservare che in alcuni scenari applicativi, si pensi ad esempio al monitoring dei livelli di inquinamento atmosferico di un’area urbana, i sensori di cui sono provvisti gli smartphone sono assolutamente inutili, e risulta necessaria l’installazione di una rete di sensori dedicata.

Procediamo quindi con l’esplorazione dei sensori di cui sono comunemente equipaggiati gli smartphone per capire meglio quali sono le possibilità offerte.

2.4.1 Sensori I primi smartphone non includevano alcun sensore particolare oltre a quelli più

basilari come microfono e fotocamera. Col passare del tempo sono aumentati sempre di più i sensori integrati all’interno dei dispositivi evidenziando quindi la tendenza generale a renderli sempre più accessoriati e “smart”. Naturalmente oggigiorno non tutti i dispositivi mobili sono dotati dello stesso set di sensori. L’accelerometro, ad esempio, è una tipologia di sensore utilizzato originariamente per realizzare la funzionalità di re-orientazione del display quando il dispositivo viene ruotato. Tale sensore è assente nella maggior parte degli smartphone appartenenti alla famiglia BlackBerry, prodotti dalla società canadesi Research In Motion, che non sono progettati per essere utilizzati secondo diverse orientazioni. Altri dispositivi, come ad esempio l’Apple iPhone 4, rappresentano i massimi esponenti del trend di sviluppo del sensing essendo dotato di ben 8 sensori: accelerometro, giroscopio, bussola, sensore di prossimità, sensore di luminosità, ricevitore GPS, fotocamera e microfono.


54

Figura 14 - L'Apple iPhone 4 con i suoi sensori

Probabilmente tra qualche anno i dispositivi saranno equipaggiati con un numero ancora maggiore di sensori. Illustriamo di seguito la funzione dei sensori che possiamo incontrare negli smartphone attuali.

2.4.1.1 Accelerometro Si tratta di un dispositivo in grado di misurare l’accelerazione del dispositivo

lungo 3 assi di riferimento. È solitamente usato per rilevare l’orientazione del dispositivo misurando la direzione dell’accelerazione di gravità.

Può essere utilizzato per conoscere importanti informazioni sullo stato e sull’ambiente dell’utente. Gli autori di [MIL08] ad esempio sfruttano i dati collezionati attraverso l’accelerometro per classificare l’attività che l’utente sta effettuando (ad esempio camminare, correre, stare seduto, stare in piedi) e condividerla sui social network.

2.4.1.2 Giroscopio Questo sensore riesce a rilevare la velocità angolare del dispositivo lungo 3 assi

di riferimento. Come l’accelerometro permette di individuare l’orientazione del dispositivo ma, a differenza di quest’ultimo, non è soggetto all’accelerazione di gravità.

2.4.1.3 Bussola Si tratta di una bussola digitale con funzionamento analogo a quello di una

bussola magnetica. È quindi soggetto alle interferenze prodotte da campi magnetici presenti nelle vicinanze.


55

Viene usata in combinazione con il sistema GPS e il giroscopio per migliorare le funzionalità di localizzazione, individuando anche orientazione e direzione in cui è posizionato il dispositivo.

2.4.1.4 Sensore di prossimità Si tratta di un sensore a infrarossi che rivela la presenza di oggetti vicini al

sensore, con un raggio massimo di circa 10 cm. Solitamente è posto vicino all’altoparlante e viene usato per disattivare le funzionalità del touchscreen quando è in corso una telefonata, in modo da evitarne l’attivazione in seguito al contatto con l’orecchio dell’utente.

2.4.1.5 Sensore di luminosità È un sensore in grado di rilevare il livello di luminosità dell’ambiente

circostante. È solitamente utilizzato per regolare automaticamente la luminosità dello schermo in base alle condizioni ambientali.

Anche questo sensore può essere utilizzato per ricavare una serie di informazioni sul contesto dell’utente. Ad esempio dagli autori di [MIL11] viene utilizzato, in combinazione ad altri sensori, per inferire se il dispositivo si trova nella tasca dell’utente o meno.

2.4.1.6 Fotocamera Si tratta del sensore più diffuso tra tutti, insieme, naturalmente, al microfono. È

un dispositivo capace di catturare singole immagini o sequenze video dell’ambiente circostante. Può essere posto sulla parte posteriore del dispositivo o, nei dispositivi più avanzati, sia su quella anteriore che posteriore.

L’utilizzo più comune è quello di catturare immagini e/o video per caricarle in rete. Tuttavia esistono diversi studi che utilizzano tale sensore per funzionalità avanzate. Gli autori di [WAN12] ad esempio utilizzano la fotocamera posta sul retro degli smartphone per individuare automobili in arrivo mentre l’utente è impegnato in una telefonata, permettendo quindi di avvisare l’utente e metterlo in sicurezza.

2.4.1.7 Microfono È un dispositivo in grado di registrare sequenze audio concernenti l’ambiente

circostante. Tutti gli smartphone, dovendo permettere di effettuare telefonate, devono essere equipaggiati con questo sensore. Può invece essere assente nei tablet.

Può essere utilizzato per ricavare importanti informazioni di contesto dell’utente. Ad esempio gli autori di [LUP09] utilizzano il microfono per collezionare feature sonore che, in seguito all’etichettamento da parte dell’utente, possono essere usate per effettuare un successivo riconoscimento delle attività svolte.

2.4.1.8 Ricevitore GPS Si tratta di un dispositivo che sfrutta il sistema GPS (Global Positioning

System) per ricavare le coordinate geografiche e quindi la posizione del dispositivo.


56

La maggior parte degli smartphone utilizza un sistema detto Assisted-GPS, in cui il sistema GPS è affiancato dal sistema di telefonia allo scopo di ridurre i tempi di inizializzazione ed il consumo energetico che caratterizzano il sistema GPS classico. I sistemi GPS e A-GPS saranno discussi con maggiori dettagli nel paragrafo 2.4.5.1.

Questo sensore rappresenta il cardine attorno cui si sviluppano i servizi detti location-based (LBS, Location-Based Services), servizi cioè in cui la posizione geografica dell’utente ha un ruolo centrale nell’erogazione e nella personalizzazione del servizio stesso.

2.4.2 Scale di sensing Una caratteristica fondamentale dei sistemi di sensing è rappresentata dalla

dimensione della base di utenza a partire della quale sono aggregati ed elaborati di dati raccolti. Possiamo avere applicazioni che utilizzano esclusivamente le informazioni raccolte su un singolo dispositivo, altre invece che producono un risultato elaborando le informazioni raccolte da un gruppo di centinaia di dispositivi. A questo proposito gli autori di [LAN10] distinguono tre differenti scale di sensing, personal, group, e community sensing, illustrate schematicamente in Figura 15.

Figura 15 - Le diverse scale del mobile sensing: individual, group e community sensing

2.4.2.1 Personal sensing L’elaborazione del sistema sfrutta esclusivamente i dati raccolti su un singolo

dispositivo, che riguardano quindi con molta probabilità il singolo individuo che gestisce il dispositivo. I dati e, tipicamente, anche i risultati dell’elaborazione sono quindi destinati a essere fruiti dal singolo utente, senza necessità di essere condivisi.

Un esempio di questa tipologia di sistemi è UbiFit Garden [CON08], citata in Figura 15, un’applicazione con l’obiettivo di stimolare la cura del benessere fisico dell’utente. Attraverso un dispositivo di sensing dedicato ed esterno allo smartphone


57

sono raccolti dati sull’attività fisica svolta dall’utente. Attraverso una metafora tra la rigogliosità di un giardino virtuale visualizzato sullo smartphone e il benessere fisico, si cerca di stimolare l’esercizio dell’utente.

2.4.2.2 Group sensing Spesso gli utenti di un’applicazione hanno interesse a condividere le loro

esperienze all’interno di gruppi di persone con gli stessi interessi, obiettivi o abitudini, siano essi il gruppo di lavoro, gli amici o il vicinato. In questo senso la classe di applicazioni che va sotto il nome di group sensing utilizza le informazioni raccolte dal singolo utente condividendole, in forma primitiva o dopo aver eseguito un’elaborazione, all’interno del gruppo. Queste tipologie di applicazioni hanno quindi una forte componente sociale. Spesso l’appartenenza a un gruppo comporta la presenza di un rapporto di fiducia tra i membri con effetti positivi su due aspetti: una maggiore affidabilità dei dati rilevati e una minore necessità di riservatezza. Inoltre i dati raccolti all’interno del gruppo possono essere semplicemente condivisi o utilizzati per elaborare ulteriori risultati.

L’applicazione CenceMe [MIL08], ad esempio, utilizza i sensori dei dispositivi mobili per inferire le attività che l’utente sta compiendo, secondo un processo detto activity recognition, e utilizza tale informazione per aggiornare lo status dell’utente sui social network, condividendolo quindi all’interno della sua rete di amici. GarbageWatch invece, citata in Figura 15, permette gli studenti universitari di segnalare i casi di negligenza nel sistema di raccolta di rifiuti dell’ateneo.

2.4.2.3 Community sensing Il community sensing si basa sulla raccolta di informazioni su una scala più

ampia rispetto al group sensing, e fa riferimento ad una vasta comunità, quale può essere una intera città, piuttosto che un gruppo limitato di persone. Considerato questo scenario, a differenza del group sensing non è possibile supporre alcun rapporto di fiducia tra gli utenti. Da ciò consegue la necessità di garantire maggiore riservatezza dei dati e di implementare meccanismi di sensing che non richiedano troppo impegno agli utenti. Gli scenari applicativi più classici sono il rilevamento di parametri riguardanti l’area urbana come inquinamento atmosferico e acustico o traffico. NoiseSpy [KAN09] rappresenta un esempio di applicazione che utilizza gli smartphone per rilevare il rumore degli ambienti cittadini e costruire una mappa dell’inquinamento acustico aggiornata in tempo reale.

2.4.3 Paradigmi di sensing Le operazioni di raccolta dei dati di sensing possono prevedere diversi gradi di

coinvolgimento dell’utente. Ad esempio può essere necessario che gli utenti attivino esplicitamente la rilevazione o che ciò avvenga in automatico. Gli autori di [LAN08] distinguono due principali categorie in cui possono essere classificati i sistemi di mobile sensing: partecipativo o opportunistico.


58

2.4.3.1 Sensing opportunistico Nel sensing opportunistico la fase di raccolta dei dati avviene completamente in

modo automatico, senza bisogno dell’intervento dell’utente. Questo permette di ottenere più facilmente un’ampia base di utenti, e mantenerla attiva anche nel caso in cui l’applicazione non sia particolarmente attrattiva. Per questo motivo è particolarmente indicato nei casi di community sensing, in cui i benefici per il singolo utente potrebbero svilupparsi e rendersi evidenti solo sul lungo periodo.

Uno dei problemi del sensing opportunistico è legato al constesto del telefonino che può non essere appropriato all’operazione di sensing. Nel caso dell’applicazione NoiseSpy [KAN09] citata nel paragrafo precedente, ad esempio, la rilevazione dell’inquinamento sonoro non è praticabile nel caso in cui il dispositivo si trovi nella tasca dell’utente e dovrebbe quindi essere sospesa. In alcuni casi è possibile ovviare questo tipo di problematiche ricorrendo al sensing per monitorare il contesto del dispositivo e attivare la rilevazione solo quando appropriato. Ritornando al caso di NoisySpy, [MIL11] propone una serie di possibili soluzioni, basate principalmente sui sensori di prossimità e luminosità, per inferire se il dispositivo si trova in tasca o meno.

2.4.3.2 Sensing partecipativo Nel sensing partecipativo l’utente è coinvolto attivamente nella raccolta dei

dati, decidendo quando, dove, come o cosa rilevare. Rispetto al sensing opportunistico, quindi, presuppone un maggior peso per l’utente, che si fa carico di una parte delle operazioni di sensing selezionando quali dati collezionare e procedendo al campionamento. Da ciò deriva che l’utente deve essere sufficientemente motivato a compiere questo sforzo in luce dei benefici derivano dall’uso dell’applicazione. Ad esempio, nel caso già citato di GarbageWatch, sono gli utenti stessi, gli studenti universitari, a dover individuare un cestino pieno e a scattare una foto, stimolati dall’incentivo di studiare in un ambiente pulito e ben tenuto.

Uno dei vantaggi del sensing partecipativo consiste nella possibilità di superare le eventuali problematiche incontrate nel meccanismo di sensing coinvolgendo l’intelligenza dell’utente. Ritornando al caso di NoisySpy [MIL11], ad esempio, è possibile fare affidamento sulla responsabilità dell’utente nel tenere il dispositivo fuori dalla tasca per ottenere rilevazioni corrette.

Naturalmente, le due modalità di sensing, partecipativo e opportunistico, con i loro pro e i loro contro, rappresentano due estremi tra i quali vi sono molte configurazioni intermedie che possono essere esplorate.

2.4.4 Architetture di sensing Nonostante l’architettura generale di un sistema di sensing sia una caratteristica

determinante per le performance e la qualità di un sistema, non vi è ancora un modello universalmente accettato. Non è immediato stabilire ad esempio cosa dovrà essere eseguito sul dispositivo e cosa invece sarà trasferito ed elaborato sull’infrastruttura di back-end. O ancora, è bene valutare con attenzione l’incidenza del carico di sensing


59

cui è sottoposto il dispositivo sulle prestazioni del sistema, soprattutto in termini di risorse utilizzate (memoria, processore) e durata della batteria.

Gli autori di [LAN10] propongono un modello di base, illustrato in Figura 16, composto da 3 fasi fondamentali: rilevazione, interpretazione e fruizione.

Figura 16 - Il modello a 3 blocchi proposto dagli autori di [LAN10]: percezione, apprendimento, condivisione

2.4.4.1 Rilevazione L’architettura di sensing coinvolge innanzitutto il singolo dispositivo e i sensori

in esso integrati per la raccolta dei dati in forma. Questa fase comporta diversi ostacoli legati principalmente a tre fattori: il livello di controllo delle operazioni di sensing offerte dal dispositivo e dal sistema operativo, la dinamicità del contesto legata alla mobilità dell’utente, e la necessità di supportare il sensing in modo continuativo.

I sistemi meno recenti, come ad esempio Symbian, supportano un basso livello di programmabilità e non permettono il controllo completo dei sensori e di altre funzionalità di basso livello. Gli autori di [MIL08], ad esempio, durante l’implementazione dell’applicazione CenceMe, sul dispositivo Nokia N95 con sistema Symbian e piattaforma JME, riscontrano la mancanza d’interfacce per accensione e spegnimento di GPS e GPRS, necessari per una gestione efficiente dei consumi energetici, e la mancanza di API per il controllo dell’accelerometro integrato. Se quest’aspetto è andato via via scomparendo nei sistemi recenti, con iOS e Android che supportano un maggiore livello di controllo sui sensori, gli autori di [PAP11] mostrano come iOS presenti alcune limitazioni rispetto alla controparte. In particolare, mentre in Android è possibile abilitare individualmente i differenti meccanismi di localizzazione


60

quali GPS, WiFi e basato su cella, permettendo una migliore ottimizzazione dei consumi energetici, il sistema iOS offre una gestione a grana più grossa, in cui è nascosto al programmatore il tipo di meccanismo effettivamente utilizzato. Sempre nello stesso articolo si riscontra come il sistema iOS provveda a disabilitare l’accelerometro nel momento in cui l’applicazione viene portata in background, mentre ciò non avviene in Android. Maggiori informazioni sulle diverse piattaforme per dispositivi mobili e in particolare sul sistema Android saranno date nel capitolo 3 - Piattaforme per dispositivi mobili.

Il tema del multitasking e dei task in background assume un ruolo centrale nel contesto del sensing continuativo. Molti casi applicativi, infatti, richiedono che l’operazione di sensing sia protratta per un tempo prolungato. Ciò presuppone che sia possibile continuare con le operazioni di sensing anche quando l’applicazione è passata in background, cioè quando l’utente non sta direttamente interagendo con questa. Mentre nel sistema Android il multithreading è supportato sin dalle prime versioni, ed è possibile controllare i sensori anche quando l’applicazione esegue in background (seppure la documentazione consigli vivamente di disabilitare i sensori non necessari per limitare il consumo di batteria [AND01]), in iOS la questione è stata molto dibattuta: il multithreading è stato introdotto solo dalla versione 4.0, con forti limitazioni alle applicazioni che eseguono in background tra cui l’impossibilità di comunicare con i sensori. Solo dalla versione 5.0, invece, ciò è reso possibile sotto particolari restrizioni [NEU12].

Nello scenario del sensing continuativo è necessario quindi tenere in considerazione la possibilità che il task esegua in background e condivida le risorse del dispositivo con altre applicazioni. A questo si aggiunge che gli smartphone, nonostante sempre più evoluti, costituiscono ancora dei dispositivi con risorse limitate se sono richieste attività quali l’elaborazione di segnali e l’inferenza di informazioni da questi. Vi possono essere casi in cui è richiesta un’elevata percentuale di CPU per elaborare grosse moli di dati (e.g. segnali audio, [LUP09]), in altri l’utilizzo troppo frequente di alcuni sensori provoca un elevato dispendio di energia (e.g. GPS, [MUN09]), mentre in altri può essere richiesta l’inferenza di informazioni in tempo reale (e.g. Darwin [MIL10]). Per risolvere le problematiche legate al sensing continuativo sono stati proposti diversi approcci. In VibN [PAP11], ad esempio, si fa ricorso ad una gestione dinamica dei cicli di lavoro dei sensori, alternando fasi di attività a fasi di riposo. Per quanto riguarda l’uso del processore è possibile sfruttare l’infrastruttura di back-end per ridurre il carico di elaborazione sul dispositivo mobile. Nel caso di CenceMe [MIL08], ad esempio, sul dispositivo mobile viene eseguita solo una prima estrazione di feature, mentre un’estrazione più robusta e la successiva elaborazione sono eseguite sull’infrastruttura di back-end. Tuttavia, anche il trasferimento verso l’infrastruttura di back-end ha un costo in termini di banda e di energia. Per questo in alcuni casi [LUP09] si preferisce eseguire tutta la fase di elaborazione sul dispositivo mobile. A questo proposito sono stati compiuti sforzi anche per ottimizzare il trasferimento dei dati rilevati nell’ottica della riduzione dei consumi. Gli autori di [MUL10] propongono ad esempio soluzioni basate su diversi aspetti: miglior compromesso tra accuratezza dei dati e consumo, predizione lato server dei dati rilevati in futuro e ottimizzazione della trasmissione in base alla posizione geografica. Altre soluzioni possono essere ideate sullo specifico caso applicativo. Se l’applicazione lo consente potrebbe essere


61

sensato, ad esempio, rimandare il trasferimento dei dati verso l’infrastruttura al momento in cui il dispositivo viene ricaricato.

Per garantire correttezza e qualità dei dati rilevati necessario che il contesto del dispositivo sia adeguato all’operazione di sensing. Il problema del contesto riguarda tutte quelle situazioni che vanno ad interferire con l’abilità del dispositivo e dei sensori di intercettare un determinato evento: dalle azioni dell’utente, come inserire il telefono in tasca Per loro natura i dispositivi mobili sono usati in diverse modalità che è difficile prevedere a priori. Le azioni dell’utente (e.g. l’utente potrebbe mettere in tasca il telefono, o essere impegnato in una telefonata) o il tempo di esposizione insufficiente, (e.g. l’utente si muove in macchina, il sensore richiede un tempo di esposizione elevato) sono esempi di fattori del contesto che contribuiscono a degradare la qualità della rilevazione. Le soluzioni proposte a questo tipo di problematiche sono diverse. Gli autori di [EIS08] realizzano un sistema di condivisione di sensori tra dispositivi vicini, in modo da fornire un’alternativa ai sensori il cui contesto non è favorevole. Sempre in questa direzione, gli autori di [HON08] propongono l’aggregazione dei dati provenienti da tutti i sensori presenti in un’area come tecnica per migliorare affidabilità e precisione delle misurazioni e ridurre l’impatto del rumore. Infine, un altro valido approccio è quello adottato dagli autori di [LUP09] con SoundSense, che utilizzano una fase preliminare di controllo mirata a scartare le rilevazioni di bassa qualità.

2.4.4.2 Interpretazione I dati grezzi raccolti nella fase di rilevazione non hanno alcuna utilità senza

un’opportuna interpretazione. Dai dati raccolti dai sensori del dispositivo, infatti, devono essere distillate le informazioni riassuntive da presentare all’utente, come l’inquinamento acustico medio nella zona attraversata o il numero di passi percorsi. Per ricavare tali informazioni si ricorre solitamente a tecniche di data mining e calcolo statistico. L’elaborazione dei segnali avviene tramite due fasi fondamentali: l’estrazione di feature e la classificazione, come mostrato in Figura 17.

Figura 17 - I dati grezzi vengono trasformati prima in una serie di feature che permettono agli algoritmi di classificazione di

individuare il contesto dell'utente

L’estrazione di feature consiste nell’individuare e calcolare una serie di parametri statistici che sono ritenuti particolarmente caratterizzanti nei confronti del tipo di classificazione che si vuole effettuare. È importante selezionare feature sufficientemente robuste rispetto alle alterazioni introdotte dalle variazioni di contesto. Gli autori di [LUP09], ad esempio, evidenziano come il Valore Efficace (o Root Mean Square) sia molto sensibile all’orientazione e alla posizione del dispositivo rispetto alla fonte dell’evento (in questo caso sonoro), come mostrato in Figura 18.


62

Figura 18 – Variazioni del Valore Efficace del segnale audio a seconda che il dispositivo sia (A) nella mano dell’utente di

fronte alla sorgente, (B) in tasca di fronte alla sorgente, (C) nella mano rivolto altrove, (D) in tasca rivolto altrove.

L’estrazione delle feature può operare direttamente sui segnali rilevati o su una trasformazione di essi (e.g. Trasformata Discreta di Fourier, DFT). In [MIL08], ad esempio, sono utilizzate feature differenti per i dati raccolti dall’accelerometro e i segnali audio campionati dal microfono. Per i primi, utilizzati per l’individuazione dell’attività svolta dall’utente (e.g. seduto, in piedi, camminando, correndo), viene ritenuta sufficientemente efficace ed efficiente l’estrazione di semplici parametri statistici dal segnale originale quali media, varianza e numero di picchi. Nel caso dei segnali audio, invece, si esegue prima una trasformazione DFT, ottimizzata considerando solo una porzione ristretta dello spettro, per poi calcolare media e varianza dello spettro di potenza del segnale DFT. Esistono molti altre feature possibili, come ad esempio quelle utilizzate in [LUP09] di cui citiamo solo alcune: Zero Crossing Rate, Low Energy Frame Rate, Spectral Flux, Spectral Rolloff, Spectral Centroid, Normalized Weighted Phase Deviation etc.

La seconda fase di classificazione, invece, ha l’obiettivo di etichettare i campioni ottenuti sulla base delle feature estratte, stabilendo l’appartenenza dell’evento a una ben precisa categoria. È possibile utilizzare diverse tecniche di data mining, come ad esempio quelle utilizzate in [MIL08], quali l’analisi discriminante o l’albero di classificazione. Tralasciamo l’approfondimento di tali tecniche che non sono oggetto della trattazione, considerando anche che se nei sistemi di sensing è molto comune la fase di estrazione di feature, non è sempre necessario e previsto dal contesto applicativo procedere alla fase di classificazione. Ad esempio, un’applicazione che ha l’obiettivo di visualizzare i livelli di inquinamento sonoro delle diverse aree urbane prevedrà l’estrazione di feature, quali la potenza del segnale rilevato, ma non necessiterà di alcuna classificazione. Esistono poi tecniche di apprendimento volte ad accrescere in modo automatico le tipologie di attività e di contesto riconosciute dall’algoritmo di classificazione.

In letteratura esistono diversi esempi di applicazioni che, sfruttando principalmente microfono GPS e accelerometro, riescono a inferire attività umane complesse. Gli autori di [LIA07], ad esempio, esclusivamente sulla base dei percorsi rilevati tramite GPS e attraverso particolari tecniche statistiche, sono riusciti non solo ad inferire i luoghi significativi visitati dall’utente, ma a dedurne l’attività correlata (e.g. casa, lavoro, autobus etc.). Altro lavoro degno d’interesse è SoundSense [LUP09], in grado di riconoscere sia un insieme statico di attività dell’utente a partire


63

dai suoni rilevati dal microfono, sia di accrescere l’insieme di attività riconosciute individuando classi ricorrenti non note, che vengono etichettate manualmente dall’utente.

2.4.5 Location Awareness La posizione rappresenta sicuramente l’informazione sensoriale più utilizzata

tra tutte, permettendo un ampio spettro di possibilità e funzionalità applicative molto interessanti e appetibili sia per l’utente finale sia per lo sviluppatore, siano esse destinate al settore B2C o B2B. Mostrare all’utente la sua posizione attuale su una mappa, visualizzare una lista dei ristoranti più vicini, essere avvisati quando si è giunti alla propria fermata di tram, o essere aggiornati riguardo ingorghi stradali nelle vicinanze sono solo alcuni dei possibili task realizzati da una particolare tipologia di applicazioni, dette Location Aware per la loro capacità di tenere conto della posizione corrente dell’utente.

Vi sono diverse tecniche che possono essere utilizzate per ottenere la posizione corrente dell’utente, ognuna basata su una tecnologia differente: attraverso il sistema GPS, attraverso la rete telefonica, e infine tramite reti Wi-Fi. A ogni metodo corrisponde un diverso grado di accuratezza e comporta un differente onere energetico e computazionale. In base al tipo di scenario applicativo in cui si usufruisce della localizzazione, la stima della posizione dell’utente necessità un determinato grado di accuratezza. Nel caso di un navigatore, ad esempio, le misurazioni sarebbero inutili se troppo inaccurate, mentre notificare all’utente i film in programmazione nella città rappresenta un task più tollerante riguardo il grado di accuratezza.

La posizione è espressa con riferimento al reticolo di linee fisse formato da meridiani e paralleli. In questo sistema di riferimento la posizione è rappresentata tramite le coordinate geografiche, costituite da tre grandezze: latitudine, longitudine e altitudine. La latitudine è la distanza angolare del punto dall’equatore e la longitudine è la distanza angolare di un punto dal meridiano di riferimento, il meridiano di Greenwich, lungo lo stesso parallelo del luogo. Latitudine e longitudine sono misurate in gradi. L’altitudine invece individua la distanza verticale del punto geografico dal livello del mare. In Figura 19 è schematizzata la rete di meridiani e paralleli e sono esemplificate le grandezze latitudine e longitudine di un punto P.

Figura 19 - La rete di meridiani e paralleli e un esempio di latitudine e longitudine di un punto P sulla superficie terrestre.


64

Di seguito saranno esaminate le diverse metodologie tramite cui può essere recuperata la posizione geografica di un utente.

2.4.5.1 Global Positioning System Il Global Positioning System (GPS) [GPS00] è stato creato dal Dipartimento di

Difesa Americano, United States Departement of Defense (DoD), per fini militari ed in seguito utilizzato per scopi civili. Il funzionamento del GPS è basato su una rete di 27 satelliti, di cui 4 operativi e 3 di riserva, orbitanti intorno alla terra su 6 diversi piani, che compiono due rotazioni ogni giorno, come illustrato in Figura 20.

Figura 20 - La rete di satelliti del sistema GPS

Le orbite sono studiate in modo che ogni punto della terra sia visto in ogni momento da almeno 4 satelliti contemporaneamente. Vi sono inoltre 4 stazioni terrestri incaricate di verificare costantemente lo stato dei satelliti e correggerne orologio atomico e posizione orbitale.

Altro componente fondamentale del sistema è il ricevitore, costituito generalmente da un antenna, un microprocessore ed una sorgente temporale, che per ottenere la propria posizione deve svolgere le seguenti operazioni:

1. localizzare 4 o più satelliti; 2. calcolare la distanza da ognuno di essi; 3. calcolare la propria posizione mediante trilaterazione.

La distanza tra il ricevitore e il satellite viene calcolata misurando il tempo di percorrenza di un segnale ad alta frequenza (le bande usate sono 1575.42 Mhz e 1227.60 Mhz) inviato dal satellite e al ricevitore.

Il metodo della trilaterazione rappresenta l’analogo della triangolazione nelle 3 dimensioni. Sebbene sarebbero sufficienti solo 3 misure per individuare il punto preciso, la necessità di un quarto satellite è dovuta alla scarsa precisione della misura temporale presente sul ricevitore, che a differenza dei satelliti non è dotato di un orologio atomico. Una imprecisione di un millesimo di secondo provocherebbe infatti


65

un errore nell’ordine di centinaia di chilometri. L’imprecisione temporale introduce un ulteriore grado di libertà che rende necessaria la necessità di un quarto vincolo per la risoluzione del sistema di variabili associato. Da qui la necessità di un satellite aggiuntivo.

Fino all’anno 2000 la precisione del sistema a uso civile era intenzionalmente degradata dal governo degli Stati Uniti. Attualmente invece la precisione massima di circa 10-20 metri è disponibile anche ad usi civili.

Nonostante la sua elevata accuratezza, un grande svantaggio della tecnologia GPS è rappresentato dalla necessità di visibilità diretta tra il ricevitore e il satellite. Risulta quindi inutilizzabile negli ambienti interni o in particolari zone urbane in cui gli edifici ostruiscono la comunicazione.

2.4.5.2 Assisted GPS La ricerca dei satelliti necessari calcolo della posizione da parte del ricevitore

costituisce un’operazione piuttosto costosa in termini di risorse hardware, energetiche e temporali (in media tra i 45 e i 90 secondi). Ciò ha inizialmente frenato la diffusione dei ricevitori all’interno dei dispositivi mobili quali smartphone e tablet, a causa dei vincoli stringenti che caratterizzano questa tipologia di dispositivi. Quest’ostacolo è stato superato negli ultimi anni con l’introduzione del sistema Assisted GPS, o A-GPS, che sfrutta la rete di telefonia mobile per far pervenire le informazioni sui satelliti visibili dalla cella radio cui il terminale è agganciato. In questo modo è possibile saltare la prima fase di acquisizione, rendendo il procedimento di ottenimento della posizione più veloce e meno costoso.

2.4.5.3 Rete telefonica È possibile sfruttare l’infrastruttura telefonica per identificare la posizione del

dispositivo [STE04]. Ciò può essere ottenuto mediante diverse tecniche, ognuna con un differente grado di precisione. Tutti i metodi si basano sull’assunzione che il dispositivo sia in comunicazione con i ripetitori più vicini.

Il metodo più semplice, detto Cell-of-origin consiste nell’identificare la posizione del dispositivo l’area stessa coperta dalla cella, come mostrato in Figura 21.

Figura 21 - Localizzazione Cell-based.

In realtà questa tecnica non effettua nessun reale sforzo di computazione per calcolare la posizione del dispositivo.


66

Esistono poi un insieme di tecniche più complete e precise che utilizzano il tempo di comunicazione tra il ricevitore ed il ripetitore (Time of Arrival, TOA) per ricavare la distanza dai ripetitori, di posizione nota, e calcolare quindi la posizione tramite triangolazione. Nel caso in cui il ricevitore sia collegato con 3 o più ripetitori questi metodi riescono a fornire una buona stima della posizione, come mostrato in Figura 22.

Figura 22 - Localizzazione tramite triangolazione delle celle.

Nel caso in cui il dispositivo sia collegato con un solo ripetitore, però, è possibile ottenere solo una circonferenza di punti che rappresentano le possibili posizioni del dispositivo. La precisione di questo metodo è quindi fortemente dipendente dal numero di ripetitori presenti, e quindi dalla loro densità, nell’area interessata.

A differenza del GPS, però, la tecnica è applicabile anche in ambienti interni, a patto che sia disponibile la copertura della rete di telefonia mobile.

2.4.5.4 Wi-‐Fi Positioning System Il Wi-Fi Positioning System (WPS) [GOO01] è una tecnica diffusasi solo

recentemente che sfrutta l’elevata densità di wireless Access Point (AP) che caratterizza le aree urbane.

Esistono diversi provider di questo servizio, di cui il più famoso è Google. L’azienda mantiene e gestisce un archivio degli identificativi (indirizzo MAC e SSID) di tutti gli AP presenti nelle aree mappate. L’archivio è stato costruito in occasione Si basa su un archivio, gestito da Google, contenente le posizioni geografiche degli Access Point, costruito dalle stesse Google Car utilizzate per il servizio Street View, e che hanno catalogato la presenza di Access Point wi-fi associandovi una posizione geografica.

Per conoscere la propria posizione geografica un dispositivo invia ai server del servizio Google Maps una lista contenente gli identificati degli AP visibili con associata l’intensità del segnale Wi-Fi ricevuto (Received Signal Strength, RSS). I server possono quindi verificare la presenza nell’archivio degli identificativi ricevuti


67

dal dispositivo e recuperarne la posizione geografica. Tramite la triangolazione delle misure di RSS i server possono quindi calcolare la posizione dell’utente. La precisione della misura ottenuta dipende quindi dalla densità di AP dell’area.

2.4.5.5 Confronto Il sistema GPS si contraddistingue per una precisione più elevata rispetto agli

altri metodi di localizzazione. È caratterizzato, infatti, da un margine d’errore nell’ordine dei 10-20 metri, a differenza dei 150-1000 metri dei metodi basati su rete telefonica.

D’altra parte un grosso svantaggio del sistema GPS consiste nell’inutilizzabilità in ambienti chiusi. Sia il sistema basato su rete telefonica che il WPS invece sono applicabili anche in ambienti chiusi, a condizione che sia presente la copertura di rete, telefonica nel primo caso e Wi-Fi nel secondo.

Infine, l’uso del GPS comporta un maggiore consumo energetico, aspetto particolarmente sensibile nei dispositivi mobili, anche se notevolmente ridotto nella variante A-GPS.

Alla luce di queste considerazioni risulta evidente come la scelta del metodo di localizzazione da utilizzare dipenda dal particolare scenario applicativo e dal contesto d’uso a cui è destinato. Se in alcuni casi un particolare metodo risulterà più idoneo degli altri, in altri casi sarà più opportuno utilizzarne una combinazione, o verificare quale è più appropriato a seconda delle condizioni operative.

2.5 - Conclusioni Nel corso del capitolo abbiamo analizzato le caratteristiche che

contraddistinguono lo scenario dei dispositivi mobili, principalmente la mobilità e la comunicazione wireless. Vi sono diverse tecnologie di comunicazione wireless afferenti a diversi ambiti: quello delle reti cellulari, come UTMS e la rete di nuova generazione LTE, quelli delle reti LAN, WAN e PAN come WiFi, Bluetooth e ZigBee. L’instabilità della connessione che caratterizza lo scenario mobile ci ha spinto ad esaminare i sistemi basati su scambio di messaggi, data le loro capacità di conferire maggiore disaccoppiamento. Sistemi quali JMS o REST rappresentano esempi di sistemi che permettono di ottenere questa caratteristica. Infine lo scenario del mobile sensing rappresenta un ambito di ricerca in continua evoluzione. Gli sforzi di ricerca hanno dato diversi contributi in merito a criticità quali l’efficienza energetica e computazionale delle operazioni di sensing. A seconda delle necessità e dei requisiti applicativi è applicare la rilevazione dei dati su base individuale o applicare meccanismi di aggregazione su gruppi di utenti o su intere comunità, con paradigmi di tipo partecipativo o opportunistico. La posizione dell’utente inoltre rappresenta un’informazione importantissima non solo nei servizi location-based, e che può essere ottenuta tramite diverse tecnologie ognuna delle quali presenta vantaggi e svantaggi da valutare in base alle necessità applicative.

3 - Piattaforme per dispositivi mobili

I dispositivi mobili odierni appartengono, come descritto nel capitolo precedente, a una terza generazione di dispositivi, e sono dotati di hardware molto evoluto e potente rispetto alle generazioni, partendo innanzitutto da processore e memoria, alle interfacce di rete per la connettività, ai sistemi di posizionamento e i sensori. A ciò corrisponde una complessità altrettanto elevata anche dal punto di vista software, dato che questi dispositivi sono capaci di offrire servizi complessi e avanzati se confrontati con i micro-browser che avevano caratterizzato la generazione precedente. Ciò è reso possibile indubbiamente da complesse piattaforme software che si occupano da una parte di gestire il complesso hardware dei dispositivi, dall’altra di offrire alle applicazioni una serie di funzionalità e servizi di alto livello su cui appoggiarsi. Alcuni di questi rappresentano veri e propri sistemi operativi, come ad esempio Android, ed eseguono direttamente sopra l’hardware del dispositivo, altri invece si appoggiano sul sistema operativo preesistente e giocano quindi il ruolo di middleware, come J2ME. In ogni caso queste piattaforme rappresentano un elemento caratterizzante del dispositivo, in quanto incidono notevolmente sia sulle prestazioni del sistema e sia sulle caratteristiche delle applicazioni che ospitano.

Sono molte le piattaforme che sono state sviluppate nel corso del tempo, ma non tutte hanno avuto lo stesso successo. Al momento il mercato è conteso da un cerchio ristretto di grandi player, che costituiscono i sistemi che troviamo installati sulla maggior parte dei dispositivi in commercio. I sistemi più diffusi sono Android, iOS, Symbian, RIM e Microsoft e sono rappresentati in Figura 23 con le relative quote di mercato (fonte Gartner 2012) [SIN12].


70

Figura 23 - Quota di mercato globale dei più diffusi sistemi operativi per dispositivi mobili

Il sistema Android, nato nel 2008, ha riscosso da allora sempre più successo tanto da divenire il primo player globale con una quota del 56,1%. Si tratta di un sistema operativo open source il cui marchio è attualmente di proprietà di Google Inc. Diverse le case produttrici che lo hanno scelto come sistema operativo per i loro dispositivi: Samsung, HTC, LG, Motorola. Il sistema iOs è sviluppato da Apple Inc. per i propri dispositivi smartphone e tablet, rilasciato con licenza proprietaria è attualmente al secondo posto con una quota di mercato del 22.9%. Segue Symbian con l’8,6%, il sistema sviluppato da Nokia, un tempo player incontrastato del mercato, ha perso nel corso del tempo una larga fetta a favore dei suoi concorrenti. BlackBerry OS è il sistema operativo proprietario installato dagli omonimi dispositivi sviluppati dall’azienda canadese Research In Motion (RIM), detiene una quota pari al 6.9%. Infine Windows Phone, il sistema sviluppato da Microsoft con licenza proprietaria, evoluzione dei precedenti Windows Mobile e Windows CE, detiene una quota inferiore al 5% ed è utilizzato da alcuni modelli di marchio Samsung, HTC e LG.

Nel corso del capitolo analizzeremo le caratteristiche delle singole piattaforme, al fine di poterne valutare pregi e difetti, per poi focalizzare l’attenzione su quella che riteniamo più idonea.

3.1 - Piattaforme software Una piattaforma software mobile è definita come la combinazione di un sistema

operativo, compatibile con un certo insieme di dispositivi mobili, cui si aggiungono poi diverse librerie, application programming interface (API) e strumenti di sviluppo. Una piattaforma rappresenta quindi una soluzione completa per il supporto e lo sviluppo di applicazioni su dispositivi mobili.

Vi possono essere sia piattaforme proprietarie, indirizzate a dispositivi specifici, oppure piattaforme aperte a tutti i produttori hardware e software. Con l’avanzare delle tecnologie hardware, della potenza di elaborazione, e della connettività wireless, i sistemi operativi devono essere in grado si sfruttare al meglio queste risorse e fornire un supporto adeguato allo sviluppo delle applicazioni. In questa sezione faremo


71

riferimento a sei piattaforme per dispositivi mobili che rappresentano quelle più affermate e diffuse nel mercato: Symbian OS, Windows Mobile, J2ME, iOS e Android.

Come già accennato, J2ME non è una vera e propria piattaforma software ma un’ambiente di esecuzione che fa si appoggia su un sistema operativo sottostante e permette l’esecuzione di applicazioni Java. Ad ognuna di queste piattaforme è inoltre associato un insieme di strumenti che permettono lo sviluppo di software, cioè un software development kit. RIM Blackberry è una piattaforma proprietaria disponibile sono su dispositivi prodotti dalla casa RIM, e non sarà trattata in questa sede. Symbian OS è un sistema operativo sviluppato da Symbian risalente al 2005 che dopo l’abbandono da parte di Nokia non è più supportato da alcun produttore di dispositivi mobili.

3.1.1 Java ME Nonostante non sia un vero e proprio sistema operativo, Java Micro Edition

(Java ME, o in precedenza J2ME) può essere utilizzato in combinazione con gli altri sistemi operativi per ottenere portabilità e migliorare la sicurezza. In questo senso Java e in particolare Java ME agisce come livello intermedio tra uno specifico sistema operativo e le applicazioni a valore aggiunto.

3.1.1.1 Introduzione a Java La definizione di Java in senso stretto è quella di un linguaggio

multipiattaforma e object-oriented, sviluppato da Sun Microsystem. Alla base di Java troviamo un insieme di macchine virtuali dette Java Virtual Machine (JVM) per differenti piattaforme che si occupano di fornire un ambiente di esecuzione standardizzato e di interpretare il codice compilato (Java Bytecode), dove con la nozione di piattaforma si fa riferimento all’hardware di una macchina e al suo sistema operativo. Le applicazioni Java eseguono all’interno di un ambiente detto Java Runtime Enviroment che consiste della JVM e della piattaforma sottostante, delle librerie base, e alcuni file di supporto.

Il codice sorgente Java è compilato in bytecode indipendente dalla specifica piattaforma che viene interpretato dalla JVM specifica per una certa piattaforma, secondo il paradigma detto “compile once, run everywhere”. Una critica mossa a questo linguaggio, come linguaggio interpretato, è quello di essere considerevolmente più lento dei linguaggi che generano codice nativo specifico di una piattaforma. Per migliorare le prestazioni la JVM offre la tecnologia Just-In-Time (JIT) che carica il bytecode e lo compila in codice nativo appena prima che il codice sia eseguito.

Oltre all’indipendenza dalla piattaforma e al paradigma object-oriented altre caratteristiche importanti sono quella di fornire un ampio insieme di librerie standard e di terze parti, il supporto al multithreading e alla sincronizzazione, la gestione automatica della memoria e del garbage colletion, il supporto all’internazionalizzazione.


72

Java Standard Edition rappresenta la soluzione pensata per i dispositivi desktop, mentre Java Enterprise Edition amplia Java SE con un insieme di strumenti per lo sviluppo di applicazioni enterprise stratificate basate su componenti.

Java Micro Edition è invece una specifica che raccoglie un sottoinsieme della piattaforma Java, e mira a fornire un insieme di API Java standardizzate per lo sviluppo di software sui dispositivi con risorse limitate. S’indirizza quindi a dispositivi sia di consumo che industriali, dispositivi per la sicurezza, per la difesa, per il multimedia etc.

3.1.1.2 Configurazioni La piattaforma ha un’architettura stratificata, come mostrato in Figura 24.

Esistono diverse configurazioni che determinano la virtual machine e le librerie principali. Le più conosciute sono Connected Device Configuration (CDC) e Connected Limited Device Configuration (CLDC). Il primo è per dispositivi di fascia alta come gli smart phone mentre il secondo è pensato per dispositivi con capacità più ristrette in termini di risorse energetiche, computazionali, di memoria e di connettività, come cellulari e sensori wireless. Alle configurazioni si aggiungono poi i profili, che definiscono le API addizionali per le applicazioni. Il profilo più comune è il Mobile Information Device Profile (MIDP), indirizzato ai dispositivi mobili. Un altro profilo conosciuto è il Personal Profile, che mira ai prodotti di consumo e i dispositivi integrati.

Figura 24 - Panoramca di J2ME.

3.1.1.3 Connected Device Configuration La Connected Device Configuration (CDC) è un sottoinsieme di Java Standard

Edition che include quasi tutte le librerie non relative all’ambiente grafico. A differenza di CLDC, dispone di un insieme molto più ampio di librerie. I profili più usati con questa configurazione solo il Foundation Profile, il Personal Basis Profile, e il Personal Profile.

Il Foundation Profile è concepito per essere usato da dispositivi che richiedono un’implementazione completa della Java Virtual Machine e che includono l’interno insieme di API Java SE. Il Personal Basis estende il Foundation Profile per fornire un


73

supporto leggero all’interfaccia grafica. Il Personal Profile infine include un supporto ulteriore alle funzionalità GUI basate su AWT e alle applet.

3.1.1.4 Connected Limited Device Configuration La Connected Limited Device Configuration (CLDC) contiene un sottoinsieme

delle librerie Java. È specificatamente progettato per dispositivi con memoria, capacità computazionale e grafica limitata. A causa di queste limitazioni non può essere utilizzata la JVM standard, ed è quindi utilizzata una versione di macchina virtuale (detta KVM) più semplice e leggera, specifica per questo tipo di dispositivi.

Il Mobile Information Device Profile è concepito per i cellulari e include le librerie fondamentali. Le applicazioni basate su questo profilo sono dette MIDlet. L’Information Module Profile (IMP) è invece un profilo per dispositivi integrati che non dispongono di uno schermo. Il primo dispositivo tascabile che utilizzava MIDP 1.0 venne distribuito sul mercato nel 2001 e permetteva di scaricare MIDlet da siti web ed interagire attraverso un’interfaccia più ricca rispetto ai normali dispositivi portatili. Tuttavia MIDP presentava limitazioni nell’accesso al supporto di archiviazione e alle funzionalità audio e di visualizzazione, e prevedeva esclusivamente interazioni HTTP. La versione 2.0 cerca appunto colmare queste lacune e aggiungeva supporto al multimedia, al gaming e alla sicurezza. Infine la versione 3.0, o anche MIDP3, è supportata sia nella configurazione CLDC e CDC e permette il multitasking e la comunicazione tra MIDlet (InterMIDlet). Sono state inoltre realizzate un elevato numero di estensioni opzionali (dette Java Specification Request, o JSR) per aggiungere specifiche caratteristiche e funzionalità, come ad esempio per la localizzazione, i web services, la grafica 3D, metodi di pagamento, supporto ai sensori, streaming multimediale etc.

Complessivamente quindi Java ME rappresenta una piattaforma abbastanza versatile per lo sviluppo di applicazioni in ambito mobile. Se le prime applicazioni MIDP erano basate su un insieme di librerie molto ristretto, le versioni successive e le estensioni offrono supporto a molte funzionalità.

3.1.2 Symbian OS Symbian OS è un sistema operativo aperto per dispositivi mobili sviluppato

dall’omonima azienda Symbian. Inizialmente, Simbyan fu fondata da Nokia, Ericsson, Motorola, Matsushita e Psion come join venture con l’obiettivo di trasformare un sistema operativo proprietario in uno standard aperto. Uscito nel 2001, nel 2005 era utilizzato 48 diversi dispositivi, all’epoca si parlava ancora di telefoni cellulari piuttosto che smart phone, registrando vendite pari a 32 milioni di unità. Tuttavia dopo l’abbandono da parte di Nokia, il 27 gennaio 2013, non è al momento più utilizzato da alcun produttore di dispositivi mobili. Era originariamente basato sul sistema operativo EPOC ed era usato principalmente su PDA sviluppati da Psion. L’ultima versione rilasciata è Nokia Belle, appartenente alla generazione Symbian^3, in cui vengono introdotte nuove caratteristiche relativamente all’architettura grafica 2D e 3D e altri miglioramenti dell’interfaccia grafica.


74

Symbian OS è progettato per supportare un ampio spettro di servizi della generazione cellulare 3G. Le più comuni sono il supporto alla navigazione Internet, registrazione, riproduzione e streaming di formati multimediali, Bluetooth, supporto alla suite TCP/IP, sicurezza e certificati. Symbian OS supporta processori ARM e l’emulazione x86. In Figura 25 è rappresentata l’architettura complessiva del sistema.

Figura 25 - Architettura di Symbian OS.

Il kernel è un sistema multithread e real-time che si occupa della gestione della memoria, dello scheduling dei thread, della comunicazione tra processi, della gestione delle risorse relative ai singoli processi e ai singoli thread, ed esegue in maniera natica sul core ARM.

I servizi di base forniscono un framework di sviluppo di componenti Symbian, driver per i dispositivi, accesso al file system, e librerie standard C++. Sulla base dei servizi basilari troviamo un insieme di servizi per la comunicazione, il multimedia, la connettività, e altri servizi generici. I servizi di comunicazione gestiscono l’accesso alla rete di telefonia mobile e a reti LAN, PAN (in questo caso Bluetooth) e MAN. I sevizi di multimedia riguardano la registrazione, la riproduzione e lo streaming di contenuti multimediali. I servizi di connettività al PC permettono la sincronizzazione con questi. Infine i servizi generici offrono funzionalità comuni come la gestione della memoria e l’accesso al file system. I servizi applicativi permettono ai programmi utente di essere eseguiti in servizi separati. Il framework grafico è formato da un insieme di componenti di User Interface e di un meccanismo di gestione degli eventi che permette la gestione semplificata dell’interfaccia. Fornisce inoltre supporto alle applicazioni J2ME gestendo un piccolo ambiente di esecuzione Java.

3.1.3 iOS iOS è il sistema operativo proprietario sviluppato dall’azienda Apple Inc. per le

serie di dispositivi iPhone e iPod Touch, e deriva dal sistema operativo per sistemi desktop Mac OS X, a sua volta fondato su Darwin.

Il sistema iOS, rappresentato in Figura 26, è basato su 4 livelli: Core OS, Core Services, Media e Cocoa Touch. Il livello Core OS include il kernel OS X, lo stack


75

TCP/IP per la comunicazione di rete, la gestione dell’alimentazione e del file system, e la sicurezza. Il livello Core Services include le API si OS X intermedie tra i livelli Media e Cocoa Touch e il livello Core. Queste includono librerie per la comunicazione in rete, la gestione dei thread, e per i web service. Inoltre, fornisce un database di tipo SQLite a il supporto alla geolocalizzazione. Il livello Media è relativo alla riproduzione e alla registrazione di audio e video e al supporto alle animazioni. Infine il livello Coco Touch supporta gli eventi e il controllo multi-touch.

Figura 26 - Panoramica di iOS.

L’interfaccia grafica è infatti basata su multi-touch gestures, cioè movimenti standardizzati che possono essere utilizzati per interagire con l’interfaccia touch-screen. Inoltre, tramite gli accelerometri interni la rotazione del dispositivo altera l’orientazione dello schermo. Apple fornisce il SDK gratuitamente ma il rilascio del software e la pubblicazione sull’Apple Store, il market-place ufficiale, è soggetto all’approvazione dell’azienda e al pagamento di una quota. Il download delle applicazioni dall’Apple Store può essere gratuito o a pagamento a seconda dei casi.

In Figura 27 è rappresentata una panoramica dell’architettura Mac OS X, che è stata adattata per l’architettura iOS. Il sistema iOS è costruito su processore ARM e il Core OS (Darwin) include il kernel XNU e le funzionalità base di sistema. Il kernel XNU, un ibrido che combina il microkernel Mach 3 e diversi elementi della distribuzione Unix BSD, include il supporto POSIX e il supporto alla comunicazione di rete, al file system e ai driver dei dispositivi. Al di sopra del kernel abbiamo le funzionalità base di sistema. Sul kernel si poggia il middleware che ha una struttura stratificata composta dai livelli Core Service, Application Service, API, e infine l’interfaccia grafica, Aqua. Nel livello API troviamo cinque librerie molto importanti per lo sviluppatore: Carbon, Quicktime, BSD/Posix, Classic e Cocoa. Il supporto a Java è mostrato in figura ma non includo in iOS. Carbon consiste di una serie di gestori indipendenti per il file system, le risorse, i font, e gli eventi. La specifica POSIX definisce delle interfacce molto importanti per il sistema operativo, e una libreria di threading supportata dalla maggior parte dei sistemi moderni. Si divide nel Kernel API, Commands, Utilities e Conformance Testing. Il Kernel API include servizi real-time, thread, sicurezza, accesso remoto a file, e comunicazione tra processi remoti. Classic è una libreria per la retro-compatibilità non più supportata nelle versioni correnti. Cocoa Touch fornisce un layer di astrazione per l’iOS, ed è basato su un ambiente object-oriented e sui principi del Model-View-Controller.


76

Figura 27 - Panoramica di Mac OS X.

3.1.4 Windows Mobile & Windows 8 Microsoft ha proposto nel corso del tempo diverse soluzioni per l’ambito

mobile. La serie di piattaforme Windows Mobile, basate su piattaforma Windows Compact Edition (Windows CE), sono state sostituite dopo la versione 6 dal sistema Windows Phone 7, radicalmente diverso e non compatibile con i precedenti seppure ancora basato su Windows CE. Un ulteriore passo è stato compiuto nello scorso ottobre 2012 quando ha presentato il sistema Windows Phone 8, non più basato su Windows CE ma piuttosto su Windows NT.

Analizzeremo quindi prima le soluzioni Windows Mobile in quanto la maggior parte dei dispositivi con sistema Windows presenti sul mercato adotta ancora le versioni Mobile o Phone 7, per poi concentrarci sulla nuova soluzione Windows Mobile 8.

3.1.4.1 Windows Mobile e il .NET Compact Framework L’ultima versione di Windows Mobile basata su Windows CE, Windows

Mobile 6, è stata rilasciata nel 2007. Inizialmente il sistema era stato rilasciato con tre diverse versioni, per smartphone, per PDA con funzionalità di cellulare e per PDA classici, che sono andate poi ad unificarsi con la convergenza dei 3 diversi ambiti. Era basato sul sistema operativo Windows CE 5.0 e lo sviluppo del software era supportato tramite Visual C++ o il .NET Compact Framework. L’architettura complessiva è una combinazione del sistema operativo, le API Win32, strumenti per lo sviluppo software, e un set di applicazioni standard.

Come mostrato in Figura 28, alla base dell’architettura Windows Mobile e direttamente sopra l’hardware troviamo il sistema operativo Windows CE, progettato per supportare dispositivi con capacità ridotte quali PDA, telefoni cellulari,


77

smartphone, dispositivi integrati etc. Il .NET Compact Framework fornisce le funzionalità per sviluppare le cosidette “managed application”, tuttavia è supportato anche lo sviluppo tradizionale tramite le API Win32. Il Framework .NET rappresenta il cuore dell’infrastruttura di molti sistemi basati su Windows, e consiste di due componenti: il Common Language Runtime e le librerie .NET. Il primo rappresenta un livello intermedio tra le applicazioni .NET e il sistema operativo sottostante. Gli sviluppatori possono scegliere tra una vasta schiera di linguaggi supportati tra cui C, C++, C# e Visual Basic. Le applicazioni sono poi compilate in un linguaggio intermedio (IL). Al momento dell’esecuzione, il CLR esegue una compilazione just-in-time per generare il codice nativo relativo al sistema operativo utilizzato. In un certo senso agisce in modo analogo alla JVM nel caso Java, offrendo inoltre servizi di garbage collection, gestione delle eccezioni e della sicurezza. Per i dispositivi mobili è stata sviluppata una particolare versione del Framework .NET, il .NET Compact Framework, con un CLR ridotto e più efficiente e le librerie che costituiscono un sottoinsieme (circa il 30%) di quelle standard. I vantaggi di questo approccio sono, come nel caso Java, un ambiente di esecuzione più sicuro e maggiore portabilità, a scapito però delle prestazioni. Inoltre in questo caso la garbage collection contribuisce ulteriormente a degradare le prestazioni. Il CLR consiste di tre componenti: le librerie, il motore di esecuzione, e il livello di adattamento alla piattaforma. Il primo fornisce le classi e le interfacce sulla base delle quali vengono realizzate le applicazioni in .NET. Il motore di esecuzione è il nucleo del CLR poiché fornisce i servizi fondamentali necessari all’esecuzione delle applicazioni, come ad esempio il class loader e il garbage collector. Infine il Platform Adaptation Layer (PAL) fornisce un livello di astrazione dal livello sottostante permettendo la portabilità delle applicazioni, e mappa le invocazioni del motore di esecuzione in funzioni del sistema operativo.

Figura 28 - Panoramica di Windows Mobile.

Windows Phone 7, pur essendo basato su una architettura analoga, presenta notevoli vantaggi rispetto alle versioni precedenti Windows Mobile sia a livello di kernel che a livello utente. Il kernel Windows CE 7 infatti offre supporto ai sistemi multi-core, connettività WiFi, la tecnologia Bluetooth e notevoli miglioramenti per in termini di multimedia. Esegue inoltre su processore ARMv7. Dal punto di vista utente, aggiunge il supporto al miltitouch e agli schermi capacitivi, e presenta una nuova


78

interfaccia grafica migliorata. Integra supporto per i social network e una nuova versione di Internet Explorer, oltre che una edizione Mobile di Microsoft Office.

3.1.4.2 Windows Phone 8 Windows Phone 8 rappresenta il capostipite di una seconda generazione di

sistemi operativi per dispositivi mobili di casa Microsoft. Rilasciato il 29 ottobre 2012, apporta dal punto di vista architetturale due importanti cambiamenti strettamente correlati tra loro: il passaggio dal kernel Windows CE a kernel Windows NT e l’abbandono del .NET Framework.

Innanzitutto, Windows Phone 8 utilizza un kernel Windows NT, lo stesso utilizzato anche per la versione desktop del sistema operativo, Windows 8, contribuendo così a colmare il divario tra i due scenari, mobile e desktop. Non solo, oltre al kernel le due versioni condividono le librerie Windows Core, responsabili di file system, gestione multimedia, driver dei dispositivi, e alcune parti del modello di sicurezza. Il kernel offre inoltre nuove funzionalità come il supporto a processori multi-core, dispositivi criptati e schede rimovibili microSD. Altro elemento importante, come è possibile notare in Figura 29, l’architettura .NET Compact Framework e le API Win32 sono sostituite da Windows Runtime (WinRT), un insieme di API che fornisce l’accesso al kernel sottostante che supporta lo sviluppo di applicazioni native in diversi linguaggi come C, C++, e addirittura JavaScript. L’approccio dell’esecuzione nativa permette un notevole miglioramento delle performance e, essendo utilizzato anche nell’architettura desktop, favorisce la condivisione dei componenti.

Notevoli miglioramenti anche dal punto di vista della GUI, con supporto a nuove risoluzioni e l’innovativa interfaccia Metro. Altro elemento d’innovatività è il supporto alla tecnologia Near Field Communication (NFC), una tecnologia che fornisce connettività wireless a corto raggio (max 10 cm) ideata per effettuare pagamenti tramite i dispositivi mobili.

Figura 29 - Panoramica di Windows Phone 8.

3.1.5 Flash Lite Flash Lite è stato introdotto come alternativa leggera ad Adobe Flash Player,

appositamente pensata per lo scenario dei dispositivi mobili. Adobe Flash Player è un


79

software grafico usato nell’ambito della multimedia, per lo streaming di contenuti audio e video e per la creazione di applicazioni web particolarmente avanzate e interattive, le cosiddette Rich Internet Application. Flash Lite mira a portare su dispositivi con risorse limitate questo stesso tipo di esperienza e d’interazione. È implementato sul lato client, in particolare nel livello di interfaccia utente e compete quindi con altre tecnologie come ad esempio JavaFX di Sun Microsystem e può essere visto anche come una tecnologia alternativa a Java ME.

Flash Lite 1.1 supporta la tecnologia Flash 4 ActionScript, mentre Flash Lite 2.0, che è basato su Flash Player 7, supporta il più recente Action Script 2.0. Tutte le versioni supportano lo standard W3C Scalable Vector Graphics (SVG) Tiny, un profilo per ambiente mobile delle specifiche SVG, tecnologia per la visualizzazione di oggetti con grafica vettoriale. Flash Lite 3 è basato su Flash 8, che supporta lo standard video H.264 e i contenuti Flash Video (FLV). Flash Video è il nome di un formato usato per distribuire video su Internet usando Adobe Flash Player, adottato da YouTube, Google Video e Yahoo! Video.

3.1.6 Android Lo sviluppo del sistema Android inizia nel 2005 quando Google Inc. acquisisce

una piccola società che si occupava dello sviluppo di software per dispositivi mobili, di nome Android Inc., con l’obiettivo di entrare nel settore mobile, già popolato da numerosi player quali Apple, Microsoft, Symbian e RIM. Nel novembre 2007 si ha la prima presentazione del sistema Android, contestualmente alla nascita dell’Open Handset Alliance (OHA) [OHA07], un’alleanza strategica tra Google e altre 35 importanti aziende del settore tra cui Texas Instruments, HTC, Intel, Motorola, Samsung, T-Mobile, Vodafone, Telecom Italia e Ebay con lo scopo di sviluppare standard aperti per dispositivi mobili. La prima versione del sistema è stata rilasciata nel settembre 2008, mentre un mese dopo, ottobre 2008, è immesso sul mercato il primo smartphone dotato di Android: l’HTC Dream. Da allora ha riscosso un successo sempre maggiore che lo ha portato, a partire dal 2010, a diventare il sistema operativo per dispositivi mobili più diffuso sul mercato.

Le caratteristiche peculiari del sistema Android sono la natura open source e la sua struttura basata su kernel Linux. È distribuito sotto i termini di licenza Apache 2.0, il cui unico obbligo è la dichiarazione di un’informativa nelle parti sono state modificate.

3.1.6.1 Architettura La piattaforma Android comprende, oltre al sistema operativo, un middleware

di supporto e alcune applicazioni basilari per l’utilizzo del dispositivo. La struttura complessiva, mostrata in Figura 30, comprende 5 livelli: il kernel e gli strumenti di basso livello, le librerie native, l’ambiente di esecuzione Android Runtime, il layer di supporto alle applicazioni Application Framework, e infine il livello applicativo vero e proprio [AND00].


80

Figura 30 - L'architettura della piattaforma Android.

Il kernel usato è basato sul kernel Linux 2.6, modificato viste le particolari esigenze riguardo la gestione della batteria, della memoria e dell’ambiente di esecuzione. Mette a disposizione le funzionalità di basso livello quali i driver dell’hardware presente sul dispositivo mobile, la gestione della memoria, la gestione dei processi, le funzionalità di rete, la sicurezza.

Android Runtime contiene due particolari librerie che forniscono il supporto a tempo d’esecuzione. In particolare la Core Library fornisce le funzionalità fondamentali del nucleo del linguaggio di programmazione Java. La Dalvik Virtual Machine (DVM) invece è una particolare Virtual Machine, sviluppata da Google e ottimizzata per il particolare ambiente di esecuzione rappresentato dai dispositivi mobili.

Le librerie, scritte in linguaggio C/C++, mettono a disposizione dei componenti del livello superiore una serie di funzionalità di base, come la riproduzione di contenuti multimediali di tipo audio e video, il motore per la grafica 2D e 3D, un motore per i web browser, un database relazionale (SQLite) per la memorizzazione di informazioni disponibile a tutte le applicazioni.

L’Application Framework, in linguaggio Java, definisce la struttura e i componenti di cui dovranno essere costituite le applicazioni. In particolare è concepito per promuovere e semplificare il riuso dei componenti, permettendo alle applicazioni di pubblicare le loro funzionalità in modo che possano essere richieste da altri. Fornisce inoltre l’accesso sia alle librerie native e alle funzionalità della macchina virtuale sottostante, sia ad un insieme di servizi di supporto, tra cui:

1. un insieme di viste preconfigurate da combinare per creare in modo semplice interfacce grafiche elaborate;

2. componenti di supporto per la condivisione di informazioni tra applicazioni diverse;

3. un gestore delle risorse, che permette alle applicazioni di accedere a risorse di vario genere esterne al codice come stringhe localizzate, elementi grafici, icone etc.;


81

4. un gestore delle notifiche destinate all’utente, che possono essere comunicate sia tramite l’interfaccia grafica che tramite suoni o vibrazione del dispositivo;

5. un gestore delle schermate delle applicazioni per abilitare la navigazione dell’utente nello stack di attività;

6. un gestore dei sistemi di localizzazione.

Infine, il livello applicativo rappresenta il livello con cui si interfaccia normalmente l’utente e contiene una serie di applicazioni per funzionalità di uso comune come email, SMS, calendario, mappe, internet browser etc. Le applicazioni sono scritte in linguaggio Java.

3.1.6.2 Dalvik Virtual Machine Condizioni come le dimensioni ridotte della RAM, la lentezza delle CPU e

l’assenza di aree di memoria swap hanno spinto gli sviluppatori della piattaforma a optare per una propria Virtual Machine, alternativa alla Java Virtual Machine (JVM) prevista normalmente dal linguaggio Java.

Le differenze tra le due Macchine Virtuali sono diverse [HAN07][EHR10]:

1. la DVM utilizza un proprio bytecode, più compatto e ottimizzato per un’occupazione di memoria minore del Java byte code. Il byte code è rappresentato da particolari file, detti Dalvik Executable (estensione .dex), ottenuti dalla trasformazione dei Java Class file.

2. la memoria non viene gestita attraverso uno stack ma attraverso registri; ciò permette di ottenere un minor numero di istruzioni (circa il 30% in meno), in quanto le istruzioni di gestione dello stack non sono necessarie, e migliori performance su una macchina con memoria limitata;

3. l’esecuzione di molteplici macchine virtuali è ottimizzata; in particolare, mentre nella JVM anche le aree di memoria di sola lettura sono replicate per ogni istanza di macchina virtuale, nella DVM le aree di memoria di sola lettura vengono condivise, riducendo il consumo di memoria; ciò permette di eseguire ogni applicazione Android in una istanza differente di DVM senza compromettere le performance;

4. la DVM sfrutta il kernel Linux per alcune funzionalità come il threading e la gestione a basso livello della memoria.

A partire dalla versione 2.2 del sistema Android inoltre la DVM è dotata del supporto per la Just In Time (JIT) compilation, per la traduzione dinamica a tempo di esecuzione del bytecode in codice macchina nativo.

3.1.7 Confronto Di seguito procederemo ad evidenziare alcuni aspetti caratterizzanti per poi

confrontare tra loro le diverse piattaforme. Data la natura fortemente proprietaria riteniamo opportuno scartare la piattaforma iOS, anche alla luce dei vincoli sul threading e sulla gestione dei sensori emersi in [MIL08].

Sebbene Java ME abbia una buona diffusione all’interno della comunità di sviluppatori, non realizza in pieno il paradigma “write once, run everywhere”.


82

L’ampia differenziazione delle architetture in termini di hardware (es. schermo, memoria, capacità di elaborazione, hardware aggiuntivo), software (es. diversi sistemi operativi, diverse versioni di API, differenti estensioni da utilizzare) e implementazione (es. interpretazioni differenti di uno standard, bug in alcune versioni) rende necessario realizzare versioni leggermente diverse di una stessa applicazione, dando luogo al fenomeno detto device fragmentation, che incrementa considerabilmente il costo del ciclo di sviluppo di un prodotto. Come abbiamo già accennato, inoltre, l’esecuzione di codice intermedio qual è il Java Bytecode implica generalmente un peggioramento delle prestazioni.

Il framework .Net può essere equiparato a Java ME per quanto riguarda la gestione dell’ambiente di esecuzione, l’elevato numero di librerie e di componenti disponibili per il riuso, e un insieme di API già noto in ambito .NET. Tutte queste caratteristiche semplificano la transizione dall’ambito desktop a quello mobile. Come per Java ME, anche in questo caso il Common Intermediate Language migliora la portabilità a discapito delle prestazioni. Windows Phone 8 migliora quest’aspetto, giacché permette l’esecuzione nativa delle applicazioni. Inoltre, la natura proprietaria della piattaforma permette di fare maggiori assunzioni sull’hardware e sul software sottostante, e realizzare quindi una maggiore integrazione con le funzionalità specifiche del dispositivo. Dall’altra parte, però, l’insieme di dispositivi indirizzato è ristretto, e gli strumenti di sviluppo necessitano il pagamento di una licenza.

Anche Flash Lite semplifica la migrazione dall’ambiente desktop a quello mobile, dato che le conoscenze in ambito di sviluppo Flash possono essere facilmente adattate a Flash Lite. Tuttavia si tratta di una piattaforma adatta perlopiù per applicazioni che fanno un uso intensivo di grafica e non si presta allo sviluppo di complete applicazioni stand-alone. Anche le prestazioni sono ridotte a causa delle complesse elaborazioni grafiche.

Android supporta un insieme relativamente ampio delle API Java SE, riducendo i costi di migrazione dall’ambiente desktop. In modo simile a Java ME, lo sviluppo delle applicazioni è supportato da popolari strumenti di sviluppo Java. Fornisce inoltre ampio supporto per la realizzazione di applicazioni modulari e orientate ai servizi. Anche in questo caso l’apertura della piattaforma, in combinazione all’elevato numero di versioni introdotte, può portare a pericoli di frammentazione.

Dal punto di vista della portabilità Java ME rappresenta sicuramente la soluzione migliore, seguito poi da Flash Lite. Anche Android dispone di ottime caratteristiche di portabilità che combinate alla vasta base di installazione e alle previsioni di sviluppo determinano sicuramente una posizione di privilegio. Per quanto riguarda Windows Mobile e Windows Phone 8, il carattere proprietario limita lo sviluppo ai dispositivi compatibili Windows. D’altra parte però Java ME presenta la problematica della frammentazione, che in Android è limitata grazie alla maggiore uniformità delle distribuzioni. In quanto a funzionalità, Java ME, Windows Mobile, Windows Phone, e Android forniscono tutti la possibilità di implementare applicazioni complete, mentre Flash Lite è limitato alle applicazioni grafiche. Tuttavia sono state riscontrate alcune limitazioni da parte di Windows Mobile e del .NET Framework CE come ad esempio nel supporto di gestione audio e dei sensori hardware. Infine, dal punto di vista delle performance, gli autori di [GAV11] hanno condotto esperimenti


83

prendendo in esame parametri come over-head di elaborazione, consumo di memoria e dimensione complessiva dell’applicazione, Java ME, Android e Windows Mobile hanno mostrato prestazioni simili, mentre Flash Lite è caratterizzato da un costo computazionale decisamente più elevato. Per quanto riguarda Windows Phone 8 non sono ancora disponibili dati sperimentali.

La valutazione delle piattaforme deve essere sicuramente effettuata anche in base al tipo di sistemi che s’intende realizzare. Ponendoci nell’ambito del mobile sensing, dove è necessario disporre di una piattaforma che permette l’accesso all’hardware del dispositivo in modo opportuno. È possibile scartare a priori Flash Lite in quanto non siamo orientati alla realizzazione di applicazioni di tipo grafico. Possiamo osservare che sia Java ME che Android rappresentano entrambe piattaforme aperte e basate sul un linguaggio largamente noto e diffuso qual è Java, e forniscono inoltre un ampio spettro di servizi di supporto e l’accesso alle funzionalità hardware del dispositivo. Sia Android che Java ME supportano infatti un numero molto elevato di sensori, che vanno sia dai più comuni come l’accelerometro, il giroscopio e la bussola sia ad altri ancora non presenti su molti dispositivi come termometro (interno ed esterno), sensore di umidità, sensore di luminosità etc. Il framework .NET CE, invece, rappresenta una piattaforma proprietaria, per cui l’accesso agli strumenti di sviluppo non è gratuito, e che presenta inoltre alcune limitazioni nell’accesso alle risorse dei dispositivi, come ad esempio nella gestione dell’audio. Supporta inoltre solo i sensori più comuni quali sono l’accelerometro, il giroscopio e la bussola, e ciò rappresenta una grave limitazione per il nostro ambito applicativo. Tornando a Java ME, dobbiamo poi considerare il problema della frammentazione, che non consente di sviluppare applicazioni realmente portabili su un insieme di dispositivi eterogenei. Questo fenomeno è inoltre ulteriormente accentuato nel caso dei sensori, poiché rappresentano apparati hardware molto eterogenei e dotati spesso di interfacce vendor-specific. Da questo punto di vista Android presenta caratteristiche di portabilità molto maggiori, offrendo un’interfaccia uniforme e completa per l’accesso alle risorse del dispositivo.

Queste caratteristiche, combinate con l’ampio successo registrato in questi anni, l’ampia fetta di mercato conquistata nello scenario dei dispositivi, e le previsioni più che ottimali di diffusione per il futuro, rendono Android la scelta più adatta ai nostri scopi. Ne deriva implicitamente il vantaggio di poter usufruire sia delle ampie conoscenze in ambito Java sviluppate nel corso degli studi e sia di una gamma di strumenti di supporto allo sviluppo gratuiti e ampiamente diffusi quali l’IDE Eclipse. Lo strumento di sviluppo ufficiale del sistema Android, infatti, l’Android Software Development Kit (ASDK), è fortemente integrato Eclipse. Questi due fattori contribuiranno indubbiamente a velocizzare e semplificare le fasi di sviluppo. Detto questo, nel corso delle sezioni successive scenderemo più nel dettaglio delle caratteristiche e delle funzionalità offerte dal sistema Android.

3.2 - La piattaforma Android Come abbiamo già accennato le caratteristiche peculiari del sistema Android

sono il carattere open source, il kernel Linux alla base, l’ambiente di esecuzione


84

ottimizzato della Dalvik Virtual Machine e un insieme di librerie e API che supportano un ampio spettro di funzionalità e tecnologie.

Android rappresenta attualmente il sistema operativo più diffuso sul mercato. La versione più recente, 4.2.2, appartenente alla famiglia “Jelly Bean” e risalente al 12 febbraio 2013 (storicamente tutte le versioni di Android sono denominate facendo riferimento a un famoso dolciume) sarà sostituita a maggio 2013 dalla nuova famiglia “Key Lime Pie”. La versione attualmente più diffusa tra i dispositivi presenti sul mercato è “Ginger Bread” (2.3) con il 45.6%, ma sistemi più recenti come “Ice Cream Sandwich” (4.0) e “Jelly Bean” (4.1) stanno registrando una forte crescita [DIM13]. Andando oltre i semplici numeri, si tratta di dati importanti in quanto ad ogni versione è associato un ben preciso API Level, cioè l’insieme di funzionalità messe a disposizione dello sviluppatore da parte del sistema operativo. Applicazioni sviluppate per un determinato API Level sono incompatibili con i livelli inferiori, e conoscere la diffusione delle differenti versioni sul mercato è un requisito fondamentale per garantire alle applicazioni una buona base di utenza.

In questa sezione procederemo, dopo aver enunciato le caratteristiche principali della piattaforma, a descrivere i principi fondamentali che guidano lo sviluppo delle applicazioni, per poi scendere nel dettaglio delle librerie che permettono l’accesso alle risorse del sistema riguardo due aspetti ritenuti molto importanti nell’ambito del mobile sensing: la localizzazione e l’uso dei sensori, per ovvi motivi, e in secondo luogo la tecnologia Bluetooth, che riteniamo interessante poiché può essere utilizzata per realizzare politiche di coordinamento e d’interazione tra utenti presenti in una stessa località.

3.2.1 Caratteristiche Di seguito saranno enunciate alcune caratteristiche generali del sistema

Android, confrontandole con quelle degli altri principali sistemi operativi.

3.2.1.1 Sicurezza Android eredita le politiche di sicurezza dal sistema Unix, in particolare il

meccanismo di controllo degli accessi alle risorse e la separazione tra processi. Il sistema di privilegi basato su GroupID (GID) e UserID (UID) è utilizzato per creare un ambiente isolato e separato per ogni applicazione in quanto:

1. ad ogni applicazione viene assegnato un proprio UID, e rappresenta quindi un utente Unix diverso; a tutte le risorse associate all’applicazione presenti sul file system viene assegnato lo stesso UID;

2. ogni processo esegue in una propria Virtual Machine; 3. ogni applicazione esegue in un proprio processo, creato dal supporto Android

quando uno dei suoi componenti deve essere eseguito.

In questo modo Android realizza la politica del minimo privilegio: ogni applicazione ha accesso esclusivamente ai componenti e alle risorse strettamente necessarie alla sua esecuzione.


85

Anche la gestione delle funzionalità di supporto segue la stessa politica: per default un’applicazione non ha alcun permesso associato. Ciò assicura che non gli sia possibile alcuna azione che possa compromettere l’esperienza dell’utente o i dati presenti sul dispositivo. Per accedere a dati e funzionalità protette, come la rete, i contatti dell’utente o il calendario, l’applicazione deve dichiarare staticamente (tramite il Manifest File, come verrà descritto in 3.2.2.2) di voler utilizzare determinati permessi. Al momento dell’installazione dell’applicazione l’utente deve esplicitamente accettare di concedere i permessi richiesti. Una volta installata, l’applicazione non può richiedere dinamicamente ulteriori permessi.

Un meccanismo analogo è previsto anche in altri sistemi operativi come Symbian, iOS e Windows Phone.

3.2.1.2 File system Le versioni di Android fino alla 2.2 adottavano il file system YAFFS [MAN12],

un particolare file system appositamente progettato e ottimizzato per memorie flash di tipo NAND e molto diffuso nel settore dei dispostivi mobili. Ha però lo svantaggio di non supportare l’accesso concorrente da parte di molteplici thread alla stessa partizione. Alla luce dell’imminente diffusione dei sistemi multi-core anche nell’ambito mobile, il team di sviluppo Android decise di abbandonarlo a partire dalla versione Android 2.3 in favore di EXT4 [MAT07], lo stesso file system utilizzato anche dal kernel Linux. A differenza di YAFFS, EXT4 gestisce garantisce l’accesso in mutua esclusione tra thread con una granularità più fine (in particolare a livello di file anziché di partizione), permettendo di sfruttare al meglio le potenzialità del multi-core.

3.2.1.3 Memory footprint Con memory footprint s’intende l’ammontare di memoria principale che un

programma, in questo caso un sistema operativo, usa mentre è in esecuzione, ed è un importante indicatore dell’impatto del programma sulle performance del sistema, specialmente nell’ambito dei dispositivi mobili in cui la memoria rappresenta una delle risorse più preziose.

Per il sistema Android tale valore si aggira intorno ai 250 KiloByte, contro i 280 di Windows Phone 8 e i 200 di Symbian OS.

3.2.1.4 Connettività La connettività rappresenta la capacità dei dispositivi di connettersi tra loro e

scambiare informazioni. Nell’ambito dei dispositivi mobili la connettività che risulta determinante è quella di tipo wireless, piuttosto che quella via cavo, e coinvolge sia reti di grandi dimensioni (Local Area Network, Wide Area Network), supportate da tecnologie quali Wi-Fi, GPRS e UMTS, che reti personali (Personal Area Network) tramite infrarossi o Bluetooth.

Android supporta tutte le più importanti tecnologie di connettività per la telefonia moible (GSM, GPRS, EDGE, UMTS, LTE), connessioni Wi-Fi, Bluetooth e Near Field Connectivity (NFC, tecnologia per comunicazioni in un raggio di pochi


86

centimetri tra il dispositivo e un tag NFC). La tecnologia a infrarossi è l’unica non supportata, che è invece presente in sistemi quali Windows Phone e Symbian OS.

3.2.1.5 Affidabilità L’affidabilità di un programma in generale consiste nella capacità di non

incorrere in errori e malfunzionamenti durante l’uso. È strettamente legato alla correttezza del codice che lo costituisce: più il codice è affetto da errori di programmazione, più c’è la probabilità che si verifichino condizioni di malfunzionamento.

Uno studio del Computer Science Research Center della Stanford University [DEL04] mostra come il kernel Linux 2.6 abbia, su circa 5,7 milioni di linee di codice totali, una percentuale di circa lo 0.00017% di linee contenenti “bug” di vario genere. Degli 895 bug totali, sono 569 quelle che possono provocare errori che compromettono il funzionamento del sistema. I sistemi commerciali invece riportano una media che va dallo 0.02% allo 0.03/, superiore quindi di ben due ordini di grandezza. Essendo Android basato su kernel Linux, si può considerare un sistema più affidabile rispetto agli altri in commercio.

3.2.1.6 Open source Android è fortemente orientato all’apertura, ed è perciò distribuito con licenza

Apache 2.0, che obbliga gli utenti a preservare l'informativa di diritto d'autore e d'esclusione di responsabilità nelle versioni modificate. Oltre ad essere open source, la piattaforma Android si distingue per il suo carattere di gratuità. Può essere infatti utilizzato dalle case produttrici di smartphone in modo assolutamente gratuito, a differenza ad esempio di Windows Phone per cui è richiesto l’acquisto di una licenza d’uso. Non solo, anche l’accesso al market-place delle applicazioni è gratuito, mentre Microsoft e Apple impongono agli sviluppatori il pagamento di una quota d’iscrizione per pubblicare le proprie applicazioni sul market-place.

Altro elemento caratterizzante, e strettamente connesso ai precedenti, è la portabilità. Android è progettato per essere utilizzato su una larga varietà di dispositivi, indipendentemente dalla casa produttrice, dal modello, dalla tipologia di dispositivo (smartphone, tablet, e-reader, pc-portatili etc.), a differenza ad esempio di iOS, che è pensato per essere distribuito solo su dispositivi con marchio Apple.

3.2.2 Principi applicativi Di seguito saranno dettagliate le principali caratteristiche delle applicazioni

Android e i componenti messi a disposizione dal framework per la loro costruzione, facendo riferimento a quanto descritto nella guida ufficiale relativo alla comunità di sviluppatori Android [AND02].

3.2.2.1 Introduzione Le applicazioni Android sono scritte nel linguaggio di programmazione Java, e

il loro sviluppo è ufficialmente supportato tramite l’Android Software Development Kit (Android SDK) e il relativo plug-in per l’IDE Eclipse. Un’applicazione Android è


87

contenuta all’interno di un archivio con estensione apk (Android PacKage), che include tutte le risorse necessarie alla sua esecuzione. Come descritto nel paragrafo 3.2.1.1, l’esecuzione di un’applicazione Android ha luogo all’interno di un ambiente isolato e separato dalle altre applicazioni.

I componenti applicativi sono i blocchi fondamentali di cui costituita un’applicazione Android, e rappresentano dei punti di ingresso tramite cui il sistema può accedere all’applicazione. Sono previste quattro diverse tipologie di componenti:

1. activity, una singola schermata dell’interfaccia grafica con cui l’utente può interagire;

2. service, un componente che esegue in background per portare a termine compiti di lunga durata;

3. content provider, componenti per la gestione di informazioni condivise tra applicazioni, siano esse presenti su un database locale o accedute tramite web;

4. broadcast receiver, componenti che rispondono a segnali broadcast inviati dal sistema o da altre applicazioni.

Un aspetto fondamentale del sistema Android è rappresentato dalla possibilità per una qualsiasi applicazione di utilizzare componenti di un’altra applicazione. Se ad esempio vogliamo che l’utente scatti una foto, è possibile sfruttare l’activity predisposta dall’applicazione di sistema, piuttosto che svilupparne una da zero. Quando è avviato un qualsiasi componente, viene creato, se non è già presente, anche il processo per l’applicazione associata. Ogni componente esegue sempre nel processo relativo alla propria applicazione, piuttosto che in quello che ne ha richiesto l’attivazione (maggiori dettagli a riguardo saranno dati nel paragrafo 3.2.2.7 - Processi e thread). Il fatto che componente chiamante e chiamato eseguano in processi differenti rende necessario il coinvolgimento del sistema Android all’interno del meccanismo di attivazione, attraverso la consegna di un opportuno messaggio detto intent al sistema. Un intent rappresenta un messaggio asincrono che permette di attivare e collegare tra loro componenti individuali che appartengono o meno alla stessa applicazione e può essere pensato come “un messaggio di richiesta, proveniente da un certo componente, a svolgere una particolare azione”. È creato tramite un oggetto di tipo Intent, specificando tramite una stringa la particolare azione richiesta. L’intent può essere consegnato al sistema, rappresentato dall’oggetto Context, tramite diversi metodi che si differenziano a seconda del tipo di componente da attivare: startService() per un service, startActivity() per una activity e sendBroadcast() per un broadcast receiver. Per quanto riguarda i content provider, piuttosto che tramite intent sono acceduti tramite un oggetto di tipo ContentResolver, che agisce da intermediario tra l’applicazione e il content provider.

Tutti i componenti contenuti all’interno dell’applicazione devono essere dichiarati all’interno di un file xml, detto manifest file, che contiene anche numerose informazioni sull’applicazione.


88

3.2.2.2 Manifest Ogni applicazione Android deve essere dotata di un file manifest nella sua

directory principale. Questo file contiene le informazioni essenziali ai fini dell’esecuzione dell’applicazione, tra cui:

• il nome del package Java dell’applicazione, che ne costituisce un identificativo univoco;

• la descrizione dei componenti che costituiscono l’applicazione (activity, service, content provider e broadcast receiver), specificando la particolare classe che li implementa e pubblicando le loro capacità, ovvero quali tipi di intent sono in grado di gestire;

• specifica quale processo ospiterà i diversi componenti dell’applicazione (maggiori dettagli a riguardo nel paragrafo 3.2.2.7);

• specifica i permessi necessari per accedere a librerie protette e interagire con altre applicazioni, tramite il tag <uses-permission>; ogni permesso è individuato da una etichetta univoca; ad esempio android.permission.INTERNET rappresenta il permesso per accedere alla connessione internet, mentre android.permission.VIBRATE è necessario per utilizzare la funzionalità di vibrazione del dispositivo;

• dichiara il minimo livello di API Level Android richiesto dall’applicazione; • specifica le librerie necessarie all’esecuzione, nel caso siano necessarie librerie

estranee a quella di default fornita da Android, tramite il tag <uses-library>; ad esempio, per poter utilizzare il servizio Google Maps [GOO02] è necessario dichiarare l’utilizzo della libreria com.google.android.maps.

3.2.2.3 Activity Un’activity rappresenta una singola schermata dell’interfaccia grafica con cui

l’utente può interagire per portare a termine una determinata operazione, come ad esempio scattare una foto, inviare un’email, o consultare una mappa. Tipicamente un’applicazione è formata da un insieme di activity, una (e solo una) delle quali costituisce la main activity, cioè quella deputata a essere mostrata all’utente all’avvio dell’applicazione. La realizzazione di un componente di tipo activity ha luogo estendendo la classe Activity fornita da Android.

Come accennato precedentemente, un’activity è attivata tramite l’invio di un intent, creato attraverso l’oggetto Intent che specifica l’azione da eseguire o la particolare activity da attivare. Ad esempio, per inviare una email, si specifica l’azione Intent.ACTION_SEND, mentre per attivare una specifica activity si indica direttamente la sua classe, ad esempio Intent intent = new Intent(this, SignInActivity.class). L’invio è effettuato tramite il metodo startActivity(intent). Nel manifest è possibile specificare da quali particolari intent può essere attivata un’activity, tramite l’uso degli intent filter, in cui sono indicate le action che possono essere richieste all’activity stessa. L’action predefinita main è usata per indicare che l’activity costituisce l’entry point dell’applicazione. Per terminare un’attività è invece disponibile il metodo finishActivity(), ma il suo uso


89

è sconsigliato in quanto la gestione del ciclo di vita delle activity è compito del sistema.

Le activity attive nel sistema sono gestite in modalità LIFO attraverso una pila, detta back stack: l’attivazione di una nuova activity ne provoca l’inserimento in cima al back stack, e la sua visualizzazione all’utente. Quando l’activity in cima al back stack termina, o è premuto il tasto Back, l’activity è rimossa dallo stack e distrutta, cedendo il posto a quella posta direttamente sotto nello stack. A seconda che un’activity sia cima allo stack, direttamente all’attenzione dell’utente (foreground), o sia passata in secondo piano (background) in seguito all’attivazione di un’altra activity, si possono individuare diverse fasi del ciclo di vita. In particolare un’activity può trovarsi negli stati:

• resumed, (detto anche running), se l’activity è in foreground; • paused, se l’activity non è in foreground ma è ancora parzialmente visibile, a causa

di un’activity che si trova in cima ma non occupa interamente lo schermo; l’activity è completamente attiva, tutto lo stato è conservato ed è ancora agganciata al gestore delle finestre, ma può essere terminata dal sistema in situazioni di estrema carenza di memoria;

• stopped, l’activity è completamente oscurata da un’altra activity; tutto lo stato viene mantenuto ma non è più agganciata al gestore delle finestre; nel caso il sistema debba recuperare memoria può decidere di terminarla.

Se un’activity è in stato paused o stopped, il sistema può terminarla sia tramite il metodo opportuno finishActivity() e sia tramite la terminazione del processo, causando quindi una perdita dello stato. Nel caso in cui sia nuovamente attivata deve essere quindi creata nuovamente. Per gestire opportunamente lo stato dell’activity riguardo questo tipo di eventi sono forniti una serie di metodi di callback, che permettono di individuare diverse fasi associate all’esecuzione dell’activity, illustrati in Figura 31:

• l’interno periodo di vita dell’activity è individuato dal periodo che intercorre tra l’invocazione del metodo onCreate() e onDestroy(); onCreate() è invocato all’atto della creazione dell’activity, e deve quindi essere utilizzato per inizializzare i componenti essenziali dell’activity; un’operazione molto comune è quella di inizializzare l’interfaccia grafica tramite il metodo setContentView(); nel metodo onDestroy(), che precede la distruzione dell’attività, è invece necessario rilasciare le risorse acquisite;

• il periodo di visibilità corrisponde al periodo in cui l’attività è visibile all’utente, ed è racchiusa tra l’invocazione del metodo onStart() e onStop(); in questo periodo l’attività è visibile all’utente, ma non necessariamente in foreground; è quindi necessario mantenere le risorse necessarie a mostrare l’activity all’utente, risorse che non saranno più necessarie quando l’activity non sarà più visibile in seguito all’invocazione di onStop(); nel caso in cui sia stato invocato onStop() e l’utente selezioni nuovamente l’activity si incorre nell’invocazione del metodo onRestart();

• il periodo di foreground, che intercorre tra l’invocazione del metodo onResume() e onPause(); in questo lasso di tempo l’activity è in primo piano ed è disponibile a


90

ricevere gli input dell’utente; un activity può entrare e uscire da questo stato molto frequentemente, e per questo motivo le operazioni svolte da questi metodi non devono essere troppo costose.

Figura 31 - Ciclo di vita di un’activity. I rettangoli in grigio rappresentano i metodi di callback.

3.2.2.4 Service Un Service è un componente Android deputato all’esecuzione in background di

operazioni di lunga durata, e che non è associato ad alcuna interfaccia con l’utente come, ad esempio la riproduzione di musica o l’esecuzione di una transazione sulla rete. Può essere avviato da un qualsiasi altro componente e rimane in esecuzione anche quando l’utente esce dall’applicazione per lanciarne un’altra. È possibile inoltre che un componente si leghi ad un servizio per la comunicazione tra processi, attraverso le API InterProcess Communication (IPC).

Uno stesso servizio può essere utilizzato in due differenti modalità. Un servizio è di tipo “started” o “avviato” quando è attivato tramite il metodo startService(). Una volta avviato il componente rimane in esecuzione in background per un tempo indefinito, indipendentemente dal componente che lo ha avviato. Si tratta invece di un servizio “bound” o “legato”, quando un altro componente invoca il metodo bindService(). Un bound service offre una interfaccia client-server che permette agli altri componenti di interagire inviando richieste e ottenendo risultati anche tra processi diversi, come nel caso IPC. Il servizio bound termina nel momento in cui il chiamante si slega dal servizio.

Dal punto di vista dell’implementazione la differenza è sottile poiché risiede solo nel differente metodo di callback da implementare: onStartCommand() nel primo


91

caso e onBind() nel secondo. In entrambi i casi si utilizza il meccanismo degli intent. Bisogna inoltre tenere presente che un service esegue normalmente nel thread principale del processo che lo ospita. Di conseguenza nel caso in cui esegua delle operazioni bloccanti o con elevato consumo di CPU è opportuno creare un thread dedicato. Maggiori dettagli riguardo il threading dati nella sezione 3.2.2.7.

Per creare un service Android è necessario estendere la classe Service, o una delle sue sottoclassi. L’implementazione deve inoltre definire alcuni metodi di callback, rappresentati in Figura 32 necessari a gestire opportunamente il ciclo di vita del servizio. I più importanti sono:

• onStartCommand(), che è invocato dal sistema quando un componente terzo richiama il servizio tramite il metodo startService(); dopo l’esecuzione del metodo il servizio è avviato e rimane in esecuzione fino all’invocazione di stopSelf() o stopService();

• onBind(), che viene eseguito quando un componente vuole legarsi al servizio invocando bindService(); il metodo deve fornire come parametro di ritorno un’implementazione dell’interfaccia IBinder che il client userà per comunicare, o null se non si vuole permettere di legarsi al servizio;

• onCreate(), che viene invocato alla prima creazione del servizio per eseguire l’inizializzazione e prima che siano invocate onStartCommand() o onBind();

• onDestroy(), che viene invocata quando il servizio non è più utilizzato e deve essere distrutto; deve essere quindi implementato per il rilascio delle risorse;

• onUnbind(), che viene invocato nel caso di bound service quando l’ultimo client si slega dal servizio tramite il metodo unboundService();

• onRebind(),invocato quando un client ha invocato bindService() dopo che onUnbind() è stato già invocato.

Figura 32 - Ciclo di vita di un service Android. I rettangoli in grigio rappresentano i metodi di callback.


92

Sulla base dei metodi di callback sopra descritti è possibile individuare diverse fasi relative al ciclo di vita di un service:

• l’intero periodo di vita, che è quello che intercorre tra l’invocazione dei metodi onCreate() e onDestroy(); in questo periodo tutte le risorse del servizio sono conservate;

• il periodo di attività, che inizia con l’invocazione del metodo onStartService() o onBind() all’interno dei quali è gestito l’intent passato rispettivamente a startService() e bindService(); nel caso di started service il periodo di attività termina con la distruzione del servizio stesso, mentre nel caso di bound service termina con la terminazione del metodo onUnbind().

3.2.2.5 Content provider Un content provider gestisce l’accesso a un repository centrale di dati

strutturati. In particolare è concepito per permettere a un’applicazione di mettere i propri dati a disposizione di altre applicazioni. L’applicazione che detiene i dati, ad esempio all’interno del proprio database privato, definisce un content provider cui le altre applicazioni possono accedere tramite i client. Il content provider rappresenta quindi l’interfaccia standard attraverso cui le altre applicazioni possono accedere ai dati privati di un’applicazione, gestendo la comunicazione tra processi differenti e l’accesso sicuro ai dati. Sottolineiamo il fatto che l’utilizzo di un content provider non è necessario nel caso in cui l’applicazione abbia come unico requisito quello di memorizzare i dati, senza alcuna necessità di condividerli con altre applicazioni. In questo caso è sufficiente utilizzare le funzionalità di persistenza descritte nel paragrafo 3.2.2.8.

Un content provider può esporre i dati contenuti al suo interno in due modalità: come file o come dati strutturati. Nel primo caso si tratta ad esempio di foto, file audio e video. All’atto della ricezione di una richiesta di accesso da parte di un’applicazione il provider fornisce un riferimento al file. La seconda modalità è rappresentata dai dati strutturati, cioè tabelle simili a quelle che troviamo in un database relazionale. In entrambi i casi la sorgente dei dati può essere rappresentata indifferentemente da: un database relazionale privato all’applicazione, dei file presenti sulla memoria di massa privata, o dati provenienti dalla rete. Inoltre, in entrambi i casi le risorse, siano esse tabelle o file, sono rappresentate da URI. La gestione degli URI è supportata dalla classe utility URIBuilder.

Per la creazione di un content provider è necessario estendere la classe astratta ContentProvider, fornendo un’implementazione per i seguenti metodi di accesso alle informazioni quali query(),insert() o update().

Il sistema Android fornisce inoltre alcuni content provider predefiniti per accedere a informazioni comuni sul sistema: il Contacts Provider, che raccoglie le informazioni riguardanti i contatti dell’utente, e il Calendar Provider, che costituisce un repository per gli eventi previsti nel calendario utente. Di seguito si analizzerà il Calendar Provider sia per fornire un esempio d’uso dei content provider e sia perché gli eventi previsti in agenda dall’utente rappresentano importanti informazioni di contesto.


93

3.2.2.6 Broadcast Receiver Un broadcast receiver è un componente Android che permette di registrarsi per

eventi applicativi o di sistema. Per un dato evento possono essere registrati molteplici receiver, che saranno tutti notificati all’atto del verificarsi dell’evento.

Un broadcast receiver è realizzato estendendo la classe Broadcast Receiver e registrando poi il componente nel file manifest dell’applicazione nell’elemento <receiver>, in cui si specifica la classe che lo implementa. In alternativa è possibile registrare dinamicamente un broadcast receiver tramite il metodo Context.registerReceiver(). La classe che implementa il broadcast receiver deve definire il metodo onReceive(), che rappresenta il metodo di callback invocato dal sistema Android ed in cui sono gestiti gli eventi.

Il tempo di vita di un broadcast receiver coincide con l’esecuzione del metodo onReceive(). Terminata l’esecuzione di questo metodo, il sistema Android considera l’oggetto inattivo e potrebbe quindi terminare il processo associato. Di conseguenza non è possibile l’esecuzione di operazioni asincrone, e lo svolgimento di operazioni di lunga durata dovrebbe essere delegata a un servizio dedicato.

I broadcast receivers sono sensibili alla ricezione degli intent. Per inviare un intent a un broadcast receiver è disponibile il metodo sendBroadcast(). Non è possibile inviare intent di sistema, ma è possibile definire degli intent filters, all’interno del file manifest, per rendere il broadcast receiver sensibile a particolari intent piuttosto che altri: <receiver android:name="com.example.MyReceiver" >

<intent-filter> <action android:name=

"com.example.intent.MY_INTENT" /> </intent-filter>

</receiver>

Nel sistema Android sono previsti diversi eventi generati automaticamente dal sistema, a ognuno dei quali è associato un particolare intent. I più importanti sono:

• android.intent.action.BOOT_COMPLETED, generato quando viene completata l’operazione di avvio del sistema; può essere quindi utilizzato per lanciare servizi all’avvio del sistema; richiede l’uso dei permessi android.permission.RECEIVE_BOOT_COMPLETED;

• android.intent.action.POWER_CONNECTED, generato quando il dispositivo è collegato ad una fonte di alimentazione;

• android.intent.action.POWER_DISCONNECTED, generato quando il dispositivo è disconnesso ad una fonte di alimentazione;

• android.intent.action.BATTERY_LOW, generato quando la carica di batteria scende sotto una certa soglia (circa il 15%);

• android.intent.action.BATTERY_OKAY, generato quando, in seguito all’evento precedente, la carica di batteria risale sopra la soglia.


94

Tali eventi sono molto importanti per realizzare meccanismi di gestione e ottimizzazione del consumo energetico, ad esempio riducendo l’impatto delle operazioni effettuate in caso di batteria scarica.

3.2.2.7 Processi e thread La gestione dei processi da parte del sistema Android prevede che ad ogni

applicazione sia associato un processo. Se un componente viene attivato, ad esempio tramite l’invio di un intent, e nessun altro componente dell’applicazione è già attivo, viene creato un processo, contenente un unico thread, in cui è eseguito il componente. Se un componente viene attivato quando esiste già un processo per quella applicazione, perché un altro componente è già stato attivato, allora il componente è attivato nello stesso thread dello stesso processo. Il comportamento di default prevede infatti che tutti i componenti di una applicazione siano attivati nello stesso thread dello stesso processo, che prende il nome di main thread. È possibile personalizzare questo comportamento sia assegnando ad alcuni componenti processi diversi sia creando nuovi thread all’interno dello stesso processo.

3.2.2.7.1 - Processi

Il comportamento di default prevede che tutti i componenti di una applicazione siano eseguiti nello stesso processo. Tuttavia è possibile, tramite il file manifest, modificare questo comportamento e associare determinati componenti ad un processo separato.

I tag xml usati per la dichiarazione dei componenti applicativi (<activity>, <service>, <receiver> and <provider>) permettono di specificare tramite l’attributo android:process il processo in cui i componenti dovranno eseguire. In questo modo è possibile controllare la distribuzione dei componenti nei processi, facendo in modo ad esempio che alcuni componenti eseguano nel processo di default mentre altri in un processo dedicato. Infine è possibile fare in modo che componenti di applicazioni differenti condividano lo stesso processo.

Nel caso il sistema Android debba recuperare memoria può terminare uno o più processi, causando la distruzione di tutti componenti associati. La scelta del processo da terminare è effettuata valutando l’importanza relativa per l’utente. Ad esempio, è più probabile che sia terminato un processo le cui activity non sono più visibili all’utente, piuttosto che il processo che ospita le activity correntemente visualizzate. L’importanza relativa è valutata in base ad una gerarchia d’importanza, riportata in ordine decrescente, in cui i livelli più importanti sono terminati per ultimi:

• foreground process (processo in primo piano), cioè un processo strettamente correlato all’attività corrente dell’utente; è considerato tale un processo che ospita una activity in foreground, o un bound service legato all’activity in foreground, o un servizio che sta eseguendo uno dei metodi di gestione del ciclo di vita (onCreate(), onStart() etc.), o un broadcast receiver che sta eseguendo il metodo onReceive();

• visible process (processo visibile), un processo che non ha elementi in foreground ma che influenza ciò che è visibile all’utente; è un processo che ospita activity non


95

in foreground ma ancora visibili (è stato cioè invocato onPause()) o un bound service collegato ad una attività visibile;

• service process (processo di servizio), cioè un processo che esegue uno started service già avviato (tramite il metodo startService()) e che non ricade in nessuna delle due categorie precedenti;

• background process (processo di background), cioè un processo che ospita activity in background, e che non ha quindi impatto diretto sull’esperienza dell’utente; tipicamente nel sistema è presente un elevato numero di questo tipo di processi, che vengono terminati secondo una politica di tipo Least Recently Used (LRU), cioè a partire dal meno recentemente utilizzato;

• empty process (processo vuoto), cioè un processo che non contiene nessun componente attivo; tali processi vengono tenuti in vita solo per motivi di caching e sono quindi i primi ad essere terminati in caso di necessità.

Ogni processo è classificato secondo il livello più alto possibile in riferimento ai componenti attualmente attivi nel processo. Inoltre un processo che ospita un componente (es. un content provider) che sta servendo un altro componente (es. un servizio) di un altro processo non può mai avere un’importanza inferiore del componente servito.

È importante notare che un processo che ospita un servizio ha un’importanza relativa superiore a un processo che ospita delle attività in background. Di conseguenza, se un’attività deve dare luogo a operazioni di lunga durata, è preferibile attivare un processo dedicato piuttosto che creare un semplice thread, poiché il processo avrà una priorità maggiore (service process anziché background process) nel caso in cui l’utente decidesse di lasciare l’activity.

3.2.2.7.2 - Thread

Quando un’applicazione viene lanciata il sistema crea un thread per l’esecuzione dell’applicazione, che viene chiamato main thread. Lo stesso thread è utilizzato per interagire con gli elementi dell’interfaccia grafica, ad esempio per ricevere gli eventi scatenati dall’utente, tanto che è chiamato anche User Interface thread (UI thread).

Il sistema non crea un thread per ogni componente applicativo. Tutti i componenti che eseguono nello stesso processo sono istanziati nel main thread, e le invocazioni di sistema sui componenti (es. metodi di callback) sono consegnati da questo thread. Quando l’applicazione esegue operazioni di lunga durata nel main thread questo modello può portare a un degrado delle performance. Quando il main thread è impegnato o bloccato, infatti, gli eventi concernenti l’interfaccia e il rendering degli elementi grafici non possono essere consegnati, dando all’utente l’impressione che l’interfaccia sia bloccata. Inoltre, se il main thread rimane bloccato per più di 5 secondi l’utente è notificato con l’infausto messaggio “Application Not Responding” (ANR).

In aggiunta, gli strumenti di User Interface offerti da Android non sono thread-safe, potrebbero cioè comportarsi in modo errato in caso di esecuzioni multiple da


96

parte di più thread. È quindi sconsigliato manipolare gli elementi dell’interfaccia grafica da un thread diverso dell’UI thread.

Riepilogando un uso corretto del modello di threading proposto da Android deve sottostare a 2 importanti regole:

1. non bloccare l’UI thread; 2. non accedere agli elementi di interfaccia grafica fuori dall’UI thread.

Per garantire il rispetto di questi vincoli la piattaforma Android mette a disposizione diversi strumenti descritti nel seguito. Supponendo di dover svolgere un’operazione molto costosa, come ad esempio scaricare dalla rete un’immagine da visualizzare, è immediato pensare di dover creare un thread dedicato all’operazione, in virtù del primo dei due vincoli sopra citati. Tuttavia, una volta effettuata l’operazione all’interno del thread dedicato e ottenuta l’immagine, non è possibile, per il secondo vincolo, interagire direttamente con i componenti della UI per visualizzarla. Per questo motivo sono messi a disposizione i seguenti metodi, che permettono di eseguire le operazioni desiderate all’interno dello stesso UI thread:

• Activity.runOnUiThread(Runnable) • View.post(Runnable) • View.postDelayed(Runnable, long)

Il secondo strumento è costituito dal componente AsyncTask, che permette di eseguire operazioni in modo asincrono e di interagire con l’interfaccia grafica senza preoccuparsi della gestione dei thread. In particolare è necessario estendere la classe AsyncTask e implementare il metodo di callback doInBackground(), che permette di eseguire le operazioni desiderate in un pool di thread dedicati. Oltre a questo è possibile implementare i metodi onPreExecute() ed onPostExecute() per eseguire operazioni all’interno dell’UI thread rispettivamente prima e dopo l’esecuzione di doInBackground(), ed in cui è quindi possibile interagire in modo sicuro con gli elementi dell’interfaccia grafica.

3.2.2.8 Storage La piattaforma Android offre diverse possibilità in merito all’archiviazione

locale persistente d’informazioni. In particolare è possibile salvare le informazioni all’interno di database, sotto forma di file nella memoria di massa integrata del dispositivo o su supporti esterni, o sotto forma di preferenze applicative. La scelta dell’opzione più adatta deve essere effettuata sulla base di alcuni requisiti come la quantità di dati da archiviare e la loro natura pubblica o privata rispetto alle altre applicazioni. Nel caso in cui si scelga una modalità privata all’applicazione è sempre possibile combinarla con il meccanismo dei content provider per rendere i dati accessibili alle altre applicazioni.

Le modalità disponibili per l’archiviazione persistente delle informazioni sono le preferenze utente, la memoria di massa interna, i supporti di archiviazione interni e i database.


97

3.2.2.8.1 - Preferenze

Le preferenze di un’applicazione sono concepite per salvare in modo persistente le preferenze espresse dall’utente in merito a parametri applicativi. Sono costituite da una serie di coppie chiave-valore e sono rappresentate nel sistema Android dalla classe SharedPreferences. Tramite questa classe è possibile salvare tipi primitivi come valori numerici interi e in virgola mobile, booleani e stringhe. Tali valori sono salvati in modo persistente su di un file. È possibile ottenere un’istanza della classe tramite il metodo getSharedPreferences() specificando il nome del file preferenze. Nell’istanza restituita sono caricati automaticamente dal sistema i valori precedentemente salvati. Nel caso in cui si voglia gestire un file preferenze unico per tutte le activity è possibile utilizzare il metodo getPreferences(), che non necessita del nome del file. In seguito è possibile effettuare la lettura dei metodi tramite i metodi getBoolean(), getString(), getInteger() etc., in cui viene specificata la chiave che identifica il parametro richiesto.

Per effettuare inserimenti e modifiche del valori all’interno delle preferenze è necessario innanzitutto recuperare un oggetto di tipo SharedPreferences.Editor tramite il metodo edit(). L’oggetto Editor fornisce i metodi setBoolean(), setString(), setInteger() etc., per inserire valori specificando la chiave che identifica il parametro.

3.2.2.8.2 - Database

Android fornisce un supporto completo a database di tipo SQLite [SQL01]. La libreria SQLite implementa un database SQL transazionale compatto e veloce, caratteristiche che lo rendono particolarmente adatto allo scenario mobile.

Android fornisce un componente di supporto per la gestione di questo tipo di database tramite la classe SQLiteOpenHelper. La creazione del database può essere controllata tramite la ridefinizione del metodo onCreate(), in cui eseguire codice SQL custom per la creazione. Per eseguire operazioni di lettura o scrittura è necessario ottenere un’istanza del database, rappresentata dall’oggetto SQLiteDatabase, rispettivamente tramite i metodi getReadableDatabase() o getWritableDatabase().

È possibile eseguire query sul database tramite il metodo query() fornito dall’oggetto SQLiteDatabase, che accetta diversi parametri quali tabella interessata, proiezione, selezione, e colonne interessate. L’oggetto SQLiteQueryBuilder permette la costruzione di query più complesse. Il risultato di una query è restituito sotto forma di un oggetto Cursor, che costituisce un puntatore alle righe recuperate dalla query.

3.2.3 Posizione e sensori Android offre ampio supporto all’uso dei sensori integrati del dispositivo quali accelerometro, giroscopio, termometro, barometro, etc., e di sistemi di localizzazione basati su GPS, rete Wifi e rete cellulare.

Nel seguito saranno esaminate pima le modalità e le strategie tramite cui è possibile recuperare la posizione dell’utente, ed in seguito gli strumenti forniti dalla piattaforma


98

per interfacciarsi con i sensori presenti sul dispositivo. Infine, nell’ultima parte della sezione descriveremo come è possibile catturare campioni audio e immagini rispettivamente dal microfono e dalla videocamera.

3.2.3.1 Localizzazione Le funzionalità di localizzazione e di gestione delle mappe sono raccolte

all’interno dalla libreria Google Maps Android API, individuata dal package Java android.location.

Il componente centrale della libreria è il LocationManager, che rappresenta il servizio di sistema deputato al recupero di informazioni riguardanti la posizione geografica del dispositivo. Essendo un servizio di sistema il componente non viene istanziato direttamente ma recuperato dal sistema tramite il metodo getSystemService() specificando il parametro Context.LOCATION_SERVICE. Attraverso l’interfaccia offerta dal componente l’applicazione può eseguire fondamentalmente tre diverse operazioni:

• recuperare l’ultima posizione conosciuta su ognuno dei provider disponibili; • registrarsi presso uno specifico provider per la ricezione di aggiornamenti periodici

della posizione corrente; • registrarsi per la ricezione di un intent che viene generato quando il dispositivo si

trova nella prossimità di una data coordinata geografica.

La visualizzazione della posizione geografica dell’utente è effettuata tramite la classe MapView fornita dalle API Google Maps Android. Si tratta di una classe che gestisce in modo automatico la visualizzazione di mappe, occupandosi dell’accesso al servizio Google Maps per il download delle mappe e dei metadati associati, e abilitando inoltre il controllo tramite gesture di tipo touch per lo zoom, il trascinamento etc. Permette inoltre di evidenziare sulla mappa determinati punti d’interesse.

3.2.3.1.1 - Provider

Android supporta tutti i sistemi di localizzazione descritti nel paragrafo 2.4.5 riguardante la Location Awareness: il sistema GPS, la localizzazione tramite rete di telefonia e tramite rete Wi-Fi. Le diverse tecnologie di localizzazione disponibili sono rappresentate all’interno del sistema Android dai location provider. Un location provider rappresenta una sorgente d’informazioni di posizionamento del dispositivo. La tecnologia GPS è rappresentata dal provider GPS_PROVIDER. I sistemi di localizzazione tramite rete telefonica e Wi-Fi sono invece riuniti sotto un unico provider detto NETWORK_PROVIDER. In accordo alle considerazioni effettuate nel paragrafo 2.4.5.5 possiamo quindi dire che il GPS_PROVIDER è associato ad una elevata precisione ma ha un elevato costo in termini di risorse energetiche e di tempo necessario ad ottenere una misurazione. Il NETWORK_PROVIDER invece, seppur caratterizzato da una minore precisione rispetto al GPS, permette di ottenere misurazioni tempestivamente evitando un eccesivo consumo di batteria.

Infine, il PASSIVE_PROVIDER rappresenta un location provider fittizio, poiché non associato ad alcun sistema di localizzazione specifico, che permette a


99

un’applicazione di ricevere le informazioni di localizzazione solo quando richiesto da altre applicazioni. Il provider fornirà quindi le informazioni generate dagli altre applicazioni.

3.2.3.1.2 - Ottenimento della posizione

Il meccanismo tramite cui un’applicazione ottiene le informazioni sulla posizione del dispositivo è quello del callback. In particolare l’applicazione deve innanzitutto richiedere al LocationManager la ricezione degli aggiornamenti tramite il metodo requestLocationUpdates().

Il metodo richiede di specificare il provider da cui ricevere gli aggiornamenti e di fornire un oggetto che implementi l’interfaccia di callback LocationListener. L’interfaccia fornisce diversi metodi di callback per gestire gli eventi che possono verificarsi: onLocationChanged() è il metodo principale in quanto permette di gestire la ricezione degli aggiornamenti di posizione, onProviderEnabled() e onProviderDisabled() per gestire rispettivamente l’attivazione e la disattivazione del provider; onStatusChanged() per gestire un cambiamento di stato del provider (es. disponibile/non disponibile). Il metodo permette inoltre di controllare la frequenza con cui devono essere ricevuti gli aggiornamenti di posizione tramite due parametri: il minimo intervallo di tempo che deve trascorrere, e la minima distanza spaziale che deve intercorrere tra due aggiornamenti successivi. Tali parametri, soprattutto il primo, permettono di limitare il consumo energetico in quanto riducono la frequenza delle operazioni di recupero della posizione tramite i provider utilizzati.

I valori della posizione recuperata sono comunicati al metodo onLocationChanged() tramite un oggetto di tipo Location. Un aspetto importante delle misurazioni è di essere costituiti, oltre che dalle coordinate geografiche e dall’istante temporale in cui sono state effettuate, da un’indicazione dell’accuratezza. Tale valore è indicato in metri e rappresenta il raggio entro cui si ha il 68% di probabilità che l’utente si trovi all’interno della circonferenza individuata. In termini statistici, e assumendo che gli errori di misurazione abbiano distribuzione di densità di probabilità normale, tale percentuale rappresenta i casi che differiscono dal valor medio per una quantità inferiore alla deviazione standard.

Quando l’applicazione non è più interessata agli aggiornamenti di posizione può fermarne la ricezione tramite il metodo del removeUpdates() del LocationManager, specificando il LocationListener interessato.

Per poter usufruire dei meccanismi di localizzazione è inoltre necessario richiedere i relativi permessi. In particolare il permesso android.permission.ACCESS_FINE_LOCATION permette di utilizzare sia il GPS_PROVIDER e sia il NETWORK_PROVIDER, mentre per utilizzare il solo NETWORK_PROVIDER è sufficiente dichiarare il permesso android.permission.ACCESS_COARSE_LOCATION.

L’informazione di posizione è rappresentata da un oggetto di tipo Location, che contiene, oltre alla posizione espressa in termini di latitudine e longitudine, anche altre importanti informazioni, quali l’altitudine sul livello del mare, la velocità e l’accuratezza della misurazione. Quest’ultimo parametro, come vedremo nella


100

prossima sezione, gioca un ruolo fondamentale nel processo di raffinamento delle misurazioni di posizione.

3.2.3.1.3 - Best practices

Ottenere la posizione dell’utente è un processo complesso che deve tenere conto di diversi fattori: la precisione non sempre ottima, il movimento dell’utente, i molteplici provider disponibili, e la necessità di ottimizzare i consumi. Per questo motivo è utile definire un insieme di buone norme d’uso che permettono di eseguire quest’operazione nel migliore dei modi.

Innanzitutto, la posizione utilizzata dall’applicazione deve essere il risultato di un processo di selezione e raffinamento di molteplici misurazioni ottenute in un’ampia finestra temporale. Secondo questo modello l’applicazione, una volta avviata, si registra per la ricezione degli aggiornamenti di posizione dal provider desiderato o, presumibilmente, anche da più provider. Da questo momento l’applicazione inizierà a ricevere gli aggiornamenti che, provenendo da provider diversi, avranno differenti livelli di precisione associati. In seguito alla ricezione di nuove misurazioni l’applicazione deve quindi selezionare la migliore misurazione ottenuta, sia in base alla precisione e sia in base alla freschezza della misurazione. L’ampiezza della finestra di ricezione delle misurazioni deve essere valutata in base all’accuratezza desiderata e a quando è necessaria la posizione all’applicazione. Una volta ottenuta la stima, l’applicazione può fermare la ricezione degli aggiornamenti, per poi utilizzare la migliore misurazione ottenuta. Il procedimento è riassunto in Figura 33. La selezione della migliore misurazione può essere effettuata valutando quanto è più recente, più accurata, e da quale provider proviene.

Figura 33 - Linea temporale che rappresenta il periodo di ricezione degli aggiornamenti.

A prescindere dal provider utilizzato, recuperare la posizione dell’utente può richiedere un tempo non trascurabile. Nel caso in cui l’applicazione abbia bisogno di conoscere tempestivamente la posizione dell’utente è possibile utilizzare l’ultima posizione recuperata dal sistema. Il LocationManager, infatti, effettua il caching dell’ultimo valore ottenuto da ogni provider, indipendentemente dall’applicazione che lo ha richiesto, e lo rende disponibile tramite il metodo getLastKnownLocation().

Per utilizzare i sistemi di posizionamento ottimizzando i consumi energetici è necessario ridurre al massimo l’ampiezza della finestra temporale all’interno della quale si ricevono gli aggiornamenti, scegliere con cura i provider da utilizzare e diminuire la frequenza degli aggiornamenti all’interno della finestra temporale, il tutto compatibilmente con i requisiti di accuratezza che contraddistinguono lo scenario applicativo.


101

3.2.3.2 Sensori La maggior parte dei dispositivi compatibili Android ha una vasta gamma di

sensori integrati che permettono di misurare diversi parametri con notevole precisione. La piattaforma Android supporta tre macro categorie di sensori: i sensori di movimento, che misurano la forza di accelerazione e di rotazione lungo i 3 assi cartesiani, e includono l’accelerometro, i sensori di gravità, il giroscopio; i sensori ambientali, che permettono di misurare diversi parametri riguardanti le condizioni ambientali circostanti, come la temperatura e la pressione dell’aria, l’illuminazione e l’umidità, e includono barometro, fotometro e termometro; i sensori di posizione, che misurano la posizione fisica di un dispositivo, e includono i sensori di orientazione e il magnetometro.

Android mette a disposizione strumenti e API per la gestione e l’acquisizione di dati dai sensori. In particolare permette di determinare quali sensori sono disponibili sul dispositivo, ottenere informazioni su un determinato sensore come risoluzione e scala di misurazione, acquisire i dati sensoriali specificando una frequenza di campionamento, registrarsi per monitorare lo stato dei sensori.

I sensori si suddividono in sensori hardware e software. I sensori hardware sono costituiti da veri e propri componenti fisici integrati all’interno del dispositivo, e misurano grandezze fisiche e ambientali come accelerazione, campo geomagnetico, accelerazione angolare etc. I sensori software, invece, non sono associati a un preciso componente hardware sul dispositivo, seppure ne simulino il comportamento offrendo un’interfaccia analoga. I dati provenienti dai sensori software, detti anche sensori virtuali, sono il risultato della post-elaborazione dei dati provenienti da uno o più sensori hardware. Ne è un esempio il sensore di accelerazione lineare, il cui output è derivato da quello dell’accelerometro eliminando il contributo dell’accelerazione di gravità. In Tabella 1 è mostrata la lista di tutti sensori supportati dalla piattaforma Android.

Sensore Tipo Descrizione Uso comune ACCELEROMETER Hardware Misura la forza di

accelerazione sui 3 assi (x, y, z), incluso la forza di gravità.

Riconoscimento dei movimenti.

AMBIENT TEMPERATURE

Hardware Misura la temperatura dell’ambiente.

Monitorare la temperatura dell’aria.

GRAVITY Software o Hardware

Misura la forza di gravità sui 3 assi (x, y, z).


GYROSCOPE Hardware Misura la velocità angolare attorno ad ognuno degli assi (x, y, z).


LIGHT Hardware Misura il livello d’illuminazione

Controllare la luminosità dello


102

dell’ambiente. schermo. LINEAR ACCELERATION

Software o Hardware

Misura la forza di accelerazione sui 3 assi (x, y, z), escluso la forza di gravità.

Monitorare l’accelerazione lungo un singolo asse.

MAGNETIC FIELD

Hardware Misura il campo geomagnetico lungo ognuno degli assi (x, y, z).

Creare una bussola.

ORIENTATION Software Misura la rotazione del dispositivo attorno agli assi (x, y, z).

Determinare l’orientamento del dispositivo.

PRESSURE Hardware Misura la pressione dell’aria nell’ambiente circostante.

Monitorare i cambiamenti nella pressione dell’aria.

PROXIMITY Hardware Misura la prossimità di un oggetto relativamente allo schermo del dispositivo.

Determinare se il dispositivo è posto vicino l’orecchio dell’utente durante una telefonata.

RELATIVE HUMIDITY

Hardware Misura l’umidità relativa dell’ambiente circostante.

Monitorare l’umidità assoluta e relativa.

ROTATION VECTOR

Software o Hardware

Misura l’orientazione del dispositivo fornendo gli elementi del vettore di rotazione.

Riconoscimento del movimento e della rotazione.

TEMPERATURE Hardware Misura la temperatura del dispositivo. È stato rimpiazzato dal sensore AMBIENT_TEMPERATURE nella versione API Level 14.

Monitoraggio della temperatura.

Tabella 1 - Tipologie di sensori supportati dalla piattaforma Android

Si noti che nella lista precedente non compare il microfono, che essendo considerato come dispositivo a sé stante è gestito attraverso delle API differenti, e sarà pertanto trattato separatamente. Naturalmente non tutti i dispositivi sono dotati di tutte le tipologie di sensori descritte, oppure possono fornire in alcuni casi più sensori della stessa tipologia. Per questo motivo prima del loro uso è necessario controllarne la disponibilità.

3.2.3.2.1 - Il framework dei sensori

L’infrastruttura dedicata alla gestione dei sensori è parte della libreria individuata dal package Java android.hardware. In particolare i componenti principali per la gestione dei sensori sono e gli oggetti deputati alla gestione dei sensori sono: il SensorManager, che rappresenta l’interfaccia principale per il servizio


103

di sistema riguardante i sensori; la classe Sensor, che rappresenta un’istanza di uno specifico sensore; la classe SensorEvent che rappresenta un singolo evento, cioè una misurazione, generato dal sensore; il SensorEventListener, una classe contenente i metodi di callback che permettono di ricevere le notifiche dai sensori, sotto forma di SensorEvent.

Un riferimento al SensorManager può essere ottenuto tramite il metodo getSystemService() indicando il servizio SENSOR_SERVICE. Tale componente permette innanzitutto di ottenere l’elenco dei sensori disponibili tramite il metodo getSensorList(), costituito da una lista di oggetti Sensor. Nel caso in cui il parametro del metodo sia uguale a TYPE_ALL viene restituita la lista completa dei sensori, mentre per ottenere solo i sensori di una particolare tipologia si specifica come parametro il tipo di interesse tra quelli indicati in Tabella 1. Un oggetto di tipo Sensor permette poi di accedere a informazioni specifiche del sensore come il produttore, la risoluzione, la massima frequenza di campionamento etc. Il metodo getDefaultSensor () permette inoltre di recuperare il sensore di default per una determinata tipologia di sensore.

Altra funzionalità fondamentale del SensorManager è permettere di registrarsi per la ricezione degli eventi di uno specifico sensore tramite il metodo registerListener(). I parametri del metodo sono costituiti da: i) un’istanza di tipo SensorEventListener, che riceverà gli eventi dal sensore, ii) una costante intera che identifica il tipo di sensore di interesse tra quelli indicati in Tabella 1, e iii) la frequenza con cui si intende ricevere gli aggiornamenti. L’interfaccia SensorEventListener definisce i metodi di callback onSensorChanged() e onAccuracyChanged(). Il primo permette di ricevere gli eventi generati dal sensore, sotto forma di oggetti di tipo SensorEvent, mentre il secondo è invocato in corrispondenza di una variazione nella precisione del sensore. Un oggetto di tipo SensorEvent contiene informazioni sul nuovo dato rilevato: la precisione della rilevazione, l’istante temporale in cui è stata effettuata, il sensore che l’ha generata, e i valori rilevati. Per quanto riguarda il terzo parametro del metodo registerListener(), cioè la frequenza di ricezione degli eventi, viene specificata tramite il periodo che intercorre tra due misurazioni. Sono previste 4 modalità: SENSOR_DELAY_FASTEST, che corrisponde ad un ritardo minimo di 0 microsecondi, e quindi alla frequenza massima supportata dal dispositivo; SENSOR_DELAY_GAME, pari ad un intervallo di 20 microsecondi; SENSOR_DELAY_UI, pari ad un intervallo di 60 microsecondi; infine SENSOR_DELAY_NORMAL corrisponde ad un intervallo pari a 200 microsecondi. Inoltre dalla versione Api Level 11 è possibile specificare tale parametro come valore assoluto. È importante tenere presente che tale parametro rappresenta solo un suggerimento per il sistema Android, e potrebbe essere alterato in base alle condizioni operative. Una buona pratica è specificare il massimo periodo compatibile con le specifiche applicative, considerando che il sistema utilizzerà in condizioni normali un valore leggermente inferiore a quello specificato. Ad una frequenza di campionamento inferiore è inoltre associato un minore costo energetico e computazionale.


104

3.2.3.2.2 - Sistema di coordinate

Il framework dei sensori usa un sistema di riferimento standard a 3 assi in base a cui esprimere i dati rilevati. Per la maggior parte dei sensori tale sistema di coordinate è definito in riferimento allo schermo del dispositivo quando questo si trova nell’orientazione di default, riportata in Figura 34. In tale posizione l’asse X è orizzontale e diretto alla destra dell’utente, l’asse Y è diretto verticalmente verso l’alto, e l’asse Z è perpendicolare allo schermo e con verso uscente.

Figura 34 - Sistema di riferimento utilizzato dal framework dei sensori.

Il sistema di riferimento descritto è usato dai seguenti sensori: accelerometro, sensore di gravità, giroscopio, accelerometro lineare, sensore di campo geomagnetico.

3.2.3.2.3 - Sensori di movimento

La piattaforma Android fornisce diversi sensori per rilevare il movimento del dispositivo. Due di questi sensori, l’accelerometro e il giroscopio, sono sempre sensori hardware. Altri tre, il sensore di gravità, di accelerazione lineare, e il sensore del vettore di rotazione, possono essere sensori hardware o software, a seconda della disponibilità sul dispositivo.

Per questa tipologia di sensori l’oggetto SensorEvent contiene un vettore di tre elementi, che rappresentano le componenti lungo ognuno degli assi cartesiani di: forza di accelerazione (inclusa la gravità) per l’accelerometro, forza di gravità per il sensore di gravità, velocità angolare per il giroscopio, forza di accelerazione (esclusa la gravità) per il sensore di accelerazione lineare, vettore di rotazione nel caso del sensore del vettore di rotazione. In quest’ultimo caso può inoltre essere presente una quarta componente opzionale che rappresenta la componente scalare del vettore.

L’Android Open Source Project (AOSP) fornisce tre sensori software di movimento: un sensore di gravità, un sensore di accelerazione lineare, ed un sensore del vettore di rotazione. Per utilizzare tali sensori è necessario individuarli tramite campi dell’oggetto Sensor ottenuti tramite getVendor() e getVersion, dato che sono riconosciuti dal sistema come sensori secondari. In particolare il campo vendor deve avere valore pari a “Google Inc.” ed il numero di versione deve essere pari a “3”. La versione è necessaria per individuare l’aggiornamento introdotto in Android 4.0 che fa uso del giroscopio in aggiunta agli altri sensori.


105

La misura !! dell’accelerazione applicata al dispositivo ottenuta tramite l’accelerometro è sempre influenzata dalla forza di gravità secondo la relazione: !! = −! − !

!, dove ! rappresenta la massa del dispositivo, ! le forze ad esso

applicate e ! l’accelerazione di gravità. Di conseguenza, quando il dispositivo è fermo misurerà un’accelerazione di 9,8 !/!! mentre quando è in caduta libera misurerà un’accelerazione di 0 !/!!. L’accelerometro presenta inoltre il vantaggio di usare una quantità di energia pari a circa 1/10 degli altri sensori di movimento. Per isolare i contributi delle forze applicate al dispositivo e dell’accelerazione di gravità vengono forniti rispettivamente il sensore di accelerazione lineare ed il sensore di gravità.

Il giroscopio misura la velocità angolare in rad/sec attorno agli assi del sistema di riferimento. In accordo alla definizione matematica, una rotazione in senso antiorario è considerata di verso positivo.

Il vettore di rotazione rappresenta l’orientazione del dispositivo tramite un angolo di rotazione θ attorno ad un asse individuato dal versore !. Il vettore di rotazione è rappresentato dal sistema Android con la notazione dei quaternioni, cioè tramite un vettore di 4 elementi in cui le prime tre componenti sono costituite rispettivamente da: !! ∗ sin(!/2 ) , !! ∗ sin(!/2 ) , ed !! ∗ sin(!/2 ) . La quarta componente è rappresentata dal cos(!/2 ) . Il sistema di riferimento utilizzato, rappresentato in Figura 35, è definito con una base ortonormale in cui l’asse X è tangente alla superficie terrestre e diretto approssimativamente verso Est, l’asse Y è tangente alla superficie terrestre e diretto verso il Polo Nord, mentre l’asse Z è perpendicolare alla superficie terrestre e uscente verso l’esterno.

Figura 35 - Sistema di riferimento utilizzato dal vettore di rotazione.

3.2.3.2.4 - Sensori di posizione

La piattaforma Android fornisce due sensori che permettono di determinare la posizione del dispositivo rispetto a un sistema di riferimento solidale con il globo terrestre: il sensore di campo geomagnetico e il sensore di orientazione. In aggiunta è fornito un sensore capace di rilevare la vicinanza della parte frontale del dispositivo con un oggetto, il sensore di prossimità. Mentre il sensore di campo geomagnetico e il sensore di prossimità sono sensori hardware, il sensore di orientamento è un sensore software che deriva i suoi dati dal sensore di campo geomagnetico e dall’accelerometro.


106

Nel caso del sensore di campo geomagnetico l’oggetto SensorEvent contiene un vettore di 3 elementi che rappresenta l’intensità del campo magnetico lungo ognuno dei 3 assi cartesiani che formano il sistema di riferimento. Il sensore di orientamento, invece, combina i dati rilevati dal sensore di campo geomagnetico e dall’accelerometro per fornire i seguenti 3 valori: l’azimut, cioè l’angolo tra il nord magnetico e l’asse y del dispositivo; il pitch, cioè l’angolo di rotazione attorno all’asse x; il roll, cioè i gradi di rotazione attorno all’asse y. A causa della complessità di calcolo di tali valori e della bassa precisione che ne deriva, il sensore di orientamento è stato deprecato a partire dell’API Level 8. In alternativa sono forniti i metodi getRotationMatrix() e getOrientation() del SensorManager.

Infine, il sensore di prossimità restituisce attraverso l’oggetto SensorEvent un valore che rappresenta la distanza in centimetri di un oggetto dalla facciata frontale del dispositivo.

3.2.3.2.5 - Sensori di ambiente

La piattaforma Android supporta 4 tipologie di sensori che permettono di monitorare diverse proprietà dell’ambiente circostante il dispositivo: l’umidità relativa, l’illuminazione, la temperatura del dispositivo e dell’ambiente, e la pressione atmosferica. In tutti i 4 casi si tratta di sensori hardware, e sono quindi disponibili solo se il dispositivo dispone di questo tipo di sensori integrati al suo interno. Tipicamente, solo il sensore d’illuminazione è largamente diffuso poiché utilizzato per controllare la luminosità dello schermo.

L’oggetto SensorEvent contiene per questa tipologia di sensori un unico valore che rappresenta il dato rilevato. In particolare questo valore rappresenta la temperatura in gradi centigradi per il sensore di temperatura ambientale e del dispositivo, l’illuminamento (rapporto tra flusso luminoso e superficie illuminata) nel caso del sensore d’illuminazione, la pressione in millibar per il sensore di pressione, la percentuale di umidità relativa per il sensore di umidità.

Questa tipologia di sensori, a differenza delle altre, è caratterizzata da una maggiore facilità di utilizzo in quanto i dati possono essere direttamente fruiti senza alcuna operazione di calibrazione o modifica. Tuttavia è comunque possibile elaborarli per ottenere informazioni più complesse. Ad esempio i dati rilevati dal sensore di umidità e di temperatura ambientale possono essere combinati per calcolare il punto di rugiada e l’umidità assoluta.

3.2.3.3 Media Alcune tipologie di sensori quali fotocamera e microfono sono gestite dalla

piattaforma Android in modo separato dagli altri sensori mettendo a disposizione dello sviluppatore un set di API distinto. Tuttavia nello scenario del mobile sensing questi dispositivi possono essere considerati alla stregua di tutti gli altri sensori. Di seguito procederemo quindi a esporre le modalità con cui è possibile interfacciarsi con il microfono per la registrazione di suoni e con la fotocamera per la cattura di immagini.


107

3.2.3.3.1 - Microfono

La piattafroma Android supporta la registrazione di sequenze audio secondo diversi formati. Per utilizzare il microfono è necessario dichiarare nel file manifest l’utilizzo del permesso android.permission.RECORD_AUDIO. La registrazione di sequenze audio tramite microfono può avvenire attraverso due modalità. La prima prevede che i dati siano letti come sequenza di byte manipolabile dall’applicazione. La seconda invece si appoggia sulla prima ma prevede che l’output sia archiviato all’interno di un file, secondo una ben precisa codifica quale MPEG4, AAC, o 3GPP.

La prima modalità, cioè che prevede la lettura della sequenza audio come stream di byte, è basata sulla classe android.media.AudioRecord, che si occupa di gestire la registrazione di sequenze audio dall’hardware di input audio del dispositivo. All’atto della creazione di un’istanza di questo oggetto vanno specificati una serie di parametri, tra cui i più importanti sono: i) la frequenza di campionamento, che può variare da 8000 Hz a 44100 Hz, ii) la codifica desiderata, che può essere PCM 16 bit o PCM 8 bit, e iii) la dimensione del buffer che conterrà i campioni, opportunamente selezionata in base alla frequenza di campionamento e alla durata della registrazione che si vuole effettuare. Per iniziare la registrazione è fornito il metodo startRecoding(), mentre per terminarla il metodo stop(). I dati registrati possono essere letti tramite il metodo read() che accetta un array di byte di dimensione inferiore o uguale a quella specificata all’atto della creazione. Ciò permette di riempire il buffer di lettura leggendo progressivamente delle porzioni di dimensione limitata. Il metodo read() è inoltre bloccante nel caso in cui sia invocato quando il buffer di lettura non è ancora pieno.

La seconda modalità si basa invece sull’uso della classe android.media.MediaRecorder. L’inizializzazione della classe prevede diverse operazioni tra cui: i) l’impostazione della sorgente audio, tramite il metodo setAudioSource(), specificando per il microfono la costante MediaRecorder.AudioSource.MIC; ii) la scelta del formato di output tramite il metodo setOutputFormat(), ad esempio MPEG4, AAC o 3GPP; iii) la scelta del nome del file di output tramite il metodo setOutputFile(). L’operazione d’inizializzazione è completata con l’invocazione del metodo prepare(), che configura l’oggetto per la registrazione e codifica dei dati. I metodi start() e stop() segnano rispettivamente l’inizio e la fine della registrazione. A differenza del caso precedente, in cui i dati dovevano essere letti tramite un buffer, in questo caso sono automaticamente codificati e salvati all’interno del file specificato all’atto dell’inizializzazione. Infine, quando la registrazione è conclusa e l’istanza di MediaRecorder non è più necessaria è consigliato l’utilizzo del metodo release() per il rilascio immediato delle risorse associate.

3.2.3.3.2 - Fotocamera

La piattaforma Android include il supporto per diverse tipologie di fotocamera e varie funzionalità legate all’utilizzo della stessa. Permette sia la registrazione di sequenze video che la cattura di singole immagini. In entrambi i casi, l’applicazione può utilizzare la fotocamera sfruttando componenti già esistenti di altre applicazioni,


108

richiamati attraverso il meccanismo degli intent, oppure realizzare essa stessa le funzionalità sfruttando le API Android per la gestione della fotocamera.

Il modo più semplice per utilizzare le funzionalità della fotocamera è quello di usare gli intent per invocare i componenti di applicazioni Android già esistenti. Gli intent con azioni MediaStore.ACTION_IMAGE_CAPTURE e MediaStore.ACTION_VIDEO_CAPTURE rappresentano rispettivamente una richiesta di catturare un immagine o un video tramite una applicazione esistente che, dopo aver assolto all’operazione richiesta, restituisce il controllo all’applicazione chiamante. Attraverso il metodo startActivityForResult() è possibile inviare l’intent mentre il metodo di callback onActivityResult() permette di gestire il completamento dell’operazione e la riacquisizione del controllo da parte dell’applicazione. L’intent da inviare può essere correlato dall’informazione aggiuntiva MediaStore.EXTRA_OUTPUT costituita da un URI che specifica il percorso e il nome del file in cui salvare i dati. Nel caso tali informazioni non siano specificate, sono utilizzati i valori di default. Un’applicazione che utilizza la fotocamera con questa modalità deve dichiarare il permesso <uses-feature android:name="android.hardware.camera"/>.

L’implementazione delle operazioni di gestione della fotocamera tramite le Android API è una pratica necessaria solo nel caso in cui l’applicazione abbia bisogno di utilizzare particolari funzionalità. In questo caso la classe Camera permette di controllare la fotocamera e può essere utilizzata per catturare immagini e video. Tramite il metodo statico open() è possibile creare un’istanza della classe. Nel caso in cui la fotocamera sia già in uso o non sia presente sul dispositivo l’invocazione del metodo genera un’eccezione. La vista SurfaceView permette di mostrare all’utente l’anteprima dell’immagine o del video, visualizzando in tempo reale le immagini provenienti dalla fotocamera. Tramite il metodo Camera.takePicture() è possibile catturare l’immagine corrente, specificando come parametro un oggetto di tipo PictureCallback che nel metodo onPictureTaken() gestisca i dati dell’immagine, rappresentati attraverso un array di byte. Per registrare un video è invece necessario incapsulare l’oggetto Camera all’interno di un’istanza della classe MediaRecorder. È necessario impostare le sorgenti audio e video utilizzate dal MediaRecorder, rispettivamente tramite i metodi setAudioSource() e setVideoSource(), specificando il microfono associato alla fotocamera, rappresentato dalla costante MediaRecorder.AudioSource.CAMCORDER, e la fotocamera stessa, rappresentata dalla costante MediaRecorder.VideoSource.CAMERA. Come nel caso del microfono, l’invocazione del metodo prepare() del MediaRecorder conclude la fase di inizializzazione, mentre l’inizio e la fine della registrazione sono gestiti tramite i metodi start() e stop(). Inoltre, durante la fase di registrazione è necessario garantire l’accesso esclusivo del MediaRecorder alla fotocamera tramite i metodi lock() e unlock() dell’oggetto Camera. Infine, un’applicazione che utilizza la fotocamera tramite le API deve richiedere il permesso <uses-permission android:name="android.permission.CAMERA" /> in aggiunta a quelli indicati nel paragrafo precedente riguardanti l’utilizzo degli intent.


109

3.3 - Conclusioni Nel corso del capitolo abbiamo esaminato le maggiori piattaforme per sistemi

mobili presenti sul mercato. Alcune di queste, come Symbian, sono ormai in declino tanto che sono state abbandonate da tutti produttori di dispositivi mobili. iOS e RIM Blackberry rappresentano invece piattaforme fortemente proprietarie, con compatibilità limitata ai soli dispositivi della stessa casa produttrice. Anche Windows Mobile e Windows Phone rappresentano sistemi proprietari, utilizzati però da un certo numero di case produttrici quali Nokia, LG e Samsung. Tuttavia la portabilità risulta comunque limitata se confrontata con i sistemi Java ME e Android. Tra questi, che offrono un ampio insieme di API per supportare le funzionalità e l’hardware del dispositivo, Java ME presenta problemi di device fragmentation che Android riesce invece a gestire in modo soddisfacente. Considerando anche che si tratta al momento rappresenta il più diffuso sul mercato, con ottime previsioni di sviluppo, la nostra scelta è caduta su questo sistema operativo aperto e basato su kernel Linux.

Dopo aver descritto i componenti fondamentali quali activity, service, broadcast receiver e content provider e i meccanismi di threading e di storage previsti dal sistema Android, abbiamo esaminato le API che permettono un controllo capillare di un ampio spettro di sensori quali accelerometro, giroscopio, bussola, sensore di orientamento, di temperatura di umidità e di luminosità. Abbiamo inoltre analizzato il supporto ai sistemi di posizionamento e le best practice necessarie a gestire in maniera efficiente la localizzazione dell’utente. Infine, il supporto alla tecnologia Bluetooth permette di rilevare i dispositivi vicini e il contesto sociale dell’utente.

In ultima analisi riteniamo quindi che il sistema Android rappresenti un’ottima piattaforma per sviluppare applicazioni di mobile sensing capaci di monitorare lo stato dell’utente e l’ambiente circostante coniugando i requisiti di efficienza computazionale ed energetica richiesti dai dispositivi mobili.

4 - Piattaforme per applicazioni enterprise

Il termine enterprise, letteralmente “azienda”, fa riferimento a un’organizzazione d’individui o entità che lavorano e cooperano per il raggiungimento di un obiettivo comune. Possiamo avere aziende di ogni dimensione e taglia, profit o non-profit, pubbliche o private, anche se solitamente con il termine enterprise si fa riferimento a organizzazioni di grandi dimensioni e a scopo di lucro.

Servizi di vendita online ed elaborazione dei pagamenti, monitoraggio delle vendite, analisi dei costi, sistemi di fatturazione, registrazione dei crediti, gestione della catena di rifornimento, supporto clienti ed erogazione di servizi IT, sono tutti esempi di classi di applicazioni che sono etichettate come “enterprise” non solo in quanto concernenti l’ambito aziendale, ma poiché sono chiamate ad affrontare le diverse problematiche e le sfide che ne conseguono.

Si tratta di applicazioni che coinvolgono una grande quantità di dati archiviati, solitamente organizzati in database, che devono essere continuamente prelevati, aggiornati e modificati. Spesso si tratta di archivi d’informazioni ereditati da vecchi sistemi ormai dismessi, che hanno sopravvissuto agli stessi sistemi che li avevano creati originariamente, e la cui struttura deve essere continuamente aggiornata per supportare l’archiviazione di nuovi moduli d’informazione senza compromettere i precedenti. Anche nel caso in cui siano installati nuovi sistemi software all’interno dell’azienda, i dati devono essere migrati dalla vecchia piattaforma alla nuova in modo opportuno.

Tali sistemi devono gestire l’accesso contemporaneo e concorrente degli utenti. Per alcuni sistemi il volume di utenti potrebbe essere circoscritto a un centinaio di perone, ma per sistemi basati su Web e connessi alla rete Internet questo numero può crescere di diversi ordini di grandezza. Volumi di utenza come questi comportano


112

indubbiamente problematiche di efficienza e sono necessari sistemi in grado di garantire l’accesso a tutti gli utenti in modo appropriato. Le aziende di successo tendono inoltre a crescere in dimensione, assumere più personale, aumentare i volumi di vendita e di erogazione dei servizi Internet, svilupparsi su diverse locazioni geografiche e così via. Le applicazioni enterprise devono essere scalabili e supportare questa crescita, piuttosto che ostacolarla.

L’elevato numero di utenti e l’eterogeneità dei dispositivi comporta inoltre la necessità di gestire un elevato numero di interfacce utente differenti. Le varie tipologie di utenti accedono a viste diverse delle applicazioni, e la presentazione dei dati deve essere adattata in funzione della tipologia di utente e dello scopo dell’interazione.

Altra sfida ricorrente è l’integrazione di sistemi precedentemente separati per guadagnare efficienza su scala aziendale. Si tratta spesso di sistemi legacy, costruiti in tempi diversi con differenti tecnologie, che supportano meccanismi di collaborazione tra loro incompatibili. Nel caso in cui l’integrazione coinvolga aziende diverse diventa ancora più problematica. Strettamente collegata alla questione dell’integrazione vi è la necessità di avere a che fare con un ambiente multi-vendor. Sia a causa dell’evoluzione tecnologica che delle necessità aziendali spesso si adottano nelle diverse divisioni soluzioni simili ma provenienti da produttori differenti.

Le applicazioni enterprise richiedono spesso funzionalità ricorrenti, come la gestione della sicurezza per salvaguardare la conoscenza aziendale, e i servizi di transazioni per garantire l’integrità dei dati. Ognuna di queste richiede capacità e conoscenze specifiche. Ad esempio, la gestione appropriata dalle transazioni richiede la capacità di ripristino del sistema in seguito ai malfunzionamenti, la gestione delle situazioni multiutente, la garanzia di consistenza tra le transazioni e così via. In modo simile l’implementazione della sicurezza potrebbe richiedere la conoscenza di diversi protocolli di sicurezza.

A questo tipo di funzionalità trasversali si contrappongono invece le logiche specifiche di un determinato dominio applicativo. Il cuore delle applicazioni enterprise è, infatti, costituito dalla cosiddetta business logic, o “logica di business”, cioè l’insieme degli algoritmi funzionali che regolano lo scambio d’informazioni e le interazioni tra le entità del sistema, e che determinano come le informazioni all’interno del sistema sono elaborate. È strettamente correlato al dominio applicativo mentre può essere associato come abbiamo detto a molteplici viste. Si tratta di un elemento fondamentale per l’applicazione, poiché ha un forte impatto sull’efficienza complessiva del sistema. Non solo, non è raro dover affrontare la necessità di modificare e aggiornare la business logic, ed è quindi auspicabile progettarla secondo principi di modularità ed estendibilità.

Sulla base di tutte queste considerazioni definiamo quindi le applicazioni enterprise come grandi sistemi software distribuiti che operano in un ambiente aziendale, come un’impresa o un’amministrazione, e che ne gestiscono l’insieme dei processi di business e l’erogazione di servizi IT. Si tratta quindi di sistemi di grandi dimensioni ed estremamente complessi, che devono gestire grandi quantità di informazioni e un elevato volume di utenti, garantendo buone caratteristiche di efficienza e la possibilità di integrazione con piattaforme e sistemi esterni. Requisiti


113

fondamentali per questi sistemi sono la portabilità sulle diverse piattaforme, interoperabilità tra diversi ambienti anche legacy e un supporto a tempo di esecuzione che garantisca scalabilità, efficienza, affidabilità e tolleranza ai guasti. Per soddisfare queste necessità sono state sviluppate diverse piattaforme in grado di semplificare e supportare lo sviluppo di applicazioni enterprise.

Nel corso del capitolo, dopo aver tracciato alcuni concetti generali, procederemo presentando le più importanti piattaforme per lo sviluppo di applicazioni enterprise, analizzando vantaggi e svantaggi di ognuna. In seguito descriveremo più in dettaglio la piattaforma che riterremo più idonea.

4.1 - Generalità Le piattaforme enterprise nascono per soddisfare le necessità legate alla

realizzazione delle applicazioni enterprise. Sostanzialmente possiamo strutturare questo tipo di applicazione su tre elementi fondamentali. Alla base di tutto troviamo un insieme di dati, strutturati in qualche modo, attorno cui è organizzata l’applicazione, e che sono acceduti e modificati da questa. Abbiamo poi le modalità con cui il sistema interagisce con l’utente, presentando le informazioni da visualizzare attraverso viste differenziate in funzione del tipo di client, e raccogliendo l’input dell’utente. Tra queste due troviamo il cuore dell’applicazioni enterprise, la cosiddetta “logica di business”, cioè l’insieme degli algoritmi funzionali che regolano lo scambio d’informazioni e le interazioni tra le entità del sistema, e che determina come le informazioni all’interno del sistema sono elaborate. Si tratta di un elemento fondamentale per l’applicazione, in quanto ha un forte impatto sull’efficienza complessiva del sistema. Non solo, non è raro dover affrontare la necessità di modificare ed aggiornare la business logic, ed è quindi auspicabile progettarla secondo principi di modularità ed estendibilità.

Questi tre elementi costituiscono le fondamenta di ogni applicazione enterprise e generalmente le piattaforme odierne promuovono la strutturazione delle applicazioni secondo questo modello, fornendo gli strumenti opportuni per supportare ognuno di essi. Storicamente tuttavia non è stata sempre questa l’organizzazione adottata e vedremo quindi come si sono evolute nel tempo.

4.1.1 Evoluzione delle applicazioni enterprise Le applicazioni e i sistemi enterprise hanno seguito una linea evolutiva ben

precisa. Originariamente il mondo delle applicazioni enterprise era governato dai main-frame, grandi elaboratori in cui era concentrata tutta la potenza di elaborazione ed il software dell’azienda. Tipicamente i client erano rappresentati da cosiddetti dumb terminal, o “terminal stupidi”, in quanto capaci solo di semplici operazioni di input/output per l’interfacciamento con l’utente. Se quest’approccio centralizzato presentava da un lato il vantaggio di dover gestire un unico sistema per tutte le necessita di elaborazione, dall’altro era fonte di molti problemi: innanzitutto costituiva un single point of failure, cioè un punto di vulnerabilità il cui malfunzionamento comprometteva il funzionamento dell’intero sistema, e poneva inoltre forti limiti alla


114

scalabilità del sistema e all’accessibilità da postazioni remote. Questo tipo di organizzazione dell’applicazione enterprise è comunemente chiamato single-tier, in quanto costituito da un unico livello applicativo che raccoglieva e mescolava tra loro le funzionalità di presentazione delle informazioni, la business logic, e i dati stessi. In questo modo, un cambiamento su uno solo degli aspetti aveva ripercussioni anche su tutti gli altri obbligando così a rivalidare l’intero sistema.

L’approccio client-server ha in parte alleviato queste problematiche spostando gli aspetti legati alla presentazione e parte della business logic sul livello cliente, dando luogo al modello detto two-tier. Tuttavia la logica di business era spezzata e mescolata in parte con il livello di presentazione sul modulo client e in parte con il livello dei dati sul server. Inoltre nascono nuove problematiche legate ad esempio alla necessità di aggiornare il software presente su un grande numero di client.

L’approccio detto three-tier fornisce invece un bilanciamento ottimale separando la logica di presentazione dalla logica di business e la logica di business dai dati sottostanti. All’affermazione di questo modello ha contribuito indubbiamente anche lo sviluppo del Web, che ha permesso la realizzazione di livelli di presentazione leggeri e senza necessità di installazione. Sottolineiamo che i singoli livelli non devono necessariamente costituire un elemento hardware separato, nonostante sia certamente possibile. Un livello rappresenta, soprattutto, una separazione delle responsabilità del software stesso. I differenti livelli sono logicamente distinti dal punto di vista software ma potrebbero sia coesistere fisicamente sulla stessa macchina sia essere distribuiti tra macchine diverse. Logicamente s’individuano tre diversi elementi lato server: il server di presentazione, che incarica il livello di presentazione e può essere ad esempio un web server che interagisce con il web browser presente sul lato client, l’application server su cui risiede la business logic, ed un database che conserva le informazioni in modo persistente. Un application server ha il compito di supportare la realizzazione della business logic favorendone caratteristiche come modularità e riusabilità e fornendo un ampio spettro di servizi di supporto come transazioni, sicurezza e interazione con il database. Talvolta questo modello può essere indicato anche con il termine n-tier, facendo riferimento al fatto che il software non è limitato a soli tre livelli, ma potrebbe essere organizzato in un numero maggiore di strati per soddisfare specifiche necessità. Il livello centrale, quello relativo ala business logic,

In generale, i benefici offerti dall’organizzazione n-tier sono molteplici. Innanzitutto aumenta la manutenibilità del software permettendo di isolare le modifiche a un singolo livello fin tanto che le interfacce con gli altri livelli rimangono invariate. In secondo luogo favorisce la modularità e il riuso dei componenti e degli strati applicativi abbassando il costo di sviluppo delle applicazioni. Infine, è più semplice sostituire componenti di business con nuove versioni se queste risiedono su livello di business piuttosto che rimpiazzare centinaia o migliaia di applicazioni clienti. In Figura 36 sono rappresentate le organizzazioni single-tier, two-tier e n-tier descritte. Per il modello n-tier è rappresentato il caso di un livello di presentazione basato su web, che comprende quindi un web browser sul lato client e un web server sul lato server. Tuttavia potrebbe essere realizzato tramite qualsiasi tecnologia come ad esempio una serie di RESTful Web Services che si interfacciano con dispositivi


115

mobili. Il livello intermedio è realizzato tramite software detti application server, sistemi che forniscono l’infrastruttura e le funzionalità di supporto alla realizzazione di applicazioni server enterprise in un contesto distribuito.

Figura 36 - Organizzazione single-tier, two-tier e n-tier.

Di seguito procederemo ad esaminare più in dettaglio i singoli livelli del modello.

4.1.2 Il modello three-tier I livelli principali che costituiscono il modello three-tier prendono il nome di

presentation layer o livello di presentazione, business layer o livello di business, e data layer o livello dei dati. L’architettura complessiva è rappresentata in Figura 37.

Il presentation layer si occupa di gestire l’interazione tra l’utente e il sistema software. Potrebbe essere rappresentato semplicemente da una interfaccia a linea di comando, anche se oggigiorno è più probabile che si tratti di client con una complessa interfaccia grafica o una interfaccia basata su pagine HTML accedute tramite browser. Le responsabilità principali di questo livello consistono nel visualizzare le informazioni all’utente e interpretare l’input proveniente da questo, traducendolo in azioni che saranno eseguite dal livello di business.

Il business layer incapsula la logica di business dell’applicazione, cioè l’insieme dei comportamenti associati allo specifico dominio applicativo cui l’applicazione fa riferimento. Coinvolge l’elaborazione sia dei dati provenienti dall’utente sia di quelli memorizzati nel livello sottostante, la validazione dei dati provenienti dal livello di presentazione e la scelta di quale specifico data source utilizzare.

Infine, il data layer riguarda la comunicazione e l’integrazione con altri sistemi che portano a termine determinati compiti su ordine dell’applicazione. Questi possono essere altre applicazioni, sistemi di messaggistica o altro con cui l’applicazione interagisce. Per la maggior parte delle applicazioni l’elemento fondamentale di questo livello riguarda la persistenza delle informazioni, ed è solitamente costituito fisicamente da uno o più database. Tra le sue responsabilità troviamo quella di fornire la connettività con i database, permettere lo scambio delle informazioni e garantire la consistenza dei dati attraverso meccanismi di locking e replicazione.


116

Figura 37 - Schema dell'architettura three-tier.

Gli application server e le piattaforme enterprise moderne supportano inoltre un particolare modello di organizzazione delle entità software detto “a componenti”, che promuove il riuso e la modularità nelle applicazioni.

4.1.3 Componenti e container Uno dei grandi vantaggi che era stato previsto in seguito alla nascita e alla

diffusione dell’approccio object-oriented consisteva nella maggiore riusabilità e modularità l’adozione di questo modello avrebbe comportato. Questa aspettativa, tuttavia, fu realizzata solo parzialmente, soprattutto causa della granularità molto fine che contraddistingue gli oggetti e la conseguente difficoltà nel realizzare forme di riuso su larga scala, a causa dell’elevato livello di accoppiamento che gli oggetti presentavano.

Il modello a componenti è concepito per superare questa limitazione. A differenza di un oggetto, un componente è progettato ad un livello di astrazione più alto e fornisce una funzionalità o un servizio in modo completo. I componenti software sono quindi più disaccoppiati tra loro, e tramite le interfacce esposte, possono essere facilmente combinati insieme per costruire applicazioni sofisticate.

Strettamente legato al modello a componenti, tanto da poter dire che rappresentino le due facce di una stessa medaglia, è il modello a contenimento. Questo modello si basa su un’entità, detta container, che rappresenta l’ambiente standardizzato all’interno del quale eseguono i componenti. Oltre all’ambiente di esecuzione, il container può fornire molteplici servizi di supporto sia di base che più avanzati. Tra i servizi più comuni troviamo la gestione del ciclo di vita dei componenti, che vengono quindi attivati e disattivati ad opera del container, la ricezione delle richieste dai clienti e l’invio dei risultati, la gestione degli errori o di particolari eventi, l’implementazione di politiche di default. Servizi più avanzati possono riguardare il supporto alla sicurezza, alle transazioni, alla ricerca dei servizi.

Presenteremo di seguito le piattaforme più diffuse analizzandone analogie e differenze.


117

4.2 - Piattaforme enterprise Abbiamo detto che la realizzazione di applicazioni enterprise è supportata

tramite piattaforme che promuovono il modello multi-thier e si occupano di fornire un ambiente di esecuzione scalabile affidabile e sicuro ai componenti che eseguono nel container. Oltre a questo forniscono una serie di servizi di supporto avanzati quali sicurezza, transazioni, meccanismi di integrazione, gestione della persistenza, ricerca dei servizi etc.

Possiamo avere soluzioni di tipo proprietario e altre basate invece su standard aperti. I primi prevedono che il contratto su cui è basata l’interazione tra container e componenti sia definito in modo proprietario dal produttore della piattaforma. Le applicazioni costruite su questo tipo di piattaforma sono quindi fortemente legate alle specifiche proprietarie, con considerevoli costi di riconversione nel caso si voglia migrare l’applicazione su un’altra piattaforma. In questo modo l’azienda è indissolubilmente legata al fornitore della piattaforma, dando luogo al fenomeno indesiderabile detto vendor lock-in. Alcune delle soluzioni più conosciute in quest’ambito sono la tecnologia .NET, i cui standard sono dettati da Microsoft, o la tecnologia Web Sphere di casa IBM.

Nel caso delle soluzioni basate su standard aperti il container fornisce i servizi di sistema secondo una specifica ben definita in accordo a standard industriali. L’interfaccia standardizzata fornisce all’azienda la possibilità di scegliere tra numerosi prodotti server, tutti conformi alla medesima specifica. L’azienda può quindi selezionare configurazioni specificatamente studiate in base alle sue necessità, o decidere di migrare verso una nuova configurazione non appena la domanda interna o esterna lo richiedano. Il maggiore esempio di soluzione di questo tipo è rappresentato da Java Enterprise Edition (Java EE).

Sebbene Java EE rappresenti una soluzione molto completa ed esaustiva, non sempre le applicazioni necessitano dell’insieme completo di servizi che fornisce. In questo senso Java EE costituisce una soluzione monolitica, in cui tutte le sue funzionalità sono tirate in campo indipendentemente dalla loro necessità. Non solo, per garantire i servizi di supporto il container s’inserisce in modo consistente all’interno delle interazioni tra i componenti, introducendo un considerevole livello di indirettezza. Si tratta di un approccio a “container pesante” che si contrappone a quello detto “container leggero” tipico di altre piattaforme come ad esempio Spring. Quest’ultimo rappresenta un framework open source per la realizzazione di applicazioni su piattaforma Java, che si contraddistingue per flessibilità e modularità in quanto permette di selezionare le funzionalità applicative necessarie combinandole a formare un container che comprende le sole funzionalità essenziali.

Nel seguito descriveremo le tecnologie .Net, Java Enterprise Edition e Spring, come esempi di piattaforme enterprise con caratteristiche molto differenti tra loro, consci del fatto che l’ambito delle piattaforme enterprise rappresenta uno scenario molto ampio e variegato.


118

4.2.1 Microsoft .NET Microsoft .NET rappresenta in senso più ampio la strategia perpetrata da

Microsoft in risposta alla piattaforma Java, e costituisce una suite di prodotti per la realizzazione di sistemi sia client e sia server, in ambito Internet ed Intranet. Il cuore di della suite .NET è rappresentato dal Framework .NET, la piattaforma di esecuzione che permette di combinare tra loro la gamma di tecnologie destinate allo sviluppo di applicazioni enterprise e non. Il Framework .NET è composto fondamentalmente da un motore di esecuzione virtuale, il Common Language Runtime (CLR), una libreria di classi detta Base Class Library (BCL), e da un insieme di servizi run-time usati nello sviluppo e nell’esecuzione delle applicazioni .NET.

Il CLR rappresenta un ambiente di esecuzione virtuale che gestisce i requisiti per l’esecuzione delle applicazioni. Fornisce l’astrazione di una macchina virtuale in modo che il programmatore non debba tenere in considerazione le caratteristiche della macchina sottostante. Le applicazioni che eseguono all’interno dell’ambiente CLR sono dette applicazioni managed. Le applicazioni .NET sono sviluppate quindi usando codice managed, cioè che verrà eseguito all’interno del CLR. Il CLR fornisce inoltre servizi aggiuntivi quali meccanismi di sicurezza, gestione della memoria e delle eccezioni, e altri. Introducendo un livello di astrazione tra il sistema operativo e le applicazioni permette la portabilità delle applicazioni sulle differenti versioni di sistema operativo Windows. Lo sviluppatore può inoltre utilizzare un’ampia scelta di linguaggi di programmazione che sono poi compilati in un Common Intermediate Language (CIL) per essere eseguiti dal CLR, analogamente a quanto avviene in ambito Java in cui il codice viene compilato in Java Bytecode per essere eseguito dalla Java Virtual Machine.

La Base Class Library (BCL) fornisce un insieme fondamentale di classi che copre un ampio spettro di necessita e di aree: lo sviluppo di interfacce grafiche per dispositivi sia desktop che mobili, l’accesso ai dati e la connettività con i database, la comunicazione di rete, ect.

Al di sopra della BCL troviamo le tecnologie per lo sviluppo delle applicazioni .NET enterprise. Queste includono librerie e servizi raggruppati secondo il livello applicativo d’interesse. In particolare si suddividono in Rich Client e Rich Internet Application, destinate allo sviluppo di Client di tipo desktop e Web particolarmente interattivi e dinamici, Data Access per la gestione del livello di persistenza, Services che racchiude le tecnologie per la realizzazione dei Web Services, Workflow che si occupa di realizzare la business logic dell’applicazione, Web Applications in cui troviamo le tecnologie per la realizzazione delle applicazioni Web e il modulo Mobile Applications destinato ai dispositivi mobili e che contiene anche il Microsoft .NET Compact Framework descritto precedentemente nella sezione 3.1.4.1. La piattaforma d’esecuzione descritta è rappresentata in Figura 38.


119

Figura 38 - Architettura del Framework .NET 4.0.

Di seguito ci concentreremo sui livelli Web Application, Workflow, Services e Data Access che sono i più pertinenti all’ambito delle applicazioni enterprise.

4.2.1.1 Web Applications ASP.NET rappresenta la tecnologia di realizzazione delle applicazioni Web su

server Microsoft. Prevede un insieme di funzionalità molto comuni come la gestione della sessione utente, autenticazione e autorizzazione, la generazione dinamica dei contenuti Web.

ASP.NET Web Forms è la tecnologia standard per la progettazione di interfacce grafiche per applicazioni Web. Un’applicazione ASP.NET Web Forms esegue all’interno di un Web server e non richiede nessun componente installato sulla macchina client. Permette la creazione di pagine ASPX che includono sia tag HTML standard e sia tag custom che vengono mappati in componenti detti Web Control. I Web Control incapsulano logica riusabile relativa alla presentazione e forniscono funzionalità avanzate per facilitare la programmazione Web. ASP.NET Web Forms prevede inoltre due estensioni che supportano le tecnologie Asynchronous JavaScript and XML (AJAX) e Silverlight, tramite cui sviluppare applicazioni Web altamente interattive e dinamiche.

ASP.NET MVC invece permette la creazione di applicazioni ASP.NET basate sul pattern Model-View-Controller (MVC). Permette quindi di ottenere una maggiore separazione tra le informazioni di presentazione e la logica di business e facilita inoltre il testing dei componenti.

4.2.1.2 Workflow e Services Nella piattaforma .NET i componenti di business sono realizzati come semplici

componenti managed. Questi sono combinati per formare la logica di business dell’applicazione enterprise tramite il concetto di Workflow. La tecnologia Windows Workflow Foundation (WF) permette di implementare i workflow basati su macchine di tipo sequenziale, cioè con un flusso di esecuzione prevedibile, o dotate di stato, in cui il tipo di comportamento dipende dallo stato della macchina. La tecnologia WF è inoltre integrata con il livello Services permettendo di esporre i workflow tramite Web Services.


120

Il livello Services permette invece la creazione di applicazioni basate su Web-Service. La tecnologia Windows Communication Foundation (WCF) è progettata per offrire un approccio semplice all’elaborazione distribuita e fornisce un elevato livello interoperabilità. Supporta un grande numero di protocolli tra cui HTTP, TCP e Microsoft Message Queuing per i sistemi di messaggistica.

4.2.1.3 Data Access Le tecnologie del modulo Data Access sono concepite per facilitare l’accesso

delle applicazioni al livello di persistenza.

La tecnologia ActiveX Data Object (ADO.NET) racchiude un insieme di funzionalità per l’accesso ai dati basati su modello relazionale. Le funzionalità base, ADO.NET Core, permettono le operazioni più semplici quali recupero, aggiornamento e gestione dei dati per comunicare con un qualsiasi database dotato di un provider ADO.NET. L’ADO.NET Entity Framework fornisce la funzionalità di mapping Object-Relational e permette agli sviluppatori di definire un mapping ai dati relazionali flessibile che isola le applicazioni dalle modifiche dello schema di archiviazione sottostante.

Il Language Integrated Query (LINQ) rappresenta una libreria che permette di utilizzare linguaggi come C# e Visual Basic per effettuare interrogazioni al database. LINQ to SQL, in particolare, rappresenta una soluzione specifica per i server di tipo Microsoft SQL Server. In combinazione con la tecnologia ADO.NET Entity Framework, permette di effettuare le query direttamente sugli oggetti di business.

ADO.NET Data Services Framework permette inoltre di esporre dati presenti su database compatibili LINQ direttamente tramite RESTful Web Service. I servizi, acceduti tramite protocollo HTTP, forniscono i dati formattati secondo la notazione JSON.

4.2.1.4 Applicazioni enterprise Nel seguito analizzeremo la struttura tipo di un’applicazione .NET enterprise. È

distribuita su un Web Server, che realizza il layer di presentazione, un Application Server che realizza il middle-tier e infine un Database Server che si occupa della persistenza dei dati, come rappresentato in Figura 39. Sul lato client possiamo ipotizzare l’accesso all’applicazione tramite un Web browser.

Nel layer di presentazione troviamo una serie di componenti di tipo ASP.NET Web Forms che si occupano della generazione delle pagine HTML e della ricezione dell’input dell’utente. Sono combinati con opportune classi di supporto, dette Code-Behind Classes, responsabili di interpretare gli eventi scatenati dall’utente e invocare i servizi del livello di business.

Il livello di business logic è realizzato da componenti .NET managed, che eseguono quindi all’interno dell’ambiente CLR. Quest’ultimo fornisce ai componenti i servizi di supporto quali la gestione delle transazioni, della sicurezza e dell’accesso remoto dei servizi. I componenti possono inoltre essere combinati tra loro in un ambiente grafico tramite la tecnologia WF.


121

Infine, il data layer permette l’accesso trasparente alle diverse sorgenti di dati. Tramite la tecnologia ADO.NET è possibile astrarre dal particolare database sottostante. Si occupa inoltre di fornire la connettività al database gestendo il pooling delle connessioni, la possibilità di eseguire gli statement di accesso, e il mapping delle strutture relazionali all’interno del database in componenti object-oriented.

Figura 39 - Architettura di una applicazione enterprise .NET.

In conclusione, caratteristica peculiare del Framework .NET è quella di utilizzare in modo estensivo il concetto di componente software per aumentare la modularità, e di includere molte funzionalità progettate espressamente per integrarsi in un ambiente Internet. È corredato inoltre da una serie di strumenti di sviluppo delle applicazioni altamente integrati all’interno della piattaforma, tra cui l’IDE Visual Studio.

4.2.2 Java Enterprise Edition La Java Platform, Enterprise Edition, abbreviata Java EE, è una tecnologia che

estende la piattaforma Java Standard Edition (Java SE) per fornire un approccio basato su componenti per la progettazione, lo sviluppo il dispiegamento di applicazioni enterprise. Conosciuta precedentemente all’attuale versione 5 come Java 2 Enterprise Edition, o J2EE, nasce ad opera della Sun Microsystems, in seguito all’affermarsi della piattaforma Java in ambito server, per raccogliere e unificare le varie tecnologie di tipo enterprise in un’unica piattaforma che fornisce interfacce vendor-independent per accedere a diversi tipi di sistemi e servizi. I prodotti conformi allo standard Java EE permettono agli sviluppatori di concentrarsi sulla realizzazione della logica di business, dell’interfaccia utente, e dell’accesso alle informazioni occupandosi di fornire servizi quali sicurezza, gestione delle transazioni, ricerca di componenti e risorse, connessione al database, pooling delle risorse e altri ancora.

La sua adozione offre numerosi vantaggi in quanto permette alle aziende di sviluppare prodotti che possono essere eseguiti su ogni sistema che supporti la piattaforma Java EE, evitando il pericolo del vendor lock-in, e di scegliere il prodotto più adatto e produttivo in funzione dei propri requisiti. La piattaforma promuove inoltre un chiaro partizionamento logico delle applicazioni secondo il naturale modello


122

multi-tier che caratterizza le applicazioni enterprise. Migliora inoltre la produttività permettendo agli sviluppatori di concentrarsi sui processi di business piuttosto che costruire l’infrastruttura di supporto.

4.2.2.1 Architettura L’architettura multi-tier proposta da Java EE, rappresentata in Figura 40, è

composta da quattro livelli. Il primo è rappresentato dal Client-tier, che interagisce direttamente con l’utente finale visualizzando le informazioni e raccogliendo gli input dell’utente. La piattaforma Java EE supporta diverse tipologie di client, sia di tipo Web-based come HTML e Java applet e sia applicazioni Java standard. Il Web-tier realizza la logica di presentazione e riceve l’input dell’utente dai Client di tipo Web. Sulla base delle richieste ricevute dall’utente richiama i servizi di business necessari all’elaborazione e genera quindi la risposta appropriata. Nella piattaforma Java EE il livello Web è realizzato dalle tecnologie JSP e Servlet, che eseguono all’interno di un container Web. Il Business-tier gestisce la business logic dell’applicazione tramite un insieme di componenti di business che si avvalgono dei servizi di supporto offerti dalla piattaforma. I componenti di business sono implementati da componenti di tipo Enterprise Java Bean (EJB), uno standard per lo sviluppo di componenti server riusabili, che supportano servizi di persistenza, processi di business, transazioni e elaborazione distribuita. I componenti EJB eseguono all’interno di un container EJB che ne gestisce il ciclo di vita, l’allocazione delle risorse, e altri servizi di supporto. L’EIS-tier, dove EIS sta per Enterprise Information Systems, è responsabile dei sistemi di gestione delle informazioni, inclusi i database, sistemi di gestione delle transazioni, sistemi legacy e sistemi di pianificazione delle risorse. Rappresenta il livello in cui l’applicazione Java EE si integra con sistemi esterni.

Il business-tier e il web-tier eseguono sul lato server all’interno della piattaforma Java EE, e sono per questo solitamente raggruppati all’interno di un livello detto Middle-tier. All’interno del middle-tier troviamo anche una serie di servizi di supporto quali JMS e JNDI che descriveremo in seguito.

Figura 40 - Architettura multi-tier Java EE.


123

4.2.2.2 Componenti e container Il container Java EE supporta i componenti dell’applicazione all’interno del

middle-tier fornendo un ambiente di esecuzione standard. I componenti che possiamo trovare al suo interno sono molteplici. Quelli più semplici sono rappresentati dalle applicazioni Java standard e le Applet, piccoli programmi Java eseguibili all’interno di un browser.

Servlet e Java Server Pages (JSP) sono componenti appartenenti al livello Web che eseguono in un Web container e forniscono meccanismi per la generazione dinamica dei contenuti, l’elaborazione e la formattazione delle informazioni relativamente alla presentazione. Le servlet sono classi Java in grado di ricevere le richieste provenienti dai client, generare dinamicamente la risposta (eventualmente coinvolgendo i componenti del business-tier), ed inviarla al client ad esempio in un documento HTML. La tecnologia Java Server Pages fornisce un modo estensibile per generare contenuti dinamici per un client Web. Sono rappresentate da documenti contenenti sia codice HTML sia codice Java, oltre a speciali tag xml, che descrivono come processare le richieste. Possono inoltre al loro interno richiamare le funzionalità di business incapsulate dagli EJB per realizzare elaborazioni complesse. Servlet e JSP eseguono all’interno del Web container che, oltre alle funzionalità standard quali la gestione del ciclo di vita, fornisce i servizi di rete per ricevere le richieste, decodificarle, formattare ed inviare le risposte. Il principale protocollo supportato è HTTP, ma sono possibili anche altri protocolli.

I componenti EJB invece sono componenti a granularità grossa scalabili e transazionali per la realizzazione delle logiche di business, ed eseguono all’interno di un container EJB. Anche detti enterprise bean, possono essere di due tipologie: session bean e message-driven bean.

I session bean permettono di realizzare processi di elaborazione e flussi di lavoro, e rappresentano una conversazione transiente con un client in quanto non possono essere ripristinati in seguito ad un malfunzionamento del container. Possono essere stateful o stateless. I primi sono usati quando è necessario conservare informazioni di stato tra le diverse richieste di servizio provenienti dal client e sono pertinenti a una singola sessione utente, mentre i secondi non mantengono alcuna informazione e permettono quindi una gestione più efficiente da parte del sistema.

I message-driven bean combinano le caratteristiche di un session bean con quelle dei listener previsti dalla specifica JMS (precedentemente descritta nella sezione 2.3.2), giacché permettono ai componenti di business di ricevere messaggi JMS in modo asincrono. Questi bean sono sempre più frequentemente utilizzati all’interno delle installazioni Java EE come strumenti per integrare sistemi differenti, poiché favoriscono il disaccoppiamento tra i sistemi.

Un terzo tipo di bean, previsto nelle specifiche precedenti di Java EE ma ormai deprecato nella versione 6, era rappresentato dagli entity bean, attualmente rimpiazzati da componenti detti entity e previsti dalla specifica Java Persistence API. Ad ogni modo lo scopo di questi componenti è analogo. Si tratta di oggetti persistenti che rappresentano i dati memorizzati in una singola riga di un database relazionale. Se il


124

client termina o il server cade, i servizi sottostanti assicurano che i dati al suo interno siano stati salvati. Generalmente i session bean utilizzano gli entity bean per salvare informazioni in database.

4.2.2.3 Servizi La piattaforma Java EE specifica una serie di servizi che ogni prodotto

conforme allo standard deve garantire.

L’API Java Database Connectivity (JDBC) fornisce la connettività al database indipendentemente dalla specifica tipologia di database sottostante. Nella maggior parte dei casi si tratta di un DBMS relazionale, acceduto tramite linguaggio SQL. Le API si occupano di gestire le connessioni con il database e le transazioni, inviare gli statement SQL e ricevere i risultati e altre funzionalità correlate.

Java Transaction API (JTA) permette di fornire il supporto alla gestione delle transazioni in modo indipendente dalla specifica implementazione. JTA specifica un’interfaccia standard tra un gestore delle transazioni e le parti coinvolte in un sistema transazionale distribuito: il gestore delle risorse, l’application server, e le applicazioni transazionali.

Java Naming and Directory Interface (JNDI) rappresenta un’interfaccia standardizzata per l’accesso a servizi di naming e directory distribuiti. Si tratta di servizi che permettono di immagazzinare e recuperare determinate risorse partendo da un nome univoco che gli è stato assegnato.

Java EE Connector Architecture fornisce un’architettura standard per l’integrazione con Enterprise Information System eterogenei quali sistemi di Enterprise Resource Planning (ERP), sistemi di Transaction Processing (TP), database ed applicazioni legacy scritte in linguaggi diversi da Java. Tramite degli adapter standard permette di risolvere il problema delle interfacce vendor-specific che caratterizzavano questi sistemi e che dovevano essere adattate allo specifico application server caso per caso.

Java EE Security rappresenta il servizio di sicurezza fornito a tutte le tipologie di componenti Java EE da parte dei container stessi all’interno di cui eseguono. È prevista la gestione della sicurezza in modo dichiarativo, cioè tramite descrittori di deployment esterni all’applicazione ed espressi in XML, tramite annotazioni apposte al codice sorgente dei componenti stessi, oppure in modo programmatico, cioè incorporando all’interno dell’applicazione il codice necessario a prendere decisioni riguardanti le politiche di sicurezza. I primi due rappresentano meccanismi molto flessibili e versatili, mentre il terzo è solitamente utilizzato quando gli altri due non sono sufficienti a esprimere il modello di sicurezza di un’applicazione.

Java API for XML Web Services (JAX-WS) e Java API for RESTful Web Services (JAX-RS) rappresentano due tecnologie per la realizzazione di Web Service basate rispettivamente su protocolli SOAP e REST. Permettono di nascondere i dettagli relativi al protocollo sottostante e di definire le interfacce del servizio direttamente in linguaggio Java. Entrambi utilizzano uno stile di programmazione basato su annotazioni.


125

Java Persistence API è il framework di gestione della persistenza che facilita l’operazione di mapping tra il mondo a oggetti della piattaforma Java e il mondo relazionale basato su tabelle che caratterizza i database. Fornisce inoltre un linguaggio specifico per le interrogazioni del database e diverse funzionalità di supporto.

Infine, altro servizio fondamentale è Java Message API (JMS), già descritto nella sezione 2.3.2, che definisce un’interfaccia standardizzata per i sistemi a scambio di messaggi e specifica le entità coinvolte e la struttura dei messaggi.

In questo quadro Java EE rappresenta una soluzione molto ampia e completa, capace di coprire ogni necessità. Rappresentando uno standard permette inoltre la scelta fra diversi prodotti commerciali che ne forniscono una implementazione. Tuttavia presenta come difetto quello di essere una soluzione monolitica, che non offre la possibilità di selezionare un sottoinsieme di funzionalità di interesse.

4.2.3 Spring Spring rappresenta un framework altrettanto popolare per lo sviluppo di

applicazioni enterprise basate su linguaggio Java. Permette di realizzare applicazioni altamente performanti e facilmente testabili promuovendo allo stesso tempo il riuso dei componenti. Si tratta di una piattaforma open-source inizialmente sviluppata da Rod Johnson, sviluppatore di applicazioni enterprise con alle spalle innumerevoli progetti commerciali di successo, contestualmente alla stesura della pubblicazione “Expert One-on-One Java EE Design and Development”, in cui esprime il suo disappunto riguardo lo stile di programmazione imposto dal framework Java EE, e la necessità di un’architettura più leggera e meno vincolante, capace di rendere più snella l’interazione tra i diversi componenti di un’applicazione Java EE. La prima versione del framework è rilasciata nel 2003 con licenza Apache 2.0. Spring è considerato, rispetto a molte altre piattaforme tra cui Java EE, un container “leggero”. Quest’aggettivo è riferito a diversi aspetti che lo caratterizzano.

In primo luogo, la sua architettura è organizzata secondo uno stile altamente modulare. Pur offrendo un numero sostanziale di funzionalità e di estensioni, è possibile utilizzare solo quelle strettamente necessari e ignorare le restanti. La versione base del framework, che potremmo chiamare “core”, occupa meno di 1 MB su disco. Tuttavia non si tratta solo di un vantaggio per lo sviluppatore, che deve preoccuparsi di gestire solo un set minimo di librerie e di funzionalità, ma anche di un vantaggio a tempo di esecuzione, in quanto il container provvederà a fornire solo le funzionalità strettamente necessarie, risultando così più leggero ed efficiente dal punto di vista computazionale.

Altro elemento fondamentale è lo stile di programmazione. Spring permette di sviluppare componenti di livello enterprise usando semplici Plain Old Java Object (POJO), ovvero oggetti Java ordinari che non estendono classi specifiche o implementano interfacce particolari dettate dal framework. Si tratta di una caratteristica che risaltava soprattutto se confrontata con la specifica EJB 2.0, in cui i bean dovevano estendere classi definite dalla specifica J2EE ed essere accompagnati da opportuni file di configurazione che rendevano la programmazione pesante e incline agli errori. Nonostante la specifica EJB 3.0 migliori notevolmente


126

quest’aspetto, è ancora evidente una differenza sostanziale: mentre i componenti EJB devono necessariamente eseguire all’interno di un container EJB, e quindi in un application server, i componenti Spring non necessitano di alcun container particolare e possono essere quindi eseguiti all’interno di un normale server web. Da ciò consegue anche una notevole facilità di eseguire le operazioni di testing dei componenti.

Infine, i cosiddetti container “pesanti” sono caratterizzati da un maggiore livello d’indirezione tra i componenti, in quanto il container, per fornire molti dei servizi di supporto, deve intervenire ad ogni interazione tra essi per assolvere ai servizi necessari. In Spring, questo modello è molto semplificato, sia perché prevede normalmente un’interazione diretta tra i componenti, sia perché, quando necessario, provvede a inserire come abbiamo detto solo le funzionalità strettamente necessarie.

Nonostante le funzionalità basilari del framework permettano di sviluppare qualsiasi applicazione Java, vi sono numerose estensioni che supportano lo sviluppo di applicazioni Web ed enterprise sulla base della piattaforma Java EE. Il framework Spring punta a rendere più semplice lo sviluppo di applicazioni J2EE e promuovere uno stile di programmazione basato su POJO. Per questo motivo Spring si pone sia come sostituto sia come alternativa che come complemento a J2EE.

L’intero framework è basato essenzialmente su due elementi chiave: l’Inversion of Control, detta Dependency Injection nell’ambiente Spring, e l’Aspect Oriented. Su di queste due funzionalità se ne sviluppano altre non meno importanti nell’ambito delle applicazioni enterprise: il supporto alla persistenza, l’integrazione con il livello Web, supporto alle transazioni, alla sicurezza, al testing e altre ancora.

4.2.3.1 Dependency Injection L’Inversion of Control è un pattern di programmazione molto generale che

prevede lo spostamento del flusso di esecuzione dall’applicazione al framework. È lo stesso principio utilizzato in molti framework grafici, in cui lo sviluppatore deve preoccuparsi di implementare solo degli handler di risposta all’utente, mentre il controllo del flusso applicativo è demandato al framework. È spesso riassunto nel cosiddetto Hollywood Principle: “Don’t call me, I’ll call you.” (letteralmente “Non chiamarmi, ti chiamerò io”), a significare che non è il codice applicativo a richiedere direttamente ad una libreria le funzionalità di cui ha bisogno, ma è piuttosto il framework ad invocare il codice applicativo quando necessario tramite metodi appositi.

In Spring i principi di IoC sono utilizzati per implementare una particolare tecnica, il cui nome è stato coniato dallo stesso team di sviluppo Spring, detta Dependency Injection (DI). Questa forma di IoC mira a rimuovere le dipendenze esplicite tra i componenti applicativi demandandone la gestione al framework sottostante, che si occupa di effettuarne il binding effettivo tra i componenti. Ciò può essere realizzato in diversi modi, ad esempio tramite gli argomenti dei costruttori o tramite metodi setter.

Quindi, se nei framework tradizionali sono i componenti applicativi a rivolgersi al framework sottostante quando hanno bisogno di un particolare componente, con la DI è il framework stesso a “iniettare” all’interno dei componenti le dipendenze


127

opportune. Eliminando le dipendenze esplicite favorisce quindi le possibilità di riuso e facilita le operazioni di testing.

4.2.3.2 Aspect Oriented Programming La seconda funzionalità alla base del framework Spring è il supporto all’Aspect

Oriented Programming (AOP). Spesso alcune funzionalità applicative rappresentano aspetti trasversali che interessano molteplici componenti e moduli, devono essere coinvolte in diversi punti dell’applicazione e sono concettualmente separati dalla logica di business in senso stretto. Ne sono esempi comuni la gestione delle transazioni, del logging, della sicurezza, del caching etc.

Mentre l’unità fondamentale dell’Object Oriented Programming è rappresentata dalle classi, nell’AOP l’unità di modularità è costituita dagli aspetti, cioè dalle funzionalità trasversali comuni a più componenti dell’applicazione. Mentre la DI favorisce il disaccoppiamento dei componenti, l’AOP permette di disaccoppiare gli aspetti dalle funzionalità di business dei componenti. In questo modo è possibile gestire le funzionalità trasversali in modo trasparente ai componenti applicativi cui sono applicati.

Il modulo AOP di Spring fornisce un’implementazione del modello aspect-oriented permettendo di definire intercettori di metodi e punti di inserimento degli aspetti.

4.2.3.3 Architettura Il framework Spring consiste di molteplici funzionalità organizzate in circa 20

moduli. Questi sono raggruppati all’interno di sei macro contenitori: Core Container, Data Access/Integration, Web, AOP, Instrumentation e Test, come mostrato in Figura 41.

Figura 41 - Architettura del framewrok Spring.

Di seguito illustreremo le funzionalità e le caratteristiche di ognuno dei moduli.


128

4.2.3.3.1 - Core Container

Il Core Container consiste dei moduli Core, Beans, Context e Expression Language. I moduli Core e Bean forniscono le parti fondamentali del framework, incluse le funzionalità di IoC e Dependency Injection. Un componente particolare, denominato BeanFactory, costituisce una sofisticata implementazione del pattern factory che permette il disaccoppiamento tra la specifica delle dipendenze e la logica applicativa.

Il modulo Context, costruito sulla base dei due moduli precedenti, fornisce l’accesso ai componenti applicativi secondo una modalità basata su registry, simile a quella fornita dai normali framework. Aggiunge alle funzionalità del modulo Bean il supporto alla propagazione degli eventi, al caricamento delle risorse, e alla creazione trasparente dei contesti tramite, ad esempio, un servlet container. Supporta inoltre alcune funzionalità Java EE quali EJB, JMX e il remoting di base. Il componente fondamentale del modulo è rappresentato dall’interfaccia ApplicationContext. Il modulo Expression Language fornisce un potente linguaggio per interrogare e manipolare a tempo di esecuzione un grafo di oggetti. Supporta lettura e scrittura delle proprietà, l’invocazione di metodi, l’accesso a vettori e collezioni, operatori aritmetici e il recupero di componenti dal container IoC Spring.

4.2.3.3.2 - Data Access/Integration

Il livello di Data Access//Integration consiste dei moduli JDBC, ORM, OXM, JMS, e Transaction.

Il modulo JDBC, come nel caso Java EE, fornisce un livello di astrazione che facilita la scrittura del codice JDBC per l’accesso al database e rimuove la necessità di tradurre i codici di errore specifici del vendor del database.

Il modulo ORM supporta l’integrazione con i più diffusi framework per il mapping tra il mondo a oggetti e quello relazionale, come JPA, JDO e Hibernate. Permette di usare questi framework in combinazione con le altre funzionalità offerte da Spring, come ad esempio la gestione dichiarativa delle transazioni.

Il modulo OXM fornisce un layer di astrazione che supporta le implementazioni dei framework di mapping tra mondo ad oggetti e XML come JAXB, XMLBeans e XStream. Il modulo Java Messaging Service (JMS) implementa la specifica Java per i sistemi a scambio di messaggi. Il modulo Transaction, infine, supporta la gestione delle transazioni, sia in maniera programmatica e sia dichiarativa, per tutti i componenti applicativi.

4.2.3.3.3 - Web

Il livello Web consiste dei moduli Web, Web-Servlet, Web-Struts, e Web-Portlet.

Il modulo Web fornisce l’integrazione con funzionalità web-orientented di base, come l’upload di file tramite messaggi multipart o l’inizializzazione del container IoC tramite servlet listener. Inoltre contiene le funzionalità di supporto all’accesso remoto relative al contesto web.


129

Il modulo Web-Servlet contiene un’implementazione del pattern Model-View-Controllert (MVC) per le applicazioni web. Il framework Spring MVC promuove una netta separazione tra il modello del dominio e quello di presentazione web, e s’integra inoltre con tutte le altre funzionalità del framwork Spring.

Il modulo Web-Struts contiene le classi di supporto per l’integrazione tra un’applicazione Spring e un livello di presentazione web basato su tecnologia Struts. Sottolineiamo che tale soluzione è al momento deprecata in favore della tecnologia Struts 2.0 che supporta l’integrazione con Spring in modo nativo.

Il modulo Web-Portlet fornisce l’implementazione del pattern MVC da utilizzare in un ambiente basato su portlet rispecchiando le stesse funzionalità del modulo Web-Servlet.

Infine, un ulteriore modulo detto Web Services non rappresentato in figura permette la realizzazione, tramite semplici POJO e annotazioni, di Web Services basati sia su protocollo SOAP che REST. Facilita la definizione dei contratti di servizio e supporta molteplici strumenti per la manipolazione di payload XML.

4.2.3.3.4 - AOP, Instrumentation e Test

Il modulo Spring AOP fornisce un’implementazione del modello di programmazione Aspect-Oriented conforme alle specifiche dello standard AOP-Alliance [AOP01], che mira all’interoperabilità tra le implementazioni Java EE nell’ambito dell’AOP. Il modulo Aspects fornisce inoltre integrazione con AspectJ, un potente e maturo framework AOP basato su piattaforma Java.

Il modulo Instrumentation fornisce il supporto alla gestione e il monitoraggio dei componenti e delle applicazioni secondo le specifiche Java Management Extesion (JMX). Espone misure di performance fornendo quindi il controllo delle risorse del container a tempo di esecuzione. Il modulo Test infine supporta il testing dei componenti con framework molto diffusi quali JUnit.

Il framework Spring prevede molte altre estensioni non previste nella piattaforma iniziale. Spring Social, ad esempio, permette l’integrazione delle applicazioni con i social network più diffusi come Facebook e Twitter, funzionalità molto interessante nello scenario Web odierno. Altra estensione che riteniamo particolarmente interessante, soprattutto in riferimento al nostro scenario applicativo, è Spring for Android. Si tratta di un modulo che supporta lo sviluppo di applicazioni Android e l’integrazione con la piattaforma server fornendo un client Android di tipo REST e il supporto a protocolli di autorizzazione quali OAuth.

Spring rappresenta quindi uno strumento estremamente flessibile e versatile, che permette di configurare la soluzione più consona alle necessità applicative combinando un grande numero di soluzioni e servizi. Proprio perché non rappresenta uno standard come nel caso di Java EE, è possibile aggiungere estensioni anche per funzionalità non coperte da Java EE. Procediamo di seguito a mettere confrontare tra loro le diverse piattaforme presentate.


130

4.2.4 Confronto Il Framework .NET rappresenta un approccio d’insieme che raccoglie al suo

interno un largo spettro di tecnologie volte a semplificare lo sviluppo di ogni tipo di applicazione. La presenza di strumenti di sviluppo, come ad esempio Visual Studio, fortemente integrati con l’intera suite tecnologica, permette di affrontare il processo di sviluppo di una applicazione enterprise in tutti i suoi aspetti, senza bisogno di plug-in o librerie addizionali. Il supporto a un grande numero di linguaggi di programmazione permette inoltre agli sviluppatori di scegliere quello che più preferiscono, velocizzando ulteriormente il processo di sviluppo. Anche dal punto di vista delle applicazioni enterprise, rappresenta un approccio semplificato rispetto a Java EE, ad esempio perché non prevede alcuna tecnologia specifica per la realizzazione dei componenti di business, che sono realizzati come semplici componenti managed all’interno dell’ambiente CLR. Se questi aspetti possono contribuire a semplificare lo sviluppo delle applicazioni, danno luogo una soluzione meno completa e organica rispetto a quella di Java EE e Spring. Inoltre, .NET non fornisce supporto diretto a diversi meccanismi molto importanti come DI e AOP, che devono essere ottenuti facendo ricorso a framework esterni. Anche le tecnologie offerte sono meno flessibili e potenti rispetto a quelle che troviamo negli altri framework. Il framework ASP.NET MVC, ad esempio, prevede un solo tipo di componente Controller, a differenza di Spring che offre una vasta varietà di Controller secondo il grado di configurazione e di disaccoppiamento con la View che si vuole ottenere. Ancora, in ADO.NET l’interfaccia verso database di tipo Microsoft SQL Server o Microsoft Access è differente, mentre Spring e Java EE offrono la stessa interfaccia di interazione con qualsiasi tipo di database. Tuttavia, lo svantaggio più grande dell’architettura .NET è rappresentato dalla natura proprietaria e dalle forti limitazioni alla portabilità delle applicazioni, che possono essere eseguite solo sulle piattaforme di tipo Windows, a differenza di Java EE e Spring che offrono portabilità su ogni tipo di piattaforma.

La piattaforma Java EE costituisce un insieme completo di soluzioni che vanno dall’ambito Web con JSP e Servlet, alla business logic con gli EJB, alla persistenza con JPA. Fornisce un framework per lo sviluppo di Web Service basati sia su protocollo SOAP (JAX-WS) e sia su protocollo REST (JAX-RS). I servizi messi a disposizione dal container permettono di ridurre i costi di sviluppo delle applicazioni enterprise e di concentrarsi sulla business logic piuttosto che sull’infrastruttura. Il modulo EJB, ad esempio, gestisce la comunicazione distribuita, la scalabilità, il multithreading, le transazioni. In modo analogo Servlet e JSP semplificano lo sviluppo dei moduli Web fornendo supporto per la comunicazione e la gestione della sessione. Il modulo EIS fornisce inoltre diversi strumenti per l’integrazione di applicazioni e sistemi legacy. JMS permette l’integrazione tra applicazioni in modo disaccoppiato e asincrono. La tecnologia Java EE rappresenta inoltre un insieme di standard che può essere implementato da molti vendor, permettendo di scegliere tra una molteplicità di realizzazioni commerciali e assicurando la portabilità delle applicazioni Java EE.

Infine, l’attuale specifica EJB 3.0 si contraddistingue rispetto alla precedente EJB 2.0 per aver compiuto un grande sforzo di semplificazione del modello di programmazione (in parte mutuato anche da Spring), orientandosi all’uso di POJO e delle specifiche Java Persistence API (JPA). I componenti EJB 3.0 sono costituiti da


131

classi Java ordinarie che utilizzano semplici annotazioni e non hanno bisogno di alcun file di configurazione, mentre JPA permette di mappare facilmente gli oggetti Java in database relazionali, ereditando il modello proposto da famosi framework di persistenza quali Hibernate. Gli EJB 3.0 ricorrono inoltre, come Spring, all’utilizzo della DI per aumentare il disaccoppiamento tra i componenti ed eliminare il codice di lookup JNDI.

Spring è un potente framework che può rappresentare sia un’alternativa che un’integrazione a Java EE, e la sua struttura modulare lo rende meno intrusivo e più efficiente. Può gestire componenti relativi al middle-tier (Web e business logic) sia che si utilizzino le specifiche EJB o meno e soprattutto può essere utilizzato in un qualsiasi ambiente di esecuzione. Rende l’uso della tecnologia EJB una scelta implementativa piuttosto che un elemento determinante dell’architettura dell’applicazione, lasciando agli sviluppatori la libertà di scegliere di implementare le interfacce dei servizi come semplici POJO o come EJB, in modo assolutamente trasparente al chiamante dei servizi. I componenti Spring sono progettati per eliminare al minimo le dipendenze dalle API del framework. L’uso della DI favorisce il disaccoppiamento e rende le applicazioni molto facili da testare. Il framework AOP basato sulla piattaforma Java standard permette di risolvere molte problematiche come sicurezza e transazioni senza ricorrere all’uso di un container EJB e di un’implementazione JTA, abilitando queste funzionalità su semplici oggetti POJO. Fornisce inoltre un framework consistente per l’accesso ai dati usando sia JDBC sia soluzioni per il mapping O/R come Hibernate. Si tratta quindi di una soluzione che permette di affrontare lo stesso livello di complessità di Java EE senza ricorrere necessariamente a esso.

La differenza principale tra Spring e Java EE è rappresentata dal fatto che, mentre Java EE rappresenta una specifica, Spring costituisce un’implementazione. Mentre Java EE rappresenta una soluzione completa e pronta all’uso, il container Spring è costruito e configurato sulla base delle necessità applicative, dando luogo a una maggiore flessibilità e a un approccio più leggero. Inoltre Spring permette l’uso di estensioni che non sono parte dello standard Java EE. Da contro, mentre alcuni aspetti come sicurezza e transazioni sono pre-configurate in Java EE e automaticamente messe in campo, in Spring devono essere configurate appositamente per essere utilizzate. Entrambi forniscono un supporto completo allo sviluppo di Web Service basati su SOAP e REST e all’integrazione con altre applicazioni e sistemi legacy. Java EE fornisce un supporto più robusto alla gestione dello stato dei componenti di business tramite gli Stateful Session Bean, mentre nel caso di Spring questo meccanismo è ereditato implicitamente dalla gestione dello stato a livello di web container. Spring offre invece un supporto più completo all’AOP, tramite l’integrazione con AspectJ, mentre Java EE si limita a fornire il meccanismo degli intercettori di metodo con un approccio più semplicistico.

In ultima analisi Spring permette una maggiore flessibilità in molti aspetti dello sviluppo di un’applicazione rispetto a Java EE, soprattutto riguardo l’AOP, le transazioni e la sicurezza. Java EE fornisce minore flessibilità ma alcuni di questi aspetti non hanno bisogno di essere configurati e possono essere usati in modo più semplice, mentre .NET rappresenta una soluzione più limitata sotto molti punti di vista, sia per quanto riguarda la portabilità delle applicazioni e sia per le funzionalità


132

offerte. Spring fornisce inoltre un approccio più leggero e performante, in cui il ruolo del container è meno invasivo e integra al suo interno molti standard della piattaforma Java EE, come JTA, JDBC, JMS, ma non costituisce uno standard. Nei casi in cui standardizzazione e portabilità rappresentano caratteristiche chiave allora è opportuno prendere in considerazione Java EE. Tuttavia non bisogna dimenticare che un’applicazione Spring può essere tranquillamente eseguita anche all’interno di un container Java EE, integrandosi con esso. Inoltre, nonostante la portabilità sia il punto di forza dell’architettura Java EE, non sempre si rivela tale anche dal punto di vista pratico. In letteratura sono noti e documentati casi d’incompatibilità tra implementazioni diverse di uno stesso standard, come ad esempio nel caso mostrato dagli autori di [SEM12] in riferimento alla specifica JPA, in cui differenze anche minime nelle strategie utilizzate per il mapping su database possono compromettere il funzionamento dell’intera applicazione.

Per questi motivi riteniamo che Spring costituisca la scelta più valida nel nostro caso. In primo luogo poiché è in grado di garantire, a differenza di soluzioni proprietarie come .NET, un ottimo livello di portabilità e compatibilità verso diverse piattaforme, requisito molto importante in uno scenario enterprise variegato e dinamico. Al tempo stesso fornisce un ampio spettro di funzionalità altamente flessibili e configurabili, mantenendo però un approccio più leggero, e quindi con prestazioni più elevate, rispetto a Java EE.

Procederemo quindi nella sezione successiva a descrivere più in dettaglio le caratteristiche di questo framework e gli strumenti che offre per la realizzazione di applicazioni enterprise.

4.3 - Il framework Spring Nella sezione precedente abbiamo delineato l’architettura generale del

framework, composta dai moduli Core, che forniscono le funzionalità fondamentali del framework quali l’IoC, Data Access/Integration che fornisce l’accesso ai dati e le funzionalità di persistenza, il modulo AOP che implementa il paradigma della programmazione ad aspetti, il modulo Web per la realizzazione del livello di presentazione, ed infine i moduli Instrumentation e Test. Nel seguito procederemo ad analizzare prima le tecnologie di IoC e AOP che costituiscono il nucleo del framework, ed in seguito gli altri moduli che forniscono il supporto a funzionalità altrettanto importanti.

4.3.1 Container e IoC In questa sezione tratteremo dell’implementazione Spring del principio di

Inversion of Control. Come abbiamo spiegato nella sezione , Spring realizza una particolare tecnica di IoC, detta Dependency Injection, che permette ai componenti di dichiarare le loro dipendenze senza preoccuparsi di risolverle concretamente. È il container che si occupa di “iniettare” le opportune dipendenze al momento della creazione del bean, con un processo fondamentalmente inverso rispetto a quello


133

standard in cui è il componente stesso ad istanziare le sue dipendenze, da cui il nome Inversion of Control.

Le fondamenta del container IoC sono rappresentate dai package org.springframework.beans e org.springframework.context. L’interfaccia BeanFactory fornisce un meccanismo di configurazione avanzato capace di gestire ogni tipo di oggetto. Una particolare interfaccia, ApplicationContext, derivata da BeanFactory, permette di integrare ulteriori funzionalità quali Spring AOP e i meccanismi di pubblicazione degli eventi e di gestione delle risorse. Vi sono poi altri contesti specifici per determinati livelli applicativi come ad esempio il WebApplicationContext per le applicazioni web.

Gli oggetti che compongono la struttura applicativa e che sono gestiti dal container IoC sono chiamati bean nel gergo di Spring. Un bean è un oggetto che è istanziato, assemblato, e gestito dal container IoC di Spring. I bean e le dipendenze tra essi sono configurati dai metadati di configurazione usati dal container.

Il container Spring IoC è rappresentato dall’interfaccia org.springframework.context.ApplicationContext ed è responsabile di istanziare, configurare e assemblare i bean sulla base delle informazioni estratte dai metadati di configurazione. Tali metadati possono essere espressi tramite file XML, annotazioni Java, o codice Java e permettono di esprimere quali bean compongono l’applicazione e le interdipendenze tra di essi. Spring fornisce diverse implementazioni dell’interfaccia ApplicationContext a seconda del tipo di metadati che si vuole utilizzare. Ne sono un esempio il ClassPathXmlApplicationContext, che permette di utilizzare un file XML presente nel class path, o il FileSystemXmlApplicationContext che recupera i metadati da un file XML presente sul file system. Nonostante sia possibile, nella maggior parte degli scenari applicativi non è necessario codice applicativo che istanzi esplicitamente il container. Ad esempio, nel caso delle applicazioni web, la creazione del contesto avviene contestualmente alla creazione dell’applicazione grazie ad una opportuna configurazione dell’applicazione stessa. In è rappresentato il processo descritto di configurazione del sistema in cui le classi dell’applicazione sono combinate con i metadati di configurazione dal container per dare luogo a un sistema completamente configurato.

Figura 42 - Funzionamento del container IoC.


134

4.3.1.1 Metadati di configurazione Il container IoC Spring costruisce la struttura dell’applicazione sulla base di

metadati di configurazione. Tali metadati rappresentano uno strumento che permette agli sviluppatori di istruire come i bean che formano l’applicazione devono essere istanziati, configurati e combinati tra loro per formare l’applicazione completa.

Il modo tradizionalmente più utilizzato per esprimere tali metadati è il formato XML. Questo approccio permette quindi di separare la configurazione dal codice dei componenti, consentendo di modificare la configurazione senza compilare nuovamente le classi dell’applicazione. Altra modalità molto usata ma non altrettanto flessibile è quella delle annotazioni. In questo caso si ha il vantaggio di produrre codice più leggibile.

4.3.1.1.1 - Configurazione tramite XML

La configurazione basata su XML prevede l’utilizzo di uno o più tag <bean/> all’interno di un elemento radice <beans/>. Ogni elemento di tipo <bean/> definisce un bean dell’applicazione. I bean definiti corrispondono ai componenti dell’applicazione, tipicamente oggetti di servizio appartenenti alla business logic, al data layer o al livello di presentazione. Ma posiamo avere anche componenti specifici di un particolare framework quali ad esempio code JMS.

Il tag <bean/> fornisce inoltre gli attributi id e class. Il primo indica una stringa utilizzata per identificare il bean, mentre il secondo definisce la classe che costituisce il bean. All’interno del tag <bean/> è inoltre possibile indicare le dipendenze con gli altri bean o con particolari risorse per far sì che il container provveda ad iniettarli. Maggiori dettagli sulla Dependency Injection saranno dati nella sezione 4.3.1.4. Tramite il tag <import/> è inoltre possibile comporre tra loro diversi file di configurazione.

A partire dalla configurazione XML, per istanziare il container IoC Spring basta fornire ad una delle implementazioni dell’ApplicationContext una stringa che rappresenta il nome del file XML contenente i metadati.

4.3.1.2 Uso del container Una volta ottenuta un’istanza del container IoC opportunamente configurata, è

possibile ottenere recuperare da essa le istanze dei bean dell’applicazione. L’ApplicationContext rappresenta quindi un’interfaccia per una factory dalle capacità avanzate, capace di mantenere un dizionario dei bean e delle loro dipendenze, in cui a ogni nome identificativo corrisponde una precisa istanza del bean.

Tramite il metodo T getBean(String name, Class<T> requiredType) è possibile recuperare le istanze del bean. Tuttavia, in alcuni scenari, come quello web, non è necessario fare uso di questo metodo, in quanto è il container stesso che si occupa di iniettare le dipendenze, eliminando quindi ogni dipendenza dell’applicazione dalle API Spring.


135

4.3.1.3 Panoramica sui bean Il container Spring gestisce uno o più bean. Questi sono creati attraverso i

metadati di configurazione forniti al container nella forma, ad esempio, di definizioni XML <bean/>.

All’interno del container, questi metadati sono rappresentati da oggetti di tipo BeanDefinition, contenenti diverse informazioni tra cui il nome completo della classe che implementa il bean, diversi elementi che ne configurano il comportamento, l’indicazione delle dipendenze. A ognuna di queste informazioni corrisponde un insieme di proprietà che può essere specificata alla definizione del bean e che andremo a descrivere in questa sezione.

Oltre alla definizione dei bean l’implementazione dell’interfaccia ApplicationContext permette la registrazione di oggetti già esistenti creati dall’utente fuori dal container. Ciò è possibile tramite il metodo getBeanFactory() dell’ApplicationContext che restituisce la BeanFactory associata su cui è possibile registrare i bean.

4.3.1.3.1 - Istanziare i bean

La definizione del bean specifica anche come deve essere creato. Quando un bean viene richiesto, il container consulta la configurazione per conoscere le modalità di creazione del bean.

Usando la configurazione XML è specificata la classe dell’oggetto tramite l’attributo class dell’elemento bean. Questo attributo è solitamente obbligatorio. L’attributo class può essere utilizzato per specificare la classe da costruire nel caso in cui il container stesso crea il bean invocando il suo costruttore in maniera riflessiva. Un altro metodo è quello di specificare la classe di un oggetto che agisce da factory del bean, cioè un oggetto incaricato della sua costruzione. Tale classe deve quindi contenere un metodo statico che permette la creazione del bean.

Nel primo approccio, quello del costruttore, è possibile usare una qualsiasi classe senza requisiti particolari. A seconda del tipo di IoC che si usa tuttavia potrebbe essere necessario fornire un costruttore di default senza argomenti. Nel caso sia previsto un costruttore con argomenti, tramite le tecniche di Dependency Injection, illustrate nella sezione 4.3.1.4, è possibile specificare gli argomenti del costruttore che il container provvederà ad iniettare.

Per istanziare un bean attraverso il metodo statico di una factory, è necessario specificare all’interno dell’attributo class dell’elemento <bean/> la classe che realizza la factory, e utilizzare l’attributo factory-method per indicare lo specifico metodo statico da utilizzare per la creazione dell’istanza.

Un altro modo per istanziare i bean tramite factory fa invece uso di una factory con metodo non statico, e quindi di cui è stata precedentemente creata una istanza. Tale factory deve essere a sua volta un bean definito all’interno del container. Per usare questa modalità è necessario utilizzare, anziché l’attributo class, l’attributo


136

factory-bean, per indicare il nome del bean che funge da factory. Il metodo che crea l’istanza viene specificato come nel caso precedente.

4.3.1.4 Dipendenze Tipicamente i bean dovranno collaborare tra loro per raggiungere gli obiettivi

dell’applicazione, e avranno quindi delle associazioni tra loro, nel senso che un bean mantiene al suo interno un riferimento ad un altro bean, al fine di poterne invocare i servizi. In questo senso il bean ha una dipendenza da un altro bean. La Dependency Injection è il processo tramite il quale gli oggetti definiscono le loro dipendenze specificando solo gli argomenti dei loro costruttori, dei loro metodi factory, o proprietà che sono impostate sull’istanza dell’oggetto dopo che l’oggetto è stato creato. Il container di conseguenza inietta queste dipendenze quando crea il bean, con un procedimento fondamentalmente inverso a quello in cui è il bean a istanziare o recuperare di sua iniziativa le dipendenze. In questo modo gli oggetti non conoscono la reale classe o la locazione delle loro dipendenze.

La DI può essere di due tipi: Constructor-based, cioè basata su costruttore, o Setter-based, cioè basata su particolari metodi detti metodi “setter”. Spring permette inoltre di iniettare sia altri bean e sia valori primitivi di campi all’interno di un bean.

4.3.1.4.1 - Constructor-based DI

La Constructor-based DI prevede che il container inietti le dipendenze invocando il costruttore e specificando un certo numero di argomenti che rappresentano le dipendenze del bean. Un metodo analogo è rappresentato da quello di un metodo statico di una factory a cui sono forniti gli argomenti necessari a costruire il bean. Viene realizzato utilizzando l’elemento <constructor-arg/> all’interno dell’elemento <bean/>, all’interno del quale è possibile indicare il nome univoco del bean da iniettare tramite l’attributo ref, o il valore di un campo tramite l’attributo value.

La corrispondenza tra gli elementi <constructor-arg> e gli argomenti del costruttore è ricavata dal container sulla base del tipo dei parametri. Nel caso in cui non vi siano potenziali ambiguità negli argomenti del costruttore, l’ordine in cui gli argomenti sono definiti è l’ordine con cui sono forniti al costruttore quando il bean è istanziato. Nei casi di ambiguità, ad esempio perché si usa un argomento di tipo primitivo, o perché sono dello stesso tipo, è necessario fare ricorso a attributi aggiuntivi dell’elemeto <constructor-arg> quali type, che permette di indicare il tipo a cui fa riferimento un argomento, e index, che permette di indicare la posizione dell’argomento nella signature del costruttore.

Tuttavia, all’interno della comunità di sviluppatori, la modalità di DI più usata è quella basata su metodo setter.

4.3.1.4.2 - Setter-based DI

La Setter-based DI è realizzata dal container facendo affidamento su metodi dei bean opportunamente definiti detti setter. In questo caso questi metodi sono invocati


137

successivamente alla creazione del bean che deve quindi fornire un costruttore o un metodo factory senza argomenti.

I metodi setter sono particolari metodi che hanno lo scopo di fornire l’accesso in scrittura agli attributi di una classe. Permettono di sovrascrivere il valore di un attributo con il valore fornito come parametro. Seguono una particolare signature: il nome del metodo è dato apponendo il prefisso “set” al nome dell’attributo, e il tipo parametro è dello stesso tipo dell’attributo che sovrascrivono. Se ad esempio una qualsiasi classe ha un attributo di nome bar di tipo Foo, il corrispondente metodo setter è public void setBar(Foo foo). L’implementazione del metodo provvede a sovrascrivere l’attributo corrispondente della classe con il nuovo valore: this.foo=foo;. Sono duali ai metodi getter che forniscono accesso in lettura, non hanno argomenti e restituiscono il valore dell’attributo (es. public Foo getBar()). La coppia getter/setter di un attributo individua quella che viene chiamata proprietà di una classe.

Tornando alla Setter-based DI, la classe deve definire opportunamente i metodi setter per tutte le dipendenze che devono essere iniettate. Inoltre nel file di configurazione all’interno dell’elemento <bean/> è necessario inserire un elemento <property/> per ognuna delle dipendenze da iniettare, che tramite l’attributo ref specifica il nome del bean da iniettare e tramite l’attributo name specifica il nome dell’attributo. Nel caso si tratti invece di valori primitivi si utilizza invece l’attributo value al posto di ref.

L’ApplicationContext supporta entrambe le modalità, Setter-based e Constructor-based. È possibile inoltre combinarle iniettando alcune dipendenze tramite metodi setter dopo che altri sono stati iniettati tramite costruttore all’atto della creazione. Tuttavia lo stesso team di sviluppo Spring raccomanda l’uso della Setter-based DI in quanto il numero di costruttori può diventare difficile da gestire, ad esempio quando ve ne sono alcuni opzionali. Inoltre i metodi setter rendono possibile successive riconfigurazioni.

4.3.1.4.3 - Risoluzione delle dipendenze

La risoluzione delle dipendenze ha luogo tramite diversi passi. In primis viene creato e inizializzato con i medatati di configurazione un oggetto di tipo ApplicationContext. La configurazione può essere specificata tramite XML, codice Java, o annotazioni Java. Per ogni bean le dipendenze sono espresse tramite proprietà, argomenti del costruttore, o argomenti del metodo factory. Queste dipendenze sono fornite al bean nel momento in cui il bean è realmente creato. Ogni proprietà o argomento di costruttore corrisponde ad un valore da impostare o a un riferimento ad un altro bean di un container.

Nel caso si tratti di un valore, è convertito dal formato in cui è specificato (es. una stringa se il valore è indicato in un file XML) al formato reale della proprietà che lo rappresenta. Spring può convertire tutti i valori di tipo primitivo come int, long, String, boolean, etc.

Anche se le proprietà sono impostate solo al momento della creazione del bean, all’atto della creazione del contesto il container Spring valida la configurazione di ogni


138

bean, incluso il controllo che le dipendenze tra bean facciano riferimento a bean validi. A tempo di caricamento del container sono quindi rilevati i possibili problemi di configurazione, come le inconsistenze dei riferimenti o le dipendenze circolari. Tuttavia le dipendenze sono realmente risolte solo alla creazione dei bean, ed è quindi possibile che si verifichino problemi anche dopo il caricamento del container, ad esempio se la creazione di un bean genera una eccezione. Per questo motivo Spring cerca di anticipare la creazione di alcuni bean detti singleton (illustrati nella sezione 4.3.1.5.1 -) a tempo di caricamento della configurazione, anche se è possibile modificare questo tipo di comportamento. Nel caso in cui non si verifichino problemi, quando un bean viene iniettato in un altro è stato totalmente configurato in ogni sua dipendenza.

4.3.1.4.4 - Autowiring

Il container Spring può provvedere all’iniezione dei componenti in maniera automatica, deducendo i particolari bean che devono essere iniettati. In questo modo è possibile ridurre l’ammontare di configurazione necessaria e aggiornare automaticamente la configurazione man mano che i componenti evolvono. Fondamentalmente sono possibili tre tipi di autowiring: in base al nome, al tipo o al costruttore.

Nel primo caso il container IoC cerca all’interno della configurazione un bean con lo stesso nome della proprietà che deve essere iniettata. L’autowiring basato sul tipo invece si fonda sull’assunzione che esista esattamente un solo bean dello stesso tipo della proprietà che deve essere iniettata. Il container cerca quindi un bean di questo tipo per iniettare la proprietà. Infine, l’autowiring basato su costruttore si basa sulle stesse considerazioni di quello basato su tipo ma si applica al costruttore.

4.3.1.5 Scope dei bean La configurazione di un bean comporta la definizione di una precisa modalità di

creazione delle istanze del bean stesso. Oltre alle dipendenze, è possibile controllare attraverso la configurazione lo scope delle istanze del bean. Con scope s’intende l’ambito di esistenza del bean, la sua visibilità e il suo tempo di vita in riferimento ad un particolare scenario. Spring supporta cinque tipologie di scope predefinite, tre delle quali sono valide solo all’interno di un ApplicationContext che fa riferimento ad un contesto web. In aggiunta, è possibile creare scope personalizzati. Gli scope predefiniti sono: singleton, prototype, request, session e global session.

È possibile controllare lo scope dei bean tramite l’omonimo attributo scope dell’elemento <bean/>.

4.3.1.5.1 - Singleton Scope

Rappresenta lo scope di default dei bean e prevede che il container crei e gestisca un’unica istanza del bean condivisa. Tutte le richieste per il bean da parte di altri componenti sono soddisfatte dal container Spring con la stessa istanza, come raffigurato in Figura 43.


139

Figura 43 - Schema dello scope singleton.

Precisiamo che Spring contestualizza il concetto di singleton all’interno del container e per il bean particolare. Nel caso in cui sia definito un altro bean per la stessa classe, sarà possibile crearne più istanze. Allo stesso modo se si crea un altro container sarà possibile avere altre istanze del bean. Non si tratta quindi di un singleton a livello di classe e di class loader, come è previsto dalla versione canonica del pattern.

Normalmente le istanze per tali bean sono create a tempo di inizializzazione del container. È tuttavia possibile modificare questo comportamento impostando l’attributo lazy-init dell’elemento <bean/> al valore booleano true. In questo modo la creazione dell’istanza del bean avviene solo al momento della prima richiesta del bean.

4.3.1.5.2 - Prototipe

Lo scope prototype prevede la creazione di una nuova istanza del bean ogni volta che il bean è richiesto al container, sia se il bean è iniettato dal container stesso sia se viene richiesto tramite il metodo getBean(). Di regola, questo scope viene utilizzato per tutti i bean dotati di stato, mentre lo scope singleton è utilizzato per i bean senza stato. La mostra lo schema risultate da un bean configurato con scope prototype, in cui ogni richiesta per lo stesso bean è soddisfatta con una nuova istanza.

Figura 44 - Schema dello scope prototype.

A differenza degli altri scope, Spring non gestisce il ciclo di vita completo di un bean prototype: dopo aver istanziato e configurato l’oggetto il container lo consegna al client senza conservare alcuna traccia dell’istanza. Di conseguenza, se i metodi di callback per l’inizializzazione del bean sono chiamati indipendentemente dallo scope,


140

quelli di distruzione non sono invocati nel caso di scope prototype. Maggiori dettagli sulla gestione del ciclo di vita saranno dati nella sezione 4.3.1.6.1 -.

Nel caso in cui un bean di tipo singleton abbia delle dipendenze verso bean con scope prototype, teniamo a precisare che le dipendenze saranno risolte a tempo di creazione dell’istanza del bean e l’istanza iniettata sarà l’unica mai fornita al bean singleton. Nel caso in cui si voglia permettere al bean singleton di acquisire nuove istanze del bean prototype a tempo di esecuzione, non è possibile utilizzare la DI ma è necessario ricorrere al metodo getBean().

4.3.1.5.3 - Request, session e global session

Gli scope request, session, e global session possono essere usati solo nel caso di una implementazione di ApplicationContext cosidetta web-aware, come ad esempio XmlWebApplicationContext. Si tratta cioè di un container Spring che viene creato all’interno di un web server e tiene conto delle dinamiche di gestione delle richieste di servizio e delle sessioni web. Se ciò non avviene, e cioè se sono usati all’interno di un container IoC che non rispetta questi requisiti è generata una eccezione. Si tratta, infatti, di scope legati ad una singola richiesta di servizio o ad una intera sessione HTTP di interazione con l’utente, entità che hanno senso solo all’interno dello scenario web.

Per supportare queste tipologie di scope è richiesta in alcuni casi una configurazione particolare rispetto agli scope tradizionali per legare il container IoC all’interno del contesto web, in particolare al Servlet container. Tale configurazione non è tuttavia necessaria nel caso si utilizzi Spring MVC. Se non si utilizza Spring MVC è invece necessario configurare un apposito ServletRequestListener, definito da Spring, all’interno del file web.xml, di tipo RequestContextListener.

Nel caso di scope request il container Spring crea una nuova istanza del bean ad ogni richiesta HTTP ricevuta. Nel caso lo stato del bean sia modificato, all’arrivo di una seconda richiesta sarà fornita una nuova istanza in cui non saranno presenti le modifiche. Quando l’elaborazione della richiesta è completato, il bean è rimosso.

Lo scope di tipo session prevede la creazione di un bean per il tempo di vita di una sessione HTTP, individuata da un oggetto di tipo Session all’interno di un Servlet container. Come nel caso precedente le modifiche apportate al bean non saranno visibili ad altre sessioni HTTP che facciano uso del bean. Anche in questo caso il bean è distrutto quando la sessione HTTP viene scartata.

Lo scope global session infine è simile allo scope session appena descritto ma si applica solo al caso delle applicazioni web basate su portlet. La specifica portlet definisce il concetto di global session che è condivisa tra tutte le portlet che formano una stessa applicazione web. I bean con scope global request sono legati al tempo di vita di questo tipo di sessione.

4.3.1.5.4 - Combinazioni di scope

Vi sono alcuni casi in cui una particolare combinazione di scope deve essere opportunamente trattata al fine di dare luogo al comportamento desiderato. In particolare facciamo riferimento al caso in cui si inserisca un bean con scope di vita


141

limitato, come request o session, all’interno di un bean con scope di vita più ampio come singleton.

In questo caso, ci si potrebbe aspettare che il comportamento risultante sia quello di disporre all’interno del bean singleton dell’istanza corrente del bean, legato ad esempio alla sessione HTTP in corso. Tuttavia, dato che DI agisce solo all’atto della creazione dei bean, e il bean con scope singleton è costruito un’unica volta, l’istanza iniettata al suo interno rimane sempre la stessa. Si tratta quindi di un comportamento molto differente da quello che ci aspetteremmo.

Per porre rimedio a questo inconveniente Spring ricorre alla tecnica dell’AOP, che sarà descritta con più dettaglio nella sezione 4.3.2. In particolare, all’atto della creazione del bean singleton, piuttosto che il bean vero e prorio viene iniettato un proxy, in modo assolutamente trasparente dato che espone la stessa interfaccia. Tale proxy rimane fisso per tutto il tempo di vita del bean singleton. Tuttavia, quando viene invocato un metodo del proxy, che corrisponde ad un analogo metodo del bean che rappresenta, il proxy si occupa di recuperare l’istanza specifica del bean legata alla richiesta o alla sessione HTTP in corso. Si tenga presente, inoltre, che dato che in un server web vi è un thread per ogni richiesta, tale oggetto è unico per il thread che sta eseguendo il bean singleton, e non vi sono quindi problemi di corse critiche legate alla condivisione di più bean tra lo stesso thread.

Il comportamento descritto può essere ottenuto specificando l’elemento <aop:scoped-proxy/> all’interno della definizione del bean con scope request o session.

4.3.1.5.5 - Scope personalizzati

A partire da Spring 2.0, il meccanismo degli scope è estensibile. È possibile definire scope personalizzati o ridefinire gli scope esistenti, sebbene il secondo caso sia altamente sconsigliato e non sia possibile ridefinire gli scope singleton e prototype.

Per creare uno scope è necessario implemetare l’interfaccia Scope fornira dal framework. Questa interfaccia presenta quattro metodi per recuperare, rimuovere e distruggere oggetti dallo scope. Il metodo get() permette di recuperare un oggetto dallo scope, specificando il nome ed eventualmente una factory per il bean. Il metodo remove() è utilizzato per rimuovere il bean di nome specificato. Il metodo registerDestructionCallback() permette invece di registrare un oggetto Runnable che contiene il codice di callback da eseguire al momento della distruzione del bean di nome specificato. Infine il metodo getConversationId() permette di recuperare una stringa che identifica univocamente il bean all’interno dello scope.

Il metodo fondamentale che permette di registrare uno scope all’interno del container Spring è il metodo registerScope() dell’interfaccia ConfigurableBeanFactory, implementata dalla maggior parte degli ApplicationContext. Ad esempio il framework Spring fornisce lo scope SimpleThreadScope che normalmente non è registrato e deve quindi essere creato esplicitamente e registrato tramite il metodo registerScope() prima di poter essere usato.


142

La configurazione degli scope può essere realizzata anche configurando per via dichiarativa, all’interno di del file XML di configurazione, un bean predefinito di tipo CustomScopeConfigurer. Nella configurazione del bean è necessario inserire tra le dipendenze il bean che rappresenta lo scope desiderato.

4.3.1.6 Funzionalità avanzate Di seguito saranno descritte alcune funzionalità avanzate offerte dal container

IoC: la gestione del ciclo di vita dei bean, la possibilità di iniettare componenti di sistema nei bean, e la possibilità di estendere il container stesso con funzionalità personalizzate.

4.3.1.6.1 - Gestione del ciclo di vita

Spring permette di gestire con opportuni metodi di callback il ciclo di vita dei bean. In particolare offre diversi modi per intercettare l’inizializzazione e la distruzione dei bean. Il metodo di inizializzazione è invocato appena dopo aver iniettato tutte le dipendenze del bean, mentre la distruzione appena prima della sua distruzione.

Per realizzare questi metodi è possibile seguire tre alternative. Il primo è quello di implementare le interfacce InitializingBean e DisposableBean, rispettivamente per la creazione e distruzione, ognuna delle quali definisce un metodo che verrà invocato dal container al momento opportuno. In questo modo però i bean sono legati alle API Spring. In alternativa è possibile, tramite gli attributi init-method e destroy-method dell’elemento <bean/>, indicare un metodo qualsiasi del bean stesso da utilizzare come callback. Terza opzione è possibile istruire il container, impostando gli attributi default-init-method e default-destroy-method nell’elemento radice <beans/>, a ricercare i metodi di default init() e destroy() in tutti i bean dell’applicazione. Infine è possibile annotare i metodi del bean che si vuole utilizzare come callback con le annotazioni @PostConstruct e @PreDestroy.

4.3.1.6.2 - Injection dei componenti di sistema

Spring definisce un meccanismo che permette l’injection nei bean dei componenti di sistema Spring. Questo è possibile tramite opportune interfacce che sono legate ad un particolare oggetto di sistema. Estendendo una di queste interfacce e il metodo setter che dichiarano, all’interno del bean sarà automaticamente iniettato l’oggetto corrispondente. Ad esempio, l’interfaccia ApplicationContextAware definisce un metodo per iniettare il componente ApplicationContext nei bean che implementano l’interfaccia stessa.

4.3.1.6.3 - Estensioni al container

Il container IoC può essere esteso con nuove funzionalità tramite l’implementazione di speciali interfacce di integrazione.

L’interfaccia BeanPostProcessor definisce dei metodi di callback che possono essere implementati per fornire la propria logica di creazione delle istanze dei bean, di risoluzione delle dipendenze, e così via. In particolare l’interfaccia definisce due metodi di callback che permettono di intervenire dopo la creazione del bean


143

rispettivamente appena prima e appena dopo la configurazione e l’inizializzazione del bean. I componenti che implementano queste funzionalità sono trattate differentemente dal container e creati all’inizializzazione del container. È possibile inoltre controllare l’ordinamento con cui le funzionalità dei componenti saranno applicate.

Alcune funzionalità del container stesso, come ad esempio l’infrastruttura Spring AOP, sono realizzate proprio attraverso questa tecnica. Di conseguenza, componenti di tipo BeanPostProcessor non possono essere oggetto dei meccanismi AOP. Altra funzionalità implementata con questa tecnica è il PropertyPlaceholderConfigurer, che permette di spostare i valori di configurazione di un file XML di configurazione dei bean all’interno di un file separato in cui le proprietà sono definite secondo il formato Java Properties. Infine, funzionalità fondamentale fornita attraverso i BeanPostProcessor è quella che permette la configurazione del container IoC tramite l’uso di annotazioni.

4.3.1.7 Configurazione tramite annotazioni Spring permette di configurare la struttura dei bean e il comportamento del

container IoC anche tramite annotazioni Java piuttosto che tramite file XML.

L’introduzione di questa funzionalità è stato oggetto di un dibattito su quale fosse il modo migliore di definire la configurazione. Ogni approccio ha tuttavia vantaggi e svantaggi. Le annotazioni permettono di esprimere in modo breve e conciso la configurazione mantenendola inoltre agganciata al contesto a cui fa riferimento. Tuttavia l’XML permette di cambiare la configurazione dei componenti senza modificare il codice e quindi compilare nuovamente le classi. Inoltre Spring permette di combinare i due meccanismi. È importante tenere presente che la DI basata su annotazioni viene effettuata prima dell’injection tramite XML, e quindi la configurazione espressa tramite XML andrà a sovrascrivere le proprietà che sono specificate secondo entrambi i meccanismi.

Tutte le annotazioni che permettono di controllare la configurazione del container sono supportate da opportuni BeanPostProcessor che si occupano di implementare le funzionalità correlate. Piuttosto che configurare individualmente tutti i BeanPostProcessor necessari, è possibile registrare un insieme di default di bean relativi alle annotazioni includendo l’elemento <context:annotation-config/> all’interno del file di configurazione. In questo modo si abilitano un insieme prestabilito di annotazioni sufficiente per la maggior parte delle funzionalità comunemente utilizzate. Sono previste anche annotazioni appartenenti alla specifica Java EE e JPA. Tramite questa configurazione inoltre le annotazioni sono cercate solo all’interno dello stesso contesto in cui è definita. Questo aspetto è particolarmente importante nel caso delle applicazioni web, in cui il WebApplicationContext è limitato alla singola servlet che gestisce le richieste di servizio. Per maggiori dettagli si faccia riferimento alla sezione 4.3.4.2.


144

4.3.1.7.1 - @Autowired e @Required

Due annotazioni molto comuni sono @Autowired e @Required. La prima permette di abilitare le funzionalità di autowiring descritte in 4.3.1.4.4 - relativamente ai campi a cui è applicata. L’annotazione @Required permette di indicare quelle proprietà che devono essere necessariamente iniettate a tempo di configurazione. Nel caso in cui ciò non avvenisse, il container genera un’eccezione e la configurazione del sistema fallisce. Anche l’annotazione @Autowired supporta l’attributo booleano required.

L’annotazione @Autowired può essere utilizzata a livello di classe, per fare in modo che tutti i campi al suo interno siano iniettati, oppure a livello di singolo campo o di singolo metodo per specificare singolarmente i campi da iniettare. Infine, nel caso si voglia utilizzare la DI basata su costruttore è possibile applicare l’annotazione al costruttore stesso.

4.3.1.7.2 - @Qualifier

Dato che l’autowiring basato su tipo potrebbe dare luogo a molteplici candidati, è spesso necessario avere maggiore controllo sul processo di selezione dei componenti. Per questo è possibile utilizzare l’annotazione @Qualifier che, combinata con @Autowire, permette di restringere l’insieme di tipi che combacia con la definizione in modo che un bean specifico sia selezionato.

L’annotazione permette di specificare come valore una stringa arbitraria. All’interno del file di configurazione XML, ogni definizione di bean può utilizzare al suo interno l’elemento <qualifier/> specificando nell’attributo value una stringa. In questo modo i candidati per l’autowiring di un certo campo si restringono ai soli bean che presentano, nella loro definizione, quello stesso qualificatore.

Inoltre il qualificatore di default di ogni bean è rappresentato dal suo stesso nome identificativo, ed è quindi possibile specificare tale valore all’interno dell’annotazione per riferire un bean specifico. Tuttavia per questo tipo di utilizzo, cioè l’autowiring basato su nome, è raccomandato l’utilizzo dell’annotazione @Resource.

4.3.1.7.3 - @Resource

Spring supporta l’injection usando l’annotazione JSR-250 @Resource, che può essere applicata a campi, proprietà o metodi setter. Quest’annotazione fa parte della specifica Java EE 5 e Java EE 6.

È utilizzata per indicare al container che il campo etichettato deve essere oggetto di DI, e segue una semantica per nome. Può essere specificato un nome come attributo, o se non è specificato è usato il nome del campo stesso. Questa annotazione supporta inoltre l’injection di un qualsiasi tipo di risorsa.

4.3.1.7.4 - @PostConstruct e @PreDestroy

Altre annotazioni facenti parte della specifica Java EE 5, ed in particolare della specifica JSR 250 sono @PostConstruct e @PreDestroy.


145

Queste annotazioni permettono di utilizzare i metodi annotati come metodi di callback rispettivamente per gli eventi di inizializzazione e distruzione del bean, secondo quanto descritto in 4.3.1.6.1 -.

4.3.1.7.5 - Scansione del Classpath

Le annotazioni descritte precedentemente erano utilizzate per specificare metadati di configurazione della singola configurazione di un bean. Tuttavia in tutti i casi precedenti la definizione del bean avveniva comunque in modo esplicito all’interno del file XML, tramite l’elemento <bean/>. Le annotazioni erano utilizzate esclusivamente per guidare la DI.

È possibile utilizzare le annotazioni anche per definire quali componenti costituiscono dei bean all’interno dell’applicazione. Per fare ciò il container IoC scansiona il class path andando alla ricerca di componenti etichettati con specifiche annotazioni.

Spring prevede diverse annotazioni da applicare ai componenti che soddisfano uno stereotipo, cioè un particolare ruolo all’interno dell’applicazione. In particolare può essere utilizzata sia l’annotazione generica @Component, per indicare che la classe etichettata rappresenta un bean Spring, oppure è possibile utilizzare stereotipi specifici per i diversi livelli applicativi: @Repository, @Service, @Controller. Il primo è utilizzato a livello dei dati per indicare i componenti che svolgono il ruolo di Data Access Object (DAO) per una sorgente dati. L’utilizzo di questa annotazione abilita automaticamente i meccanismi di traduzione delle eccezioni vendor-specific in annotazioni di carattere generale, come descritto nella sezione 4.3.3.2. Le annotazioni @Service ed @Controller sono utilizzate rispettivamente nei livelli di business e di presentazione. L’annotazione @Controller è utilizzata all’interno del framework Spring MVC come descritto nella sezione 4.3.4.3, mentre l’annotazione @Service non ha al momento una semantica specifica ma non se ne esclude una particolare caratterizzazione in futuro. In ogni caso possono essere utilizzate per rendere i componenti idonei ad essere processati da strumenti specifici o associarli a particolari aspetti. Le annotazioni per gli stereotipi son dotate di un campo name che permette di specificare il nome univoco del bean. Nel caso in cui non sia specificato viene utilizzato il nome non qualificato della classe stessa.

Per abilitare la scansione del class path da parte del container è necessario specificare all’interno della configurazione XML l’elemento <context:component-scan/> in cui l’attributo base-package indica il package che deve essere usato come base di partenza della ricerca dei componenti. Inoltre l’utilizzo di questa configurazione abilita esplicitamente le funzionalità di <context:annotation-config> descritte nella sezione precedente, e include quindi anche alcuni BeanPostProcessor per le annotazioni. Inoltre i sotto-elementi include-filter o exclude-filter permettono di indicare, tramite espressioni regolari, percorsi o classi del classpath che devono essere rispettivamente inclusi o esclusi dalla ricerca.

I componenti Spring possono anche contribuire alla definizione dei metadati del container. Applicando l’annotazione @Bean ad un metodo all’interno di una classe annotata con @Component, è possibile utilizzare metodo stesso come sostituto della


146

definizione del bean. La classe del bean è rappresentato dal tipo di ritorno e il nome del metodo rappresenta, a default, l’identificativo del bean. Il metodo deve occuparsi di creare e restituire al chiamante un’istanza del bean. Vedremo che un utilizzo analogo è possibile in combinazione con l’annotazione @Configuration, che ha in questo caso però una sostanziale differenza nel modo in cui i bean sono processati.

Il framework fornisce alcune annotazioni che permettono di configurare le proprietà del componente stesso. L’annotazione @Scope permette di specificare, tramite il suo valore, lo scope del componente, tra quelli indicati nella sezione 4.3.1.5. Nel caso in cui sia necessario, come descritto nella sezione 4.3.1.5.4 -, ricorrere all’utilizzo dei proxy per la gestione degli scope, è necessario utilizzare l’attributo scoped-proxy dell’elemento <context:component-scan/> per abilitare questa funzionalità. Sono possibili tre diversi valori: no, che disabilita l’utilizzo dei proxy, interface, che utilizza i proxy standard JDK, e targetClass che fa ricorso ai proxy di tipo CGLIB (maggiori dettagli sui proxy JDK e CGLIB nella sezione 4.3.2.3).

4.3.1.7.6 - Qualifier tramite annotazioni

Nella sezione abbiamo discusso di come sia possibile guidare il processo di autowiring tramite l’annotazione @Qualifier apposta ai campi oggetto dell’autowiring. Tuttavia per applicare questa tecnica era necessario specificare, all’interno della definizione del bean nel file XML, un qualificatore per il bean stesso tramite l’elemento <qualifier/>.

Dato che è possibile definire i bean direttamente tramite annotazioni piuttosto che con XML, è anche possibile fornire loro un qualificatore tramite cui possa essere guidato il processo di autowiring. Ciò è possibile apponendo l’annotazione @Qualifier direttamente al componente a cui è applicato anche lo stereotipo. Il valore del qualificatore va indicato all’interno dell’annotazione.

4.3.1.7.7 - Uso delle annotazioni JSR 330

In alternativa alle annotazioni @Autowired e @Component Spring supporta anche le annotazioni dello standard JSR 330, le annotazioni @Inject e @Named.

@Inject ha la stessa funzione di @Autowired e come questa può essere utilizzata a livello di classe, di campo, di metodo o di costruttore, con semantica equivalente. Tuttavia non supporta, a differenza di @Autowired, l’attributo required.

L’annotazione @Named invece è analoga a @Component e può essere usata nello stesso modo.

4.3.1.8 Configurazione tramite codice Abbiamo visto come sia possibile configurare il container IoC tramite l’uso di

file XML o tramite le annotazioni. Un terzo modo di configurare il container è rappresentato dal codice stesso.

Alla base di questo meccanismo troviamo l’annotazione @Configuration. Tale annotazione si applica a classi che forniscono la configurazione e che consistono principalmente di metodi etichettati con l’annotazione @Bean. L’annotazione @Bean ha


147

lo stesso ruolo dell’elemento XML <bean/> e individua nel tipo di ritorno del metodo la classe del bean e nel nome del metodo il nome del bean. Permette inoltre di specificare i metodi di gestione del ciclo di vita del bean, e può essere combinata con le annotazioni @Scope per definire lo scope del bean. Quest’ultima permette in questo caso di specificare anche la tipologia di proxy (no, interface o targetClass).

Rispetto all’uso dell’annotazione @Bean all’interno di componenti etichettati con @Component, descritto nella sezione 4.3.1.7.5 -, in questo caso si ha un comportamento differente. Infatti nel caso di @Configuration sulle classi è utilizzato il meccanismo di proxing (descritto nella sezione 4.3.2.3.3 -) per intercettare l’invocazione di metodi e campi e creare quindi i metadati di configurazione. Di conseguenza i metodi non sono invocati con la normale semantica Java, che è invece quella utilizzata nel caso di annotazione @Component.

La costruzione di un contesto configurato tramite codice si basa sull’utilizzo dell’ApplicationContext di tipo AnnotationConfigApplicationContext. All’atto della creazione del contesto, si specificano una o più classi annotate con @Configuration che specificano la configurazione del container. In alternativa è possibile utilizzare anche classi annotate con @Component.

L’annotazione @Import, analogamente all’elemento XML <import/>, permette invece di rendere modulari le configurazioni importando le definizioni dei bean da una classe di configurazione all’altra.

È possibile inoltre abilitare lo scansionamento automatico del class path per cercare le classi di configurazione tramite l’elemento <context:annotation-config/>. Tale elemento è inoltre implicito nel caso si faccia uso di <context:component-scan/>.

Per combinare configurazione tramite XML e basata su classi è possibile utilizzare l’annotazione @ImportResource che permette di fare riferimento, all’interno di una classe di configurazione, alle entità definite all’interno di un file di configurazione specificato nell’annotazione.

Altre funzionalità più avanzate del container, che non sono oggetto di questa trattazione, permettono di realizzare funzionalità avanzate quali l’internazionalizzazione, l’accesso a risorse quali URL e file, la pubblicazione di eventi ai bean che implementano l’interfaccia ApplicationListener, o il caricamento di molteplici contesti secondo un’organizzazione gerarchica.

4.3.2 AOP in Spring L’Aspect Oriented Programming (AOP) rappresenta un modello

complementare all’Object-Oriented Programming (OOP). Se l’unità fondamentale di modularità nell’OOP è la classe, nell’AOP è l’aspetto. Gli aspetti permettono la modularizzazione di funzionalità trasversali quali gestione delle transazioni, sicurezza, che interessano una molteplicità di componenti e oggetti.

Uno degli elementi fondamentali di Spring è il suo framework AOP, che unitamente alle funzionalità di IoC fornisce una soluzione completa e funzionale.


148

Inoltre da Spring 2.0 è stato introdotto il supporto agli aspetti basato, oltre che su XML, su annotazioni. Inoltre entrambe le modalità permettono l’utilizzo del linguaggio AspectJ, mentre utilizzano Spring AOP per l’inserimento degli aspetti.

All’interno del framework Spring l’AOP è sia utilizzata per fornire servizi in stile dichiarativo a livello enterprise, specialmente in sostituzione di quelli di tipo EJB, come ad esempio la gestione dichiarativa delle transazioni, ma anche per permettere all’utente di definire aspetti personalizzati e integrare l’uso dell’AOP all’OOP.

4.3.2.1 Concetti di AOP Prima di scendere nei dettagli dell’implementazione Spring AOP è necessario

definire alcuni concetti fondamentali nell’ambito dell’AOP.

Innanzitutto definiamo un aspetto come una modularizzazione di una funzionalità che interessa in modo trasversale diverse classi. La gestione delle transazioni è un buon esempio di questo tipo di funzionalità nell’ambito enterprise. In Spring AOP gli aspetti sono implementati utilizzando semplici classi o classi annotate con l’annotazione @Aspect secondo lo stile @AspectJ.

In secondo luogo, un join point rappresenta un punto durante l’esecuzione di un programma, come l’esecuzione di un metodo o la gestione di una eccezione. In Spring AOP un join point è sempre rappresentato dall’esecuzione di un metodo.

Un advice costituisce l’azione eseguita da un aspetto in corrispondenza di un particolare join point. Esistono differenti tipologie di advice, tra cui l’“around” advice, il “before” advice e l’“after” advice (saranno discussi in seguito). Molti framework AOP, incluso Spring, modellano gli advice come interceptor, mantenendo una catena di interceptor attorno al join point. Gli oggetti cui sono applicati gli advice sono detti adviced o anche oggetti target.

I join point sono individuati da predicati detti pointcut. Un advice è associato con una espressione di pointcut e viene eseguito ad ogni join point individuato dal pointcut (ad esempio, l’esecuzione di un metodo con un certo nome). Il concetto di join point individuato dall’espressione di un pointcut è centrale nell’AOP e Spring fa uso delle espressioni del linguaggio AspectJ per eseprimerli.

Inoltre è possibile introdurre metodi e campi addizionali ad un tipo già definito, attraverso le cosidette introduction. Spring AOP permette di introdurre nuove interfacce e la corrispondente implementazione a ogni oggetto adviced. Ad esempio, se si realizza una funzionalità di caching, è possibile utilizzare una introduction per fare in modo che un bean implementi un’interfaccia IsModified. Il concetto di introduction è noto nella comunità AspectJ anche con il nome di dichiarazione inter-tipo.

Dato che in Spring l’AOP è realizzata tramite l’utilizzo di oggetti proxy, tutti gli oggetti target sono incapsulati all’interno di proxy e sono per questo chiamati oggetti proxied. Un AOP proxy è un oggetto creato dal framework AOP al fine di implementare il meccanismo deli aspetti. In Spring AOP, un proxy AOP può essere


149

realizzato come un proxy dinamico JDK o come proxy CGLIB (maggiori dettagli in 4.3.2.3).

Infine, con il termine weaving si fa riferimento all’operazione che lega gli aspetti ai componenti applicativi al fine di creare oggetti adviced. Ciò può essere fatto a tempo di compilazione (usando il compilatore AspectJ ad esempio), a tempo di caricamento, o a tempo di esecuzione. Spring, come altri framework AOP, esegue l’operazione di weaving a tempo di esecuzione.

Esistono diverse tipologie di advice. Il before advice esegue prima di un join point e non ha, a differenza di altri advice, la capacità di impedire il procedere del normale flusso di esecuzione. L’after returning advice viene eseguito dopo che un join point è normalmente completato, ad esempio se un metodo ritorna senza generare una eccezione. L’after throwing advice è invece eseguito quando un metodo termina lanciando un’eccezione. L’after finally advice, detto comunemente after advice, prevede invece l’esecuzione dell’advice indipendentemente dal modo in cui un join point viene completato (normalmente o tramite eccezione). Infine, l’around advice è il tipo di advice più potente in quanto circonda l’esecuzione di un metodo. Può quindi attuare le sue logiche sia prima che dopo l’esecuzione del metodo. È inoltre responsabile di scegliere se procedere con il join point o di evitare l’esecuzione del metodo intercettato, restituendo un proprio valore di ritorno o generando un’eccezione.

L’around advice è il tipo più generico di advice. Dato che Spring AOP fornisce una vasta schiera di advice, è in genere raccomandabile l’uso dell’advice più specifico che riesce ad implementare il comportamento richiesto. In questo modo si semplifica il modello di programmazione e si riducono le possibilità di errore.

In Spring 2.0 inoltre tutti i parametri di un advice e i tipi di ritorno sono staticamente tipati, così che sia possibile lavorare direttamente con i tipi appropriati piuttosto che con array di oggetti di tipo Object su cui è necessario effettuare cast espliciti.

4.3.2.2 Capacità e obiettivi di Spring AOP Spring AOP è implementato interamente in Java. Non vi è necessità di

compilatori speciali e non ha bisogno di controllare la gerarchia di class loader. Per questi motivi è molto adatto ad esempio ad un Servlet container o un application server.

Spring AOP supporta come join point solo l’esecuzione dei metodi dei bean Spring. Non è al momento possibile intercettare l’assegnamento dei campi, anche se non si esclude sarà possibile in future implementazioni. L’approccio all’AOP di Spring è differente da quello di molti altri framework. Nonostante sia molto completo, il suo obiettivo non è fornire l’implementazione più estensiva delle funzionalità in ambito AOP, ma piuttosto di fornire un elevato livello di integrazione tra l’infrastruttura AOP e il container Spring IoC per risolvere i problemi più comuni nell’ambito delle applicazioni enterprise.

Quindi, ad esempio, Spring AOP è utilizzato configurando gli aspetti di tramite la normale sintassi di definizione dei bean (anche se è possibile utilizzare le


150

funzionalità di autoconfigurazione). Non è concepito invece per utilizzare gli advice su oggetti con livello di granularità molto fine come gli oggetti del dominio. Per questo tipo di applicazioni sono più adatti framework come AspectJ. In ogni caso Spring AOP fornisce un’ottima soluzione alla maggior parte dei problemi più comuni che si presentano in ambito enterprise e sono riconducibili allo scenario AOP.

Spring AOP non si pone l’obiettivo di competere con framework come AspectJ per fornire una soluzione AOP omnicomprensiva ed esauriente. L’approccio basato su proxy come quello di Spring AOP e quello completo proprio di AspectJ sono piuttosto complementari.

4.3.2.3 Proxy e AOP Spring AOP implementa il meccanismo AOP tramite l’utilizzo di proxy. Si

avvale in particolare di due tipologie di proxy: i Dynamic Proxy, utilizzati per default, o i CGLIB proxy. Procediamo innanzitutto a presentare il concetto di proxy e i due meccanismi di base.

4.3.2.3.1 - Pattern proxy

Il pattern proxy prevede la creazione di un oggetto fittizio il cui scopo è di accettare le richieste provenienti dal client per inviarle all’oggetto reale che serve la richiesta. L’oggetto proxy espone la stessa interfaccia dell’oggetto reale. Ciò permette di fornire al client un riferimento all’oggetto proxy, piuttosto che all’oggetto reale, in modo assolutamente trasparente. Le richieste provenienti dal client sono quindi intercettate dall’oggetto proxy che provvede poi a inoltrarle al client. In questo modo il proxy può essere utilizzato per implementare funzionalità aggiuntive rispetto a quelle previste dall’oggetto reale. In Figura 45 è rappresentato il diagramma UML del pattern.

Figura 45 - Il pattern proxy.

Uno degli ambiti di utilizzo più comuni del pattern proxy è quello dell’invocazione remota di metodi, o Remote Method Invocation (RMI), in cui il proxy, detto stub, si occupa di nascondere la natura remota dell’oggetto e realizzare le funzionalità di marshalling e unmarshalling dei dati. Nelle versioni tradizionali della piattaforma Java precedenti alla 1.3 l’implementazione del meccanismo RMI prevedeva la generazione degli stub a tempo di compilazione, sulla base dell’interfaccia dell’oggetto remoto. A partire dalla versione 1.3 della piattaforma Java


151

Standard Edition è stato invece introdotto il meccanismo molto potente dei dynamic proxy, o proxy dinamici, un’implementazione del pattern proxy che permette la generazione dei proxy dinamicamente, cioè a tempo di esecuzione.

4.3.2.3.2 - Dynamic Proxy

I Dynamic Proxy permettono la generazione di proxy per gli oggetti a tempo di esecuzione. Alla base del meccanismo dei dynamic proxy troviamo l’interfaccia InvocationHandler. Questa interfaccia si occupa di effettuare la reale invocazione di metodo per conto di un dynamic proxy.

L’interfaccia espone un unico metodo invoke() a cui sono passati un oggetto di tipo Method, che rappresenta il metodo che deve essere invocato, e la lista di argomenti che devono essere consegnati al metodo. Per realizzare il meccanismo è necessario implementare questa interfaccia inserendo la logica di gestione delle invocazioni prevista dal proxy. L’implementazione più semplice che si può pensare si occupa solamente di invocare il metodo passando gli argomenti e di restituire il risultato. Ogni proxy ha associato un invocation handler che è chiamato quando un metodo del proxy è invocato.

L’oggetto proxy può essere creato tramite il metodo statico Proxy.newProxyInstance(), a cui sono passati il classloader corrente, l’insieme di interfacce implementate dal proxy, e l’istanza dell’oggetto reale che deve essere incapsulata all’interno del proxy.

Requisito fondamentale per la realizzazione di questo meccanismo è che siano definite una o più interfacce che costituiscano la specifica comune del proxy e dell’oggetto target. Non è possibile utilizzare questo meccanismo senza la definizione di tali interfacce.

In Spring è possibile utilizzare anche un altro meccanismo di proxing che presenta un comportamento differente rispetto a quello dei dynamic proxy.

4.3.2.3.3 - CGLIB Proxy

Code Generation Library rappresenta una libreria per la generazione di codice molto usata in scenari come quello dell’AOP. La principale differenza rispetto al caso precedente dei dynamic proxy Java SE consiste nel fatto che consente di creare proxy per classi che non implementano alcuna interfaccia. Essenzialmente, genera dinamicamente una classe derivata che ridefinisce tutti i metodi non final della classe target e vi inserisce dei metodi di callback che richiamano gli intercettori definiti dall’utente. Non facendo uso in alcun modo di meccanismi riflessivi, rappresenta un approccio generalmente più performante del meccanismo Java Standard.

Il meccanismo utilizzato nelle implementazioni AOP utilizza generalmente l’interfaccia di callback MethodInterceptor che definisce il metodo intercept(). Le invocazioni effettuate sul proxy sono consegnate a questa interfaccia prima di invocare i metodi dell’oggetto originale. Il primo argomento del metodo intercept() è rappresentato dall’oggetto proxy. Il secondo e il terzo argomento rappresentano rispettivamente il metodo e gli argomenti del metodo intercettato. Nel metodo


152

intercept() l’utente può quindi inserire il codice da eseguire prima o dopo l’invocazione del metodo originale.

La creazione di un proxy avviene attraverso l’oggetto Enhancer. Dopo aver creato un oggetto di questo tipo e impostato la classe target, che non deve essere necessariamente un’interfaccia, e il callback, è possibile ottenere un’istanza del proxy semplicemente invocando il metodo create().

4.3.2.3.4 - AOP Proxies

Spring AOP utilizza come comportamento di default i dynamic proxies forniti dalla J2SE. Questo permette di realizzare proxy per una qualsiasi interfaccia, o per un qualsiasi insieme d’interfacce, ma non per una classe. Di conseguenza, con questo approccio sarà possibile utilizzare il meccanismo AOP solo su bean che implementano un’interfaccia.

Spring supporta anche l’uso dei proxy CGLIB. Oltre ad essere più performante in quanto non fa uso di meccanismi riflessivi, CGLIB permette di realizzare proxy sulle classi piuttosto che sulle interfacce. In questo modo è possibile utilizzare il meccanismo AOP anche su bean che non implementano alcuna interfaccia. Sebbene sia una buona pratica quella utilizzare una o più interfacce per ogni oggetto di business, nel caso in cui l’oggetto target non implementa alcuna interfaccia Spring utilizza automaticamente i proxy CGLIB.

Tuttavia è bene tenere a mente alcune considerazioni nel caso si utilizzi questa seconda opzione. In primo luogo, dato che CGLIB basa il suo funzionamento sulle classi derivate, non possono essere intercettati i metodi dichiarati final. In secondo luogo per ogni istanza dell’oggetto target, il costruttore dell’oggetto sarà invocato due volte, in quanto sia il proxy e sia l’oggetto stesso fanno riferimento alla stessa classe.

È possibile forzare l’uso dei proxy CGLIB all’interno del file di configurazione XML. Nella sezione <aop:config/> relativa alla configurazione del meccanismo AOP è necessario impostare al valore true l’attributo proxy-target-class. Nel caso invece si utilizzi il supporto @AspectJ autoproxy, è necessario impostare l’attributo proxy-targetclass dell’elemento <aop:aspectj-autoproxy>.

In entrambi i casi, sia dei proxy Java SE e sia di CGLIB, il meccanismo risultante è quello di un’interazione mediata tra il chiamate e l’oggetto target, come riassunto in Figura 46. Il chiamante non mantiene un riferimento diretto all’oggetto target ma piuttosto verso il proxy. Quando effettua l’inovocazione, il proxy è in grado di attivare tutti gli advice che sono pertinenti a quel particolare metodo, per poi inoltrare l’invocazione all’oggetto target. Ciò vuol dire che, una volta raggiunto l’oggetto target, ogni invocazione effettuata dall’oggetto facendo riferimento alla sua stessa istanza, tramite la parola chiave this, non è in alcun modo oggetto di advicing in quanto non fa riferimento all’oggetto proxy ma bensì all’oggetto target.


153

Figura 46 - Meccanismo di proxy AOP in Spring.

4.3.2.4 Il supporto @AspectJ @AspectJ fa riferimento ad uno stile di dichiarazione degli aspetti come

normali classi Java etichettate con annotazioni Java 5. Lo stile @AspectJ è stato introdotto all’interno del progetto AspectJ, famoso framework AOP in ambito Java, come parte della versione 5. Spring supporta le stesse annotazioni di AspectJ 5, usando una libreria fornita da AspectJ stesso, per l’interpretazione dei pointcut e l’individuazione dei join point. Tuttavia l’ambiente di esecuzione è costituito esclusivamente dall’ambiente Spring AOP, e non c’è alcuna dipendenza dal compilatore e dal weaver AspectJ.

4.3.2.4.1 - Abilitare il supporto @AspectJ

Per poter utilizzare @AspectJ all’interno di una applicazione Spring è necessario abilitare il supporto Spring per la configurazione di Spring AOP basato sugli aspetti @AspectJ e l’autoproxing dei bean. Con il termine autoproxing si fa riferimento alla capacità di Spring di generare automaticamente il proxy per un bean che deve essere oggetto di advising.

Il supporto @AspectJ può essere abilitato sia attraverso la configurazione XML sia tramite codice. In entrambi i casi è necessario assicurarsi anche che la libreria aspectjweaver.jar di AspectJ sia presente nel classpath dell’applicazione.

L’abilitazione tramite codice è eseguita aggiungendo ad una classe di configurazione (cioè che è etichettata con @Configuration) l’annotazione @EnableAspectJAutoProxy. Nel caso di configurazione via XML si aggiunge l’elemento <aop:aspectj-autoproxy>.

4.3.2.4.2 - Creare un aspetto

Una volta abilitato il supporto, è possibile creare un aspetto @AspectJ etichettando la classe di un qualsiasi bean con l’annotazione @Aspect. Precisiamo che se il bean non è definito tramite XML e si utilizza la scansione del classpath è comunque necessario utilizzare l’annotazione @Component o una delle sue specializzazioni.

Inoltre, in Spring AOP non è possibile che un aspetto sia al tempo stesso oggetto target del meccanismo di AOP. L’utilizzo dell’annotazione @Aspect esclude automaticamente il bean da essere oggetto del meccanismo di autoproxing.


154

4.3.2.4.3 - Dichiarazione di pointcut

Ricordiamo che i pointcut sono espressioni che permettono di individuare i join point di interesse e controllare il momento in cui gil advice sono eseguiti. Spring AOP inoltre supporta l’esecuzione dei metodi quali join point. Di conseguenza è possibile pensare ai pointcut come un’espressione che individua l’esecuzione di determinati metodi da parte dei bean Spring.

La dichiarazione di un pointcut è costituita da due elementi: una signature costituita da un nome e da diversi parametri, e un’espressione che determina esattamente quali esecuzioni di metodo sono coinvolte. Nello stile di definizione @AspectJ, la signature di un pointcut è rappresentata da una regolare definizione di metodo, il cui tipo di ritorno è void, e l’espressione del pointcut è indicata attraverso l’annotazione @Pointcut apposta al metodo stesso.

Ad esempio, la seguente definizione del pointcut anyOldTransfer identifica l’esecuzione di un qualsiasi metodo di nome transfer: @Pointcut("execution(* transfer(..))")//expression

private void anyOldTransfer() {} //signature

L’espressione del pointcut che forma il valore dell’annotazione @Pointcut è una espressione regolare AspectJ 5 e saranno discusse nelle sezioni successive.

4.3.2.4.4 - Pointcut Designator

Nel gergo AspectJ, i Pointcut Designator (PCD) rappresentano parole chiavi utilizzate all’interno delle espressioni regolari AspectJ per individuare specifiche entità. Rappresentano uno strumento molto potente in quanto permettono di individuare diversi eventi quali l’invocazione di un metodo o di un costruttore, fare riferimento a particolari oggetti come l’oggetto target e altro ancora. Rispetto ad AspectJ, Spring supporta un insieme ridotto dei Pointcut Designator, che andremo di seguito a esplorare.

Uno dei PCD più utilizzati, soprattutto all’interno di Spring AOP, è execution, che permette di individuare i join point che fanno riferimento all’esecuzione di un particolare metodo, come ad esempio execution(void Point.setX(int)) che permette di inividuare le invocazioni del metodo setX() della classe Point con argomento intero e senza alcun tipo di ritorno. Il PCD within permette di limitare l’insieme di join point ai metodi dichiarati all’interno della classe indicata. Ad esempio, con l’espressione within(MyClass) si individuano tutti i metodi dichiarati all’interno della classe MyClass.

I PCD finora citati fanno riferimento ad una classe o ad un metodo, cioè a entità statiche note a tempo di compilazione. Esistono poi PCD che fanno riferimento ai tipi attuali utilizzati a tempo di esecuzione, e sono this, target e args. La parola chiave this limita i join point alle esecuzioni di metodi in cui il riferimento al bean (cioè il proxy AOP) è istanza di un certo tipo. L’uso di target invece fa riferimento alle invocazioni in cui l’oggetto target (cioè l’oggetto incapsulato nel proxy) è un’istanza del tipo specificato. Altro PCD molto importante è args, che limita i join point ai metodi in cui gli argomenti sono istante del tipo specificato.


155

Un altro insieme di PCD molto usati fa invece riferimento alle annotazioni applicate alle classi. La più semplice, @annotation, fa riferimento ai join point in cui il metodo invocato è etichettato con l’annotazione specificata. I PCD @target, @within e @args sono analoghi ai PCD omonimi precedentemente descritti ma si riferiscono alle annotazioni. Attraverso @args è quindi possibile individuare i join point in cui il tipo attuale dei parametri passati al metodo è dotato delle annotazioni specificate. Il PCD @target seleziona l’invocazione di metodi in cui il tipo dell’oggetto invocato (cioè il target object all’interno del proxy) presenta un’annotazione del tipo specificato. Infine, @within individua i metodi dichiarati all’interno di classi che presentano l’annotazione specificata.

Specifichiamo che tali definizioni sono riferite all’ambito di Spring AOP, che limita i join point alle sole invocazioni di metodo. Nel caso di AspectJ quindi ai designatori descritti corrispondono definizioni più ampie. Inoltre in AspectJ le parole chiave this e target riferiscono lo stesso oggetto, mentre in Spring AOP, a causa del meccanismo basato su proxy, la semantica è differenziata: this fa riferimento all’oggetto proxy e target fa riferimento all’oggetto target vero e proprio incapsulato nel proxy.

Spring AOP mette a disposizione un ulteriore PCD, non previsto da AspectJ, denominato bean. Questo PCD permette di limitare i join point ad un particolare bean individuato dal nome specificato. Il nome viene specificato nella forma bean(idOrNameOfBean) dove la stringa “idOrNameOfBean” indica il nome di un bean Spring. Anche gli operatori logici sono supportati.

4.3.2.4.5 - Combinare le espressioni dei pointcut

Come nella comuni sistemi che fanno uso di espressioni regolari, AspectJ e Spring AOP permettono l’uso di metacaratteri, anche detti wildcard, che permettono di specificare un insieme di elementi. In particolare è supportato il metacarattere “*” che indica una qualsiasi stringa alfanumerica. Può essere quindi utilizzata all’interno dei nomi dei tipi, dei metodi e degli argomenti per individuare un insieme di elementi. I PCD possono essere inoltre combinati attraverso gli operatori di AND, OR e NOT logico, rappresentati rispettivamente dai simboli &&, || e !.

Inoltre, una volta definito un pointcut, dato dall’espressione più la sua signature, è possibile riferirlo attraverso la sua signature. Ad esempio il pointcut: @Pointcut("within(com.xyz.someapp.trading..*)")

private void inTrading() {}

Può essere riferito all’interno delle espressioni regolari con l’espressione inTrading(). Inoltre la visibilità che si applica ai metodi non ha alcun impatto sulla visibilità dei pointcut, che sono visibili sempre e ovunque.

4.3.2.4.6 - Dichiarare gli advice

Un advice rappresenta l’azione da compiere in corrispondenza di un join point. Sono associati quindi ad un particolare pointcut precedentemetne definito oppure ad una espressione dichiarata al momento, e possono eseguire prima dopo o attorno all’invocazione di un metodo.


156

Gli advice sono rappresentati da semplici metodi posti all’interno di un aspetto. Il tipo di advice (before, afterReturning, around etc.) è specificato tramite l’uso di annotazioni specifiche. All’interno delle annotazioni è indicato il pointcut associato all’advice, oppure un’espressione regolare.

In particolare, l’annotazione @Before permette di definire un before advice, cioè che esegue prima dell’invocazione del metodo di join point. @AfterReturning definisce un afterReturning advice, che esegue dopo che il metodo di join point è terminato. In questo caso è possibile, se necessario, accedere al valore di ritorno del metodo, specificando nell’attributo returning dell’annotazione un nome che coincide con il nome del parametro iniettato nel metodo di advice.

Un afterThrowing advice è eseguito quando il metodo di join point termina lanciando un’eccezione. In questo caso l’advice è definito tramite l’annotazione @AfterThrowing ed è possibile accedere all’eccezione generata utilizzando l’attributo throwing dell’annotazione, in cui si indica il nome del parametro del metodo di advice in cui deve essere iniettata l’eccezione.

Un after advice è invocato quando il metodo di join point individuato termina, sia con esito positivo che in seguito ad una eccezione, ed è solitamente utilizzato per il rilascio delle risorse. È definito utilizzando l’annotazione @After.

L’ultimo tipo di advice, l’around advice, esegue “attorno” al metodo intercettato, e ha l’opportunità di compiere operazioni sia prima che dopo l’esecuzione del metodo, e di determinare quando, come, e anche se, il metodo deve essere effettivamente eseguito. L’around advice è dichiarato tramite l’annotazione @Around. Il primo parametro del metodo deve essere sempre di tipo ProceedingJoinPoint. All’interno dell’advice, il metodo proceed() dell’oggetto ProceedingJoinPoint permette di eseguire il metodo intercettato. Il metodo proceed() può anche essere invocato specificando un vettore di oggetti di tipo Object, che sono usati come parametri del metodo da eseguire. Il metodo proceed() restituisce inoltre il valore di ritorno del metodo, che può essere manipolato dall’advice. Il valore visto dal chiamante del metodo sarà quello ritornato dal chiamante.

4.3.2.4.7 - Parametri degli advice

Spring offre advice completamente tipati, nel senso che è possibile specificare nella signature dell’advice i parametri tipizzati piuttosto che array di oggetti di tipo Object su cui devono essere poi eseguiti cast espliciti. Nel seguito vedremo quindi come è possibile rendere disponibili all’interno dell’advice sia gli argomenti del metodo intercettato sia altri oggetti molto utili.

Ogni metodo di advice può dichiarare come suo primo parametro un parametro di tipo JoinPoint (nell’around advice è obbligatorio dichiarare il primo parametro di tipo ProceedingJoinPoint, che è una sottoclasse di JoinPoint). L’interfaccia JoinPoint fornisce metodi molto importanti quali getArgs(), che restituisce gli argomenti del metodo, getThis(), che restituisce l’oggetto proxy, getTarget(), che restituisce l’oggetto target incapsulato nel proxy e getSignature() che ritorna una descrizione del metodo intercettato.


157

Abbiamo visto come recuperare il valore di ritorno o una eccezione all’interno di after returning advice e after throwing advice. Per rendere i valori degli argomenti disponibili nel corpo dell’advice, è possibile utilizzare una particolare forma del PCD args. In particolare, nell’espressione args è possibile specificare, piuttosto che il tipo di un parametro, il nome di un parametro dell’advice. In questo modo, il valore del parametro del metodo intercettato è legato al parametro dell’advice. Quando l’advice è invocato, Spring si occupa di iniettare il valore del parametro del metodo intercettato. Naturalmente i tipi dei due parametri, quello del metodo intercettato e quello dichiarato nell’advice, devono coincidere o almeno essere compatibili (ad esempio nell’advice può essere una super-classe).

Nell’esempio che segue questa tecnica è utilizzata per iniettare il parametro account di tipo Account del metodo dataAccessOperation nell’advice validateAccount: @Pointcut("com.xyz.myapp.SystemArchitecture.dataAccessOperation() &&" + "args(account,..)")

private void accountDataAccessOperation(Account account) {}

@Before("accountDataAccessOperation(account)")

public void validateAccount(Account account) { // ...

}

In modo analogo è possibile iniettare all’interno dell’advice, sempre sotto forma di parametri, l’oggetto proxy, l’oggetto target, e le annotazioni.

La corrispondenza tra i parametri dell’advice e quelli del pointcut si basa sui nomi dei parametri utilizzati. Dato che i nomi dei parametri non sono accessibili a tempo di esecuzione tramite reflection, il container deve adottare alcune strategie per determinare la corrispondenza. La prima strategia, prevede che l’utente espliciti la corrispondenza tramite l’attributo argNames dell’annotazione che definisce l’advice. Il valore dell’attributo rappresenta la sequenza ordinata di parametri. Nel caso sia previsto come primo parametro un oggetto di tipo JoinPoint non è necessario indicarlo nell’attributo. Tale attributo può essere omesso nel caso in cui il codice sia compilato includendo le informazioni di debug (tramite flag “–g:vars” come minimo). Nel caso non sia disponibile nessuno dei due metodi precedenti Spring cerca di dedurre le corrispondenze automaticamente, ma ciò può dare luogo a eccezioni nel caso in cui questo processo non sia possibile.

4.3.2.4.8 - Ordinamento degli advice

Nel caso in cui siano previsti molteplici advice per uno stesso join point, Spring AOP utilizza la stessa politica adottata da AspectJ: l’advice più prioritario è eseguito per primo prima dell’esecuzione del metodo di join point, e per ultimo dopo l’esecuzione del metodo di join point.

Quando due advice che sono definiti nello stesso aspetto devono essere eseguiti nello stesso join point, se non è specificato alcuna precedenza allora l’ordinamento è indefinito. Per specificare una precedenza l’aspetto deve implementare l’interfaccia Ordered, o etichettare gli aspetti con l’annotazione @Order. Nel primo caso la priorità dell’aspetto è data dal valore restituito dal metodo Ordered.getValue(), nel secondo


158

caso dal valore dell’annotazione stessa. Dati due aspetti, quello in cui questo valore di priorità è numericamente inferiore sarà eseguito per primo.

Quando due advice sono definti nello stesso aspetto e devono essere eseguiti in corrispondenza dello stesso join point, l’ordinamento è indefinito. Nel caso sia necessario definire un ordinamento tra i due deve essere considerata la possibilità di dividere gli advice in aspetti differenti.

4.3.2.4.9 - Dichiarazioni inter-tipo

Le dichiarazioni inter-tipo, dette anche introduction, permettono ad un aspetto di fare in modo che l’oggetto target implementi una precisa interfaccia, e forniscono un’implementazione della data interfaccia.

È possibile creare un’introduction tramite l’annotazione @DeclareParents, che sta a significare come suggerisce il nome che i tipi specificati hanno un nuovo super-tipo. L’annotazione va apposta alla dichiarazione, all’interno dell’aspetto, di un campo dello stesso tipo dell’interfaccia che si vuole introdurre. In questo modo l’interfaccia da introdurre può essere dedotta dal tipo del campo annotato. All’interno dell’annotazione, il valore value stabilisce, secondo un’espressione regolare AspectJ, i tipi coinvolti, mentre l’attributo defaultImpl determina l’implementazione di default fornita per l’interfaccia.

4.3.2.4.10 - Modelli di istanziazione degli aspetti

Il comportamento di default di Spring AOP prevede che vi sia una singola istanza per ogni aspetto all’interno del contesto applicativo. AspectJ definisce questo modello con il termine singleton. È possibile tuttavia definire aspetti con un ciclo di vita differente. Spring, in particolare, supporta altri due modelli di gestione del ciclo di vita: perthis e pertarget.

Un aspetto di tipo perthis può essere creato specificando la clausola perthis nell’annotazione @Aspect che definisce l’aspetto. Nella clausola va specificato un pointcut definito all’interno dell’aspetto. In questo caso sarà creata un’istanza dell’aspetto per ogni oggetto di servizio che esegue un metodo di business, cioè ogni oggetto legato nell’ambito del join point all’entità this. L’aspetto viene distrutto quando questo stesso oggetto viene distrutto.

Il modello pertarget ha un funzionamento analogo a quello di perthis con la differenza di creare un’istanza dell’aspetto per ogni oggetto individuato, nel contesto del join point, dalla parola chiave target.

4.3.2.5 Dichiarazione tramite file XML Gli stessi comportamenti descritti in precedenza possono essere configurati,

piuttosto che attraverso il supporto alle annotazioni, tramite file XML. In questo caso si fa riferimento allo schema XML aop di cui si importano i tag ed il namespace.

La configurazione degli aspetti e degli advice va posta all’interno di un elemento <aop:config>. Al suo interno possono essere contenuti pointcut, advice, e aspetti, che sono definiti tramite opportuni elementi quali <aop:poincut>


159

<aop:aspect> per pointcut e aspetti, e <aop:before>, <aop:afterReturing> e così via per i diversi tipi di advice. Si tratta sostanzialmente di differenze sintattiche, mentre sul piano concettuale il modello AOP risultante è identico a quello precedentemente descritto. Inoltre questo stile di configurazione non supporta alcune funzionalità quali i modelli d’istanziazione perthis e pertarget, e risulta molto meno leggibile rispetto al caso precedente. Solitamente viene adottata solo nel caso non sia disponibile il supporto a Java 5 e alle annotazioni. Pertanto tralasceremo questi elementi rimandando alla documentazione relativa in caso di approfondimento [SPR12].

4.3.2.6 Creazione manuale dei proxy In alternativa alla dichiarazione degli aspetti tramite annotazione e il supporto

@AspectJ o tramite file XML, è anche possibile provvedere alla creazione manuale dei proxy che incapsulano gli oggetti target.

La classe AspectJProxyFactory può essere usata per creare un proxy per un oggetto tarxget a cui sono applicati uno o più aspetti @AspectJ. L’utilizzo di base per questa classe prevede la creazione dell’oggetto AspectJProxyFactory fornendo l’oggetto target al costruttore. Dopodiché, è possibile aggiungere un numero arbitrario di aspetti tramite il metodo addAspect(). Il metodo prevede un parametro che rappresenta l’aspetto a aggiungere all’oggetto target, e che deve essere costituito da un aspetto @AspectJ. È possibile invocare il metodo più volte per aggiungere diversi aspetti. Infine, per ottenere il proxy, è possibile utilizzare il metodo getProxy() che restituisce, in conformità al pattern proxy, un oggetto con la stessa interfaccia di quello target.

4.3.3 Livello dei dati Il framework Spring offre un ampio spettro di soluzioni per gestire le comuni

problematiche in ambito enterprise riguardanti l’interazione tra il livello di accesso ai dati e il livello di business. Ciò comprende un supporto completo alla gestione delle transazioni e l’integrazione con diversi framework e tecnologie che permettono di semplificare la gestione delle sorgenti di dati.

4.3.3.1 Transazioni Il supporto alla gestione delle transazioni è una dei motivi più frequenti che

spinge all’uso del framework Spring. Spring permette la gestione delle transazioni sia con approccio dichiarativo, cioè tramite l’utilizzo di annotazioni Java 5, sia in modo programmatico, cioè esplicitamente attraverso l’uso di normale codice Java. Il supporto offerto permette di ottenere diversi benefici: un modello di programmazione consistente tra differenti API per la gestione delle transazioni, tra cui Java Transaction API (JTA), Java Database Connectivity (JDBC), Hibernate, Java Persistence API (JPA), e Java Data Objects (JDO), il supporto dichiarativo alle transazioni, cioè tramite semplici annotazioni, API semplificate rispetto a framework quali JTA.


160

4.3.3.1.1 - Introduzione alle transazioni

Una transazione è una sequenza di azioni che deve essere trattata come una singola unità di lavoro. Queste azioni devono essere completate interamente oppure non avere alcun effetto sulle risorse su cui agiscono. La gestione delle transazioni è quindi un importante elemento delle applicazioni enterprise che fanno uso di database relazionali che permette di garantire l’integrità e la consistenza dei dati.

Il concetto di transazione è riassunto nei quattro principi di atomicità, consistenza, isolamento, e durabilità (ACID). Con atomicità si fa indica che una transazione debba essere trattata come una singola operazione indivisibile, sia se la sequenza di operazioni ha successo o meno. La consistenza fa riferimento alla consistenza delle informazioni presenti all’interno del database, in termini di chiavi primarie, tabelle etc. Per isolamento si intende il fatto che ogni transazione debba essere eseguita in modo isolato e l’eventuale fallimento di una transazione non deve influire sull’esito di un’altra. L’ultimo requisito, la durabilità o anche persistenza, prevede che una volta completata la transazione, le modifiche apportate ai dati non possano andare perse.

Le quattro proprietà devono essere garantite per ogni transazione. A questo scopo sono solitamente fornite alcune operazioni per la gestione delle transazioni: un’istruzione begin che segna l’inizio di una transazione e una istruzione di commit che determina il completamento della transazione. Tra le due istruzioni sono quindi presenti le operazioni di accesso alla sorgente di dati. Nel caso in cui durante il corso della transazione sia necessario annullare la transazione, l’istruzione rollback prevede l’annullamento di tute le operazioni eseguite e il ripristino della situazione inziale.

4.3.3.1.2 - Differenze con Java EE

Uno dei maggiori vantaggi del modello di gestione offerto da Spring, rispetto ad altri quali Java EE, è la capacità di abilitare un modello di gestione consistente in qualsiasi ambiente. La stessa applicazione può beneficiare di strategie differenti di gestione delle transazioni in qualsiasi ambiente.

Quest’aspetto è fortemente contrapposto al modello offerto da Java EE, che offre fondamentalmente due tipologie di gestione, globale o locale, ed in cui la gestione è differenziata a seconda del tipo di strategia. Nel caso di strategie globali la gestione è ad opera di JTA, ed è possibile gestire risorse transazionali multiple, come database e code di messaggi. In questo caso però l’applicazione e vincolata ad eseguire in un application server e si introducono dipendenze con altre specifiche come ad esempio JNDI. Le transazioni locali, invece, non prevedono l’utilizzo di JTA ma sono limitate a una singola risorsa transazionale e sono invasive a livello di programmazione.

Nel caso di Spring, invece, offre un modello unificato e consistente pur permettendo la differenziazione delle strategie. Non è necessaria inoltre la presenza di un application server, e le applicazioni possono essere eseguite in ambienti differenti. Spring fornisce fondamentalmente due modelli di gestione: quello dichiarativo e quello programmatico. Il primo tuttavia è quello raccomandato e ci soffermeremo quindi nella descrizione di questo modello.


161

4.3.3.1.3 - Il modello transazionale Spring

Un transazione è identificata da un oggetto di tipo TransactionDefinition. L’interfaccia specifica alcuni parametri molto importanti di una transazione. Innanzitutto specifica il livello di isolamento della transazione dal lavoro eseguito dalle altre transazioni. Ad esempio, se le sono visibili le modifiche eseguite da altre transazioni. Altro parametro è il livello di propagazione, che specifica il comportamento da adottare nel caso in cui un metodo transazionale è eseguito quando esiste già un contesto transazionale. Ad esempio, il metodo potrebbe richiedere la sospensione di una transazione corrente e la creazione di una nuova transazione, oppure utilizzare quella precedentemente attivata. Il parametro timeout specifica per quanto tempo la transazione rimane attiva prima di scadere ed attivare automaticamente la procedura di callback. Infine specifica se si tratta di una transazione in sola lettura, dato che in questo caso sono possibili diverse ottimizzazioni.

Spring supporta tutte le modalità di propagazione perviste dalle CMT EJB: MANDATORY, NESTED, NEVER, NOT_SUPPORTED, REQUIRED, REQUIRES_NEW, SUPPORT e DEFAULT. MANDATORY richiede obbligatoriamente la presenza di una transazione e genera un’eccezione se questa non è presente. NESTED esegue una transazione innestata se esiste già una transazione. NEVER lancia un’eccezione se esiste già una transazione corrente. NOT_SUPPORTED provoca un’esecuzione non transazionale. REQUIRED crea una nuova transazione nel caso non esista. REQUIRES_NEW sospende la transazione corrente e crea una nuova transazione. Infine SUPPORTS esegue in modo transazionale se esiste già una transazione, ed in modo non transazionale se questa non esiste.

La chiave dell’astrazione transazionale Spring consiste nella nozione di strategia transazionale. Una strategia transazionale è definita dall’interfaccia PlatformTransactionManager, che definisce i metodi commit() e rollback() per eseguire rispettivamente le operazioni di commit o di annullamento della transazione. Le implementazioni di questa interfaccia sono definite nelle stesse modalità degli altri bean all’interno del container IoC, e non necessita di strumenti quali JNDI per essere recuperata. Ciò permette di fornire facilmente implementazioni fittizie per abilitare le funzionalità di test. Il metodo getTransaction()restituisce un oggetto di tipo TransactionStatus, che rappresenta lo stato di una transazione e può essere una nuova transazione o una transazione esistente a seconda del parametro TransactionDefinition passato.

Per il corretto funzionamento del meccanismo di gestione delle transazioni è essenziale definire la strategia transazionale, e cioè la corretta implementazione del PlatformTransactionManager. Tipicamente ciò è eseguito tramite dependency injection. La strategia è dipendente dal particolare ambiente di esecuzione: a JDBC, JTA, Hibernate e così via corrispondono implementazioni di PlatformTransactionManager differenti. Ad esempio, nel caso di JTA, si utilizza il JtaTransactionManager mentre nel caso di Hibernate si fa riferimento all’HibernateTransactionManager. La scelta è effettuata all’interno del file di configurazione XML del container IoC, configurando un normale bean di nome


162

arbitrario con l’implementazione opportuna. Tale bean dovrà poi essere utilizzato per configurare il supporto di gestione delle transazioni, come indicato nella sezione successiva.

4.3.3.1.4 - Gestione dichiarativa

La gestione dichiarativa delle transazioni è resa possibile dall’infrastruttura Spring AOP. Questo approccio permette la gestione delle transazioni tramite configurazione e annotazioni piuttosto che tramite codice. In questo modo la gestione delle transazioni può essere separata dal codice applicativo.

Sotto alcuni aspetti l’approccio di Spring è simile all’approccio offerto dagli EJB con le Container Managed Transaction (CMT) in ambiente Java EE, tuttavia presenta anche sostanziali differenze.

In primo luogo EJB CMT necessita del supporto JTA, mentre Spring può lavorare con qualsiasi ambiente come JDBC, JPA, Hibernate, JDO ed anche JTA. In secondo luogo è possibile usare il supporto transazionale in qualsiasi classe, non necessariamente un EJB. Inoltre offer una funzionalità non presente in EJB, quella delle regole di rollback, che saranno descritte nelle sezioni successive. Inoltre è possibile in Spring personalizzare il comportamento transazionale, usando Spring AOP, ad esempio inserendo un proprio comportamento di gestione in caso di rollback. Tuttavia Spring non supporta la propagazione remota delle transazioni, che è invece supportata dagli EJB.

La gestione dichiarativa delle transazioni è strettamente correlata alla natura AOP del sistema stesso. Fondamentalmente la gestione dichiarativa delle transazioni è supportata attraverso l’utilizzo di proxy AOP, in cui l’advice che si occupa della semantica transazionale è configurato tramite opportuni metadati, forniti tramite configurazione XML o tramite annotazioni. Il proxy si occupa quindi di gestire la creazione o meno della transazione in funzione della configurazione, e di gestire l’operazione di commit o di rollback in seguito alla terminazione del metodo. Lo schema descritto è rappresentato in Figura 47.

Il primo passo è quindi rappresentato dalla creazione di un advice che gestisca la semantica tradizionale. Tramite l’elemento <aop:config/> è configurare il supporto AOP. AL suo interno, l’elemento <aop:pointcut/> definisce, tramite le espressioni AspectJ, i metodi cui deve essere applicata la semantica tradizionale, mentre un elemento <aop:advisor/> richiama l’advice che si occupa della semantica transazionale, fornito da Spring. Quest’ultimo può essere configurato tramite l’elemento <tx:advice/> all’interno della configurazione XML. L’elemento permette di configurare il gestore delle transazioni, specificare se i metodi accedono in lettura o scrittura, gli attributi del sistema di gestione delle transazioni, come le regole di propagazione, il livello di isolamento e il time-out.


163

Figura 47 - Gestione delle transazioni basata su AOP.

Per provocare il rollback di una transazione è sufficiente generare un’eccezione. La configurazione di default inoltre prevede che il rollback sia provocato solo dalle cosiddette eccezioni unchecked, cioè derivate da RuntimeException. A differenza delle eccezioni checked, queste eccezioni hanno la caratteristica di non dover essere necessariamente dichiarate nelle signature dei metodi. Le regole di rollback rappresentano un concetto importante poiché permettono di specificare, in modo dichiarativo all’interno della configurazione XML, quali eccezioni devono causare il rollback automatico.

In aggiunta alla configurazione tramite XML, è possibile utilizzare l’approccio basato su annotazioni. In questo modo la configurazione transazionale è più vicina al codice e maggiormente comprensibile. Si potrebbe obiettare che in questo modo si crei un eccessivo accoppiamento, tuttavia i componenti concepiti per essere eseguiti in una semantica transazionale raramente sono utilizzati all’infuori di questo contesto.

L’approccio basato su annotazioni è realizzato tramite l’annotazione @Transactional. Con questa annotazione è possibile etichettare i metodi, le classi o le interfacce che richiedono una semantica transazionale. Se applicata ai metodi la semantica transazionale è associata al singolo metodo, mentre se applicata alla classe o all’interfaccia sono considerati tutti i metodi che ne fanno parte. Per abilitare le annotazioni la configurazione xml deve presentare, in sostituzione alla definizione degli advice e della configurazione descritta in precedenza, l’elemento <tx:annotation-driven/>. Nell’elemento va indicato anche il bean che funge da gestore delle transazioni.

L’annotazione @Transactional permette di specificare gli attributi della transazione da applicare. In particolare il tipo di propagazione, il livello di isolamento, se si tratta di sola lettura, il time-out, ed anche un insieme di annotazioni che deve causare il rollback della transazione. Il comportamento di default prevede che ogni eccezione unchecked provochi il rollback.

4.3.3.2 Object/Relational mapping Il framework Spring supporta l’integrazione con molti framework di persistenza

quali Hibernate, le specifiche Java Persistence API (JPA), Java Data Objects (JDO) e


164

fornisce inoltre servizi molto importanti nell’ambito dell’accesso ai dati quali il supporto alle transazioni. Tale integrazione permette l’utilizzo delle funzionalità di Dependency Injection e di configurazione in simbiosi i framework citati, integrandoli all’intero del sistema di gestione delle risorse e delle transazioni.

Tutti i framework sopra citati vantano tra le loro funzionalità principali il supporto al cosiddetto Object/Relational Mapping (ORM). L’ORM rappresenta una tecnica che favorisce l’integrazione del mondo object-oriented con quello relazionale. Mentre il primo vede gli oggetti come entità principali, il secondo è organizzato in tabelle. Gestire il trasferimento delle informazioni dagli oggetti alle tabelle rappresenta un’operazione piuttosto meccanica e spesso fonte di errori. Per questo molti famework di persistenza supportano questa funzionalità. L’ORM rappresenta quindi, come rappresentato in Figura 48, un collegamento tra il paradigma ad oggetti a quello relazionale, secondo una relazione che lega le classi alle tabelle, le istanze alle righe delle tabelle, e gli attributi delle istanze alle colonne. Sulla base di metadati opportunamente definiti dall’utente, il framework si incarica di gestire la creazione, il prelievo l’aggiornamento e la gestione dei dati relazionali mentre lo sviluppatore può limitarsi a gestire oggetti opportunamente definiti. Inoltre, nascondendo i dettagli implementativi del supporto di persistenza, questi framework offrono inoltre un’elevata portabilità nei confronti della specifica tecnologia DBMS utilizzata.

Figura 48 - Schema generale ORM e Hibernate.

I benefici offerti dal supporto Spring all’integrazione con questi framework sono molteplici. Innanzitutto la facilità di eseguire test sul livello di accesso ai dati, grazie all’approccio IoC di Spring che rende estremamente semplice modificare la configurazione sia del framework sia dello strato di accesso alle sorgenti dati. In questo modo è possibile eseguire le operazioni di test con una configurazione appropriata e realizzare l’isolamento dei singoli moduli di persistenza. In secondo luogo il supporto Spring si occupa di fornire un’interfaccia omogenea per il sistema di eccezioni che caratterizza il framework ORM. Spesso gli strumenti ORM utilizzano errori ed eccezioni specifiche e dipendenti dalla particolare implementazione, compromettendo la portabilità della soluzione. Spring si occupa di incapsulare le eccezioni proprietarie in eccezioni standard realizzando quindi uno strato omogeneo di gestione degli errori. Il contesto applicativo Spring può inoltre gestire la configurazione di molti dei componenti essenziali utilizzati dai framework ORM, come le SessionFactory di Hibernate o le EntityManagerFactory di JPA. Le operazioni di gestione e configurazione risultano quindi notevolmente facilitate. Inoltre permette di risolvere alcuni problemi ricorrenti relativi alla gestione delle risorse nell’ambito della persistenza. Ad esempio nel caso di Hibernate permette la condivisione degli oggetti Session al fine garantire efficienza ed una opportuna


165

gestione delle transazioni. Infine, gli strumenti ORM sono integrati all’interno del supporto transazionale Spring, permettendo la gestione delle transazioni in stile dichiarativo tipica del framework Spring. Spring supporta fondamentalmente tre diversi framework ORM: Hibernate, JPA e JDO. In questa sede ci soffermeremo su Hibernate al fine di fornire un esempio dei meccanismi di integrazione offerti da Spring, considerando che considerazioni analoghe valgono anche per gli altri due framework.

Spring raccomanda l’uso delle tecnologie ORM in combinazione al pattern Data Access Object. Si tratta di un pattern che prevede la presenza di un oggetto che fornisce un’interfaccia di accesso uniforme alle funzionalità di persistenza nascondendo la reale implementazione. Nell’ambito di Spring è utilizzato per nascondere il particolare framework di persistenza utilizzato, ad esempio incapsulando l’uso di oggetti specifici come l’oggetto Session per Hibernate o l’EntityManager di JPA.

4.3.3.2.1 - Integrazione ORM

L’obiettivo più importante dell’integrazione ORM in Spring è ottenere una suddivisione ben definita dei livelli applicativi, indipendentemente dalla tecnologia di accesso ai dati e di gestione delle transazioni, e promuovere il disaccoppiamento degli oggetti dell’applicazione. Elimina quindi le dipendenze dei servizi di business dalle strategie di accesso ai dati e di gestione delle transazioni tramite un approccio consistente di combinare gli oggetti applicativi mantenendoli liberi da dipendenze dal container e garantendone quindi la riusabilità.

Spesso nelle applicazioni enterprise la gestione delle risorse richiede la creazione di codice ripetitivo e poco pertinente alla reale logica di business dell’applicazione. In questo ambito sono state sviluppate diverse soluzioni che hanno però il difetto di sacrificare una gestione opportuna dei malfunzionamenti in favore di una semplificazione dello stile di programmazione. Spring adotta una soluzione molto semplice per la gestione appropriata delle risorse, che consiste nell’applicazione degli intercettori AOP alle tecnologie ORM.

L’infrastruttura fornisce una gestione appropriata delle risorse e la conversione delle eccezioni proprietarie verso un sistema generale di eccezioni indipendente dal particolare framework utilizzato. Introduce una gerarchia di eccezioni applicabile ad ogni strategia di accesso ai dati. In funzione della tecnologia utilizzata, infatti, i componenti DAO possono generare un’eccezione di tipo HibernateException, PersistenceException oppure JDOException. Questo vuol dire che per trattare le eccezioni in modo appropriato è necessario introdurre una dipendenza dalla particolare tecnologia di persistenza utilizzata. In questo senso Spring si occupa di effettuare la traduzione di queste eccezioni in modo trasparente, semplicemente tramite l’applicazione dell’annotazione @Repository, come descritto nella sezione 4.3.1.7.5 -. È necessario poi definire all’interno del file di configurazione il componente PersistenceExceptionTranslationPostProcessor, un particolare tipo di PostProcessor, che si occupa di ricercare i componenti PersistenceExceptionTranslator, incaricati di effettuare l’operazione di


166

traduzione, e intercettare tramite AOP tutti i bean marcati con @Repository per applicare la traduzione delle eccezioni appropriata.

4.3.3.2.2 - Hibernate

Uno dei framework più diffusi per la gestione del mapping ORM è Hibernate. Si pone tra i tradizionali oggetti Java e il database per gestire le operazioni di persistenza sulla base del meccanismo di mapping O/R appropriato. In Figura 49 è rappresentata l’architettura generale. Al fine di rendere persistenti dei dati su database, sono creati a livello applicativo delle istanze di oggetti dette entità (entity), classi Java a cui corrispondo precise tabelle sul database. Questi oggetti sono detti transienti (Transient) dato che non sono ancora stati resi persistenti. Per fare ciò è necessario utilizzare una Session, che rappresenta una singola connessione single-threaded con il database. Supporta inoltre la gestione delle transazioni e mantiene una cache di entità persistenti per facilitare le operazioni di accesso al database. Un’istanza dell’oggetto Session viene ottenuta tramite la SessionFactory, un oggetto singleton che implementa il pattern factory. L’oggetto SessionFactory contiene al suo interno le informazioni di configurazione del mapping O/R, opportunamente caricate all’atto della sua creazione. Inoltre gestisce due oggetti molto importati: il ConnectionProvider, che permette di creare e gestire le connessioni verso il database, e permette di astrarre dalla sorgente di dati sottostante, e la TrannsactionFactory, una factory che permette di creare le transazioni.

Figura 49 - Architettura di Hibernate.

La potenza del framework Hibernate sta nel fatto che le entità persistenti sono rappresentate da semplici oggetti POJO, i cui campi rappresentano le colonne della tabella associata su database. Ciò permette di utilizzare gli stessi oggetti che rappresentano le informazioni persistenti anche all’interno del livello di business o di presentazione. Le entità sono associate esclusivamente ad un oggetto Session, e alla chiusura della connessione sono completamente slegati (o detached) dal contesto di persistenza.

Una configurazione Hibernate è rappresentata da un’istanza dell’oggetto Configuration. Un’istanza di questa classe rappresenta l’interno mapping delle entità presenti nell’applicazione verso il database. È inoltre utilizzato per costruire un’istanza


167

immutabile dell’oggetto SessionFactory. Le informazioni di mapping possono essere espresse o tramite XML oppure tramite l’uso di annotazioni apposte alle entità stesse.

4.3.3.2.3 - Hibernate in Spring

Nell’approccio Hibernate tradizionale, è necessario all’interno dell’applicazione procurarsi oggetti di tipo SessionFactory per poter creare poi oggetti Session. Questo rendeva quindi necessario la creazione di codice per la creazione o il recupero dell’unica istanza presente a livello applicativo di questo oggetto. Spring viene incontro a questa necessità permettendo di definire queste ed altre risorse come bean all’interno del container Spring. In questo modo gli oggetti che devono accedere queste risorse possono ricevere riferimenti a istanze predefinite tramite iniezione. Non solo, è possibile configurare questi oggetti specificando le loro dipendenze all’interno del file XML. Ad esempio, per una SessionFactory, è possibile configurare la particolare sorgente dati da utilizzare. Non solo, sono forniti tag per specificare il percorso dei file di configurazione Hibernate con cui configurare la factory.

Spring permette inoltre l’implementazione del pattern DAO con tecnologia Hibernate facendo uso di una sintassi puramente Hibernate, cioè che non fa riscorso, nonostante sia integrato con il supporto Spring alle transazioni, alle API Spring. In questo modo il livello DAO non prevede alcuna dipendenza da Spring. Sostanzialmente l’approccio tradizionale Hibernate prevede che, all’interno di un’implementazione DAO, le operazioni di accesso al contesto di persistenza siano effettuate a partire da un oggetto SessionFactory, da cui è recuperata la sessione corrente tramite il metodo getCurrentSession(). Questo restituisce un oggetto di tipo Session tramite cui è possibile accedere al contesto di persistenza. Come abbiamo detto prima, è possibile fare in modo che Spring inietti l’oggetto SessionFactory opportunamente configurato. Inoltre Spring fornisce una particolare implementazione di SessionFactory, la LocalSessionFactoryBean, che implementa il metodo getCurrentSession per qualsiasi strategia transazionale Spring, ritornando una sessione configurata secondo la semantica transazionale al momento utilizzata. In questo modo è possibile fornire un’implementazione DAO basata esclusivamente su Hibernate conservando per la capacità di partecipare al suo interno alle transazioni gestite da Spring, descritte nella sezione 4.3.3.1.

4.3.4 Spring MVC Il framework Spring Model-View-Controller (MVC) rappresenta la soluzione

Spring per il livello di presentazione in ambito web. Il framework è concepito per supportare la costruzione di applicazioni web flessibili e altamente disaccoppiate. Il pattern model-view-controller permette di separare la logica di presentazione dalla logica di business e dalla logica di navigazione all’interno dell’applicazione. In accordo al pattern Spring MVC definisce le tre entità fondamentali: gli oggetti del modello sono responsabili di incapsulare i dati applicativi, le view visualizzano le informazioni all’utente con l’aiuto degli oggetti del modello, e i controller sono responsabili di ricevere le richieste dall’utente e richiamare i servizi di back-end.

Il framework è costruito attorno ad una speciale servlet, la DispatcherServlet, che si occupa di smistare le richieste provenienti dall’utente


168

verso i componenti Controller atti a gestirle. Il framework permette inoltre di configurare la corrispondenza tra gli indirizzi URL e i metodi del controller e la risoluzione delle viste da presentare all’utente in funzione dei risultati di elaborazione.

La creazione dei componenti Controller è basata sulle annotazioni @Controller e @RequestMapping, descritte nella sezione 4.3.4.3. A partire da Spring 3.0, inoltre, l’annotazione @Controller permette anche la creazione di RESTful Web Services.

In Spring Web MVC è possibile usare un qualsiasi oggetto per incapsulare i dati provenienti dall’utente. Spring si occupa di effettuare automaticamente di mappare queste informazioni all’interno degli oggetti appropriati. Il meccanismo di conversione è inoltre molto flessibile: se i tipi dei dati non combaciano, ad esempio, sono trattati come errori di validazione piuttosto che come errori di sistema, e possono quindi essere gestiti opportunamente dall’applicazione. Ciò elimina la necessità di prevedere appositi oggetti con campi non tipizzati quali stringhe, al fine di accogliere l’input dell’utente. Al contrario, è altamente consigliato utilizzare gli stessi oggetti di business.

Anche il meccanismo di risoluzione delle view è estremamente flessibile. Un Controller è tipicamente responsabile di costruire un modello dei dati e selezionare il nome di una view atta a visualizzarli. La risoluzione del nome delle view è altamente configurabile, sia tramite l’estensione dei file, che tramite l’header HTTP Accept, tramite i nomi dei bean, file di proprietà, o anche una implementazione personalizzata del ViewResolver. Il modello può essere rappresentato da un oggetto di tipo Map, quindi come insieme di coppie chiave-valore, permettendo la completa astrazione dalla tecnologia di visualizzazione. È possibile integrare quindi molteplici tecnologie di visualizzazione quali JSP, Velocity e Freemarker, o utilizzare direttamente i formati XML, JSON, e altre tipologie di contenuti.

4.3.4.1 Caratteristiche di Spring MVC I moduli Spring MVC includono alcune caratteristiche molto peculiari.

Innanzitutto una chiara separazione dei ruoli tra i componenti. Ogni componente, sia esso un controller, un componente pe la validazione dei dati, la DispatcherServlet o un oggetto del modello rappresenta un oggetto con responsabilità altamente specializzate. Inoltre è possibile configurare sia il framework sia i componenti applicativi come bean. Ne risulta un framwork adattabile, non intrusivo, e flessibile. È ad esempio è possibile definire controller i cui metodi hanno una signature arbitraria, in funzione del tipo di richiesta che devono servire. Gli oggetti di business sono altamente riusabili in quanto non fanno riferimento in alcun modo alle API Spring MVC. Offre un meccanismo personalizzabile di validazione e conversione dei tipi, con la generazione di errori a livello applicativo nel caso di valori incompatibili. Permette di personalizzare il gestore del mapping dei metodi di servizio e la risoluzione delle viste, andando dalla configurazione più semplice basata su URL a strategie molto sofisticate.


169

Il trasferimento del modello come insieme di coppie chiave-valore supporta l’integrazione con qualsiasi tecnologia. Una libreria specializzata di tag JSP, nota come Spring tag library, fornisce supporto per funzionalità come il binding dei dati.

4.3.4.2 La DispatcherServlet Il framework Spring MVC è progettato, come molti altri framewrok MVC,

attorno ad una Servlet centrale che smista le richieste verso i controller e offre funzionalità che facilitano lo sviluppo delle applicazioni web. La DispatcherServlet Spring, tuttavia, offre funzionalità molto più avanzate. È completamente integrata con il container IoC abilitando anche tutte le altre funzionalità offerte da Spring.

Quando una richiesta è inviata al Framework MVC, la richiesta è inizialmente ricevuta dalla DispatcherServlet, che consulta l’HandlerMapping per conoscere il controller associato alla richiesta da invocare. Il controller elabora la richiesta invocando il metodo di servizio associato e restituisce un oggetto di tipo ModelAndView alla DispatcherServlet. L’oggetto ModelAndView contiene il modello dei dati e il nome della view. La DispatcherServlet consegna il nome della view al ViewResolver per trovare la view da invocare. A questo punto la DispatcherServlet passa alla view l’oggetto del modello per visualizzare il risultato. La view, con l’aiuto dei dati del modello, visualizzerà il risultato all’utente. Il processo descritto è rappresentato in Figura 50.

Figura 50 - Flusso di gestione di una richiesta da parte del framework MVC.

Il meccanismo descritto però rappresenta solo il meccanismo base. Vi sono in realtà molte possibili varianti e sfaccettature che rendono il meccanismo altamente flessibile. Ad esempio, piuttosto che un oggetto MapAndView, è possibile che il controller restituisca semplicemente il modello, e la view sia dedotta sulla base di una serie di convenzioni, oppure è possibile che sia il modello ad essere definito implicitamente e il controller restituisca semplicemente una stringa che rappresenta il nome logico della view in cui visualizzare il modello. Ancora, è possibile che il metodo di servizio restituisca un oggetto arbitrario che il container si occupa di convertire nel corpo del messaggio di risposta.

La DispatcherServlet è una normale Servlet che estende la classe HttpServlet ed è quindi dichiarata nel file web.xml dell’applicazione web. È necessario quindi, secondo la normale configurazione Java EE, indicare l’insieme di


170

URL che devono essere mappati nella Servlet all’interno del file di configurazione, e che saranno quindi gestiti dal framework Spring MVC.

Come descritto nella sezione 4.3.1, i contesti applicativi possono essere organizzati all’interno di una gerarchia, secondo precise regole di visibilità dei bean definiti. All’interno del framework Spring MVC, ogni DispatcherServlet ha un proprio contesto applicativo, rappresentato da un WebApplicationContext, che eredita i bean già definiti nel WebApplicationContext radice. Ognuna delle DispatcherServlet può, all’interno del proprio contesto, ridefinire i bean ereditati o definirne altri. In Figura 51 è rappresentata la gerarchia di contesti descritta.

Figura 51 - Gerarchia di contesti in Spring MVC.

Per l’inizializzazione di una DispatcherServlet, Spring MVC va alla ricerca di un file chiamato [nome-sevlet]-servlet.xml, all’interno del direttorio WEB-INF dell’applicazione web, per creare i bean definiti al suo interno, sovrascrivendo la definizione di un qualsiasi bean con lo stesso nome che si trovi nello scope globale.

Il WebApplicationContext rappresenta un’estensione dell’ApplicationContext dotato di alcune funzionalità addizionali specifiche per le applicazioni web. Differisce da un normale ApplicationContext poiché è capace di risolvere i cosiddetti temi (che saranno illustrati nella sezione 4.3.4.6), e perché è a conoscenza della Servlet a cui è associata. Il WebApplicationContext inoltre è legato al contesto della servlet, il ServeltContext, che è possibile recuperare attraverso gli opportuni metodi forniti dalle API Java EE.

4.3.4.2.1 - I bean predefiniti

La DispatcherServlet si avvale di alcuni bean predefiniti, che sono parte del framework Spring MVC, per elaborare le richieste di servizio e fornire le viste appropriate. È possibile selezionare quali particolari bean utilizzare semplicemente configurandoli nel WebApplicationContext. Tuttavia ciò non è necessario in quanto Spring MVC mantiene una lista dei bean di default da usare nel caso non siano configurati.

L’HandlerMapping si occupa di mappare le richieste in ingresso, secondo criteri che variano in funzione dell’implementazione utilizzata, nei gestori opportuni e


171

in una lista di pre- e post-processori. L’implementazione più usata utilizza controller configurati tramite annotazioni, ma sono possibili anche altre implementazioni. L’HandlerAdapter aiuta la DispatcherServlet a invocare i gestori mappati per una determinata richiesta, indipendentemente dal tipo di gestore. Nel caso di controller configurati tramite annotazioni, ad esempio, è necessario verificare la risoluzione in conformità a questi metadati. Lo scopo principale di un HandlerAdapter è di nascondere alla DispatcherServlet questo tipo di dettagli. L’HandlerExceptionResolver mappa le diverse eccezioni in viste opportune per la notifica degli errori all’utente e permette inoltre comportamenti di gestione degli errori più complessi. Il ViewResolver si occupa di risolvere i nomi logici delle viste, rappresentati da stringhe, nelle view concrete. Il LocaleResolver permette di recuperare informazioni in merito alle funzionalità di internazionalizzazione per offrire viste specifiche per la località dell’utente. Il ThemeResolver recupera i temi, cioè le configurazioni di visualizzazione, usati dall’applicazione per offrire viste con stili personalizzati. Il MultipartResolver interpreta i messaggi di tipo multi-part per supportare funzionalità quali il caricamento dei file sul server.

Per ognuno di questi oggetti la DispatcherServlet mantiene una lista d’implementazioni di default. Tali bean sono configurati con i valori più comuni, ma è molto frequente la necessita di personalizzare una o più proprietà fornite dai bean sovrascrivendo l’implementazione di default. Nel caso in cui sia specificata una diversa configurazione per un bean, quella di default è ignorata.

4.3.4.2.2 - Il processo di elaborazione

Dopo la configurazione di una DispatcherServlet, all’arrivo di una richiesta ha luogo il processo di elaborazione per elaborarla e produrre la risposta per l’utente. Innanzitutto, all’arrivo della prima richiesta viene recuperato il WebApplicationContext e legato come attributo alla richiesta, in modo che possa essere acceduto dagli altri componenti.

Inizialmente il processo prevede l’applicazione dei vari resolver al fine di supportarne il processo di elaborazione. Il LocaleResolver è legato alla richiesta per abilitare gli elementi nel processo di risoluzione della località da usare per l’elaborazione della richiesta. Se non è prevista risoluzione della località, questo passo non è eseguito. Il ThemeResolver è legato alla richiesta per permettere a elementi come viste di determinare quali temi usare. Se non si fa uso di temi, è possibile ignorarlo. Se è specificato un MultipartResolver, la richiesta è ispezionata per la ricerca di campi multipart. Se sono trovati, la richiesta è incapsulata in una MultipartHttpServletRequest e procede nei passi successivi di elaborazione.

A questo punto il container cerca un handler appropriato per elaborare la richiesta. Nel caso in cui sia presente, la catena di esecuzione associata all’handler, costituita nell’ordine da pre-processori, controller, e post-processori, viene eseguita per elaborare il modello o la vista da utilizzare. Nel caso in cui sia restituito un modello, questo è integrato all’interno della vista selezionata. Se non è ritornato alcun modello (ad esempio perché un pre-processore intercetta la richiesta), non è elaborata alcuna vista, tipicamente poiché sono messi in atto altri meccanismi che soddisfano la


172

richiesta in modo differente. Ad esempio, potrebbe essere previsto l’invio di una risposta con contenuto JSON, piuttosto che di una vista tradizionale.

4.3.4.3 Realizzazione dei Controller I controller forniscono l’accesso alle logiche applicative che sono tipicamente

definite all’interno di un’interfaccia di servizio. Interpretano l’input dell’utente e lo trasformano in un modello che è presentato tramite la vista. Spring implementa i controller in modo molto astratto, permettendo di creare un’ampia varietà di servizi.

A partire da Spring 2.5 è stato introdotto il modello di controller basato su annotazioni. Questo supporto è disponibile sia per il framewrok Servlet MVC sia per Portlet MVC. I controller implementati in questo modo non devono estendere alcuna classe specifica o implementare particolari interfacce. Inoltre, non hanno alcuna dipendenza dalle API Servlet o Portlet, nonostante possano essere facilmente configurati per accedere alle loro funzionalità.

L’utilizzo dell’annotazione @Controller su di una particolare classe indica che questa svolge il ruolo di controller. L’annotazione funge quindi da stereotipo per la classe annotata. Il container scansiona la classe così annotata alla ricerca di metodi di servizio, che sono indicati tramite l’annotazione @RequestMapping. In alternativa è possibile definire esplicitamente i bean che fungono da controller, secondo le modalità standard della configurazione XML. Tuttavia quella basata su annotazioni è decisamente la modalità consigliata più utilizzata. Come indicato nella sezione 4.3.1.7.5 -, per utilizzare l’annotazione @Controller è necessario abilitare la scansione del classpath all’interno della configurazione XML tramite l’elemento <context:component-scan/>.

L’annotazione @RequestMapping è utilizzata per configurare la corrispondenza tra determinati URL e un particolare metodo di servizio del controller. Può anche essere usato a livello di classe per mappare un insieme di richieste in un particolare controller, utilizzando poi l’annotazione a livello di metodo per direzionare le richieste verso i singoli metodi.

All’interno dell’annotazione è possibile quindi indicare innanzitutto l’URL che corrisponde a un particolare metodo o a una classe, sotto forma di stringa. Dispone inoltre dell’attributo method per specificare il metodo HTTP (GET, POST, etc.) cui il metodo di servizio deve corrispondere.

Non è necessario utilizzare l’annotazione anche a livello di classe, ma in questo caso l’URL indicato nei metodi di servizio è relativa a quella indicata a livello di classe. L’annotazione @RequestMapping supporta inoltre pattern per i percorsi contenenti metacaratteri, come ad esempio * per indicare una stringa arbitraria.

4.3.4.3.1 - URI Template pattern

Gli URI template possono essere usati all’interno dell’annotazione @RequestMapping per facilitare l’accesso dei metodi di servizio a specifiche parti dell’URL.


173

Gli URI template sono simili ai normali URI formati da stringhe, ma contengono anche uno o più nomi di variabili racchiusi tra parentesi graffe, secondo la notazione {nome-variabile}. Quando queste variabili sono sostituite con il loro valore attuale, il template diventa un URI. L’URI template http://www.example.com/users/{userId}, ad esempio, contiene la variabile userId. L’assegnamento del valore john alla variabile dà luogo all’URI http://www.example.com/users/john.

In Spring MVC è possibile apporre l’annotazione @PathVariable all’argomento di un metodo per legare il parametro al valore di una variabile dell’URI template. Quando il controller gestisce la richiesta, il valore dell’argomento del metodo è impostato al valore trovato all’interno dell’URI. Facendo riferimento all’esempio precedente, quando è ricevuta una richiesta per http://www.example.com/users/john, il valore di un argomento @PathVariable String userId presente nel metodo è john. Ciò permette di accedere facilmente, all’interno del metodo, alle informazioni presenti nell’URI, rendendole disponibili direttamente come parametri. Il nome della variabile nell’URI template e dell’argomento del metodo devono coincidere. Altrimenti nell’annotazione @PathVariable è possibile specificare il nome della variabile dell’URI template.

È possibile avere più di una variabile all’interno di un URI template, ognuna legata a un diverso argomento @PathVariable del metodo. Il tipo degli argomenti legati a una variabile può essere di un qualsiasi tipo primitivo come int, long o anche Date. Spring si occupa di effettuare automaticamente la conversione al tipo appropriato, o genera un’eccezione nel caso il procedimento fallisca. Se l’annotazione è utilizzata su un argomento di tipo Map<String, String>, la mappa è popolata con tutte le variabili presenti nell’URI template. È inoltre possibile registrare il supporto per la conversione di tipi di dati addizionali. Gli URI template possono essere utilizzati anche nel caso in cui l’annotazione @RequestMapping sia utilizzata a livello di metodo.

Gli URI template supportano inoltre l’utilizzo di espressioni regolari all’interno dei nomi delle variabili. La sintassi è {nome-variabile:regex} dove la prima parte definisce il nome della variabile e la seconda parte l’espressione regolare.

4.3.4.3.2 - Media Type

È possibile restringere l’insieme di richieste HTTP mappate su un particolare metodo di servizio del controller specificando una lista di media type, cioè un insieme di tipologie di media, che il metodo è in grado di accettare. Questa specifica fa riferimento al campo Content-Type contenuto all’interno dell’header HTTP, descritto nel paragrafo 2.3.4.1. In questo modo il metodo di servizio sarà invocato solo se l’header Content-Type della richiesta coincide con il media type specificato. Per attuare questa tecnica si utilizza il campo consumes dell’annotazione @RequestMapping. Possibili valori sono “application/json” per un metodo che accetta contenuti in formato JSON, “application/xml” per servizi che accettano messaggi in formato XML, o “text/plain” per il puro testo. È anche possibile utilizzare espressioni negate sfruttando il metacarattere “!”, come ad esempio


174

“!text/plain”, per indicare un qualsiasi media type all’infuori di quello specificato.

Oltre a specificare il tipo di contenuti che il metodo consuma, è possibile indicare anche quelli che il metodo produce, contribuendo a restringere ulteriormente l’insieme di richieste che sono mappate sul metodo. In questo caso la selezione è effettuata sulla base del valore dell’header HTTP Accept, che indica il tipo di contenuti che una richiesta accetta come messaggio di risposta. Il tipo di contenuti che un metodo di servizio produce è specificato tramite il campo produces dell’annotazione @RequestMapping. Anche in questo caso le espressioni contenenti i media type possono essere negate.

È possibile controllare l’insieme delle richieste HTTP mappate sul metodo di servizio anche attraverso i parametri contenuti all’interno della richiesta e i valori contenuti all’interno dell’header. In particolare i campi header e param dell’annotazione permettono di specificare la presenza, l’assenza, o un particolare valore sia di un header sia di un parametro della richiesta.

4.3.4.3.3 - Definizione dei metodi di servizio

I metodi di servizio etichettati con l’annotazione @RequestMapping possono avere signature molto flessibili, grazie all’ampio spettro di argomenti e tipi di ritorno supportati dal framework Spring MVC. Di seguito procederemo con una panoramia prima sugli argomenti e poi i tipi di ritorno supportati, rimandando alle sezioni successive l’analisi dettagliata dei singoli meccanismi.

Innanzitutto è possibile utilizzare come argomenti dei metodi di servizio numerosi tipi di oggetti che fanno riferimento alle API Servlet. Spring MVC si occupa automaticamente di iniettare gli oggetti corrispondenti prelevandoli dal web container. Si tratta in particolare dei tipi HttpServletRequest, HttpServletResponse e HttpSession, che rappresentano rispettivamente la richiesta, la risposta e la sessione HTTP corrente, o i tipi InputStream o Reader che permettono di accedere alla richiesta in lettura, o OutputStream e Writer che permettono di accedere alla risposta in scrittura. Ancora, nel caso si esegua all’interno di un contesto di sicurezza, che preveda l’autenticazione degli utenti, è possibile indicare un argomento di tipo Principal che rappresenta l’utente correntemente autenticato.

Come abbiamo già detto è possibile annotare gli argomenti con @PathVariable per accedere alle variabili contenute all’interno dell’URI template. Spring MVC offre un’altra annotazione molto importante che può essere applicata agli argomenti di un metodo. Si tratta di @RequestParam, che permette di accedere all’interno del metodo a specifici parametri presenti all’interno della richiesta. Come nel caso degli URI template, i valori dei parametri sono convertiti secondo il tipo dichiarato dall’argomento del metodo. L’annotazione sarà descritta più in dettaglio nella sezione 4.3.4.3.4 -. L’annotazione @RequestHeader permette di accedere a specifici header HTTP, ed anche in questo caso si ha la conversione automatica dei tipi. Attraverso @RequestBody i parametri annotati sono collegati al corpo della richiesta HTTP. In questo caso la conversione del corpo del messaggio al tipo dell’argomento è effettuata con l’ausilio di oggetti di tipo HttpMessageConverter. Il


175

meccanismo sarà descritto in dettaglio più avanti. L’annotazione @RequestPart permette invece di accedere ad una specifica sezione di messaggi HTTP di tipo multipart/form-data. Questo tipo di messaggio è costituito da molteplici sezioni, ognuna contenente un certo tipo di contenuto, che possono quindi essere facilmente acceduti all’interno del metodo grazie al supporto Spring MVC.

Ancora, è possibile utilizzare argomenti di tipo Map, Model o ModelMap per arricchire il modello implicito che è esposto alla vista web. Definendo argomenti di tipo RedirectAttributes è possibile accedere l’insieme di attributi da usare in caso di re-direzione, ed anche aggiungere attributi temporanei accessibili durante la redirezione.

Gli oggetti form permettono di legare i parametri della richiesta provenienti da una form alle proprietà e ai campi dei bean, con conversione di tipi personalizzabile, in funzione dei metodi etichettati @InitBinder e della configurazione degli HandlerAdapter. Inoltre è possibile accedere agli errori di validazione di questi attributi dichiarando oggetti di tipo Errors o BindingResult direttamente dopo l’oggetto form.

È possibile iniettare inoltre un UriComponentBuilder, cioè un oggetto capace di costruire gli URL tenendo conto dell’host, della porta, dello schema e della servlet corrente.

Per quanto riguarda i metodi di ritorno, sono supportati innanzitutto oggetti di tipo ModelAndView, che rappresentano una coppia formata da un modello, popolato dal risultato dei metodi accessori annotati con @ModelAttribute, e il nome logico di una view. Nel caso si ritorni un oggetto di tipo Model, che non contiene il nome della view, questo viene implicitamente determinato tramite un RequestToViewNameTranslator, e il modello arricchito come nel caso precedente. Anche ritornando un oggetto di tipo Map questo viene usato nello stesso modo del caso precedente. Ritornando un oggetto di tipo View, invece, il modello è implicitamente determinato tramite gli oggetti comando e le annotazioni @ModelAttribute. Un valore di tipo String è interpretato come il nome logico di una view, con il modello implicitamente determinato tramite l’annotazione @ModelAttribute. Un tipo di ritorno void è utilizzato nel caso in cui il metodo gestisca da solo la risposta, ad esempio dichiarando un argomento di tipo HttpServletResponse, o se il nome della view può essere implicitamente determinato.

Infine, se il metodo è annotato con @ResponseBody, il tipo di ritorno è automaticamente trasferito all’interno del corpo della risposta HTTP. Il valore di ritorno è convertito al tipo dichiarato nel metodo attraverso un HttpMessageConverter. L’annotazione sarà descritta con maggiore dettaglio più avanti. Restituendo oggetti di tipo HttpEntity o ResponseEntity si ottiene lo stesso comportamento di @ResponseBody ma è possibile anche accedere agli header e alla risposta HTTP. Il corpo dell’oggetto sarà anche in questo caso convertito usando un HttpMessageConverter. Ogni altro tipo di ritorno è considerato come un singolo attributo del modello che deve essere fornito alla vista, usando il nome dell’attributo specificato tramite @ModelAttribute a livello del metodo.


176

4.3.4.3.4 - @RequestParam

L’annotazione @RequestParam permette di legare i parametri di una richiesta HTTP agli argomenti di un metodo di servizio nel controller. Va apposta all’argomento del metodo in cui deve essere iniettato il parametro desiderato. Il valore dell’annotazione specifica il nome identificativo del parametro all’interno della richiesta HTTP.

Il comportamento di default prevede che, se dichiarati nella signature del metodo, tali parametri debbano essere obbligatoriamente presenti nella richiesta HTTP. In alternativa è possibile specificare, tramite l’attributo required, che si tratta di parametri opzionali. Nel caso in cui il tipo dell’argomento non sia String, è messo in atto il meccanismo di conversione automatica dei tipi, descritto nella sezione 4.3.4.3.10 -.

4.3.4.3.5 - @RequestBody

L’annotazione @RequestBody indica che il parametro deve essere legato contenuto del corpo del messaggio di richiesta HTTP. Il meccanismo di conversione del corpo della richiesta nel tipo dell’argomento è attuato tramite un HttpMessageConverter. Quest’oggetto è utilizzato nel caso di una conversione sia da richiesta HTTP a oggetto, come in questo caso, e sia da oggetto a risposta HTTP, come nel caso di @ResponseBody descritto in 4.3.4.3.6 -.

Il framework Spring MVC supporta a default le conversioni dei seguenti tipi: vettori di byte, tramite il ByteArrayMessageConverter, stringhe, tramite lo StringHttpMessageConverter, form da e verso una MultiValueMap. Inoltre, abilitando particolari configurazioni dette MVC Java Config o MVC XML Namespace, è possibile disporre di due convertitori molto importati: il Jaxb2RootElementHttpMessageConverter, che permette di convertire oggetti Java in e da XML, e il MappingJackson2HttpMessageConverter, che permette la conversione al e dal formato JSON. Si tratta di due servizi molto importanti in quanto permettono di ricevere e inviare messaggi HTTP contenenti XML e JSON. Questo meccanismo, unito a quello di @RequestMapping che specifica gli URI delle risorse e i metodi HTTP, permette di definire semplici metodi del controller che fungono a tutti gli effetti da servizi RESTful. Oltre ad essere estremamente semplice, questa tecnica svincola il programmatore dell’onere della traduzione degli oggetti di business nel formato equivalente JSON o XML, che viene effettuato in modo automatico e trasparente dal container sottostante. All’interno dei metodi di servizio quindi, il programmatore può limitarsi a gestire oggetti di business mantenendo un elevato livello di astrazione.

Nel caso in cui sia aggiunta l’annotazione @Valid all’argomento del metodo, questo sarà validato usando un’istanza di Validator. Il meccanismo è configurato automaticamente sotto l’assunzione che l’oggetto Validator sia disponibile all’interno del classpath. Come nel caso dei parametri @ModelAttribute, se l’argomento è seguito da un altro argomento di tipo Error è possibile esaminare gli errori di conversione. Altrimenti è generata un’eccezione ed è inviato al client un messaggio HTTP di errore con status 400 (Bad Request).


177

4.3.4.3.6 - @ResponseBody

L’annotazione @ResponseBody è molto simile a @RequestBody, con la differenza che è apposta ad un metodo piuttosto che ad un argomento, e indica che il tipo di ritorno deve essere convertito nel corpo della risposta HTTP, piuttosto che inserito in un modello o interpretato come una view.

Come nel caso di @RequestBody, Spring converte l’oggetto restituito dal metodo nel corpo della risposta usando uno degli HttpMessageConverter registrati presso il container.

4.3.4.3.7 - HttpEntity e ResponseEntity

L’oggetto HttpEntity<?> è molto simile al caso degli oggetti etichettati con @RequestBody e @ResponseBody, e può essere usato per indicare, tramite parametrizzazione, sia il tipo di un parametro di ingresso che di uscita di un metodo di servizio. Tuttavia, oltre a fornire accesso al corpo della richiesta e della risposta HTTP come nei casi precedenti, HttpEntity<?> e la sua sottoclasse ResponseEntity<?>, specifica per la risposta, permettono l’accesso agli header presenti nei messaggi HTTP, tramite il metodo getHeaders(). È possibile quindi leggere o scrivere gli header a seconda che si tratti di un messaggio di richiesta o di risposta. Anche in questo caso la conversione tra il corpo dei messaggi di richiesta e risposta, ed il tipo parametrico “?” indicato nella definizione dell’HttpHeader<?>, è effettuato tramite gli HttpMessageConverter.

4.3.4.3.8 - @ModelAttribute

L’annotazione @ModelAttribute può essere usata sia su metodi che sugli argomenti.

Se applicata sui metodi indica che lo scopo del metodo è, piuttosto che soddisfare le richieste di servizio, popolare con uno o più attributi il modello. Questo tipo di metodi supportano gli stessi tipi di argomenti dei metodi di servizio @RequestMapping, ma non possono essere mappati direttamente in richieste. Sono invece invocati prima dei metodi @RequestMapping, all’interno dello stesso controller, per popolare il modello con gli attributi necessari. I metodi possono popolare il modello sia restituendo il nuovo attributo come parametro di ritorno sia accettando un parametro di tipo Model da popolare. Un controller può avere numerosi metodi @ModelAttribute. Tutti questi metodi sono invocati prima dei metodi @RequestMapping del controller stesso. È possibile raccogliere questi metodi in una classe separata annotata con @ControllerAdvice.

L’annotazione @ModelAttribute può inoltre essere usata sui metodi @RequestMapping. In questo caso il valore di ritorno del metodo è interpretato come attributo di un modello piuttosto che come il nome di una view. Il nome della view è invece dedotto secondo la convezione di nomi, come nel caso dei metodi senza parametro di ritorno.

Utilizzando l’annotazione @ModelAttribute su un argomento di metodo, si vuole indicare che l’argomento deve essere recuperato dal modello. Se non presente nel modello, l’argomento dovrebbe essere prima istanziato e poi aggiunto al modello.


178

Una volta presente nel modello, i campi dell’argomento dovrebbero essere popolati da tutti i parametri della richiesta che hanno nomi coincidenti. Questo è noto in Spring MVC come data binding, un meccanismo molto utile che permette di evitare la necessità di convertire singolarmente ogni campo di una form.

Prendendo ad esempio un metodo del tipo: @RequestMapping(value="/owners/{ownerId}/pets/{petId}/edit", method = RequestMethod.POST)

public String processSubmit(@ModelAttribute Pet pet) { }

L’istanza dell’oggetto pet potrebbe provenire da diversi meccanismi: potrebbe essere stato inserito nel modello da un metodo @ModelAttribute all’interno dello stesso container precedentemente invocato, o potrebbe essere stato recuperato sulla base di una variabile dell’URI template o istanziato usando il costruttore di default. Il primo caso, quello del metodo @ModelAttribute, prevede normalmente l’accesso ad un database all’interno del metodo stesso al fine di recuperare un attributo e popolare il modello. Nel secondo caso invece, il nome dell’attributo del modello combacia con il nome della variabile nell’URI e viene quindi utilizzato un convertitore di tipo, che trasforma il valore della variabile, rappresentato da una stringa, nel tipo dell’attributo.

Il passo successivo all’invocazione dei metodi @ModelAttribute, che contribuisce in maniera sostanziale a popolare il modello, è il data binding. Il componente WebDataBinder mappa i nomi dei parametri della richiesta, inclusi i parametri di query nell’URI della richiesta e i campi delle form, in campi del modello con lo stesso nome. I campi che combaciano sono popolati applicando dove necessario la conversione automatica dei tipi. Nel caso vi siano errori di conversione, gli errori sono accumulati in un oggetto BindingResult che può essere previsto come argomento aggiuntivo del metodo, e che può essere utilizzato per attuare strategie alternative per la conversione o per il recupero dei dati.

4.3.4.3.9 - @RequestHeader

L’annotazione @RequestHeader permette di legare il parametro di un metodo all’header di una richiesta. All’interno dell’annotazione è indicato il nome dell’header che si vuole legare, che deve essere presente all’interno della richiesta. Anche per questi campi è applicata la conversione di tipo in modo analogo ai casi precedenti e come illustrato nella sezione successiva.

4.3.4.3.10 - Conversione dei tipi

I valori estratti dalla richiesta che consistono sostanzialmente di stringhe, come i parametri della richiesta, le variabili all’interno degli URI, gli header, potrebbero dover essere convertiti nel tipo del parametro indicato dal metodo o dal modello. Nel caso in cui questo tipo non sia una semplice stringa, il framework si occupa automaticamente dell’operazione di conversione. Tutti i tipi primitivi, come int, long, float, e alcuni tipi semplici come Date, sono direttamente supportati. È possibile personalizzare ulteriormente questo processo tramite un WebDataBinder o registrando degli oggetti Formatter. L’inizializzazione di un WebDataBinder può


179

essere effettuata tramite un metodo all’interno del controller annotato con @InitBinder.

4.3.4.4 Risoluzione delle viste Tutti i framework MVC per le applicazioni web forniscono strumenti per

riferire le viste. Spring fornisce un meccanismo automatico di risoluzione delle viste, che permette di visualizzare i modelli in un browser senza legarsi a una specifica tecnologia di presentazione. In questo modo abilita l’utilizzo in modo intercambiabile di molteplici viste, come JSP, Velocity, e XSLT.

Le due interfacce importanti nell’ambito della risoluzione delle viste sono ViewResolver e View. L’interfaccia View permette la costruzione di una richiesta di visualizzazione e la consegna di questa richiesta alla tecnologia di visualizzazione selezionata. La ViewResolver stabilisce la corrispondenza tra le reali view e i nomi nomi logici utilizzati per riferirle.

Come discusso nella sezione 4.3.4.3, tutti i metodi di servizio all’interno di un controller, tranne quelli annotati con @ResponseBody o che restituiscono un oggetto di tipo HttpResponse, devono fornire il nome logico di una view, o esplicitamente, restituendo ad esempio un nome logico, un oggetto ModelAndView, una View, o implicitamente, cioè basandosi sulle convenzioni. Le view in Spring sono riferite tramite un nome logico, costituito da una semplice stringa, la cui risoluzione è effettuata da un ViewResolver. Esistono diverse tipologie di ViewResolver, tra cui le più importanti e utilizzate sono la UrlBasedViewResolver, che effettua la risoluzione diretta dei nomi delle view in URL, e l’InternalResourceViewResolver, che estende la prima supportando anche viste di tipo InternalResourceView, specifiche per le tecnologie Servlet e JSP.

La configurazione delle viste può avvenire in modo analogo a quello di un qualsiasi bean gestito dal container. Nel caso di un UrlBasedViewResolver prevede di specificare nella configurazione due importanti informazioni: un <url-prefix> e un <url-suffix>, due stringhe che rappresentano rispettivamente un prefisso ed un suffisso utilizzati per costruire, insieme al nome logico restituito dal controller, gli URL delle viste da visualizzare all’utente., sotto forma di stringhe, da utilizzare. In questo modo è individuata l’URL della risorsa, ad esempio una pagina JSP, che deve essere elaborata come risposta. L’UrlBasedViewResolver rappresenta solo un esempio della grande varietà di strategie che è possibile utilizzare per la risoluzione delle viste, ma la sua estrema semplicità la rendono una delle più popolari.

Spring MVC fornisce inoltre alcune convenzioni riguardanti i nomi logici delle view che permettono di eseguire azioni particolari, come ad esempio il redirecting e il forwarding. Ciò è possibile utilizzando rispettivamente i prefissi redirect e forward apposti al nome logico della view. Altro modo per forzare una re-direzione è quello di restituire dal controller una vista di tipo RedirectView.

4.3.4.5 Costruzione di URI Spring MVC fornisce un meccanismo di supporto per la costruzione di URI

tramite l’UriComponentsBuilder e gli UriComponents.


180

Gli UriComponents rappresentano porzioni di un URI non ancora completo, come ad esempio le singole informazioni sull’host, sulla porta, sulla servlet, o una combinazione di queste che dà luogo a un URI non completamente formato. L’UriComponentBuilder permette di manipolare gli UriComponent in modo appropriato e costruire URI a partire da stringe contenenti variabili, espresse con la stessa notazione utilizzata nel caso degli URI template, e cioè con il nome della variabile racchiuso tra parentesi graffe ({nome-variabile}). Fornendo una stringa di questo tipo l’UriComponentBuilder restituisce un oggetto di tipo UriComponents su cui è possibile assegnare i valori delle variabili e recuperare l’URI completamente formato. È anche possibile costruire l’URI specificando i singoli componenti quali schema, host e percorso.

Inoltre, all’interno di un container Servlet è possibile ricorrere ad una specializzazione dell’UriComponentBuilder, di nome ServletUriComponentsBuilder che permette di fare riferimento a informazioni presenti nella richiesta, come i parametri o il percorso.

4.3.4.6 Locale e temi Spring MVC supporta l’internazionalizzazione tramite la DispatcherServlet

e il LocaleResolver, che è in grado di riconoscere automaticamente il locale dell’utente. Con il termine locale si fa riferimento all’insieme di parametri che definiscono la lingua, il paese e altre impostazioni scelte dall’utente per la visualizzazione dell’interfaccia in merito all’internazionalizzazione.

Quando è ricevuta una richiesta, la DispatcherServlet cerca un LocaleResolver e attraverso questo determina il locale che deve essere usato per l’interazione. Questo è reso disponibile tramite il metodo RequestContext.getLocale() all’interno dei metodi di servizio. Esistono diverse tipologie di LocaleResolver che agiscono sulla base delle informazioni di sessione, dei cookie, degli header della richiesta, e altri ancora.

I temi rappresentano invece l’insieme di impostazioni e risorse che determinano l’aspetto grafico delle view. Sono solitamente rappresentati nell’ambito delle applicazioni web da fogli di stile e immagini. È possibile definire i temi implementando l’interfaccia ThemeSource. L’implementazione di default fornita è ResourceBundleThemeSource che permette di specificare le risorse coinvolte tramite un file di proprietà. I componenti ThemeResolver si occupano di determinare il particolare tema da utilizzare, e lavorano in modo analogo ai LocaleResolver.

4.3.4.7 Supporto all’upload di file Spring MVC integra il supporto all’upload di file sul server tramite i messaggi

HTTP di tipo multi-part. Spring offre un’implementazione di default che fa uso di CommonsFileUpload, una libreria Apache che offre funzionalità di upload in modo robusto ed efficiente all’interno delle richieste HTTP, in conformità allo standard RFC 1867. Di conseguenza, l’uso di questa funzionalità richiede l’utilizzo della libreria commons-fileupload.jar fornita da Apache.


181

Il supporto all’upload dei file è abilitato inserendo all’interno della configurazione la definizione di un bean di tipo MultipartResolver. Una volta abilitato il supporto, la DispatcherServlet controlla la presenza in ogni richiesta ricevuta di contenuti multi-part. Nel caso questi siano presenti attiva il MultipartResolver dichiarato nel contesto e gli consegna la richiesta. Il resolver incapsula la richiesta HttpServletRequest corrente in una MultipartHttpServletRequest, specifica per supportare i contenuti multi-part e l’upload dei file. Quest’oggetto permette ai metodi di servizio del controller di recuperare informazioni sui contenuti e accedere ai file presenti nella richiesta.

Un controller che gestisce l’upload di file definisce un normale metodo di servizio @RequestMapping. Il parametro di tale metodo deve essere di tipo MultipartHttpServletRequest, o in alternativa MultipartFile, e annotato con @RequestParam.

La configurazione descritta si applica sia nel caso in cui la richiesta multi-part sia generata da un browser, tramite una form di tipo multi-part, sia nel caso in cui sia inviata in maniera programmatica da un client di tipo RESTful. Tuttavia, a differenza dei browser, un client programmatico può inviare contenuti di tipo più specifico insieme al file, ad esempio includendo nella richiesta una sezione in formato JSON o XML. In questo caso la sezione contenente questi dati può essere acceduta con un parametro definito come @RequestParam("[data-partname]") String metadata. In questo modo però i metadati sono forniti come stringa non tipizzata, mentre può essere desiderabile ottenere direttamente un oggetto tipizzato costruito con i dati della richiesta, analogamente a quanto avviene nel caso dei normali messaggi tramite l’utilizzo dell’annotazione @RequestBody e degli HttpMessageConverter. In questo caso è possibile utilizzare, al posto di @RequestParam, l’annotazione @RequestPart, che permette di elaborare il contenuto di una specifica sezione del messaggio multi-part tramite l’HttpMessageConverter specifico per il contenuto del messaggio (MappingJackson2HttpMessageConverter nel caso di JSON, Jaxb2RootElementHttpMessageConverter nel caso di XML), dedotto sulla base degli header Content-Type. L’annotazione può essere utilizzata anche per il MultipartFile, e prevede un valore che indica il nome della specifica sezione del messaggio relativo all’argomento del metodo.

4.3.4.8 Gestione delle eccezioni Spring MVC offre un sistema completo per la gestione delle eccezioni generate

durante l’esecuzione dei metodi di servizio dei controller.

L’interfaccia HandlerExceptionResolver permette di mappare in modo dichiarativo le eccezioni generate in specifiche viste da restituire all’utente. Tuttavia, in alcuni casi, potrebbe essere preferibile impostare direttamente lo status della risposta HTTP e inserire un codice di errore direttamente nel corpo della risposta. Ciò è possibile con i metodi annotati @ExceptionHandler, che sono applicati alle eccezioni generate dai metodi @RequestMapping. Altra modalità di gestione delle eccezioni è l’utilizzo di @ResponseStatus. L’annotazione si applica direttamente alla definizione delle eccezioni e permette di impostare lo status della risposta sulla base del tipo di eccezione generata dai metodi di servizio.


182

4.4 - Conclusioni Le applicazioni enterprise rappresentano applicazioni molto complesse ed

elaborate, che devono affrontare le sfide legate alla natura distribuita dell’elaborazione e all’elevata mole di utenti da servire e di dati da processare, garantendo al tempo stesso requisiti di affidabilità, scalabilità, sicurezza e interoperabilità. Per questo motivo le piattaforme enterprise facilitano lo sviluppo di queste applicazioni fornendo servizi di supporto e ambienti di esecuzione per i componenti applicativi. Piattaforme proprietarie quali il Microsoft .NET Framework o IBM WebSphere presentano notevoli limitazioni alla portabilità delle applicazioni e danno luogo all’indesiderato fenomeno del vendor-lockin. Soluzioni aperte e standardizzate come Java EE presentano notevoli vantaggi sotto questo punto di vista e permettono all’azienda di scegliere tra numerose implementazioni dello stesso standard. Anche Spring rappresenta una soluzione aperta e portabile, essendo basata su piattaforma Java e rilasciata con licenza Apache 2.0, e pur non costituendo uno standard come Java EE può essere portato su un qualsiasi web server o application server dotato di piattaforma Java. Dal punto di vista tecnologico Microsoft .NET Framework rappresenta una soluzione omnicomprensiva indirizzata ad ogni tipo di applicazione in ambito Microsoft, fortemente integrata con gli strumenti di sviluppo, ma che presenta diverse limitazioni rispetto a funzionalità quali DI e AOP. Java EE rappresenta una soluzioni più completa, soprattutto con la versione 3.0 della specifica EJB, che ha apportato notevoli miglioramenti sia riguardo il supporto a tempo di esecuzione e sia in merito allo stile di programmazione che risulta più leggero e meno vincolante. In ogni caso Spring si differenzia comunque come approccio a container leggero, poiché permette grazie all’architettura modulare di combinare a piacimento le funzionalità necessarie, introducendo di conseguenza un minor over-head di elaborazione, e perché non richiede la presenza di un container EJB per il livello di business. Non costituendo una soluzione standard permette inoltre di scegliere all’interno di una vasta gamma di estensioni con funzionalità avanzate, come ad esempio Spring for Android, e numerosi strumenti d’integrazione sia con gli standard Java EE sia con la piattaforma .NET. Queste caratteristiche ci hanno portato a selezionare Spring come piattaforma ideale per lo sviluppo della nostra piattaforma partecipativa.

Abbiamo quindi esplorato le caratteristiche del framework Spring analizzando prima il container per la Dependency Injection, che permette di ottenere elevato disaccoppiamento e riusabilità tra i componenti applicativi, e che può essere configurato in modo estremamente flessibile. Altra funzionalità di Spring è il supporto all’Aspect Oriented Programming che con il framework @AspectJ ha introdotto potenti strumenti per la creazione di aspetti e l’individuazione dinamica dei join point. Per quanto riguarda livello dei dati invece permette la gestione dichiarativa delle transazioni e fornisce supporto all’integrazione con numerosi strumenti di mapping O/R quali Hibernate, JPA e JDO. Anche nel layer di presentazione offre interessanti funzionalità con il framework MVC, che promuove la separazione tra la logica di business, il modello dei dati, e la logica di presentazione. Basato sulle API Java EE Servlet, permette di mappare le richieste provenienti dal client in specifici metodi dei componenti controller, offrendo un supporto molto flessibile all’estrazione delle informazioni dalle richieste e dagli URL, alla costruzione delle risposte, alla


183

conversione automatica dei tipi, alla costruzione implicita del modello e la risoluzione delle viste, all’upload di file e alla gestione degli errori. Anche la definizione di RESTful Web Service è notevolmente semplificata in quanto permette allo sviluppatore di manipolare oggetti piuttosto che interpretare messaggi secondo lo specifico formato di codifica.

La piattaforma Spring dispone quindi di un gran numero di funzionalità che supporteranno in tutti i suoi aspetti, come vedremo nel prossimo capitolo, lo sviluppo della piattaforma partecipativa per dispositivi mobili che rappresenta in fulcro di questa trattazione.

5 - Infrastruttura di supporto a servizi partecipativi

Nel corso del capitolo 1 - , Smart City e servizi partecipativi, abbiamo riconosciuto come elemento fondamentale del concetto Smart City la centralità del cittadino e il carattere partecipativo dell’intero contesto urbano. Non solo tecnologia e innovazione, ma prima di tutto un ambiente vivibile e stimolante per i cittadini, dal punto di vista non solo ambientale ma anche sociale e culturale. Lo sviluppo sostenibile della città intelligente è improntato non solo allo sviluppo economico, ma anche e soprattutto al miglioramento della qualità della vita, obiettivo che si realizza coinvolgendo in maniera diretta e attiva l’intera comunità all’interno delle dinamiche di sviluppo. Il principio dell’open-government incarna tutti questi valori, sostenendo la partecipazione dei cittadini all’interno dei processi decisionali dell’amministrazione pubblica e riconoscendo l’importante ruolo giocato dalle infrastrutture ICT per la valorizzazione dell’intelligenza collettiva della comunità. Nel corso del capitolo abbiamo inoltre esaminato alcuni esempi significativi di servizi partecipativi dispiegati in Smart City di tutta Europa, realizzando come i principi di dell’open government possano concretizzarsi attraverso tipologie di servizio molto differenti. Non troviamo solo la partecipazione diretta ai processi decisionali, come ad esempio in servizi quali ImproveSF che permettono la presentazione e la discussione delle iniziative per il miglioramento del contesto urbano, ma anche servizi più concreti e diretti come FixMyStreet e E-part, che permettono di inviare segnalazioni riguardo situazioni di degrado del territorio, permettendo quindi ai cittadini di contribuire alla costruzione di un ambiente più vivibile. Altri servizi, come Smart Citizen, utilizzano dispositivi dotati di sensori integrati per attuare meccanismi di rilevazione in una dimensione partecipativa, al fine di raccogliere indirettamente informazioni quali l’inquinamento atmosferico e costruire una mappa aggregata del territorio, sulla base della quale dirigere i processi decisionali riguardo la costruzione di aree urbane, lo smistamento


186

del traffico e così via. Tra tutti quelli esaminati, però, un servizio in particolare ha catturato la nostra attenzione: si tratta di WeGo, un piattaforma per promuovere la pratica del car-sharing tra i cittadini che abitano all’interno dello stesso quartiere. Ciò che lo rende particolarmente interessante non è tanto la natura in sé del servizio, quanto l’elemento collaborativo che presenta. Il servizio, infatti, piuttosto che costituire un canale di comunicazione verticale tra i cittadini e l’amministrazione, stimola la collaborazione tra i cittadini stessi della comunità e promuove comportamenti intelligenti da parte degli stessi.

Molti di questi servizi sono accomunati, oltre che dall’elemento partecipativo, da una naturale predisposizione all’essere fruiti tramite dispositivi mobili. La possibilità di poter offrire il proprio contributo in qualunque momento e in qualunque luogo rappresenta un’enorme potenzialità per questa tipologia di servizi. Dislocati sull’intero territorio urbano, i cittadini costituiscono una rete pervasiva di nodi che agiscono da sorgenti e da destinatari di contenuti di ogni genere, dagli status condivisi sui social network, alle immagini caricate, i luoghi di interesse, le rilevazioni effettuate tramite i sensori. Ciò è tanto più vero nell’era dei social network che stimolano le interazioni sociali tra gli individui e la condivisione di contenuti in modo esponenziale.

Sulla base di queste considerazioni si sviluppa il tema centrale di questo capitolo, che rappresenta anche il fulcro dell’intera trattazione. Dagli esempi citati risulta evidente come la partecipazione e la collaborazione dei cittadini nello scenario Smart City debbano essere opportunamente supportati e stimolati da una infrastruttura ICT evoluta che sappia interpretare e combinare i contributi degli individui in modo intelligente per valorizzarli al massimo, un sistema capace di raccogliere i contenuti inviati dai cittadini per elaborarli e redistribuirli verso gli altri utenti o verso le amministrazioni stesse costituendo una piattaforma d’interconnessione e di condivisione della conoscenza. In questo capitolo quindi procederemo prima a evidenziare i requisiti e le caratteristiche esteriori che tale infrastruttura deve presentare, per poi addentrarci nella progettazione e nello sviluppo dell’architettura software che la implementa. Cominciamo innanzitutto con il delineare lo scenario di riferimento.

5.1 - Scenario di riferimento Lo scenario dei servizi partecipativi è molto variegato e risulta difficile coprire

l’intera gamma di potenziali servizi data l’estrema eterogeneità che presentano. Per questo definiamo un insieme di scenari di riferimento che individuano le caratteristiche che intendiamo supportare tramite la nostra piattaforma.

5.1.1 Esempi di servizi Il primo esempio di servizio che esaminiamo rientra nella stessa tipologia di

servizi quali FixMyStreet e DecoroUrbano, cioè un servizio che permette all’utente l’invio di segnalazioni riguardanti situazioni di degrado o disservizi nel territorio urbano, come ad esempio dissesti stradali, cassonetti pieni, e così via. Il servizio è caratterizzato dalla possibilità quindi di inviare contenuti geo-localizzati, quali


187

messaggi testuali e foto, per documentare le segnalazioni, che sono raccolte e memorizzate dal sistema. Il sistema si occupa quindi di raccogliere le segnalazioni, memorizzarle, e renderle disponibili per la consultazione da parte degli utenti e delle amministrazioni competenti. Potrebbe inoltre essere prevista la possibilità di notificare queste segnalazioni direttamente al personale incaricato a servirle, per permettere un intervento tempestivo, o potrebbe essere necessario inviarle ad autorità competenti diverse in funzione del tipo di segnalazione. Ad esempio, una segnalazione riguardante un dissesto stradale dovrebbe essere notificata agli addetti della manutenzione stradale, mentre nel caso dei cassonetti pieni agli addetti alla nettezza urbana.

Un altro scenario molto interessante è quello che riguarda la segnalazione e il soccorso delle situazioni di emergenza. Un anziano colpito da malore o caduto a terra, un disabile che non riesce a oltrepassare una barriera architettonica, un cittadino vittima di un’aggressione, o un incendio, sono tutte situazioni di emergenza che richiedono l’intervento tempestivo sia delle autorità competenti, siano essi vigili del fuoco o pronto soccorso, ma anche dei cittadini stessi, che possono fornire il loro aiuto e la loro solidarietà. Ad esempio, nel caso di un malore lieve o di una caduta potrebbe essere necessario avvertire innanzitutto gli utenti presenti all’interno della località, o selezionare tra particolari tipologie di utenti che svolgono il ruolo di volontari per prestare il primo soccorso. Si tratta di uno scenario notevolmente differente rispetto al caso precedente: mentre prima la segnalazione richiedeva un intervento non necessariamente immediato, ora è d’importanza vitale servire la richiesta di aiuto nel modo più tempestivo possibile. Inoltre particolari situazioni di pericolo potrebbero essere rilevate in maniera automatica ad esempio monitorando gli urti del dispositivo e le invocazioni vocali di aiuto, o elaborando le immagini catturate dal dispositivo per estrarre informazioni sul tipo di emergenza.

Nonostante il graduale processo d’informatizzazione dei servizi amministrativi, vi sono ancora molte tipologie di servizio che, per la loro stessa natura, per scelta degli utenti, o perché richiedono un’interazione diretta con gli uffici e con il personale amministrativo, sono ancora fruiti nella maniera tradizionale, cioè presso gli uffici amministrativi. Per questa tipologia di servizi potrebbe essere interessante fornire la possibilità agli utenti di accedere a informazioni riguardanti lo stato di affollamento degli uffici, e abilitare un’interazione diretta tra i cittadini al fine di scambiarsi informazioni sullo stato degli uffici. Non solo, si potrebbe pensare a meccanismi di rilevazione automatica che raccolgono informazioni dai sensori dei dispositivi mobili (ad esempio il microfono) per dedurne lo stato degli uffici, o che calcolano, sulla base del tempo medio di permanenza degli utenti nell’ufficio, il tempo medio di attesa e di servizio. Una modalità più esplicita potrebbe essere quella di inserire immagini che documentano una coda particolarmente lunga nell’ufficio. Tali contenuti devono essere opportunamente indirizzati verso gli utenti che sono interessati a svolgere determinate attività nell’ufficio, ad esempio perché la loro agenda riporta tali scadenze, oppure perché hanno spesso visitato l’ufficio recentemente.

Altro ambito di riferimento dei servizi partecipativi è quello dell’informazione e dello scambio di eventi culturali e sociali. In questo scenario non è solo l’amministrazione a proporre ai propri cittadini gli eventi organizzati, ma sono anche i cittadini stessi a scambiare informazioni e contenuti tra loro per promuovere eventi di


188

carattere culturale come mostre, cineforum, eventi teatrali e musicali, workshop, rassegne cinematografiche e così via. Anche in questi casi i contenuti possono essere diretti verso diversi gruppi di cittadini, secondo criteri quali località e interessi, o piuttosto verso associazioni culturali. Troviamo un altro esempio di servizio partecipativo nell’ambito del monitoraggio del traffico: monitorando la velocità e la posizione degli utenti alla guida è possibile dedurre informazioni sul traffico e individuare situazioni di congestione. Tali informazioni potrebbero essere poi redistribuite sia agli utenti, sulla base della loro posizione corrente o dell’itinerario previsto, sia alla polizia municipale nel caso sia necessario un intervento di direzione del traffico.

Gli scenari descritti rappresentano solo alcuni esempi dei possibili scenari applicativi di stampo partecipativo, e sono tutti accomunati dal coinvolgimento di molteplici attori in funzione dei contenuti immessi dagli utenti. Alcuni richiedono la notifica tempestiva agli interessati, altri potrebbero prevedere azioni differenti di coinvolgimento del gruppo interessato. Nella sezione successiva individueremo quindi i tratti comuni ai diversi scenari intorno ai quali ideare l’infrastruttura di supporto.

5.1.2 Elementi comuni Prendiamo innanzitutto come riferimento l’ambito dei dispositivi mobili. In tutti

gli scenari descritti nella sezione precedente, gli utenti sono dislocati sul territorio urbano e tramite i loro dispositivi mobili selezionano i contenuti d’interesse da introdurre nel sistema. Tali contenuti possono essere di qualsiasi natura, e spaziano da semplici messaggi testuali a contenuti multimediali quali immagini, video, campioni audio, passando per i dati rilevati da sensori quali accelerometro, giroscopio, e così via. Non solo, facendo riferimento a scenari come quello del sensing partecipativo, la selezione dei contenuti può avvenire anche in modo automatico, nel caso in cui siano previsti meccanismi di monitoraggio dello stato dell’utente e dell’ambiente circostante per individuare situazioni ritenute rilevanti per lo scenario applicativo.

I contenuti selezionati sono quindi immessi all’interno del sistema ed elaborati al fine di attuare un processo partecipativo che coinvolge una molteplicità di attori, rappresentati sia da altri utenti del sistema sia da attori pertinenti al contesto urbano in generale, quali enti pubblici, particolari figure professionali, autorità competenti etc. La piattaforma si occupa di determinare l’insieme di figure coinvolte all’interno del processo in funzione della natura dei contenuti stessi. Una volta determinato il gruppo di attori coinvolto, il sistema si occupa di mettere in atto l’azione specifica dello scenario applicativo, che può andare dalla notifica tempestiva, alla creazione di un gruppo di discussione, o altro.

All’interno del processo di selezione degli attori, i criteri di selezione utilizzati possono essere molteplici e variano chiaramente in funzione dello scenario applicativo. Non solo, anche all’interno di uno stesso scenario, i processi di elaborazione possono essere differenziati in base alla tipologia dei contenuti o a particolari condizioni operative. Nel caso dei sistemi di emergenza, ad esempio, una richiesta riguardante un malore lieve potrebbe dare luogo alla ricerca di utenti nella località mentre una richiesta relativa ad un malore grave potrebbe essere inoltrata direttamente verso il pronto soccorso o il medico di turno.


189

Oltre l’immissione da parte degli utenti, automatica o meno, di contenuti che sono processati dal sistema per mettere in atto i meccanismi partecipativi, i dispositivi mobili permettono di raccogliere informazioni anche sugli utenti passivi del sistema, andando dalla semplice posizione corrente, a meccanismi più avanzati come quelli di activity recognition, già citato nella sezione 2.4 - riguardante il Mobile sensing, con particolare riferimento agli studi di [MIL08], [WAN09] e altri. Raccogliendo quindi i dati sensoriali tramite i dispositivi mobili è possibile dedurre importanti informazioni sullo stato dell’utente, come ad esempio l’attività svolta correntemente, che possono essere utilizzate all’interno del processo partecipativo per selezionare gli utenti secondo particolari criteri. Ad esempio, nello scenario delle segnalazioni delle emergenze, è ragionevole selezionare, nella località dell’emergenza, gli utenti liberi (che non stanno ad esempio guidando un’auto) giacché sono più predisposti a fornire soccorso. In generale, quindi, il mobile sensing permette di rilevare importanti informazioni sull’utente e sull’ambiente circostante. Inoltre, in conformità alla natura mobile dello scenario, la posizione geografica dell’utente rappresenta un’informazione fondamentale per erogare servizi strettamente legati al territorio urbano, offrendo la possibilità di localizzare sia i contenuti generati sia gli utenti del sistema e attuare quindi logiche d’interazione e collaborazione sulla base della prossimità.

Un altro elemento importante nello scenario dei servizi partecipativi è rappresentato dalla componente sociale. È evidente, ancora di più nell’era dei social network, come gli schemi di interazione e di collaborazione tra utenti si sviluppino sulla base della rete sociale che lega gli individui all’interno della comunità. Considerando ad esempio i servizi di informazione e di condivisione di eventi, è ragionevole pensare che determinati contenuti possano essere condivisi all’interno di una rete di utenti conoscenti e interessati. Anche facendo riferimento al servizio di emergenza, determinate richieste di aiuto potrebbero essere distribuite all’interno della rete sociale dell’utente, selezionando ad esempio i familiari dell’utente o i conoscenti che si trovano nella stessa località. Anche nei sistemi di segnalazione dei disservizi, si potrebbe pensare di coinvolgere in una segnalazione un insieme di utenti collegati da relazioni sociali, ad esempio residenti nello stesso quartiere, per promuovere la discussione delle criticità e sollecitare l’intervento dell’amministrazione su una problematica comune. La socialità rappresenta quindi un elemento importantissimo per i servizi partecipativi in generale.

Come abbiamo detto, lo scenario urbano è caratterizzato dalla presenza allo stesso tempo degli utenti visti come normali individui e cittadini, ma anche dalla presenza di enti pubblici e autorità governative, corpi statali come vigili del fuoco o polizia, ma anche organizzazioni socio-culturali, enti assistenziali e così via. In generale, quindi, troviamo insieme ai cittadini privati un insieme d’istituzioni con cui i cittadini, attraverso i servizi partecipativi, interagiscono. Non solo, la sfera individuale e istituzionale spesso s’incontrano dando luogo ad un terzo elemento non meno importante: quello dei profili professionali degli utenti. Gli stessi utenti del sistema, infatti, spesso sono anche membri di particolari organizzazioni o rivestono ruoli professionali rilevanti. Prendendo nuovamente ad esempio il caso del servizio di segnalazione delle emergenze è ragionevole pensare che vi siano utenti che svolgono il ruolo di volontari per un’organizzazione d’assistenza, oppure di medico di base.


190

Questo tipo d’informazioni rappresenta una risorsa importante nella dimensione collaborativa dei cittadini giacché permette di selezionare utenti in funzione della loro specializzazione professionale. Non solo, è importante caratterizzare gli utenti anche in conformità a altre informazioni di profilazione, quali ad esempio l’indicazione dei familiari o dei vicini di casa, come avviene nel già citato servizio WeGo

Riassumendo, quindi, possiamo evidenziare cinque elementi fondamentali nello scenario dei servizi partecipativi per dispositivi mobili, rappresentati in Figura 52: la socialità, come incentivo alla collaborazione dei cittadini attraverso la rete di relazioni che si costruiscono all’interno dello scenario urbano; la presenza sul territorio delle istituzioni, sia governative sia non, come corpi statali, organizzazioni culturali, o associazioni di volontariato, che prendono parte attivamente al processo partecipativo; la caratterizzazione degli utenti secondo particolari informazioni, come il ruolo professionale, che derivano direttamente dall’appartenenza degli utenti all’interno della comunità; infine, dallo scenario dei dispositivi mobili derivano la geo-localizzazione dei contenuti e degli utenti stessi e, in generale, la possibilità di usufruire delle informazioni rilevate tramite i sensori dei dispositivi, in modo volontario o meno per gli utenti. Inoltre, seppur particolarmente caratterizzanti nel contesto dei servizi partecipativi per dispositivi mobili, gli elementi enunciati non esauriscono le necessità che potrebbero presentarsi in alcuni dei molteplici scenari applicativi del genere. Allo stesso tempo, è possibile che in altri casi alcuni di essi siano superflui.

Figura 52 - Socialità, istituzioni, profili, geo-localizzazione e mobile sensing sono alcuni degli elementi fondamentali che

caratterizzano lo scenario dei servizi partecipativi per dispositivi mobili.

Il nostro obiettivo è quindi quello di costruire una piattaforma che permetta di combinare questi elementi per la realizzazione di servizi partecipativi. Tale piattaforma deve mantenere un elevato livello di estendibilità e flessibilità, gli stessi elementi devono poter essere combinati e utilizzati in modo differente all’interno di scenari applicativi diversi. Procediamo quindi a descrivere più in dettaglio le caratteristiche della piattaforma.


191

5.1.3 La piattaforma In accordo a quanto detto finora, lo scenario dei servizi partecipativi cui

facciamo riferimento è caratterizzato dall’immissione di contenuti da parte degli utenti, che sono poi processati dal sistema al fine di determinare l’insieme di attori coinvolti nel processo partecipativo. Sulla base dell’insieme coinvolto poi sono messe in atto azioni specifiche dello scenario applicativo di riferimento.

L’elaborazione dei contenuti e la selezione dell’insieme di attori coinvolti da parte della piattaforma ha luogo in conformità a una serie di criteri riconducibili in gran parte agli elementi descritti nella sezione precedente. Elementi quali socialità, geo-localizzazione, informazioni di stato rilevate dagli utenti, profilo degli utenti stessi, rappresentano alcune delle informazioni alla base del processo partecipativo che permettono di determinare quali attori devono essere coivolti. Prendiamo ad esempio il caso dei servizi d’informazione sugli eventi. L’insieme di destinatari cui distribuire un determinato contenuto potrebbe essere determinato in funzione delle informazioni di profilazione quali gli interessi culturali degli utenti, ma in alcuni casi potrebbe essere ristretto in funzione delle relazioni sociali se si tratta di un evento personale, o in base alla posizione geografica se lo scopo è quello di coinvolgere i cittadini residenti in una precisa area geografica. Vediamo quindi non solo come l’insieme di criteri sia differente a seconda dello scenario applicativo in cui ci muoviamo, ma vari anche nell’ambito dello stesso scenario in funzione del tipo di contenuti che sono immessi dall’utente. Non solo, vi potrebbero essere situazioni in cui i criteri applicati dipendono dal contesto operativo e dalle condizioni che si verificano durante l’elaborazione. Facendo riferimento allo scenario delle richieste di soccorso, è ragionevole pensare che, nel caso in cui non siano presenti potenziali soccorritori nella località in cui è stata generata la richiesta, siano applicati altri criteri come ad esempio l’invio della richiesta direttamente al medico di turno. Dalle considerazioni effettuate emerge quindi come il comportamento applicato sia estremamente dinamico anche all’interno dello stesso scenario. Per questo motivo è necessario elaborare un meccanismo altrettanto flessibile e dinamico che permetta di modellare le situazioni citate. Dovrà inoltre permettere l’applicazione di una molteplicità di criteri per la selezione degli utenti, ed essere capace di elaborare in modo adeguato contenuti di natura eterogenea.

Lo schema generale del sistema è rappresentato in Figura 53. La rilevazione dei contenuti è supportata da un insieme di meccanismi operanti direttamente sui dispositivi mobili che permettono sia la generazione di contenuti sia la rilevazione delle informazioni di sensing al fine di fornire al sistema le informazioni di stato sugli utenti. Tali informazioni sono raccolte da un’infrastruttura di supporto che si occupa di elaborare i contenuti e selezionare gli attori coinvolti nel processo partecipativo applicando una precisa sequenza di criteri di selezione, sulla base della tipologia di contenuti e delle condizioni operative del sistema. I criteri più comuni utilizzano informazioni quali la posizione geografica degli utenti, le informazioni di profilazione, l’attività corrente, le relazioni sociali, ma possono esservi in generale criteri definiti per lo specifico scenario applicativo. Tali criteri sono utilizzati per selezionare l’insieme di attori, che conterrà sia gruppi di utenti del sistema sia enti istituzionali, sul quale il sistema si occuperà di mettere in atto le azioni previste dallo specifico scenario


192

applicativo, che potranno prevedere la distribuzione dei contenuti agli utenti o alle istituzioni selezionate, la pubblicazione su di una bacheca, o altre azioni specifiche dello scenario.

Figura 53 - La piattaforma riceve contenuti e dati dagli utenti e si occupa di selezioare gli attori coinvolti nel processo

partecipativo secondo diversi criteri.

Il sistema complessivo è quindi costituito sia da un insieme di meccanismi predisposti sui dispositivi mobili degli utenti, deputati all’immissione dei contenuti nel sistema e della rilevazione delle informazioni di sensing, e sia da una piattaforma di elaborazione che riceve i contenuti e li elabora applicando una sequenza di criteri. Precisiamo quindi che il nostro intento non è quello di sviluppare il sistema completo che gestisce uno specifico scenario applicativo, ma piuttosto fornire un’infrastruttura di supporto che supporti i servizi partecipativi, occupandosi della raccolta dei contenuti e della loro elaborazione, come illustreremo nella sezione successiva.

5.1.4 Obiettivi Il nostro obiettivo in merito a questa trattazione non consiste nella realizzazione

di un sistema auto-contenuto e completo, come potrebbe apparire dallo schema presentato nella sezione precedente, ma piuttosto nello sviluppo dell’infrastruttura di supporto alla realizzazione dei servizi partecipativi per dispositivi mobili. È necessario quindi definire con precisione il confine tra l’infrastruttura di supporto e i servizi che si sviluppano su di essa.

In base alle considerazioni della sezione precedente emerge innanzitutto la presenza sui dispositivi mobili degli utenti di una serie di meccanismi volti alla raccolta e all’immissione nel sistema d’informazioni di sensing e dei contenuti selezionati dagli stessi. Tuttavia la specifica di quali particolari contenuti dovranno essere immessi rappresenta una caratteristica specifica del particolare scenario applicativo, e risulta difficile fornire un supporto abbastanza generico per queste funzionalità. È possibile tuttavia fornire supporto per le funzionalità legate alla sfera


193

del mobile sensing, cioè alla rilevazione dei dati sensoriali, applicando ove possibile ottimizzazioni per il risparmio energetico e per l’utilizzo efficiente delle risorse computazionali. Uno dei nostri obiettivi sarà quindi quello di definire un insieme di moduli responsabili del monitoraggio dei sensori, selezionati in base alle tipologie più rilevanti, che potranno essere utilizzati sia per fornire alla piattaforma di elaborazione informazioni di stato e di contesto sugli utenti, utilizzate per la geolocalizzazione e per il processo di activity recognition, sia per mettere in atto meccanismi di generazione automatica dei contenuti, cioè la rilevazione di particolari situazioni tramite i sensori che danno luogo all’immissione di contenuti nella piattaforma. Quest’ultima funzionalità è tuttavia strettamente legata ai particolari contenuti e specifica quindi dello scenario applicativo, e il supporto deve quindi limitarsi a fornire opportune interfacce al livello applicativo che gli permettano di configurare i meccanismi di rilevazione sottostanti per supportare questo tipo di scenario. Oltre al monitoraggio delle rilevazioni, il supporto potrà occuparsi dell’intero processo di activity recognition al fine di fornire le informazioni di stato sugli utenti. Naturalmente, questa funzionalità non è necessaria in tutti gli scenari applicativi, e sarà di conseguenza attiva solo nei casi in cui è esplicitamente richiesta. In altri scenari si potrà ricorrere all’utilizzo di dati sensoriali in modo diverso, ad esempio al fine di fornire informazioni sull’ambiente circostante. Il supporto dovrà quindi essere sufficientemente flessibile per coprire tutti questi casi.

L’altro elemento importante, che l’infrastruttura deve supportare, è rappresentato dal processo di selezione degli attori. Se da una parte questo meccanismo coinvolge alcuni criteri di selezione ragionevolmente generali e ricorrenti, quali ad esempio la socialità, la geo-localizzazione e la profilazione, dall’altra alcuni scenari potrebbero richiedere particolari criteri che risultano difficili da prevedere in anticipo. L’infrastruttura deve quindi offrire la possibilità di definire nuovi criteri. In funzione dello scenario applicativo sarà inoltre necessario combinare in modo opportuno l’applicazione dei criteri, secondo schemi che non è possibile definire a priori. Il supporto deve quindi fornire gli strumenti per combinare in modo opportuno i criteri di selezione. Non solo, come abbiamo accennato nelle sezioni precedenti spesso l’applicazione di determinati criteri è funzione delle condizioni operative e quindi nota solo durante l’esecuzione. Questo rende necessario la presenza di meccanismi dinamici oltre che flessibili per l’applicazione dei criteri.

La Figura 54 riassume le considerazioni effettuate evidenziando la separazione tra le funzionalità di supporto e quelle inerenti lo specifico scenario applicativo. In particolare è possibile individuare due macro-gruppi di funzionalità: quelle legate al mobile sensing e quelle legate al processo partecipativo in senso stretto. Il primo prevede al livello di supporto i meccanismi di monitoraggio, elaborazione e invio dei dati dei sensori, in cui rientra anche l’activity recognition. Su queste funzionalità di supporto è possibile a livello applicativo generare i contenuti, anche con meccanismi automatici. L’insieme di funzionalità legate al processo partecipativo fornisce gli strumenti per creare e combinare tra loro i criteri di selezione degli utenti e prevede inoltre la presenza di criteri built-in, alcuni dei quali fanno uso delle funzionalità legate al mobile sensing (es. il criterio di geo-localizzazione). Attraverso queste funzionalità il livello applicativo definisce quindi i processi di elaborazione dei contenuti nello scenario partecipativo. Precisiamo che tale schema ha il solo scopo di


194

illustrare la separazione tra le funzionalità di supporto e quelle applicative e non è in alcun modo indicativa della struttura software della soluzione.

Figura 54 - Le funzionalità del sistema complessivo sono suddivise in quelle fornite dal livello di supporto e in quelle

applicative specifiche dello scenario.

Sulla base dei requisiti e delle necessità emerse dalle sezioni precedenti, abbiamo sviluppato l’infrastruttura di supporto che le soddisfa. Il processo di sviluppo è stato organizzato secondo le fasi di analisi dei requisiti, analisi del problema, progettazione, sviluppo e testing, e in virtù dei principi di qualità propri dell’ingegneria del software quali robustezza, affidabilità, modularità e riusabilità. Poiché la descrizione del processo di sviluppo in ogni suo aspetto non compete questa trattazione, ci dedicheremo piuttosto alla descrizione della struttura complessiva dell’infrastruttura risultante, e delle politiche e dei meccanismi che la caratterizzano.

5.2 - Il sistema complessivo In questa sezione descriveremo il sistema realizzato nel suo complesso prima di

scendere nel dettaglio delle singole sue parti. Partiamo innanzitutto con la descrizione generale delle funzionalità che il sistema offre.

5.2.1 Funzionalità generali La funzionalità principale del sistema consiste nel supporto a quello che

chiameremo processo partecipativo. Con questo termine facciamo riferimento al processo che ha luogo all’interno del sistema e che elabora i contenuti immessi dagli utenti per determinare, attraverso l’applicazione di criteri di selezione degli utenti, l’insieme di attori coinvolti nell’attività partecipativa. L’attività partecipativa rappresenta l’azione, specifica dello scenario applicativo, che ha luogo nell’ambito del processo e che coinvolge un preciso insieme di attori. Può essere rappresentato dall’invio diretto dei contenuti agli attori, dalla pubblicazione dei contenuti su una bacheca virtuale, o altro. Il processo partecipativo prevede quindi, a partire dal contenuto immesso dall’utente, la selezione di un insieme di entità, che chiameremo


195

attori, che possono prendere parte all’attività partecipativa. Gli attori rappresentano sia gli utenti stessi del sistema, ma anche le istituzioni o qualsiasi tipo di entità di questo genere. In questo scenario il sistema supporta la definizione da parte dell’applicazione di processi partecipativi altamente configurabili, con la possibilità di introdurre elementi di dinamicità che consentono di discriminare durante l’esecuzione, in funzione delle condizioni operative e del tipo di contenuti elaborati, il particolare processo partecipativo da applicare. Il sistema applica il processo partecipativo in modo trasparente all’applicazione permettendo a questa di concentrarsi sulla specifica dell’attività partecipativa in sé.

Il processo partecipativo prevede l’utilizzo di un insieme di criteri, parametri cioè che permettono di individuare e discriminare un insieme di attori. I criteri rappresentano quindi le regole tramite cui sono selezionati gli attori coinvolti nell’attività partecipativa. Il processo partecipativo è concepito come una catena dinamica di criteri. In questo senso il sistema fornisce all’applicazione gli strumenti per definire e configurare la catena di criteri da applicare. Inoltre fornisce all’applicazione sia un insieme di criteri preesistenti, sia gli strumenti per la definizione di criteri specifici dello scenario applicativo, promuovendo quindi modularità e riusabilità dei criteri. L’infrastruttura fornisce i seguenti criteri built-in: il criterio basato su socialità, che seleziona gli utenti in relazione sociale con il creatore dei contenuti; quello di geo-localizzazione, che mette in relazione un contenuto con gli utenti che si trovano all’interno di una precisa area geografica, che non deve necessariamente coincidere con quella in cui è stato generato il contenuto; il criterio di profilazione degli utenti, che permette di selezionare utenti in base a particolari informazioni di profilazione quali la professione dell’utente o il ruolo sociale. In generale i criteri possono portare all’ampliamento alla riduzione dell’insieme di attori coinvolto, aggiungendone di nuovi o filtrando quelli già presenti.

L’altra funzionalità fondamentale del sistema è rappresentata dalle funzionalità di monitoraggio dei sensori dei dispositivi mobili al fine di recuperare informazioni sull’utente e sull’ambiente circostante. I meccanismi realizzati abilitano operazioni di rilevazione sia di tipo continuativo che sporadico, attuando inoltre politiche di gestione delle rilevazioni volte a promuovere un utilizzo efficiente ed efficace di risorse energetiche e computazionali. I meccanismi di rilevazione sono realizzate con un approccio modulare, flessibile e configurabile dall’applicazione, in merito alle tipologie di sensori da monitorare e al processo di elaborazione da applicare ai dati, al fine di promuovere il riutilizzo dei meccanismi all’interno dei diversi scenari applicativi e permettere alle applicazioni di combinare i diversi componenti sulla base delle necessità. I meccanismi di rilevazione sono utilizzati per supportare due distinte funzionalità: il monitoraggio dello stato dell’utente e la generazione dei contenuti. Chiariamo quindi la distinzione tra i due. I contenuti sono rappresentati nel sistema da un qualsiasi tipo di dato generato volontariamente o involontariamente dall’utente, come possono essere semplici messaggi testuali o dati multimediali, che sono oggetto del processo di selezione degli attori coinvolti nell’attività partecipativa. Si tratta quindi di elementi molto eterogenei, che dipendono fortemente dallo specifico scenario applicativo. Sono esclusi da questa classificazione i dati sensoriali destinati al monitoraggio dello stato dell’utente, che sono invece utilizzate per fornire informazioni sullo stato dell’utente, quali l’attività correntemente svolta, e


196

costituiscono quindi un’informazione utilizzata piuttosto dai criteri di selezione degli utenti. Mentre i contenuti sono l’oggetto del processo partecipativo stesso, le informazioni di stato rappresentano un’informazione utilizzata da alcuni dei criteri utilizzati nel processo stesso.

Detto questo, la rilevazione dei dati sensoriali destinati alla classificazione dello stato dell’utente avviene in modo trasparente all’applicazione e automatico attraverso il monitoraggio continuativo dei sensori. I dati rilevati sono sottoposti a un processo di elaborazione volto ad estrarre informazioni significative sullo stato dell’utente, come ad esempio il processo di activity recognition. Gli stessi meccanismi di monitoraggio possono essere sfruttati dall’applicazione anche per la generazione dei contenuti. A questo scopo non solo i componenti di rilevazione possono essere invocati dall’applicazione, ma il supporto sottostante si occupa di gestire le richieste di rilevazione in accordo alle operazioni di monitoraggio dello stato, permettendo di condividere le stesse operazioni di rilevazione. Per fare un esempio, se il processo di activity recognition prevede la registrazione di campioni audio, e l’applicazione richiede l’utilizzo del microfono, il sistema si occupa di gestire la condivisione delle stesse operazioni di registrazione per entrambi i processi di elaborazione. In questo modo evita quindi la duplicazione dello sforzo di rilevazione, permettendo un migliore utilizzo delle risorse. Per la generazione dei contenuti sono previste due differenti modalità: quella manuale e quella automatica. La modalità manuale si utilizza nel caso in cui l’applicazione debba permettere all’utente di effettuare singole rilevazioni il cui risultato è utilizzato per creare un nuovo contenuto. È il caso ad esempio dell’applicazione che permette all’utente di scattare una foto per inviare una segnalazione. L’applicazione può quindi utilizzare i componenti di supporto per effettuare la rilevazione, sia essa una registrazione audio, la cattura di un’immagine, o altro. Come abbiamo detto se lo stesso tipo di rilevazioni è effettuato anche da altri task, come ad esempio il processo di activity recognition, le rilevazioni risultanti sono condivise da entrambi. La modalità automatica permette invece all’applicazione di configurare meccanismi di generazione che non coinvolgono l’intervento dell’utente. Può trattarsi quindi di operazioni di tipo periodico oppure generate in corrispondenza di particolari condizioni rilevate attraverso i sensori. Anche in questo caso sono sfruttate le stesse operazioni di monitoraggio dello stato dell’utente attuate dal supporto.

In questo modo il sistema garantisce un elevato grado di flessibilità e modularità, e permette alle applicazioni sviluppate sull’infrastruttura di supporto di selezionare e utilizzare solo i componenti e le funzionalità ritenute necessarie, provvedendo al tempo stesso a fornire un insieme di servizi di supporto che facilitano lo sviluppo delle applicazioni partecipative per dispositivi mobili. Procediamo ad analizzare l’architettura generale del sistema.

5.2.2 Architettura L’architettura generale del sistema è organizzata secondo un modello di tipo

Client-Server. Date le peculiarità dello scenario dei dispositivi mobili, quali l’elevata dinamicità, l’instabilità delle connessioni, le limitate risorse a disposizione, risulta difficile concepire una architettura puramente decentralizzata, basata ad esempio sul


197

modello peer-to-peer, sia per l’elevata mole di informazioni e la capacità di calcolo necessaria sia perché il processo di elaborazione deve mettere in relazione informazioni afferenti a utenti diversi e non necessariamente legati ad una specifica località. Pensare di realizzare questo processo tramite lo scambio diretto di informazioni tra client attraverso la rete comporterebbe un overhead di comunicazione considerevole. La presenza di un’infrastruttura di back-end che riveste il ruolo di entità centrale e agisce da punto di riferimento per i dispositivi client permette invece di fare affidamento su un’elevata capacità di calcolo e di archiviazione, nonché di coordinare e mettere in relazione i client e i dati da essi prodotti. Tramite tecniche di replicazione permette inoltre di ottenere elevata scalabilità e tolleranza ai guasti. Non a caso, rappresenta l’architettura di riferimento nello scenario delle applicazioni enterprise.

La struttura del sistema è rappresentata in Figura 55. I client sono costituiti dai dispositivi mobili e sono basati su piattaforma Android. La scelta di tale piattaforma è motivata, oltre che dalle considerazioni effettuate nel capitolo 3 - Piattaforme per dispositivi mobili, da alcune caratteristiche presentate dalla piattaforma che ben si sposano con i requisiti applicativi e che saranno approfondite più avanti nella sezione 5.3 -. Sul client troviamo innanzitutto i moduli di rilevazione dei dati dai sensori e di estrazione dei dati di contesto, funzionalità che si appoggiano direttamente sul supporto offerto dalla piattaforma Android per l’accesso ai sensori hardware e alle informazioni di contesto, e che sono rappresentate dal livello detto “Sensing & Context data”. Su di questi troviamo un ulteriore livello, detto “Data processing & Uploading”, che si occupa dell’elaborazione dei dati rilevati per l’estrazione proprietà rilevanti, dette feature, e dell’invio delle informazioni verso il server. Come descritto nella sezione precedente, questi meccanismi supportano la rilevazione dei dati destinati sia a essere processati come contenuti e sia a fornire le informazioni di stato sull’utente utilizzate dai criteri. Possono quindi essere utilizzate dal livello applicativo sovrastante, detto Content Generation, per la generazione dei contenuti.

Il server si occupa della raccolta e dell’elaborazione delle rilevazioni inviate dai client e dell’attuazione del processo partecipativo sui contenuti. È basato su framework Spring, una scelta dettata, come vedremo nella sezione 5.4 -, sia dai requisiti di portabilità e di interoperabilità che abbiamo descritto in , sia da alcune particolari funzionalità offerte dal framework. Il modulo User Data memorizza le rilevazioni provenienti dagli utenti, quali le posizioni, le rilevazioni dei sensori ed i dati di contesto, e le elabora per fornire informazioni di stato utilizzabili dai criteri. Un importante processo di elaborazione attuato dal modulo User Data è di activity recognition, che rende disponibile ai criteri del processo partecipativo l’informazione dell’attività correntemente svolta dall’utente. Il livello di Criteria Management supporta il processo partecipativo di elaborazione dei contenuti, permettendo la definizione del processo come catene di criteri e gestendo catene differenziate secondo il tipo di contenuti. Permette inoltre la definizione dei criteri arbitrari. Il modulo Built-in Criteria contiene l’insieme di criteri prestabiliti, che si appoggiano sul modulo di gestione dei criteri e utilizzano inoltre le informazioni raccolte dagli utenti. Attraverso il modulo Criteria Management e i criteri built-in l’applicazione può quindi realizzare il livello di Content Processing che si occupa di elaborare i contenuti immessi dagli utenti.


198

Figura 55 - Architettura generale del sistema.

L’interazione tra client e server è basata sullo stile architetturale REST. Come abbiamo detto nella sezione 2.3 - parlando di Mobile messaging, lo scenario dei dispositivi mobili richiede un elevato disaccoppiamento tra client e server, che spinge quindi ad adottare un modello di interazione basato sullo scambio di messaggi. La scelta di questo protocollo è motivata dalla sua semplicità e leggerezza, giacché fa uso del protocollo HTTP, e dal supporto alla veicolazione di strutture dati complesse secondo il paradigma Object-oriented, attraverso il formato JSON. Per questi motivi REST rappresenta una soluzione di comunicazione client-server largamente diffusa e condivisa all’interno dello scenario mobile. La comunicazione gestita dal supporto ha principalmente lo scopo di permettere il trasferimento delle informazioni rilevate dal client verso il server, al fine di renderle disponibili ai criteri utilizzati nel processo partecipativo. La comunicazione dei contenuti, come per la creazione, è demandata a livello applicativo, trattandosi di informazioni la cui struttura dipende fortemente dal particolare scenario di riferimento.

Nelle sezioni successive procederemo ad illustrare singolarmente il client ed il server, scendendo nei dettagli dei meccanismi implementati.

5.3 - Client Sul client troviamo l’insieme di meccanismi responsabili della rilevazione,

elaborazione e trasferimento sul server delle informazioni sensoriali e di contesto. Il modello secondo cui sono organizzati è orientato ai principi di modularità e riusabilità, per permettere all’applicazione di combinare tra loro i componenti e costruire il processo di rilevazione richiesto dallo specifico scenario. Permette inoltre l’utilizzo delle stesse funzionalità sia per il processo di monitoraggio dello stato dell’utente sia per il processo di generazione dei contenuti da parte dell’applicazione, supportando sia la possibilità di effettuare singole rilevazione sia di monitorare periodicamente ed in modo continuativo i sensori.

Altro elemento da tenere in considerazione è rappresentato dall’efficienza energetica e computazionale: quello dei dispositivi mobili rappresenta uno scenario caratterizzato da vincoli molto ristretti su questo tipo di risorse, e le operazioni di


199

rilevazione dei dati dai sensori e il loro trasferimento verso il server incidono in modo determinante su di esse. Sensori quali microfono, i sistemi di posizionamento quali GPS, e i sistemi di comunicazione wireless hanno un forte impatto sui consumi energetici dei dispositivi, a cui si aggiunge il fatto che in scenari di sensing continuativo questi meccanismi sono costantemente attivi sul dispositivo. Per garantire una sufficiente autonomia ai dispositivi è quindi necessario attuare politiche di ottimizzazione. Allo stesso tempo il processo di elaborazione cui sono sottoposti i dati comporta un costo computazionale non trascurabile, che deve essere compatibile con il normale utilizzo del dispositivo da parte dell’utente. Il monitoraggio continuativo del dispositivo rappresenta una funzionalità attiva in background sul dispositivo e da cui l’utente non trae alcun beneficio diretto. Per questo motivo un impatto troppo invasivo sulle prestazioni del sistema potrebbe portare l’utente a terminare queste funzionalità.

Riteniamo quindi che due requisiti indispensabili che il client debba soddisfare siano da una parte l’efficienza energetica e computazionale, dall’altra l’elevata modularità dell’architettura e la flessibilità dei meccanismi forniti. Analizziamo innanzitutto le caratteristiche del processo di sensing.

5.3.1 Sensing In letteratura, l’approccio comune e ampiamente riconosciuto per la

realizzazione delle funzionalità di sensing continuativo è quello dei cosiddetti cicli di sensing, o cicli di rilevazione. Consiste nella strutturazione delle singole rilevazioni come sequenze di campioni contigui nel tempo di lunghezza prefissata e dipendente dallo scenario applicativo, che sono poi rilevati dai sensori con cadenza periodica. A seconda del periodo scelto per il ciclo di sensing, le singole rilevazioni saranno svolte con particolare frequenza. Ad esempio, nel caso dell’accelerometro, una singola rilevazione potrebbe essere rappresentata da un vettore di 512 elementi ognuno rappresentate una lettura del sensore. In funzione della frequenza di campionamento supportata dal sensore la singola rilevazione corrisponderà ad un intervallo di lettura del sensore più o meno lungo. Il periodo del ciclo determina invece ogni quanto deve essere effettuata una singola rilevazione. Il caso limite è rappresentato dall’uguaglianza tra il periodo del ciclo e la lunghezza di una singola rilevazione, che corrisponde ad un monitoraggio ininterrotto del sensore. La mostra un esempio di singola rilevazione nel caso di una frequenza di campionamento di 500 Hz e rilevazioni di lunghezza di 500 campioni, le singole rilevazioni corrispondono a una durata di 1 secondo, e di cicli di sensing con periodo di 3 secondi.


200

Figura 56 - Singole rilevazioni e cicli di sensing.

La scelta della durata delle singole rilevazioni e del periodo dei cicli di sensing rappresenta un elemento che dipende dallo scenario applicativo ma che è al tempo stesso molto determinante sulle prestazioni del sistema. Naturalmente a rilevazioni più lunghe e cicli di sensing ravvicinati corrispondono ad una maggiore disponibilità di dati, ma nello stesso tempo comportano un maggiore impegno di risorse nelle operazioni di rilevazione.

I dati grezzi rilevati dai sensori hanno una dimensione in Byte molto variabile secondo la tipologia di sensore, e che può diventare considerevole nei casi di sensori quali il microfono, dove un campione audio di durata anche breve e non compresso può arrivare a occupare anche quasi un MegaByte (in un formato monofonico con frequenza di campionamento 11,025 Hz e codifica 16 bit PCM, un campione da 1 minuto occupa 1292 KB). Trasmettere questi dati direttamente sulla rete può portare a una notevole occupazione di banda, ed è quindi ragionevole effettuare una fase di pre-elaborazione di tali dati al fine di estrarre un insieme prestabilito di caratteristiche riassuntive. In molti lavori indirizzati all’ambito del mobile sensing, come [MIL08] e [WAN09], s’individua un processo di elaborazione ricorrente, e che può essere quindi applicato con sufficiente generalità, che mira all’estrazione dei dati grezzi di specifiche proprietà di interesse, dette feature. Per sensori come accelerometro, giroscopio, termometro etc., queste sono rappresentate da grandezze statistiche quali media, varianza e numero di picchi, relativamente una sequenza di N campioni, con N sufficientemente grande (nell’ordine di diverse centinaia di campioni). Per il microfono si utilizza invece una fase preliminare per il calcolo, attraverso algoritmi ottimizzati, della trasformata discreta di Fourier (Discrete Fourier Tansform, DFT), per poi procedere all’estrazione delle stesse grandezze del caso precedente relativamente allo spettro frequenziale del segnale.

Sulla base di queste considerazioni possiamo quindi procedere con la presentazione dell’architettura del client.

5.3.2 Architettura L’architettura del client, riportata in Figura 57, è basata su diverse tipologie di

componenti. I SensorClient e i ContextClient si occupano rispettivamente della rilevazione dei dati sensoriali e di contesto, appoggiandosi direttamente sulle API della piattaforma sottostante per l’accesso ai sensori e alle sorgenti dei dati di contesto. Si tratta di componenti differenziati secondo la tipologia di sensori e di dati di contesto di


201

cui si occupano: abbiamo quindi il LocationClient per i sistemi di posizionamento, l’AccelerometerClient per l’accelerometro, il MicrophoneClient per il microfono, il CalendarClient per gli eventi presenti nell’agenda dell’utente, il BluetoothClient per la rilevazione degli utenti nella prossimità, e così via. Questi componenti si occupano di effettuare una singola rilevazione dei dati sensoriali o di contesto, rappresentati rispettivamente da oggetti di tipo SensorData e ContextData, e possono quindi essere utilizzati dall’applicazione per la generazione di contenuti che richiedono questa funzionalità.

I componenti di tipo SensorClient e ContextClient sono coordinati rispettivamente dai componenti di tipo SensingController e ContextController. Questi componenti si occupando di gestire i cicli di sensing, coordinando l’attivazione dei rispettivi Client secondo il periodo previsto dal ciclo di rilevazione. Permettono quindi la realizzazione delle funzionalità di sensing di tipo continuativo, schedulando l’esecuzione delle singole rilevazioni. Questi componenti implementano inoltre politiche di ottimizzazione energetica e computazionale gestendo i cicli di sensing in modo dinamico secondo le risorse disponibili nel sistema.

Un insieme di componenti di tipo FeatureExtractor realizzano invece le operazioni di estrazione delle feature a partire dai dati grezzi rilevati dai componenti SensorClient, applicando funzioni per il calcolo delle statistiche richieste. Le feature prodotte sono rappresentate da oggetti di tipo SensorFeature. Anche in questo caso i componenti FeatureExtractor e gli oggetti SensorFeature si differenziano secondo la particolare tipologia del sensore cui fanno riferimento. A differenza del caso precedete però, l’attivazione dei componenti avviene non appena i dati sono disponibili. Un componente detto UpdloadController si occupa di gestire il trasferimento delle feature e dei dati di contesto. In modo analogo ai componenti SensingController e ContextController, i trasferimenti sono schedulati secondo cicli periodici la cui durata è stabilita dinamicamente in base alle condizioni di carico computazionale e di disponibilità energetica del dispositivo. Le operazioni sono svolte secondo la normale frequenza se vi è sufficiente disponibilità di risorse, mentre sono ritardate nel caso in cui sia rilevata una carenza. Infine, lo scambio di informazioni di tipo SensorData, ContextData e SensorFeature tra i componenti avviene attraverso repository locale e condiviso detto LocalRepository.

Figura 57 - Architettura del client.


202

Come abbiamo accennato precedentemente, i meccanismi di rilevazione sono realizzati con l’obiettivo di garantire una elevata modularità e permettere alle applicazioni di comporre le funzionalità fornite secondo le necessità. Questo è possibile grazie ad un modello di interazione ispirato al modello ad eventi, che promuove il disaccoppiamento e facilità la riusabilità dei componenti, in quanto prevede che i componenti siano attivati in seguito alla generazione di eventi piuttosto che tramite invocazione diretta e che permette la configurazione delle tipologie di eventi cui un componente deve essere sensibile. Da questo punto di vista il meccanismo degli intent offerto da Android, descritto nella sezione 3.2.2, rappresenta un supporto perfetto per la realizzazione di questo modello. Gli intent rappresentano lo strumento standard offerto da Android per l’attivazione dei componenti applicativi quali activity, service e broadcast receiver, e permettono di invocare servizi e funzionalità senza avere conoscenza diretta del particolare componente che li fornisce. Nell’architettura descritta, ogni componente è attivato tramite la generazione di una specifica tipologia di intent, e genera, al completamento dell’operazione che gli compete, un intent ben definito che può quindi essere catturato da terzi. Ciò permette all’applicazione di utilizzare i componenti di supporto secondo le esigenze. Tramite l’invio di un intent al MicrophoneClient, ad esempio, può innescare una singola rilevazione sul microfono, catturando poi l’intent generato dal MicrophoneClient che segnala il completamento dell’operazione, o può attivare i meccanismi di sensing continuativo inviando un intent al SensingController.

Non solo, Android permette di configurare il meccanismo degli intent anche tramite file XML. Questo permette allo sviluppatore di predisporre catene di elaborazione costituite dai componenti di supporto senza prevedere il coinvolgimento del livello applicativo. Configurando opportunamente i componenti coinvolti, è possibile fare in modo ad esempio che il completamento di una rilevazione da parte dell’AcceleromterClient dia luogo direttamente all’attivazione dell’AccelerometerExtractor, seguito poi dall’UploadController per l’invio delle feature sul server. Ciò permette un’elevata flessibilità dei meccanismi, che possono essere combinati per realizzare i processi di rilevazione ed elaborazione richiesti dallo scenario applicativo.

Procediamo nel seguito ad illustrare i singoli componenti applicativi.

5.3.3 SensorClient e ContextClient Come abbiamo detto i componenti SensorClient si occupano di effettuare le

singole rilevazioni sui sensori di competenza. Sono realizzati come componenti android di tipo service, in quanto sono responsabili di task eseguiti in background e di durata non trascurabile. Sono differenziati secondo la tipologia di sensori cui fanno riferimento e producono rilevazioni, cioè oggetti SensorData, di tipo specifico. Il componente relativo all’accelerometro, ad esempio, l’AccelerometerClient, produce un oggetto di tipo AccelerometerData contenente una matrice 3xN di elementi di tipo float, dove N rappresenta la lunghezza della rilevazione e in cui ogni riga della matrice rappresenta un singolo campione (costituito dalle tre componenti sugli assi X, Y e Z).

I componenti di tipo SensorClient sono attivati da intent con action di tipo ACTION_<SENSOR>_CLIENT, dove <SENSOR> rappresenta il tipo di sensore cui


203

fanno riferimento (ad esempio avremo ACTION_ACCELEROMETER_CLIENT nel caso dell’accelerometro). Inoltre, è previsto anche l’intent generale ACTION_SENSOR_CLIENTS che provvede all’attivazione di tutti i client presenti nell’applicazione (cioè che sono stati opportunamente configurati come Android service nel file manifest dell’applicazione), che rappresenta il meccanismo usato dal SensingController per attivare tutti i componenti di sensing previsti dall’applicazione.

All’atto dell’attivazione, il generico SensorClient provvede ad effettuare una singola rilevazione sul sensore che gli compete, secondo la durata prevista. La durata di una singola rilevazione rappresenta un parametro che può essere configurato all’interno dei file di configurazione dell’applicazione. In alternativa, all’interno dell’intent inviato per l’attivazione è possibile includere il parametro DATA_LENGTH che specifica la durata della rilevazione. Anche la frequenza di rilevazione può essere impostata tramite file di configurazione o specificata nell’intent tramite il parametro DATA_RATE. Nel caso in cui il SensorClient riceva ulteriori richieste quando è già in corso una rilevazione, assume che la rilevazione in corso possa essere utilizzata anche dagli altri richiedenti e non effettua quindi una ulteriore rilevazione. Al termine della rilevazione, il SensorClient costruisce un oggetto di tipo SensorData contenente i dati rilevati, lo inserisce nel LocalRepository, e invia infine un intent di tipo <SENSOR>_DATA, dove <SENSOR> rappresenta il nome del sensore di competenza. L’intent può essere catturato da chi interessato, e contiene il parametro TIMESTAMP, che rappresenta l’istante iniziale della rilevazione nonché l’identificativo univoco della rilevazione per quel dato sensore, da utilizzare per l’estrazione dei dati dal LocalRepository. Dopodiché il componente termina la propria esecuzione. Il comportamento del generico SensorClient è riassunto in Figura 58: alla ricezione di un intent si attiva senza bloccare il chiamate, ed effettua una singola rilevazione dal sensore ottenendo un oggetto SensorData, che inserisce poi nel repository; a questo punto invia l’intent di completamento e termina l’esecuzione.

Figura 58 - Funzionamento a livello logico del genrico SensorClient.

Dal punto di vista implementativo, possiamo distinguere due tipologie di SensorClient: quelli che utilizzano API di supporto bloccanti, e quelli che fanno riferimento invece ad API non bloccanti. I primi sono costituiti sostanzialmente dai SensorClient per la registrazione audio e video che, come descritto nella sezione 3.2.3.3, utilizza API bloccanti per effettuare le rilevazioni. In questo caso l’operazione è gestita da un thread dedicato in modo da non bloccare il main thread


204

dell’applicazione, in conformità alle linee guida di gestione dei thread nelle applicazioni Android descritte nella sezione 3.2.2.7. La seconda categoria, più ampia, è formata da tutti i SensorClient che utilizzano l’interfaccia SensorManager per l’accesso ai sensori, descritta nella sezione 3.2.3.2. È quindi il caso dell’accelerometro, del giroscopio, e di tutti gli altri sensori supportati da Android. In questo caso il SensorManager offre un modello di interazione ad eventi, in cui il componente si registra per la ricezione degli aggiornamenti che il sistema si occupa poi di notificare. Per questo motivo, e dato che le operazioni svolte sai SensorClient alla ricezione di un dato sono semplicemente quello di memorizzare il dato, l’evento è gestito nel main thread dell’applicazione. Alla ricezione dell’ultimo dato, a cui corrisponde la memorizzazione nel LocalRepository e l’invio dell’intent di terminazione, viene generato un nuovo flusso di esecuzione, rappresentato da un oggetto AsyncTask, per gestire le operazioni.

I componenti ContextClient hanno un funzionamento analogo a quello dei SensorClient, ma si occupano della rilevazione dei dati di contesto, rappresentati da oggetti di tipo ContextData. Le due tipologie più importanti di ContextClient sono il CalendarProviderClient ed il BluetoothClient. Il primo si occupa di prelevare gli eventi nell’agenda dell’utente programmati in un tempo prossimo, configurabile dall’applicazione. Il BluetoothClient invece rileva gli utenti presenti all’interno di una località tramite la tecnologia Bluetooth. In questo caso l’operazione di rilevazione consiste quindi nell’operazione di discovery prevista dal protocollo Bluetooth. Attraverso l’operazione di discovery il client riceve l’identità dell’utente vicino. L’oggetto BluetoothData prodotto dal componente contiene quindi una lista di tutti gli utenti rilevati nelle vicinanze. Il componente comprende inoltre un modulo che agisce da server verso gli altri dispositivi, abilitando quindi il processo inverso di discovery da parte di terzi.

5.3.3.1 LocationClient Un tipo particolare di SensorClient è rappresentato dal LocationClient, che si

occupa di recuperare le informazioni sulla posizione corrente dell’utente tramite i sistemi di posizionamento. La disponibilità di molteplici sistemi di posizionamento, e i tempi necessari ad ottenere le misurazioni, rendono necessaria per questa tipologia di componente l’utilizzo di particolari strategie che differiscono da quelle che sono normalmente utilizzate dagli altri client dei sensori.

Come abbiamo visto nella sezione 3.2.3.1, il sistema Android mette a disposizione diversi provider tramite cui ottenere informazioni sulla posizione corrente dell’utente: il GPS_PROVIDER, corrispondente al sistema GPS descritto nel paragrafo 2.4.5.1, e il NETWORK_PROVIDER, che rappresenta i meccanismi di posizionamento basati su Wi-Fi e rete cellulare descritti rispettivamente nelle sezioni 2.4.5.4 e 2.4.5.3. Nel sistema Android, inoltre, una rilevazione di posizione è correlata da una misura del grado di accuratezza della rilevazione, che può essere recuperata attraverso il metodo getAccuracy(). A questo proposito, abbiamo visto nella sezione 3.2.3.1.3 - come la pratica consigliata per il recupero della posizione dell’utente sia di sfruttare diversi provider di posizionamento per ricevere molteplici aggiornamenti e selezionare di volta in volta la misurazione più accurate. In questo modo l’operazione


205

di rilevazione diviene un processo che richiede un intervallo di tempo relativamente ampio, che si protrae fino al raggiungimento di una sufficiente precisione della misurazioni ottenuta, come mostrato in Figura 59.

Figura 59 - Processo di rilevazione della posizione dell'utente.

Il LocationClient si occupa principalmente dell’implementazione di questo schema di funzionamento. All’atto della ricezione di un ACTION_LOCATION_CLIENT si registra per la ricezione degli aggiornamenti di posizionamento dai diversi provider. L’intent può contenere due parametri, ACCURACY e TIMEOUT, che rappresentano rispettivamente il livello di precisione che deve essere raggiunto nelle misurazioni, ed un timeout di terminazione che può essere utilizzato per evitare che la rilevazione si prolunghi per un tempo eccessivo. Specificando un valore pari a zero per il parametro TIMEOUT, si può ottenere l’attivazione del LocationClient in maniera continuativa. Durante la fase di attività, il LocationClient si occupa di gestire gli aggiornamenti ricevuti scartando le rilevazioni considerate meno accurate e conservando invece quelle con qualità maggiore. La qualità di una nuova misurazione ricevuta è valutata in base ai due criteri, in ordine d’importanza, di freschezza e accuratezza. Il primo prende come riferimento il timestamp associato alla misurazione, mentre il secondo il parametro accuracy. Innanzitutto, se la nuova misurazione è più recente di una soglia THRFRESH della precedente misurazione, è direttamente accettato, mentre se è più vecchio di una soglia THROLD è automaticamente scartato. Le misurazioni il cui timestamp cade all’interno dell’intervallo sono oggetto della seconda fase di valutazione, che si basa sull’accuratezza. Se il dato è più accurato del precedente, è considerato migliore e accettato. Infine, se è più recente del precedente e non è meno accurato di una soglia THRACC viene comunque accettato. In tutti gli altri casi la nuova rilevazione è scartata ed è mantenuta quella precedente. In Figura 60 sono rappresentate le possibili regioni in funzione della differenza di timestamp e di accuratezza tra la vecchia e la nuova rilevazione.


206

Figura 60 - Regioni di accettazione (verde) e rifiuto (rosso) in funzione di differenza di timestamp e accuratezza.

Altra caratteristica peculiare del sistema Android è di poter indicare, all’atto della registrazione presso uno specifico provider, la frequenza e la precisione con cui s’intende ricevere gli aggiornamenti. Vedremo che questa ed altre caratteristiche del supporto sono utilizzata per mettere in atto due strategia di ottimizzazione dell’uso delle risorse dette Cycle Optimization e Low Battery Mode, che saranno descritte in seguito nella sezione 5.3.7 in quanto riguardano anche altri componenti non ancora presentati.

5.3.4 SensingController e ContextController Il componente SensingController si occupa di gestire i cicli di rilevazione per

realizzare le operazioni di sensing continuativo. Questo componente, a differenza dei SensorClient che terminano dopo aver effettuato una singola rilevazione, una volta attivato attraverso l’intent ACTION_SENSING_START rimane attivo fino a che non si esprime l’esplicità volontà di terminarlo attraverso l’invio di un intent di tipo ACTION_SENSING_STOP. Anche questo tipo di componenti è realizzato come Android service. Durante la fase di attività, il componente provvede ciclicamente, secondo il periodo previsto dal ciclo di sensing, ad attivare i componenti previsti dall’applicazione attraverso l’invio di un intent di tipo ACTION_SENSOR_CLIENTS, che abbiamo già citato nella sezione precedente tra gli intent di attivazione dei SensorClient. Il funzionamento logico del componente è rappresentato in Figura 61: dopo l’attivazione, invia eventi di attivazione ai SensorClient ad ogni ciclo sospendendosi per un intervallo di tempo pari al periodo del ciclo; ripete il ciclo fino alla ricezione di un intent ACTION_SENSING_STOP. Considerazioni analoghe valgono anche per il ContextController.


207

Figura 61 - Funzionamento a livello logico del SensingController.

I componenti SensingController e ContextController realizzano inoltre due importanti strategie di ottimizzazione dell’utilizzo delle risorse, dette Cycle Optimization e Low Battery Mode. La prima prevede la gestione dinamica del periodo dei cicli di rilevazione in funzione del carico computazionale corrente del processore e della disponibilità di batteria. La seconda prevede un’ulteriore riduzione del periodo di rilevazione in corrispondenza della rilevazione di un livello di batteria particolarmente basso. Le strategie saranno presentate nella sezione 5.3.7.

5.3.5 FeatureExtractor I FeatureExtractor sono componenti relativamente semplici che si occupano

dell’operazione di estrazione delle feature dai dati rilevati dai SensorClient. Sono differenziati in base al tipo di sensore cui fanno riferimento e sono attivati alla ricezione di un intent ACTION_<SENSOR>_DATA, dove <SENSOR> rappresenta il tipo di sensore cui fanno riferimento. Avremo quindi l’AccelerometerExtractor per l’accelerometro, che è attivato dall’intent ACTION_ACCELEROMETER_DATA, o il MicrophoneExtractor per il microfono che è attivato dall’intent ACTION_MICROPHONE_DATA.

Una volta attivato, il componente estrae dall’intent il campo TIMESTAMP che rappresenta l’identificativo dell’oggetto SensorData di competenza, e recupera l’oggetto in questione dal LocalRepository. Sfruttando opportune funzioni e librerie matematiche elabora le feature a partire dalle informazioni presenti nell’oggetto SensorData. A questo punto inserisce le feature calcolate nel LocalRepository utilizzando lo stesso identificativo dell’oggetto SensorData, per poi generare un intent che segnala il completamento dell’esecuzione di tipo ACTION_<SENSOR>_FEATURE, dove <SENSOR> rappresenta lo specifico sensore di competenza. Anche in questo caso l’intent prevede un campo TIMESTAMP che contiene l’identificativo dell’oggetto. In Figura 62 è rappresentato il funzionamento logico del generico componente di tipo FeatureExtractor: alla ricezione dell’intent di attivazione, estrae l’oggetto SensorData dal repository ed elabora con questi le feature; dopodiché inserisce le feature nel repository ed invia l’intent di completamento dell’esecuzione.


208

Figura 62 - Funzionamento logico dei componenti FeatureExtractor.

5.3.6 UploadController L’UploadController si occupa di effettuare periodicamente i trasferimenti verso

il server dei dati rilevati dai SensorClient, delle feature estratte dai FeatureExtractor, o dei dati di contesto rilevati, ed è realizzato come componente Android di tipo service. Può essere attivato dagli intent di tipo ACTION_<SENSOR>_DATA, ACTION_<SENSOR>_FEATURE, o ACTION_<CONTEXT>_DATA. In funzione della tipologia di intent ricevuto, si occupa di prelevare le informazioni corrispondenti dal LocalRepository ed effettuare il trasferimento. Nonostante sia possibile effettuare il trasferimento sia dei dati grezzi rilevati dai sensori, sia delle feature estratte, abbiamo già discusso il fatto che la dimensione dei dati grezzi può essere considerevole e può comportare un notevole impegno di banda. Per questo motivo è preferibile trasferire solo le feature estratte dai dati, mentre la funzionalità di trasferimento dei dati grezzi deve essere utilizzata solo quando assolutamente necessario per lo scenario applicativo.

Il modello di funzionamento del componente mira a ridurre il numero di trasferimenti effettuati verso il server accumulando i dati da inviare e effettuando trasferimenti più consistenti. In particolare, all’atto della ricezione di una richiesta di attivazione, l’UploadController non effettua immediatamente il trasferimento, ma attende per un periodo di tempo, pari a TWAIT, l’arrivo di ulteriori richieste di trasferimento. Allo scadere dell’intervallo, il componente raccoglie i dati relativi a tutte le richieste ricevute ed effettua un unico trasferimento che comprende tutti i dati da inviare. L’obiettivo è quello di ridurre l’overhead di comunicazione raccogliendo all’interno dello stesso messaggio una quantità sufficiente di payload ed effettuando un numero minore di singoli trasferimenti. Il parametro TWAIT deve essere opportunamente configurato dall’applicazione in base ai periodi di sensing degli altri componenti. Un valore troppo elevato rispetto ai cicli di rilevazione comporterebbe l’accumulo di una quantità eccessiva di dati per cui i singoli trasferimenti diventano eccessivi, ma allo stesso tempo un valore troppo basso comporta un numero di trasferimenti elevato. Inoltre, nel caso di esigenze specifiche per il trasferimento di rilevazioni particolari è possibile specificare nell’intent di attivazione il valore del periodo attraverso il parametro T_WAIT.


209

All’atto della ricezione della prima richiesta il componente costruisce un nuovo messaggio, rappresentato da un oggetto di tipo Message, e vi inserisce i dati prelevati dal LocalRepository specificati nell’intent di attivazione tramite il parametro TIMESTAMP. A questo punto attiva un timer che segnalerà lo scadere del periodo di attesa individuato da TWAIT. Durante questo intervallo di tempo, alla ricezione di ulteriori richieste il componente si occupa di prelevare i dati relativi dal LocalRepository e inserirli nel messaggio. Solo allo scadere dell’intervallo TWAIT il messaggio è effettivamente inviato al server tramite le API fornite dalla piattaforma Android. Il comportamento descritto, che rappresenta il funzionamento a livello logico del componente, è schematizzato nel diagramma di Figura 61.

Figura 63 - Diagramma di funzionamento a livello logico dell’UploadController.

Dal punto di vista implementativo la funzionalità di invio delle informazioni è basata sul framework Spring for Android. Questa libreria offre funzionalità di alto livello per la realizzazione di una comunicazione basata su stile architetturale REST. I messaggi inviati dall’UploadController sono rappresentati da messaggi HTTP di tipo POST. Spring for Android utilizza librerie quali Jackson Json e specifiche quali JAXB per il mapping tra oggetti e corpo dei messaggi. In questo modo è possibile specificare la struttura dei messaggi scambiati tramite la definizione di oggetti POJO opportunamente formati. Nel nostro caso i messaggi utilizzati per il trasferimento delle rilevazioni sul server sono rappresentati da oggetti di tipo ServerUpdate. Questi sono costituiti da una lista per ogni tipologia di oggetti SensorData, ContextData e SensorFeature. Tutti i campi sono opzionali, così da permettere l’invio di messaggi contenenti solo le informazioni disponibili al momento del trasferimento. Il formato scelto per la codifica dei messaggi è JSON, data la maggiore semplicità e compattezza rispetto a XML.

5.3.7 Cycle Optimization e Low Battery Mode Le operazioni di sensing rappresentano delle attività dispendiose in termini di

risorse energetiche e computazionali, e che trattandosi di operazioni in background non direttamente visibili all’utente non devono degradare le prestazioni del sistema inficiando l’esperienza di fruizione percepita dall’utente. A questo proposito la politica Cycle Optimization (CO) cerca di ridurre l’impatto delle operazioni di sensing tramite


210

la gestione dinamica dei cicli di rilevazione in funzione delle risorse disponibili sul sistema. Considerando che, oltre ai sensori, anche l’utilizzo dei sistemi di comunicazione wireless e dei sistemi di posizionamento ha un considerevole impatto sulle prestazioni del sistema, la strategia è utilizzata, oltre che dal SensingController e dal ContextController, anche dall’UploadController per il coordinamento delle operazioni di trasferimento verso il server. Anche il Location Client, come vedremo, utilizza una strategia analoga per controllare la frequenza di ricezione degli aggiornamenti dai sistemi di posizionamento.

Come abbiamo detto, la strategia si basa sulla regolazione dinamica del periodo (T) dei cicli di rilevazione o di operatività dei componenti. In particolare prende in considerazione due parametri fondamentali, che chiameremo TMIN e TMAX, che rappresentano rispettivamente il periodo minimo e massimo dei cicli di operatività. Questi due parametri individuano l’intervallo entro cui può oscillare il valore del periodo T utilizzato durante l’attività del componente. Il parametro T è ricalcolato ad ogni attivazione del componente sulla base del carico computazionale del sistema, rappresentato dall’utilizzazione della CPU, e dal livello di carica della batteria. In particolare sono calcolati due differenti valori di T, uno basandosi sul carico computazionale (TCPU) e l’altro basandosi sul livello di batteria (TBAT) secondo le seguenti formule:

!!"# = !!"# + !!"# − !!"# ∗ !"# !"#!"#

!!"# = !!"# + !!"# − !!"# ∗ (1 − !"#)

in cui CPU rappresenta una misura percentuale dell’utilizzazione della CPU, BAT rappresenta il livello di carica corrente della batteria, e CPUTHR costituisce un parametro di configurazione che permette di indicare la soglia massima di utilizzazione di CPU in corrispondenza della quale il periodo deve essere ridotto al minimo. Le due formule definiscono una proporzionalità diretta molto semplice tra il periodo e l’utilizzazione di CPU o la carica di batteria già consumata, in cui la grandezza (TMAX- TMIN) rappresenta il coefficiente angolare che determina la pendenza delle rette. In Figura 64 è riportata la relazione di proporzionalità nel caso di TCPU abbiamo.

Figura 64 - Relazione tra il periodo TCPU e l'utilizzazione del processore.


211

Nel caso in cui l’utilizzazione della CPU superi la soglia CPUTHR è preso come periodo di riferimento il valore TMIN. Tipicamente, l’utilizzazione di CPU rappresenta un parametro molto più dinamico e variabile nel tempo rispetto alla carica di batteria. Per la batteria, infatti, l’andamento crescente o decrescente è determinato dal fatto che il dispositivo sia collegato o meno all’alimentazione, e le variazioni hanno una dinamica molto più lenta rispetto a quella che caratterizza l’utilizzazione della CPU. In ogni caso, la strategia CO prevede che sia scelto come periodo T corrente il minimo tra i due valori TCPU e TBAT, nell’ottica di preservare la risorsa di cui il sistema scarseggia.

La strategia permette quindi di aumentare il periodo dei cicli di operatività, e conseguentemente ridurre l’impatto energetico e computazionale delle operazioni di sensing, nei momenti in cui il carico sulla CPU diventa eccessivo o la batteria si sta scaricando. La strategia descritta è utilizzata dal SensingController e dal ContextController per regolare il periodo dei cicli di sensing. Nel caso dell’UploadController, invece, gli stessi meccanismi sono utilizzati per determinare il tempo di attesa T che intercorre dalla ricezione della prima richiesta di trasferimento e l’effettivo trasferimento dei dati. In particolare, il parametro TWAIT è configurato a livello applicativo tramite la definizione di un TWAIT_MIN minimo e di un TWAIT_MAX massimo. All’atto della ricezione della prima richiesta di trasferimento, il controller determina il valore effettivo di TWAIT da utilizzare come minimo tra TCPU e TBAT. Nel caso in cui il parametro sia specificato via intent di attivazione è utilizzato il valore esatto. Nel caso del Location Client, invece, la strategia Cycle Optimization è utilizzata per regolare due importanti parametri che influiscono sulla frequenza con cui sono utilizzati i sistemi di posizionamento. Si tratta dei parametri MIN_FREQUENCY e MIN_DISTANCE, che rappresentano rispettivamente la frequenza minima e la distanza minima di spostamento dell’utente che devono caratterizzare gli aggiornamenti. Questi parametri vanno specificati all’atto della registrazione presso il provider di posizionamento. Il LocationClient, all’atto dell’attivazione, prima di effettuare la registrazione presso i provider determina attraverso formule analoghe e simili parametri massimi e minimi il valore più adatto per queste grandezze. Tali parametri rimangono fissi per tutto il periodo di attivazione del LocationClient. Tuttavia, è possibile forzare la riconfigurazione del componente inviando un nuovo intent di attivazione.

Un’altra strategia di ottimizzazione, indirizzata però principalmente al risparmio energetico, e in particolare a evitare il completo spegnimento del dispositivo, è la Low Battery Mode (LBM). Rappresenta una modalità di funzionamento dei componenti orientata al risparmio energetico che si attiva quando la carica di batteria scende sotto la soglia BATTHR e utilizza un periodo TLOW ancora più basso del TMIN utilizzato dalla CO. Entrambi i parametri, BATTHR e TLOW possono essere configurati dall’applicazione a piacimento, tuttavia l’utilizzo consigliato è quello di indicare un livello di batteria relativamente basso (il valore di default, ad esempio, è del 15%) e un periodo TLOW inferiore al TMIN utilizzato per la CO. Il senso della strategia è che, mentre la CO è utilizzata per indicare un intervallo dinamico che però fa sempre riferimento alla normale operatività del dispositivo, la LBM mira a ridurre considerevolmente l’uso delle risorse, imponendo una funzionalità ridotta in maniera stabile anziché variabile, per ritardare il più possibile l’evento indesiderato


212

rappresentato dallo spegnimento del dispositivo. Nel caso del LocationClient, la strategia non si traduce esclusivamente in periodi di attivazione più bassi, ma anche in parametri MIN_FREQUENCY e MIN_DISTANCE più elevati, per ridurre la frequenza di ricezione degli aggiornamenti, e soprattutto nella disattivazione del sistema GPS per utilizzare esclusivamente i sistemi di posizionamento basati su rete Wi-Fi e su rete cellulare.

La CO e la LBM rappresentano due elementi fondamentali del sistema poiché permettono di affrontare le criticità che contraddistinguono i dispositivi mobili in merito alle risorse energetiche e computazionali. La combinazione delle due strategie permette quindi di ridurre il carico di elaborazione e il consumo energetico durante il normale funzionamento, e di preservare la batteria nel caso in cui la carica sia prossima all’esaurimento. Nel capitolo successivo inoltre, queste strategie saranno applicate ad un caso concreto e testate per verificarne l’effettiva efficacia.

5.3.8 LocalRepository Rappresenta un repository locale e condiviso tra i componenti applicativi che

raccoglie i dati provenienti dall’infrastruttura di sensing e di raccolta dei dati di contesto. In particolare raccoglie: i dati rilevati dai sensori, che sono depositati dai Client dei sensori e prelevati dai FeatureExtractor; le feature, depositate dai FeatureExtractor e prelevate dall’UploadController per essere inviate al server; i dati di contesto, depositati dai Clienti di contesto e prelevate dall’UploadController per essere inviate al server.

È implementato come database di tipo SQLite sfruttando il supporto offerto dalla piattaforma Android per questo tipo di supporto di archiviazione. Il componente LocalRepository incapsula la logica di accesso al database fornendo i metodi per rendere gli oggetti SensorData, ContextData e SensorFeature persistenti, e per recuperarli a partire dall’identificativo. In tutti i casi l’identificativo utilizzato per recuperare i dati è rappresentato dal timestamp associato alla rilevazione.

5.3.9 Configurazione degli intent Nelle sezioni precedenti abbiamo descritto in modo discontinuo i meccanismi di

attivazione dei singoli componenti, specificando di volta in volta quali particolari intent davano luogo all’attivazione dei componenti e quali invece venivano generati in corrispondenza della conclusione delle operazioni. In questa sezione procederemo innanzitutto a ricapitolare queste specifiche per maggiore chiarezza, per poi descrivere brevemente le tecniche con cui è realizzato ma soprattutto illustrare le modalità con cui può essere configurato il meccanismo di attivazione e di interazione dei componenti. La comprensione di questi meccanismi è un requisito fondamentale per permettere la combinazione dei componenti secondo le necessità dello scenario applicativo e per abilitare la costruzione di flussi di elaborazione delle informazioni specifici.

Partiamo innanzitutto con un breve riepilogo dei meccanismi di attivazione. La Tabella 2 riassume gli intent di attivazione e quelli generati previsti a default per le


213

diverse tipologie di componenti. Per brevità è stata omessa la stringa “ACTION” davanti all’action di ogni intent.

Componente Intent di attivazione (disattivazione)

Intent generati

<Sensor>Client <SENSOR>_CLIENT, SENSOR_CLIENTS

<SENSOR>_DATA

<Context>Client <CONTEXT>_CLIENT, CONTEXT_CLIENTS

<CONTEXT>_DATA

SensingController SENSING_START (SENSING_STOP)

SENSOR_CLIENTS

ContextController CONTEXT_START (CONTEXT_STOP)

CONTEXT_CLIENTS

FeatureExtractor <SENSOR>_DATA <SENSOR>_FEATURE

UploadController <SENSOR>_DATA, <CONTEXT>_DATA, <SENSOR>_FEATURE

Tabella 2 - Intent di attivazione e di completamento dei componenti di supporto.

Per conoscere le possibilità offerte e comprendere il funzionamento del sistema di interazione dei componenti è necessario studiare i meccanismi attraverso cui è implementato. Ogni componente tra quelli presenti nella tabella precedente è realizzato come componente Android di tipo service. Come abbiamo descritto nella sezione 3.2.2.4, l’attivazione degli Android service avviene attraverso il meccanismo degli intent, che sono inviati tramite il metodo startService(intent), e può essere realizzato tramite intent espliciti o impliciti. Negli intent espliciti si specifica direttamente il tipo del componente che deve essere attivato, mentre gli intent impliciti, piuttosto che indicare esplicitamente il componente da attivare, si utilizza un parametro detto action per specificare il tipo di attività che si richiede. Il meccanismo di risoluzione degli intent offerto dal supporto Android si occupa di trovare un componente capace di rispondere all’action richiesta. Si tratta di un modello di interazione molto potente che ha però la limitazione di portare all’attivazione di un solo componente service per volta. Ciò non rende possibile realizzare schemi di attivazione uno a molti, in cui ad esempio lo stesso intent MICROPHONE_DATA è consegnato sia al relativo FeatureExtractor per l’estrazione delle feature, sia al livello applicativo per la creazione di un contenuto. Per questo motivo abbiamo scelto di utilizzare una modalità di interazione basata sui componenti broadcast receiver, che come abbiamo visto nella sezione 3.2.2.6 permettono la ricezione degli intent da parte di più componenti.


214

L’invio degli intent non è quindi effettuato tramite il metodo startService() ma tramite il metodo sendBroadcast(). Per ognuno dei componenti di supporto riportati in Tabella 2 sono realizzati dei broadcast receiver che si occupano di gestire gli intent di attivazione (e di disattivazione) del servizio. Tali componenti, che sono chiamati attraverso la notazione <NomeComponente>Receiver, vanno configurati all’interno del file XML specificando quali intent devono gestire. In questo modo l’applicazione può configurare a proprio piacimento e nel modo più flessibile possibile le dinamiche di attivazione dei componenti. Inoltre, il meccanismo dei broadcast receiver può essere utilizzato dall’applicazione per intercettare le operazioni di rilevazione e implementare ad esempio meccanismi di generazione dei contenuti. Tramite la realizzazione e la configurazione di opportuni broadcast receiver, in aggiunta a quelli di sistema, l’applicazione può catturare gli eventi generati dai componenti e mettere in atto le politiche desiderate, prelevando i dati dal LocalRepository o inviando intent di attivazione ad altri componenti. La realizzazione di brodcast receiver applicativi permette inoltre di introdurre nuovi intent di attivazione dei componenti, oltre a quelli previsti in Tabella 2.

In ogni caso, è sempre possibile ricorrere all’attivazione di componenti richiesti tramite il metodo startService(), utilizzando sia intent impliciti che espliciti. Questa modalità è tipicamente preferibile per i componenti di tipo SensingController e ContextController, che spesso non è necessario attivare tramite intent in broadcast, in quanto evita la necessità di configurare i relativi broadcast receiver. In questo caso i componenti possono essere attivati e disattivati semplicemente tramite i metodi startService() e stopService().

In Figura 65 è mostrata una configurazione di esempio che utilizza un componente AccelerometerClient per il monitoraggio continuativo dell’accelerometro, e un MicrophoneClient che è invece utilizzato dall’applicazione per la generazione di contenuti. Il SensingController è attivato tramite intent esplicito e non necessita quindi la configurazione del broadcast receiver. Anche il MicrophoneClient è attivato tramite intent esplicito e non utilizza il BroadcastReceiver. I dati estratti dall’accelerometro sono inviati al Feature Extractor e le feature risultanti sono raccolte all’UploadController per il trasferimento verso il server. Nel caso del MicrophoneClient invece l’intent MICROPHONE_DATA generato è catturato da un broadcast receiver applicativo che si occupa di gestire i dati rilevati.


215

Figura 65 - Esempio di configurazione dei componenti.

In conclusione, i meccanismi predisposti sul client permettono di realizzare il processo di rilevazione, elaborazione e trasferimento delle informazioni provenienti dai sensori e dei dati di contesto, garantendo estrema flessibilità e configurabilità nella combinazione dei componenti. Le politiche di ottimizzazione Cycle Optimization e Low Battery Mode inoltre permettono di ridurre l’impatto del processo di rilevazione e elaborazione sulle risorse energetiche e computazionali del sistema. Vediamo ora com’è realizzata l’infrastruttura server.

5.4 - Server Il server è responsabile di due funzionalità fondamentali. In primo luogo, quella

di elaborare i contenuti provenienti dai client applicando il processo partecipativo e determinando quindi gli attori che devono essere coinvolti nell’attività partecipativa. Inoltre, si occupa di raccogliere, memorizzare ed elaborare le informazioni sensoriali rilevate sul client per estrarre informazioni di stato sugli utenti, che sono messe quindi a disposizione dei criteri di selezione degli utenti. A questo proposito il processo di elaborazione più importante è quello di activity recognition, che fornisce informazioni di stato sugli utenti quali l’attività svolta correntemente e la sua disponibilità ad essere coinvolto o meno in attività partecipative.

Per l’architettura server un requisito fondamentale è rappresentato dalle possibilità d’integrazione con gli scenari e le tecnologie in ambito enterprise. In previsione di un futuro dispiegamento dell’infrastruttura in un contesto reale, all’interno di uno scenario aziendale, si pone la necessità di garantire la possibilità di interfacciare i meccanismi dell’infrastruttura di back-end con piattaforme di erogazione di servizi partecipativi preesistenti. A questo proposito, nel capitolo 4 -


216

abbiamo evidenziato come la piattaforma Spring garantisca un’elevata portabilità, mutuata direttamente dalla piattaforma Java, e al tempo stesso permetta l’integrazione con una vasta gamma di tecnologie di tipo enterprise. Per questi motivi è particolarmente adatta a garantire interoperabilità e possibilità di integrazione all’interno degli scenari di tipo enterprise più disparati. L’altro grande vantaggio di Spring consiste nell’approccio a container leggero che permette di ottenere prestazioni elevate e scalabilità, caratteristiche determinanti per garantire l’usabilità dei servizi partecipativi su larga scala, data l’elevata mole di utenti che caratterizza lo scenario. Spring inoltre offre due funzionalità importantissime nel nostro contesto: la DI e il supporto AOP. Tramite la prima è possibile garantire alle applicazioni una elevata configurabilità del sistema, che potrà essere configurato e costruito selezionando i componenti di supporto necessari in base alle funzionalità richieste. Vedremo inoltre come il supporto AOP sia particolarmente adatto alla realizzazione della catena partecipativa in modo trasparente e trasversale alle applicazioni. Tramite il supporto ORM offerto dal framework, inoltre, sarà è realizzare il layer di persistenza e il pattern DAO in modo semplice ed efficace.

L’architettura server, rappresentata in Figura 66, è organizzata secondo il modello three-tier caratteristico delle applicazioni enterprise, come abbiamo visto nella sezione 4.1.2, formata dai tre livelli di presentazione, business e persistenza. Nel livello di presentazione troviamo il componente SensingController che, basandosi sul supporto Spring MVC, si occupa di ricevere le informazioni provenienti dal client, costituite dai dati grezzi rilevati dai sensori, le feature e dati di contesto, e veicolate dal protocollo REST. Eventuali componenti per la ricezione dei contenuti generati dal client sono di competenza del livello applicativo in quanto la struttura di queste informazioni è fortemente legata allo scenario applicativo. Le informazioni ricevute sono trasferite ai livelli sottostanti per essere resi persistenti ed elaborati. Nel livello di business troviamo i componenti che si occupano del processo di activity recognition e della gestione del processo partecipativo. Il primo è realizzato attraverso componenti detti PrimitiveClassifier e FeatureClassifier, che come vedremo si occupano di elaborare feature per calcolare primitive e fatti. I componenti principali di gestione del processo partecipativo sono invece rappresentati dalle factory per la creazione dei processi partecipativi, le ChainFactory, dai componenti di gestione delle catene di criteri detti ChainManager, e dagli altri componenti di supporto per la creazione delle catene tra i quali i criteri built-in e un’implementazione del pattern Chain-of-Responsibility (CoR). Infine nel layer di persistenza troviamo diverse interfacce DAO per la gestione delle informazioni sugli utenti, da quelle di rilevazione provenienti dal client, a quelle relative la profilazione e la socialità, alle informazioni di stato estratte dal processo di activity recognition.


217

Figura 66 – Architettura three-tier dell'infrastruttura server.

Procediamo quindi ad esaminare i singoli livelli.

5.4.1 Presentation Layer Il livello di presentazione prevede il componente SensingController che si

occupa di gestire la ricezione dei dati provenienti dal client relativamente al monitoraggio dei sensori. È realizzato come componente di tipo Controller secondo la semantica propria del framework Spring MVC, descritto nella sezione 4.3.4.3. Questi componenti rappresentano gli strumenti principali offerti dal framework per la gestione del layer di presentazione e la creazione di servizi di ogni genere, svolgendo il ruolo di controller all’interno del pattern MVC. In accordo all’approccio leggero che caratterizza Spring, il SensingController è rappresentato da un semplice POJO cui è apposta l’annotazione @Controller.

Il componente definisce sostanzialmente un RESTful Web Service che permette l’upload di dati sensorisali, feature e dati di contesto relativi ad un particolare utente tramite messaggi HTTP di tipo POST. Precisiamo che questo componente si occupa esclusivamente della ricezione dei dati di monitoraggio e di contesto utilizzati per attività relative all’elaborazione dello stato dell’utente quali l’activity recognition. La gestione dei contenuti, la cui struttura e tipologia di messaggi dipende fortemente dal contesto applicativo, è demandata ai componenti di presentazione definiti dall’applicazione. Il supporto Spring MVC permette la definizione dei messaggi scambiati con il client tramite oggetti Java. In modo analogo a quanto avveniva con il supporto Spring for Android sul Client, Spring MVC si occupa di tradurre i messaggi ricevuti ed inviati in istanze di oggetti opportunamente definite, attraverso le librerie Jackson JSON e JAXB che gestiscono il mapping dei formati JSON e XML in oggetti Java. Non solo, Spring MVC si occupa di iniettare le istanze degli oggetti Java che rappresentano i messaggi all’interno dei metodi di servizio definiti dai controller, semplificando notevolmente la realizzazione dei servizi.

Il SensingController gestisce messaggi di tipo ServerUpload, gli stessi già introdotti in merito all’UploadController sul client nella sezione 5.3.6. Questi


218

messaggi contengono una lista di istanze per ogni tipologia di dato: SensorData per i dati rilevati dai sensori, SensorFeature per le feature, e ContextData per i dati di contesto. Come abbiamo già detto in sede di presentazione dei messaggi ServerUpload, tutti i campi sono opzionali e ciò permette di utilizzare la stessa tipologia di messaggio per ogni configurazione e scenario, indipendentemente dal particolare sottoinsieme di dati utilizzati dall’applicazione. Il RESTful Web Service esposto dal componente è rappresentato dal metodo uploadData(), cui è apposta l’annotazione @RequestMapping, descritta nella sezione 4.3.4.3.1 -, tramite cui definiamo l’URI corrispondente al servizio. In particolare, l’URI è rappresentato dalla stringa /users/{userid}/data, e contiene l’URI template pattern {userid} che rappresenta il nome del particolare utente che effettua l’upload. L’annotazione @RequestBody apposta al parametro del metodo di tipo ServerUpload fa in modo che, all’atto della ricezione di un messaggio e della conseguente invocazione del metodo di servizio, il container v’inietti un’istanza costruita con le informazioni contenute all’interno del corpo del messaggio HTTP. Come avevamo già anticipato parlando del modulo client, il formato scelto per il corpo dei messaggi è il formato JSON. Inoltre, tramite l’annotazione @ResponseStatus è possibile definire lo status HTTP che deve essere restituito al client nel caso in cui l’esecuzione del servizio abbia successo. In questo caso abbiamo scelto di restituire il codice 201 che indica la creazione delle risorse corrispondenti ai dati inviati dal client. Le caratteristiche del servizio descritto sono riassunte in Figura 67.

Figura 67 - Schema riassuntivo del RESTful Web Service uploadData().

Alla ricezione di un messaggio di questo tipo, il componente si occupa di rendere persistenti le informazioni contenute attraverso i componenti del layer di persistenza di tipo SensingDAO, che forniscono l’accesso al layer di persistenza in merito alle informazioni di rilevazione. Dopodiché notificano l’avvenuta ricezione ai componenti del livello di business responsabili del processo di activity recognition, cioè i PrimitiveClassifier, come mostrato in Figura 68.


219

Figura 68 - Diagramma di interazione del SensingController alla ricezione di un messaggio ServerUpdate.

5.4.2 Business Layer Le responsabilità principali del livello di business sono rappresentate dal

processo di activity recognition e dal processo partecipativo. I componenti di questo livello sono realizzati, salvo rare eccezioni che saranno specificate, come Spring bean. Si tratta, come abbiamo specificato nella sezione 4.3.1 relativamente al Container e IoC del framework Spring, di componenti che possono quindi usufruire dei servizi di supporto offerti dal framework, prima fra tutte la Dependecy Injection (DI). Questa tecnica permetterà di definire le associazioni e le dipendenze tra i componenti in modo estremamente flessibile, consentendo la costruzione e la configurazione delle applicazioni sfruttando i meccanismi di supporto. Vedremo inoltre come la DI risulterà utile per abilitare una particolare modalità di definizione delle catene partecipative, caratterizzata da elevata flessibilità in quanto basata su file XML.

Oltre alla DI, anche il supporto Spring alle tecniche AOP avrà un ruolo fondamentale per la realizzazione del processo partecipativo e nel meccanismo d’inserimento dello stesso all’interno delle dinamiche applicative. Procediamo quindi a presentare il modulo di gestione del processo partecipativo.

5.4.2.1 Participatory Il modulo Participatory raccoglie le funzionalità fondamentali che supportano

l’elaborazione dei contenuti all’interno del processo partecipativo. Come abbiamo detto in precedenza, questo processo elabora i contenuti applicando una catena di criteri per determinare l’insieme di attori coinvolti. I concetti fondamentali di questo processo sono rappresentati quindi dai contenuti, dagli attori, e dai criteri. La realizzazione del processo partecipativo è basata, oltre che su queste entità fondamentali, sull’implementazione del pattern Chain-of-Responsibility, che permette di combinare i criteri a formare una catena di esecuzione, e due interfacce molto importanti, ChainFactory e ChainManager, che si occupano della creazione e della gestione delle catene. Procediamo quindi ad illustrare prima le entità di base per poi descrivere i componenti più complessi.


220

5.4.2.1.1 - Contenuti, attori, criteri

I contenuti rappresentano le informazioni caricate dagli utenti che divengono oggetto del processo partecipativo. Si tratta di una struttura fortemente dipendente dallo scenario applicativo e ci limiteremo pertanto a raccoglierne gli elementi fondamentali e ricorrenti. Il generico contenuto è rappresentato all’interno del processo partecipativo dall’interfaccia Content, che ne definisce un insieme minimo di proprietà, costituito dall’identificativo dell’utente mittente e dall’istante di tempo in cui è stato generato. Questa seconda proprietà è molto importante in quanto permette di mettere in relazione il contenuto con le informazioni di rilevazione memorizzate dal server, anch’esse associate ad un preciso istante temporale. La scelta di un’interfaccia piuttosto che di una classe astratta non è casuale ed ha, come vedremo in seguito, un forte impatto sulla portabilità e sulla riusabilità sia dei criteri sia delle catene partecipative. Inoltre permette l’utilizzo dei framework ORM in cui la configurazione è basata su annotazioni, in quanto lascia alle implementazioni concrete la possibilità di definire campi e metodi. Ciò non sarebbe possibile se avessimo utilizzato una classe astratta.

Figura 69 – Interfaccia Content.

Altra unità fondamentale del processo partecipativo è rappresentato dal concetto di attore. L’insieme di attori coinvolti costituisce, infatti, l’elemento stesso sul quale operano i criteri. Gli attori possono rappresentare diverse tipologie di entità che vanno dagli utenti del sistema, a istituzioni, associazioni o qualsiasi altro soggetto che può prendere parte al processo partecipativo. Una particolare tipologia di attori è rappresentata dagli utenti del sistema in senso tradizionale, cioè dagli individui che accedono al sistema tramite i loro dispositivi mobili, in quanto dotati di proprietà particolari che possono essere utilizzate dal sistema, a cui è tipicamente applicato un processo di elaborazione differente. Date queste differenze vedremo come risulti più sensato definire queste categorie come insiemi disgiunti, così da permettere una elaborazione differenziata da parte dei criteri. Per questo motivo scegliamo di separare gli utenti dal resto degli attori, definendoli come due entità ben distinte. La classe Actor quindi è utilizzata per rappresentare il generico attore che non costituisce un utente nel sistema. Gli oggetti User, la cui struttura è riportata in Figura 70, rappresentano invece gli utenti del sistema. In accordo alle specifiche, sono correlati da un insieme di informazioni aggiuntive quali l’insieme di utenti in relazione sociale, un profilo che raccoglie le informazioni personali (Profile), uno stato che rappresenta l’insieme di informazioni elaborate attraverso i processi di activity recognition (State). A queste informazioni si aggiungono infine l’insieme di contenuti creati dallo stesso e, come vedremo nella sezione relativa l’activity recognition, anche l’insieme di informazioni di rilevazione caricate dal client, che per comodità di rappresentazione abbiamo omesso dal diagramma.


221

Figura 70 - Diagramma della clase User.

I criteri elaborano quindi oggetti di tipo Content determinando l’insieme di attori coinvolti nel processo. Sono rappresentati dall’interfaccia Criteria, parametrizzata rispetto al tipo generico T extends Content, la cui operazione apply(T, ParticipatoryContext) permette di applicare il criterio ad un insieme di attori. I parametri del metodo sono costituiti dal contenuto e da un oggetto ParticipatoryContext creato per rappresentare il contesto partecipativo incapsulando l’insieme di utenti e l’insieme di attori coinvolto. Per un singolo criterio, questo oggetto rappresenta l’insieme di attori che rappresenta il risultato dell’applicazione dei criteri precedenti. Per permettere ai criteri di operare in modo più semplice e selettivo sull’insieme di attori e su quello di utenti, e in accordo alla scelta di tenere i due insiemi disgiunti, l’oggetto ParticipatoryContext li espone separatamente. L’oggetto prevede include inoltre inoltre un insieme di bacheche virtuali su cui possono essere pubblicati i contenuti, rappresentati da oggetti di tipo Wall. L’oggetto può premette inoltre di ampliare l’insieme di elementi coinvolti nel processo partecipativo, prevedendo ulteriori destinazioni per i contenuti. L’interfaccia di base dell’oggetto è rappresentata in Figura 71.

Figura 71 - Struttura dell'oggetto ParticipatoryContext.

I criteri si differenziano inoltre per il tipo di operazione che svolgono sull’insieme di attori. In particolare distinguiamo due casi: quello in cui un criterio incrementa l’insieme di attori, introducendone di nuovi in base al criterio di competenza, e quello in cui effettua un’operazione di filtraggio sull’insieme preesistente, selezionando al suo interno gli attori che soddisfano particolari requisiti. Lo schema generale di funzionamento dei criteri è rappresentato in Figura 72: accedono alle informazioni dei contenuti tramite un’interfaccia specifica definita per il particolare criterio, e recuperano le informazioni associate dalla piattaforma sottostante. L’input dei criteri è rappresentato dall’insieme di attori precedentemente individuato, su cui il criterio applica un’operazione di ampliamento o di filtraggio per dare luogo all’insieme di output.


222

Figura 72 - Funzionamento generale dei criteri.

I criteri built-in previsti dalla piattaforma sono rappresentati dal LocationCriteria, che permette di individuare gli utenti che si trovano in prossimità di una determinata posizione geografica, il SocialCriteria, che permette di selezionare gli individui con relazioni sociali, il ProfileCriteria, che permette di selezionare attori sulla base delle informazioni di profilazione, e lo StateCriteria, che individua gli utenti che si trovano in un particolare stato. Per tutte le quattro tipologie di criteri sono previste le specializzazioni Source e Filter, che corrispondono rispettivamente all’aggiunta di nuovi elementi all’insieme, tramite ad esempio l’accesso al layer di persistenza, e al filtraggio degli attori già presenti precedentemente individuati. La struttura descritta è rappresentata in Figura 73. Ognuno dei diversi criteri può essere configurato con specifici parametri, come ad esempio il raggio di posizionamento per il LocationCriteria o il particolare stato richiesto agli utenti nel caso dello StateCriteria. È inoltre mostrato l’esempio del LocationSource, che accede al layer di persistenza attraverso il SensingDAO per recuperare gli attori che si trovano all’interno del raggio di ricerca dal luogo da cui è stato generato il contenuto.

Figura 73 - Diagramma della struttura dei criteri.

I contenuti built-in accedono alle informazioni presenti nei contenuti attraverso le proprietà fondamentali definite dall’interfaccia Content: il LocationCriteria, ad esempio, utilizza il metodo getLocation() che caratterizza l’interfaccia Content. Allo


223

stesso modo, il SocialCriteria e il ProfileCriteria fanno riferimento al metodo getUserid() che fornisce l’identità dell’utente che lo ha generato. In generale, per garantire la portabilità dei criteri definiti da un’applicazione, è buona norma parametrizzare il criterio rispetto ad una interfaccia piuttosto che alla specifica implementazione del contenuto. Ad esempio, se un’applicazione introduce un criterio per l’elaborazione delle immagini e vuole garantirne la portabilità, può definire l’interfaccia ImageProcessable che estende Content ed espone il metodo getImageURI() per recuperare l’URI dell’immagine associata. In questo modo il criterio è legato a una interfaccia sufficientemente generica, piuttosto che una particolare tipologia di contenuti. Inoltre, la parametrizzazione di T nel relativo criterio evita la necessità di effettuare cast espliciti all’interno del metodo apply() e migliora quindi la type-safety del codice.

5.4.2.1.2 - Catene di criteri

Nella sezione 5.2.1, in cui abbiamo descritto gli obiettivi e i requisiti che la piattaforma deve realizzare, è emerso come il processo partecipativo debba essere dotato di particolari caratteristiche di dinamicità e flessibilità di configurazione. L’insieme di criteri che deve essere utilizzato e l’ordine in cui sono applicati non differiscono solo in funzione dello scenario applicativo e della tipologia di contenuti, ma anche da condizioni che si verificano durante l’esecuzione della catena di criteri, e che richiedono l’applicazione di flussi di elaborazione differenti in funzione delle condizioni che si creano durante l’esecuzione. L’esito di elaborazione dei criteri precedenti può ad esempio determinare quali criteri devono essere applicati successivamente. Ciò richiede la definizione di opportuni strumenti che permettano di gestire questi elementi di dinamicità.

Innanzitutto, il processo partecipativo è realizzato tramite la composizione dei criteri in sequenze dette catene. Le catene rappresentano nell’insieme il processo partecipativo vero e proprio. Per realizzare questo tipo di struttura facciamo riferimento al pattern Chain-of-Responsibility (CoR), che permette di combinare tra loto singoli elementi formando sequenze arbitrarie di elaborazione. Per garantire la dinamicità necessaria introduciamo il concetto di nodi condizionali, che possono essere inseriti all’interno delle catene, e tramite cui è possibile indicare flussi di esecuzione alternativi che devono essere applicati in funzione di condizioni valutate a tempo di esecuzione. L’interfaccia ChainNode rappresenta il singolo nodo della catena e le due classi astratte CriteriaNode e ConditionalNode rappresentano rispettivamente un nodo contenente un criterio ed un nodo condizionale. Il primo incapsula al suo interno un criterio, che è applicato al contenuto quando il nodo è attivato. I ConditionalNode rappresentano invece i nodi condizionali della catena, che determinano sulla base di una condizione booleana flusso di elaborazione da seguire. In Figura 74 è rappresentata la struttura dei nodi della catena.


224

Figura 74 - Implementazione del pattern CoR.

Attraverso questa struttura è possibile quindi costruire la catena di criteri che da luogo al processo partecipativo, includendo elementi di dinamicità per determinare a tempo di esecuzione il flusso di elaborazione da applicare. In Figura 75 è illustrato un esempio di applicazione del modello proposto: se l’applicazione del criterio di localizzazione, utilizzato per recuperare gli utenti presenti in una determinata area, da luogo un insieme vuoto, allora provvediamo a recuperare gli utenti in base alla socialità prima di applicare un filtraggio sulla base dell’attività corrente. Un altro esempio di utilizzo dei nodi condizionali è quello che utilizza valori presenti all’interno dei contenuti per determinare il flusso da seguire.

Figura 75 - Esempio di uso dei nodi condizionali all'interno di una catena di criteri.

È necessario infine fornire al livello applicativo uno strumento semplice e flessibile per la definizione della struttura delle catene utilizzate. A questo scopo introduciamo l’interfaccia ParticipatoryChain, rappresentata in Figura 76, per rappresentare e incapsulare le catene. Implementando questa interfaccia l’applicazione può definire la struttura della catena partecipativa, ad esempio introducendo all’interno del costruttore il codice per la creazione e la composizione dei criteri. Attraverso i metodi setRoot() e getRoot() espone una proprietà che rappresenta la radice della catena. Inoltre, in modo analogo ai criteri, anche l’interfaccia ParticipatoryChain è parametrizzata rispetto al tipo generico T extends Content, che è restituito dal metodo getContentType().


225

Figura 76 - Interfaccia ParticipatoryChain.

Sebbene possa sembrare un’interfaccia poco utile, che non introduce nulla di nuovo, è in realtà molto importante per due aspetti: la possibilità di configurare le catene tramite file XML, e la riusabilità delle catene partecipative. Per quanto riguarda il primo aspetto, tramite il metodo setRoot(), permette l’utilizzo delle funzionalità di DI offerte dal container IoC di Spring per iniettare nelle sue implementazioni catene partecipative la cui struttura è definita all’interno dei file di configurazione del container IoC. Ciò permette quindi di raccogliere la struttura della catena all’interno di un file XML portabile da una applicazione Spring all’altra.

In secondo luogo, la parametrizzazione al tipo generico T permette l’associazione di una catena partecipativa alla tipologia di contenuto che è in grado di elaborare. A differenza del caso dei criteri, il generico T ha un significato diverso rispetto al caso dei criteri, individuando le proprietà del contenuto con una granularità maggiore. Mentre prima indicava la specifica interfaccia utilizzata dal criterio per l’accesso ai contenuti, in questo caso si intende una interfaccia che raccoglie tutte le proprietà che il contenuto deve avere per essere elaborato dalla catena in questione, ottenuta quindi estendendo le diverse interfacce cui fanno riferimento i singoli criteri che la compongono. In Figura 77 è rappresentata un esempio di utilizzo della parametrizzazione: i contenuti Audio e Photo sono utilizzati rispettivamente dai criteri AudioCriteria e PhotoCriteria. La catena ParticipatoryChain, che è formata dai criteri sopra citati, fa riferimento invece al tipo ImageAudioContent che raccoglie le due tipologie di contenuti precedenti.

Figura 77 - Esempio di parametrizzazione delle interfaccie Criteria e ParticipatoryChain.

In questo modo si garantisce la massima portabilità sia dei singoli criteri che delle catene partecipative. L’implementazione dell’interfaccia ParticipatoryChain permette inoltre di definire un insieme di parametri che rappresentano i parametri di


226

configurazione dei singoli criteri. In questo modo, agendo sulle proprietà della catena è possibile modificare i parametri dei singoli criteri.

5.4.2.1.3 - Gestione delle catene

Mentre la definizione delle catene rappresenta una responsabilità del livello applicativo, il livello di supporto si occupa della gestione delle catene e di recuperare le catene associate alle diverse tipologie di contenuto. A questo proposito sono definiti i componenti di supporto ChainManager e ChainFactory, per cui sono fornite inoltre alcune implementazioni di base.

Il componente ChainManager si occupa di gestire l’associazione tra i contenuti e le catene relative, permettendo di recuperare a partire da un contenuto la catena di elaborazione associata tramite il metodo getChain(). Il supporto fornisce una implementazione di base dell’interfaccia tramite la classe BaseChainFactory. Questa classe definisce al suo interno una lista di oggetti ParticipatoryChain, che rappresenta l’insieme di catene gestite dall’applicazione. Attraverso la configurazione di questo componente, quindi, l’applicazione può definire l’insieme di catene, e quindi l’insieme di contenuti, che sono gestite dall’applicazione. Tale lista può essere configurata tramite file XML e iniettata all’interno del componente con l’insieme delle catene previste. All’atto dell’invocazione del metodo getChain(), il chain manager si occupa quindi di recuperare le catene associate ai contenuti e restituirle al chiamante. L’applicazione può, in base alle necessità, estendere tale classe per personalizzarne i comportamenti, e ridefinirne il metodo getChain().

Sebbene la definizione e la configurazione delle catene tramite DI e file XML sia molto flessibile e portabile, non sempre è applicabile. Vi sono casi in cui le catene non sono trattate come bean Spring e non possono essere iniettate, ad esempio poiché devono essere istanziate sulla base dei contenuti attuali, utilizzando tecniche quali le chiusure per legare il comportamento dei criteri ai parametri del contenuto. In questi casi le catene non sono iniettate dal container e il ChainManager si occupa di richiederne la creazione di una istanza al componente ChainFactory. Questo componente si occupa quindi della creazione di istanze delle catene tramite reflection. Possiamo avere diverse implementazioni del componente ChainFactory in funzione della particolare strategia di creazione delle istanze. In particolare sono fornite le implementazioni SingletonChainFactory e PerRequestChainFactory. La prima fornisce sempre la stessa istanza singleton per un dato tipo di contenuto, che è quindi condivisa tra tutte le richieste. La strategia del PerRequestChainFactory consiste invece nella creazione di una nuova istanza ad ogni richiesta effettuata. In Figura 78 è rappresentata la struttura dei componenti descritti.

Figura 78 - Diagramma delle classi ChainManager e ChainFactory.


227

In Figura 79 è rappresentata l’interazione tra i componenti: quando è richiesta una catena per un certo tipo di contenuto, il ChainManager si occupa di recuperarla all’interno delle liste gestite e, nel caso non sia trovata all’interno della lista, si occupa di crearla tramite la ChainFactory.

Figura 79 - Diagramma di sequenza relativo al recupero delle catene.

Ancora una volta, tramite la configurazione del container IoC è possibile ottenere notevole flessibilità nella combinazione delle strategie applicative, selezionando la particolare implementazione di ChainFactory in base alla strategia desiderata o la specializzazione di BaseManager definita dall’applicazione.

5.4.2.1.4 - Attivazione del processo partecipativo

Per la realizzazione del meccanismo di attivazione del processo partecipativo dobbiamo tenere in considerazione due importanti requisiti. In primo luogo, vogliamo che sia possibile inserire il comportamento partecipativo in modo trasversale ad una molteplicità di servizi partecipativi. In uno scenario in cui una stessa applicazione fornisce diversi servizi di tipo partecipativo, l’esecuzione delle catene può essere considerata come una funzionalità trasversale che interessa molteplici componenti all’interno delle applicazioni. In secondo luogo, vogliamo che tale meccanismo sia trasparente ai componenti, attivandosi senza l’intervento esplicito dei componenti. Per questo motivo le catene sono attivate secondo uno schema di tipo aspect-oriented. Un aspetto detto ParticipatoryAspect si occupa di intercettare l’esecuzione dei metodi applicativi che individuano l’esecuzione di un servizio partecipativo, per attivare l’esecuzione della catena prima dell’esecuzione del componente che eroga il servizio stesso. Tale meccanismo è realizzato attraverso framework Spring AOP, in particolare sul supporto @AspectJ, descritto nella sezione 4.3.2.4, che permette la definizione degli aspetti in modo estremamente semplice tramite le annotazioni.

Il generico servizio partecipativo è rappresentato dall’interfaccia ParticipatoryService, che espone il metodo participate(). Gli argomenti del metodo sono costituiti dal contenuto che è reso oggetto del processo partecipativo, di tipo Content e dall’insieme di attori coinvolti. L’invocazione del metodo participate() è intercettata dall’aspetto ParticipatoryAspect che si occupa di applicare la catena di criteri al contenuto per determinare l’insieme di attori e di utenti coinvolto. La


228

struttura dei componenti descritti è rappresentata in Figura 80. L’aspetto ParticipatoryAspect è rappresentato secondo la sintassi AspectJ e definisce il pointcut participatoryPointcut in modo da intercettare l’esecuzione del metodo participate().

Figura 80 - Diagramma dei componenti ParticipatoryService e ParticipatoryAspect

L’aspetto è rappresentato da un semplice POJO annotato @Aspect. Il pointcut participatoryPointcut è rappresentato da un metodo omonimo etichettato con l’annotazione: @Pointcut("execution(Object ParticipatoryService.participate("+

" Participable,"

+"List<User>,"+

+"List<Actor>)"+

+"&& args(participable, users, actors)") ")

In accordo alla semantica AspectJ, l’uso del predicato args fa in modo che il container si occupi di iniettare gli argomenti del metodo participate() come parametri del pointcut. Infine, il metodo participatoryProcess() rappresenta l’advice che viene eseguito in corrispondenza del pointcut, e che riceve come parametri i parametri attuali del metodo participate. Si tratta di un before advice, che viene quindi invocato prima dell’esecuzione del metodo associato, ed è definito apponendo al metodo participatoryProcess() l’annotazione: @Before("participatePointcut(participable, users, actors)")

Il meccanismo descritto è riassunto in Figura 81: all’atto dell’invocazione del metodo participate() su un oggetto ParticipatoryService, l’advice participatoryProcess() intercetta l’invocazione individuata dal pointcut participatoryPointcut().

Figura 81 - Schema del meccanismo di attivazione dell'aspetto ParticipatoryAspect.


229

L’advice participatoryProcess() si occupa di recuperare dal ChainManager la catena di criteri associata al contenuto oggetto del metodo participate() per poi attivare l’esecuzione della catena, come rappresentato nel diagramma di sequenza in Figura 82.

Figura 82 - Diagramma di sequenza dell'attivazione dell'aspetto ParticipatoryAspect.

In questo modo è possibile attivare la catena di criteri per l’elaborazione dei contenuti all’interno del processo partecipativo in modo trasparente all’applicazione e fattorizzare il comportamento trasversale di applicazione della catena di criteri.

5.4.2.2 Activity Recognition La funzionalità di activity recognition fornisce alla piattaforma le informazioni

necessarie per attuare criteri di selezione basati su informazioni di stato degli utenti, come l’attività svolta correntemente, lo stato libero o occupato e così via.

In letteratura [MIL08] [WAN09] [LUP12] troviamo molti esempi di come le informazioni ricavate da accelerometro, microfono, e altri sensori del dispsitivo possano essere utilizzate per riconoscere l’attività degli utenti. In tutti i casi, il processo di activity recognition opera sulla base delle feature estratte dalle rilevazioni, piuttosto che sui dati grezzi. È possibile quindi per questo scopo utilizzare le feature estratte dai moduli presenti sul client. Sostanzialmente si segue un approccio strutturato secondo due fasi. Una prima fase si occupa di classificare le feature in base ad etichette dette primitive. Ad esempio, sulla base di media, varianza e numero di picchi dei dati rilevati dall’accelerometro, è possibile riconoscere se l’utente è in piedi, seduto, sta camminando o correndo. Ancora, a partire da media e varianza della Discrete Fourier Transform (DFT) dei dati rilevati dal microfono è possibile classificare il tipo di suoni dell’ambiente come silenzio, rumore, o voci umane. Le primitive rappresentano quindi etichette di basso livello elaborate a partire dalle feature relative ad un singolo sensore. Le primitive sono poi combinate tra loro, insieme a dati di contesto quali utenti gli utenti in prossimità o la permanenza in un particolare luogo, per dedurre informazioni più elaborate detti fatti. I fatti rappresentano il risultato finale del processo di activity recognition e costituiscono forme di classificazione di alto livello quali attività dell’utente, statistiche, luoghi significativi etc.

Le due fasi che costituiscono in processo di activity recognition sono svolte quindi da due diverse tipologie di componenti, detti classificatori. In particolare s’individuano rispettivamente i FeatureClassifier per l’elaborazione delle feature e il


230

PrimitiveClassifier per le primitive. I primi ricevono in input le feature specifiche di un sensore e calcolano la primitiva associata, i secondi invece elaborano i fatti a partire dalle primitive afferenti ad una molteplicità di sensori e dei dati di contesto. Fatti e primitive sono rappresentati rispettivamente da oggetti di tipo Fact e Primitive. I componenti descritti sono illustrati nel diagramma di Figura 83.

Figura 83 - Classificatori di feature e di primitive.

I FeatureClassifier si occupano di elaborare le feature ricevute dal client, rese persistenti dal SensingController, per elaborare le primitive. Questo tipo di componenti è quindi specifico per la tipologia di sensori a cui è associato. I PrimitiveClassifier invece operano sulla base delle primitive afferenti a sensori diversi, delle informazioni di geolocalizzazione, e dei dati di contesto per calcolare fatti. Sono possibili diverse tipologie di PrimitiveClassifier secondo la tipologia di fatti prodotti. Sono tipologie di fatti ad esempio l’attività corrente dell’utente e le informazioni di stato associate, oppure informazioni statistiche riassuntive dei dati recuperati dagli utenti. Le primitive e i fatti sono rappresentate da opportuni oggetti Primitive e Fact. Le primitive sono differenziate in funzione del tipo di sensore cui fanno riferimento. I fatti invece sono specializzati secondo il tipo di informazione rappresentata. In Figura 84 sono rappresentati i componenti coinvolti nel processo di activity recognition.

Figura 84 - Componenti che realizzano il processo di activity recognition.

Mentre i FeatureClassifier sono attivati direttamente dal FeatureController alla ricezione di nuove feature, i PrimitiveClassifier si attivano periodicamente per verificare la presenza di nuove informazioni da elaborare. Questi componenti prelevano quindi dal livello di persistenza le feature e le posizioni dell’utente mettendo in relazione tra loro le primitive relative ad uno stesso utente che appartengono ad un intervallo temporale ristretto e applicano algoritmi di classificazione e alberi


231

decisionali, che non sono oggetto di questa trattazione e non saranno pertanto affrontati in questa sede.

5.4.3 PersistenceLayer Il livello di persistenza è realizzato attraverso il pattern Database Access Object

(DAO), che prevede l’utilizzo di oggetti che incapsulano la logica di accesso ai supporti di persistenza garantendo maggiore disaccoppiamento e indipendenza dalla specifica tecnologia di persistenza.

Le funzionalità di accesso al livello di persistenza sono raggruppate all’interno di tre oggetti DAO, rappresentate in Figura 85: lo UserDao, il SensingDao e l’ActivityRecognitionDAO. Il primo gestisce le informazioni di profilazione relative agli utenti, il secondo le informazioni rilevate dai sensori provenienti dal client, ed infine il terzo gestisce le informazioni coinvolte nel processo di activity recognition. Tutte le interfacce espongono i metodi di accesso in lettura e scrittura degli oggetti utilizzati dagli altri componenti applicativi.

Figura 85 - Interfacce DAO per accesso al livello di persistenza.

Come possiamo notare, UserDao espone alcuni metodi che permettono di recuperare gli utenti basandosi su criteri quali la posizione o lo stato corrente. Questi metodi sono utilizzati dai criteri per selezionare gli utenti di interesse. Il SensingDao invece permette al SensingController di salvare le informazioni ricevute dal client e al FeatureClassifier di recuperarle. Infine l’ActivityRecognitionDAO permette ai componenti di tipo FeatureClassifier e PrimitiveClassifier di manipolare oggetti primitive e fatti.

Le implementazioni realizzate dei componenti DAO utilizzano il framework ORM Hibernate. In particolare mantengono un riferimento al componente di sistema SessionFactory da cui ottengono oggetti Session su cui effettuare le operazioni di persistenza. Tutti i componenti del modello del dominio, dagli oggetti SensorData e SensorFeature, agli oggetti User, UserState e Profile, alle primitive e ai fatti, presentano le annotazioni Hibernate opportune per gestire il mapping in tabelle relazionali.


232

5.5 - Conclusioni L’infrastruttura definita supporta quindi la realizzazione di servizi partecipativi

per dispositivi mobili attraverso un insieme di funzionalità distribuite tra client e server. Sul client troviamo un insieme di meccanismi di supporto per la rilevazione delle informazioni sensoriali e dei dati di contesto, che permettono di gestire in modo semplice e altamente configurabile i processi di sensing e di trasferimento delle informazioni sul server. Strategie quali Cycle Optimization e Low Battery Mode sono indirizzate a risolvere le criticità legate allo scenario dei dispositivi mobili, attraverso una gestione efficiente dei cicli di sensing e di trasferimento sul server in funzione delle risorse computazionali ed energetiche, ed ottimizzando l’uso dei provider di localizzazione. Il meccanismo degli Intent fornisce inoltre elevata flessibilità e ampie possibilità di configurazione e del sistema.

Sul server troviamo invece i componenti di gestione del processo partecipativo, orientati alla riusabilità dei criteri all’interno delle diverse catene partecipative e degli scenari applicativi. Attraverso il supporto alla Dependency Injection offerto da Spring è possibile definire la struttura delle catene file XML, e provvedere alla configurazione delle diverse politiche di gestione. L’utilizzo delle tecniche AOP e di AspectJ rende inoltre il processo partecipativo trasparente all’applicazione e trasversale ad una molteplicità di servizi. Il processo di activity recognition fornisce inoltre ai criteri importanti informazioni di stato sugli utenti.

Dopo aver realizzato la piattaforma, ci occuperemo ora di metterla alla prova realizzando un prototipo di servizio partecipativo. Vedremo che lo scenario applicativo farà ricorso a molte delle funzionalità di supporto e dei meccanismi offerti dalla piattaforma sia sul lato client che sull’infrastruttura di back-end, e permetterà inoltre di ottenere dei dati sperimentali sull’efficienza e sull’efficacia delle strategie implementate.

6 - Il caso di Emergency Alert

Nel capitolo precedente abbiamo realizzato una piattaforma per il supporto di servizi partecipativi per dispositivi mobili. In questo capitolo ci occuperemo quindi di costruire, sulla base di questa piattaforma, un servizio partecipativo che, appoggiandosi sulle funzionalità offerte da questa, permetta di convalidare le scelte progettuali. In particolare, il nostro obiettivo è da una parte verificare la validità del supporto allo sviluppo dell’applicazione, dall’altra quello di testare l’efficienza della soluzione. Piuttosto che indirizzare i nostri sforzi nella realizzazione di un servizio fittizio e fine a se stesso, ci impegneremo per dare uno stampo di autenticità e di concretezza ideando uno scenario applicativo verosimile e realizzando un servizio che possa poi essere realmente dispiegato, una volta completo, all’interno di scenari aziendali.

Nell’ambito della Smart City i concetti di partecipazione e coesione sociale tra i cittadini giocano un ruolo centrale, e come abbiamo visto nel capitolo 1 - rappresentano la base di fondamento di molti servizi di nuova generazione. Non solo l’interazione con la pubblica amministrazione, ma anche e soprattutto tra i cittadini stessi, secondo una dimensione collaborativa che incentiva il carattere “smart” degli individui all’interno della comunità. In questo senso le nuove tecnologie si pongono l’obiettivo di supportare e promuovere la partecipazione alla vita comunitaria e la cooperazione dei cittadini. Inoltre, questi servizi assumono ulteriore valore aggiunto se combinati con elementi quali socialità, geolocalizzazione, sensing e profilazione degli utenti, che abbiamo individuato nel capitolo precedente come fondanti per la nostra piattaforma, in quanto capaci di rendere particolarmente intelligenti le dinamiche di interazione tra i cittadini.

Uno degli scenari applicativi più comuni e più interessanti in accordo alle linee collaborative e partecipative descritte è rappresentato da quello di segnalazione delle situazioni di emergenza e di pericolo. Situazioni come malori lievi, piccoli traumi, o


234

altre difficoltà molto comuni dei cittadini possono trarre elevato beneficio dal supporto della comunità, sotto la condizione che siano forniti gli strumenti adatti a promuovere l’interazione e la cooperazione efficace ed efficace tra gli individui. Anche le criticità più gravi, che richiedono l’intervento delle autorità competenti, spesso possono beneficiare in modo considerevole di un intervento tempestivo da parte dei cittadini. A chiunque può essere capitato di trovarsi in una situazione di disagio e sentire la necessità di inviare una richiesta di aiuto tempestivamente e nel modo più semplice possibile, e ciò diventa ancora più vero per categorie deboli quali disabili o anziani. Facciamo riferimento ad esempio a malori, situazioni di pericolo, furti, ma anche disagi di minore entità, quali l’impossibilità di scendere degli scalini, barriere architettoniche e così via. In tutti questi casi può risultare di vitale importanza la presenza di un meccanismo di segnalazione che permetta di richiedere l’aiuto necessario da persone che si trovino nelle immediate vicinanze, oppure ai nostri familiari, o ancora alle autorità incaricate. Le nuove tecnologie, e in particolare i dispositivi mobili, assumono un ruolo fondamentale in quest’ambito.

Ci occuperemo quindi della realizzazione di un servizio di segnalazione, che chiameremo Emergency Alert, che si occupi di gestire richieste di soccorso di varia natura, provenienti dagli utenti, indirizzandole verso gli altri individui della comunità e verso le autorità. Il servizio sarà basato sulla piattaforma sviluppata nel capitolo precedente, e potrà beneficiare delle funzionalità di supporto fornite da questa. Procederemo quindi con la presentazione delle funzionalità desiderate per il servizio e poi con la descrizione della soluzione realizzata.

6.1 - Caratteristiche del servizio Il servizio Emergency Alert è, come abbiamo accennato, un servizio di

segnalazione di situazioni di pericolo che permette l’invio da parte degli utenti di richieste di soccorso in merito ad emergenze di vario genere. È destinato non solo a fasce di utenza svantaggiate, come anziani e portatori di handicap, ma in generale a tutta la comunità di cittadini. Le richieste di aiuto inviate dai cittadini sono correlate da una serie di informazioni di vario genere, che vanno dalla posizione geografica, che localizza la richiesta, a contenuti multimediali quali foto e registrazioni audio.

Il servizio prevede la possibilità per gli utenti di inviare richieste differenziate secondo il livello di allerta. Le richieste inviate dai dispositivi mobili sono raccolte dall’infrastruttura server che si occupa di pubblicarle e renderle disponibili agli altri utenti del sistema. Il grado di allerta associato determina la priorità e la qualità di servizio con cui la richiesta è gestita e il grado di disseminazione all’interno del sistema. Le richieste provenienti dai client, infatti, sono interpretate dal sistema come richieste di soccorso di diverso livello di priorità in base alla tipologia di richiesta e alle informazioni da cui è correlata. Alcune di esse ad esempio sono gestite come semplici segnalazioni e pubblicate su una bacheca virtuale, per essere visualizzata dagli altri utenti, altre invece che rappresentano vere richieste di soccorso sono notificate tempestivamente ai dispositivi mobili degli utenti che agiscono da soccorritori, secondo un modello di interazione di tipo “push”. Gli utenti cui notificare una richiesta di soccorso sono selezionati secondo diversi criteri, quali la posizione


235

geografica, l’attività corrente, il tipo di richiesta, le informazioni di sensing correlate, sia all’interno della rete sociale dell’utente che ha inviato la richiesta, e sia tra particolari classi di utenti classificati come soccorritori (es. volontari, medici, autorità competenti). Una volta notificata la richiesta ai soccorritori, questi sono messi in comunicazione tramite una sessione di chat multiutente in tempo reale al fine di coordinare i soccorsi.

In funzione del tipo di richiesta e dei contenuti dai quali è correlata, il sistema interpreta le richieste come emergenze di diverso genere e priorità, e determina quindi il relativo insieme di utenti destinatari cui deve essere notificata. Questo insieme dipende quindi sia dal livello di allerta della richiesta, selezionato dall’utente, sia dalle informazioni di sensing rilevate, nonché dal contesto dell’utente qual è ad esempio l’insieme degli utenti vicini. Quanto descritto è schematizzato in Figura 86.

Figura 86 – Schema di funzionamento del servizio Emergency Alert.

6.1.1 Tipi di Alert Gli Alert rappresentano le richieste inviate dagli utenti per segnalare le

situazioni di pericolo. Il servizio prevede 4 tipologie di Alert, in ordine di priorità decrescente: Red, Yellow, Green e Blue Alert, che individuano diversi livelli di allerta associati alla richiesta.

I Blue Alert rappresentano richieste con bassa priorità orientate alla segnalazione di disservizi, e per cui non vi è necessità di soccorso. Sono documentati spesso da foto e da un messaggio testuale e il sistema si incarica di determinare il tipo di disservizio (es. una barriera architettonica, dei fili elettrici scoperti) sulla base della documentazione presente. Le richieste di questo tipo sono destinate alla pubblicazione su bacheche virtuali per la raccolta da parte delle amministrazioni pubbliche. I Green Alert rappresentano come nel caso precedente segnalazioni di basso livello ma sono associate ad una richiesta di soccorso per situazioni a basso rischio per la salute, come ad esempio nel caso di un invalido che non riesce ad oltrepassare da solo una barriera architettonica e vorrebbe essere aiutato. Sono per questo notificate ad utenti presenti nella località che svolgano il ruolo di volontari per l’assistenza o a conoscenti che possono intervenire per aiutare l’utente. Oltre ad essere notificata agli utenti del sistema, può essere oggetto di pubblicazione su bacheche virtuali per la segnalazione dei disservizi, soprattutto nel caso in cui sia documentata da un’immagine fotografica. Gli Yellow Alert sono associati a richieste di aiuto con rischio intermedio, ad esempio


236

per malori lievi e piccoli traumi. Per questo tipo di richieste di soccorso può essere quindi sufficiente l’intervento da parte di utenti volontari all’interno della località, ma è necessario garantire, nel caso in cui questi ultimi non siano presenti, l’intervento di altre figure qualificate come ad esempio il medico di turno. Infine, i Red Alert rappresentano situazioni di massima emergenza, quale può essere un malore grave, un furto o un incendio, che richiedono l’intervento, oltre che degli utenti presenti nella località, anche l’intervento tempestivo delle autorità competenti. Il sistema deve quindi essere in grado di riconoscere il tipo di emergenza e inviare la richiesta verso l’autorità.

La Figura 87 riassume le diverse tipologie di Alert e le situazioni cui sono associate.

Figura 87 - Le diverse tipologie di Alert e i destinatari cui sono associati.

6.1.2 Sensing Il ruolo dei sensori non si esaurisce con la documentazione delle segnalazioni:

sensori come GPS, accelerometro e microfono permettono, infatti, di monitorare lo stato degli utenti per dedurne importanti informazioni riguardo l’attività corrente, e realizzare così diverse politiche di gestione.

Sui dispositivi degli utenti classificati come a rischio, sono attivate funzionalità per il monitoraggio dello stato dell’utente finalizzate all’invio automatico di richieste di soccorso. Ad esempio, la rilevazione di un urto tramite accelerometro scatena l’attivazione automatica del microfono; tramite quest’ultimo, la rilevazione di una voce con volume elevato è interpretata come un’invocazione di aiuto e dà luogo all’invio automatico di una richiesta di aiuto.

Nel caso degli utenti che agiscono da soccorritori, invece, le informazioni rilevate dai sensori sono utilizzate per il riconoscimento dell’attività dall’utente (es. camminando, in macchina, etc.). La conoscenza dell’attività e dello stato degli utenti fornisce importanti informazioni al sistema per la selezione dei soccorritori che sono maggiormente propensi a rispondere alla richiesta di aiuto al fine di fornire i soccorsi necessari.


237

In Figura 88 è riassunto il funzionamento complessivo del sistema: il server raccoglie da una parte i dati di sensing provenienti dagli utenti, dall’altra le richieste di soccorso rappresentate dagli Alert. Gli Alert ricevuti sono elaborati dal sistema per determinare i destinatari verso cui dirigerli, che possono andare dalle istituzioni, alle bacheche virtuali su cui sono pubblicate le segnalazioni, alla notifica tempestiva sui dispositivi mobili degli utenti soccorritori. Quest’ultimi, inoltre, sono messi in comunicazione tra loro attraverso una chat di gruppo che permette il coordinamento dei soccorsi.

Figura 88 - Schema del funzionamento del servizio Emergency Alert.

La forte componente di interazione non solo tra i cittadini e le autorità ma anche e soprattutto tra i cittadini stessi rendono EmergencyAlert uno strumento d’incentivazione della partecipazione dei cittadini alle dinamiche urbane e di promozione della collaborazione tra gli individui della comunità, che integra inoltre le tecniche del mobile sensing e della context-awareness per implementare funzionalità avanzate. Procediamo di seguito alla realizzazione del servizio.

6.2 - Implementazione L’implementazione del servizio è basata, come avevamo anticipato,

sull’infrastruttura di supporto sviluppata nel capitolo 5 - ed è strutturata, come mostrato in Figura 89, secondo un’architettura Client/Server. Il Client si appoggia sulle funzionalità di sensing offerte dall’infrastruttura, descritte nella sezione 5.3 - e rappresentate dal modulo Sensing Support, sia per la creazione dei contenuti che documentano gli Alert, sia per il monitoraggio dello stato dell’utente. Quest’ultimo contribuisce a fornire al server le informazioni di stato sugli utenti soccorritori e a supportare i meccanismi di generazione automatica degli Alert per gli utenti a rischio. A livello applicativo, distinguiamo le funzionalità utilizzate dagli utenti soccorritori, rappresentate dal modulo Alert Receiver per la ricezione degli Alert, e quelle utilizzate dagli utenti generatori degli Alert, contenute nel modulo Alert Sender. Vi sono infine


238

funzionalità comuni utilizzate da entrambi, rappresentate dal modulo Common, quali l’autenticazione degli utenti o la gestione della comunicazione di gruppo per il coordinamento dei soccorso. Quest’ultima funzionalità, che permette l’interazione tra i client, è basata sul protocollo Extensible Messaging and Presence Protocol (XMPP), di cui abbiamo discusso nella sezione 2.3.3, e la relativa rete di server di supporto.

Il server, invece, si occupa di ricevere ed elaborare le richieste provenienti dai client, per determinarne l’insieme di destinatari cui deve essere notificata. A questo proposito sfrutta il supporto dell’infrastruttura, rappresentato dal modulo Participatory Support, per la costruzione di catene differenziate secondo le diverse tipologie degli Alert, e le funzionalità di activity recognition attraverso i criteri di selezione basati sullo stato dell’utente. Una volta determinato l’insieme di utenti soccorritori coinvolto, la funzionalità di notifica delle richieste è implementata dal modulo di Alert Notification sfruttando il servizio Google Cloud Messaging for Android (GCM) [AND03], che permette l’invio di brevi messaggi di notifica diretti dal server verso i client Android, secondo un modello di interazione di tipo “push”. In modo analogo alla comunicazione delle informazioni di sensing, la comunicazione diretta tra client e server, utilizzata per l’invio degli Alert e per la trasmissione delle informazioni di sensing, è basata sul protocollo REST.

Figura 89 - Architettura generale del servizio Emergency Alert.

Procediamo di seguito ad analizzare singolarmente i moduli Client e Server dopo aver definito alcune strutture comuni ad entrambi.

6.2.1 Alert Introduciamo innanzitutto gli oggetti che rappresentano le segnalazioni,

costituiti dalla classe Alert, in quanto si tratta di entità fondamentali sia per il modulo client che per quello server. Si tratta di oggetti che implementano l’interfaccia Content, descritta nella sezione 5.4.2.1.1 -, e che definiscono l’insieme di proprietà che caratterizzano le segnalazioni: oltre all’identità del mittente e l’informazione di geo-localizzazione, contengono un breve messaggio testuale che può essere specificato dall’utente, e i riferimenti a immagini e registrazioni audio che la documentano. In


239

particolare, a questo proposito l’oggetto Alert conterrà solo i riferimenti a questi oggetti, così da poter essere utilizzato anche per la veicolazione delle informazioni tra client e server, che saranno quindi rappresentati dai timestamp associati alle rilevazioni. Altra informazione molto importante è rappresentata inoltre dall’indicazione della tipologia di Alert. Questa informazione è veicolata, oltre che da uno specifico campo che indica la costante, anche dalla particolare specializzazione della classe astratta Alert. Avremo quindi quattro diverse sottoclassi a rappresentare le diverse tipologie di Alert. Questa impostazione favorirà, oltre che una maggiore strutturazione del codice, anche la definizione delle catene partecipative da parte dei componenti di supporto, che come descritto nella sezione sono in grado di gestire catene differenziate secondo la particolare tipologia di contenuti cui sono associate. Di seguito è riportata quindi la struttura della classe Alert e delle sue specializzazioni in conformità alle considerazioni effettuate.

Figura 90 - Struttura degli oggetti di tipo Alert.

Vedremo nella sezione relativa al server ed al processo partecipativo, che sarà conveniente introdurre ulteriori interfacce all’interno di questa gerarchia per ottenere una migliore portabilità dei criteri e delle catene. Nel frattempo prenderemo questa definizione, che rimarrà valida anche in seguito, come riferimento.

6.2.2 Client Le funzionalità presenti sul client, la cui struttura è rappresentata in Figura 91,

possono essere suddivise principalmente in tre moduli: AlertSender per la generazione degli Alert, Alert Receiver per la ricezione, e Common per le funzionalità comuni di autenticazione e comunicazione di gruppo. I moduli si appoggiano sul modulo di Sensing offerto dall’infrastruttura di supporto. In particolare, troviamo i moduli di gestione dei seguenti sensori: localizzazione, per ottenere la posizione degli utenti, siano essi utenti soccorritori o i mittenti degli Alert; accelerometro e microfono, utilizzati sia per fornire al server le informazioni per attuare il processo di activity recognition, sia per innescare i meccanismi di generazione automatica degli Alert; fotocamera, che insieme al microfono può essere utilizzata per documentare le richieste di aiuto; infine tramite bluetooth e calendario dell’utente permettono di


240

ottenere informazioni di contesto sull’utente da utilizzare nel processo di activity recognition. A questo proposito precisiamo che il processo di activity recognition vero e proprio ha luogo sul server ed è utilizzato per selezionare gli utenti soccorritori più propensi a servire le richieste in base alla loro attività corrente.

Il modulo AlertSender contiene l’activity SendAlertActivity, fondamentale in quanto permette all’utente l’invio manuale degli Alert, e l’AlertTriggerService, che si occupa di gestire i meccanismi di generazione automatica degli Alert. Le funzionalità di invio vere e prorie, utilizzate da entrambi, sono raccolte dal SendAlertTask. Ricordiamo che, come abbiamo descritto nella sezione 3.2.2.3, un’activity rappresenta una singola schermata applicativa che si occupa di gestire l’interazione con l’utente. Il modulo AlertReceiver prevede invece il GCMIntentService, che permette di ricevere gli Alert inviati dal server attraverso il servizio GCM, e l’AlertMapActivity, tramite cui gli Alert ricevuti sono visualizzati all’utente. Il BootReceiver si occupa di avviare le funzionalità di sensing destinate all’activity recognition al boot del sistema. Infine, il modulo Common raccoglie funzionalità comuni sia per l’invio che per la ricezione degli Alert, e sono rappresentate dalla LoginActivity, che si occupa dell’autenticazione degli utenti, e della GroupChatActivity, che gestisce una chat di gruppo basata su protocollo XMPP.

Figura 91 - Struttura del client del servizio Emergency Alert.

Si noti che i moduli AlertSender e AlertReceiver sono tra loro indipendenti e come vedremo che utilizzano funzionalità di supporto differenti. L’applicazione client può infatti essere differenziata per gli utenti che agiscono come sorgenti delle richieste di soccorso per gli utenti che invece svolgono il ruolo di soccorritori. Vedremo come le due versioni richiedano un differente utilizzo del supporto, orientato nel primo caso alla generazione degli Alert e nel secondo alla raccolta delle informazioni di stato destinate all’activity recognition. Procediamo quindi ad analizzare i singoli moduli client, partendo innanzitutto dalla configurazione del supporto per poi esaminare i moduli di livello applicativo.

6.2.2.1 Supporto L’infrastruttura di supporto fornisce le funzionalità di rilevazione elaborazione

e trasmissione dei dati dai sensori. Come abbiamo visto nella sezione 5.3.9, è necessario configurare il supporto con i componenti necessari in base al processo di elaborazione dei dati sensoriali che vogliamo mettere in atto. Prima di tutto, è bene quindi chiarire il processo di elaborazione dei dati, alla luce degli quali obiettivi cui


241

sono destinati, per comprendere quali sono i componenti di supporto coinvolti e come devono interagire tra loro.

6.2.2.1.1 - Scenari

Il servizio Emergency Alert utilizza le funzionalità di supporto alla rilevazione fornite dall’infrastruttura con tre diversi scopi: la creazione degli Alert in modo esplicito da parte dell’utente, i meccanismi di generazione automatica degli Alert, ed infine la raccolta delle informazioni di stato destinate al processo di activity recognition. Mentre le prime due funzionalità hanno luogo sui dispositivi degli utenti che richiedono i soccorsi, la terza ha senso principalmente per gli utenti soccorritori in quanto l’activity recognition è coinvolta nel processo di selezione degli utenti. Vediamo quindi il processo di elaborazione che compete ad ognuno dei singoli obiettivi. A questo proposito rimandiamo al capitolo precedente per la definizione dei componenti di supporto e delle modalità di attivazione e interazione, descritte nella sezione 5.3.9.

Innanzitutto, il primo obiettivo è documentare le richieste di soccorso con rilevazioni scatenate dall’utente quali immagini o registrazioni audio, che indicheremo con il termine Scenario 1. In questo caso si tratta di rilevazioni esplicitamente richieste dall’utente stesso al momento dell’invio di un Alert, attraverso la SendAlertActivity. L’attuale versione di Emergency Alert fornisce la possibilità di documentare gli Alert con immagini e registrazioni audio, che sono quindi gestite dai componenti MicrophoneClient e CameraClient, responsabili della singola rilevazione rispettivamente tramite microfono e fotocamera. Questi componenti sono attivati direttamente dalla SendAlertActivity tramite l’invio dell’intent di attivazione opportuni. Una volta terminata la rilevazione, la SendAlertActivity deve quindi intercettare il completamento della rilevazione tramite l’intent relativo, per raccogliere la rilevazione e inviare l’Alert. A questo proposito è possibile sfruttare direttamente il supporto dell’UploadController per il trasferimento delle informazioni rilevate sul server: l’Alert contiene infatti, come abbiamo descritto nella sezione 6.2.1, solo un riferimento alla rilevazione, che sarà invece trasferita sul server dall’UploadController. Lo schema di interazione, riportato in Figura 92, prevede quindi l’attivazione da parte dell’applicazione dei SensorClient di interesse tramite intent di tipo ACTION_<SENSOR>_CLIENT. Una volta conclusasi la rilevazione da parte del componente, sia l’applicazione che l’UploadController ricevono l’evento di completamento e si occupano di inviare rispettivamente l’Alert e la rilevazione. A questo proposito, è bene precisare che non può essere utilizzato l’evento ACTION_<SENSOR>_DATA per l’attivazione dell’UploadController, poiché come vedremo in seguito il componente MicrophoneClient è utilizzato anche in altri processi di rilevazione, e ciò provocherebbe l’attivazione del componente anche quando non necessario, dando luogo al trasferimento sul server di tutte le misurazioni in modo indistinto. Per questo è necessario introdurre un intent specifico, che chiameremo ACTION_<SENSOR>_ALERT_DATA, per la realizzazione del processo di elaborazione. L’intent viene specificato come parametro all’atto dell’attivazione dei componenti SensorClient, e sarà utilizzato dai componenti al completamento della rilevazione.


242

Figura 92 - Interazione dei componenti di supporto per la creazione manuale di Alert.

Il secondo utilizzo dei componenti dell’infrastruttura di supporto, che chiameremo Scenario 2, prevede la generazione automatica degli Alert, attraverso il monitoraggio di specifici sensori per rilevare situazioni di pericolo. La funzionalità al momento supportata prevede il monitoraggio dell’accelerometro per rilevare urti e cadute degli utenti a rischio quali anziani. Nel caso in cui sia rilevato un urto si attiva quindi il microfono per rilevare un volume della voce elevato che è interpretato come una invocazione di aiuto. Queste funzionalità sono gestite dall’AlertTriggerService, che si occupa di individuare le situazioni di interesse e attivare quindi i comportamenti previsti. A questo proposito dobbiamo precisare che non è conveniente in questo caso utilizzare il componente AccelerometerClient per monitorare l’accelerometro, in quanto è necessario confrontare i singoli campioni consecutivi piuttosto che analizzare rilevazioni di lunga durata quali quelle fornite dal componente. Per questo motivo è più funzionale ricevere le singole rilevazioni provenienti dal SensorManager Android all’interno dell’AlertTrigger. Questo si occupa di analizzare la rilevazione per verificare la presenza dell’evento d’interesse, e attivare il MicrophoneClient quando necessario. I dati rilevati dal MicrophoneClient sono poi elaborati dal MicrophoneExtractor per l’estrazione delle feature, in quanto l’entità del volume vocale può essere verificato tramite il valor medio dello spettro del segnale. L’applicazione riceve quindi le feature per verificare il dal valor medio della rilevazione, e inviare l’Alert nel caso in cui questo superi una soglia prefissata. La sequenza di attivazione dei componenti, riportata in Figura 93, prevede in questo caso la ricezione degli eventi da parte del componente AlertTrigger, che sarà descritto in seguito, direttamente dal supporto Android. Nel caso sia rilevato un urto, il componente procede ad attivare i componenti MicrophoneClient e MicrophoneExtractor. Il risultato deve poi essere nuovamente notificato all’applicazione per verificare le feature estratte, dando luogo se necessario all’invio dell’Alert.

Figura 93 - Schema di interazione per la generazione automatica di Alert.


243

Il terzo obiettivo, o Scenario 3, per cui è utilizzato il supporto al sensing è fornire le informazioni necessarie al processo di activity recognition che ha luogo sul server, e che viene utilizzato dai criteri per selezionare i soccorritori in funzione dell’attività correntemente svolta. Per questa funzionalità sono utilizzati l’accelerometro e il microfono, effettuando sia la rilevazione tramite AccelerometerClient e MicrophoneClient, che l’estrazione delle feature tramite AccelerometerExtractor e MicrophoneExtractor. Utilizziamo inoltre i dati di contesto riguardanti gli utenti in prossimità, rilevati dal BluetoothClient, e degli eventi in programma nell’agenda dell’utente, estratti dal CalendarClient. Trattandosi di operazioni di sensing continuativo, sono coinvolti inoltre il SensingController ed il ContextController, mentre l’UploadController gestisce l’invio delle informazioni sul server. Il SensingController e l’UploadController sono attivati automaticamente all’avvio del sistema. Lo schema d’interazione risultante è rappresentato in Figura 94.

Figura 94 - Schema di interazione per le operazioni di activity recognition.

Infine, tutti i processi di elaborazione descritti sono accomunati dall’utilizzo della posizione geografica dell’utente: per quanto riguarda gli scenari 1 e 2, relativi quindi l’AlertSender, vedremo che per ovvie ragioni il LocationClient è attivato direttamente all’avvio dell’applicazione per garantire la presenza di una misurazione di posizione sufficientemente precisa nel momento di invio dell’Alert. A questo proposito, al fine di garantire l’aggiornamento continuo della posizione, e di attuare al tempo stesso le politiche di ottimizzazione CO e LBM (sezione 5.3.7), utilizziamo per la configurazione Alert Sender anche il SensingController, che in questo caso darà luogo esclusivamente all’attivazione del LocationClient (ciò è possibile escludendo gli altri SensorClient dalla ricezione dell’evento SENSOR_CLIENTS). Anche in questo caso inoltre è possibile sfruttare il supporto dell’UplaodController per il trasferimento verso il server delle rilevazioni di posizione. In questo modo non è necessario preoccuparsi di inserire esplicitamente nell’Alert l’informazione di posizione. L’unico accorgimento è quindi quello di includere l’intent LOCATION_DATA tra quelli che causano l’attivazione dell’UploadController, e che il LocationClient si occupa di generare al completamento di ogni rilevazione. Per il modulo Alert Receiver invece, vedremo che sarà attivato al boot del sistema contestualmente agli altri SensorClient.

Sulla base di queste considerazioni, è quindi possibile derivare l’insieme di componenti di supporto coinvolti e la loro configurazione in merito agli intent che devono provocarne l’attivazione.


244

6.2.2.1.2 - Configurazione

Per sinteticità della trattazione, riporteremo in una tabella le informazioni riassuntive della configurazione dei componenti di supporto. In questa sezione ci limiteremo ad esplicitare la configurazione esclusivamente dei componenti di supporto, in quanto non tutti i componenti applicativi utilizzano una configurazione dichiarativa degli intent. Alcuni componenti richiedono infatti la registrazione dinamica dei broadcast receiver e la configurazione sarà quindi valutata caso per caso nelle sezioni di competenza.

Come abbiamo visto, mentre gli scenari di utilizzo di generazione manuale (Scenario 1) e automatica (Scenario 2) degli intent competono al modulo Alert Sender per l’invio degli Alert, lo Scenario 3, di monitoraggio delle attività, è competente al modulo Alert Receiver. È ragionevole prevedere la possibilità per gli utenti di agire esclusivamente da soccorritori o da mittenti degli Alert, anche se non si esclude la possibilità che un utente rivesta entrambi i ruoli. Indicheremo quindi separatamente le due configurazioni, Alert Sender nel caso degli Scenari 1 e 2, Alert Receiver nel caso dello scenario 3, dato che è opportuno attivare solo le funzionalità strettamente necessarie in funzione dello specifico ruolo impersonato dall’utente dell’applicazione. Le due configurazioni potranno in ogni caso essere unite mettendo in atto tutti gli scenari descritti, nel caso in cui l’utente agisca sia da generatore di Alert sia da soccorritore.

La Tabella 3 riassume i componenti di supporto utilizzati dalla configurazione Alert Sender. Ogni riga della tabella corrisponde alla definizione di un componente di supporto nel file di configurazione, che ricordiamo è costituita dalla coppia di elementi <service/>, che definisce il service Android che rappresenta il componente, e <receiver/>, che definisce il broadcast receiver associato e quindi gli eventi cui il componente è sensibile.

Componente Attivato da (proveniente da)

Genera (diretto a)

Camera Client CAMERA_CLIENT (SendAlertActivity)

CAMERA_DATA (SendAlertActivity)

Microphone Client MICROPHONE_CLIENT (SendAlertActivity, AlertTriggerService)

MICROPHONE_DATA (MicrophoneExtractor) (*)

Sensing Controller SENSING_START (AlertSender)

SENSOR_CLIENTS (LocationClients)

Location Client SENSOR_CLIENTS (SensingController)

LOCATION_DATA (AlertSender)

Microphone Extractor

MICROPHONE_DATA (MicrophoneClient)

MICROPHONE_FEATURES (AlertTriggerService) (**)

Upload Controller MICROPHONE_DATA (MicrophoneClient) (*) MICROPHONE_ALERT_DATA (MicrophoneClient)

-


245

CAMERA_ALERT_DATA (CameraClient) LOCATION_DATA (LocationClient)

Tabella 3 - Configurazione del supporto per il modulo AlertReceiver.

In Tabella 4 è invece mostrato lo schema di configurazione nel caso del modulo AlertReceiver, relativo cioè allo Scenario 3.

Componente Attivato da (proveniente da)

Genera (diretto a)

Sensing Controller SENSOR_START (BootReceiver)

SENSOR_CLIENTS (MicrophoneClient, AccelerometerClient, LocationClient)

Context Controller CONTEXT_START (BootReceiver)

CONTEXT_CLIENTS (BluetoothClient, CalendarClient)

Microphone Client SENSOR_CLIENTS (SensingController)

MICROPHONE_DATA (MicrophoneExtractor)

Accelerometer Client SENSOR_CLIENTS (SensingController)

ACCELEROMETER_DATA (AccelerometerExtractor)

Location Client SENSOR_CLIENTS (SensingController)

LOCATION_DATA (UploadController)

Bluetooth Client CONTEXT_CLIENTS (SensingController)

BLUETOOTH_DATA (UploadController)

Calendar Client CONTEXT_CLIENTS (SensingController)

ContextController

Accelerometer Extractor

ACCELEROMETER_DATA (AccelerometerClient)

ACCELEROMETER_ FEATURES (UploadController)

Microphone Extractor

MICROPHONE_DATA (MicrophoneClient) (*)

MICROPHONE_FEATURES (UploadController)

Upload Controller ACCELEROMETER_FEATURES (AccelerometerExtractor) MICROPHONE_FEATURES (MicrophoneExtractor) (**) CALENDAR_DATA (CalendarClient) BLUETOOTH_DATA (BluetoothClient) LOCATION_DATA (LocationClient)

-

Tabella 4 - Configurazione del supporto per il modulo AlertReceiver.

Dalle tabelle e dagli schemi di interazione precedenti emergono due potenziali sovrapposizioni negli intent di attivazione: il primo, che coinvolge tutti i 3 scenari,


246

individuabile nelle tabelle dal simbolo (*), deriva dal fatto che l’UploadController è utilizzato nello Scenario 1 per l’invio delle rilevazioni provenienti dal microfono. A questo proposito, se fosse utilizzato l’intent MICROPHONE_DATA per l’attivazione dell’UploadController, vi sarebbe un conflitto con gli intent dello stesso tipo generati negli scenari 2 e 3, provocando il trasferimento di ogni rilevazione del microfono sul server. L’uso di un intent specifico, il MICROPHONE_ALERT_DATA permette quindi di evitare questo fenomeno indesiderato. L’altro caso di sovrapposizione (**) è analogo al precedente ma fa riferimento al componente MicrophoneExtractor nello Scenario 2, in cui la generazione dell’intent MICROPHONE_FEATURES comporta nello Scenario 3 l’attivazione dell’UploadController. Si tratta quindi di un fenomeno che si verifica solo nel caso in cui siano utilizzate contemporaneamente entrambe le configurazioni, e comporta l’overhead minimo del trasferimento sporadico sul server di un oggetto SensorFeature. Per questo motivo non utilizziamo un intent specifico come nel caso di sovrapposizione precedente, in cui l’overhead generato era invece considerevole.

Un'altra operazione necessaria è la scelta dei parametri di configurazione del supporto. In particolare si tratta dei periodi di rilevazione utilizzati dalle tecniche Cycle Optimization e Low Battery Mode, per cui si rimanda alla sezione 5.3.7, nonché dei parametri che regolano la frequenza di rilevazione nel LocationClient. La scelta di questi parametri è stata effettuata sulla base di opportuni processi di tuning indirizzati ad ottenere un bilanciamento ottimale tra la frequenza di rilevazione e aggiornamento dei dati e l’impatto energetico e computazionale generato dall’applicazione. Maggiori informazioni su sui parametri utilizzati saranno date nella sezione 6.3.1, relativa ai risultati sperimentali.

6.2.2.1.3 - Considerazioni

Dalla sezione precedente emerge in modo lampante la semplicità con cui è stato possibile realizzare gli scenari applicativi di rilevazione e di elaborazione. L’unico onere dello sviluppatore consiste nella definizione della configurazione dell’applicazione, che ricordiamo ha luogo tramite un file XML che funge da manifest per l’applicazione. Tramite la configurazione lo sviluppatore specifica i componenti utilizzati ed il modo in cui devono essere combinati tra loro. Il meccanismo degli intent permette inoltre di innescare l’attivazione dei componenti applicativi in base agli eventi di interesse, come vedremo nelle sezioni successive. Oltre alla definizione dei componenti necessari, è responsabilità dello sviluppatore individuare potenziali conflitti nel meccanismo degli intent, al fine di individuare ed evitare situazioni indesiderate di attivazione dei componenti.

Procediamo ora ad analizzare i componenti di livello applicativo.

6.2.2.2 Alert Sender Il modulo Alert Sender si occupa delle funzionalità necessarie all’invio degli

alert ed è legato come abbiamo visto agli scenari di creazione manuale o di generazione automatica degli Alert. In particolare la SendAlertActivity incapsula l’interfaccia utente per la generazione automatica, mentre il componente AlertTriggerService gestisce la funzionalità di generazione automatica. Entrambi


247

utilizzano il SendAlertTask per gestire l’operazione di invio dell’Alert in modo asincrono.

Facendo riferimento allo scenario di segnalazione delle emergenze in cui l’applicazione Emergency Alert si colloca, una delle informazioni più importanti che caratterizza una segnalazione è la posizione geografica. Senza di questa, non è possibile individuare il punto da cui l’Alert è stato originato, e diventa estremamente difficile attuare le operazioni di soccorso. Per questo motivo il modulo Alert Sender pone particolare attenzione alla rilevazione della posizione dell’utente, al fine di garantire la disponibilità dell’informazione di posizione nel momento in cui l’utente voglia inviare un Alert. In particolare, contestualmente all’inizializzazione dell’applicazione è automaticamente avviato il componente SensingController e quindi anche il LocationClient. In questo modo ha inizio il processo di recupero della posizione dell’utente mirato a fornire l’informazione di posizione all’atto dell’invio di un Alert, secondo lo schema consigliato nell’utilizzo della localizzazione che abbiamo discusso nella sezione 3.2.3.1.3 -. Il componente rimane in esecuzione durante tutto il tempo di vita dell’applicazione, beneficiando delle strategie di ottimizzazione realizzate sia dal componente stesso sia dal SensingController.

Le posizioni recuperate dal LocationClient sono sia inviate sul server da parte dell’UploadController, come descritto nella sezione relativa agli scenari, e sia utilizzate dai componenti SendAlertActivity e AlertTriggerService per l’operazione di invio degli Alert. Procediamo quindi ad analizzare i singoli componenti.

6.2.2.2.1 - SendAlertActivity

Rappresenta la schermata principale del modulo AlertSender, in quanto consente all’utente di inviare un Alert tramite un’interfaccia grafica semplice e intuitiva, come mostrato dallo screenshot in Figura 95. In particolare si distinguono quattro pulsanti la cui pressione scatena l’invio di un Alert. L’interfaccia è appositamente pensata per facilitare le operazioni di invio in situazioni critiche, attraverso pulsanti di grandi dimensioni che evidenziano attraverso il colore la tipologia di Alert da inviare. In particolare, il tasto “3” di colore blu permette l’invio di un Blue Alert, il tasto “2” di colore verde genera un Green Alert, mentre “1” e “0” di colore rispettivamente arancione e rosso causano l’invio di un Yellow Alert e di un Red Alert. Tramite il tasto “More” è inoltre possibile corredare l’Alert di ulteriori informazioni quali messaggi testuali, campioni audio registrati attraverso il microfono, o immagini scattate attraverso la fotocamera. Queste funzionalità di accesso ai componenti di supporto fanno riferimento allo Scenario 1 illustrato nella sezione 6.2.2.1.1 -.


248

Figura 95 - Screenshot di EmergencyAlertActivity.

Per effettuare le rilevazioni su accelerometro e microfono l’activity fa riferimento ai relativi componenti MicrophoneClient e CameraClient, come descritto nello Scenario 1. In particolare invia un intent rispettivamente di tipo MICROPHONE_CLIENT e CAMERA_CLIENT, e contestualmente registra un broadcast receiver per la ricezione degli eventi di completamento della rilevazione. In conformità a quanto descritto nello scenario, sono utilizzati gli intent MICROPHONE_ALERT_DATA e CAMERA_ALERT_DATA, specificati come parametro nell’intent stesso del componente SensorClient. Alla ricezione dell’evento di completamento l’activity si occupa di memorizzare gli identificativi delle rilevazioni, per inserirle all’interno dell’oggetto Alert al momento dell’invio. La Figura 96 riassume lo schema d’interazione descritto nel caso dell’utilizzo del MicrophoneClient per effettuare una rilevazione audio.

Figura 96 - Schema di interazione per la rilevazione di informazioni da corredare all'Alert.

Alla pressione di uno dei pulsanti di invio degli Alert descritti precedentemente, l’Activity si occupa di recuperare le informazioni immesse dall’utente per costruire un oggetto Alert con la stessa struttura descritta nella sezione 6.2.1. L’oggetto contiene quindi l’identificativo dell’utente, l’indicazione dell’istante temporale in cui è stato generato, il livello di emergenza rappresentato implicitamente dal tipo dell’oggetto, e, nel caso in cui siano stati specificati dall’utente, il messaggio testuale e gli identificati delle immagini e delle sequenze audio associate. Ricordiamo che l’Alert contiene al


249

suo interno solo l’identificativo delle immagini e delle registrazioni associate, in quanto come previsto dallo Scenario 2 queste informazioni sono inviate automaticamente dall’UplaodController. Lo stesso approccio è utilizzato anche nel caso della posizione dell’utente, questa volta in modo ancora più implicito, in quanto non è necessaria l’indicazione dell’identificativo della rilevazione: è l’ultima rilevazione effettuata quella da prendere in considerazione. Per l’invio dell’Alert l’activity attiva quindi il SendAlertTask che sarà descritto in seguito nella sezione relativa e che permette l’invio asincrono dell’Alert.

6.2.2.2.2 - AlertTriggerService

L’AlertTriggerService è un componente di tipo Android service che esegue in background e si occupa della generazione automatica degli Alert, facendo riferimento allo Scenario 2 descritto nella sezione 6.2.2.1.1 -. In particolare vuole rilevare gli urti del dispositivo per attivare conseguentemente il microfono e rilevare eventuali invocazioni di aiuto dell’utente. Per realizzare questo comportamento è necessario rilevare bruschi cambiamenti nelle misurazioni dell’accelerazione, confrontando tra loro campioni contigui provenienti dall’accelerometro. Per questo motivo non è indicato utilizzare l’AccelerometerClient, che è invece concepito per effettuare rilevazioni di durata più ampia. Fa riferimento invece direttamente all’interfaccia SensorManager offerta dalla piattaforma Android, da cui riceve i singoli aggiornamenti dell’accelerometro. In seguito alla rilevazione di un urto, provvede ad attivare il MicrophoneClient per effettuare una rilevazione audio e valutare l’entità del volume sonoro attraverso le feature estratte da MicrophoneExtractor.

In particolare, per la rilevazione degli urti confronta la variazione di accelerazione, ottenuta come differenza tra la rilevazione attuale e quella precedente, con una soglia ACC_THRESHOLD. Se la variazione supera la soglia, interpreta l’evento come un urto ed invia un intent MICROPHONE_CLIENT per la rilevazione del campione audio. Contestualmente registra programmaticamente un broadcast receiver per la ricezione dell’evento MICROPHONE_FEATURES da parte del MicrophoneExtractor. Come descritto nella sezione 6.2.2.1.2 -, il supporto è configurato per attivare automaticamente il MicrophoneExtractor in seguito al completamento della rilevazione da parte del MicrophoneClient. Completata l’estrazione delle feature, l’AlertTriggerService è quindi attivato di conseguenza per elaborare i dati ricevuti. In particolare confronta il valore medio contenuto nelle feature (che ricordiamo rappresenta il valor medio dell’ampiezza della DFT della rilevazione) con una soglia MIC_THRESHOLD per individuare un valore di voce elevato. In questo senso un possibile miglioramento è rappresentato dall’estensione del FeatureExtractor al fine di calcolare anche l’ampiezza di banda dello spettro, tramite cui è possibile distinguere una voce umana (con uno spettro concentrato tra i 100Hz e i 1500Hz) dal semplice rumore. Nel caso in cui il campione superi la soglia, il componente si occupa di attivare il componente SendAlertTask per effettuare l’invio dell’Alert. Lo schema di funzionamento descritto è riassunto in Figura 97.


250

Figura 97 - Schema di funzionamento del componente AlertTriggerService.

6.2.2.2.3 - SendAlertTask

Il SendAlertTask è un componente Android di tipo AsyncTask che si occupa dell’invio degli Alert sul server. Come descritto nella sezione 3.2.2.7.2 -, gli AsyncTask sono concepiti per l’esecuzione di operazioni di breve durata in modo asincrono, al fine di non bloccare il main thread dell’applicazione associato all’interfaccia grafica. Nel nostro caso incapsula la logica di invio degli Alert permettendone l’utilizzo da parte sia dall’AlertTriggerService, sia dalla SendAlertActivity.

Fa uso delle API Spring for Android per l’invio di messaggi HTTP il cui contenuto è espresso in formato JSON, in accordo quindi al paradigma REST. In particolare gli Alert sono inviati all’interno di messaggi di tipo POST. Analogamente a quanto avviene per l’UploadController e il trasferimento delle rilevazioni, descritte nella sezione , il mapping degli oggetti Java di tipo Alert nei corrispondenti messaggi in formato JSON è eseguito automaticamente dal supporto Spring for Android attraverso la libreria Jackson 2. Il componente riceve dal server un messaggio di risposta contenente un numero intero che rappresenta il numero di utenti a cui è stato notificato l’Alert. Questo messaggio viene visualizzato a video attraverso un messaggio pop-up che appare sullo schermo indipendentemente dall’activity correntemente visualizzata. Ad esempio, nel caso in cui l’utente abbia inviato l’Alert attraverso la SendAlertActivity e questa sia ancora visualizzata dall’utente è mostrato il messaggio riportato in Figura 98.


251

Figura 98 - Messaggio che mostra il risultato di invio dell'Alert.

Alla ricezione della risposta il componente si occupa inoltre di attivare la GroupChatActivity, che sarà descritta in seguito e che gestisce la comunicazione di gruppo tra gli utenti cui è stato notificato l’Alert.

6.2.2.3 Alert Receiver Il modulo Alert Receiver raccoglie le funzionalità necessarie per la ricezione e

la visualizzazione degli Alert, destinate quindi agli utenti che agiscono da soccorritori. In particolare troviamo il GCMIntentService che permette la ricezione degli Alert tramite il servizio GCM, l’AlertMapActivity, che mostra gli Alert ricevuti su una mappa, e il BootReceiver responsabile dell’attivazione delle funzionalità di monitoraggio all’avvio del sistema.

6.2.2.3.1 - GCMIntentService

Il componente GCMIntentService rappresenta un Android Service previsto dal meccanismo Google Cloud Messaging (GCM) che ha lo scopo di gestire le notifiche provenienti dal server. Oltre alla notifica degli Alert, gestisce anche altri tipi di eventi rilevanti all’interno del sistema GCM, quali registrazione e cancellazione del singolo client al servizio. Infatti, affinché il server possa inviare notifiche verso i dispositivi client, questi devono essere registrati presso il servizio GCM. L’operazione di registrazione al servizio deve essere effettuata una sola volta per un dato dispositivo, e rimane valida anche in seguito al riavvio dell’applicazione e del dispositivo. All’atto della registrazione al servizio GCM è fornito un identificativo univoco, sotto forma di stringa, che deve essere comunicato al server dell’applicazione, in quanto sarà utilizzato da quest’ultimo per l’invio di messaggi verso il dispositivo in questione. L’operazione di registrazione è effettuata al primo avvio dell’applicazione all’atto dell’autenticazione dell’utente tramite la LoginActivity, che sarà descritta in seguito.

Per quanto riguarda il componente GCMIntentService, la sua funzionalità principale consiste nel gestire i messaggi provenienti dal server contenenti gli Alert, tramite il metodo di callback onMessage(), che è automaticamente invocato all’atto della ricezione di un messaggio tramite il servizio GCM. L’intent passato come parametro contiene le informazioni presenti nel messaggio, costituite dalle


252

informazioni dell’Alert stesso nel nostro caso. Il servizio GCM pone il limite di 4 KB ai messaggi inviati dal server al client per motivi di efficienza. Data la dimensione limitata delle informazioni contenute all’interno dell’Alert si è scelto di inserirle direttamente all’interno del messaggio GCM. In futuro, nel caso in cui l’Alert sarà corredato da informazioni che richiedono un payload maggiore, come ad esempio immagini, si potrà includere nel messaggio un riferimento che il client utilizzerà per recuperare la risorsa dal server. All’interno del metodo onMessage() gli Alert ricevuti sono gestiti mostrando una notifica nella status bar Android (1), come mostrato in Figura 99, e emettendo un segnale sonoro per avvertire l’utente. Aprendo il menù a tendina delle notifiche è possibile visualizzare maggiori informazioni sull’Alert (2) e accedere alla mappa.

Figura 99 - Screenshot relativa alla notifica di un Alert

Alla pressione del messaggio associato alla notifica (2) viene lanciata l’Activity AlertMapActivity per visualizzare l’Alert sulla mappa.

6.2.2.3.2 - AlertMapActivity

Il componente AlertMapActivity permette all’utente che agisce da Alert Receiver di visualizzare gli Alert ricevuti localizzandoli sulla mappa. L’Activity mostra all’utente una mappa in cui è indicata un’icona segnaposto in corrispondenza della posizione geografica di ognuno degli Alert ricevuti. Le icone visualizzate sono di colore differente in funzione del livello di allerta associato: rosse, gialle, verdi o blu rispettivamente per gli Alert Level Red, Green, Yellow e Blue. La mappa permette tramite le funzionalità built-in previste dalla view MapView di zoomare e spostare l’area da visualizzare. È inoltre visualizzata la posizione del dispositivo corrente, così da informare l’utente, presumibilmente un soccorritore, della sua posizione rispetto alle richieste pervenute. Cliccando sulle icone degli Alert è inoltre possibile visualizzarne i dettagli: il mittente, il livello di allerta, il messaggio testuale se presente. In Figura 100 sono riportati due screenshot ottenuti in seguito ad un test dell’applicazione, in cui è visualizzata la mappa degli Alert ricevuti (in particolare un Red Alert, due Yellow Alert e un Green Alert) e il dettaglio delle informazioni riguardanti uno Yellow Alert.


253

Figura 100 - Screenshot di AlertMapActivity per (a) la visualizzazione degli Alert sulla mappa e (b) dei dettagli associati ad

un Alert in particolare.

Infine, cliccando sull’etichetta associata a un Alert, come quella mostrata in Figura 100 (b) è possibile avviare una sessione di comunicazione di gruppo in tempo reale che coinvolge il mittente dell’Alert e gli altri Alert Receiver, gestita dall’activity AlertChatActivity.

6.2.2.3.3 - BootReceiver

Il BootReceiver è un componente di tipo broadcast receiver che si occupa di ricevere l’evento di avvio del sistema. È quindi utilizzato per avviare le funzionalità di monitoraggio dello stato dell’utente del modulo Alert Receiver, che sono cioè destinate a raccogliere le informazioni necessarie per il processo di activity recognition.

Per intercettare l’evento di avvio del sistema deve essere opportunamente configurato nel file manifest dell’applicazione, specificando tra gli intent di attivazione l’action BOOT_COMPLETED, come descritto in 3.2.2.6.

All’interno del metodo onReceive() per la gestione dell’intent, il componente provvede ad inviare un intent di tipo SENSING_START al SensingController e al ContextController, avviando così le operazioni di monitoraggio descritte nello Scenario 3 della sezione 6.2.2.1.1 -.

6.2.2.4 Common Il modulo Common raccoglie funzionalità che sono comuni sia al modulo Alert

Sender che al modulo Alert Receiver, rappresentate in particolare dalla GroupChatActivity, che si occupa di gestire la comunicazione di gruppo di coordinamento dei soccorsi attivata in seguito alla notifica di un Alert, e la LoginActivity responsabile dell’autenticazione dell’utente all’avvio dell’applicazione.


254

6.2.2.4.1 - AlertChatActivity

Questo componente gestisce una comunicazione di gruppo in tempo reale tra tutti gli utenti coinvolti nella distribuzione dell’Alert, cioè l’AlertSender e tutti gli AlertListeners che ricevono l’Alert, dando la possibilità ad ognuno dei partecipanti di inviare messaggi testuali e visualizzare la cronologia di conversazione. Tale funzionalità è implementata sfruttando il protocollo Extensible Messaging and Presence Protocol (XMPP), descritto nella sezione 2.3.3 e noto anche come Jabber, protocollo di messaggistica istantanea e di presenza ritenuto particolarmente adatto al caso di studio in questione sia per la sua interoperabilità con la maggior parte dei social network e sia per la facilità di gestione di sessioni di comunicazione di gruppo.

A questo proposito è necessario specificare che sono stati riscontrati alcuni problemi d’integrazione con il social network Facebook, i quanto i server XMPP di questo social network non sono federati con la rete di server XMPP e creano invece un dominio separato. Di conseguenza non è possibile la comunicazione tra il dominio costituito dalla rete XMPP standard e quello formato dai server XMPP Facebook: un utente che fa riferimento alla prima non può comunicare con un utente Facebook e viceversa. Di conseguenza, se un utente utilizza un account Facebook per accedere il servizio di chat, sarà in grado di comunicare solo con utenti che usano un account Facebook.

Quando la sessione di gruppo deve essere avviata, il primo utente che tenta di accedervi, non importa se AlertSender o AlertListener, crea la sessione, o meglio quella che nella terminologia Jabber viene chiamata “stanza”, utilizzando un identificativo univoco formato a partire dall’identificativo dell’AlertSender e del timestamp associato all’Alert. Una volta creata, gli altri utenti possono accedere alla stanza e scambiarsi messaggi in multicast.

6.2.2.4.2 - LoginActivity

Permette di effettuare il login all’applicazione, inserendo le credenziali costituite dalla coppia username e password. Dato che la comunicazione tra client e server è gestita tramite protocollo REST, il server non memorizza alcuna informazione di sessione e tutte le richieste provenienti dal client richiedono autenticazione. Per questo motivo le credenziali dell’utente sono conservate nella memoria privata dell’applicazione per essere inviate a ogni richiesta. È evidente che per evitare la compromissione delle credenziali è necessario, in uno scenario reale, utilizzare una connessione cifrata, come SSL/HTTPS. Inoltre, per evitare la memorizzazione delle credenziali dell’utente sul client, è possibile ricorrere all’utilizzo del protocollo di autorizzazione OAuth 2.0. Il protocollo, infatti, richiede l’invio delle credenziali solo una prima volta al fine di ottenere un access token, che sostituisce le credenziali di autenticazione presso il server nelle richieste successive.

L’Activity LoginActivity permette inoltre all’utente di specificare la volontà di agire come AlertListener. In questo caso deve essere effettuata la registrazione del dispositivo al servizio GCM, necessaria affinché possa ricevere notifiche push dal server: GCMRegistrar.checkDevice(this);


255

GCMRegistrar.checkManifest(this); final String registrationId = GCMRegistrar.getRegistrationId(this); if (regId.equals("")) {

GCMRegistrar.register(this, Constants.PROJECT_ID); } else { Log.v(TAG, "Already registered to GCM with id: "+registrationId); }

Una volta ottenuto, il registrationId del dispositivo deve essere comunicato al server insieme alle credenziali dell’utente, in modo da associarlo all’utente che ha effettuato l’accesso.

6.2.2.1 Conclusioni Il client realizzato fornisce quindi le funzionalità richieste di invio e di ricezione

degli Alert permettendo all’utente Sender di inviare una richiesta di soccorso e ai Receiver di localizzare le richieste per servirle tempestivamente, e mettendo in atto diversi scenari di rilevazione dei dati sensoriali diretti da una parte a supportare la generazione degli Alert, dall’altra a raccogliere informazioni di stato sui soccorritori. In questo senso il supporto sviluppato nel capitolo 5 - ai meccanismi di rilevazione ha semplificato notevolmente il processo di sviluppo, offrendo funzionalità di alto livello e mostrando una elevata flessibilità nella configurazione delle interazioni tra i componenti e dei processi di elaborazione. La combinazione opportuna dei meccanismi di supporto con i meccanismi applicativi ha permesso di realizzare in modo estremamente semplice le funzionalità di generazione automatica dei contenuti. Un punto critico nella configurazione del supporto è rappresentato dalle possibili sovrapposizioni degli eventi di attivazione, che devono essere individuati con attenzione e gestiti opportunamente tramite gli strumenti offerti di configurazione degli intent. Infine, l’utilizzo del supporto permette di usufruire automaticamente delle strategie di ottimizzazione Cycle Optimization e Low Battery Mode, la cui effettiva efficacia sarà tuttavia valutata nelle sezioni successive di sperimentazione.

6.2.3 Server Il server si occupa di elaborare gli Alert ricevuti dai client applicando i criteri di

elaborazione che danno luogo al processo partecipativo. In particolare realizza questo processo sulla base delle funzionalità dell’infrastruttura di supporto, utilizzando sia i componenti di gestione delle catene che i criteri built-in, e implementando inoltre funzionalità aggiuntive per la gestione delle catene secondo differenti qualità di servizio. Allo stesso tempo il supporto si occupa di gestire le informazioni di rilevazione provenienti dal client, rappresentate sia dalle informazioni destinate al processo di activity recognition, facenti quindi riferimento allo Scenario 3 della sezione 6.2.2.1.1 -, sia dai contenuti quali immagini e registrazioni audio che documentano gli Alert, come previsto dallo Scenario 1. Queste informazioni sono quindi automaticamente disponibili ai criteri tramite il livello di persistenza.

Analogamente all’infrastruttura di supporto, anche il server del servizio Emergency Alert è strutturato secondo un’organizzazione multi-tier, come mostrato in Figura 101. L’architettura prevede un layer di presentazione per la ricezione delle


256

informazioni di sensing, tramite il Sensing Controller previsto dall’infrastruttura di supporto, e degli Alert, tramite l’AlertController. Non solo, il SensingController è stato esteso per fornire agli utenti soccorritori le informazioni che documentano l’Alert. Il Business Layer provvede all’elaborazione degli Alert ricevuti e all’applicazione del processo partecipativo, basandosi sui componenti di gestione e sui criteri built-in offerti dall’infrastru. In particolare offre catene differenziate per le diverse tipologie di Alert: BlueChain, GreenChain, YellowChain e RedChain rispettivamente per i BlueAlert, GreenAlert, YellowAlert, e RedAlert. Le catene sono gestite da una particolare specializzazione del ChainManager, il QoSChainManager, che si occupa di gestire politiche di differenziazione delle richieste in base alla tipologia di Alert. Il modulo AlertNotification infine implementa l’attività partecipativa attuata al termine del processo di elaborazione, che può prevedere in particolare la notifica verso gli utenti del sistema, l’interazione con le autorità o la pubblicazione su bacheche virtuali. Questa rappresenta la core business logic dell’applicazione ed è incapsulata dall’oggetto Emergency Alert Service che come vedremo incarna il servizio partecipativo implementando l’interfaccia ParticipatoryService presentata nella sezione 5.4.2.1.4 -. Attraverso questo componente ha luogo quindi l’attivazione del processo partecipativo tramite le tecniche AOP previste dal supporto. Infine nel layer di persistenza il servizio si avvale da una parte dei componenti DAO offerti dal supporto per l’accesso alle informazioni di rilevazione e alle informazioni sugli utenti, tramite SensingDAO e UserDAO, dall’altra introduce un DAO aggiuntivo per la gestione degli Alert, l’AlertDAO.

Figura 101 - Architettura del modulo server del servizio Emergency Alert.

Nel seguito procederemo ad analizzare i singoli livelli applicativi mostrando come il livello di supporto ha permesso di facilitare lo sviluppo dell’applicazione.

6.2.3.1 Presentation Layer Il livello di presentazione è basato sul framework Spring MVC e si avvale, per

l’interazione con gli utenti, di due componenti principali, il SensingController e l’AlertController. Il primo componente, offerto dal supporto stesso, è stato presentato nella sezione 5.4.1 e permette la ricezione delle informazioni di rilevazione provenienti dai client. In particolare gestisce fondamentalmente due scenari


257

applicativi, tra quelli presentati nella sezione 6.2.2.1.1 -: lo Scenario 1, in cui il client invia le rilevazioni che documentano l’Alert, e che possono rappresentare ad esempio immagini o registrazioni audio effettuate manualmente dall’utente al momento dell’invio dell’Alert stesso, e lo Scenario 3, che prevede il monitoraggio dello stato degli utenti soccorritori al fine di trasferire sul server le informazioni necessarie ad attuare il processo di activity recognition. Entrambi gli scenari sono trattati dal SensingController in modo omogeneo, in quanto si concretizzano nella ricezione di messaggi di tipo ServerUpload costruiti sul client dall’UploadController e contenenti le informazioni di rilevazione. Come descritto nella sezione 5.4.1, il SensingController si occupa di estrarre le informazioni dal messaggio e memorizzarle accedendo al layer di persistenza attraverso il componente SensingDAO. In questo modo le informazioni sono rese persistenti e sono accessibili sia ai componenti che assolvono al processo di activity recognition, per quanto riguarda le informazioni di monitoraggio, sia ai criteri che utilizzano le rilevazioni associate agli Alert.

L’altro componente fondamentale del layer di presentazione è rappresentato dall’AlertController. Si tratta, come nel caso del SensingController, di un componente di tipo Controller secondo la semantica prevista dal framework Spring MVC, che come abbiamo illustrato nella sezione 4.3.4.3, costituisce il componente che permette l’introduzione della logica applicativa all’interno del paradigma MVC. È costituito da una normale classe POJO etichettata dall’annotazione @Controller. Il componente espone un RESTful Web Service in corrispondenza dell’URI users/{userid}/alerts/, dove {userid} rappresenta l’identificativo dell’utente espresso tramite gli URI Template Pattern propri del framework Spring MVC e descritti nella sezione 4.3.4.3.1 -. Il servizio accetta richieste HTTP di tipo POST il cui contenuto è in formato JSON. È rappresentato nel controller dal metodo sendAlert(), che è annotato con l’annotazione @RequestMapping in cui sono specificate caratteristiche del servizio quali l’URI, il metodo HTTP e il formato del corpo del messaggio. Il corpo dei messaggi ricevuti contiene al suo interno gli Alert, secondo la struttura specificata precedentemente nella sezione 6.2.1. Il framework Spring MVC si occupa di convertire il corpo del messaggio nell’oggetto Java, e iniettarlo all’interno del metodo sendAlert() attraverso un parametro di tipo Alert a cui è apposta l’annotazione @RequestBody. Il servizio restituisce un messaggio HTTP con status 201 “Created” per segnalare la creazione dell’Alert all’interno del sistema, ed un intero che rappresenta il numero di destinatari cui è stato notificato. La signature risultante del metodo è quindi la seguente: @ResponseStatus(HttpStatus.CREATED)

@PreAuthorize("authentication.name == #userId")

@RequestMapping(value=SENDER_ALERTS, method=RequestMethod.POST, headers="ContentType=application/json")

public @ResponseBody int createAlert(@RequestBody Alert alert)

L’annotazione @PreAuthorize permette di realizzare le funzionalità di sicurezza. A questo proposito il controller espone il servizio login(), utilizzato sul client dalla LoginActivity per verificare al primo accesso dell’utente, le credenziali di autenticazione. In accordo alla semantica stateless del protocollo REST, tuttavia, tutti i


258

servizi del controller richiedono l’autenticazione dell’utente, tramite l’inclusione tra gli header della richiesta delle credenziali di accesso.

Alla ricezione di un Alert, l’AlertController si occupa di invocare il componente di servizio EmergencyAlertService che provvederà quindi a gestire l’elaborazione dell’Alert. Secondo le dinamiche previste dall’infrastruttura di supporto, in questo modo sarà attivato il processo partecipativo per l’elaborazione degli Alert, che andremo di seguito a descrivere.

6.2.3.2 Business Layer Il business layer ha il compito di gestire il processo di elaborazione degli Alert

sfruttando il supporto fornito dall’infrastruttura per la definizione e la gestione delle catene. Definisce quindi le catene partecipative che caratterizzano l’applicazione, differenziandole secondo la tipologia di Alert cui sono associate, e implementa inoltre una strategia di gestione degli Alert basata su priorità differenziate, tramite il QoSChainManager. Infine, il componente EmergencyAlertService rappresenta il cuore del servizio partecipativo e si occupa di eseguire le azioni opportune sull’insieme di attori selezionato attraverso le catene di criteri: l’invio dell’Alert verso gli utenti soccorritori, attraverso il servizio GCM, e verso le autorità, o la pubblicazione della segnalazione sulle bacheche virtuali.

Per rappresentare queste entità all’interno del processo partecipativo, introduciamo l’estensione dell’interfaccia ParticipatoryContext, introdotta nella sezione 5.4.2.1.1 -, relativamente al servizio Emergency Alert. Questa interfaccia aggiunge alle proprietà precedenti, costituite dall’insieme di utenti e di attori coinvolti, un oggetto che rappresenta un insieme di bacheche virtuali per la pubblicazione dei contenuti. Infine il servizio EmergencyAlertService implementa l’interfaccia ParticipatoryService definita dal supporto, il cui metodo participate() rappresenta il joinpoint in cui si inserisce la catena partecipativa, come descritto nella sezione 5.4.2.1.4 -.

Figura 102 Oggetto Context nel servizio EmergencyAlert.

Prima di descrivere l’implementazione EmergencyAlertService, procederemo prima ad analizzare la struttura delle catene e i meccanismi di gestione che caratterizzano l’applicazione.

6.2.3.2.1 - Catene partecipative

Il servizio Emergency Alert definisce quattro diverse catene partecipative ognuna associata ad una particolare tipologia di Alert. Ogni tipologia di Alert è infatti associata, come abbiamo visto nella sezione 6.1.1, ad un preciso processo di


259

elaborazione. Le catene rappresentano quattro differenti specializzazioni dell’interfaccia ParticipatoryChain, ognuna parametrizzata rispetto al tipo di Alert di competenza, come mostrato in Figura 103. Come vedremo la loro struttura è definita in alcuni casi tramite configurazione XML, altri in modo programmatico. Procediamo quindi a descriverli singolarmente.

Figura 103 Gerarchia delle catene ParticipatoryChain.

I Blue Alert costituiscono segnalazioni destinate esclusivamente alla pubblicazione sulle bacheche virtuali, in quanto non rappresentano richieste di aiuto per cui è necessario un intervento tempestivo. Le bacheche virtuali di pubblicazione possono essere di diverso genere, andando dai social network a strumenti predisposti dalle amministrazioni pubbliche per la segnalazioni di criticità. A questo proposito è necessario determinare l’insieme di bacheche verso cui dirigere la segnalazione. Questo processo è basato su alcuni criteri che prendono in esame gli elementi correlati alla segnalazione, in particolare il messaggio testuale e le foto scattate dall’utente. Definiamo quindi due diversi criteri che si occupano di esaminare i contenuti associati alla segnalazione. Il primo è rappresentato dal TextWallCriteria, che prende in esame il testo associato all’Alert ricercando parole chiave associate a particolari bacheche virtuali, e utilizza tecniche di riconoscimento di pattern linguistici per individuare l’area di interesse. Il secondo criterio è invece rappresentato dal PhotoWallCriteria, che elabora le immagini associate alla segnalazione per individuare pattern specifici secondo cui classificare la particolare tipologia di segnalazione, attraverso tecniche di image processing. Dato che le tecniche di riconoscimento linguistico e di image processing non sono oggetto di questa trattazione, non scenderemo nei dettagli delle implementazioni dei criteri. I criteri in questione sono specificatamente pensati per fare riferimento alle bacheche virtuali piuttosto che all’insieme di attori o utenti. Per permettere l’accesso alle informazioni presenti nei contenuti ma garantire al tempo stesso la portabilità dei criteri, definiamo le interfacce Image e TextMessage che foniscono accesso rispettivamente alle immagini e al testo associati ai contenuti. Come mostrato in Figura 104 i criteri fanno riferimento alle interfacce relative.


260

Figura 104 Criteri per l'elaborazione delle immagini e dei contenuti testuali.

A questo punto è possibile definire la catena di elaborazione per i Blue Alert, detta BlueChain e rappresentata in Figura 105, che è formata dalla sequenza di TextWallCriteria e PhotoWallCriteria. La struttura della catena è specificata tramite file XML di configurazione, e vedremo che sarà direttamente iniettata dal container IoC all’interno del componente ChainManager. L’ordine di applicazione dei due criteri è indifferente, dato che operano aggiungendo l’insieme di oggetti Wall al contesto partecipativo. La catena risultante è schematizzata in Figura 105.

Figura 105 Catena di elaborazione BlueChain.

In modo analogo ai Blue Alert, anche i Green Alert possono essere oggetto di pubblicazione su bacheche virtuali, in quanto possono essere associate a disservizi come ad esempio barriere architettoniche per invalidi. Per questo motivo riutilizzano all’interno della catena GreenChain i criteri definiti precedentemente. Tuttavia i Green Alert si differenziano dal caso precedente in quanto rappresentano delle richieste di aiuto e richiedono quindi il coinvolgimento degli utenti. In particolare, sono diretti a utenti svolgono il ruolo di volontari oppure conoscenti dell’utente, che possono quindi intervenire per fornire aiuto. Questo tipo di elaborazione può essere ottenuta sfruttando i criteri builtin forniti dall’infrastruttura, in particolare il ProfileCriteria, il LocationCriteria e il SocialCriteria. Come abbiamo visto nella sezione 5.4.2.1.1 -, tutti i criteri sono forniti in una versione Source, che aggiunge al contesto l’insieme di utenti coinvolto, ed in una versione Filter, che filtra l’insieme di utenti presenti nel contesto. L’elaborazione richiesta nel caso dei GreenAlert può essere quindi realizzata aggiungendo al contesto tutti gli utenti che soddisfano un particolare criterio e tutti quelli che sono in relazione sociale con l’utente, per poi filtrare l’insieme selezionato in base alla distanza degli utenti dal luogo in cui è stato generato l’Alert. La catena prevede quindi il SocialSource, che estrae gli utenti in relazione sociale con il mittente, il ProfileSource, che aggiunge gli utenti con il ruolo di volontari (role==VOLUNTARY), ed infine il LocationFilter che filtra gli utenti precedentemente selezionati sulla base di una soglia massima di distanza dal luogo di generazione dell’Alert (dist<MAX_DIST). Inoltre, può essere utile, in caso siano selezionati un numero eccessivo di utenti, superiore ad una soglia MAX_USERS,


261

selezionare solo gli utenti maggiormente propensi a fornire soccorsi in base al loro stato corrente, attraverso lo StateFilter. La composizione della catena è schematizzata in Figura 106. In questo caso è quindi necessario definire un nodo condizionale per discriminare l’applicazione dello StateFilter. In caso abbiamo scelto di definire la catena in modo programmatico evitando così la creazione di una classe apposita del nodo condizionale, che è invece definito come implementazione “inline” dell’interfaccia ConditionalNode.

Figura 106 Struttura della catena GreenChain.

Il livello di allerta successivo è costituito dagli YellowAlert. Per questa tipologia di Alert, che è associata a segnalazioni riguardanti piccoli traumi e malori lievi, può essere sufficiente come nel caso precedente ricorrere a utenti qualificati presenti nella località o anche conoscenti. Tuttavia la peculiarità di questo tipo di Alert è rappresentata dalla necessità di garantire soccorso. Di conseguenza, nel caso non siano presenti utenti nella località, devono essere coinvolti utenti qualificati che siano disponibili a fornire soccorso, quali ad esempio la guardia medica. In questo caso la catena di elaborazione è costituita quindi, come nel caso precedente, da criteri quali SocialSource, ProfileSource, e LocationFilter, ma nel caso non siano trovati utenti utilizziamo un ProfileSource configurato per i medici che attualmente stanno svolgendo il ruolo di guardia medica. La catena risultante è illustrata in Figura 107. Come nel caso precedente la definizione della catena in modo programmatico permette l’estensione della classe astratta ConditionalNode in modalità inline.

Figura 107 Struttura della catena YellowChain.

Infine, la tipologia di Alert di livello massimo è rappresentata dai Red Alert. Trattandosi di situazioni di grave emergenza, è necessario coinvolgere tutti gli utenti presenti nella località che possono fornire soccorsi. In aggiunta, è necessario coinvolgere oltre agli utenti anche le autorità competenti. A questo proposito il sistema utilizza un insieme di criteri volti ad esaminare i contenuti associati alle segnalazioni e


262

determinare quindi il tipo di autorità da coinvolgere. Ad esempio, gli Alert inviati tramite lo Scenario 2, in seguito ad un urto dell’utente e all’invocazione di aiuto tramite la voce, generano un Alert di tipo Red corredato dalla registrazione audio. In questo caso, è possibile quindi esaminare il campione audio e verificare la necessità di coinvolgere il pronto soccorso. Nel caso di presenza di immagini, può essere invece utilizzato un filtro che, in modo analogo all’ImageWallFilter, individua pattern ricorrenti nelle emergenze come la presenza di fiamme nelle immagini per dirigere la richiesta verso i vigili del fuoco. Per questo introduciamo il PhotoActorCriteria e l’AudioActorCriteria che elaborano rispettivamente immagini e sequenze audio associate all’Alert per determinare i possibili attori da coinvolgere nella disseminazione dell’Alert. La catena è definita in questo caso tramite file di configurazione XML.

Figura 108 Struttura della catena Red Chain.

L’insieme delle catene definite permette quindi la gestione delle diverse tipologie di Alert in modo appropriato. Per completare la configurazione delle catene e all’interno del supporto è necessario infine specificare le catene che costituiscono l’applicazione all’interno della configurazione del componente ChainManager. In questo caso però l’applicazione utilizza una particolare specializzazione di questo componente capace di attuare politiche di differenziazione e di gestione delle priorità nell’esecuzione delle catene.

6.2.3.2.2 - QoSChainManager e ChainFactory

Il supporto offre l’interfaccia ChainManager e la sua implementazione base, ilBaseChainManager, per la configurazione e la gestione delle catene partecipative. Il QoSChainManager rappresenta una speciale estensione del BaseChainManager appositamente introdotta per il servizio Emergency Alert per introdurre comportamenti di gestione differenziati delle catene di elaborazione degli Alert. In particolare il suo obiettivo è garantire la priorità nell’esecuzione delle catene con livello di emergenza più elevato. Ad esempio, all’atto della ricezione di un Yellow Alert l’esecuzione della Yellow Chain associata deve avere priorità maggiore rispetto ad eventuali Alert di tipo Green o Blue in elaborazione sul sistema.

Il componente si occupa di tenere traccia delle richieste attualmente attive per ognuna delle tipologie di Alert. Nel caso in cui il numero totale delle richieste attive superi una soglia prefissata, configurata in modo da individuare una situazione di sovraccarico del sistema, il sistema provvede a bloccare ed accodare le nuove richieste meno prioritarie, favorendo quindi l’esecuzione delle richieste più prioritarie. La strategia ha l’obiettivo di mantenere il carico del sistema entro limiti accettabili, che garantiscano livelli di servizio soddisfacenti, privilegiando al tempo stesso l’esecuzione delle richieste di servizio più prioritarie. Quando il numero di richieste


263

attualmente attive scende sotto la soglia di carico, o quando le richieste ricevute sono meno prioritarie di quelle accodate, il sistema provvede a riattivare le richieste presenti in coda seguendo l’ordine di priorità e l’ordine di accodamento secondo una politica FIFO. In è mostrata la struttura del componente: la classe estende il BaseChainManager fornito dal supporto e presenta i contatori per il conteggio delle catene attualmente in esecuzione e le code FIFO in cui sono accodate le richieste.

Figura 109 Struttura del componente QoSChainManager.

Il servizio EmergencyAlert utilizza la strategia singleton per l’implementazione delle istanze. Per le catene BlueChain e RedChain, che sono definite come bean all’interno del file di configurazione XML, la strategia di gestione delle istanze è configurata selezionando lo scope opportuno all’interno della configurazione XML stessa, come descritto nella sezione 4.3.1.5. Per le catene GreenChain e YellowChain invece, che sono definite in modo programmatico, la strategia di creazione delle istanze è gestita dal componente ChainFactory selezionando l’implementazione specifica SingletonChainFactory tramite la configurazione XML del bean stesso.

6.2.3.2.3 - EmergencyAlertService

Infine, il fulcro della business logic del servizio EmergencyAlert è rappresentato dall’EmergencyAlertService, che come abbiamo visto implementa l’interfaccia ParticipatpryService e definisce il metodo participate(). In accordo alla definizione del joinpoint all’interno dell’aspetto ParticipatoryAspect, nella sezione 5.4.2.1.4 -, l’esecuzione di questo metodo rappresenta il punto di attivazione delle catene partecipative e dei componenti di gestione che abbiamo precedentemente definito.

Il metodo participate() è fondamentale per il servizio Emergency Alert in quanto deve gestire l’insieme di utenti ed attori selezionati dalle catene partecipative. A questo proposito si occupa quindi di notificare gli Alert agli utenti e agli attori, attraverso i canali di comunicazione relativi. Provvede inoltre alla pubblicazione delle segnalazioni sulle bacheche virtuali selezionate. Tra questi elementi, quello più importante è rappresentato dall’interazione con gli altri utenti del sistema. Per notificare le segnalazioni agli utenti soccorritori è utilizzato il servizio GCM, già introdotto facendo riferimento al modulo client nella sezione 6.2.2.3.1 -. In questo caso provvediamo quindi all’invio degli Alert verso i client soccorritori attraverso le API


264

messe a disposizione del servizio. Come abbiamo già accennato ogni client è individuato da un identificativo univoco all’interno del servizio, che viene quindi recuperato per effettuare l’invio in modalità multicast dell’Alert in modalità multicast. L’identificativo, o registrationId, è fornito dal servizio stesso all’atto della registrazione dei client. La registrazione è gestita dai moduli client all’atto dell’autenticazione dell’utente, come descritto nella sezione 6.2.2.4.2 -. In seguito all’autenticazione dell’utente il registrationId viene comunicato al server che lo associa all’utente relativo.

L’operazione di invio è effettuata tramite l’operazione send() offerta dal servizio, in cui è specificata la lista dei registrationId dei destinatari: MulticastResult result = sender.send(message, registrationIds, 1); if (result.getResults() != null) { int success=result.getSuccess(); alert.setSuccess(success); logger.info("Alert broadcasted to "+success+" targets"); return success;

}

Si noti che l’operazione send() offerta dal servizio GCM permette di specificare una molteplicità di dispositivi, rappresentati dalla lista di identificativi registrationIds, incaricandosi quindi della gestione dell’operazione di invio in multicast verso i client. Il numero di client cui è correttamente consegnato l’Alert, restituito dal servizio GCM e rappresentato nel listato dalla variabile success, rappresenta il valore di ritorno del metodo participate ed è successivamente comunicato al client dal livello di presentazione.

6.2.3.3 Persistence Layer Il livello di persistenza è basato, come nel caso dell’infrastruttura di supporto,

su pattern DAO, in quanto permette di ottenere maggiore trasparenza rispetto alla particolare tecnologia di accesso al livello di persistenza. I principali componenti utilizzati sono rappresentati dai DAO definiti dall’infrastruttura di supporto, presentati nella sezione 5.4.3, e in particolare il SensingDAO e lo UserDAO che sono utilizzati dai componenti applicativi per accedere rispettivamente alle informazioni di rilevazione e alle informazioni associate agli utenti del sistema. Il terzo componente DAO definito dal supporto, l’ActivityRecognitionDAO, è utilizzato solo indirettamente da parte dei criteri che prendono in esame lo stato dell’utente, qual è lo StateFilter utilizzato dalla GreenChain.

È introdotto inoltre un componente aggiuntivo che si occupa di gestire la persistenza per gli oggetti di tipo Alert, permettendo di salvare e recuperare le segnalazioni e le informazioni associate quando sono richieste dagli utenti o dagli attori del sistema. Come nel caso del supporto il componente è implementato tramite tecnologia Hibernate 3. Ciò permette la definizione delle strategie di mapping dell’oggetto Alert nell’equivalente relazionale attraverso l’uso di semplici annotazioni apposte alla classe. La struttura del componente è riportata in Figura 110. La struttura dell’oggetto User inoltre è stata estesa per includere un riferimento all’insieme degli oggetti Alert associati. In questo modo è possibile accedere agli Alert associati


265

all’utente sfruttando le funzionalità del framework Hibernate 3, nascondendo gli accessi al livello di persistenza dietro l’accesso alle proprietà degli oggetti stessi.

Figura 110 Interfaccia AlertDAO.

6.2.3.4 Con il layer di persistenza si conclude la descrizione della realizzazione del

servizio Emergency Alert. Come nella realizzazione del modulo client, anche nel caso del server l’infrastruttura di supporto ha facilitato notevolmente lo sviluppo del servizio, fornendo le funzionalità per la gestione delle informazioni di sensing e la base di realizzazione per il processo partecipativo. Le rilevazioni provenienti dal client sono automaticamente gestite dai componenti di supporto del layer di presentazione e di persistenza, rendendole così disponibili ai processi partecipativi. Le modalità dichiarative e programmatiche per la creazione delle catene hanno permesso di definire la struttura della Red, Yellow, Green e Blue Chain in modo semplice e flessibile, promuovendo il riuso dei criteri e fornendo un ampia scelta di criteri predefiniti. Infine, i meccanismi di supporto e di gestione delle catene hanno mostrato elevata configurabilità ed estendibilità, permettendo la realizzazione di particolari strategie di gestione delle catene come nel caso del QoSChainManager e della gestione delle priorità.

A questo punto procederemo con la descrizione dei risultati sperimentali volti a verificare le prestazioni del sistema ottenuto, al fine di valutare le caratteristiche di efficienza e scalabilità dei moduli client e server, con riferimento non solo al servizio Emergency Alert ma anche e soprattutto all’infrastruttura di supporto.

6.3 - Risultati sperimentali In questa sezione procederemo a presentare i risultati di alcuni test preliminari

che sono stati condotti sull’implementazione del servizio Emergency Alert presentata al fine di valutare l’efficienza e le prestazioni del servizio e dell’infrastruttura di supporto a servizi partecipativi realizzata nel capitolo 5 - . I test sono stati indirizzati separatamente verso i moduli client o server e procederemo quindi nel presentarne singolarmente i risultati.

6.3.1 Client I test effettuati sul client vogliono valutare l’efficienza e l’efficacia dei meccanismi di ottimizzazione presentati nella sezione 5.3.7, rappresentati in particolare dalle strategie Cycle Optimization (CO) e Low Battery Mode (LBM). A titolo di promemoria ricordiamo che la CO consiste nella regolazione dinamica della frequenza di rilevazione, elaborazione e trasferimento sul server dei dati sensoriali da parte dei


266

componenti client, in base al carico computazionale e alla disponibilità energetica del dispositivo. Il meccanismo mira quindi a garantire la disponibilità di risorse energetiche e computazionali necessarie al normale utilizzo del dispositivo da parte dell’utente, anche nei casi in cui sono attivi i meccanismi di monitoraggio continuativo dello stato dell’utente. Abbiamo visto inoltre come nel caso del LocationClient, la strategia preveda meccanismi specifici di gestione della frequenza di aggiornamento della posizione volti al risparmio energetico. La strategia Low Battery Mode è invece indirizzata a prolungare la durata della batteria nel momento in cui la carica disponibile è inferiore ad una soglia prefissata, riducendo ulteriormente la frequenza dei cicli di rilevazione e provvedendo, nel caso del LocationClient, a disattivare il GPS. I test condotti mirano quindi a verificare l’impatto di queste strategie sulle risorse energetiche e computazionali del sistema.

I test sono stati effettuati su un dispositivo Samsung Galaxy S II, con sistema operativo Android 4.0.3, ed attivando i meccanismi di monitoraggio dello stato dell’utente previsti al modulo Alert Receiver del servizio Emergency Alert, facendo quindi riferimento allo Scenario 3 di rilevazione presentato nella sezione 6.2.2.1.1 -. Lo scenario prevede quindi il monitoraggio di accelerometro e microfono tramite i componenti SensorClient e l’estrazione delle feature tramite FeatureExtractor. Una singola rilevazione ha durata pari a 5 secondi per l’accelerometro e 500 millisecondi per il microfono. Allo stesso tempo sono estratte le informazioni di contesto relative agli utenti presenti nella prossimità e gli eventi dell’utente, rispettivamente tramite BluetoothClient e CalendarClient. Infine, il LocationClient effettua le rilevazioni di posizione attraverso i sistemi di posizionamento basati su WiFi, GPS, e rete cellulare. I componenti SensingController e ContextController si occupano di schedulare le singole rilevazioni secondo la frequenza prevista dalla strategia CO, che come ricordiamo deve essere configurata specificando un periodo minimo (T_MIN) e massimo (T_MAX entro il quale oscilla la frequenza di rilevazione. Infine, l’UploadController effettua i trasferimenti verso il serve, anch’esso applicando una strategia di ottimizzazione analoga per la frequenza dei trasferimenti. Per simulare l’attività dell’utente, si utilizza un processo in background che scarica periodicamente pagine html dalla rete, con una frequenza di 1 richiesta ogni 30 secondi e si provvede inoltre ad attivare lo schermo per un periodo di tempo pari 3 minuti ad intervalli casuali con distribuzione uniforme di valor medio di 15 minuti. Inoltre, un processo in esecuzione in background effettua operazioni di elaborazione ogni 60 secondi, generando dei picchi di utilizzazione della CPU pari a circa il 30%.

Il test consiste nel confronto di 3 diversi scenari. Il primo prevede un periodo di rilevazione costante pari a 15 secondi, e non utilizza quindi né la strategia CO né la strategia LBM. In questo caso il processo di rilevazione genera un carico computazionale che oscilla tra il 10 e il 15%. Il secondo scenario prevede invece l’utilizzo della strategia CO configurata con parametri T_MIN pari a 5 secondi e T_MAX pari a 30 secondi, modulando quindi il carico computazionale in funzione delle risorse disponibili. Infine, nel terzo scenario è utilizzata la strategia LBM in aggiunta alla CO, con un ciclo di rilevazione fisso pari a 60 secondi e la disattivazione, come previsto dalla strategia stessa, del sistema GPS. La strategia LBM è attivata solo nel caso in cui la carica di batteria scenda sotto il 15%.


267

Per valutare l’efficacia delle strategie sono state prese in considerazione le misure di utilizzazione della CPU e di durata della batteria.

6.3.1.1 CPU In Figura 111 sono riportati i risultati ottenuti misurando l’utilizzazione di CPU

per un periodo di circa 5 minuti, rispettivamente nel primo scenario (No Optimization, a sinistra), cioè senza applicare alcuna strategia di ottimizzazione e nel secondo scenario (Cycle Optimization, a destra) in cui si utilizza CO. Com’è possibile notare, nel primo caso l’utilizzazione della CPU totale supera il 40% in corrispondenza dei picchi generati dal processo di background, poiché risulta essere la somma dell’utilizzazione del processo di test (CPU Consuming Process, in blu) e di quello di sensing (Sensing Process, in rosso). Nel secondo caso invece, è possibile notare come il carico computazionale massimo superi leggermente il 30%. Ciò è dovuto al fatto che la strategia CO riduce la frequenza di esecuzione delle rilevazioni e dei trasferimenti sul server in corrispondenza dei picchi, contenendo quindi il carico computazionale complessivo del sistema.

Figura 111 Utilizzazione della CPU nel caso senza ottimizzazione.

6.3.1.2 Batteria In secondo luogo abbiamo misurato la durata totale della batteria (partendo da

una carica del 100% fino ad arrivare all’esaurimento completo) con riferimento ai 3 differenti scenari. In Figura 112 è riportata la durata della batteria in riferimento alle 3 diverse strategie. Com’è possibile osservare, CO permette di ottenere un incremento del 59,7% nella durata complessiva della batteria rispetto al caso in cui non sia attivata alcuna strategia. Nel caso in cui sia attiva anche la strategia LBM, si registra un incremento del 74,9% rispetto al primo scenario, e un incremento del 31,8% nella durata della carica sotto il 15% rispetto allo scenario che utilizza unicamente CO.


268

Figura 112 - Durata della batteria con le diverse strategie di ottimizzazione.

Complessivamente, i risultati mostrano come le strategie CO e LBM comportino sostanziali miglioramenti sia per quanto riguarda l’efficienza computazionale, sia sotto il profilo energetico. Procediamo ora ad analizzare i risultati ottenuti in merito all’infrastruttura server.

6.3.2 Server I test condotti sul server hanno l’obiettivo di valutare la scalabilità non solo del

servizio Emergency Alert, ma soprattutto dell’infrastruttura di supporto. Per questo motivo non è stato attivato il supporto alla QoS previsto dal servizio Emergency Alert, al fine di verificare le caratteristiche del sistema in uno scenario generico, piuttosto che con caratteristiche di QoS.

Per il test sono stati utilizzati due nodi, che agiscono uno da client ed uno da server, connessi tramite una rete WLAN di tipo 802.11b. I due nodi sono entrambi connessi ad un router centrale che svolge il ruolo di Access Point. La scelta della rete wireless è mirata a simulare lo scenario dei dispositivi mobili. Il collegamento tra client e server è caratterizzato da un Round Trip Time (RTT) medio pari a 165,809 millisecondi con deviazione standard di 105,221 millisecondi (misurazione effettuata su 100 risultati). La macchina server, su cui è dispiegata l’infrastruttura di backend, è equipaggiata da processore Intel Core 2 Duo a 2.4 GHz e memoria RAM da 4 GB, e dispone di sistema operativo Mac OS X 10.6.8. Il servizio è ospitato dal web container Tomcat 7. Il client è dotato di processore Intel Pentium M 1,3 GHz e di 512 MB di RAM.

A partire dall’istante iniziale del test il client provvede ad attivare un thread ogni secondo, per un periodo di tempo pari a 100 secondi, raggiungendo quindi il valore massimo di 100 thread contemporaneamente attivi dopo 100 secondi. Ogni thread vuole simulare il comportamento di un singolo utente inviando ripetutamente Alert al server. In particolare la tipologia di Alert è determinata in modo casuale tra le


269

4 tipologie Red, Yellow, Green e Blue. Anche l’intervallo temporale tra due invii da parte di uno stesso thread rappresenta una variabile aleatoria con distribuzione gaussiana di valor medio pari a 500 millisecondi e varianza 500 millisecondi. Il server applica a ogni Alert ricevuto la catena di elaborazione associata, secondo quanto è stato descritto nella sezione 6.2.3.2.1 -. Il test ha avuto una durata totale pari a 5 minuti.

La Figura 113 riporta un diagramma riassuntivo dei risultati ottenuti. In rosso è indicato il numero (moltiplicato per 10) di thread contemporaneamente attivi sul client nel corso del tempo. Com’è possibile notare, questo valore cresce di una unità ogni secondo, raggiungendo il valore massimo di 100 thread dopo 100 secondi. In blu è indicato il numero (moltiplicato per 10) di richieste servite dal server per secondo, fornendo quindi una indicazione del throughput del sistema. Il valore massimo si attesta intorno alle 80 richieste al secondo, ed è quindi inferiore al numero di richieste effettivo che dovrebbe essere inviato al server, dato che ognuno dei 100 thread attivi invia in media più di una richiesta al secondo. Questo è dovuto al fatto che i thread, prima di effettuare ogni invio, attendono la ricezione della risposta da parte del server. La soglia di 80 richieste al secondo indica quindi il massimo throughput possibile, in corrispondenza del quale il tempo necessario all’elaborazione delle richieste da parte del server blocca i thread client in attesa della risposta. In rosa è indicata la percentuale di utilizzazione (moltiplicata per 10) del processore sulla macchina server. Infine, le misurazioni in verde rappresentano i tempi di risposta medi.

Figura 113 - Grafico riassuntivo dei risultati sperimentali.

Il grafico evidenzia una stretta correlazione tra il throughput del sistema (in blu) e l’utilizzazione di CPU (in rosa). Ciò corrisponde a una caratterizzazione del sistema di tipo “CPUbound”, in cui cioè il tempo di soddisfacimento delle richieste è strettamente legato al carico computazionale del sistema. In particolare le due grandezze sono legate da una relazione di tipo lineare, com’è possibile notare dalla loro sovrapposizione nella prima parte del grafico. Ciò rappresenta un dato molto importante, poiché indica che aumentando in modo opportuno la capacità computazionale e le risorse del sistema è possibile sostenere volumi di utenza e di traffico arbitrari. Di conseguenza, possiamo concludere che il sistema presenta ottime caratteristiche di scalabilità, in quanto è possibile aumentare il throughput del sistema secondo le necessità fornendo adeguate risorse hardware.


270

6.4 - Conclusioni Il presente lavoro di tesi è stato orientato allo sviluppo di un’infrastruttura

capace di supportare la realizzazione di servizi partecipativi per dispositivi mobili, all’interno del particolare contesto inclusivo e collaborativo che caratterizza le Smart City. Come abbiamo visto, infatti, partecipazione e inclusione dei cittadini rappresentano elementi fondamentali all’interno dello scenario Smart City, e sebbene siano già molteplici gli esempi di servizi di questo tipo dispiegati in diverse città europee e non, abbiamo individuato la componente collaborativa come quella più qualificante in quanto capace di incarnare in pieno il modello di cittadino intelligente promosso dalla Smart City. L’infrastruttura sviluppata si propone quindi come una piattaforma capace di raccogliere i contenuti immessi dagli utenti per determinare l’insieme di attori coinvolti nel processo partecipativo, che consistono non solo negli organi dell’amministrazione cittadina ma anche e soprattutto negli utenti del sistema, in conformità a diversi criteri di elaborazione dei contenuti quali la posizione geografica, le informazioni di profilo, le attività e lo stato corrente, le relazioni sociali degli utenti.

Per verificare la validità dell’infrastruttura sviluppata abbiamo realizzato il servizio Emergency Alert, un servizio partecipativo concepito per permettere la segnalazione di situazioni di emergenza e di pericolo, che permette agli utenti di inviare richieste di aiuto differenziate in base al livello di allerta richiesto. Attraverso la realizzazione del caso applicativo specifico abbiamo evidenziato l’elevata flessibilità delle funzionalità di supporto predisposte sia sul client, in cui hanno semplificato la realizzazione dei processi di sensing, sia sul server, attraverso l’implementazione delle catene di elaborazione con livelli di servizio differenziati. I risultati sperimentali hanno inoltre mostrato da una parte l’efficacia dei meccanismi di ottimizzazione predisposti sul client, che permettono di migliorare notevolmente l’efficienza energetica e computazionale dei dispositivi, e dall’altra la scalabilità dell’infrastruttura server, che è in grado di supportare volumi di traffico arbitrari previa la predisposizione di adeguate risorse di elaborazione.

Nonostante lo specifico caso applicativo preso in considerazione, la generalità delle soluzioni progettate conferisce all’infrastruttura uno spettro di applicabilità ben più ampio dello scenario dell’emergency. È infatti in grado di supportare qualsiasi scenario partecipativo che preveda la raccolta e la redistribuzione di contenuti all’interno della comunità di utenti, siano essi destinati ad esempio alla segnalazione delle criticità del territorio, al coordinamento del personale all’interno di strutture ospedaliere, alla creazione e condivisione di eventi e informazioni turistiche o al coordinamento degli utenti nell’accesso a strutture cittadine quali gli uffici pubblici. Lo stack infrastrutturale costituito dalla piattaforma di supporto e dal servizio Emergency Alert sono state oggetto inoltre di una fase di installazione e dispiegamento all’interno di uno scenario reale in Regione Emilia Romagna, che ha permesso di validare ulteriormente il sistema e le scelte progettuali che vi sono alla base realizzando l’integrazione da una parte con i sistemi di autenticazione e di gestione delle credenziali che forniscono la base di utenza, dall’altra con gli organi dell’amministrazione pubblica per lo smistamento delle segnalazioni.


271

Il lavoro presenta diverse strade aperte per possibili innovazioni e miglioramenti. Innanzitutto, i moduli client supportano al momento solo un set ristretto di sensori, quali accelerometro, giroscopio, fotocamera, e microfono, ed è possibile quindi espandere le funzionalità a tutte le altre tipologie di sensori previste dalla piattaforma Android. Inoltre, le strategie di ottimizzazione sono pensate per agire in modo indifferenziato su tutti i sensori, mentre può essere ragionevole ampliare la strategia includendo la possibilità di una gestione differenziata per i diversi sensori. Non ultima, la necessità di realizzare il porting dei meccanismi client verso altre piattaforme quali Windows Phone, iOS, RIM Blackberry. L’infrastruttura server può invece essere ampliata prevedendo un insieme più ampio di criteri di elaborazione predefiniti, fornendo un maggior numero di strategie di gestione delle catene in aggiunta a quelle previste al momento e realizzando forme di integrazione con piattaforme sociali.

Conclusioni

Il presente lavoro di tesi è stato orientato allo sviluppo di un’infrastruttura capace di supportare la realizzazione di servizi partecipativi per dispositivi mobili, all’interno del particolare contesto inclusivo e collaborativo che caratterizza le Smart City. Come abbiamo visto, infatti, partecipazione e inclusione dei cittadini rappresentano elementi fondamentali all’interno dello scenario Smart City, e sebbene siano già molteplici gli esempi di servizi di questo tipo dispiegati in diverse città europee e non, abbiamo individuato la componente collaborativa come quella più qualificante in quanto capace di incarnare in pieno il modello di cittadino intelligente promosso dalla Smart City. L’infrastruttura sviluppata si propone quindi come una piattaforma capace di raccogliere i contenuti immessi dagli utenti per determinare l’insieme di attori coinvolti nel processo partecipativo, che consistono non solo negli organi dell’amministrazione cittadina ma anche e soprattutto negli utenti del sistema, in conformità a diversi criteri di elaborazione dei contenuti quali la posizione geografica, le informazioni di profilo, le attività e lo stato corrente, le relazioni sociali degli utenti.

Per verificare la validità dell’infrastruttura sviluppata abbiamo realizzato il servizio Emergency Alert, la cui realizzazione ha evidenziato l’elevata flessibilità delle funzionalità di supporto predisposte sia sul client, in cui hanno semplificato la realizzazione dei processi di sensing, sia sul server, attraverso l’implementazione delle catene di elaborazione con livelli di servizio differenziati. I risultati sperimentali hanno inoltre mostrato, da una parte, l’efficacia dei meccanismi di ottimizzazione predisposti sul client, che permettono di migliorare notevolmente l’efficienza energetica e computazionale dei dispositivi, e dall’altra, la scalabilità dell’infrastruttura server, che è in grado di supportare volumi di traffico arbitrari previa la predisposizione di adeguate risorse di elaborazione.


274

Nonostante lo specifico caso applicativo preso in considerazione, la generalità delle soluzioni progettate conferisce all’infrastruttura uno spettro di applicabilità ben più ampio dello scenario dell’emergency. È infatti in grado di supportare qualsiasi scenario partecipativo che preveda la raccolta e la redistribuzione di contenuti all’interno della comunità di utenti, siano essi destinati ad esempio alla segnalazione delle criticità del territorio, al coordinamento del personale all’interno di strutture ospedaliere, alla creazione e condivisione di eventi e informazioni turistiche o al coordinamento degli utenti nell’accesso a strutture cittadine quali gli uffici pubblici. Lo stack infrastrutturale costituito dalla piattaforma di supporto e dal servizio Emergency Alert sono state oggetto inoltre di una fase di installazione e dispiegamento all’interno di uno scenario reale in Regione Emilia Romagna, che ha permesso di validare ulteriormente il sistema e le scelte progettuali che vi sono alla base realizzando l’integrazione da una parte con i sistemi di autenticazione e di gestione delle credenziali che forniscono la base di utenza, dall’altra con gli organi dell’amministrazione pubblica per lo smistamento delle segnalazioni.

Il lavoro presenta diverse strade aperte per possibili innovazioni e miglioramenti. Innanzitutto, i moduli client supportano al momento solo un set ristretto di sensori, quali accelerometro, giroscopio, fotocamera, e microfono, ed è possibile quindi espandere le funzionalità a tutte le altre tipologie di sensori previste dalla piattaforma Android, così come ad altri tipi di sensori che potranno essere a breve disponibili. Inoltre, le strategie di ottimizzazione sono pensate per agire in modo indifferenziato su tutti i sensori, mentre può essere ragionevole ampliare la strategia includendo la possibilità di una gestione differenziata e negoziata per i diversi sensori. Non ultima estensione, la necessità di realizzare il porting dei meccanismi client verso altre piattaforme quali Windows Phone, iOS, RIM Blackberry.

L’infrastruttura server può invece essere ampliata prevedendo un insieme più ampio di criteri di elaborazione predefiniti, fornendo un maggior numero di strategie di gestione delle catene in aggiunta a quelle previste al momento e realizzando forme di integrazione con piattaforme sociali.

Bibliografia

[ABI11] ABIResearch: “Smart City Technologies Will Grow Fivefold to Exceed $39 Billion in 2016”, 2011.

(http://www.abiresearch.com/press/smart-city-technologies-will-grow-fivefold-to-exce)

[AMS] Amsterdam Smart City: “Economically strong and sustainable Structural Vision: Amsterdam 2040”, 2011.

(http://www.amsterdam.nl/publish/pages/377545/plan-01-2011-eng.pdf).

[BAR] Barcelona City Council: “Barcelona Smart City: paving the way”.

(http://ec.europa.eu/information_society/activities/livinglabs/docs/pdf/paca_co_%20llabs/barcelona.pdf)

[CAM98] R. Camagni, R. Capello, P. Nijkamp: “Towards sustainable city policy: an economy-environment technology nexus”, Ecological economics n. 24, 103-118, 1998.

(http://www.sciencedirect.com/science/article/pii/S0921800997000323)

[CAR09] A. Caragliu, C. Del Bo, P. Nijkamp: “Smart Cities in Europe”, 3rd Central European Conference in Regional Science, 2009.

(http://ideas.repec.org/p/dgr/vuarem/2009-48.html)

[CHE11] L. Chen, W. Chen: “Intelligent City - Tianjin: The System Analysis of Intelligent Community Public Service”, 18Th International Conference on Industrial Engineering and


276

Engineering Management, 2011.

(http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6035412&tag=1)

[EDI] Edimburg City Council: “e-Government Smart City”.

(http://www.edinburgh.gov.uk/info/691/council_performance/967/e-government_smart_city/1)

[GIF07] R. Giffinger, C. Fertner, H. Kramar, R. Kalasek, N. Pichler-Milanovic, E. Meijers: “Smart cities Ranking of European medium-sized cities”, Centre of Regional Science, Vienna UT, 2007.

(http://www.smart-cities.eu/download/smart_cities_final_report.pdf)

[GLA06] E. L. Glaeser, C. R. Berry: “Why Are Smart Places Getting Smarter?”, Taubman Center for State and Local Government, Harvard University, 2006.

(http://www.hks.harvard.edu/var/ezp_site/storage/fckeditor/file/pdfs/centers-programs/centers/taubman/brief_divergence.pdf)

[GRA02] S. Graham: “Bridging urban digital divides: urban polarisation and information and communication technologies (ICTs)”, Urban studies, Vol. 39, No. 1, p. 33–56, 2002.

(http://unpan1.un.org/intradoc/groups/public/documents/apcity/unpan013630.pdf)

[HEL] Forum Virium Helsinki: “Smart City”.

(http://forumvirium.fi/en/project-areas/smart-city)

[HOL08] R. G. Hollands: "Will the real smart city please stand up?", City n. 12, p. 303–320, 2008.

[ISH00] T. Ishida , K. Isbister : “Digital Cities : Technologies, Experiences, and Future Perspectives ”, Edizione 1765, Springer, 2000.

[KOM02] N. Komninos, Intelligent Cities: “Innovation, Knowledge Systems and Digital Spaces”, Routledge, 2002, p. 195-201.

[KOM09] N. Komninos, E. Sefertzi: “Intelligent Cities: R&D offshoring,


277

web 2.0 product development and globalization of innovation systems”, Second Knowledge Cities Summit, 2009.

(http://www.urenio.org/wp-content/uploads/2008/11/Intelligent-Cities-Shenzhen-2009-Komninos-Sefertzi.pdf)

[MIT99] William J. Mitchell: “E-topia : urban life, Jim-but not as we know it.”, Cambridge (Mass.), London : The MIT press, 1999.

[MOS01] M. A. Moser: “What is smart about the smart communities movement?”, EJournal, 10/11(1), 2001.

(http://www.ucalgary.ca/ejournal/archive/v10-11/v10-11n1Moser-browse.html)

[SHA12] V. Shaffler: “Project: Smart city Wien”, Smart Cities Stakeholder Platform, 2012.

(http://eu-smartcities.eu/blog/project-smart-city-wien)

[SUL11] K. Su, J. Li, H. Fu: “Smart City and the Applications”, International Conference on Electronics, Communications and Control (ICECC), 2011.

(http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6066743).

[PRO05] P. Properzi: “Government e Governance”, Rapporto dal Territorio, 2005.

(http://www.rapportodalterritorioinu.it/2005/Pagine%20separate/Governance_government.pdf)

[ONU11] United Nations, Department of Economic and Social Affairs, Population Division: “World Urbanization Prospects, the 2011 Revision.” Final Report with Annex Tables. New York, 2012.

(http://esa.un.org/unpd/wup/Documentation/final-report.htm)

[CAR12] M. Cardone: “La rivoluzione delle smart city è in corso”, Qualenergia.it, analisi mercati e scenari energetici, 2012.

(http://www.qualenergia.it/articoli/20120802-la-rivoluzione-delle-smart-city-in-europa-e-negli-usa)

[VIA12] M. Vianello: “Smart City creatrici di conoscenza”, Corriere delle Comunicazioni, 19 marzo 2012.

(http://www.vegapark.ve.it/images/stories/articoli/rassegna_sta


278

mpa_2012/Corriere_delle_Comunicazioni_19_marzo_2012.pdf)

[CHI12] P. S. Chillon: “A Smart City overall mission, from infrastructure to the role of citizens”, keynote in Smart City Exhibition 2012, Bologna.

(http://smartinnovation.forumpa.it/story/69695/pablo-sanchez-chillon-cittadino-e-spina-dorsale-della-smart-city)

[NOT05] C. Notamurzi: “La governance nell e-Government: l’e-governance”, I mercati dell’amministrazione, ed. Il Sole 24 ore, 2005.

(http://www.astrid-online.it/E-governme/Studi-e-ri/Archivio-21/NOTARMUZI-Governance-dell-e-governme.pdf)

[SMA09] M. Deakin, P. Cruickshank: “Transformation of City portals”, Smart City Research Brief N° 6, European Smart Cities Project, 2009.

(http://www.smartcities.info/files/Smart_Cities_Research_Brief_Transformation_of_City_Portals.pdf)

[ORE05] T. O’Reilly: “What is Web 2.0”, O’Reilly Media, 2005.

(http://oreilly.com/web2/archive/what-is-web-20.html)

[WIL12] A. Williams: “Feds Close The Once-Heralded Apps.gov Cloud Storefront”, Tech Crunch, 2012.

(http://techcrunch.com/2012/12/04/a-disappointing-set-back-feds-close-the-one-heralded-apps-gov-cloud-storefront/)

[SLA12] G. Slabodkin: “IDC: Local government mobile app development to outpace federal state in 2013”, Fierce Mobile Government, 2012.

(http://www.fiercemobilegovernment.com/story/idc-local-government-mobile-app-development-outpace-federal-state-2013/2012-12-19?utm_medium=nl&utm_source=internal)

[CAR11] C. Carella: “Frost & Sullivan: m-Government Spinge il Mercato delle Tecnologie Mobili”, Frost & Sullivan, 2011.

(http://www.frost.com/prod/servlet/press-release.pag?docid=239918257)

[ANS12] Ansa: “Allo Smau 2012 la crescita ��dei canali digitali”, La


279

Stampa, 2012.

(http://www.lastampa.it/2012/10/11/tecnologia/allo-smau-la-crescita-dei-canali-digitali-GLW9uHgoJltn4Ap6wwgIsN/pagina.html)

[TAN10] L. Tan, N. Wang: “Future internet: The Internet of Things”, 3rd International Conference on Advanced Computer Theory and Engineering (ICACTE), 2010.

(http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5579543)

[MOG12] U. Moghe , P. Lakkadwala, D. K. Mishra: “Cloud computing: Survey of different utilization techniques”, Conference on Software Engineering (CONSEG), 2012 CSI Sixth International, 2012.

(http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6349524)

[SHA11] H. Shaffers, N. Komninos, M. Pallot: “Developing a Policy Roadmap for Smart Cities and the Future Internet”, eChallenges e-2011 Conference Proceedings, Paul Cunningham and Miriam Cunningham (Eds), IIMC International Information Management Corporation, 2011.

(http://www.urenio.org/wp-content/uploads/2008/11/2011-eChallenges_ref_196-Roadmap-for-Smart-Cities-Publised.pdf)

[GIA11] F. Giambarresi: “In Europa gli smartphone superano i cellulari”, WebNews, 2011.

(http://www.webnews.it/2011/09/12/in-europa-gli-smartphone-superano-i-cellulari/#ixzz1XusSbMiu)

[RUS12] F. Russo: “La diffusione del telefono cellulare dal 1991 al 2010”, InTime, 2012.

(http://www.franzrusso.it/condividere-comunicare/la-diffusione-del-telefono-cellulare-dal-1991-al-2010-animazione/)

[COX11] Anthony Cox: “Number of Entry-Level Smartphones to reach over 185 million by 2015, driven by Operator Own-Brand Initiatives and Falling Prices”, Press Release, Juniper Research, 2011.

(http://juniperresearch.com/viewpressrelease.php?pr=224)


280

[SAH03] D. Saha, A. Mukherjee: “Pervasive Computing: A Paradigm for the 21st Century”, IEEE Computer Society, 2003.

(http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1185214)

[TAR09] S. Tarkoma: “Mobile Middleware: Supporting Applications and Services”, Wiley, 2009.

[GAR12] K. Garg: “Mobile Computing: theory and practice”, Pearson, 2012.

[ZHE05] P. Zheng, L. Ni: “Smart Phone and Next Generation Mobile Computing”, Morgan Kaufmann, 2005.

[ABO05] G. D. Abowd, L. Iftode, H. Mitchell: “The Smart Phone--A First Platform for Pervasive Computing”, IEEE Pervasive computing, Vol. 4, P. 18-19, 2005.

(http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1427644)

[LAN10] N. D. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, A. T. Campbell: “A survey of mobile phone sensing”, Communications Magazine IEEE, 2010.

(http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5560598)

[SCH99] A. Schmidt, K. A. Aidoo, A. Takaluoma, U. Tuomela, K. Van Laerhoven, W. Van de Velde: “Advanced Interaction in Context”, Lecture Notes in Computer Science, Volume 1707/1999, p. 89-101, 1999.

(http://www.springerlink.com/content/f0d3d5a3ec9enb1r/)

[ABD09] F. B. Abdesslem, A. Phillips, T. Henderson: “Less is more: energy-efficient mobile sensing with senseless”, Proceedings of the 1st ACM workshop on Networking, systems, and applications for mobile handhelds, p. 61-61, ACM Digital Library, 2009.

(http://dl.acm.org/citation.cfm?id=1592621)

[WAN09] Y. Wang, J. Lin, M. Annavaram, Q. A. Jacobson, J. Hong, B. Krishnamachari, N. Sadeh: “A framework of energy efficient mobile sensing for automatic user state recognition”, Proceedings of the 7th international conference on Mobile


281

systems, applications, and services, ACM Digital Library, 2009.


[KAN09] E. Kanjo, J. Bacon, P. Landshoff, D. Roberts: “MobSens: Making Smart Phones Smarter”, Pervasive Computing, IEEE, 2009.

(http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=05280684)

[MIL08] E. Miluzzo, N. D. Lane, K. Fodor, R. Peterson, H. Lu, M. Musolesi, S. B. Eisenman, X. Zheng, A. T. Campbell: “Sensing meets Mobile Social Net- works: The Design, Implementation, and Evaluation of the CenceMe Application”, 6th ACM conference on Embedded network sensor systems, p. 337-350, 2008.


[MIL11] E. Miluzzo, M. Papandrea, N. D. Lane, H. Lu, A. T. Campbell: “Pocket, Bag, Hand, etc. - Automatically Detecting Phone Context through Discovery”, Computer Science Department, Dartmouth College, Hanover, 2011.

(http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf)

[WAN12] T. Wang, G. Cardone, A. Corradi, L. Torresani, A. T. Campbell: “WalkSafe: A Pedestrian Safety App for Mobile Phone Users Who Walk and Talk While Crossing Roads”, Twelfth Workshop on Mobile Computing Systems & Applications, Article No. 5, 2012.


[LUP09] H. Lu, W. Pan, N. D. Lane, T. Choudhury, A. T. Campbell: “SoundSense: Scalable Sound Sensing for People-Centric Applications on Mobile Phones”, Proceedings of the 7th international conference on Mobile systems, applications, and services, P. 165-178, 2009.


[NEU12] M. Neuburg: “Programming iOS 5, 2nd Edition”, O'Reilly Media, P. 1033, 2012.


282

[CON08] S. Consolvo, D. W. McDonald, T. Toscos, M. Y. Chen, J. Froehlich, B. Harrison, P. Klasnja, A. La Marca, L. Le Grand, R. Libby, I. Smith, J. A. Landay: “Activity sensing in the wild: a field trial of ubifit garden”, Proceedings of the SIGCHI conference on Human factors in computing systems, P. 1797-1806, 2008.


[PAP11] M. Papandrea, E. Miluzzo, N. D. Lane, A. M. Sarroff, S. Giordano, A. T. Campbell: “Tapping into the Vibe of the City Using VibN, a Continuous Sensing Application for Smartphones”, Proceedings of 1st international symposium on From digital footprints to social and community intelligence, P. 13-18, 2011.


[LAN08] N. D. Lane, S. B. Eisenman, M. Musolesi, E. Miluzzo, A. T. Campbell: “Urban sensing systems: opportunistic or participatory?”, Proceedings of the 9th workshop on Mobile computing systems and applications, P. 11-16, 2008.


[MUN09] M. Mun, S. Reddy, K. Shilton, N. Yau, J. Burke, D. Estrin, M. Hansen, E. Howard, R. West, P. Boda: “PEIR, the Personal Environmental Impact Report, as a Platform for Participatory Sensing Systems Research”, Proceedings of the 7th international conference on Mobile systems, applications, and services, P. 55-68, 2009.


[EIS08] S. B. Eisenman, N. D. Lane, A. T. Campbell: “Techniques for improving opportunistic sensor networking performance”, Lecture Notes in Computer Science, Vol. 5067/2008, P. 157-175, 2008.

[HON08] RJ Honicky, E. A. Brewer, E. Paulos, R. M. White: “N-SMARTS: Networked Suite of Mobile Atmospheric Real-time Sensors”, Proceedings of the second ACM SIGCOMM workshop on Networked systems for developing regions, P. 25-30, 2008.


[LIA07] L. Liao, D. Fox, H. Kautz: “Extracting Places and Activities


283

from GPS Traces Using Hierarchical Conditional Random Fields”, International Journal of Robotics Research, Vol. 26, Pag. 119-134, 2007.


[GPS00] GPS.ogv, Official U.S. Government information about the Global Positioning System (GPS).

(http://www.gps.gov/)

[STE04] S. Steiniger, M. Neun, A. Edwardes: “Foundations of Location Based Services”, Project CartouCHe – Cartography for Swiss Higher Education, University of Zurich, 2004.

(http://www.spatial.cs.umn.edu/Courses/Fall11/8715/papers/IM7_steiniger.pdf)

[GOO01] Google Maps – Location Based Services

(http://support.google.com/maps/bin/answer.py?hl=en&answer=1725632)

[SIN12] S. Singh: “Global Smartphone Market Share Trends: Android, iPhone Lead, Windows Phone Struggles, Tech-Thoughts”, 2012.

(http://www.tech-thoughts.net/2012/07/global-smartphone-market-share-trends.html#.UHgtDo4UWgc)

[AND00] Android Developers - App Framework

(http://developer.android.com/about/versions/index.html)

[HAN07] P. Hanik, “Inside the Java virtual Machine”, Covalent technologies, 2007.

(http://www.springsource.com/files/uploads/all/pdf_files/news_event/Inside_the_JVM.pdf)

[EHR10] D. Ehringer, “The Dalvil Virtual Machine Architecture”, 2010.

(http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf)

[GAV11] D. Gavalas, D. Economou: “Development Platforms for Mobile Applications: Status and Trends”, Software IEEE vol. 28, p. 77-86, 2011.


284

(http://ieeexplore.ieee.org/ielx5/52/5672507/05654492.pdf?tp=&arnumber=5654492&isnumber=5672507)

[DIM13] M. Di Marco: “Diffusione Android: cresce Jelly Bean, ma Gingerbread continua a dominare”, International Business Times, 2013.

(http://it.ibtimes.com/articles/42546/20130206/android-diffusione-jelly-bean-ice-cream-sandwich.htm)

[MAT07] A. Mathur, M. Cao, S. Bhattacharya, A. Dilger, A. Tomas, L. Vivier: “The new ext4 filesystem: current status and future plans”, IBM Linux Technology Center, 2007.

(http://kernel.org/doc/ols/2007/ols2007v2-pages-21-34.pdf)

[MAN12] C. Manning: “Yaffs Direct Interface”, YAFFS flash filesystem, 2012.

(http://www.yaffs.net/sites/yaffs.net/files/YaffsDirect.pdf)

[DEL04] M. Delio: “Linux: Fewer Bugs Than Rivals”, Wired, 2004.

(http://www.wired.com/software/coolapps/news/2004/12/66022)

[AND02] Android Developers – App Components

(http://developer.android.com/guide/components/index.html)

[GOO02] Google – Google Maps

(https://maps.google.it/)

[SQL01] SQLite

(http://www.sqlite.org/)

[SEM12] L. Sembera: “Comparison of JPA providers and issues with migration”, Graduate Thesis, Masaryk University, 2012.

(http://is.muni.cz/th/365414/fi_m/thesis.pdf)

[ORA99] Java Standard Edition Reference Documentation: “Dynamic Proxy Classes”, Oracle, 1999.

(http://docs.oracle.com/javase/1.3/docs/guide/reflection/proxy.html)


285

[SPR12] R. Johnson et al.: “Spring Framework Reference Documentation”, Spring Framework, 2012

(http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/)

[AND03] Android Developers - Google Cloud Messaging for Android

(http://developer.android.com/google/gcm/index.html)

Smart City E-R

Technology

Transcript of Smart City E-R