Proxy-Based Infrastructure for LBS Tailoring Reti di Calcolatori LS – Prof. A. Corradi Presentazione di: Roberto Amici Gruppo: Roberto Amici Alessandro Antonelli Luca Pistolesi

Location-Based Services ● Client mobili (collegamenti wireless) ● Informazioni legate alla specifica locazione da cui il client le richiede ● Cambi di posizione del client implicano modifiche al contenuto informativo fornito dal server

Proxy-Based Tailoring Crescente eterogeneità dei dispositivi client Necessità di servizi personalizzati Tailoring: adattamento dei servizi in base alle capacità e alle preferenze del client Uso di un proxy per adattare i contenuti informativi forniti dai server

Scenario Applicativo Realizzazione di un servizio di Virtual Museum Tour (visita ad un museo supportata da servizi multimediali fruibili tramite un dispositivo portatile: pda, laptop, notebook) Fornitura di informazioni relative alle opere vicine alla posizione attuale del client Adattamento del servizio in base alle capacità del dispositivo ed alle preferenze dell'utente Regole di adattamento aggiornabili runtime Suddivisione del museo in macroaree servite da un proxy ciascuna

Elementi del sistema Client PNS Proxy Registry Server

Meccanismi, non politiche Idea di base: separazione dell'infrastruttura di gestione dalla fornitura dei contenuti Possibilità di inserire ed eliminare servizi a tempo di esecuzione Sistema di tailoring modulare ed estendibile Coordinamento per la gestione dei server disponibili Necessità di informazioni per poter integrare i nuovi servizi nel sistema Tailoring statico e dinamico Statico: decisione del miglior match tra le capacità/preferenze dell'utente e le risorse disponibili per la locazione corrente Dinamico: adattamento del flusso informativo in erogazione per venire incontro a necessità dinamiche dell'utente

Server Entità che fornisce i servizi Deve esporre un'interfaccia di integrazione con il sistema VMT Potenzialmente legacy: bisognerà costruire un wrapper che fornisca la possibilità di integrazione Regole e metaregole File jar per l'adattamento runtime del servizio

Registry Entità di coordinamento e gestione dinamica Visione globale dello stato del sistema Aggiunta, rimozione e modifica di server/servizi Attivazione e disattivazione di proxy Location-awareness: mette in corrispondenza le risorse fornite dai server con l'effettiva disposizione geografica delle opere all'interno del museo Espone un WebService per la registrazione/attivazione (sia per i server che per i proxy) Comunicazione Registry-Proxy in formato proprietario tcp/ip (nessuna necessità di standardizzazione) per notificare i proxy di modifiche alle risorse o ai servizi

Proxy Elemento di base dell'infrastruttura Comunicazione con i client (Java RMI) Tailoring: regole fornite dai server (motore di inferenza: DROOLS) Adattamento ed inoltro dei servizi dai server verso i client Gestione delle richieste multiple (possibilità di sfruttare flussi condivisi: multicasting) Stima dello stato di carico della rete e conseguente gestione della banda da assegnare ai singoli client Gestione differenziata per utenti paganti e non Struttura interna pipelined: throughtput parzialmente limitato dal numero di stadi della pipeline ma gestione più semplice delle strutture dati condivise

DataFlow Client: recupero della propria posizione tramite GPS Client: interrogazione del servizio di nomi (PNS) Client: notifica di cambio posizione al server rmi del proxy Proxy: tailoring, predisposizione delle strutture per il forwarding e richiesta del servizio al server Server: fornitura del servizio

Testing Ambiente di test: Simulazione di un numero variabile di client e server di risoluzione dei nomi da un pc dedicato (notebook Intel centrino, Windows XP, scheda wireless g) Proxy e Registry su una macchina apposita (notebook Intel centrino duo, Linux, scheda ethernet 100Mbs, wireless g); Server web tomcat come container per il web service di accettazione richieste del registry Server (Legacy+Wrapper) su notebook Intel Pentium IV, Windows XP, scheda ethernet 100Mbs – Server Web tomcat come container per i web service di gestione del server Rete wireless di facoltà Simulazioni: Arrivo a flusso continuo di utenti Worst case test: arrivo contemporaneo di n utenti

Testing - Risultati Tempi di registrazione al sistema di un client presso il proxy locale al piano di riferimento Caso di utenti con arrivo intervallato: prestazioni sostanzialmente indipendenti dal numero di client. Worst case scenario: Utenti con arrivo contemporaneo: peggioramento delle prestazioni

Testing - Risultati Tempi di risposta del proxy su notifiche di cambiamento di posizione del client Caso di utenti con arrivo intervallato: leggero degrado delle prestazioni Worst case scenario – Arrivo contemporaneo: aumento rilevante dei tempi di attesa

Conclusioni Tempi di risposta accettabili in condizioni di utilizzo normale, problemi invece con arrivo contemporaneo di molti client Non testata la funzionalità di raggruppamento dei client in multicast, migliora le prestazioni in caso di arrivi contemporanei Ottima flessibilità per quanto riguarda il riuso e le possibilità operative fornite dall'infrastruttura, grazie alla gestione modulare del modulo di tailoring e adattamento Estensioni Availability e fault tolerance non prese in considerazione, ma aspetti imprescindibili di un progetto completo Layer di presentazione: l'implementazione attuale è fornita solo di un semplice sistema per il testing