		MokaByte Numero 31 - Giugno 1999

		Jini
	di Gabriele Baroni Marco Masotti

Un sistema Jini e' un sistema distribuito basato su tecnologia Java, dove sono messi a disposizione gli strumenti per riunire hardware e software in una federazione per la mutua esclusione dei servizi. In pratica Jini e' un insieme di 48kbyte di classi Java.
Grazie a Jini e' possibile condividere servizi e risorse, rendere semplice l'accesso alle risorse da qualsiasi punto della rete, semplificare tutto sommato la vita agli amministratori.
Trattando Jini analizzeremo le politiche con cui la Sun ha affrontato i problemi tipici dei sistemi distribuiti.

Ambiente

Ogni dispositivo collegato deve essere dotata di una JVM, hardware o software, o di poterne utilizzarne una, anche condivicendola con altri. Ad esempio una nuova fotocamera digitale dotata di una JVM su chip o una vecchia stampante che utilizza quella del computer a cui e' collegata tramite la classica porta parallela. Sebbene Jini, utilizzando il protocollo TCP-IP, possa funzionare anche su reti a larga scala, e' congliabile l'utilizzo in ambiente LAN dove la maggior velocita' di trasmissione lo rende efficiente. La scelta del linguaggio di programmazione con il quale sviluppare codice per Jini e' indifferente, a patto che il compilatore generi Bytecode Java.

Concetti chiave

Una rete Jini e' basata sul concetto di servizio che e' un'entita' utilizzabile da un utente, un programma o un altro servizio. Esempi di servizi sono una computazione, l'archivio di dati, un canale di comunicazione, un dispositivo hardware o un altro utente. Un sistema Jini quindi non deve essere pensato come un insieme di server e client, ma bensi' come una federazione di membri che condividono i servizi di cui dispongono.
Una delle grosse novita' introdotte da Jini e' la completa dinamicita' e automazione dei collegamnti e scollegamenti dei dispositivi.
Cio' e' possibile grazie al servizio alla base di un sistema Jini: il lookup service, che mappa le interfaccie delle funzionalita' rese disponibili dai servizi della rete con gli oggetti che implementano tali servizi, rendendo inoltre possibile aggiungere informazioni riguardo tali servizi, per permettere agli utenti una ricerca piu' accurata.
Il lookup e' un servizio come tutti gli altri, per cui e' possibile gestire in maniera gerarchica piu' lookup service all'interno di una stessa rete; cio' rende un sistema Jini estremamente scalabile.
Naturalmente ne' un nuovo servizio, ne' colui che lo introduce in una rete jini, sono tenuti a conoscere gli indirizzi dei lookup della rete. Per questo motivo i lookup service gestiscono gruppi di entita' referenziabili (es. laboratorio.unibo.it oppure cucina.casamia.bologna.it). In questo modo i futuri menbri della rete dovranno specificare solamente il nome del gruppo cui saranno interessati.
Un servizio e' registrato presso un lookup service tramite due protocolli: "discovery" e "join" .

Discovery e Join

Il protocollo di discovery e' basato sul protocollo UDP ed e' in realta' composto da due protocolli minori: il multicast request protocol e il multicast announcement protocol che ora descriveremo in dettaglio.
Il multicast request protocol viene utilizzato dalle nuove entita' per localizzare il o i lookup service; e' attivo solo per un periodo limitato, dopo il quale l' entita' si mette in ascolto di eventuali multicast lookup announcement. Visto in dettaglio, l' entita' non fa altro che lanciare un client con il compito di ricercare un lookup ed un server per gestire eventuali risposte, mentre il lookup lancia un server per gestire i multicast che lo interessano ed un client che passa al nuovo menbro della federazione i dati per eseguire la registrazione (indirizzo del lookup, interfaccia con i metodi da chiamare per registrarsi, etc..).
Qui di seguito riportiamo lo schema di un tipico pacchetto generato da un multicast request protocol:

COUNT	TYPE	DESCRIPTION
1	int	protocol version
1	int	port to connect to
1	int	count of lookups heard
Variable	net.jini.core.lookup.ServiceID	lookups heard
1	int	count of groups
Variable	java.lang.string	groups

Ogni pacchetto come quello descritto deve avere una dimensione < 512 byte; in caso contrario se ad eccedere e' il campo lookup heard, si tralasceranno alcuni valori (risponderanno al multicast request protocol anche lookup service presso i quali il servizio e' gia' registrato), se invece e' il campo groups, il pacchetto verra' spezzato (altrimenti il servizio non entrerebbe a far parte di alcuni dei gruppi specificati).
Per dare un' idea quantitativa del protocollo di multicast request, nelle specifiche della Sun si consiglia una durata di questo protocollo di circa 5 secondi per un massimo di sette messaggi inviati.
Il multicast announcement protocol viene utilizzato dal lookup service per annunciare ai menbri della rete la propria presenza. Esso e' utile sia quando si installa un nuovo lookup o quando questo torna ad essere attivo dopo un crash. Questo protocollo e' sempre attivo durante tutta la vita del lookup service.
Piu' in dettaglio, il lookup service esegue un client che invia un messaggio di announcement ogni 120 secondi e un server per gestire le eventuali risposte, mentre una nuova entita' mantiene un elenco dei lookup service conosciuti, lancia un multicast announcement server che rimane in ascolto e risponde solo se viene a conoscenza di un lookup sconosciuto che gestisce un gruppo cui e' interessata.
Il protocollo di join invece utilizza l' unicast discovery protocol, e consiste nella registrazione vera e propria del nuovo servizio presso il lookup, una volta che questi sono venuti a conoscenza dei reciproci indirizzi tramite il discovery protocol.
Dopo essersi registrato presso il lookup service, un servizio deve mantenere alcune informazioni in memoria non volatile per evitare che ad ogni blackout o ad ogni crash, la procedura di discovery debba essere rieseguita: il proprio service ID (assegnato dal lookup), un insieme di attributi utili per le connessioni al lookup e l' insieme dei gruppi a cui il servizio partecipa. Tali informazioni verranno cancellate solo nel caso che il servizio venga trasferito su di un' altra rete.

Il lookup service

Si tratta, come gia' detto, di un servizio che mantiene un elenco centralizzato e su memoria permanente dei servizi disponibili nei gruppi da lui gestiti. In realta' non si tratta solo di un elenco, ma delle copie delle interfaccie dei servizi disponibili. In questo modo un client che richiedera' l' utilizzo di un particolare servizio al lookup, ricevera' in risposta l' interfaccia del servisio stesso, attraverso la quale lo utilizzera' direttamente.
Naturalmente non e' possibile per l' utente conoscere il nome di tutte le interfaccie, cosi' si e' deciso di referenziare i vari servizi per tipo; in questo modo se si ha la necessita' di stampare, l' utente ricevera' una lista di tutte le interfaccie di tipo print (ad esempio), nella quale scegliera' la stampante a lui piu' congeniale.
Oltre alle interfaccie poi, e' possibile mantenere presso il lookup gli attributi dei vari dispositivi (ad esempio la risoluzione della nostra stampante) e, aggiornandoli opportunamente, notificare eventuali guasti o messaggi di errore.

Il leasing

Alla base della dinamicita' di un sistema Jini vi e' l'uso del leasing per la gestione di tutti i servizi. Semplicemente ogni assegnazione di un servizio ad un determinato utente e' limitata nel tempo, tale limite e' determinato all' invio della richiesta di utilizzo. Un utente dopo aver rintracciato il servizio tramite il lookup service, richiede direttamente al gestore di tale servizio di poterlo utilizzare per un certo periodo di tempo espresso in millisecondi. Il gestore puo' a questo punto assegnare semplicemente la risorsa per il periodo richiesto, per uno minore o addirittura negarlo. In quel caso stara' all'utente decidere se riprovare piu' tardi o lasciare perdere.
Al termine del periodo assegnato il leasing svanisce e il gestore e' libero di riassegnare la risorse; l'utente pero' ha una prelazione sul rinnovo del leasing (nel caso non abbia finito con tale risorsa), anche per il rinnovo il gestore puo' comportarsi liberamente.
Nel caso opposto, in cui un utente abbia una risorsa assegnata ma che abbia finito di usarla, puo' liberarla aznitempo.
Non possono essere assegnati leasing per un periodo infinito di tempo, mentre e' possibile avere leasing sbloccabili solo dall'assegnatario.
Il tempo da parte del gestore e del richiedente viene contato a partire da due momenti diversi, il primo quando assegna la risorsa, il secondo quando ne richiede l' utilizzo. Capiamo quindi quanto sia importante la velocita' della rete in un sistema Jini: cosa succederebbe se un gestore assegnasse per un determinato tempo un risorsa e la notifica giungesse, per ritardi dovuti alla rete, dopo un tempo maggiore? Il richiedente ottiene l' utilizzo, ma quando questo gli viene notificato, il quanto di tempo concessogli e' minore di quello calcolato al momento della richiesta; a questo punto il leasing viene considerato scaduto e la risorsa liberata senza essere stata utilizzata.
Sono pero' evidenti i grandi vantaggi introdotti dall'utilizzo dei leasing. Le risorse vengono sbloccate dal proprio gestore, quindi non abbiamo problemi nel caso del crash di un oggetto client. Le risorse instaurano un leasing anche con il lookup service per essere registrate, devono quindi fare la renew di tale contratto periodicamente; nel caso vengano scollegate dalla rete per un qualsiasi motivo decade semplicemente il leasing e il lookup service le toglie dalle liste dei servizi disponibili.

Transaction

Un sistema distribuito neccesita di alcuni strumenti per poter portare a termine in maniera consistente computazioni che coinvolgono piu' partecipanti remoti. Il problema dell-atomic commit e' in risolto in jini attraverso un'implementazione del protocollo di "two phase commit" (2PC). Una transazione viene creata da un client (che puo' o meno partecpare ad essa) ed eseque tre operazioni:

instaura un leasing di durata minore o uguale a quella stimata per la transazione;
lancia un oggetto coordinatore per la gestione del 2PC;
invia un messaggio ai partecipanti cui e' interessato per avvertirli dell' esistenza della transazione.

I partecipanti, nel caso accettino di prendere parte alla transazione, avviano un operazione di join (non ha nulla a che fare con il protocollo di join gia' descritto) verso il coordinatore, passando come parametro l' id della transazione ottenuto dal client. Una transazione appena creata si dice attiva e i partecipanti possono fare join solo in questa fase. Appena il client lo ritiene opportuno invia un messaggio di commit al coordinatore, che passa alla fase di voting. In questa fase i partecipanti possono raggiungere gli stati di: abort, not changed (il partecipante vuole conosce l'esito della transazione ma non vuole parteipare attivamente ad essa), prepared (pronto per il commit). La transazione comunque fallisce nel caso di un abort o che il leasing scada. Vengono gestiti da questo protocollo anche i casi in cui un partecipante non sappia lo stato del coordinatore (lo puo' richiedere) e quello in cui avvenga un crash del sistema, dove grazie al salvatoaggio degli stati del coordinatore e dei partecipanti e' possibile fare recovery.

Architettura dei dispositivi

I requisiti che ogni dispositivo deve avere per poter funzionare in una rete Jini sono: un processore, memoria volatile dove eseguire gli oggetti, memoria non volatile dove manteere un interfaccia di dialogo (un oggetto che implenti il device driver), le classi di Jini e le informazione della rete (es. indirizzi dei lookup service). Esempi di dispositivi possono essere una stampante di nuova concezione dotata di di JVM, qualche Mb di RAM e una EPROM, oppure una stampante attuale, collegata alla porta parallela del nostro PC, di cui sfrutta la memoria e le capacita' di calcolo. Per questi ultimi dispositivi e' in progetto la realizzazione di cosiddete "jini device bay", che ad un costo meno rilevante rispetto a quello di un pc ci daranno la possibilta' di collegare ad una rete Jini alcuni dispositivi a basso costo o di vecchia concezione. Questa device bay con opportune modifiche potra' rendere alla rete il servizio di gateway verso e da altre architetture di rete.

Fault tollerance, sicurezza e affidabilita'

Vogliamo concludere l' articolo spendendo due parole a favore di questi due problemi, che sono endemici quando si parla di architetture di rete.
Essendo jini basato su java ed in particolare sulle classi di RMI (remote metod invocation), trattandosi di un ambiente distribuito, e' palese che questi non sia dotato di meccanismi di fault tollerance, in quanto le RMI ne sono completamente prive. Questo problema viene in parte superato grazie all' introduzione del leasing e dei protocolli di discovery e join, che consentono ad una rete jini di superare ad esempio eventuali partizionamenti.
Inoltre nel caso che una rete rimanga priva di lookup, l' architettura jini continua a funzionare, poiche' i client che necessitano di un servizio possono spacciarsi per lookup, lanciando un multicast announcement protocol, ed attendere che un servizio del tipo richiesto invii la propria interfaccia.
In altri casi la soluzione dei problemi di fault tollerance ed affidabilita' viene lasciata al programmatore. Un esempio e' dato dalle transazioni in cui, essendo necessarie chiamate atomiche, i programmatori si sono preoccupati di scrivere metodi che garantiscano tale funzionalita'.
Infine in jini prevede un meccanismo di sicurezza attraverso delle access control lists (gruppi in linux) mantenute presso i vari servizi.



	MokaByte rivista web su Java MokaByte ricerca nuovi collaboratori Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it