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 server



Componente lato server che si occupa di inviare
le pagine sul MOVE client
In seguito ricezione di una richiesta (messaggio
sincrono)
Service
DB
Fetch page

Notificate (messaggio asincrono)
Page Server

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
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
Service
DB
Statistics
DB
Fetch pages

Page
Server
Services/
Profile
matcher
Broker
Trigger
Time
Positio
n
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?
Raccolta statistiche (2)



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
0
25/6/08
9
26/6/08
7
15
27/6/08
Daily counters
28/6/08
29/6/08
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

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
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
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
Quali servizi inviare (3)

Prima di essere combinati per dare il punteggio
finale, i valori scorespm e scorestat 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 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.
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 trigger restituisce un servizio le cui pagine non sono
disponibili al page server


Il punteggio statistiche assegnato è 0
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
Un tradeoff importante


L’autore di un servizio può modificare singole pagine
Attualmente viene inviato l’intero servizio



Alternativa: inviare solo le pagine modificate



Vantaggio: il messaggio di statistiche contiene un campo Version globale
del servizio  leggero
Svantaggio: invio di tutte le pagine  pesante
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 all’interno del
page server
