I broker offrono due modelli di distribuzione dei messaggi, detti anche "stili di messaggistica":

Messaggistica point-to-point: questo è il modello di distribuzione utilizzato nelle code di messaggi con una relazione one-to-one tra il mittente e il destinatario. Ogni messaggio nella coda viene inviato a un solo destinatario, e viene consumato una sola volta. La messaggistica point-to-point è necessaria quando è necessario agire su un messaggio una sola volta. Tra i casi d'uso idonei a questo modello di messaggistica figurano l'elaborazione di buste paga e di transazioni finanziarie. In questi sistemi, sia i mittenti che i destinatari devono garantire che ogni pagamento venga inviato una sola volta.

Messaggistica publish/subscribe: In questo schema di distribuzione dei messaggi, spesso abbreviato in «pub/sub», il mittente di ciascun messaggio lo pubblica iscrivendolo in una data categoria, e coloro che desiderano riceverlo si "abbonano" alla categoria per la quale vogliono ricevere i messaggi. Tutti i messaggi pubblicati in una data categoria vengono distribuiti a tutte le applicazioni abbonate. Si tratta di un metodo di distribuzione ad ampio spettro, in cui la relazione che lega mittenti e destinatari è del tipo one-to-many. Se, ad esempio, una compagnia aerea dovesse diffondere aggiornamenti sui tempi di atterraggio o sullo stato dei ritardi dei suoi voli, sono molteplici i destinatari che potrebbero sfruttare queste informazioni: il personale di terra che esegue la manutenzione e il rifornimento dell'aeromobile, gli addetti ai bagagli, gli assistenti di volo e i piloti che si preparano per la tratta successiva dell'aereo, e gli operatori dei display che informano il pubblico. In questo scenario è indicato utilizzare uno stile di messaggistica pub/sub.

Le applicazioni cloud-native sono progettate per sfruttare i vantaggi intrinseci del cloud computing, tra cui flessibilità, scalabilità e rapidità di distribuzione. Queste applicazioni sono costituite da componenti piccoli, discreti e riutilizzabili denominati microservizi. Ogni microservizio viene distribuito, e può essere eseguito, indipendentemente dagli altri. Ciò significa che ognuno di essi può essere aggiornato, scalato o riavviato senza influire sugli altri servizi del sistema. I microservizi sono spesso confezionati in container, e lavorano all'unisono per comporre un'intera applicazione, sebbene ognuno abbia il proprio stack, inclusi un database e un modello di dati che possono essere diversi dagli altri.

Per poter operare in modo coordinato, i microservizi devono disporre di un mezzo attraverso il quale comunicare reciprocamente. I broker di messaggi sono proprio uno dei meccanismi utilizzati per creare questa dorsale di comunicazione condivisa.

I broker di messaggi spesso vengono utilizzati per gestire le comunicazioni tra sistemi on-premise e componenti cloud in ambienti hybrid cloud. L'utilizzo di un broker di messaggi offre un maggiore controllo sulle comunicazioni tra servizi, garantendo che i dati vengano inviati in modo sicuro, affidabile ed efficiente tra i componenti di un'applicazione. I broker di messaggi possono svolgere un ruolo simile nell'integrazione di ambienti multicloud, consentendo la comunicazione tra workload e runtime presenti su piattaforme differenti. Sono inoltre adatti per l'uso nel serverless computing, in cui i singoli servizi ospitati su cloud vengono eseguiti sulla domanda in base alla richiesta.

Le API REST sono utilizzate comunemente per le comunicazioni tra microservizi. Il termine Representational State Transfer (REST) definisce una serie di principi e vincoli che gli sviluppatori possono seguire nella creazione di servizi web. Tutti i servizi che vi aderiranno saranno in grado di comunicare attraverso una serie di operatori e richieste senza stato e condivisi. L'API (Application Programming Interface) indica il codice sottostante che, se conforme alle regole REST, consente ai servizi di comunicare tra loro.

Le API REST utilizzano il protocollo HTTP (Hypertext Transfer Protocol) per comunicare. Poiché HTTP è il protocollo di trasporto standard dell'Internet pubblico, le API REST sono largamente conosciute, utilizzate di frequente e ampiamente interoperabili. Tuttavia, HTTP è un protocollo di richiesta/risposta, quindi dà il meglio di sé in situazioni che richiedono una richiesta/risposta sincrona. Ciò significa che i servizi che effettuano richieste tramite API REST devono essere progettati in modo da aspettarsi una risposta immediata. Se il client che riceve la risposta è inattivo, il servizio di invio verrà bloccato in attesa della risposta. La logica di failover e di gestione degli errori deve essere incorporata in entrambi i servizi.

I broker di messaggi consentono le comunicazioni asincrone tra i servizi, in modo che il servizio di invio non debba attendere la risposta del servizio di ricezione. Ciò migliora la tolleranza ai guasti e la resilienza nei sistemi in cui vengono impiegati. Inoltre, l'uso di broker di messaggi semplifica la scalabilità dei sistemi poiché un modello di messaggistica pub/sub può supportare facilmente la modifica del numero di servizi. I broker di messaggi tengono inoltre traccia degli stati dei consumatori.

Mentre i broker di messaggi possono supportare due o più modelli di messaggistica, tra cui code di messaggi e pub/sub, le piattaforme di event streaming offrono solo modelli di distribuzione in stile pub/sub. Essendo progettate per volumi elevati di messaggi, le piattaforme di event streaming sono facilmente scalabili. Esse sono in grado di ordinare i flussi di record in categorie e di archiviarli per un periodo di tempo predeterminato. A differenza dei broker di messaggi, tuttavia, le piattaforme di event streaming non possono garantire la consegna dei messaggi né registrare quali consumatori li abbiano effettivamente ricevuti.

Le piattaforme di event streaming offrono maggiore scalabilità rispetto ai broker di messaggi, ma meno funzionalità a garanzia della tolleranza agli errori (come il reinvio di messaggi), oltre a capacità di routing e accodamento dei messaggi più limitate.

Maggiori informazioni sull'architettura basata su eventi.

Un'enterprise service bus (ESB) è un modello architettonico talvolta utilizzato nelle architetture orientate ai servizi (SOA) 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 le applicazioni dell'architettura possono condividere. Ad esempio, potrebbe tradurre le richieste ricevute da un protocollo (come XML) a un altro (come JSON). Gli ESB trasformano i carichi utili dei messaggi utilizzando un processo automatizzato. La piattaforma software centralizzata gestisce anche altre logiche di orchestrazione, come la connettività, il routing e l'elaborazione delle richieste.

Le infrastrutture ESB sono piuttosto complesse, e possono essere difficili da integrare e costose da mantenere. La risoluzione di problemi insorti negli ambienti di produzione non è semplice, non sono sistemi facili da scalare e il processo di aggiornamento è lungo e tedioso.

I broker di messaggi sono un'alternativa «leggera» agli ESB che forniscono una funzionalità simile, un meccanismo per le comunicazioni interservizi, in modo più semplice e a costi inferiori. Sono adatti all'uso nelle architetture di microservizi, che sono diventate sempre più diffuse con il declino degli ESB.

L'implementazione di broker di messaggi può soddisfare un'ampia varietà di esigenze aziendali in tutti i settori e all'interno di diversi ambienti informatici aziendali. Sono utili ogniqualvolta siano necessarie comunicazioni affidabili tra applicazioni e una consegna sicura dei messaggi.

I broker di messaggi vengono spesso impiegati nei seguenti modi:

• Transazioni finanziarie ed elaborazione dei pagamenti: È fondamentale assicurarsi che i pagamenti vengano inviati una sola volta. L'utilizzo di un broker di messaggi per gestire i dati di queste transazioni offre la garanzia che le informazioni di pagamento non andranno perse né duplicate accidentalmente, fornisce una prova di ricezione e consente ai sistemi di comunicare in modo affidabile anche quando le reti intermediarie non funzionano.
  
  
• Elaborazione ed evasione degli ordini di e-commerce: se fai affari online, la forza della reputazione del tuo marchio dipende dall'affidabilità del tuo sito web e della tua piattaforma di e-commerce. La capacità dei broker di messaggi di migliorare la tolleranza agli errori e garantire che i messaggi vengano consumati una sola volta li rende la scelta naturale da utilizzare durante l'elaborazione degli ordini online.
  
  
• Protezione dei dati altamente sensibili inattivi e in transito: Se il settore in cui operi è altamente regolamentato, o la tua azienda deve affrontare rischi significativi per la sicurezza, scegli una soluzione di messaggistica con funzionalità di crittografia end-to-end.