Reti di calcolatori LS Enrico Pirazzini SSB un middleware basato su JMS per l'invocazione di servizi remoti
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
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
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.
Architettura client_1 server_c server_b server_a client_2 RequestQ ResponseQ
Broker ● Gestisce le informazioni di stato del sistema ● provider registrati ● code ● attraverso servizi “interni” ● Lookup ● Registration ● Unregistration ● Stillalive
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
Implementazione SSBProvider BusAccessCore Service Requester Service Provider mbLayer SSBMessages javax.jms.Message tLayer mLayer SSBSession javax.jms.Session SSBSession javax.jms.Session BusAccessCore SSBClient
tLayer ● Incapsula le primitive JMS ● SSBSession specializata a seconda dell'utilizzatore ● SSBMessages diverse tipologie a seconda di servizio e funzionalità
mLayer ● BusAccessCore – consente di accedere ai servizi fornendo sessioni di comunicazione – invoca servizi “interni” – mantiene copia locale dello stato del sistema
mbLayer ● Contiene le entità end-user di alto livello che nascondo i dettagli sottostanti ● SSBClient ● SSBProvider
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
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
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
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
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.
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.