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 effettua questa operazione traducendo 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 di gestione del flusso di dati tra i componenti di un'applicazione, in modo che possano concentrare l'attenzione sulla relativa 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. Funzionano come intermediari tra altre applicazioni, consentendo ai mittenti di inviare messaggi senza sapere dove si trovano i destinatari, quanti siano e se sono attivi o meno. 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 resa 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, traduzione 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:
Le applicazioni cloud native sono create per sfruttare i vantaggi intrinseci del cloud computing, tra cui flessibilità, scalabilità e distribuzione rapida. Queste applicazioni sono costituite da piccoli componenti discreti e riutilizzabili, chiamati microservizi. Ogni microservizio è distribuito e può essere eseguito indipendentemente dagli altri. Questo significa che uno qualsiasi di essi può essere aggiornato, ridimensionato o riavviato senza influenzare gli altri servizi nel sistema. Spesso forniti in contenitori, i microservizi lavorano insieme per comprendere 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 avere un mezzo per comunicare tra loro per poter collaborare. I broker di messaggi sono un meccanismo che utilizzano per creare questa dorsale di comunicazioni condivisa.
I broker di messaggi sono spesso utilizzati per gestire le comunicazioni tra sistemi on-premises e componenti cloud in ambienti cloud ibridi . 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 usati per le comunicazioni tra microservizi. Il termine REST (Representational State Transfer) definisce un insieme di principi e vincoli che gli sviluppatori possono seguire durante la creazione di servizi Web. Eventuali servizi che aderiscono a questi principi saranno in grado di comunicare attraverso un insieme di operatori e richieste stateless 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 HTTP (Hypertext Transfer Protocol) per comunicare. Poiché HTTP (Hypertext Transfer Protocol\) è il protocollo di trasporto standard di Internet pubblico, le API REST sono ampiamente note, frequentemente utilizzate e ampiamente interoperabili. HTTP è un protocollo di richiesta/risposta, tuttavia, per cui è meglio utilizzato 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 prevedere una risposta immediata. Se il cliente 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 degli errori e la resilienza nei sistemi in cui sono impiegati. Inoltre, l'utilizzo di broker di messaggi semplifica la scalabilità dei sistemi in quanto un modello di messaggistica pub/sub può supportare prontamente la variazione del numero 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 volumi elevati di messaggi, le piattaforme di streaming degli eventi sono facilmente scalabili. Sono in grado di ordinare flussi di record in categorie chiamate argomenti e di memorizzarli per un periodo 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 degli 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 implementate nelle aziende. In un ESB, una piattaforma software centralizzata combina protocolli di comunicazione e formati di dati in un "linguaggio comune" che può essere condiviso da tutti i servizi e le applicazioni nell'architettura. Ad esempio, potrebbe tradurre la richiesta ricevuta da un protocollo (come XML) in un altro (come JSON). Gli ESB trasformano i propri payload di messaggi 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 dei diversi messaggio possono indirizzo una vasta gamma di esigenze aziendali tutti i settori e all'interno di diversi ambienti informatici aziendali. Sono utili quando e dove sono richieste le comunicazioni affidabili tra le applicazioni e la consegna garantita dei messaggi.
I broker di messaggi sono spesso impiegati nei seguenti modi:
I broker di messaggi stanno assumendo nuova importanza man mano che le organizzazioni tipi modernizzano le applicazioni nel percorso verso il cloud. Molte delle aziende di maggior successo al mondo, tra cui l'85% delle Fortune 100, si affidano alle funzionalità dei broker di messaggi di IBM, che sono create per supportare gli ambienti di sviluppo agile di oggi, le infrastrutture di cloud ibrido e basate su microservizi ed una vasta gamma di tipi di sistemi e requisiti di connettività.
Fai il passo successivo: scopri di più su IBM Cloud Pak for Integration, che si basa sulle funzionalità principali di IBM MQ, la soluzione di messaggistica aziendale leader del settore.
Inizia con un account IBM Cloud oggi stesso.
IBM MQ offre funzionalità di messaggistica di livello aziendale che ti permettono di spostare in modo sicuro le informazioni tra le applicazioni.
Connetti applicazioni, servizi e dati con IBM Cloud Pak for Integration, la piattaforma di integrazione più completa disponibile sul mercato.