POLITECNICO DI MILANO. Corso di Laurea in Ingegneria Informatica. Dipartimento di Elettronica e Informazione

Transcript

1 POLITECNICO DI MILANO Corso di Laurea in Ingegneria Informatica Dipartimento di Elettronica e Informazione ViTe: Una piattaforma per la composizione di mashup basata su VIsual TEmplate Relatore: Chiar.ma Prof.ssa Maristella Matera Co-relatore: Ing. Matteo Picozzi Rovatti Maurizio, Matricola: Terrazzino Leonardo Savio, Matricola: Anno Accademico 2011/2012

2 Indice I Introduzione 7 1 Introduzione Obiettivi e motivazioni Struttura della tesi II Stato dell arte 14 2 Web Mashup I Mashup Sviluppo dei Mashup Sviluppo lightweight Composizione di Mashup Differenti livelli di integrazione Composizione a livello di presentazione End-User Development Strumenti per lo sviluppo di Mashup Yahoo! Pipes Quick and Easily Done Wiki Damia JackBe Presto Marmite MashArt

3 INDICE ServFace PEUDOM Piattaforme alternative Mobile Mashup Il Web nei dispositivi mobili Sviluppo di applicazioni mobili per l utente finale EUD di Mashup mobili Altre Piattaforme Multitouch Smart TV III Modelli e Architetture 50 4 Modelli di riferimento Approccio I visual template Il paradigma di composizione Lo schema dell applicazione L integrazione di sorgenti dati Architettura della piattaforma ViTe Il Design Environment Il visual front-end Il data panel Il visual panel Il repository dei servizi Il runtime environment Il configuration server L Execution Environment Data Fusion

4 INDICE Un esempio di composizione mappa generata Valutazioni Test con gli utenti Campione del test Metodologia del test Analisi dei dati Efficienza Facilità d uso Soddisfazione dell utente Affidabilità del Test IV Conclusioni Conclusioni e lavori futuri 109 V Appendice 111 A Pre-Questionario 112 B Post-Questionario 114 C Opinioni degli utenti 119 C.1 Vantaggi C.2 Suggerimenti Bibliografia 121

5 Elenco delle figure 2.1 Modello di tipo user-driven Guadagno vs costo con i mashup Differenti scenari di creazione di un mashup Rappresentazione dell integrazione dei dati su differenti layer Logo di Yahoo! Pipes Schermata del framework di Yahoo! Pipes Logo di IBM QEDWiki Scheramata del framework di QEDWiki Logo di JackBe Presto Schermata del framework di JackBe Presto Logo di ServeFace Schermata Peudom Mobile Mashup Editor Generazione delle applicazioni mobili con PhoneGap Schermata e workflow di ogni tool di composizione Dispositivo Multitouch SmartTv Architettura della piattaforma ViTe List-template Slider-template Charts-template

6 ELENCO DELLE FIGURE Map-template Schermata del DE e composizione visuale drag-and-drop Esempio Config.xml (1) Esempio Config.xml (2) Esempio Config.xml (3) Processo di integrazione dati Architettura del Design Environment (DE) Visual front-end del Design Environment (DE) Rappresentazione ad insiemi del documento XML Vista primaria e secondaria del Map-template Inserimento di una sorgente dati nella piattaforma Selezione di una sorgente dati della piattaforma Architettura Execution Engine (EE) Funzionamento della data-fusion nel template Map Esempio di data-fusion nel template Map Schermata principale Execution Environment (EE) Menù di selezione dell applicazione all interno dell EE Visteprimaria e secondaria del template Map nell EE Menu di ricerca e selezione dei filtri Distribuzione degli utenti in base alla fascia di età Tempo medio per ogni attività del task A Tempo medio per ogni attività del task B Valutazioni medie sulla facilità di utilizzo Risposte utenti alla domanda n

7 Elenco delle tabelle 3.1 Differenze tra mashup nativi e mashup web Descrizione delle sotto-attività per il test A Descrizione delle sotto-attività per il test B Descrizione delle sotto-attività per il test B (continua..)

8 Parte I Introduzione 7

9 Capitolo 1 Introduzione L evoluzione costante dell informatica ha portato alla diffusione di servizi basati su web e di varie tipologie di dispositivi in grado di interfacciarsi ed utilizzare tali servizi. Questo scenario, visto il grado di personalizzazione offerto da questi servizi, invoglia gli utenti a partecipare allo sviluppo delle proprie composizioni in modo da poter creare quelle più adatte alle proprie esigenze. Negli ultimi anni le tecnologie dei mashup sono perciò emerse, permettendo la definizione di paradigmi d i composizione alla portata degli utenti finali. In informatica un mash-up è un sito o un applicazione web di tipo ibrido, cioè tale da includere dinamicamente informazioni o contenuti provenienti da più fonti. Un esempio potrebbe essere un programma che, acquisendo da un sito web una lista di appartamenti, ne mostra l ubicazione utilizzando il servizio Google Maps per evidenziare il luogo in cui gli stessi appartamenti sono localizzati. Mash-up (letteralmente: poltiglia ), in termini informatici, indica un applicazione che usa contenuti da più sorgenti per creare un servizio completamente nuovo. Il contenuto dei mash-up è normalmente preso da terzi via API (Application programming interface), tramite feed (es. RSS e Atom) o Javascript. I mash-up stanno rivoluzionando lo sviluppo del web permettendo a chiunque di combinare dati da siti come Amazon.com, ebay, Google, Windows Live e Yahoo! in modi innovativi[39]. 8

10 CAPITOLO 1. INTRODUZIONE 9 Tuttavia, come dimostrato da alcune ricerche condotte negli ultimi anni [3], soltanto pochi utenti sono in grado di creare le proprie applicazioni programmando l integrazione dei servizi. Le principali difficoltà che gli utenti incontrano nascono, soprattutto, quando gli strumenti utilizzati in fase di progettazione non astraggono in modo adeguato dalle tecnologie e dai linguaggi di programmazione sottostanti. Inoltre, lo scenario appena descritto potrebbe risultare più critico se vengono introdotte le necessità, da parte dell utente, di avere a disposizione la propria composizione in ogni dispositivo con il quale è abituato ad interagire. Questo perché le tecnologie native dei vari dispositivi sono molto diverse tra loro e quindi difficili da essere gestite anche da utenti esperti di tecnologie. In questo contesto, i paradigmi di composizione e gli strumenti che astraggono dai dettagli implementativi potrebbero aiutare gli utenti, soprattutto i meno esperti, nella composizione di servizi. Tenendo conto delle osservazioni fatte fino ad ora, l obiettivo principe di questa tesi è lo sviluppo di un ambiente di lavoro per la costruzione lightweight, la composizione user-driven e il rilascio (deploy) della propria composizione di servizi. Il nostro framework è caratterizzato da un ambiente di sviluppo destinato all utente finale (End-User Development Desktop Environment), nel quale il completamento di template visuali permette agli utenti di unire più sorgenti dati e configurare in modo semplice i dati da visualizzare nelle proprie composizioni. Le applicazioni così create sono applicazioni native dei singoli dispositivi che, in contrasto coi Web mashup, non hanno necessariamente bisogno di un browser Web come ambiente di esecuzione. Questa caratteristica, in caso di utilizzo di dispositivi diversi dai comuni pc, facilita l accesso dell applicativo ai servizi nativi dell OS del dispositivo. Basandosi sul completamento di template visuali, l ambiente di design automaticamente genera e rilascia uno schema del mashup finale. Il motore di esecuzione dell applicazione è, quindi, in grado di scaricare

11 CAPITOLO 1. INTRODUZIONE 10 localmente e di interpretare lo schema: grazie a tecniche generative model-tocode, costruisce dinamicamente l interfaccia utente (UI) basata sui template visuali precedentemente completati durante la fase di design del mashup, e popola dinamicamente gli elementi visuali delle UI con i dati provenienti dai differenti servizi da cui si è deciso far confluire i dati. L applicazione finale, costruita attraverso le scelte dei servizi e le politiche di integrazione, mostra inoltre un ulteriore livello di flessibilità, dal momento che l utente è in grado di raffinare on the fly la selezione dei servizi. Questo aspetto di dinamicità, che possiamo definire col paradigma mashup-within-mashups, favorisce il riuso dei mashup mobili in differenti contesti d uso. 1.1 Obiettivi e motivazioni Alla luce delle precedenti considerazioni, crediamo vi siano numerose opportunità per la ricerca e lo sviluppo in quest area. Nel nostro lavoro siamo partiti introducendo la nostra prospettiva sulla composizione di servizi e quindi abbiamo proposto alcune astrazioni e modelli sostenuti anche dall implementazione di una piattaforma Web. In particolare, abbiamo introdotto i seguenti contributi: ˆ Processo di sviluppo leggero (lightweight development process). La scelta di sviluppare un applicazione per la composizione guidata di servizi nasce soprattutto dalla necessità di avere uno strumento di sviluppo facile e veloce da usare indipendentemente dalla tipologia di utente che la utilizza. Infatti, considerando la tipologia di utenti non esperti, è desiderabile avere un modello di mashup che nasconda la complessità del back-end e semplifichi il processo di aggregazione dei dati e dei servizi attraverso metafore più vicine all organizzazione di un front-end. Il nostro paradigma visuale di composizione, quindi, chiede all utente di completare template visuali predefiniti coi dati estratti dai servizi selezionati.

12 CAPITOLO 1. INTRODUZIONE 11 Gli utenti visivamente scorrono i dati dei servizi e mappano quelli di interesse sugli elementi del template visuale. In altre parole, gli utenti manipolano esattamente gli elementi visuali che vedranno e con cui interagiranno nell applicazione finale. Un editor di tipo WYSIWYG (What You See Is What You Get) permette loro di ottenere immediatamente esempi realistici sui dati che popoleranno gli elementi del template visuale e sul modo in cui i contenuti saranno fusi in un unica visualizzazione nel caso di più servizi coinvolti. ˆ Integrazione dei dati visual-oriented. Il nostro paradigma visuale di composizione supporta differenti tipi di integrazione: join di unione e d intersezione per creare viste integrate di dati provenienti da differenti core-service. La sfida principale è stata tuttavia quella di adottare uno schema di integrazione rappresentante la fusione dei dati a livello di presentazione, con l obiettivo principale di ottimizzare la fruizione del contenuto da parte degli utenti. Oltre a guidare il processo di composizione, la nozione di visual template guida l identificazione di schemi di integrazione locali (cioè di ciascuna sorgente) e globali permettendo alle applicazioni che devono eseguire la composizioni (Execution Environment) di applicare algoritmi di Data Fusion nel caso in cui i dati restituiti dai servizi selezionati siano riconducibili allo stesso elemento. ˆ Modello di composizione. Dopo aver creato la composizione, le astrazioni fondamentali, utili alla descrizione della composizione stessa, vengono incapsulate all interno di un linguaggio di descrizione che è automaticamente generato dall ambiente di design di Vite e quindi utilizzato dagli Execution Environment per la composizione dinamica dell applicazione finale. Guardando oltre la nostra implementazione web-based, che ha il semplice scopo di mostrare come è possibile utilizzare la descrizione creata in fase di sviluppo, il modello descritto in precedenza può essere riutilizzato in differenti piattaforme e ambienti di esecuzione client-side.

13 CAPITOLO 1. INTRODUZIONE 12 ˆ Dimostrazione dei concetti. Illustriamo un architettura di riferimento e inoltre forniamo un prototipo di implementazione basato su Web. Attraverso uno studio sugli utenti abbiamo anche validato l adeguatezza del paradigma di completamento di template visuali facendo riferimento alle abilità degli utenti. 1.2 Struttura della tesi La tesi è strutturata nelle seguenti parti: ˆ Parte II: Stato dell arte Capitolo 2: Web Mashup. In questo capitolo si introducono i mashup, quindi i componenti che li costituiscono, le loro funzionalità e le diverse tecnologie. Vengono discussi i paradigmi più comuni di composizione di mashup Web tramite componenti UI. Infine, si illustrano gli attuali tool a supporto dell utente per la creazione di composizioni Web. Capitolo 3: Piattaforme alternative. In questo capitolo vengono trattati i mashup che non fanno uso diretto del web, ovvero i mashup per piattaforme alternative come i dispositivi mobile, i multitouch informativi e le smarttv di ultima generazione. Dopo una breve introduzione sull attuale situazione e quindi sugli attuali trend di crescita e di sviluppo per queste piattaforme, si illustrano quali sono le maggiori potenzialità che offrono questi dispositivi. ˆ Parte III: Modelli e Architetture Capitolo 4: Modelli. Questo capitolo offre una panoramica dei modelli che sono stati utilizzati per l implementazione della piattaforma di sviluppo (Design Environment) e dell applicazione che esemplifica l utilizzo della composizione creata (Execution Engine).

14 CAPITOLO 1. INTRODUZIONE 13 Vengono introdotte le nuove astrazioni tramite cui gli utilizzatori finali, per mezzo di azioni visuali e guidati da template visuali (Visual-Template), sono in grado di costruire viste unificate con i dati estratti da più sorgenti. Successivamente si descrive il modello del mashup (schema-application) e il processo di integrazione dei dati. Capitolo 5: Architettura. In questo capitolo si illustra l architettura dell intera piattaforma, ViTe, per lo sviluppo di mashup multipiattaforma. In particolare vengono presentate, mettendone in risalto le peculiarità, le due componenti fondamentali: il Design Environment e l Execution Engine. L implementazione descritta riflette dunque i modelli illustrati nel capitolo 4. Capitolo 6: Valutazioni. Valutazioni. In questo capitolo, dopo una breve panoramica delle metodologie di conduzione dei test e della selezione del campione statistico, si illustrano i procedimenti utilizzati per effettuare i test con gli utenti finali. Dopo una prima analisi delle tempistiche di composizione, vengono stimate attraverso opportune metriche la soddisfazione degli utenti e la facilità d uso dell applicazione, sulla base di un questionario completato a fine test. ˆ Parte IV: Conclusioni Capitolo 7: Sommario e lavori futuri. In quest ultimo capitolo si riassumo i principali risultati che sono stati raggiunti e si delineano i lavori futuri. ˆ Parte V: Appendice Appendice A: Pre-Questionario Appendice B: Post-Questionario

15 Parte II Stato dell arte 14

16 Capitolo 2 Web Mashup In questo capitolo si introdurranno i Web mashup, quindi i componenti che li costituiscono, le loro funzionalità e le diverse tecnologie. Verranno dunque discussi i paradigmi più comuni di composizione di Web mashup tramite componenti UI. Infine, verranno illustrati gli attuali tool a supporto dell utente per la creazione di queste composizioni. 2.1 I Mashup La nascita e lo sviluppo di servizi secondo il paradigma SOA (Service Oriented Architecture) ha brevemente portato, nel corso degli anni, al concetto di riutilizzo e d integrazione delle risorse Web sotto forma di contenuti e servizi Web end-user. Una delle più grandi innovazioni che ha portato con se il nuovo approccio al Web, ossia il Web 2.0, sono stati, e sono tuttora, i Mashup: composizioni ibride di più Web service che integrate e fuse tra di loro generano un nuovo servizio, che comprende e integra contemporaneamente le caratteristiche e le informazioni di tutti i suoi componenti. Tali applicazioni Web si sono sviluppate sempre più velocemente grazie anche a siti come ProgrammableWeb.com, diventato nel corso degli ultimi anni uno dei riferimenti principali per gli sviluppatori di mashup specialmente per quanto riguarda la ricerca di componenti base. I Web Mashup sono dunque siti Web dinamici, 15

17 CAPITOLO 2. WEB MASHUP 16 composti da interfacce Web-user, che integrano logica e contenuti rilasciati da soggetti terzi tramite l utilizzo di opportune API (Application Programming Interface). I primi che hanno cominciato a rendere pubbliche le loro interfacce per poter accedere ai propri servizi sono stati i grandi Web competitor tra i quali spiccano i nomi dei soliti noti Google, Yahoo ed altri. La scelta di queste aziende di rendere pubblici i propri servizi è stata adottata con uno scopo principale: la diffusione di tali servizi. Conseguentemente, il numero di API è in continuo aumento poiché, per ogni nuovo Web Service creato, vengono rilasciate le specifiche e i dettagli necessari per la corretta fruizione del servizio. Tuttavia, a causa dell instabilità di un API, che potrebbe cambiare le sue specifiche da un momento all altro, costruire mashup ad hoc è una pratica poco diffusa. I mashup sono quindi una forma di composizione e di riuso di componenti pubblicati sul Web che genera un valore aggiunto agli stessi in quanto trova nuove forme di utilizzo, innovative e creative, che spesso vanno ben oltre lo scopo originario dei singoli componenti. Si ricordi che i primi mashup sviluppati erano basati soprattutto sul riuso di contenuti estratti da pagine Web a completa insaputa del proprietario originario dei contenuti circa il loro utilizzo finale. Tutto ciò a conferma che la composizione di applicazioni o processi a partire da servizi esistenti non è una disciplina nuova. Da anni la community dell Information Technology (IT) studia metodi e linguaggi di composizione per i cosiddetti Web service con risultati molto buoni (per es. BPEL [33]), e il campo dell integrazione dei dati è ormai un area consolidata, nonostante le nuove sfide poste da dati sempre più eterogenei e meno strutturati. La vera innovazione portata dal paradigma mashup risiede nel fatto che, oltre ai tradizionali metodi di integrazione dei dati e delle logiche applicative, fornisce anche un integrazione di elementi di presentazione visuale, grazie alla standardizzazione di certe tecnologie Web (si ricordi GoogleMaps). La pro-

18 CAPITOLO 2. WEB MASHUP 17 duzione di un mashup prevede una fase di prototipizzazione rapida, costituita da un integrazione veloce di differenti API e sorgenti dati, secondo un approccio orientato all utente (user-oriented). Uno dei principali punti di forza dei mashup risiede nel permettere a persone, sprovviste di particolari abilità di programmazione, di dare forma alle proprie idee innovative, in modo veloce e relativamente semplice. Figura 2.1: Modello di tipo user-driven [18] Lo sviluppo di un mashup è composto da un insieme di fasi che sono in relazione circolare [18]. Esso ha inizio nel momento in cui una persona incontra un problema nella vita di tutti i giorni. Dal momento che è relativamente facile costruire un mashup connettendo tra loro differenti servizi, la sua costruzione avviene iterativamente ed è guidata dal funzionamento desiderato. Partendo dunque da un determinato problema (come per es. la visualizzazione sulla carta geografica dei cinema) si passa alla fase di costruzione e di design che consiste nell integrare e sincronizzare tra loro servizi, sorgenti dati e widget disponibili sul Web. Nella fase seguente si avrà quindi la fruizione del mashup, che sarà correttamente funzionante fino alla decisione dell utente-sviluppatore di introdurre per esempio nuovi servizi o sopperire eventuali problemi (come la sostituzione di una sorgente dati a fronte dell interruzione di un servizio precedentemente utilizzato). Quindi il mashup viene utilizzato fino a quando non si riscontra un nuovo problema che sarà risolto applicando nuovamente il ciclo di vita. Si tratta di un modello adattativo che a partire dal problema iniziale si plasma su quelli successivi. La Figura 2.1 illustra il suddetto modello.

19 CAPITOLO 2. WEB MASHUP 18 I mashup, come abbiamo detto, riusano servizi e dati esistenti e non richiedono eccessive abilità proprie dell IT, garantendo la creazione di applicativi in breve tempo, con bassi costi di produzione e mantenimento [27]. Figura 2.2: Guadagno vs costo con i mashup [27] In ambito business i mashup permettono di suddividere i processi Enterprise in parti più piccole e modulari abilitando quindi il riuso di servizi già esistenti. Questo migliora il time-to-market e riduce i costi di sviluppo dell applicazione. In [27], è stato pronosticato che questo rappresenterà un sostanziale vantaggio competitivo per chi utilizzerà i mashup, mentre coloro i quali non lo adotteranno si ritroveranno inevitabilmente a essere svantaggiati. Ad oggi esistono più di 6000 mashup e oltre 4000 API Web che rappresentano i componenti principali nella creazione di mashup. In base al dominio operativo i mashup in genere possono essere classificati in tre categorie: ˆ mashup commerciali, di solito si possono definire come applicazioni che combinano risorse informative Enterprise con altri servizi Web in una singola presentazione. Il processo di sviluppo è flessibile poiché richiede la continua collaborazione tra gli sviluppatori e i clienti, per la definizione e l implementazione dei requisiti di business. I mashup aziendali dal punto di vista dell interfaccia utente presentano diverse somiglianze

20 CAPITOLO 2. WEB MASHUP 19 con le rich-internet-applications (RIA) per la dimensione di interattività, multimedialità e velocità di esecuzione. ˆ mashup di consumo, combinano diversi tipi di dati provenienti da molteplici fonti Web e li organizzano attraverso una, più o meno semplice, interfaccia utente Web-client. Per esempio HealthMap [25] che raccoglie diverse fonti di dati (per es., World Health Organization) per ottenere una visione unificata e completa, su una mappa GoogleMaps, dello stato attuale globale delle malattie infettive e il loro effetto sulla salute umana e animale. ˆ mashup di dati, combinano dati e informazioni simili provenienti da più fonti, in un unica rappresentazione. La combinazione di tutte queste risorse crea un nuovo e distinto servizio Web diverso da quelli di partenza. 2.2 Sviluppo dei Mashup La struttura dei mashup (composti da componenti modulari riutilizzabili) consente di poter progettare ambienti di sviluppo orientati all utente finale (enduser), cioè facili da usare da colui che deve usufruire del mashup stesso (userfriendly). Nella creazione dei mashup è possibile distinguere due approcci di sviluppo: ˆ automatizzato: è l approccio adatto all utente che è privo di capacità di programmazione. L utente inserisce ed utilizza componenti pronti all uso (ready-to-use) che gli sviluppatori della piattaforma di creazione del mashup hanno precedentemente preparato. La creazione del mashup consiste dunque nell assemblare questi componenti, generalmente tramite paradigmi di interazione visuali. ˆ manuale: l utilizzatore dell ambiente di creazione del mashup è un utente con ampie capacità di programmazione e dunque è in grado di scri-

21 CAPITOLO 2. WEB MASHUP 20 vere il codice di gestione dei componenti e definire la loro coreografia e orchestrazione. Il tipo di mashup spesso determina l approccio di sviluppo specifico. Per capire meglio la realtà del dominio dei mashup è necessario individuare gli attori (sviluppatori) che partecipano alla catena di creazione del mashup finale [24, 23, 8]: ˆ sviluppatori esperti di mashup: esperti nella produzione veloce di mashup di qualità tramite attività di programmazione. Gli utenti finali non sono direttamente coinvolti nella realizzazione. ˆ sviluppatori esperti nella creazione di servizi: esperti che sviluppano servizi che possono essere composti in mashup e possono fornire una sandbox in cui gli utenti finali combinano loro stessi i mashup. Il ruolo degli sviluppatori è quello di creare i servizi, mentre i mashup sono costruiti dagli utenti più vicini al dominio dell applicazione. ˆ sviluppatori di piattaforme di costruzione di mashup: sono coloro i quali sviluppano il tool che consente di assemblare i componenti che serviranno alla creazione del mashup. La Figura 2.3 mostra i differenti tipi di scenari nello sviluppo di mashup. Quando i mashup sono costruiti centralmente (scenario A), le risorse per lo sviluppo del mashup sono limitate agli esperti sviluppatori del dipartimento IT. Vista questa limitazione, verranno create solo quelle applicazioni abitualmente richieste. Comunque questo tipo di approccio permette di creare ogni tipo di applicazione proveniente da servizi eterogenei.

22 CAPITOLO 2. WEB MASHUP 21 Figura 2.3: Differenti scenari di creazione di un mashup [8, 24] Quando il dipartimento IT focalizza le sue energie nel fare componenti standardizzati, questi possono essere utilizzati anche da utenti non sviluppatori (scenario B). Questi utenti generalmente hanno una comprensione maggiore del dominio dell applicazione rispetto agli esperti dell IT che hanno creato lo strumento di mashup. Questo scenario di solito consente un basso livello di integrazione dati e di parametrizzazione dei componenti data la poca abilità

23 CAPITOLO 2. WEB MASHUP 22 di programmazione degli utenti. Nell ultimo scenario (C) è possibile notare la presenza di un tool per la creazione del mashup. E lo scenario che rappresenta la sfida più grande per lo sviluppatore e allo stesso tempo il più grande pay-off. Usando il suddetto tool gli utenti sono in grado di crearsi il proprio mashup. Le possibilità di composizione sono limitate alle diverse combinazioni dei componenti offerti dal tool. Gli utenti tuttavia non hanno limiti riguardo i di tipi di applicazioni che possono costruire. Questo scenario si potrebbe dire che copre la maggior parte di bisogni degli utenti. Un altra caratteristica che differenzia gli scenari sopra proposti è il livello di controllo della qualità dei mashup che vengono creati. Comprensibilmente si può immaginare che la qualità del mashup dello scenario A sarà molto elevata dato che sarà un mashup costruito ad-hoc da un esperto ITC. Comunque, anche mashup di questo tipo possono essere carenti di caratteristiche quali sicurezza, performance o affidabilità. Inoltre una soluzione complessa e ingombrante perderebbe i vantaggi tipici dei mashup come costi e tempi di creazione. Gli scenari B e C danno dunque una maggiore libertà all utente di scegliere e creare le proprie applicazioni. Secondo Hippel [36], i mashup danno una sorta di democraticità all innovazione, permettendo agli utenti di conciliarsi con i propri bisogni, superando i centri di calcolo e i service provider che spesso non sono in grado di soddisfarli. Come detto prima, una potenzialità dei mashup è quella di permettere la creazione veloce di prototipi che risolvono problemi specifici. Tali prototipi possono poi evolvere verso soluzioni generali. Per esempio, cambiando semplicemente le sorgenti dati è possibile creare mashup per differenti contesti d uso, mantenendo la struttura del prototipo iniziale.

24 CAPITOLO 2. WEB MASHUP Sviluppo lightweight Poiché, come è risaputo, i mashup sono principalmente applicazioni Web, il loro processo di sviluppo presenta le stesse caratteristiche delle applicazioni Web generiche. Nello sviluppo per il Web le tempistiche di produzione sono diverse rispetto alle tempistiche tradizionali di sviluppo software. Per esempio, laddove la produzione software richiede mesi o anni, nella produzione Web i tempi si restringono a settimane o a volte anche giorni. Si tratta dell Internet-time (cioè l accesso rapido all informazione ovunque), che rende i processi di costruzione molto dinamici. Inoltre, anche se un applicazione è pronta ed è rilasciata in rete, essa può continuare a funzionare anche se nel back-end avvengono delle modifiche sul software. I processi cosiddetti leggeri (lightweight) di creazione del mashup, possono essere schematizzati in tre diverse attività: ˆ ricerca e selezione: partendo da una determinata idea e arricchendola con i bisogni personali, l utente (compositore) seleziona sia i servizi che forniscono i dati a lui necessari e sia le interfacce utente per la realizzazione della sua applicazione. Questa attività, dunque, implicitamente contiene l analisi dei requisiti e delle specifiche. Il programmatore che costruisce la piattaforma deve aver preparato precedentemente il wrapping per ogni componente API, che l utente utilizzerà. Il wrapping è uno strato di astrazione software in grado di interagire con l API del servizio per poterlo interrogare. ˆ composizione del mashup: i tool di costruzione di mashup permettono agli utenti con scarse o anche nulle abilità di programmazione Web di comporre graficamente i componenti selezionati e di farne il setting per la necessaria integrazione logica dell applicazione composta. La reale parametrizzazione è nascosta all utente che a video dovrà eseguire solo semplici passi assistito dal tool. Questa attività è sostanzialmente diversa dai tradizionali metodi di design e d implementazione. In particolare, evita quelle attività che tradizionalmente sono obbligatorie, come per esem-

25 CAPITOLO 2. WEB MASHUP 24 pio il design. Il rilascio (deploy) dell applicazione mashup sarà eseguito semplicemente salvando l applicazione nel server. Quando il compositore (compositor) effettua il collegamento tra i diversi componenti è il tool di mashup che crea il codice di collegamento (binding) sottostante. Dunque il compositore deve solo interagire con i componenti eseguendo semplici operazioni di drag-and-drop o di selezione nei menu presenti. ˆ uso e manutenzione: una volta che il mashup è stato salvato e depositato sul server di hosting, il mashup sarà pronto all uso. Il mantenimento dell applicativo avviene quindi semplicemente a livello di composizione. 2.3 Composizione di Mashup Nello sviluppo del software uno dei più grandi dilemmi è quello di rilasciare un prodotto che trovi un punto di intersezione tra quelli che sono i bisogni e quelle che sono le preferenze dell utente che lo utilizza. In tutti i modelli di sviluppo del software una parte importantissima è proprio la validazione da parte degli utenti che utilizzano l applicazione, cioè la validità dell oggetto (manufact) che è stato creato con l applicativo. In caso di non corrispondenza tra quello che l utente è riuscito a produrre e quello che voleva ottenere, egli dovrà continuare a iterare il ciclo di produzione/composizione fino a trovare il risultato desiderato. Come si può intuire, questo aspetto potrebbe rilevarsi determinante in termini sia di tempo che di denaro. Per fare un esempio, caliamoci nei bisogni di ingegneri, fisici, geologhi, astrofosici ovvero di tutte le possibili figure professionali. In questi domini di lavoro, un tool di facile utilizzo, che permetta loro di creare applicazioni tramite un processo di sviluppo lightweight, che produca esattamente e in breve tempo ciò di cui hanno bisogno, potrebbe aumentare drasticamente la loro produttività. Per superare le tradizionali demarcazioni tra utente finale e designer delle applicazioni, è stato necessario proporre nuovi modelli che si discostano dal classico

26 CAPITOLO 2. WEB MASHUP 25 modello waterfall top-down. Negli ultimi anni, la rivoluzione del Web 2.0 ha enfatizzato la cultura della partecipazione. Si tratta di un paradigma dove la distanza tra designer e utente è spesso esigua e gli utenti finali sono sempre più spesso guidati nel gioco di costruzione di contenuti e di applicazioni. Anche se questa soluzione incrementa notevolmente il coinvolgimento dell utente, lo sviluppo di tipo end-user non è la soluzione a tutti i problemi e spesso non permette la creazione di una soluzione completa. Consapevoli di ciò, il nostro lavoro è stato anche quello di dimostrare che sotto adeguate ipotesi e vincoli, un utente finale, tramite interfacce user-friendly è in grado di creare applicazioni mashup adattabili a diverse tipologie di dispositivi che altrimenti gli sarebbero impossibili da creare. Si cercherà ora di descrivere i framework più utilizzati e proposti in letteratura [11] per la semplificazione dello sviluppo Differenti livelli di integrazione L integrazione può avvenire in forme diverse. In generale si distinguono 3 classi principali: l integrazione dei dati, l integrazione delle applicazioni e l integrazione delle interfacce utente. L integrazione dei dati (vedi Figura 2.4 (a)) presenta diversi problemi che vanno dalla risoluzione dei disallineamenti tra i modelli dei componenti dei dati, alla costruzione e alla manutenzione di modelli dei dati e mapping eseguiti tramite query di schemi globali e locali. Richiede una scarsa collaborazione fra componenti e la comprensione della semantica del modello dei dati dei componenti. Figura 2.4: Rappresentazione dell integrazione dei dati su differenti layer

27 CAPITOLO 2. WEB MASHUP 26 Nell integrazione a livello di applicazione (vedi Figura 2.4 (b)), un applicazione composita ha una sua interfaccia utente, ma il livello di logica business è sviluppato attraverso l integrazione di funzionalità che le applicazioni componente (component-applications) offrono. Naturalmente questo approccio funziona molto bene quando le applicazioni componente espongono un API che viene mantenuta stabile nelle le versioni. L integrazione delle interfacce utente (vedi Figura 2.4 (c)) mira a comporre applicazioni a livello di presentazione, lasciando la gestione dei dati e della logica di business a ciascun componente. L integrazione UI è applicabile quando l integrazione a livello dati o applicazione non è fattibile e quando lo sviluppo di una nuova interfaccia utente è troppo costosa. Per esempio quando le applicazioni non espongono le API di livello business. Nell integrazione dell interfaccia utente è possibile quindi individuare quattro passi: ˆ definizione dei modelli e dei linguaggi per le specifiche dei componenti. ˆ definizione dei modelli e dei linguaggi per le specifiche di composizione dei componenti. ˆ scelta degli stili di comunicazione per l interazione dei componenti. ˆ definizione della ricerca delle fonti dati, dei componenti e il meccanismo di binding per la sincronizzazione dei componenti Composizione a livello di presentazione Storicamente, le prime composizioni di componenti di presentazione sono nate per applicazioni desktop, per poi col tempo migrare verso tecnologie sempre più indipendenti dal sistema operativo. E vero che queste tecnologie erano indipendenti, ma necessitavano dei loro rispettivi ambienti di runtime (per esempio JVM per RCP). Gli approcci che generalmente a oggi si usano sono:

28 CAPITOLO 2. WEB MASHUP 27 ˆ componenti di plugin per browser: l esperienza di navigazione nel browser spesso coinvolge caratteristiche di interfaccia utente avanzate. Dopo la definizione del binding dei componenti durante la scrittura della pagina da parte del Web designer, il browser scarica i componenti e a runtime vengono istanziati. Questi componenti spesso rendono disponibile la modifica della loro modalità di visualizzazione (rendering), per mezzo di ulteriori comunicazioni tra loro e la pagina Web che li contiene. Solitamente le interfacce, che sono messe a disposizione del cliente, sono molto semplici e spesso richiedono solo una una piccola modifica al codice di markup della pagina per essere incorporate. ˆ Web mashups: come già spiegato i mashup sono particolari applicazioni Web che consentono l integrazione, su differenti livelli, di servizi, API o sorgenti dati messi a disposizione in rete. I mashup sono dunque composti da parti atomiche chiamate componenti (components) che, sincronizzati e debitamente orchestrati, consentono l integrazione di diversi contenuti e generano un applicazione con valore aggiunto. ˆ Web portals e portlets: sono altresì forme di composizione nella creazione di applicazioni Web. In particolar modo i portlet sono applicativi software componibili e interfacciabili tra loro, che compongono un portale Web. Un esempio classico sono i componenti di interfaccia utente che possono arricchire un portale, come calendari, condizioni meteo o . Ciascun portlet è quindi una semplice applicazione a sé stante che può essere chiusa o aperta dall utente in base alle sue preferenze e avendo quindi la possibilità di personalizzare la propria pagina in tempo reale End-User Development Una nozione che è importante introdurre ai fini della comprensione del nostro framework di lavoro, sono i principali approcci di composizione e sviluppo esistenti:

29 CAPITOLO 2. WEB MASHUP 28 ˆ End-User Programming (EUP): permette all utente il potenziamento e il supporto alla costruzione del software tramite: pragrammazione per dimostrazione (programming by demonstration) paradigmi visuali programmazione visuale (visual programming) linguaggi di scripting e linguaggi specifici del dominio di applicazione ˆ End-User Software Engineering (EUSE): integra, oltre agli aspetti tipici dell approccio EUP (End User Programming) anche attività a supporto dell affidabilità, dell usabilità, dell efficienza e del controllo della versione. ˆ End-User Development (EUD): simile all EUP, è un approccio orientato allo sviluppo di applicazioni molto diverse fra loro, che spaziano per esempio dalle creazioni 3D ai mock-up di prototipi. Questo approccio sia astrae completamente dal linguaggio di programmazione vero e proprio. Il nostro approccio è quindi di tipo EUD. La nostra piattaforma è in grado di fornire all utente differenti tipi di soluzioni a problemi generalmente riscontrati nell utilizzo di sorgenti Web. Anche un utente end-user, con scarse o nulle capacità di programmazione, sarà in grado di compiere azioni come comporre applicazioni mashup o integrare intelligentemente sorgenti dati Web. La questione della facilitazione della creazione di applicazioni a partire da componenti Web appartiene a una delle più vaste aree di investigazione in abito software engineering e data management [10]. D altro canto, mentre questi studi hanno semplificato l integrazione a livello dati e applicativo, si è avanzato poco nel facilitare l integrazione a livello di presentazione. Coloro i quali hanno sviluppato applicazioni grafiche sono a conoscenza che lo sviluppo di interfacce grafiche è una delle parti che necessitano più tempo nelle fasi di

30 CAPITOLO 2. WEB MASHUP 29 sviluppo, come il testing e la manutenzione. Questo ci suggerisce che è buona norma, o meglio essenziale, il riuso anche di componenti dotati di una propria interfaccia utente (i cosiddetti componenti UI), quali Google Maps, YouTube e Flickr. Comunque, oggigiorno lo sviluppo di UI è facilitato da diversi framework (per es., Java Swing), che forniscono componenti grafici come bottoni, menu e simili. Il fatto però di poter disporre di interfacce stand-alone negli applicativi (per esempio GoogleMaps), è oggetto negli ultimi anni di una certa attenzione. 2.4 Strumenti per lo sviluppo di Mashup Al fine di velocizzare lo sviluppo di mashup e rendere possibile la creazione di quest ultimi anche agli utenti poco esperti in materia di programmazione, sono nati numerosi tool e piattaforme di sviluppo. Ognuno di questi ambienti porta con se differenti approcci di creazione. Per poter avere una visione globale più chiara, vediamo in sintesi le particolarità e le funzionalità dei tool più diffusi e rappresentativi Yahoo! Pipes Figura 2.5: Logo di Yahoo! Pipes Partendo da una o più sorgenti dati (data feed), attraverso un editor a interfaccia visuale e azioni drag-and-drop è possibile creare la propria applicazione [42]. Questo tool si basa su un data processing pipeline (costruzione a stadi), che consiste nell interconnessione, tramite operatori, di più sorgenti dati, come per esempio dati di tipo feed, XML o RSS/Atom.

31 CAPITOLO 2. WEB MASHUP 30 Gli operatori principali sono quelli che consentono la manipolazione dei dati (per esempio filtering o sorting) e i più sofisticati sono gli operatori di looping, di espressioni regolari o di conteggio. Inoltre è possibile effettuare operazioni di local data extraction (come per esempio le coordinate geografiche della posizione attuale) oppure una estrazione più globale su tag o parole chiave di generiche fonti dati (terms extraction). Figura 2.6: Schermata del framework di Yahoo! Pipes Quick and Easily Done Wiki Figura 2.7: Logo di IBM QEDWiki Proposto da IBM [15], è un tool a supporto della creazione di mashup, che viene eseguito all interno del browser e che viene supportato dall accesso all IBM Mashup Hub. Grazie all hub messo a disposizione da IBM è possibile creare data feed e widget. I mashup così creati, sono immediatamente visibili e vi è la possibilità di rieditarli e condividerli subito nel Web. I mashup risultanti sono dunque costituiti principalmente da widget basati su tecnologie come

32 CAPITOLO 2. WEB MASHUP 31 JavaScript o PHP e i loro collegamenti ne determinano il funzionamento. La costruzione del mashup avviene a partire da una pagina HTML che fa da template. Su di essa vengono disposti i vari widget che sono collegati fra loro in modo tale da imprimergli il comportamento finale desiderato. Figura 2.8: Scheramata del framework di QEDWiki Damia DAMIA [26], prodotto anch esso dall IBM, è basato su un interfaccia client Web che mette a disposizione a sviluppatori e a utenti, un set di tool easy-touse per raggruppare insieme dati Web (per es., feed o RSS) con sorgenti dati Enterprise (per esempio dati di tabelle Excel o di DataBase). Sono proprio i benefici dell integrazione di differenti varietà di dati a rendere DAMIA uno strumento molto apprezzato nella creazione di mashup Enterprise. DAMIA, in particolare, mette a disposizione le seguenti funzionalità: ˆ import di dati locali come fonti Excel o provenienti da database. ˆ import di dati XML, Atom e feed RSS provenienti dal Web. ˆ unione di fonti di dati Internet ed Enterprise.

33 CAPITOLO 2. WEB MASHUP 32 ˆ integrazione dati in modo da renderli usufruibili dai tool di mashup, che sono in grado di presentarli tramite opportuni componenti di presentazione. Per quanto riguarda la composizione strutturale di DAMIA si evidenziano i seguenti aspetti: ˆ interfaccia Web browser per l accorpamento, la modifica e la visualizzazione dei dati. ˆ diverse funzionalità per la gestione e la composizione dei dati Web e dei dati Enterprise. ˆ uno spazio Web dove immagazzinare o permettere lo sharing dei nuovi feed creati JackBe Presto Figura 2.9: Logo di JackBe Presto Questo tool, fornisce una piattaforma orientata alla creazione di composizioni di servizi dedicati al mondo Enterprise [29]. Offre quindi un valido supporto sia a sviluppatori software sia a utenti avanzati (power user). Le principali funzionalità che si evidenziano in JackBe Presto sono: ˆ composizione di mashup attraverso interfacce grafiche, tool di drag-anddrop e un linguaggio dichiarativo adatto ai mashup Enterprise. ˆ supporto all Enterprise Mashup Markup Language (EMML[1]). ˆ accesso ai servizi Web, database SQL, fonti RSS e Web clipping.

34 CAPITOLO 2. WEB MASHUP 33 ˆ interfacce per collegamento ai principali tool Enterprise come Oracle WebCenter, HP Sysnet e Excel di Microsoft. Figura 2.10: Schermata del framework di JackBe Presto Marmite Marmite è anch essa una piattaforma [14] che permette di ottenere come risultato un mashup. Questo tool ha come obiettivo la creazione da parte dell utente finale, che non dispone di particolari capacità di programmazione, del proprio mashup. Marmite permette di: ˆ accedere in modo facilitato alle API dei Web service. ˆ connettere le API dei Web service con semplici tecniche di combinazione a video. ˆ avere uno strumento che dispone di operatori sui dati, sui flussi di dati e sulla loro visualizzazione e rappresentazione MashArt L approccio di MashArt [5] si basa nell aiutare programmatori non professionali, con tecniche e astrazioni easy-to-use, a creare e gestire applicazioni Web composite. In particolar modo MashArt fornisce le seguenti funzionalità:

35 CAPITOLO 2. WEB MASHUP 34 ˆ un modello unificato di componenti, capace di astrarre in componenti UI (HTML), parti di applicazioni logiche (SOAP e servizi RESTful) e sorgenti dati Web (feed o XML) usando un modello unificato di viste. ˆ un modello a composizione universale che permette a MashArt di conciliare sia i bisogni di sincronizzazione di UI e sia l orchestrazione dei servizi. ˆ una piattaforma di sviluppo ed esecuzione che facilita la creazione, il testing e il mantenimento dell applicativo. MashArt è interamente residente nel layer server side e dunque completamente Web-based (zero client-side coding) ServFace Figura 2.11: Logo di ServeFace ServeFace [34] è una piattaforma a supporto della creazione di servizi modeldriven, pensata per lo sviluppo integrato di applicazioni basate su servizi. Le interfacce utente sono create automaticamente a partire dai descrittori dei servizi come WSDL. Per la composizione dei servizi sono possibili due approcci differenti: ˆ Composizione di un servizio orientato alla presentazione (presentationoriented service composition), nel quale la creazione del servizio avviene modellando graficamente l applicativo tramite tecniche di UI. ˆ Composizione di servizi dedicati a specifici obiettivi (task-oriented servicecomposition), che sfruttano certi modelli di interfacce grafiche per gene-

36 CAPITOLO 2. WEB MASHUP 35 rare una nuova soluzione, creata specificatamente per una particolare piattaforma, come per esempio gli smartphone PEUDOM Infine, per concludere con gli ambienti di sviluppo mashup EUD, è importante citare PEUDOM [38]. Questa proposta, per lo sviluppo di mashup, è basata su un paradigma totalmente visuale, che cerca di astrarre il più possibile il processo di sviluppo da competenze tecniche. Come si evince dalla Figura 2.12, un tipico scenario di sviluppo è quello in cui l utente ha a disposizione una serie di componenti creati a partire da servizi e widget Web. Essi sono quindi descritti in modo tale da esporre le proprie operazioni e parametri. L utente quindi, grazie alle opportune descrizioni, ha modo di sapere come invocare correttamente i suddetti servizi senza dover programmare la logica di invocazione delle operazioni che essi espongono. Figura 2.12: Scenario per l EUD di mashup in PEUDOM [21]

37 CAPITOLO 2. WEB MASHUP 36 L utente crea il proprio mashup tramite semplici operazioni visuali di dragand-drop, visualizzando immediatamente il servizio invocato tramite opportune componenti UI. Potrà, a questo punto, creare legami di sincronizzazione selezionando tra i possibili comportamenti messi a disposizione dai servizi registrati. Il motore di esecuzione della piattaforma, infine, provvederà a eseguire il mashup orchestrando la composizione. La conoscenza di tutte queste soluzioni di tipo EUD per la creazione guidata di applicativi Web ci permetterà di capire nel seguente capitolo (capitolo 3) come è possibile applicare queste tecniche di composizione anche in ambito mobile, per arrivare quindi identificare un paradigma di composizione EUD di mashup, per dispositivi mobili.

38 Capitolo 3 Piattaforme alternative In questo capitolo illustreremo canali alternativi di sviluppo ed esecuzione dei mashup, con particolare attenzione all attuale situazione del mondo mobile, alle potenzialità offerte da questi dispositivi ed ai principali paradigmi di sviluppo. Sarà offerta infine una panoramica su alcune delle piattaforme di ultima generazione quali i terminali Totem\Multitouch o le SmartTV. 3.1 Mobile Mashup Il Web nei dispositivi mobili L universo Mobile è un ambito in continua espansione: si è evoluto a partire dai primi telefoni cellulari degli anni 80 e la sua diffusione è stata tale da rendere normale il fatto che la maggior parte della popolazione giovane e adulta abbia almeno un telefono cellulare. L evoluzione dei dispositivi mobili è guidata dagli avanzamenti nell ambito delle infrastrutture, dei protocolli e delle funzionalità di rete e dall evoluzione delle tecnologie hardware e software. Le ultime tecnologie hardware hanno permesso ai dispositivi mobili di ultima generazione di avere a disposizione una potenza di calcolo superiore a quella di un PC di inizio anni 90. A differenza delle prime generazioni di dispositivi mobili, le ultime generazioni non sono più semplici telefoni cellulari, ma ter- 37

39 CAPITOLO 3. PIATTAFORME ALTERNATIVE 38 minali con certe funzionalità tipiche dei PC (per es., accesso internet, , social network). Inoltre sono sempre più diffusi i dispositivi tablet, in grado di connettersi alle reti cellulari o Wi-fi per accedere a Internet. Un recente studio [21] afferma che al giorno d oggi l Internet Mobile sta crescendo molto più velocemente dell Internet a livello desktop a causa della convergenza dei seguenti trend [27]: ˆ connessione internet 3G ˆ social networking ˆ video streaming ˆ VoIP Inoltre si sostiene che nell arco dei prossimi cinque anni i dispositivi mobili saranno il primo mezzo di accesso a Internet con un livello di utilizzo 10 volte superiore rispetto a quella dei dispositivi fissi [27]. Oltre a considerare la grande evoluzione che c è stata a livello hardware, è importante tener conto dell evoluzione del software per i dispositivi mobili. I moderni sistemi operativi mobili consentono all utente di poter installare veri e propri applicativi software, all interno del proprio terminale. I più importanti player in questo ambito sono attualmente Apple e Google che, creando rispettivamente App Store e Android Play Store, hanno messo a disposizione degli utenti più di un milione di applicazioni ( per App Store, di cui più di per ipad, e per Android Play Store), create non solo dalle aziende produttrici dei sistemi operativi ma anche da terze parti o da utenti sviluppatori. Le applicazioni disponibili, per esempio dell App Store di Apple, sono divise su circa 20 categorie e spaziano dall intrattenimento alla finanza, alla medicina.

40 CAPITOLO 3. PIATTAFORME ALTERNATIVE 39 Esistono, sostanzialmente, due tipi di applicazioni: applicazioni native, realizzate usando gli ambienti di sviluppo (SDK) messi a disposizione dai principali produttori di sistemi operativi mobili, o Web App, cioè applicazioni per l accesso a contenuti Web ottimizzate per i browser dei dispositivi mobili. La crescente capacità degli attuali dispositivi mobili di interfacciarsi ai servizi, calcolare dati e visualizzare risultati, unitamente alla loro capacità di rendere più accessibili le informazioni agli utenti finali tramite l utilizzo di interfacce grafiche (appositamente studiate per essere user friendly) ha reso lo sviluppo di tali applicazioni una delle attività chiave per programmatori e fornitori di servizi. Nonostante le migliorate capacità dei dispositivi mobili, il fornire l accesso all informazione giusta nel momento giusto continua a essere una sfida. Poiché i mashup sono stati concepiti con l obiettivo di raccogliere dati da sorgenti diverse per una fruizione più facile e integrata, risulta di facile comprensione il loro crescente utilizzo in ambito mobile. Per esempio, la visualizzazione di dati geo-localizzati su una mappa, cioè il mashup di servizi di mappe con sorgenti di dati localizzati geograficamente, risulta una delle tipologie di applicazioni mobili più utilizzate. La combinazione tra la flessibilità dei mashup e la pervasività dei dispositivi mobili svela infatti un mondo nuovo, quello del Mashup Mobile, la cui potenzialità è soddisfare le necessità specifiche nascoste nella long tail [19]. Non sorprende, quindi, l ampio consenso per questo tipo di applicazioni anche in ambito mobile, aumentando la diffusione di mashup mobili. D altro canto, una delle più grandi limitazioni nella produzione di software per i dispositivi mobili è quella di dover attenersi alle restrizioni hardware e alle specifiche proprie di ogni telefonino, il che non è facile, data la grande vastità di tipi di dispositivi e di fornitori. La varietà di linguaggi di programmazione

41 CAPITOLO 3. PIATTAFORME ALTERNATIVE 40 per ogni dispositivo hanno quindi reso ardua per lo sviluppatore software la scelta di programmare in modo approfondito su questi dispositivi Sviluppo di applicazioni mobili per l utente finale Quando si parla di mashup mobili si può fare una differenziazione tra mobile Web mashup, costruiti utilizzando tecnologie Web tradizionali ed eseguiti nel browser Web del dispositivo mobile, e mobile mashup, sviluppati per essere eseguiti come applicazioni native, basate sulle tecnologie proprie del sistema operativo del dispositivo. Nella tabella sottostante si evidenziano le principali differenze tra i mashup mobili nativi e i mashup Web mobili. Da questa tabella si evince come un applicativo generico per mobile, costruito tramite interfaccia Web, presenti, a nostro avviso, molte potenzialità. Mashup Nativi Completa esperienza dell utente Accesso completo al OS e all HW Facilità di discovering, market app store Facilità di scale up Supporto off-line Web Mashup Facilità e pochi costi di creazione e manutenzione Sviluppatori liberi di usare tecnologie e tecniche conosciute e tools Facile pubblicazione, senza tool intermedi Nessuna necessità di update: è cloud based Processi di revisione degli apps store non necessari Tabella 3.1: Principali differenze tra mashup mobili nativi e mashup mobili creati attraverso la composizione di interfacce Web. Nonostante l utilità percepita, la composizione di mobile mashup da parte degli utenti finali è ancora una problematica aperta. Infatti la maggior parte dei mashup mobili esistenti non sono altro che applicazioni con una logica cablata

42 CAPITOLO 3. PIATTAFORME ALTERNATIVE 41 e non modificabile che invocano e integrano servizi diversi. La sfida principale attuale è quella di promuovere in ambiente mobile i mashup come strumenti per l EUD, cioè in grado di dare la possibilità agli utenti finali di comporre le proprie applicazioni aumentando in modo concreto e pervasivo la flessibilità offerte all utente-sviluppatore. Trattandosi di dispositivi mobili, quindi con caratteristiche diverse dai desktop tradizionali come la ridotta dimensione dello schermo, la diversa modalità di interazione, e i differenti tempi di attesa fra le richieste inviate e il tempo di ricezione della risposta, quando si parla di EUD non è possibile pensare alle stesse modalità di composizione adottate in ambienti desktop. Le necessità emergenti sono, quindi, quelle di fornire strumenti che permettano, in modo semplice e intuitivo la creazione di applicazioni mashup native, personalizzate o personalizzabili. Per raggiungere quest obiettivo è possibile percorrere due strade diverse. La prima è quella di trasferire la logica di composizione direttamente sui dispositivi mobili. Tuttavia, i framework risultanti, essendo molto semplici, permettono all utente di definire solo delle micro-applicazioni [37] che si rivelano molto limitate. La seconda soluzione potrebbe essere quella di definire un ambiente desktop che generi file di configurazione utilizzabili per guidare l esecuzione di un applicazione predefinita ( scheletro ). Con il termine mobile mashup vengono dunque definite le applicazioni mobili native costruite a partire dall integrazione dei dati provenienti da differenti servizi che possono essere remoti (per esempio disponibili nel Web), o locali (cioè disponibile all interno del terminale mobile). In accordo con il nostro punto di vista, per poter rientrare nei bisogni contestuali degli utenti, le applicazioni mobili finali, dovrebbero presentare anche ulteriori livelli di flessibilità: l integrazione e la sincronizzazione definite durante la fase di design potreb-

43 CAPITOLO 3. PIATTAFORME ALTERNATIVE 42 bero, ancora una volta, essere ridefinite dinamicamente dagli utenti, i quali sceglierebbero on the fly i servizi di cui, in un dato momento, potrebbero aver bisogno. Indipendentemente dalla classe di mashup mobili (sopra illustrati) e dai servizi scelti, per avvantaggiarsi del potenziale del paradigma mashup, l utente deve essere in grado di comporli, secondo il paradigma EUD [19, 4] EUD di Mashup mobili Ad oggi, lo sviluppo mobile end-user è ancora nella sua infanzia e presenta nuove questioni principalmente correlate alla necessità di identificare paradigmi di composizione nuovi e modelli per l applicazione finale che possano adattarsi alle caratteristiche dei nuovi dispositivi mobili e al loro contesto d uso [31]. Alcuni approcci, come già anticipato, offrono ambienti di sviluppo direttamente sul dispositivo mobile. A causa, però, delle ben note limitazioni dei dispositivi mobili (dimensioni schermo in primis), gli editor per dispositivi mobili rendono possibile la creazione di applicazioni semplici, chiamate micro-servizi (micro-services): app molto limitate sia in termini di contenuti offerti e sia in termini di funzionalità. Per esempio il tool kit di creazione di servizi (Service Creation Kit, SCK) [35, 32] consente agli utenti mobile di creare micro-servizi che implementano semplici regole sulle azioni di contesto. Sulla base, quindi, di certe regole il dispositivo compie determinate azioni, per esempio quando un contesto selezionato è riconosciuto o si sono verificate determinate condizioni definite dall utente. In [31] vengono anche introdotti linguaggi visuali che, ispirati dal paradigma GoogleAppInventor [12], permettono all utente di comporre blocchi, con funzioni o azioni che possono essere direttamente attivate sul telefono. Gli approcci dei micro-service offrono, dunque, una metafora visuale intuitiva per costruire applicazioni finali direttamente sul dispositivo mobile. D altro canto, data la loro semplicità, hanno lo svantaggio di non rendere possibile in nessun modo la composizione di servizi remoti e API.

44 CAPITOLO 3. PIATTAFORME ALTERNATIVE 43 La piattaforma TELAR [6] fa qualche ulteriore passo in avanti, assistendo l utente nella costruzione dei mashup Web-based. Questi ultimi vengono depositati come pagine HTML, arricchiti con codice JavaScript ed eseguiti nel browser del dispositivo mobile. TELAR in particolar modo, consente l integrazione e la presentazione delle sorgenti dati con GoogleMaps. L unica flessibilità che presenta questo loro approccio, è il fatto che il client mashup (dunque il Web browser mobile) sia in grado di caricare un file XML (quando la pagina HTML che include il mashup è scaricata) contenente i parametri di configurazione che si riferiscono ai data provider che devono essere utilizzati. Il supporto che offre è quindi la definizione dei parametri di configurazione che, in caso di modifica, l utente è costretto a cambiare, riscrivendo il codice XML e quindi rifacendo il caricameto (upload) sul dispositivo. Nell articolo A Cross-Platform Software System to Create and Deploy Mobile Mashups [22], si cerca di proporre una soluzione alla creazione di un mashup mobile tramite un editor mashup che risiede nella macchina desktop. L applicazione è suddivisa in due parti: la parte di editor del mashup mobile e il viewer-template che verrà depositato sul dispositivo mobile. La piattaforma che crea il mashup mobile è una Rich Internet Application (RIA) che viene installata sul client. Il viewer invece è stato implementato usando il framework mobile Titanium Mobile ( Figura 3.1: Mobile Mashup Editor e risultato sul corrispettivo view-template

45 CAPITOLO 3. PIATTAFORME ALTERNATIVE 44 I problemi riscontrati da questo studio sono: ˆ Stretto legame tra il kit di sviluppo SDK e le piattaforme dei dispositivi mobili. ˆ Eterogeneità dei linguaggi di programmazione degli OS dei dispositivi mobili. ˆ Assenza di un tool che agevoli la programmazione a un utente finale non esperto. Altra menzione va fatta, invece, nei riguardi di un applicativo che permette di ottener da un Web mashup già costruito un applicazione mobile in modo automatico senza nessuna configurazione. Si tratta di PhoneGap [28], uno strumento di sviluppo open source, creato per fare da ponte tra le applicazioni Web e i dispositivi mobili. Con PhoneGap è possibile scrivere un applicazione mobile sfruttando HTML, JavaScript e CSS, ma anche utilizzare le principali risorse del dispositivo, quali file system, fotocamera, accelerometro, gps o multitouch. In Figura 3.2 si può vedere il flusso di attività necessarie alla generazione delle applicazioni mobili. Figura 3.2: Generazione delle applicazioni mobili con PhoneGap PhoneGap si rivela utile nel momento in cui non si vuole codificare nulla per ottenere il viewer dell applicazione, dato che per poter visualizzare il mashup sul terminale è necessario semplicemente disporre di un browser, presente nei comuni smartphone. D altro canto uno degli svantaggi principali di questo tipo di soluzione è che le applicazioni ibride non hanno l accesso completo alle API del dispositivo mobile e quindi rimangono limitate all uso esclusivo di servizi Web.

46 CAPITOLO 3. PIATTAFORME ALTERNATIVE 45 Un approccio interessante è riportato nell articolo [18] in cui viene presentata una piattaforma per la composizione di mashup nella quale gli utenti possono configurare, attraverso un paradigma basato sui form (form-based paradigm), alcune parametrizzazioni sulle query di invocazione dei servizi. Il limite di questo approccio è dato dal fatto che l integrazione dei servizi è possibile soltanto tra quelli selezionati e la rappresentazione solo su determinate zone della mappa. In tal modo l approccio è orientato esclusivamente alla costruzione di mashup per l accesso a servizi basati su zone pre-determinate (zone-based). Nell articolo [30], gli autori illustrano un ambiente desktop (Figura 3.3) che, in linea con la nostra prospettiva di sviluppo di applicativi di mashup orientati all utente (user-centric), genera automaticamente il codice per l applicazione. Figura 3.3: Schermata e workflow di ogni tool di composizione [30] Tramite un linguaggio di composizione ad-hoc (MAIDL), sono dunque in grado di comporre la descrizione dell interfaccia dell applicazione. Questo approccio, basato sul paradigma publish-subscribe per la sincronizzazione dei servizi, si richiama ai tradizionali modelli già adottati dai Web mashup [9, 4], adottato anche da noi per la sincronizzazione dei servizi. La suddetta piattaforma ha lo scopo di velocizzare la prototipizzazione. Il vero punto debole del loro pa-

47 CAPITOLO 3. PIATTAFORME ALTERNATIVE 46 radigma di composizione, secondo il nostro punto di vista, è l elevato tempo di creazione impiegato da un utente esperto nella composizione (in media 51 minuti per 3 servizi). La nostra validazione user-based, di cui si parlerà nel capitolo 7, dimostrerà che gli utenti finali possono avere prestazioni (performance) di creazione migliori se hanno a disposizione differenti livelli di astrazione, dato che saranno in grado di creare composizioni con lo stesso numero di servizi in poco tempo (circa 8/9 minuti). Inoltre, anche se il loro approccio permette l estrazione di contenuti da documenti Web, non offre nessun supporto all integrazione dati. 3.2 Altre Piattaforme Anche se l insieme dei personal computer e l universo dei dispositivi mobile, dal semplice cellulare ad i tablet-pc, rappresentano la maggior parte dei supporti utilizzati dagli utenti per eseguire le proprie applicazioni basate su mashup, esistono altre piattaforme che consentono l utilizzo di applicazioni di questo tipo. Tra i vari esempi a disposizione abbiamo scelto di analizzare le due seguenti tipologie di canali poiché riteniamo siano più promettenti nell ambito dell attuale ricerca e di maggiore impatto sugli utenti finali Multitouch La tecnologia Multitouch, naturale evoluzione di un comune schermo tattile, costituisce un settore di grande interesse per la ricerca nell ambito dell interazione uomo-macchina. Uno schermo tattile multi-tocco si differenzia dai suoi predecessori per la sua sensibilità al tocco, localizzata contemporaneamente in più punti della superficie interessata. I multitouch combinano una parte hardware, formata da uno schermo o un pad tattile che riconosce in simultanea più di un punto toccato da una mano, al software che riconosce ed interpreta tali punti. Le potenzialità offerte da questa tecnologia ampliano notevolmente il

48 CAPITOLO 3. PIATTAFORME ALTERNATIVE 47 paradigma di interazione con l utente, abilitato fin da subito all utilizzo del dispositivo tramite un intuitiva gestualità. In base alla grandezza degli schermi ed alla capacità di elaborazione, i dispositivi multitocco possono supportare più di un utente per volta sulla medesima superficie. L utilizzo di mashup all interno di una piattaforma multitouch appare quindi di grande utilità. La combinazione di una interazione utente immediata, così come è offerta dalla piattaforma multitocco, con la naturale semplicità di una applicazione di tipo mashup consente di costruire e sfruttare in tempi rapidi ambienti interattivi di facile utilizzo, generando al contempo nuove possibilità di sinergia tra i paradigmi software oggetto della ricerca informatica e le tecnologie hardware che le supportano ed abilitano. Figura 3.4: Dispositivo Multitouch Il principale campo di applicazione degli schermi multitocco è senza dubbio il settore dell educazione. In questo ambito la semplicità di accesso alle periferiche di input assume importanza primaria a causa della esperienza minima richiesta agli utenti, in genere bambini o ragazzi con scarse conoscenze tecniche. Concentrando interamente nell unico oggetto dello schermo tutti gli input necessari al proprio funzionamento, la tecnologia multitocco si presenta come

49 CAPITOLO 3. PIATTAFORME ALTERNATIVE 48 strumento efficace e di sempre maggiore applicazione. E comunque interessante notare come alcuni utilizzi di tali tecnologie abbiano esteso il campo di utilizzo anche a fasce d età più elevate, soprattutto tramite la combinazione di servizi che forniscono dati georeferenziati con fonti di immagini fotografiche. Ne è un valido esempio la campagna di informazione e sensibilizzazione intrapresa dalla Ideum in seguito al disastro ecologico della BP Oil del 2010, fornendo ad organizzazioni educative come centri scientifici ed acquati alcune piattaforme multitouch sulle quali erano eseguiti web mashup con fusione dati tra Flickr e Google Maps [16] Smart TV Si definiscono Smart TV i dispositivi che rientrano nella categoria di apparecchiature elettroniche di consumo che abbiano come principale caratteristica l integrazione di funzioni e di servizi legati a internet, e in particolare al cosiddetto Web 2.0, all interno di apparecchi televisivi. Più in generale si fanno rientrare in questa categoria tutti i prodotti del filone di convergenza tecnologica tra il mondo dei personal computer e quello della televisione. Il collegamento alla rete rende possibile per questi dispositivi offrire l usufrutto di servizi online tipicamente destinati a normali personal computer quali navigazione internet, video on demand, Internet TV, servizi in streaming o social network. Essendo sviluppate sulla base di una serie di caratteristiche di interattività proprie degli apparecchi televisivi e dei dispositivi ad essi collegati immessi sul mercato dopo l avvento del digitale terrestre e della televisione satellitare, le Smart TV integrano e potenziano tali caratteristiche passando di fatto da un televisore a senso unico ad una vera e propria postazione multimediale con ampio sfruttamento dei vantaggi della rete.

50 CAPITOLO 3. PIATTAFORME ALTERNATIVE 49 Figura 3.5: SmartTv Le principali Smart TV attualmente in commercio lavorano con sistemi operativi basati su kernel Unix, quando non direttamente operanti tramite Android o sistemi similari. Ciascuna di queste piattaforme software mette a disposizione un ambiente di sviluppo nativo tramite le librerie fornite dalle rispettive SDK, con applicazioni implementabili generalmente tramite Java, Javascript o vari derivati del linguaggio C. Anche grazie all utilizzo di linguaggi facilmente adattabili all ambiente Web è possibile pensare all integrazione nelle Smart TV di applicazioni basate su mashup. In questa ottica i normali strumenti di input a disposizione dell utente vedrebbero ampliarsi il proprio orizzonte di utilizzo, e le applicazioni stesse beneficerebbero di un insieme di utenti molto ampio proprio in virtù della diffusione capillare del mezzo televisivo.

51 Parte III Modelli e Architetture 50

52 Capitolo 4 Modelli di riferimento Questo capitolo offre una panoramica dei modelli che sono alla base del paradigma di composizione e di esecuzione dei mashup di ViTe. Vengono introdotte le astrazioni tramite cui gli utenti finali, per mezzo di azioni visuali, collegano i dati sulla base di uno scheletro predisposto (il visual template) costruendo viste unificate con i dati estratti da più sorgenti e predisponendo il loro accesso per il momento dell esecuzione. 4.1 Approccio L integrazione e la sincronizzazione di servizi all interno dei mashup può essere attuata a diversi livelli [10]. Lavori precedenti, particolarmente la piattaforma MobiMash, hanno affrontato l integrazione dei dati sulla base di template visuali nel contesto mobile. In tale ambiente tuttavia il livello di presentazione deve sottostare a regole intrinseche di semplicità ed immediatezza. Le relative capacità di elaborazione dei dispositivi mobili unitamente alle ridotte dimensioni dei loro schermi rendono necessaria la confluenza dei dati integrati in un modello visivo che sia concepito appositamente per l ambiente mobile, sfruttandone al meglio le caratteristiche peculiari senza compromettere l esperienza dell utente. 51

53 CAPITOLO 4. MODELLI DI RIFERIMENTO 52 Proprio per far fronte a questo insieme di presupposti è nata la piattaforma Vi- Te (Visual Template Editor), oggetto di questa tesi, il cui obiettivo principale è semplificare la creazione di mashup tramite una logica di composizione visuale basata su un set prefissato di template. Infatti, tramite questo ambiente è possibile integrare sorgenti dati operanti tramite servizi REST (Representational state transfer) che restituiscano i propri risultati in formato XML o JSON, anche se la struttura dell applicazione, come vedremo più avanti, facilita l aggiunta di nuovi protocolli di comunicazione qualora se ne rendesse necessaria la presenza per una maggiore flessibilità dell applicativo. E importante ricordare comunque che, allo stato attuale, la combinazione degli standard XML\JSON rappresenta una percentuale dominante nell universo dei servizi web. Le sorgenti dati usufruibili nelle composizioni devono essere registrate specificandone l URI di base, indirizzo primario del servizio, e ciascuna delle query utilizzabili, identificate dalle loro coppie <nome, valore>. Dovendo consentire l interazione a runtime di un qualsiasi servizio che sia stato correttamente registrato e che risponda ai requisiti descritti precedentemente è necessario uno strato di astrazione che si interponga tra essi ed i componenti visuali del template, fungendo da adattatore. Tale componente, il wrapper, permette di invocare correttamente i servizi durante l esecuzione della composizione. La piattaforma ViTe si compone di un Design Environment (DE) unificato (ossia presente allo stato delle cose come unico applicativo adibito alla costruzione delle composizioni ViTe) e di un corrispettivo Execution Environment (EE). In Figura 4.1 se ne mostra l architettura ad alto livello. Il DE è un applicazione Web che permette agli utenti di comporre mashup visuali, in ambiente desktop, attraverso il completamento di template predefiniti (visual template) con semplici operazioni di drag-and-drop. Sulla base delle azioni e delle scelte

54 CAPITOLO 4. MODELLI DI RIFERIMENTO 53 dell utente il DE genera un descrittore codificato in linguaggio XML che racchiude tutte le caratteristiche della composizione generata. Tale documento viene salvato su un database lato server (Database ServerSide) che contiene tutte le composizioni create dagli utenti. L architettura del sistema è pensata per consentire ad un qualsiasi modello di Execution Environment la comprensione dell XML salvato e l esecuzione della composizione in esso descritta. In questo modo una composizione salvata diventa portabile su qualsiasi piattaforma per la quale sia stato approntato un adeguato EE. Per rendere usufruibile direttamente il prodotto della composizione agli utenti finali, in questa tesi è stato predisposto un ambiente EE di tipo Web analogo all ambiente di design. Esso permette l autenticazione dell utente presso il server ed il caricamento delle composizioni dei mashup precedentemente create. L EE, sulla base dello schema d applicazione caricato, è in grado di generare il layer di presentazione dei dati, di invocare autonomamente le sorgenti (Remote Data Sources) e di gestire le azioni sui componenti UI permettendo all utente di eseguire le operazioni pensate per quel tipo di EE, proprie del dispositivo in uso. Figura 4.1: Architettura della piattaforma ViTe

55 CAPITOLO 4. MODELLI DI RIFERIMENTO I visual template I template visuali sono gli ingredienti fondamentali di questo approccio implementativodi composizione. Essi offrono una rappresentazione immediata del modo in cui i dati saranno mostrati nell applicazione finale. Come illustreremo successivamente in questo capitolo, il completamento dei template visuali attraverso l associazione di elementi dello schema dei dati abilita un paradigma di integration-by-example, attraverso il quale gli utenti possono selezionare i dati d interesse dalle sorgenti ed ottenerne subito la rappresentazione visuale, provvedendo se necessario ad immettere dati propri nell applicazione qualora il template in questione lo consenta. La struttura dei visual template deriva dall osservazione delle più comuni applicazioni basate sui contenuti (content-based), con un particolare riguardo al mondo dei dispositivi mobile. Pur non essendo vincolata a tale ambito, ricordiamo che la piattaforma ViTe produce composizioni eseguibili all interno di Execution Environment distribuiti su differenti categorie di dispositivi. Tali template sono generalmente organizzati secondo poche varianti di un pattern ricorrente. Il modello principale utilizza due differenti layer di presentazione. La vista primaria visualizza tutti i dati recuperati, come una lista di eventi o prodotti o un insieme di location su una mappa, dove ciascuna istanza può essere rappresentata da una terna titolo\sottotitolo\immagine, o nel caso della mappa, un insieme di POI (Point Of Interest). La vista secondaria si occupa in genere di mostrare i dettagli dell istanza selezionata. Formalizzando il concetto di template visuali, a prescindere dalla loro concreta visualizzazione (sia essa basata su lista o mappa), ciascuno di essi può essere visto come una tupla VT =<vr1,vr2,...,vrn>, dove ogni vrk rappresenta un renderer visuale utilizzato per la visualizzazione di un dato estratto da una delle sorgenti selezionate dall utente. Ciascun template visuale può essere decomposto in due sub-template, rappresentanti l organizzazione delle due

56 CAPITOLO 4. MODELLI DI RIFERIMENTO 55 differenti viste nell applicazione finale: ˆ union sub-template (uvrk), mostra gli attributi dati che rappresentano in modo conciso le istanze recuperate interrogando i servizi coinvolti ˆ merge sub-template (mvrk), mostra i dettagli di un istanza di dati selezionata nell union sub-template. Mentre l union sub-template ha un organizzazione fissa, la struttura del mergetemplate è generalmente definita a posteriori, durante la composizione del mashup, quando l utente aggiunge gli elementi alla vista secondaria perché siano visualizzati come dettaglio di alcuni o tutti gli item presenti nell union subtemplate. In accordo a questa struttura possono essere definite alcune tipologie base di template visuali: ˆ List: gli item recuperati dai servizi sono organizzati in una semplice lista. Tale organizzazione si adatta bene ad un ambiente mobile in cui gli spazi ristretti della grafica portano a prediligere strutture semplici e spartane. Un esempio pratico di utilizzo di tale template visuale può essere la piattaforma MobiMash: l union sub-template (in Figura 4.2, a sinistra) corrisponde in tale piattaforma ad una lista dove ciascun elemento è rappresentato attraverso un segnaposto per un immagine e due campi con i label title e subtitle ; il merge sub-template (in Figura 4.2, a destra) consiste dunque in un numero arbitrario di immagini e campi testuali con lo scopo di mostrare i dettagli di un elemento selezionato nello screen precedente.

57 CAPITOLO 4. MODELLI DI RIFERIMENTO 56 Figura 4.2: List-template, dettaglio del union sub-template (a) e merge subtemplate (b) ˆ Slider: pensato principalmente per creare e navigare gallerie di immagini, consiste in un pattern di navigazione guidata (in Figura 4.3 un esempio implementato da una libreria jquery) tramite un union sub-template in cui ogni item è rappresentato da un immagine a schermo pieno insieme a un campo titolo e uno sottotitolo. La selezione di un elemento dello slider conduce poi alla vista secondaria, il merge sub-template, dove vengono mostrati all utente ulteriori dati sull elemento selezionato. Figura 4.3: Slider-template, esempio di utilizzo

58 CAPITOLO 4. MODELLI DI RIFERIMENTO 57 ˆ Charts: questo visual template raccoglie un insieme molto ampio di visualizzazioni, comprendendo modelli standard di organizzazzione di dati come grafici a barre, a torta o modelli più recenti come le tagclouds. Ciascuno di questi modelli può avere differenti implementazioni delle proprie viste. Una possibile vista primaria potrebbe essere il grafico complessivo, con una vista secondaria che raccolga i dettagli dei singoli dati presenti. Un interessante esempio di utilizzo è il componente Charts della piattaforma Peudom. Figura 4.4: Charts-template nella piattaforma Peudom ˆ Map: consente l utilizzo delle informazioni di georeferenziazione dei dati. Ogni istanza recuperata è rappresentata come un punto di interesse nell union sub-template (in Figura 4.5, a sinistra), ed associata ad un indicatore sulla mappa (marker) che ne rappresenta la posizione geografica. Il merge sub-template (in Figura 4.5, a destra) consiste in un insieme di visual renderer che vengono organizzati dall utente sulla base dei dati recuperati dai servizi e che sono visualizzati tramite una casella di dettaglio (balloon) associata al marker.

59 CAPITOLO 4. MODELLI DI RIFERIMENTO 58 Figura 4.5: Map-template, dettaglio degli union (sinistra) e merge (destra) sub-templates 4.3 Il paradigma di composizione Il paradigma di composizione visuale dell editor si basa su due tipi di azioni da parte dell utente. La principale tipologia di interazione avviene tramite operazioni di drag-and-drop studiate per essere il più possibile semplici ed intuitive. Tramite tali azioni l utente può integrare i dati dei servizi interrogati e definire la struttura che tali dati assumeranno nella composizione finale. La seconda tipologia è un intervento diretto dell utente per modificare alcune caratteristiche dei dati inseriti o per aggiungerne di nuovi senza utilizzare le sorgenti predefinite.

60 CAPITOLO 4. MODELLI DI RIFERIMENTO 59 L ambiente grafico alla base del DE consiste di due pannelli principali (Figura 4.6): ˆ Data-Panel, sul lato sinistro, che mostra i dati richiesti ai servizi selezionati e precedentemente registrati. ˆ Visual-Panel, sul lato destro, che mostra il template visuale. Pur essendo in una versione leggera e studiata specificamente per il DE, tale template rispecchia l aspetto che avrà l applicazione finale al momento della sua esecuzione. L azione di drag and drop si concretizza nel prelevamento dal data-panel dei dati d interesse ed il loro collocamento tramite gesti semplici ed immediati sul visual-panel. Il gestore della vista aggiornerà dunque in tempo reale la preview in base alle informazioni che l utente ha implicitamente fornito con la sua azione di trascinamento. L utente, in fase di drag, può selezionare qualsiasi elemento presente nell albero eccetto l istanza del dato. Infatti, attraverso l azione di trascinamento, esso definisce quale elemento dello schema dati debba essere associato a un elemento del visual-template. Nell esempio in Figura 4.6 l utente associa il tag venue address nel data panel al campo location del visual-panel che attualmente mostra lo screen mappa. Sempre in Figura 4.6 l associazione effettuata è tra il tag title e il campo detail dello screen dettaglio. L insieme di tutte queste azioni si traduce in una operazione implicita di schema-mapping visuale. Gli schemi di ciascuna sorgente dati vengono mappati sui campi di un visual template che rappresenta un integration-schema, ovvero lo schema globale di tutte le sorgenti selezionate per la composizione. Quando l associazione di ciascuna coppia, elemento schema ed elemento del visual template, è completata, immediatamente il visual-renderer dispone di tutte le informazioni necessarie per istanziare nel visual-template tutti i dati che compongono lo screen mappa. Nel momento in cui l utente rilascia il

61 CAPITOLO 4. MODELLI DI RIFERIMENTO 60 campo venue address dell evento (operazione di drop) sul campo location del template, la vista della preview si popola di dati, ovvero di tanti marker quanti sono gli eventi elencati nella risposta della sorgente dati che abbiano un campo d indirizzo valido. Figura 4.6: Schermata del visual front-end del DE e paradigma di composizione visuale drag-and-drop Per quanto riguarda il template Mappa, il meccanismo subisce una netta differenziazione a seconda che l aggiunta di marker sia impostata su automatica o su customizzata. Nel primo caso il popolamento avviene sulla base di una singola azione dell utente, il quale non deve trascinare ciascuna istanza per popolare la preview ma effettua solamente il drop di un elemento dello schema, ed è la piattaforma a completare per lui in modo dinamico le operazioni di aggiunta. La natura iterativa presente nello schema dati delle sorgenti permette infatti il recupero delle diverse istanze attraverso delle query XPath, definite implicitamente dall utente in fase di drag.

62 CAPITOLO 4. MODELLI DI RIFERIMENTO 61 Nel caso di aggiunta customizzata, il dragging di dati nella vista primaria comporta l aggiunta di un marker corrispondente alla sola istanza interessata dal trascinamento. Questo consente all utente di aggiungere alla popolazione dei marker punti di interesse personalizzati ed inserirvi dettagli che non siano necessariamente vincolati alla sorgente. E possibile infatti integrare nel medesimo baloon informativo dettagli catturati da diversi item della stessa sorgente o da item di sorgenti differenti. Oltre alle azioni di drag and drop, l utente può interagire con la piattaforma tramite inserimento diretto di dati personalizzati. Nel template mappa l utente può aggiungere marker customizzabili tramite la scrittura negli appositi campi della loro location o della coppia (latitude,longitude) ed eventualmente inserire tra i dettagli di un marker custom dati personali specificandone manualmente il nome del campo ed il contenuto. 4.4 Lo schema dell applicazione Sulla base delle azioni visuali di data-integration, il Design Environment (DE) genera e salva sul server della piattaforma la configurazione che contiene le regole per la generazione automatica dell applicazione da eseguire. Il file di configurazione, in formato XML, rappresenta lo schema di funzionamento dell intera applicazione ed è dunque utilizzabile sia per avviarne l esecuzione che per caricare una composizione salvata all interno del Design Environment e provvedere al suo aggiornamento o alla sua modifica. Per comprendere la logica di scrittura di questo file XML è bene procedere ad una analisi delle sue varie parti. Si osservi il seguente frammento di codice, generato ai fini dell esposizione utilizzando una composizione creata sul visual template Map.

63 CAPITOLO 4. MODELLI DI RIFERIMENTO 62 Figura 4.7: Esempio Config.xml (1) La prima sezione del file di configurazione, subito dopo il nome dell applicazione salvata, riporta tutte le informazioni necessarie alla piattaforma per rintracciare ed interrogare correttamente i vari servizi aggiunti dall utente alla composizione. Per ciascun servizio (in questo esempio Eventful ed Upcoming) deve essere specificato un URL di base e seguentemente tutte le query che l utente vi ha effettuato, composte dai nomi dei parametri utilizzati, dalle loro tipologie e dai loro valori. Figura 4.8: Esempio Config.xml (2)

64 CAPITOLO 4. MODELLI DI RIFERIMENTO 63 In questo secondo frammento è descritta la sezione mapping, che specifica il template visuale in uso e le regole di composizione che l utente ha utilizzato per generare la propria applicazione. Il primo blocco di codice, che identifica l union sub-template, è composto dai visual renderer ( vr ) della vista primaria (nel caso della mappa: Location, Latitude e Longitude), specificando quali servizi forniscano a questi visual renderer i dati da incapsulare nel template e, per ciascuno di essi, il nome della query che recupera tali dati e l indirizzo xpath necessario a catturarne le istanze all interno della risposta che i servizi interrogati da queste query avranno inviato. Il secondo blocco identifica il merge sub-template, corrispondente alla vista secondaria del template visuale. I visual renderer qui contenuti sono opzionali ed in numero variabile: è l utente a scegliere infatti al momento del design quali dati dei servizi vadano utilizzati come dettagli degli item della vista primaria. Anche in questi visual renderer è specificata la query di riferimento e l indirizzo xpath del dato da catturare. Figura 4.9: Esempio Config.xml (3) L ultima parte del documento XML descrive e raccoglie i dati che l utente

65 CAPITOLO 4. MODELLI DI RIFERIMENTO 64 ha inserito manualmente come ulteriore personalizzazione della composizione. Nell esempio fornito, basato sul template Map, tali dati sono costituiti da punti di interesse customizzati (i marker statici) che l utente ha impostato sulla mappa e che sono dunque, da quel momento, slegati dalle risposte dei servizi interrogati. La struttura della sezione custom rispecchia quella della sezione mapping, essendo anch essa divisa in una vista primaria ed una secondaria, rispettivamente chiamata cunion e cmerge. A differenza della sezione precedente, però, tali viste sono incluse in ciascun item che l utente ha inserito manualmente, consentendo così di personalizzare in modo elastico la visualizzazione ed il contenuto di ogni punto di interesse customizzato. 4.5 L integrazione di sorgenti dati Avendo a disposizione un insieme di sorgenti dati registrate e un visual template tra quelli disponibili nella piattaforma, l utente costruisce il livello di presentazione e implicitamente vi integra i dati (data source integration) dopo avere selezionato una o più sorgenti dati disponibili tra quelle precedentemente inserite. Nel caso in cui l utente volesse costruire un mashup estraendo informazioni da differenti sorgenti dati, viene avviato un processo di dataintegration. Le azioni dell utente sono mirate alla costruzione di una vista unificata di dati (unified data view). L approccio è composto da fasi che sono simili a quelle tipiche dei processi tradizionali di data integration. Per supportare maggiormente gli utenti finali, a seconda del visual template in uso, alcune fasi dell integrazione vengono svolte automaticamente dal Design Environment. Il processo di data integration, come mostrato in figura 4.10, inizia con una fase di campionamento dei dati delle sorgenti (source data sampling), nella quale ogni sorgente dati è selezionata e interrogata in base ai parametri e i setting definiti in fase di registrazione del servizio. L insieme dati risultante è visualizzato nel data-panel dell editor, tramite una rappresentazione auto-

66 CAPITOLO 4. MODELLI DI RIFERIMENTO 65 matica degli item attributo-valore. L utente seleziona il tipo di template visuale come base della visualizzazione dei dati ricevuti dai servizi scelti, definendo implicitamente uno schema globale (global schema) d integrazione. Il template fornisce infatti accesso uniforme all insieme dei dati fornendone una rappresentazione. Figura 4.10: Processo di integrazione dati Nella data integration, una questione fondamentale è la relazione tra schema globale di integrazione e gli schemi locali delle sorgenti (source local schema). Nell approccio ViTe tale risultato è ottenuto tramite la mappatura visuale (visual mapping), attraverso la quale l utente associa i campi estratti dai dati dei servizi e visualizzati nel data panel, agli elementi del template visuale (visual renderers). In modo più formale, consideriamo l insieme delle sorgenti dati S = {s 1,..., s j } selezionate dall utente per l integrazione nel mashup. L associazione di alcuni attributi dei dati del servizio si con gli elementi del template visuale corrisponde alla funzione specifica di mapping M(s i.h) vr k. L insieme di tutti i campi s i.h che sono associati con i visual renderer che compongono lo schema visuale, ls(s i ), cioè la riduzione dello schema delle sorgenti dati, è usata a runtime per

67 CAPITOLO 4. MODELLI DI RIFERIMENTO 66 la creazione della vista unificata. Come precedentemente descritto, il template visuale in ViTe è generalmente composto da due sotto-template. Dunque lo schema locale può essere visto come diviso in due parti: ˆ una riduzione dello schema del servizio rispetto al sub-template di unione, uls(s i ) nel quale ogni attributo dei dati è mappato sul visual renderer di questo sub-template di unione: s i.h uls(s i ) : s i.h uvr k ˆ una riduzione dello schema dati del servizio rispetto al sub-template di merge, mls(s i ), nel quale ogni attributo dei dati è mappato sul visual renderer contenuto nel sub-template di merge: s i.h mls(s i ) : s i.h mvr k E importante far notare che, essendo i visual templates il cuore concettuale della piattaforma ViTe, la mappatura dei dati sui loro schemi di visualizzazione può avvenire in maniera radicalmente diversa. In alcuni casi, come nel template List, sono state applicate politiche di integrazione automatica per collegare tra loro in modo trasparente dati che, pur provenendo da sorgenti differenti, si riferiscono al medesimo item. Pertanto una post-elaborazione di questi dati ricalibra la visualizzazione della vista secondaria (merge sub-template) tramite algoritmi di data fusion e duplicate detection offrendo all utente una miglior gestione della composizione creata.

68 Capitolo 5 Architettura della piattaforma ViTe In questo capitolo verrà illustrata l architettura dell intera piattaforma ViTe, per lo sviluppo di mashup basati su template visuali. Verranno pertanto presentate le due componenti del sistema, sommariamente descritte in precedenza: il Design Environment (DE) e l Execution Environment (EE), e ne verranno messe in risalto le principali peculiarità. 5.1 Il Design Environment La scelta di adottare un ambiente di sviluppo desktop basato sul Web è dovuta alle maggiori potenzialità che tale ambiente concede. Il design di un mashup da parte degli utenti, specie se poco esperti, è un operazione complessa che l approccio visuale semplifica soltanto in maniera limitata. Per questa ragione è consigliabile consentire la maggior completezza e facilità di utilizzo possibile a chi si cimenta in questo genere di attività. Un ambiente web dinamico, pur garantendo la portabilità dell applicazione di design su qualsiasi dispositivo munito di un browser con supporto script (Javascript nel caso di ViTe) esprime il massimo delle proprie potenzialità quando viene eseguito su un personal computer grazie alla sua maggiore capacità di calcolo e, generalmente, 67

69 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 68 dalla possibilità di usufruire di schermi più grandi. Le composizioni prodotte dall ambiente potranno essere quindi più articolate e di qualità nettamente superiore alle loro controparti costruite su altri dispositivi. La corrente implementazione dell architettura del Design Environment di ViTe consiste in un modulo client-side con un motore principale (runtime environment) che permette la composizione dei mashup. La scelta di un approccio client-side è dovuta alla necessità di mantenere la soluzione semplice, soprattutto dal punto di vista del deploy della piattaforma stessa. Tale approccio semplifica enormemente l utilizzo della piattaforma rendendolo accessibile via internet da qualsiasi punto del globo senza necessità di installazioni preventive. La scelta naturale della tecnologia per l implementazione del runtime environment è stata HTML/JavaScript. Per la gestione dell interazione dell utente col front-end si è fatto ampio uso delle librerie open source JavaScript jqueryui [17], poiché forniscono funzioni di interazione ed animazione avanzate e personalizzabili. Tale tecnologia non è però sufficiente a garantire ed abilitare molte delle funzioni principali del sistema come la registrazione dei servizi, il salvataggio e l accesso multiutente. Per semplificare l architettura client-side e permettere l utilizzo di tali funzioni è stato necessario implementare anche una logica server-side. La logica server-side è stata realizza in Java attraverso l utilizzo di pagine Java Server Pages (JSP) e Java Servlet. La piattaforma scelta per l esecuzione della applicazione Web che implementa queste specifiche è Apache Tomcat, un contenitore servlet open source sviluppato da Apache Software Foundation. La sua distribuzione standard include anche le funzionalità di Web server tradizionale (che corrispondono al prodotto Apache) abilitando così appieno la gestione della comunicazione col client. Per quanto concerne invece la gestione della banca dati, che mantiene le informazioni su utenti, composizioni e sorgenti dati, si è fatto utilizzo di un database server MySql

70 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 69 gestito dalla logica di back-end della piattaforma. Conseguentemente, le pagine della piattaforma che permettono il login e la registrazione dell utente, corrispondenti alle prime pagine incontrate dall utente durante la navigazione, sono state realizzate con tecnologia JSP. Il cuore dell ambiente di design, ovvero il visual front-end in Figura 5.1, consiste invece in un unica pagina JSP contenente tutto il runtime environment. L interazione del runtime environment col server della piattaforma si basa su uno scambio di dati in background, strutturati in documenti XML, che consente l aggiornamento dinamico della pagina Web dell editor senza esplicito ricaricamento della stessa. In questo modo il server è impegnato solamente in attività utili e necessarie, mentre tutto il carico del lavoro durante la composizione del mashup è gestito dal client. Una interazione più pesante con il server, con conseguente ricaricamento della pagina JSP, è richiesto soltanto durante l operazione di switch tra template differenti. In questo senso si può dire che il runtime environment stesso sia mono-template, istanziato su uno dei template disponibili ogni volta che l utente sceglie di usufruire di uno di essi. La Figura 5.1 descrive l architettura globale del Design Environment e presenta i principali moduli che la compongono, sia client-side che server-side, ed è formata da due componenti: ˆ il runtime-environment, ovvero l applicativo client-side JavaScript che si interfaccia col front-end; ˆ il configuration-server, ovvero il server di back-end. Implementa le funzionalità richieste dal runtime environment, accedendo ai dati presenti nel DB server. Esso non offre servizi solamente al Design Environment, ma anche all Execution Environment web-based qualora un dispositivo ne richiedesse l utilizzo.

71 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 70 Figura 5.1: Architettura del Design Environment (DE) Il visual front-end L ambiente grafico (Figura 5.2) alla base del DE consiste in due pannelli principali: ˆ data-panel, sul lato sinistro, che mostra i dati richiesti ai servizi selezionati e precedentemente registrati. ˆ visual-panel, sul lato destro, che mostra il template visuale in uso, con una preview che mostra come apparirà l applicazione al momento dell esecuzione.

72 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 71 Figura 5.2: Visual front-end del Design Environment (DE) Appena i dati presenti nel data-panel sono associati attraverso azioni di dragand-drop, il pannello visuale è aggiornato con una preview dell effetto dell associazione realizzata. Ciò facilita notevolmente la composizione permettendo all utente di avere sempre sotto controllo il risultato finale e di apportare le modifiche necessarie in caso non sia soddisfatto di quanto realizzato. Oltre alla preview, all interno del visual panel vi sono altri componenti fondamentali, strumenti indispensabili per la creazione della composizione. Tali componenti sono: ˆ pannello di navigazione, generalmente posto al di sotto della casella di preview, consente all utente di muoversi fra le differenti viste e selezionare le opzioni di composizione desiderate. ˆ pannello di inserimento, posto invece in genere al di sopra della preview, è composto dalle varie caselle di dropping in cui l utente trascina i dati dal data panel. Tale pannello non è quindi statico ma viene aggiornato in base alle scelte che l utente compie sul pannello di navigazione

73 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 72 o a eventuali interazioni dirette dell utente sulla preview. Nel caso in cui il template in uso consenta all utente l inserimento manuale di dati, l inserimento avviene all interno di tale pannello. Lo sviluppatore dispone inoltre di un menu in testa ai panelli di lavoro che offre ulteriori funzionalità. Esso è strutturato in due sezioni: ˆ shortcut-menu, costituito da bottoni di dimensioni consistenti che rappresentano punti d accesso veloci alle funzionalità di registrazione delle sorgenti dati nel repository offerto dalla piattaforma, di selezione delle sorgenti dati necessarie alla composizione del mashup, al salvataggio della composizione e all esecuzione della stessa tramite l apertura dell Execution Environment. ˆ main-menu, è il menu dedicato alle informazioni utente e al cambiamento del template in uso. Permette inoltre il logout dalla sessione di lavoro Il data panel Il data panel è il pannello dell editor (in Figura 5.2 a sinistra) adibito a contenere la rappresentazione dei dati provenienti dalle sorgenti selezionate dall utente durante la composizione. La risposte XML o Json dei servizi, interrogati automaticamente dal sistema dopo la scelta dell utente, vengono elaborate e rappresentate in forma visuale. Il pannello è strutturato in modo tale da mostrare le risposte di più servizi contemporaneamente grazie ad un menu a tab che permette di navigare agevolmente tra le risposte delle differenti sorgenti selezionando quella da utilizzare a seconda delle esigenze del momento. La scelta della rappresentazione visuale, pur essendo strutturata concettualmente sotto forma di albero, si è però concentrata su una visualizzazione ad insiemi, nella quale cioè ogni elemento corrispondente ad un tag XML viene rappresentato come un insieme di forma rettangolare-ellissoidale. All interno di tale insieme sono contenuti eventuali nodi figli, rappresentati come sottoinsiemi, e le istanze dati corrispondenti. La scelta di una architettura visuale basata su albero è

74 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 73 dovuta in primis alla naturale struttura di un file XML, che rispecchia quella di un albero, e secondariamente alla necessità di mantenere e rappresentare le relazioni che intercorrono tra i nodi che compongono il documento XML. In tal modo è possibile mantenere le relazioni semantiche implicite presenti nell albero XML palesandole all utente, evitando di porlo in difficoltà rendendolo sprovvisto di tali riferimenti. A tale struttura è stata poi associata la visualizzazione ad insiemi descritta poc anzi. E doveroso far notare come la generica assenza di annotazioni da parte del fornitore del servizio renda assai ardua una interpretazione più raffinata dei dati ed una conseguente rappresentazione più versatile e intuitiva per lo sviluppatore della composizione. Allo stesso tempo, pensare di affidare l attività di annotazione dei dati a un utente non esperto in fase di registrazione della sorgente dati non è parsa, allo stato delle cose, una strada percorribile, poiché avrebbe rischiato di invalidare uno degli obiettivi principali della piattaforma, rappresentato dalla semplicità di utilizzo. Struttura dei dati Il mapping tra il file XML e la sua rappresentazione ad albero non è diretto. Difatti i tag di un documento XML presentano ulteriori informazioni che non sono gerarchicamente organizzate come un albero, per esempio gli attributi di un tag di apertura e il testo contenuto fra un tag di apertura e il corrispettivo tag di chiusura. Quest ultimi (attributi e testo) sono riferiti a un tag specifico ma non sono con esso in relazione di subordinazione (figlio) o di dominanza (padre), bensì allo stesso livello. Pertanto si è scelto di rappresentare questi elementi come sottoinsiemi dell insieme-tag di appartenenza mantenendo così il legame semantico che sussiste tra un tag e i suoi attributi o il suo testo. Un ulteriore distinzione è stata fatta: l albero presenta all utente sia lo schema dei dati sia le istanze dei dati. Per distinguere i nodi appartenenti alla rappresentazione ad insiemi dalle istanze stesse del dato, ovvero il testo di un tag e il valore di un attributo, è stata

75 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 74 introdotta una lieve differenziazione visuale (Figura 5.3). Figura 5.3: Rappresentazione ad insiemi del documento XML Si noti che, al fine di realizzare la composizione del mashup, le istanze dei dati non sono sempre necessarie, mentre lo è sempre lo schema dei dati stessi. Oltre a rappresentare un ulteriore informazione che lo agevola nella comprensione dello schema, infatti, le istanze sono utilizzabili direttamente in quei template che prevedano il drag&drop di singoli elementi delle risposte XML. In questo senso essi sono alternativi allo schema dei dati, poiché la loro aggiunta nella composizione avviene a prescindere dalla loro collocazione nella mappatura dei sottoinsiemi. Quando un dato viene trascinato staticamente da un utente che lo vuole inserire nel mashup, esso cessa di essere considerato dall applicazione come una foglia dell albero e diviene un dato fine a se stesso. Per facilitarne ulteriormente la comprensione della struttura sono state introdurre funzioni di supporto (facilities) sulle istanze dei dati, come la preview delle immagini in

76 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 75 presenza di url ad esse riconducibili o l apertura delle ulteriori risorse Web nel browser. In tal modo si è tentato di colmare il più possibile il gap tra il documento XML e l utente finale del DE, liberandolo dall onere di dover compiere una pre-annotazione dello schema della sorgente dati. Generazione della struttura dati visuale La generazione dell albero concettuale e della conseguente struttura visuale ad insiemi avviene in modo automatico a partire dal documento XML ottenuto dopo l invocazione del servizio. Un algoritmo di visita dell albero, di tipo depth-first, genera il codice HTML adatto. Tale codice può quindi essere renderizzato direttamente sotto forma di albero oppure, come si è scelto di fare in questo caso, tramite la sopracitata visualizzazione ad insiemi Il visual panel Il visual panel è il pannello dell editor adibito a mostrare lo stato della composizione attualmente realizzata all interno del template in uso. Data la sua dipendenza pressocché totale dal visual template selezionato, il pannello non ha una stuttura fissa. Ogni template tende comunque a dargli una visualizzazione il più fedele possibile al corrispondente ambiente di esecuzione, sia esso costituito da applicazioni su dispositivi mobili o da web-application su browser. Mentre alcuni template assumono forme differenti a seconda dell ambiente di utilizzo, altre tipologie hanno il vantaggio di essere aderenti a standard di convenzioni e visualizzazione universalmente accettati. La necessità di trovare delle costanti, e quindi di mostrare i contenuti in una determinata maniera, nasce dall esigenza di adattare la piattaforma ad ogni contesto e dominio applicativo (business, entertainment, information, ecc.). La presentazione, pur non essendo estranea al contesto, è concentrata nella definizione dei template visuali ed è dunque indipendente dalla tipologia e dalle peculiarità delle varie sorgenti dati.

77 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 76 Figura 5.4: Map-template, a sinistra la vista primaria e a destra un esempio di vista secondaria Il visual template esemplificato nella figura 5.4, denominato map-template, è composto da due viste differenti: ˆ union : vista primaria che contiene ed organizza su di una mappa interattiva, fornita dal servizio GoogleMaps, un insieme di punti di interesse, rappresentati ciascuno da un marker colorato. La struttura visuale di questi elementi, il marker, è quindi fissa e prestabilita. Ogni marker è identificato nella composizione da una coppia (latitudine,longitudine) o da una location indicante l indirizzo del punto d interesse. Il marker è di colore rosso quando la sua aggiunta alla composizione viene gestita in modo automatico dalla piattaforma in base ad uno schema dati indicato dall utente. I marker di colore blu rappresentano invece i punti d interesse che l utente ha aggiunto staticamente (ossia manualmente con una specifica azione di trascinamento) a partire da un istanza di dato contenuta nel data panel.

78 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 77 ˆ merge : vista secondatia che si attiva all apertura del baloon informativo di uno o più marker. Tali balloon, in quanto finestre d informazione, contenengono i dettagli relativi al punto d interesse selezionato. Per quanto anch esso dotato di una struttura di base rigida (il balloon), la vista secondaria può assumere diverse caratteristiche visuali a seconda del numero e della tipologia di dati che l utente vi destina tramite il trascinamento dei dettagli. Ogni elemento di questa lista di sarà caratterizzato da una intestazione, ossia il nome del dettaglio modificabile, e da un contenuto, ovvero il valore del dettaglio Il repository dei servizi La necessità da parte del compositore del mashup di disporre di diverse e innumerevoli sorgenti dati, per rendere più articolato ed efficace il prodotto finale realizzato, obbliga il DE a disporre di un repository di sorgenti dati costruito dall utente stesso attraverso un processo di registrazione guidato. In fase di design è possibile accedere al repository e selezionare le sorgenti dati d interesse per la composizione. Le stesse sorgenti saranno quelle utilizzate dall EE per generare il mashup al momento dell esecuzione. Il repository è strutturato in modo da permettere la registrazione di servizi RESTful che una volta invocati restituiscono dati in formato XML o Json. La descrizione dei dati da catturare nelle risposte dei servizi avviene tramite specificazione dei loro xpath, anche se è previsto l inserimento, in un secondo tempo, di interpretatori che estendano le capacità di identificazione dei dati oltre l utilizzo di path strettamente legati alle sintassi XML/Json. Una tipica sorgente dati è rappresentata da una URL di base che identifica il servizio, una stringa secondaria da accodare alla prima che ne specifica un operazione tra le varie eventualmente disponibili e da una serie di parametri che specifichino la query vera e propria da inoltrare.

79 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 78 Il modello del repository delle sorgenti dati è costituito dai seguenti elementi: ˆ categoria: l elemento categoria colleziona un insieme di servizi appartenenti allo stesso genere tematico (per esempio libri, eventi, viaggi, ecc.). ˆ servizio: l elemento servizio colleziona tutte le informazioni che identificano uno specifico Web Service. I dati registrati in questo elemento sono costituiti dal nome del servizio, da una breve descrizione che ne specifica le funzionalità e dall URL base del servizio. E quindi esclusa da questa la querystring (cioè la stringa di caratteri che segue generalmente il carattere? e che consente di passare al server uno o più parametri). ˆ operazione: l elemento operazione è costituito da un insieme di parametri. Rappresenta in pratica una particolare querystring. Un servizio può avere differenti operazioni, potendo quindi essere invocato con differenti set di parametri. Anche la risposta stessa del servizio dipenderà dall operazione tramite la quale è stato interrogato. L operazione può essere opzionale (di default) se il servizio non prevede una querystring aggiuntiva all URL di base. ˆ parametro: l elemento parametro rappresenta il singolo parametro appartenente alla querystring dell operazione e consiste in una coppia di valori <nome, valore>. Registrazione di una sorgente dati La registrazione della sorgente dati è realizzata attraverso un wizard (Figura 5.5) che guida l utente nell inserimento delle informazioni tramite una procedura precisa. Questa fase ha come requisito indispensabile che l utente abbia delle conoscenze relativamente avanzate nell ambito tecnico-informatico. In caso contrario la procedura di registrazione dovrebbe essere riservata ad un amministratore del repository che provveda a

80 CAPITOLO 5. ARCHITETTURA DELLA PIATTAFORMA VITE 79 popolarlo di sorgenti dati che, successivamente, possano essere utilizzate con facilità dagli utenti sviluppatori del mashup. Figura 5.5: Procedura di inserimento di una sorgente dati nella piattaforma Selezione di una sorgente dati Anche in questo caso la scelta del wizard permette all utente di selezionare la sorgente dati tramite una serie di passi successivi, agevolandone la ricerca. L utente seleziona innanzi tutto la categoria a cui appartiene il servizio desiderato, poi il nome del servizio e in ultimo una particolare operazione fra quelle disponibili per quel servizio. Tramite questa procedura viene selezionata la sorgente dati d interesse e, automaticamente, viene costruito l url dell interrogazione. L editor è ora in grado di invocare il servizio coi parametri corretti e di generare la rappresentazione dei dati nel data-panel. Figura 5.6: Selezione di una sorgente dati della piattaforma