[correva l'anno 2001]

In questo articolo viene illustrata la tecnologia Jini sviluppata da SUN.

Java: “write once run anywhere”
Jini: “write once run from anywhere”

Quanti oggetti elettronici riempiono le nostre case? MOLTISSIMI, dal Personal Computer al videoregistratore, dai telefoni alle stampanti, dalla televisione al forno, dalla lavatrice al …

Sono in grado di comunicare tra loro? NO, ognuno lavora in moto autonomo, ma il passo successivo all’invasione deve essere quello dell’interconnessione: visto che nella casa sono disponibili un gran numero di oggetti digitali, perché non pensare ad un qualche sistema di comunicazione in grado di far loro scambiare dati e servizi?

La sfida è proprio questa: permettere ai vari device che ci circondano, di comunicare fra loro.
SUN Microsystem ha accettato questa sfida presentando nel gennaio del 1999 Jini, una tecnologia che si basa su Java e su TCP-IP e che, utilizzando protocolli di rete, permette di mettere in comunicazione oggetti differenti fra loro, dove ognuno mette a disposizione dei servizi per tutti coloro che ne abbiano necessità.
In una comunità Jini i servizi possono essere dinamicamente aggiunti o tolti, le applicazioni possono poi ricercare tali servizi ed usarli, senza averne a priori una specifica conoscenza.
Ad esempio una stampante, nel momento in cui si connette ad una comunità Jini, prima si presenterà e poi esporrà la sua interfaccia, contenente per esempio il servizio print. Se successivamente un frigorifero Jini dovesse aver bisogno di stampare una pagina con dei dati relativi al proprio funzionamento, sarà sufficiente che vada a ricercare chi nella comunità mette a disposizione il servizio print e poi richiederne l’esecuzione.

1. Servizi

Il concetto più importante all’interno dell’architettura di Jini è quello di servizio. Un servizio è un’entità che può essere usata da una persona, da un programma, o da un altro servizio. Un servizio può essere computazione, memoria, un canale di comunicazione, un dispositivo hardware, o un altro utente. Due esempi dei servizi sono: stampare un documento e tradurre un documento da un formato ad un altro.

Un sistema di Jini non dovrebbe pensarsi come un insieme di clients e servers, o utenti e programmi, o programmi e archivi, piuttosto, un sistema Jini consiste di servizi che sono messi insieme per il compimento di una particolare operazione. I servizi possono usare altri servizi e un client di un servizio può in essere anch’esso un servizio con altri clients, la natura dinamica di un sistema Jini permette ai servizi di essere agiunti o ritirati in qualunque momento. Jini fornisce i meccanismi per la costruzione, la ricerca, la comunicazione e l’uso dei servizi del sistema distribuito. Esempi di servizi sono: dispositivi quali le stampanti, i monitor, o i dischi; software quali applicazioni o programmi di utilità; le informazioni come le basi di dati o gli archivi; e gli utenti del sistema.

I servizi in un sistema Jini comunicano tra loro usando un protocollo, che è un insieme di interfacce scritte nel linguaggio di programmazione Java.

1.1. Lookup Service

I servizi sono trovati dal Lookup Service, non è altro che una tabella contenente le interfacce che descrivono le funzionalità dei servizi presenti nella comunità Jini. In aggiunta vengono memorizzate le descrizioni testuali dei vari servizi, in modo da essere maggiormente comprensibili da un utilizzatore umano.

Un servizio è aggiunto al Lookup Service utilizzando due protocolli chiamati discovery e join: in primo luogo il servizio individua il Lookup Service (usando il protocollo discovery) e poi si unisce ad esso (usando il protocollo join).

1.2. Java Remote Method Invocation (RMI)

La comunicazione fra i servizi avviene utilizzando Remote Method Invocation (RMI) fornita da Java.

RMI permette non soltanto di trasferire dati da un oggetto ad un altro attraverso la rete, ma anche oggetti completi, compreso il codice, gran parte della semplicità del sistema Jini è consentita da questa capacità di spostare il codice, incapsulato nell’oggetto, attraverso la rete.

1.3. Leasing

L’accesso a molti dei servizi nell’ambiente Jini è basato sui leasing. Un leasing è una concessione di accesso garantito per un certo periodo di tempo. Ogni leasing è negoziato fra il richiedente e il fornitore del servizio: un servizio è chiesto per un certo periodo; l’accesso è assegnato per un certo periodo, possibilmente tenendo in considerazione il periodo richiesto.

Se un leasing non è rinnovato prima che sia esaurito, o perché la risorsa non è più necessaria, o il client o la rete viene a mancare, o non è consentito al leasing di essere rinnovato, allora la risorsa può essere liberato.

I leasing possono essere di due tipi: esclusivi o non esclusivi; quelli esclusivi assicurano che nessun altro possa usare la risorsa (ottenere un altro leasing) durante il periodo del leasing, quelli, invece, non esclusivi permettono un uso condiviso della risorsa (sono concessi più leasing sulla stessa risorsa).

1.4. Transazioni

Una serie di operazioni, all’interno di singolo servizio o riferite a più servizi, possono essere inglobate in una transazione.

Una transazione è una unità indivisibile di esecuzione, o vengono eseguite tutte le operazioni di una transazione, oppure la transazione deve non avere alcun effetto sul sistema, approccio “tutto o niente”, inoltre l’esecuzione di una transazione deve essere indipendente dalla contemporanea esecuzione di altre transazioni.

In particolare Jini per garantire una transazione utilizza il protocollo di commit a due fasi (two-phase commit). Tale protocollo ricorda, nelle sue linee essenziali, un matrimonio, la decisione di due persone viene raccolta e ratificata da una terza persona, che celebra il matrimonio, perché il matrimonio abbia luogo, è necessario che entrambi i partecipanti esprimano la loro volontà di sposarsi; il celebrante, durante la prima fase, raccoglie il desiderio di sposarsi, espresso separatamente dai due partecipanti, per poi, in una seconda fase, dar loro notizia che il matrimonio è avvenuto.

1.5. Eventi

L’architettura Jini supporta gli eventi distribuiti. Un oggetto può permettere che altri oggetti si registrino a particolari eventi dell’oggetto e ricevano una notifica del caso avvenga un tale evento.

2. Componenti

I componenti di un sistema Jini possono essere segmentati in tre categorie: l’infrastruttura, il modello di programmazione e i servizi. L’infrastruttura è l’insieme dei componenti che permette lo sviluppo del sistema federato Jini, mentre i servizi sono le entità all’interno della federazione. Il modello di programmazione è l’insieme delle interfacce che permette la costruzione di servizi affidabili, compresi quelli che fanno parte dell’infrastruttura e quelli che si uniscono alla federazione. Queste tre categorie, benché distinte e separabile, sono intrecciate a tal punto che la loro distinzione può sembrare poco chiara. Inoltre, è possibile sviluppare sistemi che hanno alcuna della funzionalità del sistema Jini con delle varianti o senza tutti e tre le categorie, ma un sistema Jini ha la sua maggiore forza perché è un sistema sviluppato con una particolare infrastruttura, con i modelli di programmazione descritti e basato sulla nozione di servizio.

3. L’infrastruttura

L’infrastruttura tecnologica di Jini include quanto segue:

  • un sistema di sicurezza distribuito, integrato con RMI, che estende il modello di sicurezza della piattaforma Java al mondo dei sistemi distribuiti;
  • discovery and join protocols, protocolli di servizio che consentono al servizio di scoprire, diventare parte, e avvisare gli altri membri della federazione;
  • lookup service, che serve come un deposito di servizi, è una tabella dove le righe sono oggetti scritti in Java.

Figura 1: Architettura della tecnologia Jini

4. Il modello di programmazione

Le righe del lookup service sono gestite con il meccanismo del leasing, permettendo al lookup service di riflettere esattamente l’insieme dei servizi attualmente disponibili nella comunità Jini. Quando i servizi si uniscono o abbandonano il lookup service, vengono generati degli eventi e gli oggetti che hanno registrato l’interesse in tali eventi ottengono le notifiche quando nuovi servizi diventano disponibili o vecchi servizi cessano di essere attivi. Il modello di programmazione si basa sulla capacità di spostare il codice, che è supportata dall’infrastruttura.

Le interfacce che compongono il modello di programmazione di Jini sono le seguenti:

  • leasing interface: definisce un modo per allocare e liberare le risorse usando un modello rinnovabile e basato sulla durata;
  • event e notification interface: sono una estensione del modello di evento usato nei componenti JavaBeans™ per sistemi distribuiti, permettono la comunicazione basata sugli eventi tra servizi Jini;
  • transaction interface: permette ad un gruppo di servizi di cooperare secondo l’approccio delle transazioni in modo tale che il cambiamento fatto dal gruppo avvenga in modo atomico (tutto o niente, commit a due fasi).

Non è espressamente richiesto che l’implementazione di un servizio Jini utilizzi il modello di programmazione, ma tali servizi devono utilizzare tale modello per la loro interazione con l’infrastruttura della tecnologia Jini. Per esempio, ogni servizio comunica con il lookup service usando il modello di programmazione; e se un servizio offre le risorse utilizzando il meccanismo del leasing, la registrazione del servizio con il lookup service deve essere effettuata con il leasing e rinnovata periodicamente.

5. Protocolli di Discovery, Join e Lookup

La parte basilare del sistema Jini è composta dai tre protocolli chiamati discovery, join e lookup.

I protocolli di discovery e join vengono usati quando un nuovo servizio si vuole unire alla comunità Jini; discovery viene utilizzato dal servizio per cercare un lookup service presso il quale registrarsi; join viene utilizzato quando il servizio, dopo aver individuato il lookup service, desidera unirsi.

Lookup si utilizza quando un cliente o un utente deve individuare ed utilizzare un servizio descritto dalla sua interfaccia (scritta nel linguaggio di programmazione Java) e da altri attributi.

Il seguente schema descrive il processo di discovery.

Figura 2: Discovery

Il processo di discovery usa tre tipi di sottoprotocolli:

  • Muliticast Request Protocol: utilizzato da un nuovo servizio Jini per trovare tutti i Lookup Service presenti su una LAN (Local Area Network) usando il multicast UDP (User Datagram Protocollo)
  • Multicast Announcement Protocol: usato dai Lookup service per annunciare la loro presenza su una LAN utilizzando il multicast UDP
  • Unicast Request Protocollo: usato da un servizio Jini per contattare un Lookup service utilizzando l’unicast TCP (Transport Control Protocol); questo protocollo viene solitamente utilizzato quando un servizio si vuole registrare presso un Lookup service che risiede fuori dalla LAN e di cui si conosce l’indirizzo.

Discovery/Join è il processo di aggiunta di un servizio ad un sistema Jini. In primo luogo, il fornitore di servizio individua un Lookup service tramite il protocollo di discovery; a questo punto, attraverso il protocollo di join, il servizio si registra presso il Lookup service che provvederà ad inserire una nuova riga nella tabella contenente il Service Object del servizio e i suoi attributi. Il Service Object contiene l’interfaccia del servizio scritta nel linguaggio di programmazione Java, con indicati i metodi che possono essere invocati.

Figura 3: Join

Il protocollo di Lookup serve per trovare ed utilizzare un servizio presente nella comunità Jini. Un client richiede al Lookup service di individuare un servizio con certe caratteristiche (il tipo di interfaccia e gli attributi associati), se esiste il Lookup service spedisce al client copia del Service Object, che viene utilizzata dal client stesso per invocare direttamente i metodi del servizio.

Figura 4: Lookup

Figura 5: Utilizzo del servizio

I metodi presenti nel Service Object possono implementare un protocollo privato fra il client ed il fornitore del servizio; differenti implementazioni della stessa interfaccia possono usare protocolli di interazione completamente differenti.

Il client sa soltanto che sta utilizzando l’implementazione di un certa interfaccia scritta in Java, in questo modo il codice che realizza l’interfaccia può fare quello che serve per fornire il servizio senza che il client ne abbia la minima conoscenza.

Un’interfaccia utente può essere anch’essa memorizzata in un Lookup service, in questo modo un utente del sistema è in grado di usare il servizio direttamente.