This Part1 section talks about how to maximize the ME's availability.
The core requirement in any enterprise system relying on messaging environment is the continuous availability of their Messaging Engine (ME). In a typical world it is possible for the server hosting the ME to fail for certain reasons triggering the HAManager to start the passive instance of the ME to now become Active. When an ME is configured to be highly available in a cluster the only unavailable time expected is the period while it is failing from one server to another.
In order to maximize the continuous availability of the Messaging Engine's, we can plan to have a topology such that the applications do not have a direct dependency on the ME that is active, but connect to a gateway or intermediate ME (as shown in the below diagram) so that the application downtime is minimized and the ME's availability is maximized
In the above topology there are 3 ME's configured, ME3 is the only ME that hosts the "local" queue, ME1 and ME2 have reference to the local point on ME3 (in other terms remote queue point). Applications connect to ME1 or ME2 to send messages, which are then transparently moved to ME's local queue point. As messages sent from an ME (i.e ME1 and ME2) that does not have the Queue Point are "stored" before forwarding to the Queue Point’s ME (ME3), you can use two tiers of bus members to closedown this unavailability window of an HA system even further.
The above topology addresses issues with your application downtime such that even when ME3 is down, applications can still send messages (not receive messages though) there by increasing your applications availability. While this does look like a good option, it is also important to understand the limitations and treating the causes associated with this approach which I will discuss in Part 2.