Corso di Reti di Calcolatori LS Prof. A. Corradi A.A. 2005/2006 Proxy-based infrastructure for LBS tailoring Presentazione di: Marco Mantovani – matr. 0000228726 Referente progetto: Carlo Giannelli Agenda • • • • • • • • • • Scenario. Obiettivo. Architettura. Topologia della rete. Tecnologie utilizzate. Formato dei contenuti. Tailorer. Servizio di Proxy per il client. Comunicazione proxy-proxy. Conclusioni e sviluppi futuri. 2 Scenario • Crescente diffusione di dispositivi wireless. • Interesse a servizi location-based. • Problema: dispositivi eterogenei. – Vincoli di banda più o meno stringenti. – Dimensioni del display varie. • Necessità di adattare il contenuto al dispositivo (tailoring). 3 Obiettivo • Realizzare un’infrastruttura per il tailoring del contenuto di servizi LBS. • Il tailoring deve essere basato sia su caratteristiche del dispositivo sia su preferenze espresse dall’utente. • Implementare, sull’infrastruttura, il servizio VMT (Virtual Museum Tour). • L’infrastruttura sarà basata su proxy. 4 Architettura VMT Server LBS Server 2 LBS Server N PROXY Client A Client B Client C • Client: applicazione su dispositivo mobile. • Server: contiene i contenuti, catalogati secondo informazioni geografiche. 5 • Proxy: entità incaricata di eseguire il tailoring. Servizio di una richiesta • Il client contatta il proxy. • Il proxy recupera il contenuto dal server. • Il proxy esegue DNS Server il tailoring. • Il proxy risponde al client. VMT Server Risorse Tailorer PROXY Client 6 Topologia della rete Client B Macro-area 1 Proxy 2 DNS Server Proxy 1 VMT Server Client C Macro-area 2 • • • • Spazio servito suddiviso in macro-aree. Un proxy per ogni macro-area. Rete cablata tra proxy e server. Rete wireless tra clent e proxy. 7 Tecnologie utilizzate • XML e XSLT per la rappresentazione e la resa grafica dei contenuti. • Web Server (Tomcat 5.5) per il server. • Web Services (Jboss 4.0.4 CR2 + Axis 1.3) per il Proxy: – Comunicazione client-proxy. – Comunicazione proxy-proxy. • • • • Jess per la gestione delle policy di tailoring. BTProximity (su Linux) per il posizionamento. Java (JDK 1.5) come linguaggio comune. Browser web XSmiles sul client. 8 Formato dei contenuti • Esigenze: – Facile resa grafica sul client. – Capacità descrittiva del contenuto per agevolare il tailoring. • Soluzione adottata: XML! – Trasformazione in HTML sul client. – Trasformazione XSLT per il tailoring. • Scarsa efficienza nell’uso della banda rispetto ad una codifica binaria. – Problema trascurabile in una rete locale. – Possibilità di comprimere i dati. 9 Formato dei contenuti • Esempio: <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" title="prova" href="stylesheet.xslt" ?> <document xml:base="http://..../LBSserver/" stylesheet="stylesheet.xslt"> <body> <audio language="ITA" quality="1" src="…" /> … <box> <text language="ITA" length="1“>Benvenuto!</text> <text language="ENG" length="1“>…</text> <text language="ITA" length="2“>…</text> <media type="video" language="ENG" quality="3" src="…" /> <media type="img" quality="1" src="…" /> </box> … 10 Tailorer • Il tailorer è il componente che costituisce il meccanismo del tailoring. • E’ basato su un trasformatore XSLT. • I suoi parametri sono configurati dal gestore delle regole (Jess), in base a: – Caratteristiche del dispositivo. – Preferenze espresse dall’utente. – Modalità selezionata dal client. • Seleziona gli elementi giusti (in base ai parametri) da inviare al client dal documento XML originale ricevuto dal server. 11 Tailorer • Principio di funzionamento. Regole Settaggio parametri Contenuto “tailorato” Contenuto da “tailorare” 12 XSLT Tailorer Servizio proxy per il client • • • • Il client deve contattare il proxy. Il formato dei dati è XML. Scelta di utilizzare un Web Service. Vantaggi derivanti dall’impiego di un container J2EE (servizi). • L’interfaccia del servizio è la seguente: 13 Servizio proxy per il client • Diagramma delle interazioni. 14 Servizio proxy per il client • Tutte le operazioni implementano la modalità request-response: – register() e request() si aspettano un valore di ritorno. – retrieveMyState() – il clent deve essere bloccato fino al completamento del trasferimento dello stato. – Gli altri metodi potrebbero essere asincroni (one-way), ma con request-response possono ricevere eccezioni in caso di problemi. 15 Stato del client • Lo stato è composto da: – Caratteristiche del dispositivo (display, banda). – Preferenze specificate dall’utente. PROXY 1 PROXY 2 • Tali informazioni sono tutte dinamiche. STATO • Lo stato del client è mantenuto in maniera decentralizzata presso il proxy di competenza retrieveMyState dell’area in cui si trova. • Quando il client cambia macro-area, lo stato Client deve essereClient recuperato dal proxy precedente. • Dopo un certo periodo di inattività, un demone (cleaner) cancella lo stato (fatti) di un client. 16 Comunicazione proxy-proxy • Quando un client si accorge di aver cambiato macro-area contatta il nuovo proxy, invocando il metodo retrieveMyState(). • A quel punto il nuovo proxy contatta il vecchio proxy, sfruttando un altro Web Service esposto. • Tale Web Service ha la seguente interfaccia: 17 Comunicazione proxy-proxy • Diagramma delle interazioni. 18 Conclusioni e sviluppi futuri • E’ stata creata un’infrastruttura basata su proxy per il tailoring di contenuti relativi a servizi location-based. • L’infrastruttura supporta più servizi. • E’ stato implementato il servizio VMT. • Sono stati adottati accorgimenti per ottenere un’infrastruttura il più possibile robusta. • Non sono stati presi in considerazione aspetti di availability. – Possibile fusione con il progetto parallelo. 19 Conclusioni e sviluppi futuri • Stack bluetooth poco maturi. – Legame con Linux per il posizionamento (limita la portabilità). – Utilizzo di altri sistemi di posizionamento? • Client multipiattaforma (.NET?) se ci si slega da Linux. • Possibilità di supportare la persistenza dello stato dei client. 20 FINE Proxy-based infrastructure for LBS toiloring
Scarica
