POLITECNICO DI MILANO
FACOLTÀ DI INGEGNERIA DELL'INFORMAZIONE
Corso di Laurea in Ingegneria Informatica
Un approccio basato sui mashup per lo
sviluppo collaborativo di spazi informativi
condivisi
Relatore: Prof.ssa Maristella Matera
Correlatore:Ing. Matteo Picozzi
Tesi di laurea di:
Marco Tonazzo, Matr. 771090
Michele Pini, Matr. 770680
Anno Accademico 2012 - 20013
Sommario
I mashup sono delle applicazioni Web nate in risposta al bisogno degli utenti, che non siano necessariamente esperti di tecnologia, di comporre velocemente ed e cacemente determinate risorse disponibili nella Rete per creare delle nuove applicazioni, che rispondano alle proprie necessità contingenti.
Ad oggi un cospicuo numero di strumenti, basati su linguaggi di composizione intuitivi, sono stati proposti, in veste di tecnologia abilitante, sia all'interno della comunità scienti ca, sia in un variegato numero di realtà del Web 2.0, con il preciso ne di promuovere lo sviluppo di mashup in modo tale da coinvolgere sempre più estese fasce di utenti.
Purtroppo, nonostante la natura stessa dei mashup sia indissolubilmente cor-relata alla preminente natura sociale del Web 2.0, ancora non esistono proposte concrete che mirino ad abilitarne lo sviluppo collaborativo. Tali composizioni con-tinuano a rimanere applicazioni prettamente personali. Tale approccio nisce per limitare le potenzialità dei mashup, riducendone l'utilità al momento contingente ed al singolo individuo.
In questa trattazione si propone un approccio per lo sviluppo collaborativo di mashup. Partendo dalla elicitazione e dall'analisi dei principali requisiti per la collaborazione, contestualizzati all'interno dello sviluppo di Spazi Informativi Personali da parte dell'utente nale, si descrivono i passi fondamentali che hanno condotto alla realizzazione di una piattaforma, capace di esprimere al meglio le potenzialità dei mashup, supportando dinamiche di condivisione e creazione compartecipata di Spazi Informativi Comuni.
Indice
Elenco delle gure 10
1 Introduzione 11
1.1 Contesto e motivazioni . . . 11
1.2 Obiettivi . . . 13
1.3 Contenuti della tesi . . . 14
2 Stato dell'Arte 17 2.1 I Web Mashup . . . 17
2.2 Strumenti per la composizione di mashup . . . 20
2.2.1 Yahoo Pipes . . . 20
2.2.2 Quick and Easily Done Wiki . . . 21
2.2.3 Damia . . . 21
2.2.4 JackBe Presto . . . 22
2.2.5 Marmite . . . 22
2.2.6 MashArt . . . 22
2.2.7 ServFace . . . 23
2.2.8 SeCo: Big Data Visualization . . . 23
2.3 Google Drive: un applicativo collaborativo . . . 23
2.4 La collaborazione in spazi di lavoro Web-based . . . 25
2.5 Tecnologie per l'interazione in tempo reale . . . 26
2.5.1 Twisted Network . . . 26
2.5.2 Node.js . . . 27
2.5.3 Ajax Polling . . . 27
2.5.4 Comet . . . 28
2.5.5 HTML5 socket . . . 30
3 Ambiente integrato per la creazione di componenti e di mashup 31 3.1 PEUDOM . . . 31
3.2 ViTe . . . 33
3.3 Complementazione di PEUDOM e ViTe . . . 35
3.4 Note sui riferimenti ai diversi ambienti integrati . . . 37
3.6 Autenticazione e Login . . . 38
3.7 L'integrazione dei due ambienti . . . 39
3.8 Architettura della nuova applicazione . . . 43
3.8.1 Server-side e client-side . . . 43
3.8.2 La nuova architettura . . . 44
4 Requisiti di condivisione e collaborazione 47 4.1 De nizioni Preliminari . . . 48
4.2 Lato Social: creazione di una community e logiche di condivisione 50 4.2.1 Un passo imprescindibile . . . 50
4.2.2 I modi della condivisione . . . 50
4.2.3 Le dinamiche di gruppo e di condivisione . . . 53
4.3 Lato Collaborative: supportare la collaborazione al tempo dei mashup . . . 55
4.3.1 Esempi di collaborazione applicata . . . 55
4.3.2 Perché collaborare in PEUDOM . . . 57
4.3.3 Le dimensioni caratteristiche della collaborazione . . . 59
4.3.4 PEUDOM e i contesti di lavoro collaborativo . . . 61
4.3.5 Condivisione . . . 61
4.3.6 Strumenti per la collaborazione asincrona . . . 61
4.3.6.1 Noti che . . . 62
4.3.6.2 Annotazioni . . . 63
4.3.6.3 Controllo di versione . . . 64
4.3.7 Strumenti per la collaborazione sincrona . . . 65
4.3.7.1 Chat . . . 66
4.3.7.2 Live Session . . . 67
4.4 Una visione uni cata e uni cante . . . 76
5 Architettura e implementazione 77 5.1 Architettura per una piattaforma collaborativa . . . 77
5.2 Gli aspetti Social della piattaforma . . . 79
5.2.1 Creazione e gestione dei gruppi . . . 79
5.2.2 La condivisione . . . 80
5.3 Azioni relative ai ruoli . . . 81
5.4 Gli aspetti collaborativi della piattaforma . . . 82
5.4.1 Collaborazione asincrona . . . 82
5.4.1.1 Noti che . . . 83
5.4.1.2 Annotazioni . . . 89
5.4.1.3 Controllo di versione . . . 90
5.4.2 Collaborazione sincrona . . . 92
5.4.2.1 Modi ca in tempo reale di una composizione . . . 92
INDICE 7
6 Valutazione con gli utenti 103
6.1 Obiettivi . . . 103
6.2 Reclutamento degli utenti . . . 103
6.3 Metodologia . . . 104
6.4 Scenari . . . 105
6.4.1 Scenario Base . . . 106
6.4.2 Scenario Intermedio . . . 107
6.4.3 Scenario Avanzato . . . 107
6.5 Analisi dei risultati . . . 108
7 Sviluppi futuri 113 7.1 Modi che a seguito della fase di valutazione con gli utenti . . . . 113
7.2 Sviluppi futuri . . . 113
7.2.1 Mashup Dashboard . . . 114
7.2.2 Component Editor . . . 115
7.2.3 Group Manager . . . 116
7.2.4 Sharing e gestione le . . . 116
7.2.5 Pagina personale . . . 116
8 Conclusioni 117 A Valutazione con gli utenti 119 A.1 Questionario prima della valutazione . . . 119
A.2 Questionario dopo la valutazione . . . 120
Elenco delle gure
2.1 Modello di tipo user-driven . . . 19
2.2 Guadagno vs costo con i mashup . . . 19
2.3 Schema di funzionamento dell'Ajax Polling . . . 29
3.1 Schermata di PEUDOM . . . 32
3.2 Schermata di ViTe . . . 34
3.3 Esempio per la popolazione di un visual template . . . 34
3.4 Schema con la struttura funzionale di ViTe . . . 40
3.5 Schema con i due di tipi wrapper . . . 42
3.6 Schema architetturale di PEUDOM . . . 42
3.7 Schema architetturale degli ambienti integrati in PEUDOM . . . . 45
4.1 Visione complementare e visione evolutiva. . . 48
4.2 Rimozione critica dalla condivisione di un Servizio. . . 55
4.3 Matrice CSCW. . . 60
4.4 Architettura funzionale di PEUDOM . . . 76
5.1 Schema architetturale dell'applicazione . . . 78
5.2 Istantanea della pagina dei gruppi . . . 80
5.3 Tabella con i ruoli e le rispettive azioni per quanto riguarda le composizioni . . . 81
5.4 Tabella con i ruoli e le rispettive azioni per quanto riguarda le composizioni . . . 82
5.5 Confronto fra il ruolo di Super-User (sulla sinistra) e il ruolo di Viewer . . . 82
5.6 Lettura di una nuova noti ca. . . 84
5.7 Schema database per la gestione delle noti che . . . 86
5.8 Schema modularità dell'oggetto che gestisce le noti che . . . 86
5.9 Esempio codice JSON dell'elenco delle noti che . . . 88
5.10 Schema della propagazione delle azioni e coda azioni sul database 93 5.11 Schema della propagazione delle azioni per Live Editing . . . 95
5.12 Esempio codice JSON contenente un'azione . . . 96
5.14 Esempio di Attività Recenti . . . 99
5.15 Schema del Live Editing con la comunicazione degli highlight . . . 100
5.16 Istantanea della chat . . . 100
6.1 Tempo di esecuzione del test . . . 109
6.2 Comprensione degli elementi base di PEUDOM . . . 110
6.3 Valutazione dell'interfaccia per la de nizione dei ruoli . . . 111
6.4 Valutazione degli strumenti per la collaborazione . . . 112
Capitolo 1
Introduzione
1.1 Contesto e motivazioni
Web 2.0 è un termine utilizzato per indicare uno stato di evoluzione del World Wide Web, rispetto a una condizione precedente. Si indica come Web 2.0 l'in-sieme di tutte quelle applicazioni online che permettono un elevato livello di interazione tra il sito web e l'utente. Ne sono un esempio blog, forum, chat e wiki, così come le piattaforme di condivisione di media come Flickr, YouTube, e allo stesso tempo i social network come Facebook, Myspace, Twitter, Google+. Ognuna di queste realtà è accomunata da uno sviluppo veicolato da opportune tecniche di programmazione Web, aerenti al paradigma del Web dinamico, in contrapposizione al cosiddetto Web statico o Web 1.0 [6].
Oltre che per l'elevato livello di interazione tra l'utente e la Rete, il Web 2.0 è caratterizzato dall'essere il Web dei contenuti creati dall'utente, ovvero uno spazio che si apre alla raccolta di contenuti, che non provengano solamente da un limitato numero di utenti con competenze speci che, ma che coinvolgano possibilmente un generico individuo, desideroso di apportare il proprio contributo al Web 2.0.
Un simile scenario, in concomitanza con la nascita e lo sviluppo di servizi se-condo il paradigma SOA (Service Oriented Architecture), ha velocemente portato al concetto di riutilizzo e integrazione delle risorse Web sotto forma di contenuti. Una delle più grandi innovazioni sono stati, e sono tuttora, i mashup: compo-sizioni di più servizi Web, che, integrati e fusi tra di loro, generano un nuovo servizio, che comprende e integra contemporaneamente le caratteristiche e le in-formazioni di tutti i suoi componenti. In informatica un mashup è dunque un sito o un'applicazione Web di tipo ibrido, cioè tale da includere dinamicamente informazioni o contenuti provenienti da più fonti.
Un tale strumento permette di supportare gli utenti nel rapido accesso a va-riegate fonti di informazione e nella creazione di un prezioso surplus informativo,
generato dall'integrazione dei servizi e dei dati disponibili sul Web. Per gli utenti nali, questo rappresenterebbe una preziosa opportunità per soddisfare la lun-ga coda dei propri bisogni speci ci. Allo stesso modo per i fornitori dei servizi, l'opportunità è quella sfruttare le informazioni derivanti dalla interazione degli utenti ai ni di studiare i livelli di utilizzo del servizio e di poter ri ettere circa la rimodulazione e la ride nizione dei propri servizi, identi candone i migliori utilizzi nel campo dell'innovazione [14].
I precedenti vantaggi possono concretizzarsi solo a patto che le tecnologie di-ventino accessibili agli utenti nali. Sfortunatamente, come dimostrato in recenti studi relativi ai Web mashup, soprattutto per quanto riguarda il livello di integra-zione dei servizi, l'eettiva composiintegra-zione di mashup spesso rimane una prerogativa di un più circoscritto numero di utenti, i quali possiedono competenze speci che medio-alte [14]. Tale situazione è accentuata nell'ambito dei dispositivi mobili, ambiente nel quale anche gli esperti possiedono una esperienza più limitata.
Per questo motivo, nonostante le recenti ricerche spingano l'utente nale ad assumere un ruolo più attivo nell'interazione con i sistemi, trasformando que-st'ultimo da passivo consumatore di informazioni a produttore, le favorevoli pro-spettive del Web 2.0 si trovano a scontrarsi con un preciso problema tecnologico. Per supportare una tale evoluzione non solo sono necessarie una riprogettazione e un nuovo sviluppo dei sistemi di interesse, ma bisogna allo stesso tempo stu-diare un nuovo paradigma di interazione che permetta all'utente di interfacciarsi con successo con la complessità insita all'interno di tali applicazioni. Proprio per questa ragione i più recenti applicativi nel campo dei mashup si inseriscono nel più generale ambito di studi dell'End-User Development (EUD), il cui obiettivo principale è proprio quello di avvicinare l'utente alla programmazione. Le tecniche implementate all'interno di tale disciplina, grazie al loro approc-cio visuale e a paradigmi di programmazione-per-esempio (PbE), sono essenziali nell'intermediazione della produzione di mashup da parte di utenti non esperti.
Ancora una volta però, al crescere della complessità dello scenario, spesso l'utente, sfruttando unicamente i propri mezzi, non risulta in grado di portare a termine il compito assegnato. È proprio a partire da una simile considerazione che gli autori in [29] hanno recentemente studiato un dierente approccio per risolvere questo problema. In tale visione si ritiene possibile supportare l'e cace sviluppo di mashup grazie ad una piattaforma che, oltre a permetterne la compo-sizione dei servizi, implementi alcune basilari logiche derivanti dall'applicazione del Crowdsourcing. La lungimiranza di tale approccio consiste nella presa di coscienza che, allo stato attuale della ricerca, il solo EUD non risulta su cien-te. Contemporaneamente l'uso del Crowdsourcing si con gura come un prezioso alleato nel colmare alcune lacune. Distribuendo su più soggetti l'elevato carico computazionale dovuto alla complessità del compito, l'utente ha la possibilità di attingere alla così detta wisdom of the crowd, riuscendo, tramite uno sforzo
collet-1.2 Obiettivi 13 tivo, a recuperare quelle idee, quei servizi e quelle competenze, necessarie per la realizzazione del proprio mashup, o addirittura il mashup stesso. L'impossibilità del singolo è risolta on-demand, inoltrando una chiamata aperta a tutti i mem-bri della comunità. Questo meccanismo, per quanto permetta il raggiungimento dell'obiettivo, non contribuisce alla formazione dell'utente, il quale si trova ora in possesso del componente desiderato, ma non delle competenze speci che che gli permetterebbero di ripetere un analogo procedimento di creazione. Un ulteriore sviluppo in tale direzione deve permettere all'utente di guadagnare tali compe-tenze di composizione tramite la manipolazione diretta degli strumenti messi a disposizione, in unione ad una interazione diretta con altri utenti. Un simile obiettivo, che superi i limiti del Crowdsourcing, sembra essere particolarmente rilevante in vista della creazione di una nuova piattaforma.
Questo lavoro di tesi si inserisce in un nuovo orizzonte che permette di sotto-lineare la potenza e la rilevanza di un approccio collaborativo nella creazione di mashup. Fino a questo momento questi ultimi sono stati considerati solamen-te come applicazioni personali e verticali, creati dall'usolamen-tensolamen-te nale, assemblando risorse pronte all'uso per risolvere problemi circostanziali: tale de nizione non è più su ciente per inquadrare il concetto di mashup. Non solo nello scenario illustrato precedentemente, ma anche in una situazione in cui tali composizioni non siano realizzate con ni ricreativi, bensì supportino decisioni strategiche, la collaborazione appare come driver necessario. Si pensi ad un mashup utilizzato come cruscotto aziendale, sfruttato da un team di colleghi per la piani cazione e controllo di una speci ca politica. In questi nuovi scenari di intelligenza collettiva la capacità per un utente di condividere e collaborare all'interno di un particola-re progetto non solo permette di miglioraparticola-re la qualità del prodotto nale, ma si con gura come un utile supporto delle logiche sviluppate dall'EUD.
1.2 Obiettivi
In forza di quanto aermato no ad ora, all'interno di questo elaborato si desidera: 1. Ri ettere sul ruolo della collaborazione in quanto strumento abilitante, che permette di supportare in maniera più completa ed e cace lo svilup-po di mashup, permettendo di superare alcune limitazioni raggiunte da piattaforme analoghe, le quali implementano solo logiche relative all'EUD; 2. Comprendere come sia possibile contestualizzare le dinamiche collaborative all'interno della realtà dei mashup, ambito in cui tale prospettiva è stata no ad ora trascurata;
3. Valutare se e come la collaborazione permetta di implementare un paradig-ma di interazione valido, in grado di disintermediare lo sviluppo di paradig-mashup e di applicativi Web in generale, abbassandone il grado di di coltà.
4. Progettare e sviluppare tali dinamiche all'interno di uno speci co framework lightweight che combini buone capacità nella manipolazione dei mashup con una più spiccata natura collaborativa, che permetta l'interazione concorren-te in maniera sincrona e asincrona degli uconcorren-tenti in un conconcorren-testo di condivi-sione e reciproca consapevolezza. Tutto ciò veicolato tramite una applica-zione Web, che assicuri portabilità e accesso istantaneo alla piattaforma, eliminando fastidiose procedure di installazione time-consuming;
5. Valutare i risultati conseguiti grazie ad una sistematica interazione con al-cuni utenti nali, così da valutare l'e cacia del nuovo approccio combinato alla creazione di mashup;
1.3 Contenuti della tesi
In questo elaborato si presenta una prospettiva incentrata sullo sviluppo colla-borativo di Spazi Informativi Comuni (Common Information Spaces - CIS), che coinvolgano lo sviluppo di mashup. In ogni capitolo si cerca di mettere a fuoco tutte le importanti tappe che permettono all'utente di concludere con successo la realizzazione di una propria composizione, ri ettendo e declinando all'interno dello speci co ambito applicativo importanti concetti di interazione, condivisione e collaborazione.
• Capitolo 2 - Stato dell'arte: Capitolo 2 - Stato dell'arte: in questo capitolo si presenta una panoramica sulle realtà presenti sul Web e in letteratura, le quali hanno costituito le basi di questo lavoro. Partendo da una introduzio-ne al mondo dei mashup, si prosegue con la descriziointroduzio-ne di alcuni strumenti per lo sviluppo di tali composizioni. Nell'ambito della collaborazione si mo-stra l'esempio di Google Drive, seguito da alcune considerazioni, presenti in letteratura, verso uno sviluppo collaborativo. In ultima istanza si pre-sentano i principali framework presi in considerazione per lo sviluppo delle dinamiche in tempo reale.
• Capitolo 3 - Ambiente integrato per la creazione di componenti e di mashup: in questo capitolo si discute dei motivi che hanno spinto a consolidare in un'unica piattaforma le esperienze pregresse, nate da alcuni progetti al-l'interno del Politecnico di Milano. Segue poi una discussione concettuale, concretizzata successivamente nel capitolo relativo all'implementazione, cir-ca le logiche da implementare per creare un'importante strato, che permetta non solo di integrare le diverse realtà precedenti, ma che costituisca il fon-damento e il collante indispensabile, capace di sostenere le successive parti sociali e collaborative.
• Capitolo 4 - Requisiti di condivisione e collaborazione: in questo capito-lo si entra nel vivo della esposizione del progetto di PEUDOM. In questa
1.3 Contenuti della tesi 15 prima parte si desidera porre le basi concettuali, a sostegno della parte im-plementativa. Ogni argomento proposto ha il preciso compito di innescare una attenta ri essione circa le tappe fondamentali da seguire per giungere all'obiettivo della realizzazione di una piattaforma collaborativa. Non solo si cerca di dibattere le criticità e le importanti questioni presentatesi nella fase di progettazione, durante la ricerca e l'analisi dei requisiti, ma si cerca anche di trattare ogni argomento in maniera sistematica, così da inserire ogni tassello della trattazione all'interno di una più ampia visione ordina-ta. In ogni sezione si dibatte sull'apporto alla piattaforma nale di ogni caratteristica peculiare, quali integrazione, interazione sociale degli uten-ti e condivisione, collaborazione concorrente, sincrona e asincrona. Scopo principale è quello di identi care le funzionalità principali per PEUDOM, orchestrandone applicazione, interazione e integrazione.
• Capitolo 5 - Architettura e implementazione: in questo capitolo si riper-corrono le tappe presentate in precedenza dallo speci co punto di vista dell'implementazione. In ogni sezione si espongono le soluzioni tecniche e tecnologiche adottate in forza delle funzionalità e degli obiettivi concordati in fase di progettazione e analisi funzionale. Ove richiesto, si confrontano scelte implementative dierenti, mostrandone pregi e difetti. In ogni argo-mento si cerca di spiegare l'implementazione di ogni logica a un su ciente grado di astrazione, fornendo, ove ritenuto opportuno, ulteriori dettagli relativi alle scelte di programmazione. Integrazione, condivisione e colla-borazione sono arontate con una particolare attenzione alle performance, in uno sviluppo che mira ad ottimizzare la richiesta di risorse, approccio essenziale soprattutto nella collaborazione in tempo reale.
• Capitolo 6 - Valutazione con gli utenti: in questo capitolo si descrivono le fasi che hanno permesso di testare la piattaforma realizzata con un gruppo di utenti. Si presentano gli scenari di utilizzo, così come i relativi risultati. • Capitolo 7 - Sviluppi futuri: in questo capitolo si descrivono brevemente alcuni cambiamenti eettuati a PEUDOM a seguito della valutazione con gli utenti. Segue poi una analisi di alcuni sviluppi futuri, che si ritengono interessanti ai ni del miglioramento e dell'estensione della piattaforma. • Capitolo 8 - Conclusioni: in questo capitolo si riassumono i risultati
eet-tivamente conseguiti, alla luce degli obiettivi consolidati e dell'esperienza fatta con la piattaforma e con gli utenti.
Capitolo 2
Stato dell'Arte
Prima di inoltrarsi nella trattazione vera e propria del lavoro svolto, si desidera fornire una panoramica sulle realtà consolidate concernenti gli applicativi per la creazione di mashup, gli strumenti attualmente più in uso per la collaborazione, e alcune proposte per la composizione collaborativa di applicazioni Web. In questo caso si è deciso di dividere la trattazione in due sezioni dierenti, allo scopo di presentare separatamente le applicazioni disponibili sul Web sviluppate da terzi e le piattaforme realizzate nei recenti anni al Politecnico di Milano. In quest'ultimo caso, grazie alla possibilità e alla necessità di entrare in contatto con tali sistemi, si desidera fornire una descrizione più dettagliata, la quale risulterà funzionale alla parte dei successivi capitoli, dedicata all'integrazione di alcune delle realtà presentate. In ne si presenterà anche per l'ambito collaborativo quella che si ritiene una delle principali realtà di riferimento del settore. Anche in questo caso, la trattazione permetterà di meglio contestualizzare e comprendere le scelte attuate in fase di progettazione e di sviluppo.
2.1 I Web 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 com-prende e integra contemporaneamente le caratteristiche e le informazioni di tutti i suoi componenti. Tali applicazioni 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,composti da interfacce Web-user, che integrano logica e contenuti
rilasciati da soggetti terzi tramite l'utilizzo di opportune API (Application Pro-gramming Interface). I primi che hanno cominciato a rendere pubbliche le loro interfacce per poter accedere ai propri servizi sono stati i grandi Web competi-tor 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 diusione di tali servizi. Conseguentemente, il numero di API è in continuo aumento poiché, per ogni nuovo Web Service creato, vengono rilasciate le speci che e i dettagli necessari per la corretta fruizione del servizio. Tuttavia, a causa dell'instabilità di un API, che potrebbe cambiare le sue speci che da un momento all'altro, costruire mashup ad hoc è una pratica poco diusa. I ma-shup 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 nale. Tutto ciò a con-ferma 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 lin-guaggi di composizione per i cosiddetti Web service con risultati molto buoni (per es. BPEL [22]), e il campo dell'integrazione dei dati è ormai un'area consolidata, nonostante le nuove s de 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 standar-dizzazione di certe tecnologie Web (si ricordi GoogleMaps). La produzione di un mashup prevede una fase di prototipizzazione rapida, costituita da un'inte-grazione veloce di dierenti 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. Lo sviluppo di un mashup è composto da un insieme di fasi che sono in re-lazione circolare [35]. 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 dierenti servizi, la sua costruzione avviene iterativamente ed è guidata dal funzionamento desiderato. Partendo dunque da un determinato problema (come per es. la visualizzazione sulla carta geogra ca 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à cor-rettamente funzionante no 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
uti-2.1 I Web Mashup 19
Figura 2.1: Modello di tipo user-driven
lizzato). Quindi il mashup viene utilizzato no 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. 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 [31].
Figura 2.2: Guadagno vs costo con i mashup
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 [31], è 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 classi cati in tre categorie:
• mashup commerciali, di solito si possono de nire come applicazioni che com-binano risorse informative Enterprise con altri servizi Web in una singola
presentazione. Il processo di sviluppo è essibile poiché richiede la continua collaborazione tra gli sviluppatori e i clienti, per la de nizione e l'imple-mentazione dei requisiti di business. I mashup aziendali dal punto di vista dell'interfaccia utente presentano diverse somiglianze con le rich-internet-applications (RIA) per la dimensione di interattività,multimedialità e velo-cità 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 [7] che raccoglie diverse fonti di dati (per es., World Health Organization) per ottenere una visione uni cata e completa, su una mappa GoogleMaps, dello stato attuale globale delle malattie infettive e il loro eetto 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 Strumenti per la composizione di mashup
Con l'avvento dei Web Mashup, sono stati proposti in letteratura e sul mercato diversi strumenti [19, 28] il cui obiettivo è facilitare lo sviluppo dei mashup da parte degli utenti nali. Tali strumenti si basano su notazioni visuali e intuitive, che cercano di astrarre il più possibile dai requisiti tecnologici, facilitando così l'integrazione dei servizi da parte di utenti inesperti di tecnologie. Di seguito si descrivono i principali strumenti proposti negli ultimi anni. Alcuni di essi sono stati nel frattempo dismessi, ma il paradigma di composizione è comunque signi cativo per individuare le potenzialità che tale classe di applicazioni può orire nello scenario dei Web mashup.
2.2.1 Yahoo Pipes
Partendo da una o più sorgenti dati (data feed), attraverso un editor a inter-faccia visuale e azioni drag-and-drop e possibile creare la propria applicazione [39]. Questo tool si basa su una 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. Gli operatori principali sono quelli che consentono la manipolazione dei dati (per esempio altering o sorting) e i più so sticati sono gli operatori di looping, di espressioni regolari o di conteg-gio. Inoltre è possibile eettuare operazioni di local data extraction (come per esempio le coordinate geogra che della posizione attuale) oppure una estrazione più globale su tag o parole chiave di generiche fonti dati.
2.2 Strumenti per la composizione di mashup 21
2.2.2 Quick and Easily Done Wiki
Proposto da IBM [20], è un tool a supporto della creazione di mashup, che viene eseguito all'interno del browser e che viene supportato dall'accesso all'IBM Ma-shup Hub. Grazie all'hub messo a disposizione da IBM e possibile creare data feed e widget. I mashup così creati, sono immediatamente visibili e vi è la possi-bilità di rieditarli e condividerli subito nel Web. I mashup risultanti sono dunque costituiti principalmente da widget basati su tecnologie come 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 nale desiderato.
2.2.3 Damia
DAMIA [34], prodotto anch'esso dall'IBM, e basato su un'interfaccia client Web che mette a disposizione di sviluppatori e utenti, un set di tool easy-to-use 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 bene ci del-l'integrazione di dierenti 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;
• 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 modica 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;
2.2.4 JackBe Presto
Questo strumento, fornisce una piattaforma orientata alla creazione di composi-zioni di servizi dedicati al mondo Enterprise [21]. Ore quindi un valido supporto sia a sviluppatori software sia a utenti avanzati. Le principali funzionalità che si evidenziano in JackBe Presto sono:
• composizione di mashup attraverso interfacce gra che, tool di drag-and-drop e un linguaggio dichiarativo adatto ai mashup Enterprise;
• supporto all'Enterprise Mashup Markup Language;
• accesso ai servizi Web, database SQL, fonti RSS e Web clipping;
• interfacce per il collegamento ai principali tool Enterprise come Oracle WebCenter, HP Sysnet e Excel di Microsoft;
2.2.5 Marmite
Marmite è anch'essa una piattaforma [38] che permette di ottenere come risultato un mashup. Questo tool ha come obiettivo la creazione da parte dell'utente nale, che non dispone di particolari capacita 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 ussi di dati e sulla loro visualizzazione e rappresentazione;
2.2.6 MashArt
L'approccio di MashArt [15] si basa nell'aiutare programmatori non professio-nali, con tecniche e astrazioni easy-to-use, a creare e gestire applicazioni Web composite. In particolar modo MashArt fornisce le seguenti funzionalità:
• un modello uni cato 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 uni cato 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;
2.3 Google Drive: un applicativo collaborativo 23 • una piattaforma di sviluppo ed esecuzione che facilita la creazione, il te-sting e il mantenimento dell'applicativo. MashArt e interamente residente nel layer server side e dunque completamente Web-based (zero client-side coding);
2.2.7 ServFace
ServeFace [3] e una piattaforma a supporto della creazione di servizi model-driven, 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 dierenti:
• composizione di un servizio orientato alla presentazione (presentation-oriented service composition), nel quale la creazione del servizio avviene modellando gra camente l'applicativo tramite tecniche di UI;
• composizione di servizi dedicati a speci ci obiettivi (task-oriented service-composition), che sfruttano certi modelli di interfacce gra che per generare una nuova soluzione, creata speci catamente per una particolare piattafor-ma, come per esempio gli smartphone;
2.2.8 SeCo: Big Data Visualization
Search Computing [2], è una piattaforma che permette di eseguire delle query complesse del tipo: Dove posso partecipare ad una conferenza interessante, nel mio paese e vicino ad una località marittima?, interagendo con una serie di servizi di ricerca, eseguendo un ranking dei risultati e combinandoli tra loro.
All'interno di questa grande realtà è stato sviluppato un piccolo progetto per la visualizzazione di grandi quantità di dati, all'interno del quale, è stato possibile combinare, su una stessa visualizzazione, più strumenti che mostrassero i dati sotto diversi aspetti. Per esempio come risultato di una ricerca su hotel, musei e ristoranti nell'intorno della stazione centrale di Roma, è possibile visualizzare i risultati della ricerca in triple, oppure ordinando i Ristoranti per vicinanza alla stazione, visualizzandoli allo stesso tempo su di una mappa. La combinazione di queste visualizzazioni su una stessa pagina è essa stessa un mashup.
2.3 Google Drive: un applicativo collaborativo
Nato nel 2012, è un sistema di storage di le fornito da Google [1]. Nasce però come l'estensione e l'arricchimento della precedente piattaforma: Google Docs. Questa piattaforma, sempre fornita dal famoso motore di ricerca, è stata crea-ta e ultimacrea-ta tra il 2005 e il 2007, con lo scopo di essere la diretcrea-ta concorrente
della suite per u cio Microsoft O ce. Infatti Google, all'interno della sua piat-taforma, fornisce una serie di strumenti che permettono l'elaborazione di testi e la produzione di fogli di calcolo e la creazione di presentazioni, oltre ad una serie di strumenti utili per la creazione di form, questionari, e semplici disegni, andando ad infastidire il famoso Paint, applicazione inclusa nei sistemi operativi Microsoft. La vera innovazione però, introdotta da Google per la prima volta, è il fatto che sia gli strumenti che i le su cui si lavora sono conservati sul server. Questo non richiede di installare alcunché da parte dell'utente e rende i contenuti disponibili in qualunque luogo ci si trovi. Infatti l'altra novità è che per accedere agli strumenti e ai le salvati c'è bisogno solo di un browser. Ciliegina sulla torta, Google mette a disposizione questi strumenti assolutamente gratuitamente.
Le innovazioni però non sono nite, infatti, essendo i le conservati sul server, l'utente ha la possibilità di condividerli con altri utenti, e così permettere ad altri di modi care il proprio lavoro. La vera innovazione sta nel fatto che se due utenti si connettono nello stesso momento allo stesso le, è possibile modi carlo insieme in tempo reale, potendo visualizzare le modi che dell'utente nel momento in cui le compie.
La nuova versione di Google Docs, Google Drive, mantiene gli stessi strumenti del precedente framework, aggiungendo strumenti e supporti per altri le, per-mettendo l'esportazione dei le in formati supportati dalla maggior parte degli editor conosciuti (Microsoft O ce incluso), ed estendendo la compatibilità con la maggior parte dei formati. Infatti uno dei punti di forza del nuovo framework sta appunto nella possibilità non solo di creare nuovi documenti, ma di poter importare quelli già esistenti, senza la minima di coltà.
Perciò i punti di forza di questa piattaforma, che sono poi quelli a cui ci si è ispirati per l'implementazione della piattaforma oggetto di questa trattazione, sono:
• la possibilità di creare dei prodotti totalmente online, senza bisogno di installare nulla sul proprio pc, che sono disponibili all'utente da qualsiasi postazione.
• la possibilità di rendere pubblico il proprio lavoro condividendolo con per-sone che si conoscono, oppure semplicemente pubblicando il link al docu-mento.
• la possibilità nel momento della condivisione di poter stabilire delle li-mitazioni, per quanto riguarda la modi ca, alle persone con cui so sta condividendo.
• la possibilità che due utenti, quando connessi allo stesso documento, pos-sano modi carlo in tempo reale visualizzando all'istante ciò che uno sta scrivendo.
2.4 La collaborazione in spazi di lavoro Web-based 25 • la possibilità di lasciare sul documento messaggi e annotazioni permanenti,
che saranno visibili alla connessione degli altri utenti.
Questo è ciò che rende Google Drive un potente strumento, a cui ci si è ispirati nello sviluppo del supporto alla collaborazione, che ci si accinge ad introdurre nei prossimi capitoli.
2.4 La collaborazione in spazi di lavoro Web-based
I tool per mashup descritti precedentemente orono paradigmi di composizio-ne che, se pur e caci, si concentrano su applicazioni single-user, mentre non supportano la co-creazione di spazi di lavoro in cui l'informazione sia condivisa. Ciò nonostante, il bisogno di meccanismi che permettano all'utente di collabo-rare nella creazione di artefatti Web è resa evidente da alcuni lavori proposti in letteratura.
Nel contesto del Web-based Collaborative Learning, la nozione di Web Space Con guration è introdotta in [23] in quanto contenitore basilare per l'instanzia-zione dei W3C Widgets. L'approccio proposto si caratterizza per l'indipendenza della composizione dei widget creata dall'ambiente di esecuzione. Una tale indi-pendenza è così sfruttata per supportare la portabilità delle applicazioni svilup-pate, così come la loro condivisione e la loro modi ca collaborativa. Più nello speci co, la condivisione e la modi ca cooperativa sono raggiunte stabilendo un legame a lungo termine con il proprietario dello spazio Web, il quale invita gli al-tri utenti ad unirsi alla visione dello spazio Web (fase di broadcasting) e a editare liberamente i contenuti (fase di co-editing).
In [29] gli autori propongono il Croudsourcing come paradigma in cui la par-tecipazione dell'utente è utilizzata come soluzione in risposta a nuove necessità nello sviluppo di applicazioni Web, tentando di risolvere collettivamente i pro-blemi relativi all'adattamento della visualizzazione di una stessa applicazione su schermi di dispositivi dierenti. Relativamente a questo approccio, gli svilup-patori di sistema possono fornire una interfaccia nella quale le funzioni adattive possono evolvere in tempo reale con l'aiuto degli utenti, i quali possono ri nire tali requisiti al ne di adattarli ai propri contesti di utilizzo. Questo paradigma apre lo sviluppo Web alla dimensione sociale. L'obiettivo in questo caso è pe-rò limitato alla sola riorganizzazione del livello di presentazione in funzione del dispositivo correntemente utilizzato da un singolo utente, mentre si trascura la collaborazione e la coordinazione di diversi utenti. In aggiunta, un tale approccio si concentra esclusivamente nella modi ca del livello di presentazione, ignorando completamente la modi ca del contenuto dell'applicazione.
In [19] gli autori propongono una infrastruttura generica che supporti la con-sapevolezza di contesto, che fornisca basilari servizi di awareness che siano però riutilizzabili in dierenti piattaforme. Tale supporto è ancorato ad un livello
standardizzato che permette di svincolare una simile infrastruttura dallo speci- co contesto applicativo (application-agnostic solution). Client dierenti inclu-dono quindi un componente, il generic awareness adapter, che integra opportuni widget e si occupa di orchestrare i meccanismi di awareness, attraverso la pro-pagazione delle informazioni di contesto (dal client verso il server e viceversa). L'approccio è molto interessante, soprattutto se si considera la sua portabilità attraverso piattaforme dierenti e la sua intrinseca estensibilità, essendo basato sull'integrazione di widget, che gestiscono i diversi aspetti collaborativi.
2.5 Tecnologie per l'interazione in tempo reale
Dopo aver rivolto lo sguardo alle principali applicazioni presenti sel Web e in letteratura, si passano in rassegna alcuni framework speci ci, presi in conside-razione al ne di realizzare meccanismi di collaboconside-razione in tempo reale simili a quelli presentati durante la descrizione di Google Drive.
2.5.1 Twisted Network
Questo framework si basa su un sistema scritto in Python che rispetta il paradig-ma di programparadig-mazione chiaparadig-mato event-driven. Questo paradigparadig-ma prevede che all'interno di ogni richiesta inviata al server, da parte del client, siano passate, co-me paraco-metro, anche due funzioni, una di callback e una di errback. La prima è la funzione che viene eseguita nel momento in cui l'evento che sta aspettando il client avviene, la seconda viene eseguita solo se vi è un errore legato al suddetto evento. In questo modo il server non si preoccupa di stare in attesa dell'evento richiesto dal client, fermando l'esecuzione sia dell'applicazione, ma sapendo già quali azioni dovrà fare nel momento in cui l'evento viene intercettato, sia client che server, possono continuare la loro esecuzione senza creare attese o ritardi. Un approccio event-driven di questo tipo, fornisce un utile supporto per la col-laborazione in tempo-reale, visto che la colcol-laborazione di questo tipo si adatta perfettamente ad un modello ad eventi: appena uno degli utenti connessi esegue un azione, la funzione di callback che era in attesa di quell'evento, viene eseguita e l'evento viene propagato a tutti gli altri utenti. Sembrerebbe la soluzione otti-ma al probleotti-ma che stiamo arontando, se non fosse per un particolare: è scritto in Python. Non che questo fatto di per se sia un problema, alla ne Python è un validissimo linguaggio di programmazione server-side, ma come abbiamo vi-sto nei capitoli precedenti, la nostra piattaforma già fa convivere forzatamente due linguaggi server-side dierenti e non compatibili, JAVA e PHP. L'aggiunta di un terzo linguaggio che comunque ha bisogno di un suo interprete installato sul server, porterebbe a delle instabilità e complicazioni che potrebbero rivelarsi non risolvibili, o rendere la piattaforma inutilizzabile. Per questo motivo è stato deciso di non utilizzare questo framework per la piattaforma.
2.5 Tecnologie per l'interazione in tempo reale 27
2.5.2 Node.js
Node.js è un altro framework, molto simile al precedente, con il grande vantaggio che è scritto in Javascript. Tale network rispetta come il precedente il paradigma event-driven, con il passaggio di funzioni di callback all'interno della richiesta da parte del client. Perciò gode di tutti i vantaggi che abbiamo descritto per il network precedente. La vera innovazione introdotta da questo network è il fatto di utilizzare un linguaggio, tradizionalmente utilizzato solo per programmazioni client-side, per gestire un server. Tale soluzione, oltre ad essere innovativa è estre-mamente e ciente, perché Javascript, essendo tipicamente eseguito dal browser, ha sviluppato, una particolare predisposizione a gestire eventi asincroni e fun-zioni di callback, cose che sono alla base del paradigma event-driven. Abbiamo detto che la soluzione è e cente, perché quasi tutti i linguaggi di programmazio-ne tipicamente server-side, non hanno alcun supporto per l'esecuzioprogrammazio-ne asincrona delle funzioni, sopperendo a questa mancanza attraverso una complicata gestione dei thread che è oltremodo scomoda e di cile da impostare in maniera e ciente. L'unico problema che presenta questo network è che si basa sul JavaScript Engine V8, che è il runtime di Google utilizzato anche da Chrome e non disponibile su tutte le piattaforme. Questo vuol dire che se facessimo uso di questa tecnologia la nostra applicazione non sarebbe fruibile da parte di tutti gli utenti. Questa è una limitazione molto forte per un'applicazione web che presenta al proprio interno degli aspetti social e collaborativi. Tuttavia questo sistema è implementato da Google per la propria suit Google Drive, e tale sistema è disponibile per tutti gli utenti. Infatti gli sviluppatori della piattaforma hanno previsto due metodi al-ternativi, nel caso in cui gli strumenti per utilizzare Node.js non siano disponibili sul client, allora viene utilizzato un altro sistema, sicuramente meno performante, ma compatibile con tutti gli utenti. Naturalmente noi ci siamo ispirati al modello di collaborazione di Google Drive, ma consapevoli di non poterlo eguagliare, e lo sviluppo di un doppio sistema di collaborazione è uno degli aspetti che non possiamo imitare. Abbiamo perciò deciso di non adottare Node.js per non li-mitare gli utenti che non hanno gli strumenti necessari per poter accedere alla piattaforma. Tuttavia in un futuro, in cui i browser saranno più evoluti e avranno tutti un miglior supporto per queste tecnologie, l'adozione di questo sistema sarà sicuramente una scelta da valutare.
2.5.3 Ajax Polling
L'ajax polling è un pattern implementativo per la realizzazione di un sistema che si comporti in maniera event-driven, ma solo emulandolo. Infatti con questo pat-tern non sono veramente gli eventi a suscitare le azioni, o meglio sono gli eventi che se accaduti determinano un comportamento, altrimenti un altro, ma in ogni caso le interrogazioni vengono fatte. Un vero sistema event-driven infatti se non vi sono eventi non fa nulla, nel senso che non esegue nemmeno delle chiamate
al server, questo pattern invece prevede che vi siano delle chiamate periodiche verso per controllare che qualcosa sia accaduto. Infatti l'ajax polling prevede di sfruttare il meccanismo delle chiamate Ajax, visto prima, verso delle pagine che si trovano sul server, permettendo di eseguire delle azioni a chiamata termina-ta, tutto senza dover ricaricare la pagina. Inoltre questo approccio si basa sul supporto di Javascript alle chiamate asincrone che non interrompono l'esecuzio-ne della pagina. Infatti, come mostrato in gura 2.3 per implementare questo meccanismo si imposta una chiamata periodica, con un tempo di riposo che può essere variabile e corrisponde al ritardo massimo che si tollera per l'aggiornamen-to della pagina. All'interno della funzione che viene richiamata periodicamente e in maniera asincrona, vi è una chiamata Ajax verso una pagina sul server, che controlla se ci sono stati cambiamenti dall'ultima chiamata. In ogni caso, sia che ci siano eventi da noti care, sia che non ve ne siano, la chiamata verso il server viene comunque eettuata, per questo non si può de nire questo meccanismo puramente event-driven.
Questo approccio presenta numerosi vantaggi: • è compatibile con qualsiasi sistema e browser
• è possibile attraverso l'impostazione di un time-out adeguato stabilire che, se il server non riceve la chiamata di un utente oltre la soglia impostata, tale utente è o ine
• è possibile tenere sotto controllo il ritardo massimo di aggiornamento della pagina, calcolando il fatto che il ritardo medio sarà sicuramente inferiore Vi sono comunque molti svantaggi: questo approccio genera un considerevole tra co sulla rete, e se la rete dell'utente non è adeguatamente veloce, vi sono delle latenze nelle risposte del server, che se troppo lunghe potrebbero far scattare il time-out e considerare un utente o ine quando in realtà non lo è. Inoltre questa tecnica basa tutto il carico computazionale sul client, perciò se l'utente ha un computer particolarmente non performante, il browser potrebbe subire dei rallentamenti nelle operazioni più banali, come l'inserimento di una keyword per una ricerca. Questo approccio sicuramente non è a dabile nè e ciente, ma potrebbe essere una valida scelta in caso di mancanza di alternative, se non altro per la sua compatibilità e possibilità di controllo anche nei particolari come il ritardo massimo di aggiornamento.
2.5.4 Comet
Comet è un modello di sviluppo di applicazioni web che richiedono un aggior-namento abbastanza frequente di una pagina senza che questa venga ricaricata. Sostanzialmente questo modello prevede una chiamata ad un server, su ciente-mente lunga da permettere al server di inviare delle noti che all'accadere di un
2.5 Tecnologie per l'interazione in tempo reale 29
Loop
Client Server
checkData()
Data
Figura 2.3: Schema di funzionamento dell'Ajax Polling
determinato evento. È come se ci fosse un canale di comunicazione aperto tra server e client, ma questo canale è rappresentato da una chiamata da parte del client al server con un tempo di latenza molto lungo, durante il quale il server continua ad inviare dati al client.
Si distinguono due tecniche fondamentali in questo modello:
Hidden Frame: Come dice la traduzione Frame nascosto, questa tecnica pre-vede che all'interno della pagina vi sia un frame, una nestra in cui poter aprire un altra pagina, ma nascosto alla vista dell'utente. Di fatto questo frame è una chiamata al server, che quando la riceve non la fa terminare, ma entra in un ciclo che ad intervalli impostati riesegue le operazioni al-l'interno della pagina. In questo modo ogni volta che un certo evento sia accaduto, il server invia al frame un determinato comando in Javascript, sostanzialmente un pezzo di codice già scritto per essere eseguito, che viene incollato direttamente nel frame all'interno della pagina. Javascript è un linguaggio interpretato, perciò le operazioni vengono eseguite non appena ricevute, e nell'ordine di ricezione. In questo modo si genera un canale di comunicazione attivo in cui è il server ad inviare messaggi al client. Vi sono ovviamente degli aspetti positivi in questo approccio. Sicuramente la compatibilità con un qualsiasi sistema e browser, ma anche il ridotto carico computazionale previsto per il client, e la rete che rimane prevalentemente libera. Molti però sono anche gli svantaggi: la tecnica manca di un metodo a dabile per la gestione degli errori, e non c'è la possibilità di veri care lo stato della richiesta da parte di chi la processa. Inoltre nel momento in cui il server esegue il ciclo, tale tecnica prevede un intervallo di tempo in cui il server non fa nulla, che per la maggior parte dei linguaggi server-side, questo si traduce con una sospensione della sessione di lavoro, e quindi una sospensione nel processare tutte le altre chiamate in arrivo da parte di altri utenti: sarebbe come introdurre un ritardo sulla rete.
Ajax Long Polling: Sostanzialmente questa tecnica si basa su quella vista pri-ma, l'Ajax Polling, ma cerca di risolvere il problema dell'intenso tra co sulla rete. Queso approccio prevede infatti che vi siano delle chiamate pe-riodiche da parte del client, ma questa volta il server, se non vi sono dati da restituire, non termina la computazione della richiesta, ma entra in un ciclo e, a intervalli di tempo regolabili, controlla se vi sono dei dati da tra-smettere, nel caso ve ne siano, restituisce la pagina richiesta con su i dati e termina la computazione della richiesta. Inoltre questa tecnica prevede che il numero di iterazioni da parte del server sia nito e non troppo elevato, per non incappare nel time-out che limita l'attesa per una richiesta web. In questo modo si riduce notevolmente il tra co sulla rete, e si distribuisce il carico computazionale tra server e client. Tuttavia, come nella tecnica pre-cedente, quando si vuole mettere in pausa il server, per alcuni linguaggi di programmazione server-side, si mette in pausa l'intera esecuzione della sessione, generando ritardi non tollerabili in una applicazione che prevede una collaborazione in tempo reale.
2.5.5 HTML5 socket
I websocket, o HTML5 socket, sono come dice il nome dei socket gestiti dal browser che permettono la creazione e gestione di un canale di comunicazione che permette lo scambio di messaggi da e verso il server. Naturalmente perché la creazione di questo canale sia possibile, i websocket devono essere supportati sia dal client che dal server. Di fatto viene creato un canale di comunicazione con tanto di messaggio di benvenuto da parte del client e del server, e in questo modo vi è la possibilità di uno scambio di messaggi tra le due parti senza che il client eettui alcuna chiamata verso il server. In questo modo si può implementare un sistema event-driven che al veri carsi di un evento lo noti ca ai client in ascolto. Si tiene così sotto controllo il tra co generato sulla rete, senza dover sospendere le sessioni del server. Unico aspetto negativo di questo approccio è la compatibilità, infatti è supportato solo da alcuni dei browser di ultima generazione.
Capitolo 3
Ambiente integrato per la creazione
di componenti e di mashup
3.1 PEUDOM
PEUDOM, Platform for End-User Development Of Mashup, è un progetto svilup-pato all'interno del Politecnico di Milano nel 2010. Si tratta di una piattaforma che si pre gge l'obiettivo di permettere direttamente agli utenti nali di crearsi il proprio mashup. Infatti come dice la traduzione del nome stesso, Piattaforma per lo sviluppo di mashup da parte degli utenti nali, ha lo scopo di mettere a disposizione degli utenti, che poi saranno gli utilizzatori del mashup, una serie di strumenti che permettano di creare la loro composizione in maniera agile e semplice. I punti di forza di questa piattaforma sono naturalmente tutti orientati alla semplicità di utilizzo da parte degli utenti, ma non per questo non presenta alcuna novità da punto di vista delle funzionalità.
PEUDOM è una piattaforma web, eseguibile direttamente dal browser, total-mente client-side, perciò senza bisogno di eseguire interrogazioni verso il server. Una volta caricata la piattaforma, le uniche interrogazioni verso l'esterno sono solo verso i servizi web inclusi nella composizione. Per questo motivo può essere considerata una piattaforma leggera, perché non genera un eccessivo volume di chiamate verso il server, una volta che è in esecuzione. Il vero punto di forza della piattaforma però è il fatto di implementare un approccio totalmente visuale, che permette all'utente di operare sulla piattaforma attraverso l'interazione con gli oggetti dell'interfaccia gra ca, come se muovesse sicamente i componenti sullo spazio di lavoro. Infatti la stessa aggiunta di un componente alla composizione avviene attraverso il trascinamento dell'icona del componente all'interno dello spazio di lavoro. Questo permette all'utente di comprendere intuitivamente la azioni che deve compiere per perseguire un determinato obiettivo. Infatti, attra-verso questo paradigma sono stati nascosti all'utente tutti i meccanismi, molto complessi, che stanno alla base del funzionamento della piattaforma, mostrando
all'utilizzatore un'ambiente semplice da usare e facile da capire, che si evolve esattamente come l'utente si aspetta che evolva. Ulteriore aspetto a favore del-l'usabilità da parte degli utenti meno esperti è l'implementazione del paradigma WYSIWYG (Ciò che vedi è ciò che ottieni), secondo il quale ciò che si vede in fase di creazione di un prodotto, è esattamente ciò che si ottiene a prodotto ni-to. Cioè non ci saranno processi di compilazione/elaborazione che modi chino il prodotto nale.
Figura 3.1: Schermata di PEUDOM
Con questa piattaforma l'utente può quindi in maniera molto facile creare una propria composizione, attraverso dei componenti che interrogano dei servizi, esterni alla piattaforma, e mostrano i risultati di tali interrogazioni. Ma l'utente oltre ad aggiungere e rimuovere componenti dalla composizione ha la possibilità di creare dei binding (collegamenti), tra un componente e l'altro, a nché, un determinato evento sollevato da un componente provochi una determinata azione su quelli ad esso collegati. Ad esempio, se un componente mappa e uno che mostra i luoghi dei concerti di un cantante, sono collegati tra loro, è possibile, selezionando un concerto, mostrare sulla mappa il luogo dell'evento, senza che l'utente esegua una vera e propria ricerca.
Unica vera problematica di questa piattaforma è la complessità con cui un nuovo servizio può essere aggiunto alla piattaforma. Infatti per poter estendere l'oerta di componenti aggiungibili alla composizione è necessaria la creazione di complessi wrapper che interroghino i servizi web e ne visualizzino i risultati;
3.2 ViTe 33 insomma un operazione che un utente non esperto non potrebbe certo portare a termine con successo. Perciò anche se la piattaforma vanta una usabilità molto alta verso l'utente nale manca di un sistema per l'estensione dei componenti disponibili, e visto che di servizi web interrogabili ce ne sono molti e dierenti, questa limitazione non è banale.
3.2 ViTe
È una piattaforma creata nel 2012, con lo scopo di creare dei mashup a partire da chiamate a dei servizi web esterni alla piattaforma. Il framework in questione, basato sulla precedente esperienza di MobiMash (piattaforma per la creazione di mobile mashup), abbandona le limitazioni imposte dall'usabilità dei dispositivi mobili, creando un'applicazione desktop molto e cace. La piattaforma è sostan-zialmente divisa in due grossi moduli: il Visual Template Editor(Figura 3.2), il modulo che presenta aspetti di maggior interesse, e l'Execution Engine. All'in-terno del primo modulo è possibile creare, o editare, dei mashup. Come dice il nome stesso, Visual Template Editor, la creazione di questi mashup avviene tra-mite dei visual template selezionati dall'utente in fase di creazione. L'utilizzo di visual template è estremamente comodo e performante, perché non sarà l'utente a dire come visualizzare i dati, magari uno per uno, ma dovrà solo selezionare il modello di visualizzazione dei dati, mappa o lista per esempio. Questo approc-cio, inoltre, permette di creare ed estendere altri visual template, aggiungendoli a quelli già esistenti, estendendo la scelta dell'utente riguardo la visualizzazione dei dati. Altro aspetto molto interessante è il meccanismo con cui viene popolato il template visuale. Infatti, i dati non vengono selezionati in maniera automatica e inseriti all'interno del template, ma vengono mostrati, in una sorta di albero che rappresenta la risposta all'interrogazione al servizio web selezionato dall'utente. Le foglie di questo albero non sono altro che i dati restituiti dalla chiamata al servizio. L'utente, con un intuitiva interazione drag-and-drop, ha la possibilità di trascinare i dati che più gli interessano all'interno del visual template, vedendo così formarsi il proprio mashup (Figura 3.3) Inoltre la possibilità di combinare tra loro i risultati di più servizi, che magari restituiscono risultati eterogenei tra loro, ore una svariata possibilità di personalizzazione da parte dell'utente. Altro aspetto interessante, è il fatto che nella composizione dei template, il trascinamen-to di un singolo datrascinamen-to attiva il popolamentrascinamen-to del template con i dati corrispondenti di tutte le altre istanze nel dataset, risparmiando all'utente di trascinare i dettagli di tutte le istanze.
L'altro modulo presenta comunque aspetti molto interessanti, principalmente riguardanti processi di elaborazione e ra namento dei dati contenuti nel mashup. Infatti l'Execution Evironment non si limita solo a mostrare i risultati secondo il visual template indicato, ma si occupa anche di non mostrare due risultati uguali o molto simili tra loro, ma di accorparli in base a logiche di similarità dei dati.
Figura 3.2: Schermata di ViTe
3.3 Complementazione di PEUDOM e ViTe 35 Questa elaborazione è molto utile, perché non è poi così raro trovare dei doppioni nel dataset mostrato, considerando il fatto che è possibile combinare tra loro i risultati di chiamate a diversi servizi esterni.
3.3 Complementazione di PEUDOM e ViTe
Il primo passo nella realizzazione della nuova piattaforma è l'integrazione tra Vi-Te e la precedente versione di PEUDOM. Quali sono i motivi che hanno portato alla decisione di integrare i due ambienti? Per rispondere a questa domanda, è necessario prendere in considerazione i punti di forza, così come i punti deboli, sia dell'uno che dell'altro. Un grande vantaggio è la predisposizione alla espansio-ne e alla personalizzazioespansio-ne delle due piattaforme: entrambe by-design realizzate seguendo un preciso pattern a template, che permette e prevede la possibilità di introdurre, sotto forma di plugin, eventuali nuove estensioni. Inoltre queste due realtà conservano un basso grado di specializzazione ad-hoc nei confronti di eventuali servizi e domini speci ci del Web. Questo ha permesso in potenza, ed ancora permette, di utilizzare una piattaforma estremamente versatile che, una volta consolidate le funzionalità di interesse, può essere resa facilmente custom, al ne di aderire ad un determinato ambito di utilizzo con utenti speci ci. Come ad esempio personale aziendale che sfrutta una dashboard che mescola componenti appartenenti alla propria realtà lavorativa con servizi Web.
Certo, in questa ultima accezione è PEUDOM ad avere maggiori possibilità: solo in questo ambiente è di fatto possibile creare ed eseguire il mashup vero e proprio. Il principale limite di PEUDOM è però l'alto livello di competenza e co-noscenza richiesti qualora si desideri aggiungere un nuovo componente. Come già accennato in precedenza, ad ogni componente corrisponde uno speciale wrapper ed alcuni le di descrizione, essenziali per la buona riuscita dell'integrazione di un nuovo servizio Web. L'operazione non risulterebbe complicata ad un utente con una media preparazione nel campo della programmazione e dell'informatica, ma si ricorda che uno degli intenti principali, in accordo con le direttive accennate in precedenza circa il Web 2.0 e la partecipazione attiva degli utenti, è quello che anche un generico utente sia in media in grado di portare a termine l'operazio-ne di aggiunta di un nuovo compol'operazio-nente, da aggiungersi a quelli resi di default disponibili all'interno della piattaforma. Questo lavoro, a dierenza della mani-polazione di un proprio mashup, non può essere guidato e mediato in maniera su cientemente e cace tramite l'interazione dell'utente con il solo layer di user interface.
Al contrario ViTe permette all'utente di creare, tramite una più intuitiva inte-razione di drag&drop, un proprio mashup, senza doversi in alcun modo preoccu-pare delle interazioni a basso livello, necessarie per ottenere il risultato desiderato. Tuttavia, per quanto le interrogazioni possano essere personalizzate, modulando servizi e parametri di ricerca, il risultante mashup è molto più vincolato rispetto
ad un ipotetico mashup prodotto in PEUDOM. Infatti banalmente, se da una parte la possibilità di creare un mashup a partire da un determinato templa-te (attualmentempla-te lista o mappa) permettempla-te di guidare l'utempla-tentempla-te nella creazione del mashup, da un dierente punto di vista, questo limita la possibilità dell'uten-te di organizzare la visualizzazione secondo dierenti paradigmi, così come non permette di combinare in maniera non prestabilita dati provenienti da sorgenti dierenti.
Va inoltre speci cato che, dal punto di vista della interazione dell'utente, anche ViTe/MobiMash presenta alcuni limiti, che rendono meno immediata la fruizione delle operazioni disponibili. La mancanza di un livello di ltro della ricerca, ad esempio, rende più di cile la localizzazione degli elementi necessari all'utente per creare il proprio componente, i quali rischiano di confondersi insieme ad elementi meno signi cativi o super ui (ID, numeri di serie, ecc...). Anche in questo caso la minore intuitività è motivata dalla volontà di mantenere versatile la piattaforma: simili migliorie, che prevedono la ri nitura dei risultati in base ad un dominio di applicazione, sono comunque possibili e di facile applicazione, seppure esulino dalla presente trattazione.
Dopo aver valutato potenzialità e criticità dei progetti esistenti, si è scelto di procedere verso l'integrazione dei due ambienti: nello speci co si è deciso di utilizzare PEUDOM come ambiente principale, con la possibilità di accedere a un editor di componenti, il quale eredita parte delle sue funzionalità da ViTe. Il ne è quello di sfruttare la versatile dashboard di PEUDOM, garantendo co-munque all'utente di poter creare nuovi componenti grazie all'ambiente di design disponibile in ViTe/MobiMash. Si è in questo modo tentato di esaltare i punti di forza di entrambe le precedenti realtà, capaci, complementandosi, di ovviare a parte dei rispettivi punti critici.
La sola compresenza delle due realtà non è però su ciente: è necessario che PEUDOM e ViTe siano integrati, ovvero che sia possibile utilizzare i componen-ti/mashup realizzati nell'editor all'interno della dashboard. Ripensando opportu-namente il motore di esecuzione di ViTe, è stato possibile integrare l'esecuzione dei componenti creati dall'utente all'interno della struttura a wrapper presen-te per i componenti di PEUDOM. La dierenza rispetto ai canonici wrapper di PEUDOM è quella di avere infranto la rigida regola di un wrapper per ogni com-ponente. Infatti, sfruttando la creazione per template di ViTe, è possibile creare un solo wrapper, capace di gestire la visualizzazione di N componenti dello stesso tipo. Ampliando la visione del discorso, questo imporrebbe soltanto al creatore di un nuovo template di composizione la necessità di fornire il rispettivo wrap-per. Allo stesso tempo questa singola azione permetterebbe a qualsiasi utente di comporre un numero non limitato di componenti su un numero non precisato di servizi, senza che l'utente debba preoccuparsi in alcun modo dell'integrazione del proprio lavoro all'interno della dashboard. In base a questo ragionamento la at-tuale implementazione supporta l'utilizzo di componenti, limitatamente a quelli generati in ViTe, conformi al template lista e al template mappa. Con un simile
3.4 Note sui riferimenti ai diversi ambienti integrati 37 grado di integrazione, l'utente ha la possibilità di muoversi liberamente tra i due ambienti con la possibilità di utilizzare in maniera indierenziata un qualsiasi tipo di componente, sia esso uno prede nito di PEUDOM oppure uno generato espressamente tramite l'ambiente di design.
Si è consci di quanto questo in eetti costituisca solo uno dei possibili passi da compiere, nel più ampio scenario di integrazione e complementazione, possibile per le due realtà assimilate nella nuova piattaforma, ma si ricorda che l'integra-zione non costituisce il punto focale di questo progetto di tesi. Allo stesso tempo, si è scelto di dedicare parte dei propri sforzi a un simile obiettivo nell'idea di poter conseguire un prodotto nale più completo, preparando allo stesso tempo una utile quanto solida base, sulla quale poter iniziare eettivamente a svilup-pare le dinamiche di condivisione e di collaborazione, punto nevralgico di questo elaborato.
3.4 Note sui riferimenti ai diversi ambienti
inte-grati
Sebbene no ad ora si sia scelto di mantenere i riferimenti ai precedenti progetti di ViTe e PEUDOM, al ne di meglio inquadrare l'iniziale framework dal quale ha successivamente preso forma la nuova applicazione, d'ora in poi ogni riferi-mento è da contestualizzarsi all'interno della nuova piattaforma. Il nome scelto per l'intero progetto rimane PEUDOM (Platform for End User Development of Mashups), una scelta di continuità con il passato, per un nuovo progetto il cui ne ultimo rimane inalterato. Le funzionalità speci che dei vecchi ambienti so-pra menzionati sono rintracciabili nei nuovi Component Editor, che conserva le caratteristiche peculiari di ViTe, e nella nuova Mashup Dashboard, le cui funzio-nalità base coincidono con quelle presenti nella precedente implementazione di PEUDOM.
3.5 Incapsulamento e sviluppo delle nuove
funzio-nalità
La decisione di integrare parti sviluppate in precedenza ha necessariamente in- uenzato lo sviluppo delle nuove componenti della piattaforma. Infatti, se da un lato la volontà è quella che l'integrazione non vada ad interferire con il buon funzionamento dei vecchi applicativi, d'altra parte è necessario riorganizzare tali soggetti così da potercisi interfacciare e renderli capaci di abbracciare le nuove funzionalità previste. Si è quindi deciso di sviluppare ogni nuova funzionalità, incapsulata in una propria struttura autosu ciente, che si inserisca in maniera ortogonale agli altri elementi presenti, ma che sia in grado di funzionare in modo
