In questo articolo sono descritti i protocolli di discovery e join necessari ai servizi per cooperare con l'ambiente Jini. Vengono inoltre illustrate le modalità di ricerca dei servizi, modalità che consentono ai client di trovare il servizio più rispondente alle loro necessità.
Introduzione
Benvenuti alla quarta ed ultima puntata della serie sulle tecnologie di Jini. In questo articolo si parla dei protocolli di discovery e join.
Come in tutti gli ambienti di computazione distribuita, il meccanismo per trovare i servizi di cui si ha bisogno rappresenta un elemento fondamentale ed irrinunciabile.
La modalità con cui in Jini si cercano i servizi è piuttosto diversa dal modo in cui in RMI o in CORBA si individuano oggetti remoti. In questi due ambienti, infatti, gli oggetti che si vogliono rendere visibili si registrano presso un servizio di nomi fornendo un nome che li individua in maniera univoca.
Il database dei servizi disponibili in un djinn, cioè un insieme di servizi Jini logicamente correlati e spesso anche fisicamente contenuti dentro la medesima intranet, è invece concepito per consentire la ricerca di un servizio non in base ad un nome che il client deve già conoscere, ma in base ai bisogni che tale client si trova ad affrontare.
L'articolo porta l'esempio della stampa di un documento PostScript: il client cercherà nel djinn i servizi in grado di stampare e, fra questi, ne sceglierà uno capace di interpretare il formato richiesto.
Lookup service e gruppi
Il database dei servizi presenti in un djinn è distribuito in un insieme di servizi Jini detti lookup service.
Non esiste fra i lookup service alcun tipo di relazione gerarchica, al contrario di quanto accade ad esempio per il servizio di nomi di Internet.
Il numero dei lookup service presenti in un djinn deve essere deciso dal djinn administrator, raggiungendo un compromesso fra disponibilità del servizio di registrazione e prestazioni complessive.
Un servizio Jini, quando attivato, ha la libertà di registrarsi presso uno, diversi o tutti i lookup service di un djinn; analogamente un client può cercare un servizio presso uno o più lookup service.
Questa fluidità e la mancanza di punti di centralizzazione rendono Jini particolarmente adatto a sistemi molto dinamici in cui i servizi vengono attivati e disattivati di frequente e in cui anche la topologia della rete possa variare.
I servizi di un djinn sono suddivisi in gruppi; i nomi dei gruppi sono semplici stringhe destrutturate, anche se le specifiche della Sun consigliano di assegnare nomi tipo DNS, ad esempio eng.sun.com.
Discovery e Join
Dato un oggetto, sia esso un client o un servizio, affinché possa interagire col djinn è necessario che ottenga uno o più riferimenti ai lookup service; ciò è possibile grazie al protocollo di discovery.
Un servizio, una volta ottenuto un riferimento ad un lookup service, può unirsi al djinn. Questo comporta però anche delle responsabilità da parte del servizio, descritte nel protocollo di join.
Proprio questa fase distingue maggiormente Jini dagli altri protocolli di computazione distribuita: a questo punto il servizio Jini, come parte della registrazione, consegna ai lookup service che compongono il djinn un proxy di sé stesso. Questo proxy verrà successivamente consegnato dai lookup service ai client che ne fanno richiesta.
I client dovranno usare questo proxy per interagire col servizio Jini.
La caratteristica di Jini che consente di iniettare una classe proxy nel codice del client è quella che lo rende adatto ad avere come servizi delle network appliances, cioè elettrodomestici o dispositivi in grado di collegarsi alla rete.
Il proxy diventa quindi una sorta di driver remoto del servizio: è l'unico a conoscere il protocollo di comunicazione del servizio che rappresenta e al momento della registrazione sul lookup service deve essere inizializzato in modo da sapere ritrovare il proprio servizio quando sarà attivato sul lato client.
Il protocollo di discovery
Il protocollo di discovery consente di trovare i lookup service presenti in un djinn. La Sun fornisce due classi, LookupDiscovery e LookupLocator, che ne nascondono l'implementazione.
Il protocollo di discovery si compone di tre sottoprotocolli:
Multicast Request ProtocolMulticast Announcement ProtocolUnicast Discovery Protocol
Nel primo caso una discovery entity manda un datagramma UDP multicast a una well-known port; i lookup service in ascolto rispondono attivando un collegamento TCP con la discovery entity. Questo protocollo va usato per scoprire lookup appartenenti ad una intranet.
Il Multicast Announcement Protocol serve invece a monitorare l'evoluzione dello stato del djinn: quando un lookup service si attiva comincia a mandare ad intervalli regolari un datagramma UDP multicast che annuncia la propria esistenza.
Nel caso in cui una discovery entity voglia connettersi ad un particolare lookup service può usare l'Unicast Discovery Protocol. In questo caso deve conoscere la locazione del lookup service e si collega usando una connessione TCP, ricevendone il riferimento. Poiché il trasporto è TCP, questo protocollo può essere usato anche per scoprire lookup service lontani, dispersi in Internet.
Conclusioni
Con discovery e join si chiude il quadro delle tecnologie fondamentali di Jini.
L'idea più importante è che la scoperta dei servizi non si basi su nomi statici ma su bisogni, gruppi e proxy distribuiti dai lookup service. È proprio questo modello, flessibile e fortemente dinamico, a distinguere Jini dai paradigmi distribuiti più tradizionali.
