La nuova architettura

Come è stato illustrato nella parte precedente la piattaforma oggetto di questa trattazione è composta da due ambienti già esistenti e funzionanti. Di conse- guenza l'architettura nale e le scelte fatte sono state molto inuenzate dalle implementazioni già esistenti delle due applicazioni integrate.

Peudom, che poi è diventato la Mashup Dashboard, è nato come piattafor- ma per la creazione di web mashup, con una diretta fruizione, senza avere la necessità di salvare questi mashup e di riaprirli in un secondo momento. Di con- seguenza non presenta delle funzioni di autenticazione dell'utente, né di controllo della sessione di lavoro. Non necessita di un database perchè non ha informazioni da memorizzare ed essendo ricco di funzionalità che richiedono l'aggiornamento della pagina in tempo reale, senza ricaricarla, presenta una struttura totalmente client-side. È infatti implementato in Javascript. ViTe, che poi è diventato il Component Editor della nuova piattaforma, è stato implementato con l'idea di creare dei mashup eseguiti in una pagina singola, che ricavassero le informazio- ni direttamente dai servizi web che un utente aveva la possibilità si registrare all'interno della piattaforma, e mostrassero i risultati ottenuti secondo uno dei template visuali scelto dall'utente in fase di denizione del mashup. Perciò pre- senta uno strato di autenticazione e un sistema per il controllo della sessione. Inoltre è stato previsto che un utente possa aprire il proprio lavoro e modicarlo,

3.8 Architettura della nuova applicazione 45 oltre che salvarlo, perciò fa uso anche di un database e di una parte server-side che ne consente l'accesso. L'applicazione quindi presenta una parte client, scritta in Javascript, e una parte server-side scritta in JAVA con pagine in JSP, che si occupava di eseguire le azioni sul database e le interrogazioni ai servizi esterni per recuperare i dati da mostrare.

Mashup Dashboard Component Editor Composition Manager Service Query Module Service Manager Visual Mapping

Manager

Service Query Module Component Execution Engine

Schema Interpreter UI Controller Data Manager Client Server Web Services and APIs Repository Server Registered Service Repository Component Schema Repository Composition Schema Repository Service

descriptor Component _schema

Visual Templates Composition schema Component schema Mashup Engine Event Handler

Figura 3.7: Schema architetturale degli ambienti integrati in PEUDOM L'architettura derivata dall'integrazione dei due ambienti è una struttura sicu- ramente più estesa e complessa, ma che conserva quella precedente. Infatti visto che entrambe le piattaforme sono perfettamente funzionanti si è scelto di non modicare eccessivamente l'architettura di entrambe, così da non dover rinuncia- re o trascurare alcune delle funzionalità meno evidenti, ma non per questo meno

importanti, presenti in entrambe. Per questo motivo è stata mantenuta l'archi- tettura del Component Editor ed è stata estesa quella della Mashup Dashboard cosi da permettere l'utilizzo del database per il salvataggio dei dati. Questo è stato reso possibile grazie ad uno strato server in PHP che comunica con la parte client in Javascript attraverso delle chiamate AJAX. Queste particolari chiamate, eseguibili dal client sono come le richieste che un browser fa verso un server per ottenere una pagina da mostrare, solo che la pagina restituita non viene mostrata, e può quindi essere letta e interpretata dalla funzione che ha eettuato la chiama- ta cosi da estrarne le informazioni necessarie. Visto che sono l'equivalente delle chiamate per ottenere le pagine da mostrare, se queste chiamate vengono fatte verso delle pagina PHP allora il codice che altrimenti sarebbe stato eseguito solo al ricaricamento della pagina, viene eseguito nel momento della chiamata, senza interrompere l'attività del client. In questo modo abbiamo mantenuto il carattere client-side della precedente piattaforma PEUDOM estendendola con l'utilizzo dei database.

Naturalmente per essere integrate le due piattaforme devono presentare una struttura esterna comune che è stata realizzata in PHP. È stato scelto tale lin- guaggio perchè, oltre ad essere più famigliare agli sviluppatori, è ampiamente supportato da tutti i server, è molto leggero per quanto riguarda compilazione, deploy ed esecuzione del programma, ma soprattutto non richiede grandi poten- zialità computazionali da parte del server, come invece fa JAVA per poter far girare la JVM. Inoltre PHP permette una più diretta e completa interazione e controllo del database, oltre che la possibilità di interrogare servizi web esterni in maniera diretta, senza l'utilizzo di proxy o strutture apposite.

In questo modo l'applicazione nale presenta una parte client-side con pagi- ne HTML, script Javascript e pagine JSP; e una parte server scritta in JAVA e PHP. Un'applicazione di questo tipo presenta già un grosso problema alla sola esecuzione. Infatti è insolito mischiare più tecnologie per la gestione della parte server, e di conseguenza i server disponibili presentano supporto per applicazioni JAVA o PHP, non per entrambe. Abbiamo risolto il problema facendo eseguire l'applicazione su un server Tomcat, che ha nativamente il supporto per l'esecu- zuione di codice JAVA, estendendolo con il supporto a PHP attraverso l'aggiunta di alcune librerie per l'interpretazione e l'esecuzione di script PHP.

In questo modo abbiamo mantenuto tutte le funzionalità delle piattaforme integrate, estendendole, e abbiamo garantito il delicato equilibrio del carico ope- razionale tra client e server, senza rinunciare alla dinamicità delle pagine attraveso delle chiamate verso il server non più statiche ma dinamiche sfruttando il mecca- nismo AJAX, che permette di interrogare pagine non ancora inviate al client, cosi da fornire al browser informazioni dal server, senza dover ricaricare la pagina.

Capitolo 4

Requisiti di condivisione e

collaborazione

Dopo aver presentato lo scenario di applicazione di questa tesi ed aver illustrato quali sono le realtà implementative e le precedenti esperienze, che hanno ispira- to e guidato la presente implementazione, si desidera ora passare in rassegna i principali punti che hanno permesso di caratterizzare il lavoro descritto a livello implementativo, contenuto all'interno del prossimo capitolo.

Dopo aver inoltre descritto quali siano state le ragioni che hanno motivato il desiderio di integrare le precedenti esperienze di PEUDOM e ViTe in una nuova piattaforma, si cerca ora di organizzare il discorso suddividendo la discussione in due macro-sezioni: la prima rivolta a quello che si può denire come lato so- cial della nuova piattaforma, la seconda interessata alla svolta collaborative della stessa. In entrambi i casi, ove possibile, si ricorre ad esempi presi da realtà di successo del Web - alcune estremamente aermate e conosciute (Facebook e al- tri social media), altre meno note, ma rilevanti all'interno dell'ambito di questa trattazione - sia per meglio contestualizzare, esemplicandole, le scelte fatte, sia per supportare queste ultime. Inne queste due prospettive sono arontate nel seguente modo: la parte relativa alle dinamiche sociali all'interno dell'applica- tivo si concentra maggiormente sulla descrizione dei requisiti e sulle successive soluzioni, attuate seguendo un minor grado di formalizzazione del problema in forza dei sopra citati standard de-facto, imposti dai principali social media; al contrario, per quanto riguarda il lato collaborativo della piattaforma, vero obiet- tivo del lavoro conseguito, l'analisi di requisiti e relative soluzioni è preceduta da una riessione di carattere più prettamente teorico, in cui si cerca di classicare e riettere sui modi della collaborazione applicati al mondo dei mashup.

A questa prima fase segue poi l'enunciazione di quelle che possono essere considerate come le principali sde, arontate nello sviluppo delle soluzioni ela- borate in fase di analisi. Seppur consci di alcune criticità presenti nell'approccio seguito, in questo capitolo si desidera seguire un approccio positivo, che mira a creare le basi concettuali, sulle quali si sviluppa il successivo capitolo dedicato

t Integrazione Lato Social Lato Collaborative Lato

Social

Integrazione

Lato Collaborative

Figura 4.1: Visione complementare e visione evolutiva. alla implementazione tecnica.

In ultima istanza, lo scopo di questo capitolo non è solo quello di mettere in luce i principali aspetti della nuova piattaforma, in base ad una divisione funzio- nale (interazione social e interazione collaborative) della trattazione, ma anche quello di dimostrare come come ogni fase, in visione della realizzazione di queste due prospettive, si sia rivelata un prerequisito necessario per il conseguimento della fase successiva. Per questo motivo, nonostante per semplicità la trattazione presenti ogni parte come ambito concettuale a sé stante, snodatosi attraverso una precisa successione temporale, preme sottolineare come integrazione, lato sociale e lato collaborativo debbano poi essere considerate come un'unica dimensione (Figura 4.1). Infatti solo in forza delle mutue interazioni tra questi ambiti è possibile ricostruire una corretta e integra visione di PEUDOM.

4.1 Denizioni Preliminari

Prima di procedere con la trattazione si desidera esplicitare il senso associato ai tre vocaboli che più ricorrono in questi capitoli. La loro denizione è pensata in modo da poter descrivere in maniera funzionale gli oggetti con i quali l'utente interagisce nella piattaforma.

Servizio: risorsa essenziale per la realizzazione di un componente. A questo elemento non è associata una specica rappresentazione all'interno della UI. Un servizio è descritto da una o più riferimenti ad API, corredati da un determinato numero di parametri. Un servizio è un oggetto che, grazie alla tecnologia REST, è in grado di interrogare un preciso service provider del Web e recuperarne il risultato.

Componente: risorsa essenziale per la realizzazione di una composizione. Que- sto presenta una duplice natura, successivamente unicata nella nuova piat- taforma. Il primo tipo di componente è quello concepito nel vecchio PEU-

4.1 Denizioni Preliminari 49 DOM, inteso come scatola funzionale in grado di gestire in maniera comple- ta e predenita tutte le azioni: a partire dall'interrogazione del servizio, no alla presentazione dei risultati. In questo caso ancora non si può parlare di mashup, bensì la struttura di un simile componente ricorda più quella di un wrapper. Il secondo tipo è invece quello derivato da ViTe, caratterizzato da un approccio totalmente modulare, in grado di sfruttare i sopra menzionati servizi per recuperare, unire e fondere i risultati in un apposito visual tem- plate, scelto di volta in volta dall'utente. In questo caso, qualora si scelga di sfruttare congiuntamente lo stesso modello di visualizzazione per risultati provenienti da interrogazioni dierenti, di fatto si è già in presenza di un mashup. In termini di UI, i componenti sono quegli oggetti, presenti nella palette, che possono essere aggiunti alla dashboard di PEUDOM per creare una composizione.

Composizione: mashup componibile grazie alla piattaforma. Evoluzione della composizione presente nel vecchio PEUDOM e principale oggetto di studio, al quale ci si è dedicati nella specica e nell'applicazione di paradigmi di condivisione e di collaborazione. La composizione è l'entità maggiormente dinamica e interattiva di questo lavoro.

Si propongono inoltre le denizioni di Spazio Informativo Personale e Condiviso, altri due termini che ricorreranno durante la trattazione:

Spazio Informativo Personale - PIS: documento interattivo, che indica una generica istanza di uno schema di composizione lungo tre precise dimensio- ni. La prima riguarda il modello di composizione del PIS, il quale descrive l'organizzazione dei servizi che lo compongono. La seconda riguarda il tem- plate visuale, che descrive il livello di presentazione. L'ultima dimensione è il modello dei contenuti, il quale descrive il contenuto vero e proprio pre- sentato in ogni istante dai diversi servizi presenti. Nel contesto specico di questo elaborato si utilizzerà tale termine per riferirsi ad un generico spazio interattivo non condiviso, ovvero ad una composizione personale.

Spazio Informativo Condiviso - CIS: documento interattivo che si propone come evoluzione del PIS, al quale si aggiunge una nuova dimensione, carat- terizzata da un modello che permetta di descrivere il supporto collaborativo multi-utente. Anche in questo caso, quando non ci si riferirà in maniera generica ad un CIS, il riferimento sarà quello di una composizione oppor- tunamente condivisa da un utente, oggetto che si congura come soggetto principale della collaborazione all'interno di PEUDOM.

4.2 Lato Social: creazione di una community e