Cos'è un broker di messaggi?

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

I broker di messaggi sono moduli software all'interno di soluzioni di 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ò fungere da livello di comunicazione distribuito che consente alle applicazioni di estendersi a più piattaforme per 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 facilita il disaccoppiamento dei processi e dei servizi all'interno dei sistemi.

Per fornire uno storage dei messaggi affidabile e una consegna garantita, i broker di messaggi spesso si affidano a una sottostruttura, o componente, che prende il nome di coda messaggi, che archivia e ordina i messaggi finché le applicazioni che ne fanno utilizzo non sono in grado di elaborarli. In una coda messaggi, i messaggi vengono archiviati nell'ordine esatto in cui sono stati trasmessi e rimangono nella coda fino a quando non viene confermata la ricezione.

La messaggistica asincrona (15:11) si riferisce al tipo di comunicazioni interapplicative reso possibile dai broker di messaggi. Impedisce la perdita di dati preziosi e consente ai sistemi di continuare a funzionare anche se si verificano problemi di connettività e latenza intermittenti, comuni sulle reti pubbliche. La messaggistica asincrona garantisce che i messaggi verranno consegnati una sola volta (e non di più) nell'ordine corretto relativamente agli altri messaggi.

I broker di messaggi possono comprendere dei gestori code, che si occupano delle interazioni tra più code messaggi, e dei servizi, che offrono funzionalità di instradamento dei dati, conversione dei messaggi, persistenza e gestione dello stato dei client.

Modelli di broker di messaggi

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 messaggi con una relazione uno-a-uno tra il mittente e 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 sola volta e basta.
• Messaggistica di pubblicazione/sottoscrizione: in questo modello di distribuzione dei messaggi, spesso indicato come "pub/sot", il produttore di ogni messaggio lo pubblica in un argomento e più consumatori dei messaggi sottoscrivono gli 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 in stile broadcast, in cui esiste una relazione uno-a-molti tra chi pubblica il messaggio e i suoi consumatori. Se, ad esempio, una compagnia aerea dovesse divulgare gli aggiornamenti relativi agli orari di atterraggio o allo stato dei ritardi dei suoi voli, più parti potrebbero fare uso di queste informazioni: il personale di terra che si occupa della manutenzione e del rifornimento di carburante degli aeromobili, gli addetti ai bagagli, gli assistenti di volo e i piloti che preparano il prossimo viaggio dell'aereo e gli operatori dei display di visualizzazione che forniscono informazioni al pubblico. In questo scenario, l'uso di uno stile di messaggistica pub/sot sarebbe appropriato.

Broker di messaggi nelle architetture cloud

Le applicazioni native del cloud sono messe a punto in modo tale da avvalersi dei vantaggi intrinseci del cloud computing, comprese la flessibilità, la scalabilità e l'implementazione rapida. Queste applicazioni sono costituite da componenti piccoli, discreti e riutilizzabili denominati microservizi. Ogni microservizio viene implementato e può essere eseguito indipendentemente dagli altri. Ciò significa che ognuno di essi può essere aggiornato, ridimensionato o riavviato senza alcuna ripercussione sugli altri servizi nel sistema. Spesso impacchettati in container, i microservizi lavorano insieme per costituire un'intera applicazione, anche se ciascuno di essi ha un suo stack, compresi un database e un modello di dati che possono essere diversi dagli altri.

I microservizi devono disporre di un mezzo per comunicare tra loro al fine di operare insieme. I broker di messaggi rappresentano uno dei meccanismi di cui fanno uso per creare questa struttura portante per le comunicazioni condivise.

I broker di messaggi sono spesso utilizzati per gestire le comunicazioni tra i sistemi on-premises e i componenti cloud in ambienti di cloud ibrido. L'utilizzo di un broker di messaggi offre un maggior controllo sulle comunicazioni interservizi, 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 le comunicazioni tra i carichi di lavoro e i runtime che si trovano su piattaforme differenti. Sono anche indicati per l'utilizzo nel serverless computing, in cui i singoli servizi in hosting sul cloud vengono eseguiti on-demand in base alle singole richieste.

Confronto tra broker di messaggi e API

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. 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 gestione dei failover e degli errori deve essere integrata in entrambi i servizi.

I broker di messaggi consentono le comunicazioni asincrone tra i servizi in modo che il servizio mittente non debba attendere la risposta del servizio destinatario. 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/sot può supportare prontamente dei numeri di servizi mutevoli. I broker di messaggi tengono inoltre traccia degli stati dei consumatori.

Confronto tra broker di messaggi e piattaforme di streaming di eventi

Mentre i broker di messaggi possono supportare due o più modelli di messaggistica, tra cui code messaggi e pub/sot, le piattaforme di streaming di eventi offrono solo modelli di distribuzione in stile pub/sot. 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 di eventi non possono garantire la consegna dei messaggi o tracciare quali consumatori hanno ricevuto i messaggi.

Le piattaforme di streaming di eventi offrono più scalabilità rispetto ai broker di messaggi ma meno funzioni che garantiscano la tolleranza agli errori (come il nuovo invio dei messaggi) e funzionalità di instradamento e accodamento dei dati più limitate.

Scopri di più sull'architettura basata sugli eventi.

Confronto tra broker di messaggi e ESB (enterprise service bus)

Un ESB (enterprise service bus) è un modello architetturale a volte utilizzato nelle 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) ad un altro (come JSON). Gli ESB trasformano i loro payload di messaggio utilizzando un processo automatizzato. La piattaforma software centralizzata gestisce anche altra logica di orchestrazione, come la connettività, l'instradamento e l'elaborazione delle richieste.

Le infrastrutture ESB sono tuttavia complesse e possono essere difficili da integrare e costose da gestire. È difficile risolvere i problemi quando si verificano negli ambienti di produzione, non è facile eseguirne il ridimensionamento e l'aggiornamento è noioso.

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 un prezzo inferiore. Sono indicati per l'utilizzo nelle architetture di microservizi che sono diventate più prevalenti man mano che gli ESB sono caduti in disuso.

Casi di utilizzo del broker di messaggi

L'implementazione dei broker di messaggi può occuparsi di una vasta gamma di esigenze di business in tutti i settori e all'interno dei diversi ambienti di calcolo aziendali. Sono utili ogni qualvolta e ovunque siano richieste delle comunicazioni interapplicative affidabili e una consegna dei messaggi garantita.

I broker di messaggi sono spesso adottati nei seguenti modi:

• Elaborazione delle transazioni finanziarie e dei pagamenti: è fondamentale essere certi che i pagamenti vengano inviati una sola volta e basta. 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 di e-commerce: se stai svolgendo un'attività di business online, la solidità 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 utilizzati una sola volta e basta li rende una scelta naturale da utilizzare quando si elaborano gli ordini online.
• Protezione di dati estremamente sensibili inattivi e in transito: se il tuo settore è altamente regolamentato o il tuo business deve fare i conti con notevoli rischi per la sicurezza, scegli una soluzione di messaggistica con funzionalità di crittografia end-to-end.

Broker di messaggi e IBM Cloud

I broker di messaggi stanno assumendo nuovi tipi di importanza man mano che le organizzazioni modernizzano le applicazioni nel loro percorso verso il cloud. Molte delle aziende di maggior successo al mondo - tra cui l'85% di quelle indicate nella lista Fortune 100 - si affidano alle funzionalità del broker di messaggi di IBM, sviluppate per supportare gli ambienti di sviluppo agili e le infrastruttura basate sui microservizi e di cloud ibrido di oggi e una vasta gamma di tipi di sistema e requisiti di connettività.

Passa alla fase successiva: scopri di più su IBM Cloud Pak for Integration, che è sviluppato sulla funzionalità di base di IBM MQ, la soluzione di messaggistica aziendale leader del settore.

Inizia con un account IBM Cloud oggi stesso.