And are there any? To me, MB knows both subscribers and publishers and acts as a mediator, notifying subscribers on new messages (effectively a "push" model). MQ, on the other hand, is more of a "pull" model, where consumers pull messages off a queue.
Am I completely off track here?
On
Service Bus is a more general term than a Message Queue.
MQ is a simple FIFO, but there are more sophisticated ways to implement a Service Bus, i.e. an Event Hub, which is a huge "center" for manipulating the messages. Beside the functionality provided by MQ, it allows for storing the messages (and hence using multiple subscribers) etc
On
Message Bus
A Message Bus is a messaging infrastructure to allow different systems to communicate through a shared set of interfaces(message bus).
Source: EIP
Message Queue
The basic idea of a message queue is a simple one:
Two (or more) processes can exchange information via access to a common system message queue.
The sending process places via some (OS) message-passing module a message onto a queue which can be read by another process
Source: Dave Marshall
Difference
Message Queue contains FIFO(first in first out) rule whereas in Message Bus does not.
Conclusion
Both LOOK like doing same kind of work - passing messages between two Applications or Modules or Interfaces or Systems or Processes, except small difference of FIFO
On
There has been some blurring of the lines between these two concepts, as some products now support features that previously belonged only to one or the other category (for instance Azure Service Bus supports both approaches).
A message queue receives messages from an application and makes them available to one or more other applications in a first-in-first-out (FIFO) manner. In many architectural scenarios, if application A needs to send updates or commands to applications B and C, then separate message queues can be set up for B and C. A would write separate messages to each queue, and each dependent application would read from its own queue (the message being removed upon being dequeued). Neither B nor C need to be available in order for A to send updates. Each message queue is persistent, so if an application restarts, it will begin pulling from its queue once it is back online. This helps break dependencies between dependent systems and can provide greater scalability and fault tolerance to applications.
A message bus or service bus provides a way for one (or more) application to communicate messages to one or more other applications. There may be no guarantee of first-in-first-out ordering, and subscribers to the bus can come and go without the knowledge of message senders. Thus, an application A could be written to communicate status updates to application B via a message bus. Later, application C is written that can also benefit from these updates. Application C can be configured to listen to the message bus and take action based on these updates as well, without requiring any update to application A. Unlike queues, where the sending application explicitly adds messages to every queue, a message bus uses a publish/subscribe model. Messages are published to the bus, and any application that has subscribed to that kind of message will receive it. This approach allows applications to follow the open/closed principle, since they become open to future changes while remaining closed to additional modification.
On
The way I see it is that the Message Queue creates the Message Bus. Clients (i.e. nodes) can then listen to the message bus. This is particularly true for the case where you have a MQ broadcasting messages through UDP, in other words, it is sending messages to a broadcast/multicast address without knowing or caring who is going to be getting them. For a more in-depth description of this scenario you can check this article.
On
A message bus is a 1-to-many model of distribution. The destination in this model is usually called topic or subject. The same published message is received by all consuming subscribers. You can also call this the 'broadcast' model. You can think of a topic as the equivalent of a Subject in an Observer design pattern for distributed computing. Some message bus providers efficiently choose to implement this as UDP instead of TCP. For topic's the message delivery is 'fire-and-forget' - if no one listens, the message just disappears. If that's not what you want, you can use 'durable subscriptions'.
A message queue is a 1-to-1 destination of messages. The message is received by only one of the consuming receivers (please note: consistently using subscribers for 'topic client's and receivers for queue client's avoids confusion). Messages sent to a queue are stored on disk or memory until someone picks it up or it expires. So queues (and durable subscriptions) need some active storage management, you need to think about slow consumers.
In most environments, I would argue, topics are the better choice because you can always add additional components without having to change the architecture. Added components could be monitoring, logging, analytics, etc. You never know at the beginning of the project what the requirements will be like in 1 year, 5 years, 10 years. Change is inevitable, embrace it :-)
On
The main difference which hasn't really been mentioned explicitly in the other answers is that a message bus allows for multiple subscribers whereas a queue will dequeue items one by one to anything listening to the queue. If you wanted multiple listeners to see the same items coming off the queue you'd have to handle that yourself, a service bus would do this out of the box for you.
By and large, when it comes to vendor software products, they are used interchangeably, and do not have the strong distinctions in terms of push or pull as you describe.
The BUS vs. QUEUE is indeed somewhat a legacy concept, most recently stemming from systems like IBM MQ and Tibco Rendezvous. MQ was originally a 1:1 system, indeed a queue to decouple various systems.
Tibco by contrast was (sold as a) messaging backbone, where you could have multiple publishers and subscribers on the same topics.
Both however (and newer competing products) can play in each other's space these days. Both can be set to interrupt as well as polling for new messages. Both mediate the interactions between various systems.
However the phrase message-queue is also used for internal intra-thread message pumps and the like, and in this context, the usage is indeed different. If you think of the classic Windows message pump, this indeed is more the pull model you describe, but it is really more intra-app than inter-app or inter-box.