Some of the more popular message queue services are:

• Amazon Web Services (AWS) Simple Queue Service (SQS)
• Kafka
• IBM MQ (this article)
• RabbitMQ

Let's say you have a web application that writes to a database. Perhaps there are periodic spikes where there are perhaps millions of write requests causing significant latency. Worse case scenario, this could perhaps causes the web app to load endlessly, fail to load at all, return timeout errors, display wonky errors, yada yada yada. Not good.

message queue to the rescue! The web application could publish messages to the message queue and then the database could consume the messages in queue. This is basically the publish/subscribe architecture (pub/sub), where the web app publishes the message to the queue and the database subscribes to the queue.

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 order placed at an online store.

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.

After you've installed MQ server, your next move is to create a queue manager and start the queue manager. As the name implies, a queue manager manages one or more queues. Enough said.

Then you'll want to create a queue. Messages will be stored in the queue. While not necessary, you could now also add the queue to your WebSphere dmgr.

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.