B3Discovery Supporto al discovery distribuito di servizi personalizzati Lavoro di Paolo Burgio Matr Reti di Calcolatori L-S Prof. Antonio Corradi A.A

(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 fornitori/fruitori tramite il sistema di discovery 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-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

Architettura del sistema UPnPUPnP Info Servizi Reg Nodo Info Peer Reg Nodo Reg Nodo Peer Registry Interfaccia Nodo- Registry

Registry: overview Registry Locale Nodo Registry Locale Nodo Interfaccia Nodo-Registry Appoggio a JXTA  prestazioni e QoS JXTA Interrogato tramite un’interfaccia  trasparenza Chiamata a procedura  asincrona, con poll object Implementativamente, è un Active Object  coda delle attività  gestore della coda  pool di thread -JXTA-

Registry: come è fatto Interfaccia Implement. VOID usa(PARAM[], POLLOBJ) “Stub” “Skeleton” Separazione interfaccia e implementazione  possibilità di distribuzione su macchine diverse Definizione di Activity (attività da eseguire) sul Registry:  per l’uso vero e proprio  per il controllo e il mantenimento Interfaccia di accesso unica. Trasparenza dalla locazione da parte del chiamante (procedure-call) INSERT, DELETE, EDIT, SEARCH, CREATE, (ecc)

Registry locale: attività 1. Richiesta esecuzione attività (asincrona) Coda delle attività 2. Estrae un’attività dalla coda e richiede al pool un executor per la sua esecuzione Pool degli executor exe c 3. Esecuzione (sincrona) dell’attività Gestore della coda 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à 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) PROBLEMA: JXTA non supporta il concetto di “modifica” e “cancellazione” di un servizio, ma solo di “inserimento” e “ricerca”

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 - 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 Create all’avvio dell’ ActivityProfile Service

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) Registry: Poll Object e sincronicità attesa (sul Poll Object) dopo la richiesta (lo uso in maniera sincrona) wait() 4 getResult() Node Executor Poll Obj Request (Activity) Response (Result) !

Architettura UPnP Root Device Control point 1 Service1 -stateVar1 -stateVar2 Nested Device Service 1 Service 2 Control point 2 advertise MULTICASTMULTICAST search Figura: schema della rete UPnP: Devices, Control Points, Services - -

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

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 Il sistema di notifica

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 ????