B3Discovery
---------------Supporto al discovery
distribuito di servizi
personalizzati
Reti di Calcolatori L-S
Prof. Antonio Corradi
A.A. 2005-06
Lavoro di
Paolo Burgio
Matr 0000197362
(Alcune) specifiche di
progetto
 Il middleware deve “consentire ad utenti con caratteristiche
variabili il ritrovamento e l’accesso a servizi eterogenei offerti da
fornitori diversi mediante diversi protocolli”
 Si prevede di “utilizzare e/o integrare protocolli di discovery
esistenti...in particolare JXTA (SUN) e UPnP”
 Disaccoppiamento
discovery
fornitori/fruitori
tramite
il
sistema
di
 Personalizzazione dell’accesso ai servizi, tramite l’utilizzo di
profili, sia per gli utenti che per i servizi stessi
 gestione dei profili
 Notifica dell’aggiunta dinamica dei servizi, anche in base agli
interessi
Architettura del sistema
 Architettura JXTA compliant, rispecchia il modello peer-topeer proposto da JXTA
 Integrazione di UPnP per il supporto alla notifica
 Separazione fra gestione dei profili dei peer e dei services
B3Discovery = Node + Registry
Architettura del sistema
Peer
Nodo
U
P
n
P
Nodo
Nodo
Info
Peer
Interfaccia NodoRegistry
Reg
Reg
Info
Servizi
Reg
Registry
Registry: overview
Nodo
Nodo
Interfaccia Nodo-Registry
 Interrogato tramite un’interfaccia
 trasparenza
 Chiamata a procedura
 asincrona, con poll object
Registry
Locale
Registry
Locale
-JXTA-
 Appoggio a JXTA
 prestazioni e QoS JXTA
 Implementativamente, è un
Active Object
 coda delle attività
 gestore della coda
 pool di thread
Registry: come è fatto
 Separazione interfaccia e
implementazione
 possibilità di distribuzione su
macchine diverse
 Interfaccia di accesso unica.
Trasparenza dalla locazione da parte
del chiamante (procedure-call)
 Definizione di Activity (attività da
eseguire) sul Registry:
 per l’uso vero e proprio
 per il controllo e il mantenimento
INSERT, DELETE, EDIT,
SEARCH, CREATE, (ecc)
VOID usa(PARAM[], POLLOBJ)
Interfaccia
“Stub”
“Skeleton”
Implement.
Registry locale: attività
1. Richiesta esecuzione attività
(asincrona)
2. Estrae un’attività
dalla coda e richiede al
pool un executor per la
sua esecuzione
Coda delle
attività
Pool degli executor
exe
c
exe
c
Gestore della
coda
exe
c
3. Esecuzione
(sincrona) dell’attività
 La coda è realizzata in modo da favorire le modifiche (INSERT,
EDIT E DELETE) piuttosto che le SEARCH
 Rischo di starvation in caso di comportamento maligno
Registry da locale a
condiviso
 I singoli Registry locali che formano il Registry condiviso creano
un JXTA PeerGroup di nome B3Registry, e chiedono di esservi
ammessi (filtraggio in base a un segreto condiviso solo dai membri)
 All’interno del gruppo, esistono tanti sottogruppi quante le
categorie dei servizi; quando un Registry locale deve operare su un
servizio di un determinato tipo, entra nel gruppo relativo e sfrutta
le funzionalità JXTA per pubblicare/modificare/cercare il servizio
 In particolare, il flow in caso del Discovery è il seguente:
 prima si opera sulla cache locale a ogni singolo peer JXTA
 in seguito, eventualmente ce ne fosse bisogno, si opera in
remoto tramite un messaggio propagato a tutti i peer del gruppo
Registry condiviso: attività
PROBLEMA: JXTA non supporta il concetto di “modifica” e
“cancellazione” di un servizio, ma solo di “inserimento” e
“ricerca”
 Bisogna fare in modo che tutti i tipi di Activity in un
determinato Registry locale vengano propagati a tutti i membri
 Inserimento di un modulo per la gestione dei profili dei
servizi, tramite la propagazione delle Activity a tutti i membri
del gruppo Registry
 Tramite Multicast Pipe JXTA (servizio integrato in JXTA)
Le Pipe JXTA
“Pipes are communication channels for sending and receiving messages,
and are asynchronous. They are also uni-directional, so there are input
pipes and output pipes”
[Gong, Li (2001) Project JXTA: A Technology Overview - www.jxta.org]
 Realizzate a livello JXTA Services; pubblicate (ovviamente)
tramite un Advertisement
 Per chi vuole aprire una pipe ex-novo: la crea e la lega ad un
ADV (servizio offerto)  publish JXTA
 Per chi vuole aprire una pipe esistente: discovery (JXTA) dell’ADV
della pipe  lo usa per crearla
 Possibilità di Pipe Multicast, del tipo uno-a-molti
 Multicast Pipe per un Service: emuliamo il molti-a-molti: un solo
ADV, contenuto nell’ADV del servizio  (logicamente) una sola Pipe
ActivityProfile Service
 Costruito sulle Pipe Multicast JXTA, relative al Servizio
ActivityProfile
 Condivisione dei profili dei Servizi  Condivisione delle
attività di EDIT e DELETE (per ora)
Registry
Locale
Registry
Locale
Registry
Locale
Create
all’avvio
dell’ ActivityProfile
Service
Registry: Poll Object e
sincronicità
PROBLEMA: il Registry è asincrono per sua stessa natura,
l’implementazione di JXTA processa sul nodo le richieste in
modo sincrono (una sola coda per le richieste, un solo gestore)
Request
(Activity)
Node
1
Executor
2 wait()
4 getResult()
Response
(Result)
3
Poll Obj
Response
(Result)
 attesa (sul Poll Object) dopo la richiesta (lo uso in maniera
sincrona)
Architettura UPnP
Root Device
Control point 1
advertise
search
Control point 2
advertise
advertise
M
U
L
T
I
C
A
S
T
Service1
-stateVar1
-stateVar2
Nested Device
Service 1
Service 2
Figura: schema della rete UPnP: Devices, Control Points,
Services
- www.upnp.org -
Il sistema di notifica
Deve essere possibile lo notifica dell’aggiunta/rimozione di un
servizio (se possibile comunicandone l’identità) di una o più
categorie specificate, anche dinamicamente
 UPnP prevede un sistema ad eventi per la notifica del cambio
del valore delle variabili di stato associate a un Service
 Possibilità di modificare dinamicamente il proprio interesse
 Utilizzo del multicast, integra il protocollo GENA (General Event
Notification Architecture)
 Nome della variabile  Nome della categoria
 Invio anche del valore attuale della variabile  informazioni
aggiuntive (ID del servizio??)
Il sistema di notifica
 Modulo parallelo al Registry-Node, non integrato in esso
 rete UPnP più “snella” e reattiva
 non congestioniamo la (già abbastanza carica) rete JXTA
 Gli interessi dei peer sono tenuti in memoria dal supporto UPnP
stesso: si è preferito separarli dal profilo per non aumentarne la
dimensione e quindi l’overhead sulla rete JXTA
 sarebbe utile (ad esempio, a fini statistici) poterli legare al
profili, ma come detto comporterebbe un aumento di dimensioni
degli stessi
Conclusioni e sviluppi
futuri
 L’architettura proposta è valida, robusta e scalabile
 Il sistema presenta grossi limiti prestazionali dovuti all’utilizzo di
JXTA, che per la comunicazione utilizza una semantica best-effort,
decisamente poco soddisfacente per gli obiettivi del progetto, e per
l’elevato numero di messaggi scambiati (in formato XML) e la loro
dimensione
 Il Sistema di Notifica potrebbe anche essere implementato come
servizio JXTA, e nel realizzare il sistema si è preferito tenere aperta
anche questa possibilità.
 overhead nella reta JXTA, pertanto è (all’attuale stato dell’arte)
sconsigliabile
 Per alleggerire la rete JXTA, si potrebbe utilizzare il modulo per la
gestione dei profili, oltre che per EDIT e DELETE, anche per INSERT
(ed eventualmente per le SEARCH)
 perdita di “struttura” JXTA ????