Reti di calcolatori LS Enrico Pirazzini 0000170400 SSB un middleware basato su JMS per l'invocazione di servizi remoti.

Presentazione sul tema: "Reti di calcolatori LS Enrico Pirazzini 0000170400 SSB un middleware basato su JMS per l'invocazione di servizi remoti."— Transcript della presentazione:

1 Reti di calcolatori LS Enrico Pirazzini 0000170400 SSB un middleware basato su JMS per l'invocazione di servizi remoti

2 Introduzione ● Un'architettura orientata ai servizi: – uno o più nodi mettono a disposizione parte delle proprie risorse per eseguire, su richiesta, un determinato servizio – comunicazione tipicamente con un protocollo basato su richiesta/risposta ● Occore un'entità intermedia che fornisca un punto di comunicazione fisso per ogni servizio, in modo da collegare client e provider in modo trasparente e possibilmente affidabile

3 Introduzione ● Utilizzando un broker che si appoggi ad un MOM si ottinene – un'infrastruttura di comunicazione che prescinde dai formati effettivi delle richieste e delle risposte dei singoli servizi – disaccoppiamento tra client e provider – interazioni sia di tipo sincrono che asincrono – scelta di JMS: un'interfaccia stardard

4 Architettura ● il client che richiede un servizio, ● il provider che fornisce il servizio ● il broker che permette la comunicazione tra i due gestendo ● canali bidirezionali (coppie di code) su cui vengono depositati e prelevati messaggi.

5 Architettura client_1 server_c server_b server_a client_2 RequestQ ResponseQ

6 Broker ● Gestisce le informazioni di stato del sistema ● provider registrati ● code ● attraverso servizi “interni” ● Lookup ● Registration ● Unregistration ● Stillalive

7 Comunicazione ● Canale bidirezionale costituito da una coppia di code in cui depositare/prelevare un messaggio ● disaccopiamento tra client e provider: il client non sà chi eseguirà la propria richiesta ed il provider non ne conosce il mittente ● Il MOM si occupa della trasmisione effettiva

8 Implementazione SSBProvider BusAccessCore Service Requester Service Provider mbLayer SSBMessages javax.jms.Message tLayer mLayer SSBSession javax.jms.Session SSBSession javax.jms.Session BusAccessCore SSBClient

9 tLayer ● Incapsula le primitive JMS ● SSBSession specializata a seconda dell'utilizzatore ● SSBMessages diverse tipologie a seconda di servizio e funzionalità

10 mLayer ● BusAccessCore – consente di accedere ai servizi fornendo sessioni di comunicazione – invoca servizi “interni” – mantiene copia locale dello stato del sistema

11 mbLayer ● Contiene le entità end-user di alto livello che nascondo i dettagli sottostanti ● SSBClient ● SSBProvider

12 BusBroker ● Costituito dai servizi “interni” e da due gestori delle strutture interne del sistema ● DataManager per la registrazione provider-servizio ● Destination Manager per le code Lookup Registration Unregistration Data Stillalive Data manager Destination manager RO RW

13 BusBroker ● Lookup elenco dei servizi disponibili e le relative code ● Registration registra l'associazione tra servizio e provider ● Unregistration registra l'associazione tra servizio e provider ● StillAlive invia periodicamente a tutti i provider una richiesta di conferma dei servizi forniti

14 QoS ● Ogni comunicazione è caratterizzata da un timeout massimo che impedisce il blocco indefinito ● Ricezione, esecuzione del servizio e invio della risposta vengono considerate come un'unica azione logica indivisibile. – Se vi è un malfunzionamento: rollback, la richiesta ritorna nella coda ● StillAlive garantisce la coerenza delle informazioni fornite dal broker

15 QoS ● Ricezione, esecuzione del servizio e invio della risposta vengono considerate come un'unica azione logica indivisibile. – Se vi è un malfunzionamento: rollback, la richiesta ritorna nella coda provider request response

16 Prototipo ● ClientConsole, consente di comandare un'istanza di SSBClient, eseguendo lookup ed invocazione di servizi in modo sia sincrono che asincrono, visualizzandone poi il responso. ● ProviderConsole, consende di comandare un'istanza SSBProvider, eseguendo lookup, registrazione e deregistrazioni di relative a uno o più servizi.

17 Conclusione ● Il sistema realizzato consente di invocare dinamicamente servizi remoti – in modo trasparente rispetto alla loro locazione ed al numero effettivo di fornitori – in modo affidabile ● Ulteriori sviluppi possono essere: – ampliare i servizi "interni", in particolare fornendo in fase di lookup una descrizione dell'interfaccia di invocazione – attuare una gestione oculata della replicazione considerando provider dotati di stato.