Proxy-based
infrastructure for
LBS tailoring
Relazione di:
Alessandro Antonelli
matr. 0000245059
Bologna, 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 servizi
in base alle capacità e alle preferenze
del client
Uso di un proxy per adattare i contenuti
informativi forniti dai server
Case Study

VMT: 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
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
•Client
•PNS
External Area
PNS
•Proxy
•Registry
Backbone
Proxy1
Proxy2
Registry
•Server
Server A
Server B
Server C
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'adattamento
runtime 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

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:::
Proxy
Tailoring
Module
Pooling Module
Multicast Module
Workers
F
O
R
W
A
R
D
I
N
G
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


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


:::Client:::
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




Deployment





PC dedicato alla simulazione client ed implementazione PNS
PC dedicato per implementazione Server Legacy + Wrapper
PC dedicato per implementazione Registry e Proxy
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
750
Millisecondi
Utenti con arrivo
intervallato: leggero
degrado delle prestazioni
700
650
600
550
500
4
20000
16
128
Worst case scenario –
Arrivo Burst: aumento
rilevante dei tempi di
attesa
16000
14000
Millisecondi
64
#Client
18000
12000
10000
8000
6000
4000
2000
0
4
16
32
#Client
64
96
128
Test
Tempi di registrazione al sistema di un client
presso il proxy locale al piano di riferimento

1100
1080
1040
Millisecondi
Utenti con arrivo
intervallato: prestazioni
indipendenti dal numero
di utenti
1060
1020
1000
980
960
940
920
900
4
16
64
128
#Client
30000
Worst case scenario –
Arrivo Burst: aumento
rilevante dei tempi di
attesa
25000
Millisecondi
20000
15000
10000
5000
0
4
16
32
#Client
64
96
128
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