E tem algum? Para mim, MB conhece assinantes e editores e atua como um mediador, notificando os assinantes sobre novas mensagens (efetivamente um modelo "push"). O MQ, por outro lado, é mais um modelo "pull", em que os consumidores retiram mensagens de uma fila.
Estou completamente fora do caminho aqui?
Respostas:
Em geral, quando se trata de produtos de software de fornecedores, eles são usados de forma intercambiável e não têm as fortes distinções em termos de push ou pull, conforme você descreve.
O BUS vs. QUEUE é de fato um conceito legado, mais recentemente originado de sistemas como IBM MQ e Tibco Rendezvous. MQ era originalmente um sistema 1: 1, na verdade uma fila para separar vários sistemas.
Tibco, por outro lado, era (vendido como um) backbone de mensagens, onde você poderia ter vários editores e assinantes nos mesmos tópicos.
No entanto, ambos (e produtos concorrentes mais recentes) podem jogar no espaço um do outro atualmente. Ambos podem ser configurados para interromper, bem como pesquisar novas mensagens. Ambos mediam as interações entre vários sistemas.
No entanto, a frase fila de mensagens também é usada para bombas de mensagem intra-thread internas e semelhantes e, neste contexto, o uso é de fato diferente. Se você pensar na bomba de mensagem clássica do Windows, este realmente é mais o modelo pull que você descreve, mas é realmente mais intra-app do que inter-app ou inter-box.
Bus de mensagens
Um Message Bus é uma infraestrutura de mensagens que permite que diferentes sistemas se comuniquem por meio de um conjunto compartilhado de interfaces ( barramento de mensagens ).
Fonte: EIP
Fila de mensagens
A ideia básica de uma fila de mensagens é simples:
Dois (ou mais) processos podem trocar informações por meio do acesso a uma fila de mensagens comum do sistema .
O processo de envio coloca por meio de algum módulo de passagem de mensagens (SO) uma mensagem em uma fila que pode ser lida por outro processo
Fonte: Dave Marshall
Diferença
Message Queue contém a regra FIFO ( first in first out ), enquanto no Message Bus não.
Conclusão
Ambos OLHE como fazer mesmo tipo de trabalho - passar mensagens entre dois aplicativos ou módulos ou interfaces ou sistemas ou processos , exceto pequena diferença de FIFO
Houve alguma indefinição das linhas entre esses dois conceitos, já que alguns produtos agora oferecem suporte a recursos que antes pertenciam apenas a uma ou outra categoria (por exemplo, o Barramento de Serviço do Azure oferece suporte a ambas as abordagens).
Uma fila de mensagens recebe mensagens de um aplicativo e as disponibiliza para um ou mais outros aplicativos de maneira primeiro a entrar, primeiro a sair (FIFO). Em muitos cenários arquitetônicos, se o aplicativo A precisar enviar atualizações ou comandos para os aplicativos B e C, então filas de mensagens separadas podem ser configuradas para B e C. A escreveria mensagens separadas para cada fila e cada aplicativo dependente leria de seu própria fila (a mensagem sendo removida ao ser retirada da fila). Nem B nem C precisam estar disponíveis para que A envie atualizações. Cada fila de mensagens é persistente, portanto, se um aplicativo for reiniciado, ele começará a puxar de sua fila assim que estiver online novamente. Isso ajuda a quebrar dependências entre sistemas dependentes e pode fornecer maior escalabilidade e tolerância a falhas para aplicativos.
Um barramento de mensagem ou barramento de serviço fornece uma maneira para um (ou mais) aplicativos comunicarem mensagens para um ou mais outros aplicativos. Pode não haver garantia de ordem do tipo primeiro a entrar, primeiro a sair, e os assinantes do barramento podem entrar e sair sem o conhecimento dos remetentes das mensagens. Assim, um aplicativo A poderia ser escrito para comunicar atualizações de status ao aplicativo B por meio de um barramento de mensagem. Posteriormente, o aplicativo C é escrito e também pode se beneficiar dessas atualizações. O aplicativo C pode ser configurado para ouvir o barramento de mensagens e agir com base nessas atualizações também, sem exigir nenhuma atualização do aplicativo A. Ao contrário das filas, onde o aplicativo de envio adiciona explicitamente mensagens a cada fila, um barramento de mensagens usa um publicar / modelo de assinatura. As mensagens são publicadas no barramento e qualquer aplicativo inscrito nesse tipo de mensagem a receberá.
A principal diferença, que realmente não foi mencionada explicitamente nas outras respostas, é que um barramento de mensagem permite vários assinantes, enquanto uma fila irá desenfileirar os itens um por um para qualquer coisa que estiver ouvindo a fila. Se você quisesse que vários ouvintes vissem os mesmos itens saindo da fila, você teria que cuidar disso sozinho, um barramento de serviço faria isso imediatamente para você.
A meu ver, é que o Message Queue cria o Message Bus . Os clientes (isto é, nós) podem então ouvir o barramento de mensagens. Isso é particularmente verdadeiro para o caso em que você tem um MQ transmitindo mensagens por meio de UDP, em outras palavras, ele está enviando mensagens para um endereço de broadcast / multicast sem saber ou se importar com quem as receberá. Para uma descrição mais detalhada desse cenário, você pode verificar este artigo .
Barramento de serviço é um termo mais geral do que uma fila de mensagens.
MQ é um FIFO simples, mas existem maneiras mais sofisticadas de implementar um Barramento de Serviço, ou seja, um Hub de Eventos, que é um grande "centro" para manipular as mensagens. Além da funcionalidade fornecida pelo MQ, permite armazenar as mensagens (e, portanto, usar vários assinantes), etc.
Um barramento de mensagem é um modelo de distribuição 1 para muitos. O destino neste modelo é geralmente denominado tópico ou assunto. A mesma mensagem publicada é recebida por todos os assinantes consumidores. Você também pode chamar isso de modelo de 'transmissão'. Você pode pensar em um tópico como o equivalente a um Assunto em um padrão de design Observer para computação distribuída. Alguns provedores de barramento de mensagem escolhem eficientemente implementar isso como UDP em vez de TCP. Para tópicos, a entrega da mensagem é 'dispare e esqueça' - se ninguém ouvir, a mensagem simplesmente desaparece. Se não for isso que você deseja, você pode usar 'assinaturas duráveis'.
Uma fila de mensagens é um destino de mensagens 1 para 1. A mensagem é recebida por apenas um dos receptores de consumo (observe: o uso consistente de assinantes para 'cliente de tópico e receptores para cliente de fila evita confusão). As mensagens enviadas para uma fila são armazenadas no disco ou na memória até que alguém as pegue ou expire. Portanto, filas (e assinaturas duráveis) precisam de algum gerenciamento de armazenamento ativo, você precisa pensar em consumidores lentos.
Na maioria dos ambientes, eu diria, os tópicos são a melhor escolha porque você sempre pode adicionar componentes adicionais sem ter que alterar a arquitetura. Componentes adicionados podem ser monitoramento, registro, análise, etc. Você nunca sabe no início do projeto como serão os requisitos em 1 ano, 5 anos, 10 anos. A mudança é inevitável, aceite-a :-)