BROKER SERVER Progetto di Ingegneria del Web 2008 Alessio Bianchi Andrea Gambitta Giuseppe Siracusano

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

Invio delle pagine 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) Page Server Page notification Fetch page Service DB Page req/resp

Il Broker server 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 Page Server Broker Services/ Profile matcher Statistics DB Time Positio n Statistics msg Update stat Fetch stat Service DB Trigger Fetch pages Services to cache

Raccolta statistiche (1) Il broker riceve le statistiche dal MOVE tramite messaggi asincroni Statistiche raccolte: Identificativo del servizio Numero di utilizzi dallultimo 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?

25/6/0826/6/0827/6/0828/6/ /6/08 Daily counters Raccolta statistiche (2) Le statistiche ricevute dal MOVE vengono utilizzate per calcolare una densità di utilizzo per ogni servizio. Nel caso in cui dallultimo 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

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

Services/profile matcher Trigger esterno che genera una lista di servizi candidati da inviare allutente 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

Quali servizi inviare (1) Il broker sceglie i servizi da inviare dalla lista fornita dal SPM Ogni servizio dispone di un valore score spm attribuito da Wordnet Per ogni servizio, viene calcolato un punteggio sulla base delluso passato del servizio I due punteggi sono combinati linearmente: Il parametro puo essere modificato dallamministratore di sistema > 1 favoriti i servizi utilizzati nel passato < 1 favoriti i servizi suggeriti dal SPM

Quali servizi inviare (2) Il parametro score stat è ottenuto sommando tre componenti: Utilizzo del servizio nellultima settimana da parte dellutente Utilizzo complessivo del servizio da parte dellutente Utilizzo complessivo del servizio da parte di tutti gli utenti

Quali servizi inviare (3) Prima di essere combinati per dare il punteggio finale, i valori score spm e score stat vengono normalizzati:

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

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

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 lerrore Il MOVE invia statistiche di un servizio di cui non abbiamo precedenti statistiche Le statistiche vengono aggiunte nella tabella Statistics

Un tradeoff importante Lautore di un servizio può modificare singole pagine Attualmente viene inviato lintero 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.

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 allinterno del page server