I've talked about the parts of WebSphere MQ, primarily queue managers connected by channels. This simplifies describing the basics of a WMQ topology.
Behind the JMS API your application sees, a WMQ messaging system is a bunch of queue managers, typically running on different server machines, connected by a bunch of channels. Applications connect to the queue managers to send and receive messages, which is where the messages are stored. The queue managers use channels to transmit messages to each other, usually from one computer to another, reliably.
This architecture also enables WMQ to achieve load balancing and failover in message transmission. When possible, you should configure WMQ to connect queue managers with separate channels, ideally across different network connections and network cards. This way, when one network connection slows down, the queue managers will shift traffic to the channels on other network connections, keeping the messages flowing even through network disruptions. This is another example of how WMQ is highly reliable, not just in terms of persisting messages but also in terms of routing traffic around network problems.
JMS: Basic WebSphere MQ Topology