E ce ne sono? Per me, MB conosce sia gli abbonati che gli editori e funge da mediatore, informando gli abbonati sui nuovi messaggi (in pratica un modello "push"). MQ, d'altra parte, è più un modello "pull", in cui i consumatori estraggono i messaggi da una coda.
Sono completamente fuori strada qui?
Risposte:
In generale, quando si tratta di prodotti software di fornitori, vengono utilizzati in modo intercambiabile e non hanno le forti distinzioni in termini di push o pull come descrivi.
Il BUS vs. QUEUE è in effetti un concetto in qualche modo legacy, più recentemente derivato da sistemi come IBM MQ e Tibco Rendezvous. MQ era originariamente un sistema 1: 1, anzi una coda per disaccoppiare vari sistemi.
Tibco al contrario era (venduto come) spina dorsale di messaggistica, in cui si potevano avere più editori e abbonati sugli stessi argomenti.
Entrambi, tuttavia (e i prodotti concorrenti più recenti) possono giocare nello spazio dell'altro in questi giorni. Entrambi possono essere impostati per l'interruzione e per il polling di nuovi messaggi. Entrambi mediano le interazioni tra i vari sistemi.
Tuttavia, la frase coda di messaggi viene utilizzata anche per pompe di messaggi intra-thread interne e simili, e in questo contesto l'utilizzo è effettivamente diverso. Se pensi al classico message pump di Windows, questo è effettivamente più il modello pull che descrivi, ma è davvero più intra-app che inter-app o inter-box.
Message Bus
Un Message Bus è un'infrastruttura di messaggistica che consente a diversi sistemi di comunicare attraverso un insieme condiviso di interfacce ( message bus ).
Fonte: EIP
Coda messaggi
L'idea di base di una coda di messaggi è semplice:
Due (o più) processi possono scambiare informazioni tramite l' accesso a una coda di messaggi di sistema comune .
Il processo di invio inserisce un messaggio tramite un modulo di passaggio di messaggi (OS) in una coda che può essere letta da un altro processo
Fonte: Dave Marshall
Differenza
Message Queue contiene la regola FIFO ( first in first out ) mentre in Message Bus no.
Conclusione
Entrambi SGUARDO come fare lo stesso tipo di lavoro - passare messaggi tra due applicazioni o moduli o interfacce o sistemi o processi , tranne piccola differenza di FIFO
I confini tra questi due concetti sono stati offuscati, poiché alcuni prodotti ora supportano funzionalità che in precedenza appartenevano solo all'una o all'altra categoria (ad esempio, il bus di servizio di Azure supporta entrambi gli approcci).
Una coda di messaggi riceve i messaggi da un'applicazione e li rende disponibili a una o più altre applicazioni in modo FIFO (first-in-first-out). In molti scenari architettonici, se l'applicazione A deve inviare aggiornamenti o comandi alle applicazioni B e C, è possibile impostare code di messaggi separate per B e C. A scriverà messaggi separati su ciascuna coda e ciascuna applicazione dipendente leggerà dalla sua coda propria (il messaggio viene rimosso dopo essere stato rimosso dalla coda). Né B né C devono essere disponibili affinché A possa inviare aggiornamenti. Ogni coda di messaggi è persistente, quindi se un'applicazione viene riavviata, inizierà a estrarre dalla coda una volta tornata in linea. Questo aiuta a rompere le dipendenze tra i sistemi dipendenti e può fornire una maggiore scalabilità e tolleranza ai guasti alle applicazioni.
Un bus di messaggi o un bus di servizio consente a una (o più) applicazioni di comunicare messaggi a una o più altre applicazioni. Potrebbe non esserci alcuna garanzia di ordine first-in-first-out e gli abbonati all'autobus possono entrare e uscire senza che i mittenti dei messaggi siano a conoscenza. Pertanto, un'applicazione A potrebbe essere scritta per comunicare gli aggiornamenti di stato all'applicazione B tramite un bus di messaggi. Successivamente, viene scritta l'applicazione C che può anche beneficiare di questi aggiornamenti. L'applicazione C può essere configurata per ascoltare il bus dei messaggi e agire anche sulla base di questi aggiornamenti, senza richiedere alcun aggiornamento all'applicazione A. A differenza delle code, in cui l'applicazione di invio aggiunge esplicitamente messaggi a ogni coda, un bus di messaggi utilizza un iscriviti modello. I messaggi vengono pubblicati sul bus e qualsiasi applicazione che ha sottoscritto quel tipo di messaggio lo riceverà.
La differenza principale che non è stata menzionata esplicitamente nelle altre risposte è che un bus di messaggi consente più abbonati mentre una coda rimuoverà gli elementi uno per uno da qualsiasi cosa in ascolto della coda. Se desideri che più ascoltatori vedano gli stessi elementi che escono dalla coda, dovresti gestirlo tu stesso, un bus di servizio lo farebbe immediatamente per te.
Per come la vedo io è che la coda dei messaggi crea il bus dei messaggi . I client (cioè i nodi) possono quindi ascoltare il bus dei messaggi. Ciò è particolarmente vero per il caso in cui si dispone di un MQ che trasmette messaggi tramite UDP, in altre parole, sta inviando messaggi a un indirizzo broadcast / multicast senza sapere o preoccuparsi di chi li riceverà. Per una descrizione più approfondita di questo scenario puoi consultare questo articolo .
Il bus di servizio è un termine più generale di una coda di messaggi.
MQ è un semplice FIFO, ma ci sono modi più sofisticati per implementare un Service Bus, cioè un Event Hub, che è un enorme "centro" per la manipolazione dei messaggi. Oltre alla funzionalità fornita da MQ, consente di memorizzare i messaggi (e quindi di utilizzare più abbonati) ecc
Un bus di messaggi è un modello di distribuzione 1-a-molti. La destinazione in questo modello è solitamente chiamata argomento o soggetto. Lo stesso messaggio pubblicato viene ricevuto da tutti gli abbonati consumatori. Puoi anche chiamarlo il modello "broadcast". Puoi pensare a un argomento come l'equivalente di un Soggetto in un modello di progettazione Observer per il calcolo distribuito. Alcuni provider di bus di messaggi scelgono in modo efficiente di implementarlo come UDP anziché come TCP. Per gli argomenti, la consegna del messaggio è "spara e dimentica": se nessuno ascolta, il messaggio scompare. Se non è quello che vuoi, puoi utilizzare "abbonamenti durevoli".
Una coda di messaggi è una destinazione 1 a 1 dei messaggi. Il messaggio viene ricevuto solo da uno dei destinatari che consumano (nota: utilizzare in modo coerente gli abbonati per i client argomenti e i destinatari per i client in coda evita confusione). I messaggi inviati a una coda vengono archiviati su disco o memoria finché qualcuno non li riprende o scade. Quindi le code (e gli abbonamenti durevoli) richiedono una gestione attiva dell'archiviazione, è necessario pensare ai consumatori lenti.
Nella maggior parte degli ambienti, direi, gli argomenti sono la scelta migliore perché è sempre possibile aggiungere componenti aggiuntivi senza dover modificare l'architettura. I componenti aggiunti potrebbero essere monitoraggio, registrazione, analisi, ecc. All'inizio del progetto non si sa mai quali saranno i requisiti tra 1 anno, 5 anni, 10 anni. Il cambiamento è inevitabile, abbraccialo :-)