Errata exists for this version of the document.

This option assumes a messaging Broker in the middle as shown in Figure 15. No application is speaking directly to other applications. All the communication is passed through the Broker. The Broker routes the NetworkMessages to the right applications based on business criteria ("queue name", "routing key", "topic" etc.) rather than on physical topology (IP addresses, host names).

Figure 15 – PubSub using broker

Advantages of this model (partly depending on used Broker and its configuration) include:

• Publisher and Subscriber do not have to be directly addressable. They can be anywhere as long as they have access to the Broker.
• Fan out can be handled to a very large list of Subscribers, multiple networks or even chained Brokers or scalable Brokers.
• Publisher and Subscriber lifetimes do not have to overlap. The Publisher application can push NetworkMessages to the Broker and terminate. The NetworkMessages will be available for the Subscriber application later.
• Publisher and Subscriber can use different messaging protocols to communicate with the Broker.

In addition, the Broker model is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the NetworkMessages that are already in the Broker will be retained even if the application fails.