Messaging models

Broker-based messaging

Every application is connected to the central broker. No application is speaking directly to the other application. All the communication is passed through the broker.

Pros:

1. Firstly, applications don't have to have any idea about location of other applications. The only address they need is the network address of the broker. Broker then routes the messages to the right applications based on business criteria ("queue name", "routing key", "topic", "message properties" etc.) rather than on physical topology (IP addresses, host names).
2. Secondly, message sender and message receiver lifetimes don't have to overlap. Sender application can push messages to the broker and terminate. The messages will be available for the receiver application any time later.
3. Thirdly, broker model is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the messages that are already in the broker will be retained even if the application fails.

Cons:

1. Firstly, it requires excessive amount of network communication. 
2. Secondly, the fact that all the messages have to be passed through the broker can result in broker turning out to be the bottleneck of the whole system. Broker box can be utilised to 100% while other boxes are under-utilised, even idle almost all the time.

Broker-less messaging

Applications sending messages each to another without the broker in the middle.

Pros:

As can be seen number of network hops decreased to three and there is no single bottleneck on the network. This kind of arrangement is ideal for applications with a need for low latency and/or high transaction rate. 

Cons:

The trade-off is worsened manageability of the system. Each application has to connect to the applications it communicates with and thus it has to know the network address of each such application.  In real world enterprise environment with hundreds of interconnected applications managing the solution would quickly become a nightmare.

Broker as a directory service

Note that we can split the functionality of the broker into two separate parts. Firstly, broker has a repository of applications running on the network. It knows that application X runs on host Y and that messages intended for X should be sent to Y. It acts like a directory service. Secondly, broker does the message transfer itself.

Pros:

This way we can get high performance and manageability at the same time. 

Cons:

Does not meet the requirements -> The sender application and the receiver application don't have to have overlapped lifetimes. The messages are stored in the broker while sender is already off and receiver has not yet started. Also, if the application fails, the messages that were already passed to the broker are not lost.

Distributed Broker

This approach overcomes the issue of broker as the bottleneck or single point of failure by letting us use multiple message queues (each registered with the central directory service as a separate application/OSGi bundle). 

Pros:

1. Overcomes the limitation of message broker being single point of failure.
2. Retains all advantages of the broker based messaging that applications don't need to know each other's address and they can lookup the message queues in the directory service and send/receive messages on the message queue.

Cons: 

Still the directory service is a single point of failure. Model is completely distributed message-wise, its configuration is still centralised in the directory service. If directory service fails or when it is unaccessible, system fails.

This blog post is an excerpt from: http://zeromq.org/whitepapers:brokerless