Relazione

SAMOA: Socially-Aware and Mobile Architecture
Relazione esame del corso di Reti di Calcolatori LS
Emanuele Colombini
Introduzione
Sin da quando si è affermata la rete internet,
sono stati sviluppati strumenti di comunicazione
sempre più evoluti, in modo da permettere a milioni
di persone di entrare in contatto tra loro. Il concetto
di comunità è cresciuto assieme alla facilità di
oltrepassare i classici limiti della conoscenza fisica di
altri individui. Gli strumenti forniti da internet hanno
permesso dapprima di comunicare semplicemente
con le persone conosciute, ad esempio usando le email; l’evoluzione dei servizi ha portato poi alla
creazione di piccole comunità dedicate a particolari
argomenti: ad esempio le comunità a tema ed i
forum.
Infine le reti sociali hanno dato possibilità
ancora maggiori di conoscere altre persone, entrando
nel vivo dei loro gusti e delle loro caratteristiche. La
maggior parte degli strumenti che aiuta nella
creazione di queste comunità di persone si basa
appunto su internet; ogni persona collegata alla rete
è slegata dalla sua posizione fisica e dal suo contesto,
ma entra a far parte di una comunità unica dove si
possono scambiare informazioni di tutti i tipi.
Moltissimi servizi attuali, estremamente pubblicizzati
anche attraverso altri canali di comunicazione,
mettono in mostra la facilità con cui si possono
creare legami tra persone che fisicamente risiedono
molto lontane le une dalle altre.
Con il recente sviluppo delle tecnologie mobile,
dispositivi portatili che hanno grandi capacità
comunicative, sono state ampliate ulteriormente le
possibilità di creare reti sociali legate al contesto in
cui si trovano i membri della rete stessa: il luogo
fisico in cui si trovano gli utenti. Un primo strumento
che permette la creazione e la gestione di tali reti è
data dall’oggetto di questa relazione: il middleware
SAMOA (“Socially-Aware and MObile Architecture”).
SAMOA è un middleware che permette
all'utilizzatore di creare reti sociali semantiche in
ambienti mobili, in qualsiasi momento ed in qualsiasi
luogo (“anytime & anywhere social network
computing”). L'obiettivo principale di SAMOA è
quello di poter fornire un supporto semplice da
usare, in modo da permettere ai programmatori di
concentrarsi sull'applicazione piuttosto che sulla
creazione e sulla gestione della rete sociale. A tale
scopo, SAMOA mette a disposizione una serie di
servizi e di funzionalità che permettono la
localizzazione e la comunicazione con altre entità
SAMOA.
I prossimi paragrafi saranno concentrati sulla
descrizione di questo middleware. In particolare il
secondo paragrafo descriverà le caratteristiche
fondamentali di SAMOA. Seguirà una descrizione più
dettagliata del modello che ha guidato la creazione
della rete sociale, considerando i ruoli delle entità in
gioco ed i profili che le caratterizzano. Il quarto
paragrafo sarà concentrato sull’architettura del
middleware descrivendo i vari servizi offerti uno per
uno. Il quinto paragrafo riguarderà invece
l’implementazione di due dei servizi fondamentali di
SAMOA. Verrà poi presentato un caso di studio in cui
sono state messe in evidenza le caratteristiche
fondamentali del progetto. La trattazione si
concluderà con il paragrafo dedicato alle conclusioni
ed ai futuri sviluppi.
Caratteristiche di SAMOA
In questo paragrafo verranno elencate le
caratteristiche dominanti di SAMOA, ovvero tutte
quelle particolarità che derivano dallo studio delle
altre soluzioni già presenti sul mercato ed ottimizzate
in modo da ottenere un unico progetto adatto ad
ogni evenienza.
Come detto nell’introduzione, una delle
principali caratteristiche di SAMOA è che non si basa
su Internet. Molte soluzioni, nate col nascere della
rete, hanno invece fatto molto affidamento su questo
mezzo di comunicazione. Un utente che vuole
partecipare ad una comunità non deve far altro che
registrarsi e specificare i propri interessi. La
semplicità di tali progetti è anche il loro maggior
limite: sebbene negli ultimi anni molte città si stiano
adoperando per offrire il servizio di connettività con
la rete Internet anche per le vie del centro, resta
comunque una soluzione che non tiene conto del
luogo in cui nasce la rete sociale. SAMOA permette
invece la definizione di reti sociali fortemente
dipendenti dal luogo in cui vengono create e per fare
questo non è necessaria la presenza della rete
Internet: questa capacità è detta “anytime and
anywhere social network computing”.
Diretta conseguenza di quanto appena detto,
un'altra caratteristica fondamentale di SAMOA
riguarda il concetto di prossimità. Creare reti sociali
basate sulla località in cui si trova l'utente (chiamato
“ego-user” per mettere in evidenza la sua presenza
centrale nella propria rete sociale) significa mettere
in relazione l'utente stesso con gli altri utenti situati
nella stessa località. Sfruttare il concetto di
prossimità permette di creare nuove interazioni con
persone sconosciute, ma che frequentano
abitualmente gli stessi luoghi (chiamati “familiar
stranger”) oppure di riconoscere un amico nelle
vicinanze, che altrimenti non avremmo visto.
Un ulteriore aspetto distintivo di SAMOA
risiede nell'adozione di un approccio semantico nella
specifica delle caratteristiche degli utenti e delle
località, oltre all'uso di algoritmi di matching
semantici per inferire relazioni tra le individualità
presenti. Tale sistema lascia all'utente uno strumento
molto potente, ma allo stesso tempo estremamente
semplice da usare per descrivere le proprie
caratteristiche e preferenze. Oltre a questo è
possibile specificare in modo flessibile anche gli
aspetti peculiari della rete sociale che si vuole creare
mediante la definizione delle caratteristiche e delle
preferenze dell'ego-user nella località. Una diretta
conseguenza dell'utilizzo del match semantico risiede
nel fatto che non è necessario registrarsi ad alcun
servizio: ogni utente può modificare le proprie
caratteristiche in qualsiasi momento e rientrare in
reti sociali senza che questo sia reso esplicito, ma in
maniera completamente automatica.
SAMOA, come indicato nel nome, permette di
creare reti mobili, ovvero l'utente può utilizzare il
middleware anche sui nuovi dispositivi portatili, che
oggigiorno sono sempre più potenti e permettono
comunicazioni wireless. In questo modo la rete segue
l'ego-user ovunque esso vada, cambiando
continuamente, adattandosi alla località in cui si
trova e aggregando nuovi membri nella rete che
prima non risiedevano nella precedente località.
Questo effetto “roaming” della rete, assieme alle
precedenti caratteristiche di SAMOA, è una
funzionalità messa a disposizione del middleware.
Il fatto che SAMOA sia il primo tentativo di
produrre un middleware che permetta la creazione di
reti sociali dimostra lo sforzo di portare l'attenzione
sulla facilità di progetto, sviluppo e distribuzione di
nuove applicazioni atte a supportare il social network
computing. Tutte le altre soluzioni analizzate si sono
dimostrate troppo legate all'applicazione e
all'ambiente di sviluppo, portando ad una
conseguente incapacità di riusare il codice prodotto e
dovendo ogni volta ricominciare il progetto daccapo.
La soluzione a middleware permette, invece, una
netta separazione tra la gestione della rete sociale e
l'applicazione vera e propria, facilitandone la veloce
prototipazione.
Modello della rete sociale
Le reti sociali gestite da SAMOA sono dei
gruppi di utenti che si trovano tutti in una stessa
località e che condividono gli stessi interessi. Le reti
sono costruite attorno all'ego-user (vengono infatti
chiamate reti egocentriche) e tengono in
considerazione vari aspetti: le caratteristiche della
località in cui si trova l'ego-user (“place-awareness”)
e le preferenze specificate dall'ego-user stesso
(“profile-awareness”). Questa distinzione è stata
introdotta per facilitare ed ottimizzare la gestione
della rete: la visibilità della località permette di
ridurre il raggio d'azione della rete considerando
solamente gli utenti vicini all'ego-user, mentre la
visibilità del profilo permette di raffinare
ulteriormente la rete sociale, considerando
solamente quegli utenti che hanno caratteristiche in
comune con l'ego-user.
Ogni entità SAMOA può ricoprire uno o più
ruoli: “manager”, “client” e “member”.
Manager: sono quei particolari ego-user che
intendono creare una propria rete sociale.
Non ci sono restrizioni sulla natura del
manager, può essere un utente reale oppure
un componente software, può essere fisso
oppure mobile. L'unico aspetto importante è
che il manager ha il compito di definire i
parametri della propria rete sociale
specificando i criteri della località e delle sue
preferenze.
Clients: i clienti sono utenti SAMOA che
entrano nel raggio d'azione del manager.
Potrebbero diventare membri della rete se le
loro caratteristiche combaciassero con quelle
richieste dal manager.
Members: i clienti che passano il test
semantico entrano a far parte della rete
sociale.
Ogni entità può svolgere più ruoli
contemporaneamente: ad esempio un manager può
essere membro di un’altra rete, oppure un utente
può essere membro di più reti sociali, come mostrato
nella figura 1.
Figura 1: Reti Sociali
I punti fondamentali per definire una rete
sociale in SAMOA sono quindi il concetto di località e
la specifica delle caratteristiche e delle preferenze
dell'ego-user.
Una località in SAMOA è definita dal numero di
entità collegate con il manager, sia direttamente che
indirettamente. Per inserire un limite alla dimensione
della rete, vengono contati un certo numero di hop
tra un utente ed il manager: se il numero supera il
limite imposto, l'utente è fuori dalla rete. A seconda
del caso, però, è possibile specificare altri sistemi per
definire una località: ad esempio possono
considerarsi vicini tutti gli utenti di una stesso access
point wireless oppure tutti gli utenti collegati ad una
stessa MANET (“Mobile Ad-hoc NETwork”).
Come detto prima, le caratteristiche e le
preferenze degli utenti vengono specificate secondo
un approccio semantico. Ogni utente, sia esso
manager, cliente o membro, dispone di una serie di
profili che contengono le loro caratteristiche, i loro
interessi e le relative preferenze. In particolare ogni
utente viene rappresentato da un identificatore
univoco, un Personal IDentifier (PID) e da un profilo
utente (UserProfile UP). Il UP contiene la lista di tutti
gli interessi ed attività che l'utente svolge,
specificando ove necessario anche le preferenze su
ciascuna attività (un utente a cui piace ascoltare la
musica inserirà l'attività “Musica” tra gli hobbies ed in
particolare specificherà il tipo di musica nelle
preferenze relative a questa attività, ad esempio
“Rock & Roll”) Per quanto riguarda il manager,
invece, vengono introdotti altri due tipi di profili, il
primo dei quali descrive la località (PlaceProfile PP)
ed il secondo indica indica i criteri che un manager
vuole per la propria rete sociale (DiscoveryProfile DP).
Il PP contiene la lista di attività che caratterizzano la
località del manager e agisce come un primo filtro.
Ogni membro della rete sociale deve avere almeno
una di queste attività nel proprio UP. Il DP invece
contiene le preferenze del manager sulle attività
specificate nel PP. Quest'ultimo profilo agisce come
un secondo filtro e permette una selezione più
raffinata degli utenti nella rete sociale.
Una particolarità della gestione dei profili di
SAMOA è che i dati scambiati con gli altri utenti sono
limitati allo stretto indispensabile. Sia per motivi di
performance che per considerazioni legate alla
privacy dei dati, i profili inviati al manager
contengono solo le informazioni relative alle attività
in comune col manager stesso.
La lista dei membri della rete sociale in un dato
momento, ovvero l'insieme degli utenti che sono
s
colocati nella stessa località del manager e che hanno
passato entrambi i filtri del PP e del DP, formano la
Place-dependent Social Network.. Questa lista,
assieme ai vari eventi di inserimento o uscita dei
membri dalla rete, rappresenta le informazioni messe
a disposizione
sposizione dell'applicazione. Il programmatore
quindi non deve fare altro che richiedere tali servizi al
middleware e concentrarsi sul resto dell'applicazione
senza preoccuparsi della gestione della rete.
Oltre alla rete “volatile”, SAMOA mette a
disposizione anche un altro tipo di rete sociale
persistente, la Global Social Network. Questa rete
memorizza tutte le reti sociali create nel tempo
dall'ego-user,
user, oltre a registrare tutti i membri che ne
hanno fatto parte. Ogni qualvolta un nuovo utente è
stato inserito nella place-dependent
dependent social network,
le stesse informazioni sono state inserite anche nella
global social network. Questa rete persistente
fornisce all'applicazione una serie di informazioni
memorizzate ed aggiornate nel tempo, che possono
essere usate per vari scopi, come ad esempio l'analisi
delle preferenze dei vari membri incontrati per scopi
commerciali.
Figura 2:: Uso dei profili nelle reti sociali
Architettura del middleware
SAMOA ha un'architettura strutturata
strutt
su due
livelli, posti tra la Java Virtual Machine e
l'applicazione. Il livello più basso, quello a contatto
con la JVM e tutti i dispositivi di hardware, è il Basic
Service Layer (BS), mentre il livello più alto, quello che
si interfaccia all'applicazione, è il Social Network
Management Layer (SNM).
Figura 3:: Architettura SAMOA
Basic Service Layer
Il BS è il layer che si interfaccia alla JVM e
mette a disposizione le varie funzioni che permettono
di rilevare e comunicare con altre entità SAMOA in
vista. E' anche presente un sistema di nomi che
consente all'applicazione e agli altri servizi SAMOA di
identificare gli utenti mediante i loro PID. In
particolare, il BS fornisce i seguenti servizi:
Message Transport Manager (MTM)
L'obiettivo principale dell'MTM è quello di
implementare i pattern di comunicazione con le altre
entità SAMOA mediante il protocollo UDP. Sono
permesse due tipologie di comunicazioni: la
comunicazione punto-punto
punto verso un singolo utente
e la comunicazione punto-multipunto
punto
verso tutti gli
utenti SAMOA presenti nel raggio d'azione dell'egodell'ego
user. L'invio di un messaggio unicast nella
comunicazione punto-punto
punto ha come destinatario un
singolo
o utente SAMOA identificato dal suo PID, il
servizio di nomi interno seleziona il corretto indirizzo
dell'utente in modo automatico. L'invio dei messaggi
punto-punto, invece, risente dello scenario
applicativo della località: nel caso di una rete
infrastrutturata si utilizza il broadcast, mentre nel
caso di una MANET viene usato un protocollo di
flooding controllato.
Location/Proximity Manager (LPM)
Il secondo servizio del BS ha come scopo
principale il riconoscimento delle entità SAMOA
presenti nel raggio d'azione, oltre alla gestione del
PID dell'ego-user. Ogni entità SAMOA, o meglio ogni
servizio LPM, rende nota la propria presenza alle altre
entità in vista mediante messaggi broadcast di
presenza, chiamati PresenceBeacon, inviati ad
intervalli regolari. Ogni PresenceBeacon contiene il
PID dell'utente e l'indirizzo IP del suo dispositivo. Le
entità SAMOA riceventi, mediante l'LPM, aggiungono
le informazioni del nuovo utente nelle proprie tabelle
delle entità co-locate e informano i livelli superiori
dell'evento. Se non arrivano più PresenceBeacon da
parte di un certo utente, tale utente viene
considerato fuori dal raggio d'azione e quindi
scollegato dalla rete sociale. Il Location/Proximity
Manager ha un ruolo molto importante nella
gestione della rete sociale, visto che è questo servizio
ad incaricarsi della responsabilità di percepire la
presenza degli altri utenti; inoltre è grazie all'LPM che
è possibile gestire il raggio d'azione delle reti sociali
indicando di volta in volta il numero di hops.
Social Network Management Layer
Tutte le funzionalità per creare e mantenere le
reti sociali dell'ego-user sono gestite mediante
questo livello. Il SNM recupera le informazioni dal BS
e comunica al livello applicativo delle variazioni delle
entità co-locate con il manager. I servizi del SNM
sono:
Profile Manager (PM)
Il PM, come indicato nel nome, si concentra
sulla gestione dei profili della rete sociale. Oltre a
questo, il PM si prende carico di determinare,
coordinandosi con il Semantic Matching Engine, quali
delle altre entità SAMOA possono entrare nella rete
sociale del manager. Innanzitutto il PM controlla la
presenza e la correttezza dei profili dell'ego-user. Gli
ego-user interessati a creare una rete sociale, i
manager, possono configurare il PM in modo tale da
accorgersi dell'arrivo di nuovi utenti nel raggio
sociale. Il servizio LPM informa il PM della presenza di
un nuovo utente e quest’ultimo inizia il protocollo
che permette l'inserimento dell'utente nella rete
sociale, se viene considerato idoneo mediante gli
algoritmi dello SME.
Semantic Matching Engine (SME)
Gli algoritmi semantici sono implementati
mediante lo SME. La versione descritta in questa
relazione è ancora in fase prototipale ed il sistema è
stato realizzato mediante sistemi simil-semantici. Nel
prossimo paragrafo verrà descritta la logica che guida
il funzionamento dello SME, senza entrare nel
dettaglio implementativo.
Place-dependent Social Network Manager
(PSNM)
Questo servizio gestisce la place-dependent
social network mediante la creazione e la gestione di
una tabella in memoria contenente tutte le
informazioni utili all'applicazione. Una volta che il PM
determina idoneo un nuovo utente, comunica al
PSNM il PID di tale utente, il suo attuale indirizzo IP e
la porzione di UserProfile compatibile con il PP. Il
PSNM ha il compito di informare anche il livello
applicativo dell'avvenuto inserimento del nuovo
utente nella rete. L'uscita di un utente dalla rete
sociale è riconosciuta dal servizio LPM, questo
informerà dell'evento il PM e a sua volta il PSNM. Il
Place-dependent Social Network Manager toglierà
l'utente uscito dalla tabella dei membri attuali ed
informerà l'applicazione.
Social Global Network Manager (GSNM)
La rete sociale persistente è gestita dal GSNM.
Per ogni rete sociale viene creata una tabella
contenente le informazioni relative ad ogni utente
incontrato. Per ogni utente le informazioni
memorizzate sono il PID e la porzione di UP che ha
permesso all'utente stesso di entrare nella rete
sociale. Oltre a queste informazioni vengono
registrati anche i PP ed i DP che hanno caratterizzato
tale rete sociale. Quando un utente cambia le proprie
preferenze
e
caratteristiche
il
GNSM
automaticamente
memorizza
le
modifiche
nell'apposita tabella. Il servizio presenta una API in
modo da permettere ai programmatori delle
applicazioni di poter elaborare le informazioni
relative agli utenti incontrati.
imposto a priori, ma deciso dal processo servitore. Ad
esempio la coda fornita dal PSNM è composta da
tabelle contenenti due colonne, nella prima delle
quali vengono inseriti i PID degli utenti, mentre nella
seconda viene specificato l'ingresso o l'uscita di
quell'utente mediante un booleano; l'applicazione
deve quindi adattarsi a ricevere messaggi di questo
tipo.
Cliente: Richiesta
coda interna XYZ
Servitore:
Controllo
presenza nome
Dettagli implementativi
Coda
Esistente?
Oggetti di questa relazione sono il servizio
Profile Manager ed il servizio Semantic Matching
Engine. Il servizio SME richiedeva tecnologie non
ancora rese disponibili durante la prototipazione del
middleware, viene quindi mostrato solamente il suo
funzionamento all’interno del sistema.
No
Servitore:
Creazione coda
Si
Cliente: Ricezione
della coda
Servitore:
Fornitura della
coda
Cliente: Receive
sulla coda
Cliente Bloccato
fino a ricevimento
Comunicazione locale tra i livelli
Per imporre una ben determinata linea di
demarcazione tra i livelli, le comunicazioni sono state
implementate a scambio di messaggi e non a
chiamata di procedura. Questo significa che le API dei
servizi di un certo livello forniscono al livello
superiore la possibilità di recuperare una o più code
di messaggi per informarli dell'evolversi della
situazione. Un esempio dell'utilizzo delle code
avviene nella comunicazione tra LPM e PM; il PM
richiede all'LPM una coda di notifica per venire
informato dell'arrivo o dell'uscita degli utenti dal
raggio d'azione dell'ego-user. La stessa procedura
deve essere attuata tra applicazione e PSNM ed in
questo caso serve per conoscere l'ingresso e l'uscita
degli utenti dalla rete sociale del manager.
La gestione delle code viene effettuata dal
servizio server che le mette a disposizione dei servizi
client. Per ogni server, le code sono individuate dal
nome. Il servizio client, una volta ottenuta la coda, si
deve porre in ascolto per l'arrivo di nuovi messaggi;
una receive sulla coda è bloccante fino a che non è
disponibile un messaggio.
Per permettere un alto grado di riusabilità
delle code, il contenuto dei messaggi non viene
Servitore: Send a
tutti sulla coda
Cliente: Ricezione
messaggio sulla
coda
Figura 4: Richiesta e funzionamento coda interna
Gli algoritmi semantici: SME
SAMOA utilizza tecniche basate sul matching
semantico per popolare le reti sociali dei manager. I
profili scambiati vengono elaborati mediante due
algoritmi e in base al risultato si può determinare se
un utente è idoneo o meno ad entrare in una
determinata rete sociale.
Il primo algoritmo viene eseguito dal cliente
che entra nel raggio d'azione del manager. Questi,
non appena lo vede, invia il PP relativo alla rete
sociale. Una volta ricevuto il PP, il primo algoritmo
determina quali attività del cliente combacino con
quelle richieste dal manager. Il risultato del primo
algoritmo viene poi inviato al manager che lo
elaborerà col secondo algoritmo. La lista di attività in
comune tra cliente e manager viene corredata con
tutte le relative preferenze del cliente stesso. Se il
risultato del primo algoritmo non contiene alcuna
attività in comune, allora il cliente viene
immediatamente considerato non idoneo ad entrare
nella rete. Il controllo semantico delle attività
prevede due modalità: una diretta, caratterizzata da
una stessa “classe di attività” sia per il manager che
per il cliente, ed una indiretta, quando il cliente
specifica una attività che è sottoclasse di una indicata
dal manager. Questa doppia modalità permette una
ulteriore forma di semplificazione nella creazione
delle reti sociali, infatti il cliente può specificare in
modo più preciso le proprie caratteristiche e
preferenze, mentre il manager può indicare una
classe di attività generica e considerare al suo interno
non solo gli utenti che mostrano gli stessi interessi,
ma anche utenti che mostrano interessi più specifici
in una branchia della attività considerata. Un esempio
di match semantico diretto può avvenire in uno
scambio di file ed informazioni musicali dove il
manager e il cliente sono entrambi interessati
all'attività dell'ascolto “Musica”. Se consideriamo
invece un software pubblicitario (il manager) avente
come attività di interesse lo “Shopping”, un cliente
interessato
ad
acquistare
vestiti
(attività
“BuyClothes”, sottoclasse di “Shopping”)
può
rientrare nella rete sociale del manager e venire
informato delle ultime proposte nel campo del
vestiario.
dall'utente e determina se quest'ultimo può far parte
o meno della rete sociale. L'algoritmo viene eseguito
dal manager e ha inizio una volta recuperato il
risultato del primo algoritmo da un client idoneo. Il
profilo del client contiene le preferenze relative alle
attività richieste dal manager nel PP. Per spiegare il
funzionamento
dell'algoritmo
semantico,
considereremo le preferenze del client come istanze
e le preferenze richieste dal manager come classi. La
similitudine semantica delle preferenze può essere di
tre tipi:
exact case : la preferenza del client è un'istanza
della classe di preferenze richiesta dal manager;
subsumes case : la preferenza del client è
l'istanza di una classe più generica rispetto a
quella del manager;
plug-in case : la preferenza del client è l'istanza
di una classe più specifica rispetto a quella del
manager.
Se alla fine dei controlli il client risulta idoneo
ad entrare nella rete, allora le sue informazioni
vengono inserite nella place-dependent social
network e nella global social network del manager e
rese disponibili per l’applicazione.
Algoritmo2
(UMP, DP)
Algoritmo1:
Creazione nuovo
UMP
UMP vuoto?
Altre Attività?
(PlaceProfile)
No
No
Algoritmo1:
Restituzione UMP
Return False
No
Return True
No
Return False
No
Si
Relazione
attività?
Si
Altre Attività?
Si
Si
Match ok?
SI
Aggiunta
preferenze utente
ad UMP
Figura 5: Funzionamento algoritmo 1
Il secondo algoritmo confronta le preferenze
specificate dal manager con quelle indicate
Figura 6: Funzionamento algoritmo 2
Il protocollo della rete SAMOA: PM
Gli algoritmi presentati nel paragrafo
precedente fanno parte del protocollo per
l’inserimento nella rete sociale. Il protocollo è gestito
dal Profile Manager,, mentre gli algoritmi sono messi
a disposizione dal Semantic Matching Engine.
Engine
Per gestire il protocollo il PM richiede al MTM
due canali unicast: uno in input ed uno in output;
questi canali vengono utilizzati nello scambio di
messaggi tra il manager e l’utente in questione.
Inoltre il PM richiede al LPM una coda locale per
ottenere le variazioni del vicinato; all’arrivo di un
nuovo utente verrà effettuato il protocollo,
rotocollo, mentre
all’uscita dell’utente
utente corrisponderà l’eventuale
rimozione dalla rete sociale.
I messaggi scambiati tra manager e utente
sono 3, come si può vedere nella figura 7:
nel paragrafo precedente
edente permettono il controllo
semantico tra i profili dell’utente
dell’utent e quelli della rete
sociale cui egli vuole far parte. Nei passi 3 e 5 del
protocollo vengono utilizzati
utilizzat rispettivamente il primo
ed il secondo algoritmo dello SME; la prima volta
viene
ene controllata la compatibilità dell’utente con la
località del manager, mentre la seconda volta
vengono confrontati i gusti dell’utente con quelli del
manager. Se entrambi i controlli danno esito positivo
allora l’utente può far parte della rete sociale.
In caso di esito positivo il PM comunica al
PSNM l’inserimento del nuovo utente nella rete
specificandone anche il PID e la porzione del suo
UserProfile (chiamato UMP, UserMatchingProfile).
Il PM cerca di garantire una certa qualità di
servizio mettendo a disposizione
disposizio
altre due
funzionalità automatiche.
In primo luogo vengono ridotte al minimo le
comunicazioni non necessarie. Mediante la global
social network vengono memorizzate tutte le
informazioni degli utenti incontrati; se l’utente
indicato dal LPM è già stato incontrato
precedentemente si cerca di usare il profilo UMP
memorizzato, evitando così un nuovo protocollo.
Figura 7: Protocollo PM
1) Il PM-Manager
Manager viene informato dall'LPM-Manager
dall'LPM
dell'arrivo del nuovo utente User.
2) il PM-Manager invia al PM-User
User il PlaceProfile
della propria località.
3) il PM-User
User riceve il PP e, mediante il primo
algoritmo dello SME, determina la porzione del
proprio UserProfile compatibile col PP (questa
porzione è chiamata UserMatchingProfile - UMP).
4) il PM-User invia il UMP al PM-Manager.
Manager.
5) il PM-Manager
Manager riceve il UMP e determina se
l'utente può entrare nella sua rete sociale
mediante il secondo algoritmo dello SME ed il
DiscoveryProfile.
6) il PM-Manager invia al PM-User
User il responso del
protocollo e, nel caso di risposta positiva,
comunica l’ingresso al PSNM
Lo SME ricopre un ruolo molto importante nel
protocollo di inserimento; i due algoritmi presentati
L’altra funzionalità, invece, si concentra
concent sulla
possibilità di perdita dei messaggi da parte della rete
mobile.. Per ogni nuovo protocollo viene memorizzato
l’istante di inizio; se questo protocollo non termina
oltre una data scadenza il protocollo viene
automaticamente re-iniziato.
iniziato.
Caso di studio:
io:
Marketing
Scenario
Viral
Per descrivere le capacità di SAMOA viene ora
presentato un esempio di viral marketing. In questo
caso di studio si ipotizzano vari negozi forniti di
applicazioni SAMOA in grado di riconoscere i passanti
interessati a certi prodotti; a questi utenti vengono
inviati messaggii pubblicitari in modo da informarli di
particolari promozioni. Gli
Gl utenti poi, camminando
per le vie del centro, passeranno le pubblicità ai
partecipanti alle loro reti sociali. Di seguito viene
presentata l’applicazione SONET basata sul
middleware SAMOA, poi verranno elencate
elencat le entità
partecipanti al caso di studio ed infine verranno
mostrate le varie interazioni tra gli utenti.
L’applicazione SONET
Una delle principali caratteristiche di SAMOA
consiste nella facile prototipazione di applicazioni per
il social networking. SONET è un’applicazione
costruita sul middleware SAMOA pensata per i
dispositivi portatili wireless. Gli utenti, camminando
per le vie del centro, possono entrare nelle
nell reti sociali
di altri manager oppure riconoscere nuovi
partecipanti alle proprie reti. L’applicazione ha anche
la capacità di registrare le pubblicità che vengono
ricevute dai negozi e che saranno poi consegnate ai
propri “amici”, ovvero ai partecipanti delle proprie
reti sociali. Le pubblicità sono inviate da altre istanze
di SONET mediante una particolare configurazione.
configura
“
handbook
Pubblicità: Promozione sul libro “The
of mobile middleware”.
ClothesShop:: venditore di vestiti;
vestiti interessato a
tutti gli utenti che intendono acquistare stivali
senza spendere più di 100 €.
Pubblicità:: Promozione sui nuovi stivali in
vendita.
Utenti:
Nome:: Ernest Hemingway
Interessi:: lettura libri del tipo “Computer
Science”
Rete Sociale:: interessato a tutti gli utenti che
amano la lettura
Nome: Umberto Nobile
Interessi:: lettura libri del tipo “Computer
Science” ed acquisto stivali con prezzo non
superiore ai 90 €.
Rete Sociale:: interessato a tutti gli utenti che
amano la lettura e gli stivali.
Nome:: Antonino Zichichi
Interessi: lettura dei giornali e acquisto
magliette.
Rete Sociale:: interessato a tutti gli utenti che
amano la lettura ed i vestiti.
Figura 8: SONET
Entità del caso di studio
Per mostrare tutte le capacità semantiche del
middleware, sono stati previsti vari partecipanti,
ognuno con le sue caratteristiche e preferenze:
Negozi:
BookShop: libreria del centro;; la promozione
riguarda tutti gli utenti che sono interessati alla
lettura dei libri del tipo “ComputerScience”.
Interazioni tra gli utenti
In questo caso di studio sono presenti,
contemporaneamente, 5 reti sociali. Ogni utente crea
una propria rete sociale riguardante
riguarda
i propri interessi
e le proprie preferenze. Ipotizzando un centro di
ritrovo, come ad esempio un bar, tutti e tre gli utenti
di questo caso di studio entreranno nelle reti sociali
degli altri e potranno conoscersi o anche
semplicemente
cemente accorgersi che un “vecchio amico è in
zona”. Quando un utente, come ad esempio il nostro
Ernest Hemingway, si avvicina ad un negozio,
negozio può
entrare a far parte della rete sociale del negozio
stesso. Questo avviene ad esempio quando Ernest si
avvicina alla libreria,, al contrario non accade nulla
quando invece si avvicina al negozio di vestiti.
L’analisi semantica dei profili viene eseguita da
entrambe le entità; sia utente-manager
utente
che negoziomanager analizzano i profili dell’altra entità e
decidono se accettarla o meno nella propria rete
sociale. Tenendo Ernest e libreria come entità
esempio, si ha che Ernest entra nella rete sociale
della libreria, ma non viceversa. Conseguenza
dell’ingresso di Ernest nella rete della libreria è l’invio
della pubblicità informativa riguardante il libro di
Computer Science. Il caso prevede anche un effetto
“viral” della pubblicità. Ernest infatti memorizza la
pubblicità per un certo determinato periodo di
tempo, all’interno del quale ogni utente che entra a
far parte della rete sociale di Ernest (quindi tutti gli
utenti interessati alla lettura) riceverà tale pubblicità
(a meno che non sia già stata ricevuta
precedentemente). Un caso simile avviene anche tra
il nostro Umberto Nobile ed il negozio di vestiti.
Anch’egli riceverà la pubblicità del negozio a cui si
riferisce e la trasporterà per consegnarla a tutti i
partecipanti della sua rete sociale. Solamente
Antonino non rientra nelle reti sociali di alcun
negozio a causa delle sue preferenze sia in fatto di
lettura, che in fatto di vestiti preferiti. Come detto
prima, la ricezione della pubblicità non avviene solo
dai negozi, ma anche attraverso i partecipanti delle
proprie reti sociali. Antonino infatti potrebbe ricevere
informazioni sui libri o sugli stivali attraverso gli altri
utenti del caso di studio.
Conclusioni
Il progetto presentato in questa relazione
riguarda SAMOA, un middleware pensato per
facilitare la prototipazione di applicazioni per il social
network computing. Il middleware è stato realizzato
usando un’architettura a livelli, ogni livello è
composto dai vari servizi che permettono
all’applicazione di comunicare alle altre entità e di
gestire la rete sociale in modo semplice ed
immediato. Attualmente il servizio SME, il motore
semantico, è in fase prototipale, la versione trattata
in questa relazione tenta di sostituire questa
mancanza con un motore sintattico. Sono in corso
d’opera ulteriori miglioramenti e sviluppi nel
middleware, come ad esempio garantire una migliore
qualità di comunicazione oppure aumentare il
numero
di
servizi
messi
a
disposizione
dell’applicazione.