Broker Server

1. Broker Server Progetto di Ingegneria del Web 2008 Alessio Bianchi Andrea Gambitta Giuseppe Siracusano

2. Architettura di SMS • Servizio • Una o più pagine XML • Memorizzati e serviti da page server • Pubblicati sulle yellow pages • Comunicazione • Basata su SMILE: middleware che astrae dai livelli di rete sottostanti • SMILE gestisce il discovery dei processi, il trasporto del traffico e il ciclo di vita dei nodi

3. Invio delle pagine Service DB • Processo Page client • Componente lato client che si occupa di richiedere le pagine e gestire l'arrivo di notifiche • Richiede pagine conoscendo a priori l'indirizzo • Riceve pagine tramite un messaggio asincrono • Processo Page server • Componente lato server che si occupa di inviare le pagine sul MOVE client • In seguito ricezione di una richiesta (messaggio sincrono)‏ • Notificate (messaggio asincrono)‏ Fetch page Page Server Page notification Page req/resp

4. Il Broker server Service DB Statistics DB • Integrato nel page server • Invia servizi al client MOVE in seguito al verificarsi di un determinato evento • Innesco da matcher servizi/profilo • Trascorso un intervallo di tempo dall'ultimo invio di servizi • Variazione della posizione dell'utente • Registra statistiche riguardanti l'utilizzo dei servizi inviate dal MOVE client Services/ Profile matcher Fetch pages Fetch stat Update stat Page Server Broker Trigger Time Position Services to cache Statistics msg

5. Raccolta statistiche (1) • Il broker riceve le statistiche dal MOVE tramite messaggi asincroni • Statistiche raccolte: • Identificativo del servizio • Numero di utilizzi dall’ultimo invio di statistiche • Versione della copia attualmente in cache • Timestamp della copia attualmente in cache • Le statistiche inviate si riferiscono a tutti e soli i servizi presenti in cache • Problema: invio statistiche non predicibile  quali dati effettivi durante i giorni di silenzio?

6. 0 7 15 9 Raccolta statistiche (2) 25/6/08 26/6/08 27/6/08 28/6/08 29/6/08 • Le statistiche ricevute dal MOVE vengono utilizzate per calcolare una densità di utilizzo per ogni servizio. • Nel caso in cui dall’ultimo arrivo di statistiche sia passato almeno un giorno, la densità viene proporzionalmente ripartita sui giorni effettivamente trascorsi • I valori di densità ripartiti sono memorizzati in contatori Dailycounters

7. Politica di invio dei servizi • I servizi vengono inviati al client utilizzando i seguenti criteri: • Utilizzo del servizio da parte dell’utente • Utilizzo globale del servizio • Profilo utente • Il numero di servizi inviabili è stabilito dall’utente: • Definendo la massima quantità di dati per invio • Definendo la massima quantità di invii giornalieri

8. Services/profile matcher • Trigger esterno che genera una lista di servizi candidati da inviare all’utente • Matching semantico tramite Wordnet tra preferenze dal profilo utente e tag dei servizi • Lista di servizi ordinata per rilevanza • I servizi in questa lista vengono opportunamente combinati con le statistiche utente per generare la lista da inviare al client

9. Quali servizi inviare (1) • Il broker sceglie i servizi da inviare dalla lista fornita dal SPM • Ogni servizio dispone di un valore scorespm attribuito da Wordnet • Per ogni servizio, viene calcolato un punteggio sulla base dell’uso passato del servizio • I due punteggi sono combinati linearmente: • Il parametro  puo essere modificato dall’amministratore di sistema •  > 1 favoriti i servizi utilizzati nel passato •  < 1 favoriti i servizi suggeriti dal SPM

10. Quali servizi inviare (2) • Il parametro scorestat è ottenuto sommando tre componenti: • Utilizzo del servizio nell’ultima settimana da parte dell’utente • Utilizzo complessivo del servizio da parte dell’utente • Utilizzo complessivo del servizio da parte di tutti gli utenti

11. Quali servizi inviare (3) • Prima di essere combinati per dare il punteggio finale, i valori scorespm e scorestat vengono normalizzati:

12. Invio dei servizi • Una volta ordinata la lista dei servizi secondo il valore score, vengono inviati quanti più servizi completi rispettando i limiti posti dall’utente. • L’invio del servizio è effettuato utilizzando le funzionalità del page server. • Tramite l’utilizzo di un campo Version per ogni servizio, non vengono inviati nuovamente i servizi già in cache e ancora aggiornati.

13. Schema del database • Utenti possono aderire al broker • Tutti i servizi possono essere selezionati dal broker • Mantenuta anche una tabella di contatori giornalieri per ogni utente e per ogni servizio

14. Scenari critici • Il trigger restituisce servizi di cui non abbiamo statistiche • Il punteggio statistiche assegnato è 0 • Il trigger restituisce un servizio le cui pagine non sono disponibili al page server • Il servizio non viene inviato, viene loggato l’errore • Il MOVE invia statistiche di un servizio di cui non abbiamo precedenti statistiche • Le statistiche vengono aggiunte nella tabella Statistics

15. Un tradeoff importante • L’autore di un servizio può modificare singole pagine • Attualmente viene inviato l’intero servizio • Vantaggio: il messaggio di statistiche contiene un campo Version globale del servizio  leggero • Svantaggio: invio di tutte le pagine  pesante • Alternativa: inviare solo le pagine modificate • Vantaggio: invio delle singole pagine modificate  leggero • Svantaggio: messaggio di statistiche contiene un campo Version per ogni pagina  pesante • Valutazione futura sulla base di frequenza dei messaggi di statistiche e di invio servizi, numero medio di pagine per servizio, frequenza media di aggiornamento di servizi e pagine.

16. Sviluppi futuri • Realizzare il trigger esterno basato sul tempo • Realizzare il trigget esterno basato sulla posizione • Integrazione • ID del servizio è stato modificato ad intero • Integrazione del services/profile matcher all’interno del page server