Comunicazione asincrona

Transcript

1 Luca Cabibbo Architettura dei Sistemi Software dispensa asw450 marzo 2019 I ll send an S.O.S. to the world. I hope that someone gets my message in a bottle. Yeah. The Police 1 - Fonti [POSA4] Pattern-Oriented Software Architecture (Volume 4): A Pattern Language for Distributed Computing. Wiley, Hohpe, G. and Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Richardson, C. Microservices Patterns: With examples in Java. Manning, Chapter 3, Interprocess communication in a microservice architecture Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, Chapter 6, Indirect Communication 2

2 Obiettivi - Obiettivi e argomenti introdurre la comunicazione asincrona basata sullo scambio di messaggi e notifiche di eventi, in modo indiretto ed asincrono discutere la semantica della comunicazione asincrona Argomenti introduzione alla comunicazione asincrona comunicazione asincrona semantica della comunicazione asincrona discussione 3 * Introduzione alla comunicazione asincrona 4 La comunicazione asincrona rappresenta un altro stile fondamentale di comunicazione nei sistemi distribuiti è una modalità di comunicazione complementare a quella sincrona offerta dall invocazione remota la comunicazione asincrona è un astrazione di programmazione distribuita basata sullo scambio di messaggi, che consente ad un componente di inviare un messaggio (contenente dei dati o la notifica di un evento), in modo indiretto ed asincrono, ad uno o più componenti, affinché questo o questi componenti possano elabora il messaggio questa modalità di comunicazione è offerta dai message broker o, più in generale, dal middleware orientato ai messaggi in pratica, esistono diverse forme specifiche di comunicazione asincrona in questa dispensa ci concentriamo soprattutto sulle idee di base comuni, ma discutiamo anche alcune variazioni e differenze

3 Sulla comunicazione sincrona L invocazione remota è una forma di comunicazione sincrona un componente client invoca un metodo offerto da un server per uno specifico servizio (il server potrebbe essere selezionato staticamente o dinamicamente, tramite un broker) quando il server ha completato l operazione richiesta, restituisce una risposta al client il client, nel frattempo, era rimasto in attesa del completamento dell operazione l invocazione remota fornisce una sincronizzazione tra client e server ad esempio, può essere usata per garantire che un gruppo di attività vengano eseguite secondo un ordine specificato (quando ciò è richiesto) 5 Sulla comunicazione sincrona Tuttavia, la comunicazione sincrona realizzata dall invocazione remota non è sempre necessaria oppure opportuna in alcuni casi, un componente vuole richiedere l elaborazione di alcuni dati ma non lo si vuole accoppiare ad uno specifico server o ad una specifica operazione o servizio in alcuni casi, un componente vuole richiedere un elaborazione ma non è interessato ad ottenere una risposta in modo sincrono, e talvolta non è nemmeno interessato ad ottenere una risposta dunque, in alcuni casi è desiderabile una modalità di interazione più flessibile di quella basata su invocazioni dirette e sincrone 6

4 Sulla comunicazione sincrona Inoltre, la comunicazione sincrona può avere conseguenze negative sulle qualità di un sistema può ridurre la concorrenza nello svolgimento delle attività limitando le prestazioni e la scalabilità il rallentamento di un componente server può rallentare i componenti client che ne richiedono i servizi il guasto o l indisponibilità di un componente server può propagarsi ai componenti client che ne richiedono i servizi per questo, chi realizza il client per un servizio si deve occupare (se serve) anche di gestire il caso dei rallentamenti o dei guasti del server 7 Verso la comunicazione asincrona La comunicazione asincrona è una modalità di interazione complementare a quella sincrona è un ulteriore paradigma fondamentale di programmazione distribuita per le situazioni in cui la comunicazione sincrona non è necessaria o non è opportuna per sostenere un accoppiamento più basso tra i componenti distribuiti e consentire interazioni più flessibili per sostenere qualità come prestazioni, scalabilità e disponibilità evitando le possibili conseguenze negative della comunicazione sincrona 8

5 * La comunicazione asincrona è un paradigma di comunicazione per componenti distribuiti, basato sullo scambio di messaggi, supportato da diversi servizi di middleware in particolare, dai message broker o, più in generale, dal middleware orientato ai messaggi (message-oriented middleware o MOM) nella comunicazione asincrona, i componenti distribuiti interagiscono inviandosi messaggi (oppure notifiche di eventi) in modo indiretto, con l ausilio di canali per messaggi in modo asincrono per questo, la comunicazione asincrona è anche chiamata messaging ( scambiarsi messaggi ) e comunicazione basata su messaggi si parla talvolta anche di code di messaggi e di sistemi publish-subscribe 9 Sulla asincronia 10 Attenzione, non si confonda la comunicazione asincrona con l invocazione remota asincrona infatti, come vedremo tra breve, queste due modalità di comunicazione sono molto diverse tra loro nell invocazione remota asincrona, il client effettua un invocazione e poi continua (senza bloccarsi) tuttavia, al momento dell invocazione, il client ed il server devono essere entrambi attivi contemporaneamente nella comunicazione asincrona, viceversa, un componente può inviare un messaggio anche quando il componente che riceverà quel messaggio non è attivo o non è nemmeno stato creato inoltre il componente che riceve il messaggio potrebbe farlo quando il componente che ha inviato il messaggio non è più attivo o è stato distrutto dunque, la comunicazione asincrona consente anche la comunicazione tra componenti con un esistenza indipendente

6 Un analogia Ecco un analogia (riferita alle persone) che illustra la differenza tra comunicazione sincrona e comunicazione asincrona la comunicazione che avviene tra due persone in una telefonata è una forma di comunicazione sincrona entrambe le persone devono partecipare contemporaneamente alla telefonata la comunicazione che avviene tra due persone nello scambio di messaggi di posta elettronica, SMS, oppure su un social network è una forma di comunicazione asincrona le persone possono inviare e leggere i messaggi in momenti distinti si tratta solo di un analogia la comunicazione a cui siamo interessati è quella tra componenti software, e non tra persone 11 - di base La comunicazione asincrona viene ora presentata, in due momenti prima viene discusso il caso di una singola interazione nella comunicazione asincrona, relativo allo scambio di un solo messaggio tra una coppia di componenti per comprendere la modalità di interazione di base dopo di che, viene discusso il caso, più significativo ma più complesso, di un sistema distribuito basato sullo scambio di numerosi messaggi tra molti componenti 12

7 Produttori, messaggi e consumatori Nella comunicazione asincrona, ciascuna singola interazione ha lo scopo di consentire ad un componente ( produttore ) di trasmettere dei dati (un messaggio ) ad un altro componente ( consumatore ) un primo componente (nel ruolo di produttore) ha dei dati che vuole che vengano elaborati ma lui non può elaborarli direttamente i dati potrebbero essere dei dati strutturati, un documento, una richiesta per un servizio (un comando) o una risposta, oppure la notifica di un evento allora, il produttore prepara un messaggio contenente questi dati, e poi lo invia ad un altro componente, che è in grado di elaborare oppure è interessato a elaborare quei dati quindi, un secondo componente (nel ruolo di consumatore) riceve questo messaggio e poi ne estrae di dati e li elabora 13 La comunicazione è indiretta Inoltre, la comunicazione è indiretta infatti, il componente produttore non trasmette il messaggio direttamente ad uno specifico componente consumatore piuttosto, il produttore invia il messaggio ad un canale per messaggi specifico per il tipo del messaggio trasmesso ma senza specificare l identità del consumatore del messaggio infatti, il produttore in genere non sa (o comunque non è interessato a sapere) qual è il componente che riceverà ed elaborerà il suo messaggio quindi, un consumatore riceve il messaggio prelevandolo da quel canale per messaggi il consumatore viene scelto tra quelli registrati presso quel canale per messaggi ovvero, tra i componenti che sono in grado di elaborare quello specifico tipo di messaggi dunque, il canale per messaggi costituisce un indirezione spaziale nella comunicazione tra produttore e consumatore 14

8 La comunicazione è asincrona Infine, la comunicazione è asincrona nel senso che l invio e la ricezione del messaggio non sono sincronizzate dopo che il produttore ha inviato il suo messaggio al canale per messaggi, prosegue nel suo lavoro il produttore non attende né che il messaggio sia stato ricevuto da un consumatore né che sia stato elaborato il consumatore del messaggio riceve ed elabora il messaggio appena è disponibile a farlo questo potrebbe avvenire subito dopo che il messaggio è stato inviato nel canale per messaggi ma anche più tardi inoltre, il consumatore in genere non comunica con il produttore del messaggio ricevuto né per notificargli la ricezione del messaggio né la sua elaborazione dunque, il canale per messaggi costituisce anche un indirezione temporale nella comunicazione tra produttore e consumatore 15 Un interazione di base nella comunicazione asincrona producer consumer 1: create 4: process 2: send 3: receive message channel data message 16

9 La comunicazione è indiretta La comunicazione è indiretta il produttore non invia il messaggio direttamente al consumatore del messaggio piuttosto, il produttore invia i suoi messaggi a un canale per messaggi intermedio il consumatore riceve i messaggi da questo canale producer consumer 1: create 4: process 2: send 3: receive 17 message channel La comunicazione è asincrona La comunicazione è asincrona il produttore comunica in una modalità send-and-forget dopo aver inviato il messaggio, prosegue il suo lavoro, e non attende che il consumatore abbia ricevuto o elaborato il suo messaggio il produttore può inviare un messaggio anche quando il consumatore non è ancora attivo o se non è stato nemmeno creato producer 1: create 2: send 18 message channel

10 La comunicazione è asincrona La comunicazione è asincrona il consumatore può ricevere un messaggio anche in un momento diverso da quando il messaggio è stato inviato il consumatore può ricevere un messaggio anche quando il produttore del messaggio non è più attivo consumer 4: process 3: receive 19 message channel Invocazione implicita Quando un consumatore riceve un messaggio, di solito lo elabora eseguendo un operazione o un metodo opportuno l operazione da eseguire viene scelta dal consumatore del messaggio, sulla base del contenuto del messaggio l operazione da eseguire non viene scelta sulla base di una richiesta diretta da parte del produttore del messaggio (che di solito non sa nemmeno qual è l interfaccia procedurale del consumatore) per questo, si parla anche di invocazione implicita infatti, l invocazione dell operazione eseguita per elaborare il messaggio è, appunto, implicita 20

11 e accoppiamento La comunicazione asincrona è caratterizzata da un accoppiamento basso più basso che non nell invocazione remota l uso dei messaggi consente un disaccoppiamento rispetto all interfaccia (operazioni) i componenti devono essere d accordo sul formato dei messaggi l uso dei canali per messaggi consente un disaccoppiamento (spaziale) rispetto all identità dei componenti i componenti non devono conoscersi tra di loro ma devono essere d accordo sul canale su cui scambiare i messaggi l uso dei canali per messaggi consente anche un disaccoppiamento temporale i componenti possono comunicare anche avendo un esistenza indipendente 21 Su produttore e consumatore Si noti che i termini produttore e consumatore hanno significato nell ambito dello scambio di ciascun singolo messaggio il componente che invia il messaggio è il produttore (producer) del messaggio chiamato talvolta anche publisher un componente che riceve il messaggio è un consumatore (consumer) del messaggio chiamato talvolta anche subscriber o listener Tuttavia, come discuteremo tra poco, ogni componente può sia inviare che ricevere messaggi dunque, in genere non c è una distinzione netta tra produttori e consumatori piuttosto, lo scambio di messaggi è una modalità di comunicazione tra pari (peer) 22

12 - Sistemi e comunicazione asincrona Finora abbiamo discusso solo il caso di una singola interazione nella comunicazione asincrona un singolo messaggio scambiato tra una coppia di componenti tramite un canale per messaggi in generale, in un sistema distribuito basato sullo scambio asincrono di messaggi, vengono scambiati una molteplicità di messaggi, tra numerosi componenti (produttori e/o consumatori) e tramite molti canali per messaggi l invio iniziale di un messaggio trovato da parte di un componente dà infatti di solito luogo ad un interazione che comprende lo scambio di molti messaggi tra diversi componenti l architettura di un sistema basato sullo scambio di messaggi può essere organizzata in termini dello stile Pipes and Filters 23 Sistemi e comunicazione asincrona L invio iniziale di un messaggio trovato da parte di un componente può dare luogo ad un interazione che comprende lo scambio di molti messaggi tra diversi componenti 24

13 Sistemi e comunicazione asincrona L architettura di un sistema basato sullo scambio di messaggi può essere organizzata in termini dello stile Pipes and Filters ci possono essere diversi componenti ed ogni componente può essere sia produttore che consumatore di messaggi ciascun componente può agire da filtro ( processor ) ovvero, può ricevere e consumare dei messaggi, elaborarli, e poi produrre e inviare altri messaggi l elaborazione di un messaggio iniziale trovato viene distribuita tra i diversi componenti del sistema ed effettuata in modo incrementale 25 Sistemi e comunicazione asincrona L architettura di un sistema basato sullo scambio di messaggi può essere organizzata in termini dello stile Pipes and Filters possono venire scambiati molti messaggi questi messaggi costituiscono dei flussi di dati all interno del sistema in generale, ciascun messaggio appartiene ad una specifica tipologia di messaggi predefinita, che i componenti sono interessati a scambiarsi ad es., Ordini, Richieste di spedizione, Fatture e Pagamenti 26

14 Sistemi e comunicazione asincrona L architettura di un sistema basato sullo scambio di messaggi può essere organizzata in termini dello stile Pipes and Filters ci sono in genere diversi canali per messaggi ciascun canale per messaggi è una pipe che rappresenta una specifica tipologia di messaggi ad es., un canale per gli Ordini ed uno per i Pagamenti dunque, a ciascuna diversa tipologia di messaggi corrisponde un canale distinto ogni canale è un indirizzo logico, tale che un componente produttore che vuole che venga elaborato un messaggio di un certo tipo, lo invia al canale per quel tipo di messaggi un componente consumatore che è in grado di elaborare oppure è interessato a ricevere messaggi di un certo tipo, li riceve dal canale per quel tipo di messaggi 27 Sistemi e comunicazione asincrona L architettura di un sistema basato sullo scambio di messaggi può essere organizzata in termini dello stile Pipes and Filters inoltre, tornando a parlare di componenti ci possono molti componenti in grado di produrre e inviare messaggi di un certo tipo ci possono essere anche molti componenti in grado di ricevere e consumare messaggi di un certo tipo in entrambi i casi, quando si parla di molti componenti, si può trattare di istanze multiple di uno stesso tipo di componente ciascuna delle quali effettua una stessa elaborazione oppure, di istanze di tipi di componenti diversi ciascuna delle quali effettua un elaborazione distinta 28

15 * Semantica della comunicazione asincrona La semantica della comunicazione asincrona riguarda diversi aspetti associati all invio di un messaggio M da parte di un componente (produttore) tra cui quanti e quali componenti (consumatori) riceveranno il messaggio M? è possibile che il messaggio M venga perso? che cosa succede se il messaggio M viene perso? che cosa succede se si verifica un guasto nel componente a cui è stato assegnato il compito di elaborare il messaggio M? 29 - Implementazione La comunicazione asincrona basata sullo scambio di messaggi è fornita da diversi servizi di middleware chiamati di solito message broker sono possibili diverse implementazioni un caso comune è un message broker implementato come un server centralizzato per gestire i canali per messaggi e lo scambio dei messaggi i canali (con i loro nomi e le loro caratteristiche) vanno in genere definiti nel message broker prima di iniziare lo scambio dei messaggi questo è analogo alla definizione dello schema di una base di dati (va definito prima di potervi inserire dei dati) ma talvolta sono definiti in modo dinamico poi, i componenti si scambiano messaggi, agendo come client nei confronti del message broker si noti che la comunicazione tra i componenti e il message broker è sincrona, anche se la comunicazione tra i componenti è invece asincrona 30

16 - Tipologie di canali per messaggi I diversi message broker offrono di solito due tipologie principali di canali per messaggi caratterizzate da una semantica differente point-to-point channel (canali punto-punto) chiamati anche queue (code) ciascun messaggio inviato a un canale point-to-point sarà consumato da uno e un solo consumatore è dunque un canale per la comunicazione a-uno publish-subscribe channel (canali publish-subscribe) chiamati anche canali pub-sub oppure topic ( argomenti ) ciascun messaggio inviato a un canale publish-subscribe può essere consumato da più consumatori, tutti quelli registrati presso il canale è un canale per la comunicazione a-molti 31 Canali e consumatori di messaggi In genere, per ciascun canale per messaggi sia nel caso di canale point-to-point che di canale publish-subscribe ci possono essere più componenti consumatori interessati a ricevere i messaggi inviati a quel canale per ricevere i messaggi per un canale C, i consumatori interessati devono di solito registrarsi (ovvero, abbonarsi o sottoscrivere) al canale C dopo di che, quando viene inviato un messaggio M sul canale C, il message broker assegna il compito di consumare il messaggio M ad uno o più tra i consumatori registrati a C se C è un canale publish-subscribe, a tutti i consumatori registrati a C se C è un canale point-to-point, ad uno solo dei consumatori registrati a C questo consumatore viene in genere scelto dal message broker 32

17 Canale point-to-point Produttore m5 invia m4 m3 m2 consuma m1 Consumatore coda 33 Canale point-to-point: più produttori Produttore 1 m14 m13 m22 m12 consuma m21 m11 Consumatore Produttore 2 m23 coda invia 34

18 Canale point-to-point: più consumatori m1 m8 m5 Consumatore 1 Produttore invia m7 m6 coda m4 Consumatore 2 consuma m3 m2 In questo caso, ciascun messaggio viene consumato da un solo consumatore. 35 Canale point-to-point: più produttori e più consumatori m21 m11 Produttore 1 m15 Consumatore 1 m13 m14 m23 Produttore 2 m24 coda m22 Consumatore 2 invia consuma m12 Anche in questo caso, ciascun messaggio viene consumato da un solo consumatore. Messaggi di uno stesso produttore possono essere consumati da consumatori diversi. 36

19 Canali point-to-point: più canali (più tipi di messaggi) Produttore 1 m14 m21 m11 m23 m13 m22 m12 consuma Consumatore 1 Produttore 2 invia coda A M31 M25 M21 Consumatore 2 M24 M33 Produttore 3 invia coda B M23 consuma Consumatore 3 M32 M22 37 Canale point-to-point: componenti consumatori/produttori Componente 1 m14 coda A m13 m12 m11 consuma Componente 2 invia M23 M22 coda B M21 Componente 3 38

20 Canale publish-subscribe m3 m2 m1 m7 m4 Consumatore 1 Produttore invia m5 m6 pub-sub m4 consuma Consumatore 2 m3 m2 m1 In questo caso, i messaggi possono essere consumati da più consumatori. 39 Canali publish-subscribe m21 m12 m11 Produttore 1 m14 m22 Consumatore 1 invia m13 m23 consuma m21 m12 m11 Produttore 2 m24 pub-sub A M32 m22 Consumatore 2 M31 M21 M23 invia M22 consuma Produttore 3 M34 M33 pub-sub B M32 Consumatore 3 M31 M21 40

21 - Prestazioni e scalabilità La comunicazione asincrona è una modalità di comunicazione che abilita prestazioni e scalabilità infatti, i messaggi vengono in genere trasmessi appena possibile, con una latenza bassa e un throughput elevato ad es., alcuni message broker (ottimizzati per le prestazioni e la scalabilità) consentono di gestire un numero di messaggi dell ordine del milione di messaggi al secondo (anche su piccoli cluster) inoltre, la possibilità di utilizzare più componenti consumatori per uno stesso tipo di messaggi favorisce sia prestazioni che scalabilità per la tattica Maintain multiple copies of computations 41 - Un esempio 42 Prima di andare avanti, è utile un esempio per descrivere un possibile scenario di applicazione della comunicazione asincrona consideriamo dei componenti che hanno dei dati che devono essere elaborati ad es., componenti che ricevono immagini da elaborare dagli utenti di un applicazione per ciascuno dei dati va eseguito un certo compito ad es., un ridimensionamento dell immagine il compito si può eseguire indipendentemente su ciascun dato ad es., separatamente per ciascuna immagine c è anche un componente in grado di svolgere questo compito il compito non va necessariamente svolto in modo sincrono, sulla base di un protocollo richiesta-risposta ciascun compito può produrre dei risultati, ma non necessariamente una risposta al componente che l ha richiesto

22 Un esempio In questo caso, potrebbe avere senso organizzare il sistema sulla base di componenti che comunicano in modo asincrono i componenti che hanno dati da elaborare agiscono da produttori di messaggi per ciascuno dei dati da elaborare, preparano un messaggio e lo inviano a un canale per messaggi ad es., un messaggio per ciascuna immagine da elaborare il componente che sa svolgere il compito agisce da consumatori di messaggi per ciascun messaggio ricevuto dal canale per messaggi, ne estrae il dato e lo elabora ad es., ridimensiona l immagine e la salva da qualche parte oppure invia l immagine ridimensionata come messaggio a un altro canale per messaggi 43 Un esempio Client 1 Ridimensiona immagini Client 2 immagini da ridimensionare immagini ridimensionate la comunicazione asincrona consente di gestire i compiti da svolgere in modo asincrono 44

23 Un esempio In questo caso, l uso di un canale point-to-point consente ai componenti produttori di inviare messaggi per chiedere l elaborazione dei loro dati anche quando attualmente non ci sono componenti consumatori pronti a svolgere il compito richiesto potrebbero essere attivati successivamente di avere più istanze di componenti consumatori in grado di svolgere il compito richiesto in modo da poter distribuire il carico dei compiti sulle diverse istanze presenti di poter variare dinamicamente il numero di istanze di componenti consumatori per svolgere il compito richiesto in caso di aumento del carico dei messaggi da elaborare e di poterlo diminuire quando il carico diminuisce sostenendo così la scalabilità nell esecuzione del compito 45 Un esempio Ridimensiona immagini Client 1 Ridimensiona immagini Client 2 immagini da ridimensionare Ridimensiona immagini immagini ridimensionate un canale point-to-point consente di distribuire il carico relativo ad un compito da svolgere tra più componenti consumatori che possono operare in modo indipendente sui messaggi individuali 46

24 Un esempio Invece, l uso di un canale publish-subscribe è utile quando per ciascun messaggio vanno svolti più compiti separati ad es., se ciascuna immagine va sia ridimensionata che convertita in bianco e nero (indipendentemente) in questo caso è possibile avere per ciascun diverso compito un componente (consumatore) differente, in grado di svolgere solo quel compito un canale publish-subscribe consente di distribuire una copia del messaggio a ciascuno dei consumatori ciascuno dei quali svolgerà il suo compito indipendentemente dagli altri consumatori inoltre, se sorgesse l esigenza di dover svolgere dei nuovi compiti per ciascuno dei messaggi, l uso di un canale publishsubscribe consente di aggiungere dinamicamente nuovi componenti in grado di svolgere i compiti aggiuntivi senza ripercussioni né sui produttori né sugli altri consumatori 47 Un esempio Ridimensiona immagini Client 1 immagini ridimensionate Client 2 immagini da elaborare Converte immagini in B/N immagini in bianco e nero un canale publish-subscribe consente di distribuire il carico relativo a più compiti da svolgere tra più componenti consumatori, ciascuno dei quali è in grado di svolgere in modo indipendente un compito differente 48

25 Un esempio Ridimensiona immagini Client 1 immagini ridimensionate Client 2 immagini da elaborare Converte immagini in B/N immagini in bianco e nero Riconosci volti volti riconosciuti un canale publish-subscribe consente di aggiungere dinamicamente nuovi componenti per svolgere dei compiti aggiuntivi 49 Discussione Questo esempio consente di comprendere il supporto fornito dalla comunicazione asincrona a diverse qualità la modificabilità in virtù dell accoppiamento basso tra componenti prestazioni e scalabilità anche grazie alla possibilità di replicare componenti 50

26 - Altri tipi di canali per messaggi In pratica, i message broker esistenti offrono anche diverse varianti rispetto a quanto descritto finora o nel seguito di questa dispensa ad es., Kafka (un servizio di middleware per messaggi) prevede un solo tipo ( ibrido ) di canale per messaggi inoltre, introduce una nozione aggiuntiva di gruppo di componenti, tale che un messaggio inviato ad un canale viene consegnato ad un solo componente per ciascun gruppo se tutti i consumatori per un canale appartengono ad uno stesso gruppo, allora il canale ha una semantica di tipo point-to-point se ogni consumatore per un canale appartiene ad un gruppo distinto, il canale ha una semantica di tipo publish-subscribe ma sono possibili anche modalità di consegna diverse, se i consumatori per un canale sono suddivisi in più gruppi 51 - Aspetti temporali La semantica della comunicazione asincrona può prevedere delle ulteriori varianti, in relazione ad aspetti temporali, nonché alla modalità di memorizzazione dei messaggi nel message broker in genere, un messaggio inviato ad un canale point-to-point viene conservato nel message broker fino a quando non è stato consegnato ad un componente consumatore registrato a quel canale dopo di che, il messaggio viene cancellato dunque, un messaggio viene mantenuto in un canale pointto-point anche se, quando è stato inviato, non c è nessun consumatore registrato a quel canale tuttavia, è anche possibile assegnare ad un messaggio una durata o scadenza dopo di che, quando il messaggio scade, viene cancellato, anche se non è stato consegnato a nessun consumatore 52

27 Aspetti temporali La semantica della comunicazione asincrona può prevedere delle varianti, in relazione ad aspetti temporali, nonché alla modalità di memorizzazione dei messaggi nel message broker invece, un messaggio inviato ad un canale publish-subscribe viene in genere consegnato a tutti i consumatori attualmente registrati presso quel canale dopo di che, di solito il messaggio viene cancellato un consumatore registrato presso un canale publishsubscribe riceve solo i messaggi inviati a quel canale durante il periodo della sua registrazione se un messaggio viene inviato ad un canale publishsubscribe quando presso quel canale non è registrato nessun consumatore, allora il messaggio viene cancellato anche senza che sia stato consegnato a nessun consumatore 53 Aspetti temporali La semantica della comunicazione asincrona può prevedere delle varianti, in relazione ad aspetti temporali, nonché alla modalità di memorizzazione dei messaggi nel message broker tuttavia, è anche possibile che un canale publish-subscribe sia persistente oppure che le registrazioni al canale siano durature nel caso di un canale publish-subscribe persistente, tutti i consumatori registrati presso il canale possono ricevere tutti i messaggi inviati a quel canale nel caso di registrazioni durature ad un canale publishsubscribe, un consumatore può ricevere tutti i messaggi inviati a quel canale durante il periodo della sua registrazione anche se il consumatore si disconnette temporaneamente dal canale (in questo caso, registrazione e connessione sono nozioni distinte) 54

28 Discussione La memorizzazione dei messaggi nel message broker richiede risorse la gestione delle scadenze, dei canali persistenti e delle registrazioni durature richiede una quantità di risorse ancora maggiore in generale, la modalità di memorizzazione dei messaggi va configurata in modo dipendente anche dal contesto applicativo 55 - Ordinamento dei messaggi In alcune situazioni, è possibile che un consumatore riceva i messaggi inviati da un produttore in un ordine differente da quello in cui sono stati inviati e questo potrebbe essere problematico in particolare, questo può accadere quando il message broker è implementato da un cluster di nodi (per motivi di scalabilità) ed i diversi messaggi transitano su nodi diversi se l ordine in cui sono stati inviati i messaggi è importante, allora i consumatori devono prevedere la possibilità di ricevere messaggi fuori ordine in alcuni casi, il message broker può fornire meccanismi per garantire la consegna in ordine di gruppi di messaggi correlati 56

29 - Duplicazione di messaggi Idealmente, il message broker dovrebbe consegnare ciascun messaggio con una semantica exactly-once tuttavia, la consegna dei messaggi avviene in genere con una semantica atmost-once oppure at-least-once quando il sistema opera normalmente, ciascun messaggio viene in effetti consegnato una sola volta tuttavia, in alcune situazioni anomale è possibile che un messaggio non venga consegnato o venga consegnato più volte in quest ultimo caso, se opportuno, l elaborazione effettuata dal consumatore del messaggio dovrebbe essere idempotente in alternativa, può essere opportuno l uso di un meccanismo di identificazione dei messaggi duplicati, per poterli ignorare tuttavia, questo è problematico quando ci sono più consumatori per uno stesso tipo di messaggi 57 - Affidabilità Un message broker può offrire diverse opzioni di consegna dei messaggi a cui corrispondono livelli differenti di affidabilità consegna non persistente (di tipo best effort) i messaggi inviati al message broker possono perdersi ad es., se il message broker fallisce oppure viene riavviato consegna persistente il message broker registra in memoria secondaria i messaggi che gli vengono inviati, che pertanto non possono perdersi nemmeno se il message broker fallisce oppure se viene riavviato 58

30 Affidabilità Un message broker può offrire diverse opzioni di consegna dei messaggi a cui corrispondono livelli differenti di affidabilità acknowledgment il message broker considera un messaggio consumato con successo quando il consumatore a cui ha assegnato il messaggio conferma la ricezione del messaggio tuttavia, un messaggio potrebbe non venire elaborato, se il consumatore a cui è stato assegnato fallisce (va in crash) consegna transazionale il message broker considera un messaggio consumato con successo quando il consumatore a cui viene assegnato il messaggio conferma l avvenuta elaborazione del messaggio se il consumatore a cui è stato assegnato un messaggio fallisce, allora il message broker riassegna il messaggio ad un altro consumatore 59 Affidabilità Un message broker può offrire diverse opzioni di consegna dei messaggi a cui corrispondono livelli differenti di affidabilità transazioni un componente può specificare una transazione per eseguire in modo atomico la ricezione e/o l invio di uno o più messaggi se la transazione fallisce, il message broker assegna i messaggi ad altri consumatori attenzione, in genere ciascuna transazione individuale può riguardare solo le attività svolte da un singolo componente ma non può includere, ad es., l invio di un messaggio da parte di un componente e la sua ricezione ed elaborazione da parte di un altro componente queste attività devono appartenere a transazioni distinte le transazioni possono includere anche compiti più ampi ad es., l accesso a una base di dati 60

31 Discussione Le diverse opzioni per l affidabilità richiedono risorse sul message broker via via maggiori l aumento dell affidabilità va di solito a scapito delle prestazioni e della scalabilità in generale, il livello di affidabilità va configurato in modo dipendente anche dal contesto applicativo 61 e affidabilità Dunque, la comunicazione asincrona è una modalità di comunicazione che abilita anche l affidabilità come abbiamo appena visto, la consegna dei messaggi può essere configurata con riferimento a diversi livelli di affidabilità inoltre, l affidabilità (tolleranza ai guasti) è sostenuta anche dalla possibilità di utilizzare repliche ridondanti dei componenti consumatori 62

32 - Modalità di consumo dei messaggi La ricezione di un messaggio da parte di un consumatore può avvenire secondo due modalità principali polling il consumatore, quando è disponibile, chiede al message broker un messaggio (se c è) da un certo canale, per poterlo elaborare subscription il consumatore si registra presso il message broker per ricevere messaggi inviati su un certo canale quando viene inviato un messaggio su un canale, il message broker lo assegna a dei consumatori registrati a quel canale scelti usando un algoritmo opportuno invocando un operazione del consumatore molti message broker (e framework per il loro accesso) privilegiano la modalità subscription 63 - Eventi di dominio Una possibile applicazione della comunicazione asincrona è la notifica di eventi un evento di dominio [DDD] rappresenta qualcosa di interessante che è avvenuto nel dominio di un componente o servizio ad es., un cambiamento di stato di un oggetto del dominio, RestaurantCreated oppure RestaurantMenuRevised interessante, nel senso che bisogna tenerne traccia, oppure perché va notificato ad altri componenti o servizi un componente produttore può inviare messaggi relativi ai propri eventi di dominio in genere in un canale publishsubscribe specifico per gli eventi di quel componente i componenti interessati a questi eventi possono abbonarsi a questo canale e comportarsi da consumatori di questi eventi di dominio e reagire in modo opportuno quando ricevono un evento di dominio di interesse 64

33 -Comandi Un altra possibile applicazione della comunicazione asincrona è l invocazione asincrona di operazioni remote un comando [GoF] rappresenta una richiesta di eseguire un operazione ad un componente o servizio, che include anche parametri della richiesta ad es., una richiesta CreateRestaurant oppure ReviseRestaurantMenu un componente consumatore può ricevere messaggi che rappresentano comandi di richiesta per le proprie operazioni in genere in un canale point-to-point specifico per i comandi di quel componente l elaborazione dei comandi ricevuti avviene mediante un opportuno command handler i componenti interessati a richiedere l esecuzione asincrona di operazioni remote possono inviare messaggi per comandi a questo canale 65 - Documenti Un altra possibile applicazione della comunicazione asincrona è la trasmissione di documenti un documento è un messaggio generico che contiene solo dei dati ad es., una risposta ad una richiesta oppure un gruppo di dati da elaborare ad es., RestaurantMenuRevision oppure un immagine da elaborare il componente consumatore di un documento decide come interpretare ed elaborare il messaggio ricevuto ( invocazione implicita ) i documenti di una certa tipologia (ad es., immagini da elaborare) vengono in genere scambiati su un canale pointto-point o publish-subscribe specifico per quella tipologia di documenti 66

34 * Discussione La comunicazione asincrona è un astrazione di programmazione distribuita basata sullo scambio di messaggi consente ad un componente di inviare un messaggio (contenente dei dati o la notifica di un evento), in modo indiretto ed asincrono, ad uno o più componenti, affinché questi possano elabora il messaggio è una modalità di comunicazione complementare all invocazione remota sostiene qualità come modificabilità (accoppiamento basso e maggior flessibilità nella comunicazione), prestazioni, scalabilità ed affidabilità come discuteremo in una successiva dispensa, questo stile di comunicazione è sostenuto dal pattern architetturale Messaging [POSA] 67 Quando usare la comunicazione asincrona? Quando preferire la comunicazione asincrona all invocazione remota? se i componenti di un applicazione possono non essere tutti attivi contemporaneamente se i componenti possono essere progettati in modo tale da inviare informazioni ad altri componenti continuando a lavorare anche senza ricevere una risposta immediata se i componenti devono/possono essere progettati in modo da ignorare le interfacce degli altri componenti, basando la comunicazione solo sul formato dei messaggi scambiati come caso estremo, se i componenti che devono comunicare sono stati sviluppati indipendentemente l uno dall altro (integrazione di applicazioni) questo è un aspetto metodologico importante, che riprenderemo in successive dispense 68

35 Benefici della comunicazione asincrona Benefici della comunicazione asincrona una forma di comunicazione remota comunicazione indiretta comunicazione asincrona temporizzazione variabile ogni componente può partecipare all interazione secondo la propria velocità eliminazione di colli di bottiglia nella comunicazione sincrona, un numero elevato di richieste concorrenti può sovraccaricare il server abilita operazioni disconnesse affidabilità della comunicazione può favorire l integrazione tra linguaggi e piattaforme consente una migliore gestione dei thread 69 Sfide della comunicazione asincrona Sfide legate all uso della comunicazione asincrona maggior complessità del paradigma di programmazione basato sullo scambio di messaggi asincroni (vedi lucido successivo) l overhead della comunicazione (e della codifica e decodifica dei messaggi) può avere un impatto negativo sulle prestazioni problemi indotti dall ordine di ricezione dei messaggi talvolta è comunque necessario gestire anche scenari che sono inerentemente sincroni molti strumenti di comunicazione asincrona sono basati su protocolli e implementazioni proprietarie il vendor lock-in può limitare la portabilità 70

36 Sfide della comunicazione asincrona Alcune implicazioni della comunicazione asincrona non c è più un singolo thread di esecuzione la concorrenza favorisce prestazioni e scalabilità ma rende la verifica più difficile se l esecuzione di un operazione prevede dei risultati, anche questi arrivano di solito in modo asincrono, mediante dei callback i componenti devono prevedere l interruzione delle loro attività per gestire notifiche di questo tipo l esecuzione dei thread di un componente che operano in modo asincrono può avvenire in un ordine qualunque i diversi thread devono essere programmati per poter lavorare indipendentemente dagli altri poi, per il componente, può essere più difficile combinare i risultati prodotti dai diversi thread 71