An extract from the 'IBM WebSphere MQ' entry in Wikipedia describes it well:
Communication between queue managers relies on a channel. Each queue manager uses one or more channels to send and receive data to other queue managers. A channel is uni-directional, a second channel is required to return data. In a TCP/IP based network, a channel will send or receive data on a specific port. A sending channel has a defined destination and is associated with a specific transmission queue, the mechanism by which messages are queued awaiting transmission on the channel; a receiving channel will receive data from any other queue manager with a sending channel of the same name. When a receiving channel receives a message, it is examined to see which queue manager and queue it is destined for. In the event of a communications failure, MQ can automatically re-establish a connection when the problem is resolved.
The "listener" has the function of detecting connections from incoming channels and manage the connection of the sending to the receiving channels. It is the application's network interface to the queue manager. In a TCP/IP network, the listener will "listen" for connections on a specific port.
MQ QManager is the profile which is used to run the instance of the MQ.
Qlistener is the object which listens to the Q which is created in the ActiveQManager.
MQchannel is the passage or the bus kind of a thing which is used for connecting two QManagers local or remote for interaction of messsages b/w its queues.
Fire me boy! Cool, soothing, shameless self promotion:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database