JDICS Java Dynamic Infrastructure for C/S systems Laura Galli matr.180699 Reti di calcolatori LS, Prof. A.Corradi A.A 2004-05.

Presentazione sul tema: "JDICS Java Dynamic Infrastructure for C/S systems Laura Galli matr.180699 Reti di calcolatori LS, Prof. A.Corradi A.A 2004-05."— Transcript della presentazione:

1

2 JDICS Java Dynamic Infrastructure for C/S systems Laura Galli matr.180699 Reti di calcolatori LS, Prof. A.Corradi A.A 2004-05

3 Agenda JDICS Architecture Client Proxy Broker Server JDICS Interaction protocols Client-Proxy Proxy-Broker Server-Broker Broker-Broker JDICS QoS (fault tolerance, load balancing)

4 JDICS architecture

5 Architecture L’architettura di JDICS consiste di quattro entità fondamentali : Client Proxy Broker Server Tali entità si trovano su due livelli logici distinti : livello applicativo livello middleware proxybrokers server clients

6 Server I server di JDICS sono oggetti remoti, referenziabili via RMI da applicazioni Java disposte fisicamente su nodi distinti. Nell’ottica di una architettura fault tolerant, il supporto prevede la possibilità di gestire la replicazione a livello server, introducendo il concetto di servizio o (cluster di servizio) e copia server.

7 Server architecture Un servizio è disponibile se esiste almeno una copia server attiva in grado di implementarlo. Counter service Un servizio può essere con o senza stato, ma la presenza del cluster non deve modificare la semantica RMI : lo stato deve essere condiviso da tutte le copie server server service cluster cluster state manager

8 Client In JDICS i client sono applicazioni Java, che per realizzare la propria logica applicativa necessitano di servizi via RMI Un client può conoscere a priori il nome di un servizio (staticamente), oppure può scoprire i servizi disponibili run-time (dinamicamente). s1 s2 s3 RMI Remote objects (services) Dynamic or static ?

9 Client requests… Un client può richiedere : i servizi al momento disponibili sulla rete l’interfaccia di un particolare servizio (metodo e parametri) il riferimento ad un particolare servizio Quali servizi ? counter echo counter, echo… Quale intefaccia per echo ? String echo(String) Riferimento a echo ! Ecco !

10 Proxy Chi risponde alle richieste dei client ? I client devono poter uscire dalla loro località per esplorare la rete… oppure possono delegare questo compito ad una entità apposita : il proxy. Il proxy è una entità locale al nodo ed è condiviso da tutti i client dello stesso host. Il proxy incapsula la capacità di un host di conoscere lo stato della rete ??? net info… But how do they know ?

11 Broker I broker sono i punti di riferimento assoluti per una rete JDICS. Lo scopo dei broker è quello di creare un link tra mondo client e mondo server raccogliendo la conoscenza (dinamica) sullo stato della rete. counter billing accounting echo ??? counter service is available with 2 copies at 192.168…. info…

12 JDICS interaction protocols

13 Server Insertion Protocol Un server può essere la prima copia del cluster, oppure può inserirsi in un cluster già esistente billing Ogni server conosce un indirizzo di multicast con cui raggiungere tutti i broker della rete per inviare la propria richiesta di registrazione multicast 239.1.2.4 new server/ billing service/acer-150 datagram socket acer-150 Il broker che gestisce la registrazione (server-token) risponde al server inviando alla socket datagram un pacchetto con l’ID Il broker che gestisce la registrazione avverte tutti gli altri broker via multicast, affinchè sappiano dell’esistenza del nuovo server. ID=2 new server/ billingservice/ID=2 multicast 239.1.2.3

14 Proxy Insertion Protocol Un proxy che voglia entrare nella rete ed esplorarla deve avere il riferimento ad un broker. Essendo i broker noti solo a run-time, deve prima effettuare una registrazione per ottenere un ID e un riferimento (remoto) ad una entità broker. Ogni proxy conosce un indirizzo di multicast con cui raggiungere tutti i broker della rete per inviare la propria richiesta di registrazione. multicast 239.1.2.4 new proxy/acer-150 datagram socket acer-150 Il broker che gestisce la registrazione risponde al proxy inviando alla socket datagram un pacchetto con l’ID del proxy, il suo ID e il suo indirizzo RMI. Il proxy recupera il riferimento al broker all’indirizzo RMI fornitogli. Il broker che gestisce la registrazione avverte tutti gli altri broker via multicast, affinché sappiano dell’esistenza del nuovo proxy a lui legato. ID=123/RMiadd r… new proxy/ ID=123 multicast 239.1.2.3

15 Broker Insertion Protocol Un broker può essere il primo del sistema ed in quel caso è l’iniziatore del sistema, oppure deve inserirsi nel ring dei broker. Nel caso in cui il ring sia già formato, il protocollo di inserimento prevede : invio in multicast della richiesta di inserimento attesa di un numero di risposte pari alla cardinalità del ring selezione del proprio predecessore determinazione del proprio ID invio del proprio ID al predecessore scelto (via RMI) e raccolta delle informazioni sullo stato della rete fase di informazione (via multicast) della nuova configurazione del ring agli altri broker new broker/RMI addr…/ acer-150 Id=…/ RMI addr/ #=3 Id=1 Id=3 Id=4 Id=5 Id =1 Id =3 Id =4 Id =5

16 JDICS QoS Fault tolerace, Load balancing

17 Broker failure Se il server che vuole registrarsi non riceve risposta da nessuno (time-out) invia (in multicast) un messaggio di richiesta di aiuto a tutti i broker. I broker attivano una procedura di identificazione del guasto : ogni broker controlla il proprio successore nel ring il broker che rileva il guasto gestisce la richiesta di registrazione (il broker guasto ha portato alla perdita del server-token), avvia un processo di riconfigurazione del ring rimuovendo il nodo guasto e ripristina il token server sul nuovo successore S.O.S

18 Broker failure Un broker può accorgersi del fallimento del proprio successore nel momento in cui tenta di passargli il token Il broker attiva una procedura di riconfigurazione dell’anello ripristinando il token sul nuovo successore

19 Broker failure Un broker nuovo che vuole inserirsi nel ring può accorgersi di un guasto nel momento in cui riceve un numero di answers inferiore alla cardinalità dell’anello comunicatagli. Il nuovo broker avverte uno dei pari che gli ha risposto indicandogli da chi ha ricevuto answers. Il broker informato individua il broker che non ha risposto, verifica il guasto e attiva una procedura di riconfigurazione in cui il nuovo broker prende il posto di quello fallito (compresi gli eventuali token). !

20 Broker failure Un proxy può accorgersi del fallimento del proprio broker nel momento in cui lo referenzia (via RMI )per ottenere dei servizi. Errore ! Il proxy invia una richiesta di aiuto (via multicast) indicando il broker che non gli ha risposto. Help ! Broker 1 failed 1 1 2 5 Il predecessore del broker fallito, risponde al proxy via socket datagram e si propone come nuovo riferimento. Il predecessore del broker fallito avvia la procedura di riconfigurazione del ring avvertendo i suoi peer. Il predecessore fa la stessa cosa per tutti i proxy che erano legati al broker fallito id=5/RMIaddr … 2 5

21 Server failure Il guasto di un server può essere rilevato da un client che lo utilizza. Il client infatti può riceve una eccezione nel momento in cui lo riferisce. Errore ! Il client avverte il suo proxy, che a sua volta avverte il suo broker Il broker consegna al proxy un nuovo riferimento e il proxy a sua volta provvede a passare il nuovo riferimento al client. Errore !

22 Load balancing Il load balancing è implementato mediante la tecnica del reference-counting. E’ compito del broker realizzare la politica di load balancing nell’ambito di ciascun cluster, provvedendo ad assegnare (come riferimento) ad ogni richiesta la copia più “libera.” echo 2 1 2 2

23