Broker e architettura a oggetti distribuiti

Transcript

1 Luca Cabibbo Architettura dei Sistemi Software Broker e architettura a oggetti distribuiti dispensa asw435 marzo 2017 Intelligence is not the ability to store information, but to know where to find it. Albert Einstein 1 - Fonti [POSA1] Pattern-Oriented Software Architecture (Volume 1): A System of Patterns. Wiley, [POSA4] Pattern-Oriented Software Architecture (Volume 4): A Pattern Language for Distributed Computing. Wiley, Coulouris, G, Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, Chapter 5, Remote Invocation Bachmann, F., Bass, L., and Nord, R. Modifiability Tactics. Technical report CMU/SEI-2007-TR

2 Obiettivi - Obiettivi e argomenti introdurre i pattern POSA per gli stili di comunicazione distribuita presentare l architettura a oggetti distribuiti e il pattern architetturale Broker Argomenti infrastruttura per la distribuzione verso l architettura a oggetti distribuiti architettura a oggetti distribuiti Broker [POSA] discussione 3 * Infrastruttura per la comunicazione Lo sviluppo dei sistemi software distribuiti è sostenuto da diversi servizi di middleware gli elementi software di un sistema software distribuito sono componenti oppure connettori i componenti sono (devono essere) focalizzati sulla logica di business dell applicazione il collegamento tra questi componenti avviene (deve avvenire) mediante connettori la comunicazione avviene sulla base di paradigmi e stili di comunicazione distribuita implementati dal middleware il middleware fornisce un infrastruttura di comunicazione che protegge i componenti delle applicazioni dalle numerose complessità tipiche dei sistemi distribuiti 4

3 Middleware e stili di comunicazione Sviluppare middleware per la comunicazione nei sistemi distribuiti è un attività estremamente complessa fortunatamente, solo raramente c è la necessità di progettare e implementare nuovi stili o paradigmi di interazione distribuita infatti, sono disponibili un ampia varietà di servizi di middleware, standard e commerciali, già usati con successo in moltissimi sistemi distribuiti Malgrado le differenze nei dettagli, le tecnologie di middleware sostengono di solito uno o più tra tre stili di comunicazione distribuita differenti rappresentati da tre pattern architetturali fondamentali invocazione remota Broker [POSA] messaging Messaging [POSA] notifica di eventi Publisher-Subscriber [POSA] 5 Stili di comunicazione e pattern [POSA] Broker [POSA] organizza il sistema distribuito in un insieme di componenti che interagiscono sulla base di invocazioni remote il broker gestisce gli aspetti della comunicazione tra questi componenti distribuiti Messaging [POSA] organizza il sistema in componenti che interagiscono sulla base dello scambio di messaggi i componenti si scambiano messaggi (che possono codificare dati, metadati, documenti, richieste, risposte) in modo asincrono, tramite un insieme di canali per messaggi Publisher-Subscriber [POSA] organizza il sistema in componenti che interagiscono sulla base dello scambio di notifiche di eventi, in modo asincrono 6

4 Stili di comunicazione e pattern [POSA] distribution infrastructure Broker Domain Object internal partitioning system evolution Domain Model remote communication functional variation Messaging Publisher- Subscriber from mud to structure Layers Pipes and Filters data stream processing data-driven processing Shared Repository user interface variation Model-View Controller Reflection Microkernel 7 Stili di comunicazione e middleware Nel seguito del corso, questi stili di comunicazione verranno discussi separatamente Broker in questa dispensa, Messaging e Publisher-Subscriber in una dispensa successiva in pratica, ciascun servizio di middleware implementa spesso uno o anche più tra questi stili di comunicazione 8

5 * Verso l architettura a oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diversi tipi di tecnologie, a diversi livelli di astrazione all inizio, dalle tecnologie di programmazione di rete offerte dai sistemi operativi (come i socket) il livello di astrazione è molto basso, l accoppiamento alla tecnologia è molto alto, nessun supporto per le difficoltà e le eterogeneità comunemente presenti nei sistemi distribuiti 9 Verso l architettura a oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diversi tipi di tecnologie, a diversi livelli di astrazione poi, dalle tecnologie di comunicazione strutturata (anni 80), come RPC l astrazione di programmazione distribuita della chiamata remota fornisce trasparenza rispetto ai meccanismi di comunicazione in rete di basso livello è anche alla base del modello client/server tuttavia, non fornisce trasparenza rispetto alla locazione dei servizi in rete che deve essere definita staticamente ed è poi difficile da cambiare, rendendo poco flessibile il rilascio dei servizi infatti, nello stile client/server, i client e i server sono organizzati secondo una struttura gerarchica rigida inoltre, non supporta l interoperabilità tra componenti realizzati con tecnologie differenti 10

6 Verso l architettura a oggetti distribuiti Lo sviluppo dei sistemi distribuiti è stato sostenuto, nel corso del tempo, da diversi tipi di tecnologie, a diversi livelli di astrazione il passo successivo è costituito dalle tecnologie a oggetti distribuiti (fine anni 80 e primi anni 90) che nascono dalla confluenza di RPC e delle tecnologie a oggetti questo modello distribuito ha svolto un ruolo fondamentale nello sviluppo dei sistemi distribuiti e del middleware il suo contributo principale è stato l introduzione della nozione di broker o object broker (discusso più avanti) per fornire ulteriore trasparenza e maggiore flessibilità oggi è una tecnologia matura e con delle capacità avanzate tuttavia, ha anche alcune limitazioni importanti la cui soluzione ha poi portato alla realizzazione di altre tecnologie di middleware 11 Verso l architettura a oggetti distribuiti L architettura a oggetti distribuiti è un evoluzione dello stile client/server è ancora basata sulle importanti nozioni di servizio e interfaccia i servizi vengono ancora consumati sulla base di un protocollo richiesta/risposta viene rimossa la distinzione rigida tra client e server ma, in ciascuna singola interazione, si continua a distinguere tra client e server (nell ambito di quella specifica interazione) viene fornita trasparenza dalla locazione dei servizi consentendo una maggiore flessibilità nel rilascio dei componenti distribuiti viene adottato un paradigma a oggetti 12

7 * Architettura a oggetti distribuiti L architettura a oggetti distribuiti (DOA) chiamata anche distributed object computing (DOC) o distributed object model organizza un sistema software in un insieme di elementi software chiamati oggetti distribuiti ciascun oggetto distribuito è un elemento software (a grana grossa) i diversi oggetti distribuiti del sistema sono distribuiti tra più processi e nodi, in modo flessibile l interazione tra oggetti distribuiti avviene sulla base dell invocazione di metodi remoti 13 Architettura a oggetti distribuiti A I A B C I B I C D E I D I E chiede servizi a Nota si tratta di una vista logica, funzionale ciascun rettangolo rappresenta un oggetto distribuito (a grana grossa) 14

8 Oggetti distribuiti Nell architettura a oggetti distribuiti, ciascun oggetto distribuito è un elemento software (a grana grossa) più precisamente, ogni oggetto distribuito è di solito composto internamente da un gruppo di oggetti (a grana più piccola) molti di questi oggetti sono oggetti locali tradizionali c è anche un oggetto remoto che è una facade che rappresenta l intero gruppo di oggetti questo consente agli altri oggetti distribuiti di poter invocare le operazioni di questo oggetto distribuito distributed object facade remote object o1 o2 o3 local objects o4 15 Comunicazione tra oggetti distribuiti Nell architettura a oggetti distribuiti, la comunicazione tra oggetti distribuiti basata su un paradigma di comunicazione di tipo RMI è supportata da un opportuna infrastruttura di comunicazione in particolare, il servizio di middleware utilizzato nell architettura a oggetti distribuiti è chiamato un object request broker (ORB) o più semplicemente broker il broker agisce essenzialmente come un bus software per consentire la comunicazione tra i diversi oggetti distribuiti 16

9 Comunicazione mediante broker A B C I A I B I C Object Request Broker D E I D I E Questa è, invece, una vista di deployment mostra l infrastruttura di comunicazione potrebbe mostrare anche i computer/nodi su cui sono rilasciati i diversi oggetti distribuiti 17 Interazione tra oggetti distribuiti Interazione tra oggetti distribuiti gli oggetti server (ovvero, gli oggetti che offrono servizi) possono registrare i servizi che forniscono presso il broker ovvero, presso il servizio di directory gestito dal broker gli oggetti client possono poi fare richieste (invocazioni remote) agli oggetti server tramite il broker usato come indirezione oppure, possono consultare il servizio di directory del broker per ottenere un riferimento remoto a un oggetto server ad es., tramite un identificatore simbolico dell oggetto server e poi interagire direttamente con l oggetto server i ruoli client e server non sono fissati in modo statico, ma si riferiscono a una singola interazione infatti i diversi oggetti possono in generale essere sia client di servizi che server di altri servizi 18

10 Conseguenze Conseguenze architettura aperta, flessibile e scalabile possibile riconfigurare il sistema dinamicamente, migrando gli oggetti tra nodi questo consente, ad es., di rimandare decisioni su dove fornire i servizi, oppure di cambiare decisioni per sostenere qualità come scalabilità e disponibilità consente l introduzione dinamica di nuove risorse, quando richieste può essere favorita la modificabilità con oggetti a grana piccola coesi e poco accoppiati l affidabilità può beneficiare del fatto che lo stato degli oggetti è incapsulato 19 Conseguenze Conseguenze le prestazioni peggiorano se sono utilizzati molti oggetti a grana piccola o con servizi/operazioni a grana piccola le prestazioni dipendono dalla topologia e dalla grana degli oggetti e della loro interfaccia bene con oggetti a grana grossa, che comunicano poco la sicurezza beneficia dall incapsulamento dei dati ma la frammentazione dei dati influisce negativamente maggior complessità rispetto ai sistemi client/server 20

11 Usi del modello a oggetti distribuiti È possibile identificare due modalità principali di utilizzo del modello a oggetti distribuiti questo modello può essere usato come un modello logico per strutturare e organizzare un sistema software gli elementi dell architettura sono macro-oggetti distribuiti che offrono servizi mediante la loro interfaccia remota il modello a oggetti distribuiti viene utilizzato per effettuare la decomposizione del sistema la tecnologia a oggetti distribuiti può anche essere usata come base (flessibile) per l implementazione di sistemi client/server ovvero, il sistema software viene organizzato secondo un architettura logica di tipo client/server ma tecnologicamente client e server sono realizzati come oggetti distribuiti che interagiscono mediante un servizio di middleware a oggetti distribuiti 21 Architettura a oggetti distribuiti Il modello a oggetti distribuiti è stato già discusso nella dispensa sull Invocazione remota il funzionamento di un ORB è descritto dal pattern architetturale Broker, illustrato qui di seguito 22

12 * Broker [POSA] In generale, il termine broker indica un intermediario un professionista che ricerca e acquista, per conto del cliente, nel mercato di riferimento, il prodotto che offre il miglior rapporto qualità-prezzo [Wikipedia] dunque, ad esempio, una parte che media tra un acquirente e un venditore Il pattern architetturale Broker [POSA] può essere usato per strutturare sistemi distribuiti con componenti disaccoppiati che interagiscono mediante l invocazione di servizi remoti un elemento broker è un intermediario responsabile di coordinare la comunicazione tra i diversi componenti remoti ad es., per inoltrare richieste di un client ad un server opportuno, e poi trasmettere al client risposte o eccezioni 23 Relazione con altri stili [POSA] distribution infrastructure Broker Domain Object internal partitioning system evolution Domain Model remote communication functional variation Messaging Publisher- Subscriber from mud to structure Layers Pipes and Filters data stream processing data-driven processing Shared Repository user interface variation Model-View Controller Reflection Microkernel 24

13 Broker [POSA4] colloca Broker nella categoria infrastrutture per la distribuzione Broker è un pattern alla base della tecnologia a oggetti distribuiti ma è anche utilizzato (nelle sue varianti o evoluzioni) anche in altri servizi di middleware (a componenti, a servizi, per il messaging, ) costituisce un infrastruttura di comunicazione per rendere trasparenti all applicazione (e al programmatore) alcune complessità della distribuzione 25 Esempio City Information System CIS sistema di informazioni turistiche portale verso altri sistemi (esterni) che effettivamente offrono servizi per turisti informazioni su alberghi e ristoranti, trasporti pubblici, musei, visite guidate,... in alcuni casi con la possibilità di fare prenotazioni/acquisti ci possono essere più sistemi esterni che possono soddisfare uno stesso tipo di richieste è possibile la registrazione dinamica di nuovi sistemi esterni il CIS si propone come un punto di contatto singolo per il turista nei confronti dei sistemi esterni dunque, CIS è un broker tra turista e sistemi esterni 26

14 Contesto Broker in un sistema distribuito, ci sono più componenti in grado di erogare dei servizi è necessaria un infrastruttura di comunicazione che protegga le applicazioni dalla complessità della distribuzione 27 Problema Broker si vuole organizzare un sistema distribuito sulla base di un insieme di componenti distribuiti, in modo flessibile ovvero, in modo che gli utenti dei servizi non debbano conoscere la natura e la posizione dei fornitori dei servizi inoltre, deve essere possibile cambiare dinamicamente i collegamenti tra utenti e fornitori di servizi dunque, si desiderano componenti interoperabili ma disaccoppiati trasparenza nell accesso ai componenti indipendenza dalla locazione, dai meccanismi di comunicazione interprocesso e dalla disponibilità dei componenti possibilità di aggiungere/rimuovere/sostituire componenti a runtime se possibile, interoperabilità tra componenti eterogenei 28

15 Problema Broker in generale, le applicazioni distribuite dovrebbero gestire le problematiche connesse alla distribuzione usando un modello di programmazione che protegga le applicazioni stesse dai dettagli della rete e della posizione dei componenti in rete idealmente, i componenti dovrebbero poter interagire mediante l invocazione dei loro servizi queste invocazioni dovrebbe poter essere espresse in modo unificato e indipendente dalla posizione dei componenti (ovvero, indipendentemente dal fatto che i servizi invocati siano locali o remoti) 29 Broker Soluzione (struttura) organizza il sistema distribuito in un insieme di componenti che interagiscono sulla base di invocazioni remote introduci un componente intermediario broker per gestire la comunicazione tra questi componenti distribuiti il broker definisce un modello di programmazione distribuita in cui i client possono invocare servizi remoti come se fossero servizi locali ed incapsula l infrastruttura di comunicazione del sistema distribuito il broker realizza un disaccoppiamento tra utenti (client) e fornitori (server) dei servizi ed inoltre sostiene una separazione tra i dettagli della comunicazione e le funzionalità applicative utilizza degli ulteriori intermediari proxy per aiutare i componenti client e server nell interazione con il broker 30

16 Broker Soluzione (dinamica) all avvio di ciascun server, il server registra i propri servizi (interfaccia e locazione) presso il broker un client accede ai servizi indirettamente, tramite il broker il client richiede un servizio al broker il broker seleziona un server in grado di erogare il servizio, e gli inoltra la richiesta del client, e poi trasmette la risposta ricevuta al client in questo modo il client può ignorare l identità, la locazione e le caratteristiche del server che lo sta servendo se un server diviene indisponibile, il broker può scegliere dinamicamente di sostituirlo con un altro server (tra quelli che offrono un servizio compatibile) il broker è l unico componente che deve sapere di questo cambiamento senza ripercussioni sui client 31 Struttura (parziale) Client-side Proxy transfer messages Broker transfer messages Server-side Proxy call service pack data retun result unpack data main event loop register service update registry send request find server send response find client call service unpack data pack data calls calls Client Server start task call service use broker API start initialize enter main loop run service use broker API 32

17 Server Partecipanti ciascun server è un oggetto o componente che offre servizi i servizi sono esposti tramite una interfaccia ad es., un IDL di solito ci sono molti server che offrono servizi diversi, ma che possono anche offrire gli stessi servizi ciascun server registra i servizi che può offrire presso il Broker Client ciascun client è un oggetto (o componente o applicazione) che vuole fruire di servizi di solito ci sono molti client concorrenti ciascun client inoltra le proprie richieste al Broker Client e server vanno intesi nell accezione flessibile dell architettura a oggetti distribuiti 33 Partecipanti Broker come abbiamo detto, il termine broker indica l intermediario tra i client e i server nel sistema distribuito il broker è un bus un messaggero responsabile della trasmissione di richieste e risposte tra client e server è responsabile di gestire un registry dei servizi e dei server presenti nel sistema distribuito (con la loro interfaccia e la loro locazione) offre ai server (mediante delle API) la funzionalità per registrare i loro servizi offre ai client (mediante delle API) la funzionalità per richiedere l esecuzione di servizi può offrire ai client e ai server altri servizi aggiuntivi ad es., di naming (directory, context) 34

18 Partecipanti Proxy lato client intermediario tra client e broker/server è il rappresentante lato client del servizio richiesto con la stessa interfaccia del servizio vive localmente al processo del client un remote proxy fornisce trasparenza rispetto alla distribuzione, perché sia il broker che l oggetto server remoto appaiono locali al client Proxy lato server intermediario tra broker e server vive localmente al processo del server responsabile di ricevere richieste dal client (tramite il broker), di invocare il servizio effettivo e di trasmettere le risposte al client (tramite il broker) 35 Parentesi: Proxy [POSA, GoF] Il design pattern Proxy fa comunicare i client di un componente che offre servizi con un rappresentante di quel componente e non direttamente con il componente stesso l introduzione di un tale segnaposto può sostenere diversi scopi ad es., aumentare l efficienza, semplificare l accesso, consentire la protezione da accessi non autorizzati Proxy [GoF] fornisce un surrogato o un segnaposto per un altro oggetto per controllarne l accesso Possibili diverse applicazioni di proxy remote proxy, protection proxy, cache proxy, synchronization proxy, virtual proxy,... in Broker, si tratta di una coppia di remote proxy 36

19 Scenario 1 registrazione server Server Broker start initialize main event loop register service update registry ack enter main loop confine tra processi 37 Scenario 2 gestione richiesta client Client Client-side Proxy Broker Server-side Proxy Server call service pack data send request find server call service unpack data run service result send response pack data return result find client result unpack data 38

20 Scenario 2 Ruolo del broker in questo scenario 2 trascurando il ruolo dei proxy (che già conosciamo) il client chiede l erogazione di un servizio ma non la chiede direttamente a un server, ma piuttosto la chiede al broker il broker (sulla base delle informazioni sui servizi registrati, che gestisce direttamente) seleziona un server in grado di erogare il servizio richiesto potrebbero esserci un solo server in grado di erogare quel servizio, ma potrebbero essercene anche più di uno inoltre, il broker inoltra la richiesta al server selezionato, per conto del client poi, il broker ottiene la risposta alla richiesta dal server, sempre per conto del client infine, il broker restituisce la risposta al client 39 Scenario 2 varianti Lo scenario per la gestione delle richieste da parte di un client ha due varianti principali nelle due varianti, il broker ha ruoli diversi anche i proxy hanno ruoli un po diversi comunicazione indiretta come mostrato dallo scenario 2 di base, tutte le richieste (e le risposte) transitano attraverso il broker il client e il server non comunicano mai in modo diretto comunicazione diretta il broker è responsabile solo di mettere in comunicazione client e server dopo di che, client e server comunicano in modo diretto richiede che client e server comprendano e utilizzino lo stesso protocollo 40

21 Scenario 2 varianti Confronto tra le due varianti nella comunicazione diretta, l overhead di comunicazione è minore tuttavia, nella comunicazione indiretta, il client è protetto in modo continuo da eventuali indisponibilità e da variazioni di locazione dei servizi inoltre la comunicazione indiretta abilita un ulteriore scenario di interoperabilità, in cui il client e il server potrebbero essere eterogenei ed essere basati su protocolli o su formati diversi questo scenario di interoperabilità che è basato sull utilizzo di una federazione di broker (anziché di un solo broker) e su componenti bridge per collegare questi broker viene qui trascurato per semplicità 41 Conseguenze Benefici trasparenza dalla posizione il client non ha bisogno di sapere dove si trova il server i server possono ignorare la posizione dei loro client modificabilità ed estendibilità dei componenti riusabilità di servizi esistenti possibile l interoperabilità tra tipi di client, server e broker diversi 42

22 Conseguenze Inconvenienti riduzione delle prestazioni, a causa dell indirezione del broker inoltre preclude la possibilità di effettuare ottimizzazioni legate, ad es., ad un allocazione statica dei componenti distribuiti minor tolleranza ai guasti rispetto a una soluzione non distribuita il broker potrebbe essere un punto di fallimento singolo (ma se è opportunamente replicato/ridondato, allora potrebbe non esserlo) maggior complessità difficile da verificare 43 Esempio: Java RMI Java RMI l architettura Java RMI è basata, in parte, su Broker il ruolo del broker è svolto dalla JVM remota che contiene l oggetto servente il ruolo del proxy lato client è svolto dalla JVM lato client e da uno stub generato implicitamente il ruolo del proxy lato server (lo skeleton) è svolto dalla JVM lato server anche in questo caso, lo skeleton è generato implicitamente comunicazione diretta la comunicazione Java RMI è normalmente basata sul protocollo JRMP tuttavia, la tecnologia Java RMI-IIOP (Java RMI over Internet Inter-ORB Protocol) consente l interoperabilità con dei broker CORBA 44

23 - Usi conosciuti Il pattern architetturale Broker è molto diffuso la prima implementazione di un broker che è stata ampliamente usata è in CORBA (Common Object Request Broker Architecture) il pattern broker è usato, in forme variate ed evolute, anche nelle tecnologie a componenti (come Java EE e.net) e nelle architetture a servizi 45 - Broker e tattiche per la modificabilità Increase semantic coherence increase cohesion ciascun server raggruppa un insieme di funzionalità semanticamente correlate Encapsulate reduce coupling ciascun server espone le proprie funzionalità mediante un interfaccia remota pubblicata l interazione con i client avviene solo sulla base di tale interfaccia anche il broker espone le proprie responsabilità pubbliche (ad es., relativamente alla registrazione dei servizi) mediante delle API pubbliche in modo indipendente dall implementazione di tali responsabilità 46

24 Broker e tattiche per la modificabilità Use an intermediary reduce coupling il broker è un intermediario tra client e server fornisce la possibilità di invocare servizi in modo indipendente dalla locazione anche il proxy lato client è un intermediario gli oggetti remoti appaiono locali al client anche il proxy lato server è un intermediario il server riceve delle chiamate locali la coppia di proxy nasconde a client e server i dettagli implementativi della comunicazione remota 47 Broker e tattiche per la modificabilità Restrict dependencies reduce coupling il client comunica con il server indirettamente, tramite i proxy e il broker questo consente cambiamenti nei server motivati, ad esempio, da obiettivi di affidabilità o bilanciamento del carico Use runtime binding defer binding i server si registrano presso il broker a runtime le registrazioni possono cambiare dinamicamente 48

25 * Discussione I servizi di middleware utilizzati nella realizzazione dei sistemi distribuiti sostengono di solito tre stili principali di comunicazione distribuita rappresentati da tre pattern architetturali fondamentali in questa dispensa abbiamo studiato Broker che suggerisce di organizzare un sistema distribuito come un insieme di componenti che interagiscono sulla base di invocazioni remote in una successiva dispensa studieremo Messaging e Publisher- Subscriber che suggeriscono di organizzare un sistema distribuito come un insieme di componenti che interagiscono sulla base dello scambio di messaggi e di notifiche di eventi, in modo asincrono in pratica, ciascun servizio di middleware implementa di solito uno o più tra questi stili di comunicazione 49