Middleware di Discovery Avanzato

Transcript

Middleware di Discovery Avanzato
(Tomaiuoli Giuseppe [email protected])
Un Middleware di Discovery che consenta di trovare il servizio che
realmente stai cercando in base alle caratteristiche esplicite ed implicite di
cui hai bisogno, sempre ed ovunque.
Abstract
L’idea di base è di consentire ad Utenti e Fornitori di poter, rispettivamente
trovare e rendere disponibili determinati servizi per il Discovery in base non
solo al nome, ma sfruttando tutta una serie di informazioni ritenute
necessarie o semplicemente in grado di agevolare la fruizione dei Servizi
stessi. Si è iniziato dallo studio delle soluzioni attualmente disponibili, dei
protocolli presenti, delle tecnologie a disposizione, si è scelto quale di esse
fosse più consona alle specifiche richieste, JXTA. Si è progettato e in parte
sviluppato un Middleware per il Discovery Avanzato, personalizzato, di tali
Servizi tenendo conto appunto di caratteristiche di preferenza dell’Utente, di
architettura hardware a disposizione, di caratteristiche del software in uso e
delle credenziali, tutto in corrispondenza di ciò che ogni Fornitore ritiene
rilevante per usufruire del proprio Servizio.
Introduzione
Obiettivo del progetto è la realizzazione di un
Middleware per il Discovery Avanzato di
servizi messi a disposizione dai Fornitori. Il
Discovery è Avanzato in quanto tiene in
considerazione
informazioni
aggiuntive
rispetto ai normali servizi di Discovery, come
le preferenze dell’Utente, le caratteristiche dei
dispositivi, le credenziali, la località e quanto
altro. Il Progetto si colloca nell’ambito
dell’ambiente Peer-to-Peer(P2P) che presenta
numerose soluzioni e diversi protocolli per
l’implementazione del Discovery. Tra queste
soluzioni si sono rivelate di particolare
interesse JXTA e UPnP. Nei prossimi
paragrafi si descrive il percorso di sviluppo
del progetto e le sue componenti.
Analisi e Studio di Fattibilità
Il team è composto da due soggetti: Giuseppe
Tomaiuoli
e
Simone
Masini
([email protected]). La prima
fase del Progetto consiste nell’analisi dei due
diversi protocolli e nello studio di fattibilità di
un Middleware che possa rappresentare
l’unione di essi. Ci si è presto resi conto che
la via fosse alquanto ardua da seguire in
quanto i protocolli presentano varie diversità
e alcune incompatibilità che potevano essere
superate solo impiegando risorse sia in
termini di tempo sia in termini di entità del
lavoro. Inoltre la soluzione avrebbe presentato
un overhead molto alto anche a runtime, in
quanto avrebbe richiesto diversi componenti
con funzionalità di adattatore sui vari lati del
Middleware. In accordo con il relatore
committente, l’Ing. A. Toninelli, si è giunti
alla conclusione che JXTA ha le
caratteristiche necessarie per il progetto. La
maggiore differenza, che ha influito in modo
prevalente sulla scelta è che mentre UPnP è
un protocollo proprietario di un consorzio di
aziende che per ogni scelta deve essere
interpellato, quindi meno flessibile, JXTA è
un protocollo open source che consente di
manipolare anche i sorgenti e quindi molto
più flessibile anche nella definizione dei
profili.
JXTA
JXTA è una piattaforma per l’esecuzione e la
programmazione in rete, progettata per
risolvere
alcuni
dei
problemi
dell’elaborazione
distribuita
moderna,
soprattutto nell’ambito P2P. JXTA ha tre
obiettivi principali da perseguire:
• Interoperabilità: la maggior parte dei
sistemi p2p sono costruiti per fornire
un singolo tipo di servizio (es. Napster
per la condivisine dei file musicali,
Gnutella per il filesharing generico,
Jabber
per
la
messaggistica
istantanea). In questo modo il singolo
Peer che vuole usufruire dei diversi
servizi dovrà implementarli tutti.
JXTA punta ad una compatibilità
totale, a portare nel mondo P2P ciò
che http e i browser hanno significato
per Internet.
• Indipendenza dalla Piattaforma:
molti sistemi P2P oggi offrono le loro
funzionalità o i loro servizi attraverso
un insieme di API che sono sviluppate
su un particolare sistema operativo
utilizzando uno specifico protocollo,
JXTA è progettato per essere
condiviso da tutti gli sviluppatori,
indipendentemente dal linguaggio di
programmazione
preferito,
dall’ambiente di sviluppo e dalla
piattaforma.
• Ubiquità: JXTA è progettato per
essere implementabile su qualsiasi
dispositivo elettronico: sensori, PDA,
laptop, PC, router, server ecc.
L’architettura di JXTA può essere suddivisa
in tre livelli(fig. 1):
• Core: si occupa della gestione dei
peer, della comunicazione e di altre
funzionalità di base.
• Service: si occupa di concetti di più
alto livello quali l’indicizzazione, la
ricerca e il file sharing.
• Applications: si occupa di sistemi tipo
email, memorizzazione, aste, ecc.
Figura 1 JXTA Architettura
Al più alto livello di astrazione JXTA è un
insieme di protocolli. Ogni protocollo è
definito da uno o più messaggi scambiati fra i
partecipanti al protocollo, ogni messaggio ha
un formato predefinito e può includere vari
campi di dati. I protocolli del progetto JXTA
creano uno strato di rete virtuale sopra
l’infrastruttura della rete fisica esistente,
nascondendo la topologia della rete
sottostante. JXTA consente agli sviluppatori
di applicazioni, e non solo agli amministratori
di reti, di progettare topologie di reti che
meglio soddisfino le esigenze delle loro
applicazioni(fig.2). Reti virtuali ad-hoc
multiple
possono
essere
create
e
dinamicamente mappate in una rete fisica
liberando un più ricco mondo di reti virtuali
multi dimensionali. JXTA guarda avanti dove
miliardi di servizi di rete, tutti indirizzabili
sulla rete saranno in grado di scoprire e
interagire con altri in una gestione
decentralizzata attraverso la formazione di
una moltitudine di reti virtuali. La rete
virtuale JXTA standardizza il modo in cui i
peer scoprono gli altri, si organizzano da soli
in peergroup, scoprono risorse di rete,
comunicano, e monitorizzano gli altri e i
servizi.
Figura 2 Reti Virtuali JXTA
Definizione e descrizione dei Protocolli e dei
Concetti di JXTA (Vedi Appendice A).
Architettura del MDA
Il Middleware di Discovery Avanzato (MDA)
si appoggia sopra i livelli di JXTA e ne
cattura le modalità di funzionamento e anche
l’interfaccia di accesso da parte dell’utente
per rendere il più possibile trasparente
l’utilizzo del Middleware al fine di non
traumatizzare l’utente con molteplici metodi
di accesso.
L’architettura del MDA si sviluppa attraverso
vari componenti del sistema. Si riporta una
descrizione logica che non pone nessun
vincolo sull’effettiva localizzazione dei vari
componenti. L’architettura si estende e
realizza attraverso la costituzione di tre
Gruppi
JXTA:
GroupMDAUtenti,
GroupMDAInfrastruttura,
GroupMDAFornitori. Il GroupMDAUtenti è
il gruppo in cui sono presenti i
PeerMDAUtente, cioè i peer che si occupano
della creazione e della registrazione dei profili
degli utenti, di prendere le richieste degli
utenti, completarle con le informazioni del
profilo, se presente, e inviarle al
PeerMDAInfrastruttura.
Il
GroupMDAInfrastruttura è appunto il gruppo
in cui sono presenti i PeerMDAInfrastruttura
che sono le entità che si occupano di
raccogliere le richieste dei PeerMDAUtente
ed elaborare la ricerca vera e propria
attraverso l’istanza MotoreDiRicerca. Il
GroupMDAFornitori è il gruppo in cui ci
sono i PeerMDAFornitore che si occupano
della creazione dei profili dei fornitori, della
registrazione, di prendere le richieste di
pubblicazione dei nuovi servizi e di
completarle con le informazioni del profilo, se
presente,
e
poi
rigirarle
nel
GroupMDAInfrastruttura. Sul lato Utente
sarà necessario avere l’implementazione del
MDAUtente che è la classe che consente
all’Utente di interfacciarsi al MDA con le
stesse modalità di utilizzo di JXTA standard.
Allo stesso modo sul lato Fornitore è
necessario implementare il MDAFornitore
che è l’interfaccia di accesso al MDA per i
Fornitori.
Figura 3 Architettura Logica del Middleware di Discovery Avanzato.
Supporto Legacy JXTA e altri
protocolli (UPnP)
Descrizione delle scelte progettuali inerenti il
protocollo su cui appoggiarsi, il linguaggio di
programmazione, le modalità di integrazione
con il preesistente e la compatibilità con altri
protocolli.
Si è deciso di accettare anche richieste non
complete per il discovery, queste verranno
svolte con la normale modalità di JXTA e
parimenti
sarà
compito
di
alcuni
PeerMDAFornitore quello di cercare dei
Servizi JXTA normali e pubblicarne gli
Advertisement nel GroupMDAInfrastruttura.
In questo modo saranno anche essi inglobati
nella ricerca e se nella loro descrizione ci
saranno delle caratteristiche che la
soddisfano, potranno essere ritornati come
risultati.
Questo al fine di ottenere una compatibilità
con i sistemi di JXTA preesistenti, soprattutto
per quanto riguarda i Servizi già in possesso
di un profilo, e da cui magari può essere
difficile ottenerne uno nuovo. Anche per gli
Utenti che magari essendo di passaggio in una
rete non hanno nessuna voglia di perdere del
tempo compilando un profilo per registrarsi
ed autenticarsi al MDA, almeno finché questo
non avrà uno sviluppo tale da necessitare di
pagamento o altre capability di accesso. Il
medesimo discorso può essere fatto per
rendere il MDA compatibile con altri
protocolli, per esempio UPnP, utilizzando dei
Bridge che consentano di trasferire le
informazioni contenute nella descrizione dei
Servizi in un Advertisement modello JXTA
da pubblicare nel GroupMDAInfrastruttura.
Accesso al MDA
Attraverso una Interfaccia che fa da Bridge
tra l’Utente e il Middleware in modo
trasparente all’Utente che continua ad
utilizzare le modalità di accesso al Discovery
di JXTA, con l’aggiunta di altre funzionalità
per il Discovery Avanzato.
Nella versione attuale l’Utente per accedere al
MDA non ha bisogno di particolari
installazioni o altro, semplicemente deve
istanziare un MDAUtente e trattarlo come un
normale riferimento al tradizionale discovery
di JXTA, con in più la possibilità di effettuare
altre operazioni quali la registrazione di un
profilo, la modifica del profilo , la
sottoscrizione ad una CATEGORIA(vedi
paragrafo Publish/Subscribe).
Allo stesso modo un Fornitore di Servizi non
deve fare altro che istanziare un
MDAFornitore e pubblicare le caratteristiche
del Servizio specifico. Se il Fornitore è un
utente registrato, e quindi ha un profilo
associato, oltre alle caratteristiche del
Servizio specifico saranno aggiunte quelle
generiche del Fornitore. Tali caratteristiche
sono comuni a tutti i Servizi da lui forniti, in
questo modo si eviterà di ripetere più volte un
certo numero di informazioni che possono
riguardare per esempio l’hardware e quindi
essere uguali per tutti i servizi.
Questo aspetto è totalmente speculare al
comportamento dell’Utente anche per rendere
più forte l’idea di P2P in un’uniformità di
comportamenti.
Bilanciamento del Carico del
Middleware (coordinamento e
sincronizzazione)
La struttura del Middleware è completamente
distribuita e il carico di lavoro viene
suddiviso fra i vari peer (componenti),
andando a preferire sempre quello
attualmente meno carico.
Data la totale distribuzione dell’intera
struttura del MDA, in tutte le sue componenti,
si è resa necessaria una soluzione che
consenta di coordinare e sincronizzare i peer
dello stesso tipo al fine di ottenerne una
gestione efficiente ed accurata. Per fare ciò si
è scelto come concetto di base di suddividere
al massimo il lavoro fra i peer, assegnando il
nuovo compito sempre al peer più scarico.
Questa scelta viene effettuata in tre momenti
distinti da tre distinti componenti. Il
PeerInfoService di JXTA consente di
abbinare un Monitor ad un servizio al fine di
misurarne il carico ed altre informazioni. Il
tutto viene svolto da JXTA attraverso lo
scambio di Advertisement. Il Peer che riceve
una richiesta di informazioni, misura il
proprio carico sommando il traffico di tutti i
canali correntemente attivi e pubblica tale
informazione in un Advertisement di risposta.
Il MDAUtente, quando riceve una Richiesta
dall’Utente, deve decidere a quale
PeerMDAUtente girarla. Ottiene dal Monitor
dei PeerMDAUtente le informazioni sul
carico dei peer presenti e quindi sceglie quello
meno carico, e apre una pipe con esso per
effettuare le richieste.
Allo stesso modo si comporta il
MDAFornitore quando riceve una richiesta da
parte di un Fornitore e deve scegliere a quale
PeerMDAFornitore girarla.
Infine la stessa politica è stata scelta per la
suddivisione del carico della ricerca vera e
propria per i PeerMDAInfrastruttura ai quali i
PeerMDAUtente si legano attraverso una pipe
per passare una Richiesta Personalizzata
dell’Utente(vedi sez. Personalizzazione della
Richiesta).
Gestione Profili (Fault Tolerance:
Persistenza, Replicazione)
Utilizzo di Direttori (Xindice), coordinazione
e sincronizzazione per la persistenza e la
replicazione dei direttori distribuiti. (Copia
Attiva e Copia Non Attiva, aggiornamento
ecc…). Sia per i profili degli Utenti sia per i
profili dei Fornitori.
Tutti gli Utenti e tutti i Fornitori hanno la
possibilità di creare un profilo che viene
abbinato a tutte le operazioni. I profili devono
essere memorizzati dal MDA e gestiti in
modo univoco. Ogni PeerMDAUtente
gestisce un certo numero di profili e li
memorizza in un suo direttorio. Poiché il
MDAUtente sceglie in base al carico a quale
PeerMDAUtente effettuare le richieste,
bisogna poi coordinarsi perché questo abbia
anche il profilo dell’Utente in questione. Se è
proprio un profilo presente nel suo direttorio,
non ci sono ulteriori operazione da effettuare,
se invece il profilo non è fra quelli gestiti dal
PeerMDAUtente, allora dovrà pubblicare una
richiesta di un profilo specifico, il
PeerMDAUtente che detiene tale profilo lo
passa al richiedente. Lo stesso procedimento
avviene lato Fornitore fra il MDAFornitore e i
vari PeerMDAFornitore. Al fine di ottenere
una Fault Tolerance adeguata, ipotizzando
sempre una condizione di guasto singolo, si è
deciso di avere due copie di ogni profilo. La
prima è la Copia Attiva ed è quella che dà
diritto al peer di “eleggersi” a gestore del
profilo. La seconda è la Copia Non Attiva che
viene utilizzata solo per il recovery. In pratica
quando un PeerMDAUtente non ha il profilo
nei suoi direttori, effettua la richiesta e il
gestore di tale profilo, dopo averlo inoltrato al
richiedente, passa il profilo dalla parte Attiva
del suo direttorio alla parte Non Attiva. In più
nello stesso momento comunica al Peer
possessore della Copia Non Attiva precedente
di eliminare tale copia. Nel caso in cui il Peer
richiedente non ottiene risposta, allora
effettua un’altra richiesta per la copia Non
Attiva del profilo. Quando ottiene la risposta
lui diventa il gestore di tale profilo, in questo
caso non è necessario cancellare nessuna
copia. L’implementazione dei direttori è stata
fatta utilizzando il servizio Xindice di Apache
poiché è lo stesso utilizzato da JXTA per la
memorizzazione e la gestione degli
adverstisement all’interno del suo sistema. La
classe XindiceManager mette a disposizione
tutti i metodi necessari per la gestione dei
direttori.
Personalizzazione della Richiesta
(località, dispositivo corrente,
caratteristiche HW e SW)
Estensione delle caratteristiche della
richiesta da JXTA (solo nome Servizio) a
Discovery Avanzato che tiene conto di
informazioni Statiche e Dinamiche (località,
dispositivo) riguardanti le preferenze
dell’utente e altre caratteristiche HW e SW
inglobate nella richiesta sia in modo esplicito
che implicito. Per maggiori informazioni
consultare articolo di S. Masini.
Implementazione della Metodologia
di Ricerca (matching)
Estensione del confronto a tutte le
caratteristiche definite nella richiesta e nel
profilo del Servizio. Tra queste ultime ci
saranno alcune ritenute necessarie e altre
meno rilevanti. (Profilo e Servizio). Per
maggiori informazioni consultare articolo di
S. Masini.
Access Control List o Capability
List (Al Servizio del Fornitore)
Tra le caratteristiche necessarie per accedere
ad un Servizio ci saranno anche quelle
inerenti i diritti di accesso e quindi le
credenziali che un Utente deve avere per
accedervi. Tali caratteristiche saranno prese
in considerazione per il matching.
Quando
un
Fornitore
specifica
le
caratteristiche di un Servizio, definisce anche
i parametri di accesso a tale servizio. Questo
potrebbe essere FREE se è a libero accesso,
oppure KEY, se l’utente deve essere in
possesso di una particolare KEY che gli
consenta di accedere sempre al Servizio. Per
completezza si potrebbe aggiungere una
ulteriore modalità, PAY-PER-SERVICE, che
consentirebbe all’Utente di accedere al
Servizio in questione, solo dopo averne
acquisiti i diritti in qualche modo. Tra le
informazioni della parte dinamica del profilo
dell’Utente ci sono quelle che rappresentano
appunto le credenziali dell’Utente. In questo
modo già nella ricerca dei Servizi vengono
confrontati i valori delle credenziali, evitando
per esempio di restituire ad un Utente senza
credenziali, quindi FREE, un Servizio KEY di
cui poi non potrebbe usufruire. Si è scelto di
mettere tali informazioni nella parte dinamica
in quanto potrebbe essere utile per un utente
modificare tali valori, acquisendo le
credenziali necessarie. Oppure in futuro
potrebbe essere un’informazione riguardante
un credito residuo per esempio su un Servizio
PAY-PER-SERVICE,
con
informazioni
reperite tramite carte prepagate o altro.
Publish/Subscribe
Descrizione ed Implementazione del servizio
Publish/Subscribe che consente ad un Utente
di iscriversi e quindi essere aggiornato sulle
novità inerenti una particolare Categoria di
interesse.
L’insieme dei Servizi è stato suddiviso in
CATEGORIE che consentono di ridurre il
lavoro della ricerca vera e propria del MDA.
A questo punto si è ritenuto interessante e
utile consentire all’Utente di potersi
sottoscrivere al fine di ricevere informazioni
riguardo delle novità in una sua
CATEGORIA di interesse. Per esempio nella
CATEGORIA dello STREAMING VIDEO,
potrebbe essere pubblicato un nuovo Servizio.
Il Servizio di Publish/Subscribe è stato
implementato nel seguente modo: l’Utente
effettua al MDAUtente una richiesta di
sottoscrizione ad una specifica CATEGORIA
di interesse. Il MDAUtente si metterà allora in
ascolto, nel GroupMDAUtenti di eventuali
NEWSADV che riguardino la CATEGORIA
specificata dall’Utente. Sarà poi compito
dell’Utente decidere se effettuare ulteriori
operazioni al fine di apprendere le novità,
come farsi dare per esempio l’elenco dei
Servizi di una CATEGORIA, oppure
trascurare tale notizia qualora non sia più di
suo interesse, in tal caso può cancellare la
sottoscrizione comunicandolo al MDAUtente.
È compito del PeerMDAFornitore pubblicare
un
NEWSADV
nel
GroupMDAUtenti
riguardante una specifica CATEGORIA nel
momento in cui gli arriva una richiesta di
pubblicazione di un nuovo Servizio. Allo
stesso modo pubblica un NEWSADV nel
GroupMDAUtenti se riceve una richiesta di
cancellazione di un Servizio o se ne constata
l’assenza (vedi sez. Liveness dei Servizi).
Gestione Carico e Liveness dei
Servizi
Controllo del carico del singolo Servizio per
evitare di sovraccaricare un servizio se c’è
un’alternativa e dell’effettiva presenza del
Fornitore per evitare di presentare soluzioni
non più disponibili. Modalità Push/Pull. Per
maggiori informazioni consultare articolo di
S. Masini.
Caching dei Servizi sul Lato Utente
Per evitare di far ricorso sempre alla
modalità remota del Discovery, si costituisce
una piccola cache lato Utente che tenga
traccia degli ultimi “n” risultati e che
controlli i parametri della richiesta prima su
quelli presenti in cache, per restituire in
modo veloce e leggero un risultato quando
possibile. Necessità di un protocollo di
gestione della consistenza della cache.
Raccolta di Informazioni per Stilare
Statistiche
Al fine di migliorare l’efficienza e la
funzionalità del Middleware e del Discovery
stesso, si possono prelevare in vari punti del
sistema delle informazioni riguardanti le
ricerche effettuate, le risposte ottenute, le
scelte dell’utente e qualsiasi altro tipo di
informazione sia ritenuto necessario per
stilare delle statistiche.
Configurazione e Test
Il sistema è stato interamente sviluppato in
rete
per
affrontare
direttamente
le
problematiche che si sarebbero potute
presentare
in
fase
di
installazione.
L’astrazione di rete virtuale di JXTA consente
di non curarsi particolarmente dell’effettiva
localizzazione dei Peer. Per configurare la
rete e per consentire il funzionamento minimo
del
sistema
sono
necessari
due
PeerMDAUtente, due PeerMDAInfrastruttura
e due PeerMDAFornitore, in modo da avere
un minimo di replicazione e load balancing, il
MDA funziona anche con un solo elemento
per ogni tipo, ma con la perdita delle
caratteristiche di Fault Tolerance. Ulteriori
test si sono svolti in LAB2 grazie alla
disponibilità di alcuni colleghi che hanno
acconsentito all’utilizzo dei loro account per
accedere su più macchine. Il sistema non ha
mostrato particolari problemi di tempistica e
ritardi
di
risposta,
almeno
non
significativamente incrementati rispetto al
normale utilizzo di JXTA che è per sua natura
non deterministico quanto a risultati e tempi
di accesso.
Conclusioni e Sviluppi Futuri
In questo lavoro ci si era proposti di studiare
ed implementare un Middleware che
consentisse di effettuare un Discovery
Avanzato, cioè personalizzato in base alle
caratteristiche
implicite
ed
esplicite
dell’Utente e dei dispositivi software e
hardware che ha a disposizione. Per fare ciò ci
si è basati principalmente sui profili, in questo
modo tutte le informazioni di preferenza
dell’utente e anche quelle relative alla sua
localizzazione e ad altre caratteristiche di
scelta personale possono essere inglobate
nelle sue richieste, evitando di presentare
all’Utente dei Servizi che potessero
corrispondere solo in parte all’effettiva
necessità. Dall’altro lato, attraverso i profili,
anche dei Fornitori, si consente a questi ultimi
di definire delle caratteristiche e delle
credenziali necessarie per accedere ai loro
Servizi, in modo tale da scartare a priori
quelle che sarebbero delle proposte non
effettivamente perseguibili. Per fare ciò si
sono sfruttate le capacità e le caratteristiche di
JXTA in quanto essendo un progetto opensource ed avendo una struttura slegata sia
dall’architettura sottostante che dal linguaggio
di
programmazione,
consentiva
una
manipolazione adeguata e rispettava in gran
parte le caratteristiche che ci si era posti di
raggiungere in questo lavoro. Si è voluto
avere un occhio di riguardo rispetto allo stato
dell’arte esistente per quanto riguarda i
Servizi già esistenti che implementano il
protocollo JXTA, acconsentendo di inglobarli
nelle possibili scelte, e visto che non è un
protocollo standard, si è lasciata aperta la
porta per eventuali acquisizioni anche di
Servizi di altri protocolli. Nello sviluppo del
progetto si è anche cercato di tenere in una
certa considerazione la QoS del Middleware,
monitorando e gestendo il carico di lavoro dei
vari attori e scegliendo di assegnare un nuovo
compito sempre a quello attualmente meno
carico. Si è messo a disposizione degli Utenti
anche un servizio Publish/Subscribe che
consenta loro di ottenere notifica delle novità
che riguardano aree di suo interesse. Si è
cercato anche di fornire all’Utente
informazioni sul carico dei Servizi stessi,
gestendo il Load Balancing dei Servizi stessi.
Poiché la Sicurezza è una caratteristica
fondamentale e di importanza rilevante per un
progetto di tali dimensioni, avrebbe
necessitato di una attenzione particolare. Per
motivi di tempo non è stato possibile andare
oltre l’aspetto del controllo dell’accesso,
attraverso l’autenticazione dell’Utente, però
può essere sicuramente migliorata e
sviluppata sfruttando le comunicazioni cifrate
e altro, anche le pipe sicure di JXTA stesso.
Allo stesso modo si sono lasciati agli sviluppi
futuri la possibilità di costituire una cache sul
lato Utente per consentire a quest’ultimo di
usufruire dei risultati delle sue ultime
richieste evitando di effettuare sempre delle
richieste in remoto. Per migliorare
ulteriormente l’efficienza e il lavoro del
Middleware si è pensato che potrebbero
essere raccolte delle informazioni utili a
stilare delle statistiche sull’utilizzo del
Middleware, sul tipo di richieste, sui risultati
corrispondenti e sulle scelte effettuate
dall’Utente sui Servizi effettivi, anche questo
aspetto è stato lasciato a sviluppi futuri.
Appendice
A
Definizione
e
descrizione dei Protocolli e dei
Concetti di JXTA
Dall’articolo Project JXTA 2.0 Super-Peer
Virtual Network.
I protocolli JXTA sono 6 divisi in 2 categorie:
Core Specification Protocols
Standard Service Protocols
Core Specification protocols
I protocolli di JXTA sono stati progettati per
essere implementabili su sistemi molto piccoli
con pochi componenti e comportamenti
richiesti. La funzionalità richiesta da tutte le
implementazioni è definita dai protocolli Core
Specification di JXTA. Le implementazioni
che desiderano essere JXTA compatibili
devono implementare tutti i protocolli del
Core
Specification
di
JXTA.
L’implementazione della Core Specification
di JXTA non garantisce e non fornisce il
necessario per l’interoperabilità con le altre
implementazioni di JXTA. Ci sono alcuni
comportamenti che devono essere forniti che
non fanno parte del Core Specification di
JXTA. Le implementazioni esistenti di questi
componenti sono descritti separatamente nelle
specifiche degli Standard Service di JXTA.
La Core Specification definisce due
protocolli:
Endpoint Routine Protocol ERP è il
protocollo tramite il quale un peer può
trovare la strada (una sequenza di hop)
usata per spedire un messaggio ad un
altro peer. Se un peer A vuole spedire
un messaggio al peer C, e non ci sono
percorsi diretti fra A e C, allora il peer
A ha bisogno di trovare il o i peer
intermedi per instradare il messaggio
al peer C. ERP è utilizzato per gestire
e determinare le informazioni sul
percorso. Se la topologia della rete ha
subito
cambiamenti
che
non
consentono più di arrivare a C, il peer
può usare ERP per trovare le vie
conosciute dagli altri peer per arrivare
a C costruendo così un nuovo
percorso.
Peer Revolver Protocol PRP è il
mandare una query di resolver
generica ad uno o più peer, e poi
ricevere risposte a tale query. Il
protocollo PRP permette sia la
disseminazione di query generiche ad
uno o più gestori nel gruppo sia il loro
incontro con le risposte. Ogni query è
indirizzata al nome di uno specifico
gestore. Il nome di questo gestore
definisce la particolare semantica della
query e le sue risposte, ma non è
associata ad uno specifico peer. Una
data query può essere ricevuta da
qualsiasi numero di peer nel gruppo,
eventualmente tutti, e processata in
accordo con il nome del gestore se il
nome del gestore è definito su quel
peer.
Standard Service Protocols
La Core Specification di JXTA definisce i
componenti e i comportamenti richiesti per
tutte le implementazioni di JXTA. Al fine di
creare un’implementazione completa di JXTA
ci sono alcuni componenti in più che tutte le
implementazioni dovrebbero fornire. I
protocolli Standard Service di JXTA sono
protocolli e comportamenti di JXTA
opzionali. Non è necessario che le diverse
implementazioni forniscano questi servizi, ma
si raccomanda fortemente di farlo.
Implementare questi servizi fornirà una
maggiore interoperabilità con le altre
implementazioni e una più vasta funzionalità.
La specifica dei protocolli Standard Service
definisce 4 protocolli:
Rendezvous Protocol RVP è il
protocollo tramite il quale i peer posso
iscriversi o essere sottoscrittori di un
servizio di propagazione. Insieme ai
peergroup. I peer possono essere peer
di rendezvous, oppure peer che sono
in ascolto verso peer di rendezvous.
RVP consente che i messaggi vengano
spediti a tutti gli ascoltatori del
servizio. RVP è utilizzato dal PRP per
propagare i messaggi.
Peer Discovery Protocol PDP è il
protocollo tramite il quale un peer
pubblica i suoi advertisement e trova
gli advertisement degli altri peer (peer,

peergroup, module, pipe and content).
PDP usa PRP per spedire e propagare
le richieste di discovery degli
advertisement.
Peer Information Protocol PIP è il
ottenere informazioni di stato sugli
altri peer, come state, ultime, traffic
load, capabilities ecc.. PIP usa PRP
per spedire e propagare le richieste di
informazioni dei peer.
Pipe Binding Protocol PBP è il
stabilire un canale di comunicazione
virtuale o pipe con uno o più peer.
PBP è utilizzato da un peer per
collegare i due o più lati di una
connessione (input e output pipe) ad
un endpoint fisico. PBP usa PRP per
spedire e propagare le richieste di
collegamento delle pipe.
I protocolli di JXTA sono stati progettati per
essere facilmente implementati su trasporti
asimmetrici e collegamenti unidirezionali. In
particolare molte forme di reti wireless e
mobili non forniscono le stesse possibilità per
i dispositivi per spedire e ricevere. JXTA
permette
che
qualsiasi
collegamento
unidirezionale posso essere usato quando
necessario, migliorando soprattutto la
connettività di rete nel sistema. L’intenzione
per i protocolli JXTA è di essere poco
pervasivi per quanto possibile e facili da
implementare su qualsiasi trasporto. Le
implementazioni su trasporti affidabili e
bidirezionali come TCP/IP o HTTP dovrebbe
portare ad una comunicazione bidirezionale
efficiente.
Un peer ha bisogno di implementare solo i
protocolli che richiede. Per esempio un
dispositivo potrebbe avere tutti i sui
advertisement prememorizzati, quindi non
richiede di implementare il PDP. Un peer
potrebbe usare un insieme di relay
preconfigurati per instradare tutti i suoi
messaggi,
perciò
non
richiede
di
implementare il protocollo Peer Endpoint, ma
solo di mandare i messaggi ai relay per
forwarding. Un peer potrebbe non aver
bisogno di ottenere o desidererebbe fornire,
informazioni di stato agli altri peer e quindi
non ha bisogno di implementare PIP.
Il progetto dei protocolli di JXTA cerca di
creare un insieme di protocolli che abbia un
overhead molto basso, fa poche assunzioni
riguardo al trasporto sottostante e impone
poche richieste sull’ambiente dei peer, e
possono essere utilizzati per sviluppare
un’ampia varietà di applicazioni e servizi P2P
in un ambiente fortemente non affidabile e
modificabile.
I
componenti
seguenti
forniscono
l’infrastruttura necessaria per gestire gli
advertisement:
1. ID
Con i protocolli JXTA ci sono diverse
entità che hanno bisogno di essere
univocamente identificate. Questi sono
i peer, i peergroup, le pipe ecc.. un ID
JXTA identifica univocamente ognuna
di queste entità e server con il
significato di un canonico riferimento
a tale entità. Questo componente
implementa gli ID JXTA come un
UUID a 128bit. UUID sono
autogenerati localmente utilizzando un
seme per generatore random. Un ID
JXTA è uno standard URN nel
namespace degli ID di JXTA. Glu
URN degli ID di JXTA sono
identificati dall’identificativo jxta nel
namespace
dell’URN.
Es
urn:jxta:id12345.
2. Cache Manager CM
Il cache manager è utilizzato per
cachare, indicizzare e memorizzare
persistentemente gli advertisement.
Questo componente consente la
memorizzazione
efficiente,
l’indicizzazione e il recupero degli
advertisement.
L’implementazione
JXTA 2.0 usa una versione ridotta del
database XML Xindice opensource
dell’Apache per memorizzare e
recuperare gli advertisement JXTA.
L’Xpath
che
indicizza
parte
dell’Xindice non è utilizzato. Il cache
manager consente di specificare su
quale campo un advertisement deve
essere
indicizzato.
Gli
oggetti
Advertisement
di
Java
sono
serializzati e deserializzati come
documenti XML. Il cache manager
fornisce la memorizzazione persistente
degli advertisement attraverso i
riavvii. Il cache manager implementa
un meccanismo di indicizzazione
efficiente
per
recuperare
gli
advertisement e ottimizzare il tempo di
recupero per gli advertisement di base
più comuni (peer, peergroup, module,
pipe, route, ecc.). il cache manager
controlla il decadimento degli
advertisement nella cache. Ogni
advertisement viene pubblicato in
cache con un time-to-live associato.
Gli advertisement vengono cancellati
dalla cache quando sono scaduti.
3. XML Parser
Il parser XMl consente di scandire i
documenti XML. Il parser consente la
serializzazione e la deserializzazione
degli oggetti Java in stream di caratteri
XML di input e di output. Un parser
XML leggero è stato implementato
che implementa le funzionalità di base
di un DOM XML minimizzando le
impronte “footprints”. I protocolli
JXTA usano un minimo sottoinsieme
dell’XML (namespace limitato e senza
validazione). I piccoli dispositivi non
richiedono un parser completo poiché i
messaggi di protocollo potrebbero
essere pregenerati.
4. Advertisements
Il modulo advertisement implementa
gli advertisement di base utilizzati nei
protocolli JXTA: peer, peergroup,
endpoint, rendezvous, transoprt, pipe,
module and route advertisements. Il
modulo advertisement consente ad un
oggetto Java di essere serializzato e
deserializzato in un documento XML
che rappresenta un advertisement.
I componenti seguenti gestiscono il
trasporto fisico e mantengono un
mapping fra i messaggeri virtuali e le
connessioni fisiche.
5. HTTP Transport
il trasporto http implementa il
trasporto
http
collegato
come
specificato
nelle
specifiche
di
collegamento dei protocolli JXTA. Il
trasport http è implementato come
servlet usando il server Jetty
embedded. Jetty è un server http Java
e un contenitore di servlet, così non è
necessario eseguire un diverso server
web come Apache per usare le servlet.
Il trasporto http esegue nello stesso
processo della piattaforma JXTA. Il
trasporto http fornisce la capacità di
inizializzare una connessione fra due
peer. La connessione viene utilizzata
prima per determinare l’identità logica
dei peer partecipanti. Le richieste http
GET sono usate per determinare
l’identità logica sul lato server http e
per il polling dei messaggi. Le
richieste http POST sono usate per
spedire e ricevere messaggi JXTA. Il
trasporto
http
supporta
l’attraversamento
dei
firewall
attraverso i proxy.
6. TCP/IP Transport
Il trasporto TCP/IP implementa un
collegamento di trasporto TCP/IP
come specificato nelle specifiche dei
protocolli di collegamento di JXTA.
L’implementazione JXTA 2.0 prende
vantaggio
dalle
connessioni
bidirezionali, così una singola socket
di connessione può essere utilizzata
per spedire e ricevere dati. Le
connessioni idle vengono riciclate per
consentire la gestione di un ampio
numero di connessioni su relay e
rendezvous. Un numero limitato di
connessioni fisiche ( ora 3) possono
essere stabilite alla stessa destinazione
per trasferimenti di dati simultanei. Il
trasporto
TCP/IP
può
essere
configurato per accettare messaggi di
broadcast attraverso l’IP Multicast.
7. TLS Virtual Transport
Il trasporto virtuale TLS implementa
un trasporto affidabile e sicuro end-toend sopra il trasporto http e TCP/IP.
L’implementazione
del
trasporto
virtuale TLS frammenta i messaggi in
record TLS. Un protocollo a messaggi
affidabile è usato per garantire che i
messaggi che contengono questi
record arrivino al peer di destinazione
nello stesso ordine nel quale erano
stati trasmessi. Il trasporto TLS
realizza lo scambio di key, la
negoziazione di una key di sessione
per criptare i messaggi.
8. Message
Il servizio di messaggi implementa il
formato dei messaggi binari legati a
JXTA usati quando i messaggi sono
spediti nella rete virtuale JXTA. JXTA
usa un formato binario per consentire
trasferimenti efficienti dei payload sia
binari che XML. Tutti i messaggi dei
protocolli JXTA sono rappresentati
come payload XML. I messaggi sono
costituiti da una sequenza di elementi
ordinata. Ogni elemento ha un nome
univoco, lunghezza e MIME-type. È
importante
notare
che
la
rappresentazione del formato legata a
JXTA
è
agnostica
della
rappresentazione dei dati. Qualsiasi
tipo di dato può essere spedito. Ogni
servizio,
mentre
processa
un
messaggio può aggiungere o togliere i
suoi elementi. Gli elementi dei
messaggi permettono di isolare le
diverse parti di un messaggio
consentendo una maggiore protezione.
Per esempio, il servizio di Router ha il
permesso di manipolare solo gli
elementi di Router del messaggio, ma
non può toccare nessun altro elemento
del messaggio.
9. Virtual Messenger
Il servizio di messaggistica virtuale
astrae tutti i trasporti JXTA attraverso
una comune interfaccia per i servizi
degli endpoint. Il messaggero virtuale
normalizza il comportamento tra i
trasporti asincroni e sincroni, con un
comportamento ben definito riguardo
la sincronicità tra spedire e ricevere
messaggi.
10. Endpoint Service
Il servizio endpoint implementa
l’astrazione di endpoint di JXTA, che
è usato per incapsulare trasporti di
diversi messaggi in un singolo
endpoint virtuale. Gli endpoint
forniscono l’astrazione di rete virtuale
che viene usata dai peer per
comunicare indipendentemente dalla
topologia della rete sottostante
(firewall o NAT), e dal trasporto
fisico. Il servizio di endpoint fornisce
uno smistamento uniforme dei
messaggi in ingresso e la gestione
delle risorse associate. Il servizio di
endpoint delega la propagazione nella
rete e lo stabilire una connessione al
trasporto dei messaggi appropriato. Il
servizio di endpoint fornisce anche
una bufferizzazione dei messaggi in
uscita, la cache dei messaggi in uscita
e un comportamento di messaggistica
uniforme.
11. Router
Il router implementa il servizio di
routing usato da un peer di endpoint
per scoprire e mantenere informazioni
sul percorso verso gli altri peer. Alcuni
peer potrebbero non avere connessioni
dirette, così i messaggi devono essere
instradati attraverso uno o più peer
fino alla destinazione finale. Il router
implementa
Endpoint
Routing
Protocol ERP, consentendo ad un peer
di richiedere e scoprire informazioni di
routing. Il router mantiene in memoria
una tabella di routing dei percorsi
scoperti. Ogni messaggio spedito o
ricevuto contiene un elemento di
routing usato per aggiornare le sue
informazioni di routing. Quando ha
ricevuto un messaggio, il payload del
router viene esaminato dal router per
ottimizzare le sue informazioni di
routing. Il router fornisce informazioni
di routing al servizio di Endpoint per il
trasporto dei messaggi.
12. Relay
Il servizio di Relay fornisce un
meccanismo per un peer che non è
direttamente raggiungibile per usare
un relay peer per mantenere i
messaggi finchè questi possano essere
trasportati. Il servizio di relay è usato
per attraversare i firewall e i NAT. Il
servizio di relay utilizza un
meccanismo di “lease and quota” per
gestire le code dei messaggi per i peer
edge.
I componenti seguenti definiscono
servizi opzionali per supportare i
peergroup JXTA:
13. Rendezvous Service
Il servizio di rendezvous è usato per
propagare i messaggi all’interno del
peergroup.
Questo
servizio
implementa il RendezVous Protocol
RVP. Il servizio di rendezvous
consente ai peer edge di ottenere un
contratto temporaneo per spedire e
ricevere i messaggi propagati. Il
servizio di rendezvous usa il servizio
di endpoint per propagare i messaggi.
14. Rendezvous Peer View RPV
Il servizio di RPV gestisce una lista
dei rendezvous disponibili nel
peergroup. L’RPV mantiene una
visione
decentralizzata
looselycoupled di tutti i rendezvous che
convergono
nel
tempo.
Ogni
rendezvous ha la sua propria lista
RPV.
15. Walker
Il servizio di walker fornisce un
meccanismo a plug-in per attraversare
o scorrere le RPV dei rendezvous per
propagare le query. Il walker
implementa una politica di default per
scorrere i rendezvous dal rendezvous
obiettivo dell’ SRDI iniziale nelle
direzioni up e down.
16. Resolver Service
Il servizio di resolver è usato per
spedire richieste (query/response)
generiche all’interno del peergroup
(RPC asincrono). Il servizio di
resolver implementa il Peer Resolver
Protocol PRP. Il resolver usa i servizi
di endpoint e rendezvous per fare
unicast e per propagare le richieste
all’interno del gruppo.
17. SRDI
Il servizio di SRDI distribuisce gli
indici delle risorse condivise nella rete
dei rendezvous. Questi indici possono
essere utilizzati per mandare le query
nella direzione verso la quale la query
avrà più possibilità di essere risolta,
oppure propaga i messaggi ai peer
interessati
in
questi
messaggi
propagati.
18. Discovery Service
Il servizio di discovery è usato per
scoprire e pubblicare ogni tipo di
advertisement nel peergroup (peer,
peergroup, pipe, module, ecc..). il
servizio di discovery implementa il
Peer Discovery Protocol PDP. Il
servizio di discovery dei peer usa il
servizio di resolver per spedire e
ricevere richieste di discovery. Il
servizio di discovery usa il cache
manager per fare cache e momorizzare
gli advertisement.
19. Pipe Service
Il servizio di pipe è usato per creare e
collegare i lati delle pipe ai peer di
endpoint all’interno del peergroup. Tre
tipi di pipe sono implementati, unicast
1-1, sicura, e propagazione 1-N. il
servizio di pipe usa un servizio di
resolver
di
pipe
per
legare
dinamicamente un lato della pipe ad
un peer endpoint. Il servizio di
resolver delle pipe implementa il Pipe
Binding Protocol PBP.
20. Membership service
Il servizio di membership è usato per
gestire i membri di un peergroup e
pubblica le credenziali dei membri. I
peer nuovi devono essere autenticati
prima di potersi aggiungere ad un
peergroup. Il servizio di membership
fornisce
un
framework
di
autenticazione a plug-in per supportare
vari meccanismi di autenticazione
(JAAS, LDAP).
21. PeerInfo service
Il servizio di peerInfo fornisce un
framework a plug-in per “misurare” e
monitorare i peer. I monitor di
misurazione possono essere associati
con qualsiasi servizio del peergroup
per collezionare informazioni sul
servizio. Il servizio di peerInfo
fornisce le capacità di monitoraggio
remoto per collezionare i dati misurati
su un peer remoto. Il servizio di
peerInfo
implementa
il
Peer
Information Protocol PIP.
22. PeerGroup Service
Il servizio di peergroup implementa
l’inizializzazione di un peer nel
NetPeerGroup e la navigazione nel
peergroup. Il servizio espone tutti i
servizi di base del NetPeerGroup alle
applicazioni che si sono unite al
NetPeerGRoup (discovery, resolver,
pipe, rendezvous, ecc..). Il servizio di
peergroup consente ad un peer di
creare, advertise e unirsi a nuovi
peergroup. I peergroup esportano un
insieme di servizi del peergroup che
sono rappresentati come moduli. Il
servizio di peergroup gestisce
l’infrastruttura
sottostante
per
pubblicare e caricare i moduli. Il
servizio di peergroup gestisce anche il
file di configurazione PlatformConfig.
Bibliografia
http://www.jxta.org
http://www.sun.com/software/jxta/
http://www.upnp.org
http://computer.org/internet/
http://xml.apache.org/xindice/