I prodotti per la messaggistica sono intrinsecamente asincroni, nel senso che c’è indipendenza temporale tra la produzione ed il consumo dei messaggi.
Applicando opportuni patterns è possibile attivare comunicazioni sincrone su infrastrutture tipicamente asincrone.
Ci sono due principali patterns (tecniche) per il messaging con le proprie varianti:
Il pattern “fire-and-forget” supporta una comunicazione unidirezionale tra produttore e consumatore del messaggio, mentre il pattern “request-reply” offre funzionalità per una comunicazione bidirezionale.
Fire-and-Forget
Fire-and-Forget è il più semplice tra i patterns di messaggistica; è una comunicazione di tipo unidirezionale dal consumatore verso il fornitore del servizio.
Il consumatore non si aspetta alcuna risposta da parte del fornitore per cui, immediatamente dopo l’invio del messaggio, continuerà con l’elaborazione.
Il pattern fire-and-forget fornisce un elevato livello di disaccoppiamento tra le due parti ed è generalmente utilizzato per semplici operazioni su ambienti asincroni in cui non c’è interesse per il risultato.
Il MOM garantisce al consumatore che l’endpoint remoto riceverà il messaggio spedito.
Request-reply
Vi sono scenari in cui il risultato dell’elaborazione del processo remoto è necessario al processo chiamante.
Il pattern request-reply supporta la comunicazione bidirezionale tra un consumatore e un fornitore di servizio: ad una richiesta da parte del consumatore corrisponde una risposta del fornitore.
La risposta può contenere una notifica di ricevimento della richiesta o il risultato dell’elaborazione della richiesta stessa da parte del fornitore.
Il pattern può essere utilizzato sia per comunicazioni sincrone che asincrone e può richiedere un forte accoppiamento tra consumatore e fornitore. Ulteriori logiche sono necessarie per correlare le richieste con le risposte e per gestire i ritardi (o le mancate ricezioni) delle risposte.
La scelta del pattern request-replay con comunicazione sincrona o asincrona dipende dallo scenario.
Per modalità online, ad esempio nel caso di applicazioni Web, il pattern request-replay con variante sincrona è consigliato, in quanto l’utente vuole ricevere notifica immediata alla propria richiesta ed è disposto a bloccarsi in sua attesa per un tempo ragionevole.
Per modalità batch è più indicato il pattern request-replay con variante asincrona in quanto bloccare il processo sarebbe poco performante. Inoltre, una serie di richieste può essere inviata in blocco per poi ricevere la serie di tutte le risposte in un secondo momento.
Tag: fire, forget, messaging, modelli, pattern, patterns, reply, request
