Middleware di Discovery Avanzato

Transcript

(Masini Simone [email protected])
Abstract
Quanti di noi in un nuovo ufficio vorrebbero
poter stampare un articolo per consultarlo
velocemente e non possono perché prima
devono configurare il proprio portatile per la
comunicazione con la stampante? Questo
articolo descrive il Middleware da noi
progettato e in parte realizzato che può
risolvere questo tipo di problemi, la ricerca e
l’utilizzo di risorse disponibili nell’ambiente
circostante con le caratteristiche del servizio
da noi espresse nel momento della ricerca.
Introduzione
Scopo di questo progetto è la realizzazione di
un Middleware di Discovery Avanzato che
consenta il recupero dei servizi in base ad una
ricerca cosiddetta avanzata. Con avanzata si
intende che a tale ricerca rispondono solo i
servizi con caratteristiche che rispecchiano le
preferenze espresse dal ricercatore ed alcune
preferenze
espresse
automaticamente
dall’architettura, come ad esempio può essere
la località.
L’ambiente è quello di una rete PeerToPeer in
cui vi sono i fornitori dei servizi e gli
eventuali
fruitori.
La realizzazione del Middleware doveva
avvenire estendendo uno o entrambi i
protocolli UPnP e JXTA che già permettono
la ricerca ma in modo molto semplice.
Analisi e Studio di Fattibilità
Il progetto è stato realizzato da Simone
Masini
e
Giuseppe
Tomaiuoli
([email protected]).
La prima fase del progetto è consistita
nell’analisi dei protocolli JXTA e UPnP,
quindi capire le caratteristiche ed i limiti di
entrambi.
In
seguito
ad
un’attenta
osservazione ci si è resi conto delle profonde
diversità di questi, dovute principalmente ai
diversi target di utilizzo. In accordo con il
committente Ing. A. Toninelli si è scelto
l’utilizzo del protocollo JXTA, in quanto più
ricco di funzionalità a noi utili, ma lasciando
disponibile l’utilizzo di un bridge per
l’eventuale integrazione con il protocollo
UPnP. A favorire la scelta su JXTA è stato
anche il fatto che è un prodotto open source,
mentre UPnP nasce da un consorzio di
aziende. Questo tipo di caratteristica si è resa
poi a noi vantaggiosa in quanto utile per la
consultazione dei sorgenti.
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: 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.
1
•
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).
2
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
3
GroupMDAInfrastruttura. In questo modo
saranno anche essi inglobati nella ricerca e,
se nella loro descrizione ci saranno delle
caratteristiche che la soddisfano, potranno
essere restituiti 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,
forse, può essere difficile ottenerne uno
nuovo. Anche per gli Utenti che, essendo
di passaggio in una rete, non hanno
nessuna intenzione 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 e 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.
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.
La presenza di profili (sia per i Fornitori,
sia per gli Utenti) fa nascere la necessità
della
persistenza
di
questi.
Le
considerazioni qui fatte si riferiscono sia al
lato Utenti sia al lato Fornitore
dell’infrastruttura. Poiché la struttura su
cui si lavora è quella di un sistema
distribuito, si è deciso di sfruttare al meglio
questa condizione: si è cercato, a tal fine,
di distribuire i profili su più nodi per
garantire il funzionamento anche a seguito
di guasto.
Nel momento in cui un utente vuole
accedere al sistema, il modulo MDAUtente
che utilizza, si lega ad un PeerMDAUtente
(PMDA1), secondo le considerazioni fatte
per l’assegnamento, tenendo conto del
carico. Affinché il PMDA1 possa svolgere
le richieste dell’utente, necessita di avere le
informazioni che risiedono nel profilo
relativo, e quindi è necessario per il
PMDA1 avere il profilo dell’utente in
locale. Essendo i profili memorizzati su
vari nodi, è improbabile che il PMDA1
abbia in locale il profilo; in tal caso questo
dovrà effettuare un discovery per ottenerlo.
Il PeerMDAUtente, in possesso del profilo
4
peer che ha in carico la copia passiva non
esista più e quindi si verrebbe a presentare
una sola copia. Considerando il fatto che,
al prossimo accesso dell’utente, quasi
sicuramente verrà creata la copia passiva,
questa scelta dovrebbe essere un giusto
compromesso.
La creazione di un nuovo profilo viene
fatta sul PeerMDAUtente più scarico e la
relativa copia viene fatta sul secondo meno
carico. Naturalmente il PeerMDAUtente,
che ha la copia attiva, deve riportare le
modifiche anche sulla copia non attiva.
L’aggiornamento della copia comporta un
piccolo costo in più sul protocollo, perché
tali modifiche si presume siano saltuarie
(aggiornamento Event-Driven).
Stato precedente:
Tra tutte le soluzioni prese in
considerazione questa è risultata la
Utente
migliore in quanto, essendo il sistema
profilo
profilo
distribuito anche in caso di guasti
attivo
non attivo
multipli, non viene compromesso
?
l’intero funzionamento perchè continua
PMDA1
PMDA2
PMDA3
ad operare anche se in modalità ridotta,
cioè in soft degradation. In più il
traffico
di rete di un peer non ha dei picchi
Stato successivo:
perché l’aggiornamento avviene nel
momento della modifica di un profilo e
Utente
quindi per ogni profilo in un momento
diverso, inoltre il backup è una
conseguenza diretta (a costo nullo se
l’utente non effettua modifiche al suo
PMDA1
PMDA2
PMDA3
profilo) dell’accesso del peer.
Xindice è la tecnologia utilizzata per la
profilo
profilo
memorizzazione dei profili sui vari peer,
attivo
non attivo
realizzato dal consorzio Apache come
strumento per la memorizzazione di dati
Se il PeerMDAUtente, a cui l’utente è
XML ed utilizzato anche dal Middleware
allacciato, non riceve una copia entro un
JXTA. Tale scelta è giustificata dal fatto
tempo prestabilito, si assume che la copia
che si devono memorizzare i profili che
attiva non sia reperibile, e quindi effettua
sono in formato XML, e Xindice nasce
un altro discovery per ottenere la copia non
proprio a tale scopo.
attiva del profilo. Una volta ottenuta, la
situazione ritornerà nella norma, ovvero
con una copia attiva ed una non attiva del
Personalizzazione della Richiesta
profilo. Tuttavia l’esistenza di una copia
(località, dispositivo corrente,
non attiva non è garantita.
caratteristiche HW e SW)
Al fine di limitare la complessità del
Estensione delle caratteristiche della
protocollo si è lasciato che ci si potesse
richiesta da JXTA (solo nome Servizio) a
trovare nella spiacevole situazione in cui il
Discovery Avanzato che tiene conto di
oggetto del discovery, (di seguito
denominato PMDA2) spedisce il profilo al
PMDA1.
Avendo fatto l’ipotesi di guasto singolo,
per garantire la tolleranza ai guasti, si è
scelto una soluzione che è praticamente a
costo nullo e che, inoltre, mantiene
inalterato il meccanismo sopra riportato.
Nel momento in cui il PMDA2 spedisce il
profilo, la sua copia diventa “non attiva” e
il profilo che ora ha il PMDA1 assume lo
stato di copia attiva; chi un tempo aveva la
copia non attiva (PMDA3) viene avvisato
dal PMDA2 affinché venga eliminata, in
quanto ora diventata superfluo.
5
informazioni
(dispositivo,
preferenze
caratteristiche
richiesta sia
implicito.
Statiche e Dinamiche
località) riguardanti le
dell’utente
e
altre
HW e SW inglobate nella
in modo esplicito che
Caratteristica di questo progetto è
l’estensione dei servizi di discovery
esistenti per poter realizzare una ricerca
avanzata dei servizi.
In base alle specifiche del committente,
oltre alla normale ricerca realizzabile in
JXTA attraverso il nome del servizio, si
doveva anche poter realizzare ricerche
complesse, ovvero tenere in considerazione
più attributi di descrizione di un servizio.
Una parte di tali attributi sono specificati
dall’utente nel momento stesso in cui
effettua la ricerca, un’altra parte sono nel
profilo dell’utente ed aggiunti alla richiesta
automaticamente dal sistema.
L’ambiente
JXTA
consente
la
realizzazione
di
advertisement
personalizzati, la cui documentazione,
peraltro, è risultata alquanto scarsa, in cui è
possibile
mettere
le
informazioni
desiderate. Qui viene riportata la
rappresentazione di un advertisement, in
formato XML, definito da noi per la
descrizione di un servizio di stampa:
<servizio type="servizio">
<DatiServizio>
<Servizio>
<Nome>Stampa</Nome>
<Attributi>
<Attributo>
<Nome>Colore</Nome>
<Valore>Bn</Valore>
</Attributo>
<Attributo>
<Nome>Tipo</Nome>
<Valore>Laser</Valore>
</Attributo>
<Attributo>
<Nome>Ppm</Nome>
<Valore>15</Valore>
</Attributo>
</Attributi>
</Servizio>
</DatiServizio>
<Nome>nome servizio</Nome>
</servizio>
La descrizione dei dati del servizio è
libera, ma la forma deve seguire quella
dell’esempio sopra riportato. Un attributo
deve avere un nome e può avere figli di
tipo ATTRIBUTI e così via. Una struttura
tanto libera, come quella riportata,
dovrebbe riuscire a descrivere tutti i
servizi, anche se questo influisce sulla
complessità della ricerca. Con questo tipo
di advertisement non è, infatti, possibile
utilizzare il normale discovery messo a
disposizione da JXTA perchè la ricerca
può avvenire solo in base al nome di un
campo, che deve essere di primo livello ed
eventualmente può avere un valore.
Purtroppo tale valore non può essere
composto, cioè non può contenere figli e
quindi tutta la struttura rappresentata sopra,
non può essere sfruttata per la ricerca.
Un esempio di una richiesta può essere
quella di seguito:
6
<richiesta type="richiesta">
<DatiServizio>
<Servizio>
<Nome>Stampa</Nome>
<Attributi>
<Attributo>
<Nome>Colore</Nome>
<Valore>Bn</Valore>
</Attributo>
</Attributi>
</Servizio>
</DatiServizio>
<DatiProfilo>
<Profilo>
<Attributo>
<Nome>Tipo</Nome>
<Valore>Laser</Valore>
</Attributo>
</Profilo>
</DatiProfilo>
<IdentificativoPeer>
peer1
</IdentificativoPeer>
<IdentificativoRichiesta>
richiesta 1
</IdentificativoRichiesta>
</richiesta>
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).
Si può vedere come la richiesta sia
suddivisa in due parti: DatiServizio e
DatiProfilo.
La parte “DatiServizio” contiene tutte le
informazioni
richieste
esplicitamente
dall’utente e in questo caso il servizio deve
essere di Stampa e deve avere un attributo
denominato Colore il cui valore deve
essere BN.
La parte “DatiProfilo” contiene le
preferenze espresse dall’utente nel
momento della creazione del profilo e, in
questo caso, l’utente esprime il fatto che il
servizio debba avere un attributo
denominato Tipo e il cui valore deve essere
Laser. Sono dette preferenze perché se
sono presenti tali dati nella descrizione del
servizio, le preferenze devono coincidere
con i relativi dati presenti nella descrizione
del servizio, ma se i dati non sono presenti
nel servizio, tale servizio viene restituito
comunque come risultato.
Le informazioni contenute in DatiServizio
“vincono” su quelle in DatiProfilo, così è
possibile che un utente possa esprime una
determinata preferenza (sarà riportata nel
profilo e andrà quindi considerata in tutte
le ricerche), ma anche optare per una
condizione diversa per una singola ricerca
(DatiServizio).
Seguendo
quindi
l’ordine
degli
avvenimenti della ricerca all’interno del
Middleware per il Discovery Avanzato, un
utente esprime la propria richiesta con un
documento XML del tipo:
<Nome>Stampa</Nome>
<Attributi>
<Attributo>
<Nome>Colore</Nome>
<Valore>Bn</Valore>
</Attributo>
</Attributi>
e quindi il PeerMDAUtente, a cui l’utente
si è collegato, aggiunge il resto delle
informazioni per fornire una richiesta
completa come espressa sopra.
Un PeerMDAFornitori pubblica, nel
gruppo
GroupMDAInfrastruttura,
un
advertisement di descrizione di un servizio
ottenuto da un fornitore che lo vuole
rendere
disponibile.
L’advertisement
pubblicato è come quello riportato in
“Personalizzazione
della
Richiesta”.
Quando un PeerMDAInfrastruttura riceve
una richiesta di discovery fa partire una
nuova istanza di MotoreDiRicerca
passandogli tutte le informazioni di cui
7
esso necessita. Questo processo esegue una
ricerca in base ad uno dei campi della
ricerca espressa dall’utente. Nel momento
in cui riceve le risposte a questo suo
discovery, le filtra utilizzando anche tutti i
campi della richiesta ed in particolar modo
con le priorità descritte sempre in
“Personalizzazione della Richiesta”. Una
volta eliminate tutte le risposte, che non
rispondono alle esigenze dell’utente, le
unisce in una unica e la pubblica sul
gruppo GroupMDAUtente. L’MDAUtente
rimarrà in ascolto di una risposta alla sua
richiesta, distinguibile da quelle degli altri
MDAUtente in base all’Identificativo
Richiesta presente nella risposta e quindi
potrà fornire all’utente i risultati della sua
ricerca.
Onde evitare che ad ogni discovery del
MotoreDiRircerca
tutti
i
PeerMDAInfrastruttura eseguano la ricerca
anche se non in possesso di informazioni
interessanti per la ricerca, si è deciso di
suddividere gli advertisement dei Servizi in
base a CATEGORIE, come descritto nella
“Gestione dei Profili dei Servizi”. Quando
un fornitore pubblica un advertisement del
suo servizio, se indica anche la categoria,
tale servizio verrà ricercato solo nella
categoria di appartenenza, sottraendo
lavoro
inutile
a
quei
PeerMDAInfrastruttura
che
non
possiedono tale categoria. Visto che le
categorie da noi messe a disposizione
possono non essere a sufficienza, esiste
una categoria generica dove vengono messi
tutti i servizi che non appartengono alle
categorie già presenti.
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. Push/Pull.
comunicare al MDA il suo stato di carico
espresso in percentuale. Un fornitore potrà
così fissarsi un tetto massimo di carico,
secondo le risorse che ha a disposizione, e
comunicare, quindi, il suo stato di carico
corrente. È lasciata al fornitore, invece, la
scelta della frequenza con cui aggiornare il
MDA. Questo perché un obbligo di
aggiornamento ad una assegnata frequenza
potrebbe causare al fornitore un’attività
eccessiva, quando in realtà il fornitore
potrebbe non aver necessità di tanti
aggiornamenti perché il suo carico rimane
costante. Una situazione opposta potrebbe
invece accadere ad un fornitore, il cui
carico è variato rapidamente, e quindi
preferisce aggiornare le informazioni
sull’MDA che lo riguardano. Dalle
informazioni del carico, l’MDA restituisce
i risultati delle ricerche ordinando quelli
con medesime caratteristiche.
Onde evitare di restituire risultati non
attendibili in risposta alle ricerche perchè
un servizio può non essere più disponibile,
un
fornitore
deve
pubblicare
periodicamente un avviso di presenza,
detto Alive. Similmente a quanto accade in
JXTA, se entro il tempo di vita concesso
all’advertisement non viene pubblicato un
messaggio di Alive, l’advertisement del
servizio viene eliminato, e quindi il
servizio risulta non più disponibile e non
verrà più restituito come risultato ad una
ricerca.
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.
Per meglio distribuire il carico tra i vari
servizi disponibili, si è deciso di rendere
disponibile al fornitore la possibilità di
8
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, come
anche le risposte ottenute, le scelte
dell’utente e qualsiasi altro tipo di
informazione sia ritenuta necessaria 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,
poiché il MDA funziona anche con un solo
elemento per ogni tipo, ma con la perdita
delle caratteristiche di Fault Tolerance. 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, 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 sarebbero potuti 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 open-source ed avendo una
struttura slegata, sia dall’architettura
sottostante, sia dal linguaggio di
programmazione,
consentiva
una
manipolazione adeguata e rispettava in
gran parte le caratteristiche che ci si era
prefissati 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 loro 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. Tuttavia, per motivi di tempo,
non è stato possibile andare oltre l’aspetto
del controllo dell’accesso, attraverso
l’autenticazione dell’Utente, però questa
9
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. Per
quanto riguarda i Servizi effettivi, anche
questo aspetto è stato lasciato a sviluppi
futuri.
10
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
protocollo tramite il quale un peer
può 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
11

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
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 protocollo tramite il quale un
peer può 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
può 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
12
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
13
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-to-end 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è
14
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 loosely-coupled 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.
15
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/
16