Message Queue vs Message Bus - what are the differences?

Question

And are there any? For me, MB knows both subscribers and publishers and acts as an intermediary, notifying subscribers of new messages (this is actually a “push”). MQ, on the other hand, is more like a pull model, where consumers pull messages from the queue.

Am I completely out of here?

Answer 1

In general, when it comes to vendor software products, they are used interchangeably and do not have strong differences in terms of push or pull, as you describe.

BUS vs. QUEUE really is a heritage concept that has recently been linked to systems such as IBM MQ and Tibco Rendezvous. Initially, MQ was a 1: 1 system, and this is really the turn for decoupling the various systems.

Tibco by contrast was (sold as) a messaging network where you could have several publishers and subscribers on the same topics.

And yet (and newer competing products) can play in every other space these days. Both can be set to both interrupt and polling for new messages. Both intermediaries interact between different systems.

However, the phrase message-queue is also used for internal in-line messages and the like, and in this context the usage is really different. If you are thinking of the classic Windows message pump, this is really more of a push model that you are describing, but it is really a more intra application than an inter-application or a firewall.

Answer 2

Message bus

A message bus is a messaging infrastructure that allows different systems to communicate through a common set of interfaces ( message bus ).

Source: EIP

Message queue

The basic message queue idea is simple:

• Two (or more) processes can exchange information through access to a common system message queue .

• The sending process sends a message to a queue that can be read by another process through some (OS) message passing module

Source: Dave Marshall

Image source

difference

The message queue contains the FIFO rule (the first in the first order), while there are no messages on the bus .

Conclusion

Both LOOKs love to do the same job - passing messages between two applications or modules or interfaces or systems or processes , with the exception of a slight difference FIFO

Answer 3

The main difference, which was not actually explicitly mentioned in the other answers, is that the message bus allows several subscribers, while the queue will deactivate the elements one by one for everything that the queue listens for. If you want several listeners to see the same elements coming out of the queue that you have to process yourself, the service bus will do this out of the box for you.

Answer 4

There was some blurring between the two concepts, as some products now support features that previously belonged to only one or the other category (for example, Azure Service Bus supports both approaches).

TURN

The message queue receives messages from the application and makes them available to one or more other applications using the first-in-first-out (FIFO) method. In many architectural scenarios, if application A should send updates or commands to applications B and C, separate message queues can be configured for B and C. A will write separate messages to each queue, and each dependent application will read from its own queue (message deleted when it is deleted). Neither B nor C should be available for A to send updates. Each message queue is constant, therefore, if the application restarts, it will begin to be pulled out of the queue as soon as it is online again. This helps break down dependencies between dependent systems and can provide greater scalability and fault tolerance for applications.

BUS

A message bus or service bus provides a method for one (or more) applications for transmitting messages to one or more other applications. There can be no first-order guarantee in the first order, and bus subscribers can come and go without the knowledge of the senders of the messages. In this way, application A can be written to send status updates to application B via the message bus. A C application was later written that could also benefit from these updates. Application C can be configured to listen on the message bus and take action based on these updates, as well as without the need to update application A. Unlike queues, in which the sending application explicitly adds messages to each queue, the message bus uses the publish / sign model. Messages are published on the bus, and any application that subscribes to this message will receive it. This approach allows applications to follow the open / closed principle, as they become open to future changes, while remaining closed for additional modification.

SOURCE

Answer 5

As I can see, a message bus is created in the message queue . Clients (i.e., Nodes) can then listen on the message bus. This is especially true when you have an MQ broadcast of messages over UDP, in other words, it sends messages to the broadcast / multicast address, not knowing or not caring about who will receive them. For a more detailed description of this scenario, you can check this article .

Answer 6

Service Bus is a more general term than a message queue.

MQ is a simple FIFO, but there are more complex ways to implement a Service Bus, that is, an Event Hub, which is a huge "center" for processing messages. In addition to the functions provided by MQ, it allows you to store messages (and, therefore, use multiple subscribers), etc.