Un broker di messaggi è un software che consente ad applicazioni, sistemi e servizi di comunicare tra loro e e scambiare informazioni. Il broker di messaggi esegue questa operazione convertendo i messaggi tra i protocolli di messaggistica formali. Questo consente ai servizi interdipendenti di "parlare" direttamente tra loro, anche se scritti in linguaggi differenti o implementati su piattaforme differenti.

I broker di messaggi sono moduli software all'interno di soluzioni middleware di messaggistica o MOM (message-oriented middleware). Questo tipo di middleware fornisce agli sviluppatori un mezzo standardizzato per gestire il flusso di dati tra i componenti di un'applicazione per consentire loro di concentrarsi sulla sua logica di base. Può essere utilizzato come livello di comunicazione distribuito che consente alle applicazioni che si estendono su più piattaforme di comunicare internamente.

I broker di messaggi possono convalidare, archiviare, instradare e consegnare i messaggi alle destinazioni appropriate. Fungono da intermediari tra le altre applicazioni, consentendo ai mittenti di emettere messaggi senza sapere dove si trovano i destinatari, se sono attivi o meno o quanti ne sono. Questo semplifica la separazione di processi e servizi all'interno dei sistemi.

Per fornire uno storage di messaggi affidabile e una consegna garantita, i broker di messaggi spesso si basano su una sottostruttura o un componente chiamato  coda di messaggi  che archivia e ordina i messaggi fino a quando non possono essere elaborati dalle applicazioni che li utilizzano. In una coda di messaggi, i messaggi vengono archiviati nell'esatto ordine in cui sono stati trasmessi e restano nella coda fino a quando non viene confermata la ricezione.

Il termine messaggistica asincrona (15:11) si riferisce al tipo di comunicazione tra applicazioni reso possibile dai broker di messaggi. Impedisce la perdita di dati preziosi e consente ai sistemi di continuare a funzionare anche in caso di problemi di latenza o connettività intermittente, comuni su  reti pubbliche. La messaggistica asincrona assicura che i messaggi vengano consegnati una volta (ed una volta sola) nell'ordine corretto rispetto agli altri messaggi.

I broker di messaggi possono comprendere gestori code per gestire le interazioni tra più code di messaggi, nonché servizi che offrono funzionalità di instradamento dei dati, conversione dei messaggi, persistenza e gestione dello stato del client.

I broker di messaggi offrono due modelli di distribuzione dei messaggi o stili di messaggistica di base:

Messaggistica point-to-point:  questo è il modello di distribuzione utilizzato nelle code di messaggi con una relazione uno a uno tra il mittente ed il destinatario del messaggio. Ogni messaggio nella coda viene inviato a un solo destinatario e viene utilizzato una sola volta. La messaggistica point-to-point è appropriata quando si deve intervenire su un messaggio una sola volta. Gli esempi di casi di utilizzo adatti per questo stile di messaggistica includono l'elaborazione delle transazioni finanziarie e delle buste paga. In questi sistemi, sia i mittenti che i destinatari hanno bisogno della garanzia che ogni pagamento verrà inviato una e una sola volta.

Messaggistica di pubblicazione/sottoscrizione:  in questo modello di distribuzione dei messaggi, spesso indicato come "pub/sub", l'autore di ciascun messaggio lo pubblica in un argomento e più utenti del messaggio effettuano la sottoscrizione agli argomenti da cui desiderano ricevere messaggi. Tutti i messaggi pubblicati in un argomento sono distribuiti a tutte le applicazioni che lo hanno sottoscritto. Si tratta di un metodo di distribuzione di tipo trasmissione, in cui esiste una relazione uno a molti tra l'autore del messaggio ed i relativi utenti. Se, ad esempio, una compagnia aerea dovesse diffondere aggiornamenti sugli orari di atterraggio o sullo stato di ritardo dei propri voli, più parti potrebbero utilizzare le informazioni: personale a terra che esegue la manutenzione ed il rifornimento dell'apparecchio, addetti ai bagagli, assistenti di volo e piloti che si preparano per il successivo viaggio dell'aereo e gli operatori dei pannelli che forniscono informazioni al pubblico. In questo scenario, l'uso di uno stile di messaggistica pub/sub sarebbe appropriato.

Le applicazioni native del cloud  sono realizzate per sfruttare i vantaggi intrinseci del  cloud computing, tra cui flessibilità, scalabilità e implementazione rapida. Queste applicazioni sono costituite da piccoli componenti discreti e riutilizzabili, chiamati microservizi. Ogni microservizio viene implementato e può essere eseguito indipendentemente dagli altri. Ciò significa che ognuno di essi può essere aggiornato, scalato o riavviato senza alcuna ripercussione sugli altri servizi nel sistema. Spesso forniti in  container, i microservizi lavorano insieme per costituire un'intera applicazione, sebbene ognuno abbia il proprio stack, incluso un database ed un modello di dati che può essere diverso dagli altri.

I microservizi devono disporre di un mezzo per comunicare tra loro al fine di operare insieme. I broker di messaggi sono un meccanismo che utilizzano per creare questa struttura portante di comunicazioni condivisa.

I broker di messaggi sono spesso utilizzati per gestire le comunicazioni tra sistemi on-premise e componenti cloud in ambienti di  cloud ibrido.  L'utilizzo di un broker di messaggi fornisce maggiore controllo sulle comunicazioni tra servizi, assicurando che i dati siano inviati in modo sicuro, affidabile ed efficiente tra i componenti di un'applicazione. I broker di messaggi possono giocare un ruolo simile nell'integrazione degli ambienti  multicloud,  abilitando le comunicazioni tra carichi di lavoro e runtime che risiedono su piattaforme differenti. Sono anche adatti per l'uso  nell'elaborazione serverless, in cui i singoli servizi ospitati nel cloud vengono eseguiti on-demand in base alle richieste.

Le API REST  sono comunemente utilizzate per le comunicazioni tra microservizi. Il termine REST (Representational State Transfer) definisce un insieme di principi e vincoli a cui gli sviluppatori possono attenersi quando creano dei servizi web. Qualsiasi servizio che li rispetta sarà in grado di comunicare mediante un set di operatori e richieste stateless condivisi uniformi. L'API (Application Programming Interface) denota il codice sottostante che, se conforme alle regole REST, consente ai servizi di comunicare tra loro.

Le API REST utilizzano HTTP (Hypertext Transfer Protocol) per comunicare. Poiché HTTP è il protocollo di trasporto standard di Internet pubblico, le API REST sono ampiamente conosciute, frequentemente utilizzate e largamente interoperabili. Tuttavia, HTTP è un protocollo di richiesta/risposta, quindi il suo utilizzo è particolarmente indicato nelle situazioni che richiedono una richiesta/risposta sincrona. Ciò significa che i servizi che effettuano le richieste tramite le API REST devono essere progettati per aspettarsi una risposta immediata. Se il client che riceve la risposta è inattivo, il servizio mittente sarà bloccato mentre attende la risposta. La logica di failover e di gestione degli errori deve essere integrata in entrambi i servizi.

I broker di messaggi abilitano le comunicazioni asincrone tra i servizi in modo che il servizio mittente non debba attendere la risposta del servizio ricevente. Questo migliora la tolleranza agli errori e la resilienza nei sistemi in cui sono adottati. Inoltre, l'utilizzo dei broker di messaggi rende più facile la scalabilità dei sistemi in quanto un modello di messaggistica pub/sub può supportare facilmente un numero variabile di servizi. I broker di messaggi inoltre tengono traccia degli stati degli utenti.

Mentre i broker di messaggi possono supportare due o più modelli di messaggistica, incluse le code di messaggi e pub/sub, le piattaforme di streaming degli eventi offrono solo modelli di distribuzione di tipo pub/sub. Progettate per l'utilizzo con elevati volumi di messaggi, le piattaforme di streaming di eventi sono prontamente scalabili. Sono in grado di ordinare i flussi di record in categorie, denominate argomenti, e di archiviarli per un lasso di tempo predeterminato. A differenza dei broker di messaggi, tuttavia, le piattaforme di streaming degli eventi non possono garantire la consegna dei messaggi o tenere traccia degli utenti che hanno ricevuto i messaggi.

Le piattaforme di streaming degli eventi offrono più scalabilità rispetto ai broker di messaggi ma un numero minore di funzioni che assicurano la tolleranza agli errori (come il reinvio dei messaggi), oltre a funzionalità di accodamento e instradamento dei messaggi più limitate.

Scopri di più  sull'architettura basata sugli eventi.

Un  ESB (Enterprise Service Bus)  è un modello architetturale utilizzato a volte nelle  architetture orientate ai servizi (SOA, service oriented architecture)  implementate nelle aziende. In un ESB, una piattaforma software centralizzata combina protocolli di comunicazione e formati di dati in un "linguaggio comune" che tutti i servizi e tutte le applicazioni nell'architettura possono condividere. Potrebbe, ad esempio, convertire le richieste che riceve da un protocollo (come XML) a un altro (come JSON). Gli ESB trasformano i loro payload di messaggio utilizzando un processo automatizzato. La piattaforma di software centralizzata gestisce anche altre logiche di orchestrazione, come connettività, instradamento ed elaborazione delle richieste.

Tuttavia, le infrastrutture ESB sono complesse e possono essere difficili da integrare e costose da mantenere. È difficile risolvere i problemi quando questi si verificano negli ambienti di produzione, non sono semplici da scalare e l'aggiornamento è noioso.

I broker di messaggi sono un'alternativa "leggera" agli ESB che forniscono una funzionalità simile - un meccanismo per comunicazioni tra servizi - più semplice e ad un costo inferiore. Sono adatti per l'uso nelle architetture di microservizi che sono diventate più diffuse quando gli ESB sono diventati meno utilizzati.

L'implementazione dei broker dei messaggi può soddisfare un'ampia varietà di esigenze aziendali in tutti i settori e all'interno di ambienti informatici aziendali eterogenei. Sono utili quando e dove sono richieste comunicazioni affidabili tra le applicazioni e una consegna garantita dei messaggi.

I broker di messaggi sono spesso impiegati nei seguenti modi:

• Transazioni finanziarie ed elaborazione dei pagamenti: è fondamentale essere certi che i pagamenti vengano effettuati una ed una sola volta. L'utilizzo di un broker di messaggi per gestire questi dati delle transazioni offre la garanzia che le informazioni di pagamento non verranno perse né duplicate accidentalmente, fornisce una prova di avvenuta ricezione e consente ai sistemi di comunicare in modo affidabile anche quando le reti intermedie sono inattive.
  
  
• Elaborazione ed evasione degli ordini e-commerce: se la tua azienda si occupa di commercio online, la reputazione del tuo marchio dipende dall'affidabilità del tuo sito Web e della piattaforma di e-commerce. La capacità dei broker di messaggi di migliorare la tolleranza agli errori e garantire che i messaggi vengano utilizzati una sola volta e basta li rende una scelta naturale da utilizzare quando si elaborano gli ordini online.
  
  
• Protezione di dati altamente sensibili inattivi e in transito: se il settore in cui operi è altamente regolamentato o la tua azienda deve affrontare rischi di sicurezza significativi, scegli una soluzione di messaggistica con funzioni di crittografia end-to-end.