B3Discovery ---------------- Supporto al discovery distribuito di servizi personalizzati

1
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

2
(Alcune) specifiche di progetto

• Il middleware deve consentire ad utenti con
  caratteristiche variabili il ritrovamento e
  laccesso 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 fornitori/fruitori tramite il
  sistema di discovery
• Personalizzazione dellaccesso ai servizi,
  tramite lutilizzo di profili, sia per gli utenti
  che per i servizi stessi
• gestione dei profili
• Notifica dellaggiunta dinamica dei servizi,
  anche in base agli interessi

3
Architettura del sistema

• Architettura JXTA compliant, rispecchia il
  modello peer-to-peer proposto da JXTA
• Integrazione di UPnP per il supporto alla
  notifica
• Separazione fra gestione dei profili dei peer e
  dei services

B3Discovery Node Registry
4
Architettura del sistema
5
Registry overview

• Appoggio a JXTA
• ? prestazioni e QoS JXTA
• Interrogato tramite uninterfaccia
• ? trasparenza
• Chiamata a procedura
• ? asincrona, con poll object
• Implementativamente, è un Active Object
• ? coda delle attività
• ? gestore della coda
• ? pool di thread

-JXTA-
6
Registry come è fatto

• Separazione interfaccia e implementazione
• ? possibilità di distribuzione su macchine diverse

VOID usa(PARAM, POLLOBJ)
Interfaccia

• Interfaccia di accesso unica. Trasparenza dalla
  locazione da parte del chiamante (procedure-call)

• Definizione di Activity (attività da eseguire)
  sul Registry
• ? per luso vero e proprio
• ? per il controllo e il mantenimento

Implement.
INSERT, DELETE, EDIT, SEARCH, CREATE, (ecc)
7
Registry locale attività
1. Richiesta esecuzione attività (asincrona)
Gestore della coda
2. Estrae unattività dalla coda e richiede al
pool un executor per la sua esecuzione
Coda delle attività
Pool degli executor
3. Esecuzione (sincrona) dellattività
exec
exec
exec

• 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

8
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)
• Allinterno 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

9
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)

10
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) dellADV 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 nellADV
  del servizio ? (logicamente) una sola Pipe

11
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)

Create allavvio dell ActivityProfile Service
12
!
Registry Poll Object e sincronicità
PROBLEMA il Registry è asincrono per sua stessa
natura, limplementazione di JXTA processa sul
nodo le richieste in modo sincrono (una sola coda
per le richieste, un solo gestore)
1
2
wait()
4 getResult()
3

• attesa (sul Poll Object) dopo la richiesta (lo
  uso in maniera sincrona)

13
Architettura UPnP
Figura schema della rete UPnP Devices, Control
Points, Services - www.upnp.org -
14
Il sistema di notifica
Deve essere possibile lo notifica
dellaggiunta/rimozione di un servizio (se
possibile comunicandone lidentità) 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??)

15
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 loverhead sulla rete JXTA
• ? sarebbe utile (ad esempio, a fini
  statistici) poterli legare al profili, ma come
  detto comporterebbe un aumento di dimensioni
  degli stessi

16
Conclusioni e sviluppi futuri

• Larchitettura proposta è valida, robusta e
  scalabile
• Il sistema presenta grossi limiti prestazionali
  dovuti allutilizzo di JXTA, che per la
  comunicazione utilizza una semantica best-effort,
  decisamente poco soddisfacente per gli obiettivi
  del progetto, e per lelevato 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 è
  (allattuale stato dellarte) 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 ????