¿Y hay alguno? Para mí, MB conoce tanto a los suscriptores como a los editores y actúa como mediador, notificando a los suscriptores sobre nuevos mensajes (en realidad, un modelo "push"). MQ, por otro lado, es más un modelo de "extracción", en el que los consumidores extraen mensajes de una cola.
¿Estoy completamente desviado aquí?
Respuestas:
En general, cuando se trata de productos de software de proveedores, se usan indistintamente y no tienen las fuertes distinciones en términos de empujar o tirar como usted lo describe.
El BUS vs. QUEUE es de hecho un concepto heredado, más recientemente derivado de sistemas como IBM MQ y Tibco Rendezvous. MQ era originalmente un sistema 1: 1, de hecho, una cola para desacoplar varios sistemas.
Tibco, por el contrario, se vendía como una columna vertebral de mensajería, donde se podían tener varios editores y suscriptores sobre los mismos temas.
Sin embargo, ambos (y los productos competidores más nuevos) pueden jugar en el espacio del otro en estos días. Ambos se pueden configurar para interrumpir y para sondear mensajes nuevos. Ambos median las interacciones entre varios sistemas.
Sin embargo, la frase cola de mensajes también se usa para bombas de mensajes internos entre subprocesos y similares, y en este contexto, el uso es de hecho diferente. Si piensa en el bombeo de mensajes clásico de Windows, este es más el modelo de extracción que describe, pero en realidad es más dentro de la aplicación que entre aplicaciones o entre cajas.
Bus de mensajes
Un bus de mensajes es una infraestructura de mensajería que permite que diferentes sistemas se comuniquen a través de un conjunto compartido de interfaces ( bus de mensajes ).
Fuente: EIP
Cola de mensajes
La idea básica de una cola de mensajes es simple:
Dos (o más) procesos pueden intercambiar información mediante el acceso a una cola de mensajes del sistema común .
El proceso de envío coloca a través de algún módulo de paso de mensajes (SO) un mensaje en una cola que puede ser leído por otro proceso
Fuente: Dave Marshall
Diferencia
Message Queue contiene la regla FIFO ( primero en entrar, primero en salir ) mientras que en Message Bus no.
Conclusión
Ambos PARECEN hacer el mismo tipo de trabajo: pasar mensajes entre dos aplicaciones o módulos o interfaces o sistemas o procesos , excepto una pequeña diferencia de FIFO
Se han difuminado un poco las líneas entre estos dos conceptos, ya que algunos productos ahora admiten características que antes pertenecían solo a una u otra categoría (por ejemplo, Azure Service Bus admite ambos enfoques).
Una cola de mensajes recibe mensajes de una aplicación y los pone a disposición de una o más aplicaciones de una manera primero en entrar, primero en salir (FIFO). En muchos escenarios arquitectónicos, si la aplicación A necesita enviar actualizaciones o comandos a las aplicaciones B y C, entonces se pueden configurar colas de mensajes separadas para B y C. A escribiría mensajes separados en cada cola, y cada aplicación dependiente leería de su propia cola (el mensaje que se elimina al ser retirado de la cola). No es necesario que B ni C estén disponibles para que A envíe actualizaciones. Cada cola de mensajes es persistente, por lo que si una aplicación se reinicia, comenzará a extraerse de su cola una vez que vuelva a estar en línea. Esto ayuda a romper las dependencias entre los sistemas dependientes y puede proporcionar una mayor escalabilidad y tolerancia a fallas para las aplicaciones.
Un bus de mensajes o bus de servicio proporciona una forma para que una (o más) aplicaciones comuniquen mensajes a una o más aplicaciones. Es posible que no haya garantía de ordenar primero en entrar, primero en salir, y los suscriptores al bus pueden ir y venir sin el conocimiento de los remitentes de mensajes. Por tanto, se podría escribir una aplicación A para comunicar actualizaciones de estado a la aplicación B a través de un bus de mensajes. Posteriormente, se escribe la aplicación C que también puede beneficiarse de estas actualizaciones. La aplicación C se puede configurar para escuchar el bus de mensajes y tomar medidas en función de estas actualizaciones también, sin requerir ninguna actualización de la aplicación A. A diferencia de las colas, donde la aplicación de envío agrega mensajes explícitamente a cada cola, un bus de mensajes usa una publicación / suscribir modelo. Los mensajes se publican en el bus y cualquier aplicación que se haya suscrito a ese tipo de mensajes los recibirá.
La principal diferencia que realmente no se ha mencionado explícitamente en las otras respuestas es que un bus de mensajes permite múltiples suscriptores, mientras que una cola eliminará los elementos uno por uno a cualquier cosa que escuche la cola. Si quisiera que varios oyentes vieran los mismos elementos saliendo de la cola, tendría que manejarlo usted mismo, un bus de servicio lo haría por usted.
A mi modo de ver, la cola de mensajes crea el bus de mensajes . Los clientes (es decir, los nodos) pueden escuchar el bus de mensajes. Esto es particularmente cierto para el caso en el que tiene un MQ transmitiendo mensajes a través de UDP, en otras palabras, está enviando mensajes a una dirección de transmisión / multidifusión sin saber o importarle quién los recibirá. Para obtener una descripción más detallada de este escenario, puede consultar este artículo .
Service Bus es un término más general que Message Queue.
MQ es un FIFO simple, pero hay formas más sofisticadas de implementar un Service Bus, es decir, un Event Hub, que es un enorme "centro" para manipular los mensajes. Además de la funcionalidad proporcionada por MQ, permite almacenar los mensajes (y, por lo tanto, usar múltiples suscriptores), etc.
Un bus de mensajes es un modelo de distribución de 1 a muchos. El destino en este modelo generalmente se llama tema o materia. Todos los suscriptores consumidores reciben el mismo mensaje publicado. También puede llamar a esto el modelo de 'transmisión'. Puede pensar en un tema como el equivalente de un sujeto en un patrón de diseño de observador para la computación distribuida. Algunos proveedores de bus de mensajes eligen implementar esto de manera eficiente como UDP en lugar de TCP. Para los temas, la entrega del mensaje es "disparar y olvidar"; si nadie escucha, el mensaje simplemente desaparece. Si eso no es lo que desea, puede usar 'suscripciones duraderas'.
Una cola de mensajes es un destino de mensajes 1 a 1. El mensaje es recibido solo por uno de los receptores consumidores (tenga en cuenta: el uso constante de suscriptores para "clientes temáticos" y receptores para clientes en cola evita la confusión). Los mensajes enviados a una cola se almacenan en el disco o la memoria hasta que alguien los recoja o caduque. Por lo tanto, las colas (y las suscripciones duraderas) necesitan una administración de almacenamiento activa, debe pensar en consumidores lentos.
En la mayoría de los entornos, diría yo, los temas son la mejor opción porque siempre se pueden agregar componentes adicionales sin tener que cambiar la arquitectura. Los componentes agregados pueden ser monitoreo, registro, análisis, etc. Al comienzo del proyecto, nunca se sabe cuáles serán los requisitos en 1 año, 5 años, 10 años. El cambio es inevitable, acéptalo :-)