Multiple bus member bus

Multiple bus members should be considered for the bus configuration where messaging traffic is high and can be suitably divided, for example, per application or queue.

The following figure shows a configuration which is very similar at runtime to any single messaging engine configuration when application messaging is self contained.

Figure 1. Multiple bus member bus configuration

However once applications on different servers start to communicate with each other using messages, the runtime starts to change.

Careful planning is important for a multiple bus member bus configuration because messaging applications will randomly connect to any available messaging engine in the bus. The only default behavior that overrides this is when an application connects to a bus that has an messaging engine running in the same server. This can result in messages taking inefficient paths to and from the applications to queues or subscriptions. This affects manageability and serviceability of the system due to the unpredictable nature of connections and variable message routing.

The general rule is to connect directly to the bus member that owns the queue. Always target connections and activation specifications. If we have to choose between a producing application or a consuming application, connect the consumers directly to the queue point's messaging engine and allow the producer to store and forward.