Proxy-based infrastructure for LBS tailoring

Relazione di:Alessandro Antonelli matr. 0000245059Bologna, 07/01/2008

Overview

LBS“Location-based services (LBS) are wireless 'mobile content' services which

are to provide location-specific information to mobile users moving from location to location”

By Wiki

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

Target

Proxy-Based Tailoring

ETEROGENEITA + PREFERENZE = TAILORING

Tailoring: adattamento dei serviziin base alle capacità e alle preferenzedel client

Uso di un proxy per adattare i contenutiinformativi forniti dai server

Case Study VMT: Virtual Museum Tour

Visita ad un museo supportata da servizimultimediali fruibili tramite un dispositivoportatile: pda, laptop, notebook

Fornitura di informazioni relative alle operevicine 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

Guideline

Ci si è preposti come linea guida quella di adottare una netta separazine tra infrastruttura di gestione e 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

Topology

PNS

Proxy2Proxy1

Registry

Server CServer BServer A

•Client

•PNS

•Proxy

•Registry

•Server

External Area

Backbone

Backbone 1/3 :::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'adattamentoruntime del servizio

Backbone 2/3 :::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

Backbone 3/3 :::Proxy::: Nodo cardine dell’architettura

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 (adapter)

Gestione delle richieste multiple (pooling)

Gestione differenziata per utenti paganti e non

I Workers informano i server sulle modalità e sui contenuti da erogare

Proxy

Pooling Module

Multicast Module

TailoringModule

Workers

FORWARDING

External Area 1/2 :::PNS:::

PNS: Proxy Naming Service Servizio di nomi contestuale Consegna ai Client l’opportuno indirizzo del Proxy

atto a servire la relativa macroarea Consente la registrazione/deregistrazione a runtime

dei Proxy Possono essere sviluppate politiche di distribuzione di

carico in caso di proxy “overlapped” Protocollo di comunicazione socket TCP

proprietario(nessuna necessità di standardizzare)

External Area 2/2 :::Client:::

Dispostivo mobile richiedente fruizione di contenuti multimediali a seconda della prossimità spaziale ad un’opera

Struttura modulare: Modulo GPS

Utilizzo delle API JSR 179 Notifiche dettate da eventi di prossimità

Modulo di Stato HardSet State:caratteristiche che rimangono immutate durante la vista al

museo Dinamyc State:racchiude al suo interno l’intero contesto di esecuzione del

client(posizione, livello di batteria, livello di banda…) In fase di deploy viene inserita una mappa del museo in modo da

poter perpetrare le corrette richieste al Proxy Comunicazione col Proxy tramite Java RMI

Workflow

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

Test

Ambiente di simulazione PC dedicato alla simulazione client ed implementazione PNS PC dedicato per implementazione Server Legacy + Wrapper PC dedicato per implementazione Registry e Proxy

Deployment Installazione di Tomcat sul server legacy, deploy del wrapper WebService, deploy dei

moduli di regole e dell'adattatore Installazione Tomcat sul Registry e deploy del componente WS per gestione Proxy e

Server Installazione sul client della mappa, del layer VMT e dell'applicazione grafica per

visualizzazione output Generazione di più client per la simulzione

Run time Simulazione di Burst di clienti Simulazione di flusso continuo di clienti

Test Tempi di risposta del proxy su notifiche di

cambiamento di posizione del client

4 16 64 128

500

550

600

650

700

750

#Client

Milli

seco

ndi

4 16 32 64 96 128

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

#Client

Milli

seco

ndi

Utenti con arrivo intervallato: leggero degrado delle prestazioni

Worst case scenario – Arrivo Burst: aumento rilevante dei tempi di attesa

Test

Tempi di registrazione al sistema di un client presso il proxy locale al piano di riferimento

Utenti con arrivo intervallato: prestazioni indipendenti dal numero di utenti

Worst case scenario – Arrivo Burst: aumento rilevante dei tempi di attesa

4 16 64 128

900

920

940

960

980

1000

1020

1040

1060

1080

1100

#Client

Milli

seco

ndi

4 16 32 64 96 128

0

5000

10000

15000

20000

25000

30000

#Client

Milli

seco

ndi

Conclusions

Tempi di risposta accettabili in condizioni di utilizzo normale, problemi invece con arrivo contemporaneo di molti client

Ottima flessibilità in ambito di: Riuso: per quanto riguarda le componanti architetturali e l’estendibilità Operativo: grazie alla gestione modulare del tailoring e

dell’adattamento Dominio applicativo: il GPS lo rende utilizzabile anche negli ambienti

estesi ed il WiMax fornisce la copertura di comunicazione (zoo, parchi, città d'arte, etc...)

Work up: 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