una ipotetica collaborazione anonima, dove con anonima si intende più che altro una collaborazione tra soggetti non caratterizzati, dato che in linea di massima è sempre possibile se non altro associare ogni utente alla macchina da cui tale utente stia operando (con le dovute eccezioni), non possa essere fruttuosa e produttiva. In questo caso si dovrebbero fronteggiare seri problemi di gestione delle azioni e dei contenuti. Un tale scenario sarebbe per lo meno singolare, se non poco sensato, soprattutto in forza delle numerose realtà di successo che sin dalla nascita del Web hanno sfruttato una simile soluzione. Questo ovviamente non solo permette di sempli care agli sviluppatori la gestione dell'utente nella sua interazione con la piattaforma, ma è anche un meccanismo che permette all'utente di salvaguardare da un ipotetico uso improprio i propri contenuti. Un semplice login con nome utente e password è soluzione su ciente per il raggiungimento di entrambi i requisiti.
Nell'ambito speci co dello sviluppo del prototipo, al quale questa trattazione si riferisce, non si sono applicate sistematicamente misure di sicurezza speci - che, ancora una volta tali interventi non sarebbero rilevanti ai ni degli obiettivi di sviluppo. Ciò nonostante, sebbene non si utilizzi, ad esempio, il protocollo HTTPS, ed esistano alcune vulnerabilità note, si è deciso di aderire ad alcune buone norme per un programmazione sicura. Ne sono un esempio la scelta co- stante di pre-processare gli input inseriti dall'utente e altre contromisure atte a limitare il fenomeno del XSS e dell'SQL-Injection, giusto per nominare due po- tenziali attacchi tra i più noti. Sempre inseguendo il compromesso tra facilità di gestione per gli sviluppatori, comodità di utilizzo degli utenti e sicurezza dei dati, si è scelto di integrare uno speci co controllo di sessione. Questo a sua volta da una parte sempli ca l'esperienza degli utenti e degli sviluppatori, mentre i primi potranno evitare di ripetere il login nel caso in cui già esista una sessione attiva e i secondi potranno sfruttare la sessione per recuperare i dati necessari relativi all'utente, d'altra parte assicura una maggiore sicurezza: anche in caso di mancato logout, in assenza di nuove attività dell'utente e allo scadere di un opportuno tempo di timeout, una successiva interazione con la pagina forzerebbe l'uscita dall'applicazione.
3.7 L'integrazione dei due ambienti
Prima di parlare di come le due piattaforme siano state integrate è necessario spendere qualche parola sull'architettura e il funzionamento di PEUDOM e di ViTe. La spiegazione di entrambe le piattaforme riguarderà, soltanto gli aspetti essenziali al ne di facilitare la comprensione delle s de implementative arontate e le scelte che ne sono derivate.
Il nostro obiettivo è quello di sostituire l'Execution Engine (EE) (Figura 3.4), integrando la visualizzazione del mashup appena creato nel Design Environment
Figura 3.4: Schema con la struttura funzionale di ViTe
(DE) all'interno di PEUDOM. Detto ciò è su ciente analizzare la struttura del- l'output del DE, per comprendere come sia possibile integrare il prodotto di una piattaforma all'interno dell'altra.
Il risultato dell'utilizzo del DE è un le di descrizione XML, che contiene le in- formazioni riguardanti il template visuale utilizzato per comporre i dati risultanti delle interrogazioni, i servizi interrogati e le informazioni che si è deciso di mostra- re. Ovviamente per ogni template è possibile generare innumerevoli descrittori XML ognuno diverso dagli altri per il servizio interrogato o semplicemente per le informazioni mostrate.
Per quanto riguarda PEUDOM l'analisi dev'essere per forza più approfondita. All'interno della piattaforma ogni servizio fornito, che si traduce in un componen- te aggiungibile al mashup, è descritto fondamentalmente da tre le, uno che ne descrive la visualizzazione (EJS), uno che descriva le possibili azioni che un utente può eseguire attraverso quel componente (UISDL) e un wrapper che implementa le funzioni per le operazioni descritte nell'UISDL (Figura 3.6). Per esempio, il componente googleMaps è composto da tre le: quello che descrive la struttura HTML all'interno della quale vengono mostrati i contenuti riguardanti il com- ponente, in questo caso un semplice <div> che contiene la mappa di Google, un descrittore che indica che sono possibili due tipi di operazioni sul componente: la ricerca attraverso un keyword e la ricerca attraverso delle coordinate, e un
3.7 L'integrazione dei due ambienti 41 wrapper che descrive le varie interrogazioni alle API di Google, nel caso in cui si eettui uno dei due tipi di ricerca previsti.
Perciò per rendere possibile che il descrittore XML, prodotto dall'esecuzione di ViTe, possa essere interpretato da PEUDOM e una volta disegnato, inserito all'interno di un mashup, basta creare un opportuna tripla wrapper - UISDL - EJS (che alla ne si con gura come un componente per la piattaforma) che prenda in ingresso il descrittore, ne elabori le informazione e ne visualizzi i risultati. È però su ciente creare un unico componente per poter gestire tutti i template visuali di ViTe? E tutti i possibili le di descrizione XML?
Vista la radicale dierenza di visualizzazione tra i vari template visuali utli- lizzati da ViTe, si sono rivelati necessari le dierenti per la descrizione della visualizzazione del componente. Analogamente, essendo molto dierenti tra loro le azioni necessarie per poter recuperare i contenuti da visualizzare, non si pos- sono implementare tutte queste azioni in un unico wrapper. È perciò necessario implementare un wrapper di PEUDOM per ogni visual template presente in Vi- Te, così da permettere che una volta ricevuto in ingresso il le XML che descriva il compoente appena creato all'interno di ViTe possa, il componente appropriato, interrogare i servizi e visualizzarne i risultati.
Si tratta però di componenti dierenti da quelli standard, che non solo sono in grado di eseguire delle operazioni come i primi, ma che devono anche poter leggere e interpretare i le di descrizione XML, estrapolarne i dati, eettuare le interrogazioni necessarie verso i servizi internet indicati, estrarre le informazioni dai risultati restituiti per poi visualizzarle. (Figura 3.5) Per comprendere meglio la dierenza facciamo un semplice esempio tra due componenti. Prendiamo il componente dedicato all'interrogazione del servizio LastFM, che dato un nome utente come keyword, restituisce l'elenco dei concerti a cui ha partecipato tale utente, e un componente creato per elaborare i le XML creati all'interno di ViTe con il template Mappa. Il primo all'interno avrà solo una chiamata al servizio lastFM e una struttura in grado di visualizzare i risultati restituiti dal servizio. Il secondo componente invece deve avere al suo interno un modulo che ricevuto il le XML lo legga e ne generi una struttura ad albero da cui si riescano ad estrapolare in modo agile le informazioni, un modulo che esegua le interrogazioni ai servizi esterni, che possono essere dei più svariati con il passaggio di un variabile numero e tipo di parametri. Inoltre si deve disporre di un modulo che, ricevuto in ingresso la risposta alle interrogazioni verso tali servizi, generi, attraverso la valutazione di percorsi xPath indicati nel le XML in ingresso al componente, il set di valori che vanno mostrati nella visualizzazione (nel caso preso come esempio: delle coppie di coordinate latitudine e longitudine, o dei nomi di località da ricecare sulla mappa.)
In questo modo, è possibile creare una composizione all'interno di ViTe, sfrut- tando un determinato template visuale, e una volta salvata, tale composizione è possibile ritrovarla all'interno di PEUDOM come componente ed è possibile com- binarla all'interno di un mashup assieme ad altri componenti creati all'interno di
XML per template 1 Wrapper Template1 chiamata REST Wrapper chiamata REST Visualizzazione ... Wrapper Template N XML per template N ... Internet
Figura 3.5: Schema con i due di tipi wrapper
3.8 Architettura della nuova applicazione 43