Before you can understand what MQ (message queue) is, it's helpful to see how data is transmitted without MQ. In this extremely simplified diagram, the sending system transmits data to the receiving system. In this scenario, the data would most probably be something like an email or an SMS message. While this is all fine and dandy, this type of design can produce problems. Most notably, if the receiving system is unable to receive the data (eg. the receving system is down or overwhelmed with requests), the sending system may not be able to move onto the next transmission or may continually try to send the data over and over again (which is a waste of the sending systems resources). MQ resolves these issues.
MQ sit's between the sending system and receiving system, as a sort of broker or proxy. In this way, if the receiving system is unavailable, the sending system does not get trapped in a situation where it cannot move onto it's next transmission or is bogged down trying to send the transmission over and over again. The sending system simply sends the data to MQ and then moves on (fire and forget). In this way, MQ makes it so that data tranmission is asynchronous. If this is something you want to implement, you can install the trial version of MQ server to see if this type of architecture will fit your needs.
To test things out, you can put (add) a message in the queue, display the messages in the queue, and then get (remove) a message from the queue. With the current setup, messages can only be added and removed from the queue on the MQ server itself, which isn't really pratical from a real world scenario, thus the next step is to configure MQ so that other systems can PUT and GET messages.
In order for a remote system to be able to PUT/GET messages in a queue, a channel and listener needs to be setup. The channel/listener is the hostname and port (socket) used to connect to the MQ server.
Next, give a user access to the channel, and grant the user permissions to the manager and queue, so that we have a basic authentication system in place for users that want to connect to our MQ server.
Congratulations! You now have an operational MQ server. Let's test these waters and create a Java application that can connect to MQ. The display conn command can be used to determine if the connection can be made.
Then, continue to develop the application so that you can PUT a message on the queue. To verify that the message was PUT on the queue, you can display the messages in the queue using MQ Explorer or the amqsbcg command. Then, develop the application to GET messages from the queue.