WebSphere MQ overview
WebSphere MQ formerly known as MQ Series is IBM's enterprise messaging solution. In a nutshell, MQ provides the mechanisms for messaging both in point-to-point and publish-subscribe. However, it guarantees to deliver a message only once. This is important for critical business applications which implement messaging. An example of a critical system could be a banking payments system where messages contain messages pertaining to money transfer between banking systems, so guaranteeing delivery of a debit/credit is paramount in this context. Aside from guaranteed delivery, WMQ is often used for messaging between dissimilar systems and the WMQ software provides programming interfaces in most of the common languages, such as Java, C, C++, and so on. If you are using WebSphere, then it is common to find that WMQ is often used with WebSphere when WebSphere is hosting message-enabled applications. It is important that the WebSphere administrator understands how to configure WebSphere resources so that application can be coupled to the MQ queues.
Overview of WebSphere MQ example
To demonstrate messaging using WebSphere MQ, we are going to re-configure the previously deployed JMS Tester application so that it will use a connection factory which communicates with a queue on a WMQ queue manager as opposed to using the default provider which we demonstrated earlier.
Installing WebSphere MQ
Before we can install our demo messaging application, we will need to download and install WebSphere MQ 7.0. A free 90-day trial can be found at the following URL:
Click the download link as shown below.
You will be prompted to register as an IBM website user before you can download the WebSphere MQ Trial. Once you have registered and logged in, the download link above will take you to a page which lists download for different operating systems.
Select WebSphere MQ 7.0 90-day trial from the list of available options as shown below.
Click continue to go to the download page. You may be asked to fill out a questionnaire detailing why you are evaluating WebSphere MQ (WMQ). Fill out the question as you see fit and submit to move to the download page.
As shown above, make sure you use the IBM HTTP Download director as it will ensure that your download will resume, even if your Internet loses a connection.
If you do not have a high-speed Internet connection, you can try downloading a free 90-day trial of WebSphere MQ 7.0 overnight while you are asleep.
Download the trial to a temp folder, for example c:temp, on your local machine. The screenshot above shows how the IBM HTTP Downloader will prompt for a location where you want to download it to. Once the WMQ install file has been downloaded, you can then upload the file using an appropriate secure copy utility like Winscp to an appropriate folder like /apps/wmq_install on your Linux machine. Once you have the file uploaded to Linux, you can then decompress the file and run the installer to install WebSphere MQ.
Running the WMQ installer
Now that you have uploaded the WMQv700Trial-x86_linux.tar file on your Linux machine, and follow these steps:
- You can decompress the file using the following command:
- Then run the un-tar command:
tar -xvf ./ WMQv700Trial-x86_linux.tar
- Before we can run the WMQ installations, we need to accept the license agreement by running the following command:
- To run the WebSphere MQ installation, type the following commands:
rpm -ivh MQSeriesRuntime-7.0.0-0.i386.rpm
rpm -ivh MQSeriesServer-7.0.0-0.i386.rpm
rpm -ivh MQSeriesSamples-7.0.0-0.i386.rpm
- As a result of running the MQSeriesServer installation, a new user called mqm was created. Before running any WMQ command, we need to switch to this user using the following command:
su - mqm
- Then, we can run commands like the dspmqver command which can be run to check that WMQ was installed correctly. To check whether WMQ is installed, run the following command:
The result will be the following message as shown in the screenshot below:
Creating a queue manager
Before we can complete our WebSphere configuration, we need to create a WMQ queue manager and a queue, then we will use some MQ command line tools to put a test message on an MQ queue and get a message from an MQ queue.
- To create a new queue manager called TSTDADQ1, use the following command:
- The result will be as shown in the image below.
- We can now type the following command to list queue managers:
- The result of running the dspmq command is shown in the image below.
- To start the queue manager (QM), type the following command:
- The result of starting the QM will be similar to the image below.
- Now that we have successfully created a QM, we now need to add a queue called LQ.Test where we can put and get messages.
- To create a local queue on the TSTDADQ1 QM, type the following commands in order:
- You are now running the MQ scripting command line, where you can issue MQ commands to configure the QM.
- To create the queue, type the following command and hit Enter:
- Then immediately type the following command:
- Hit Enter to complete the QM configuration, as shown by the following screenshot.
You can use the following command to see if your LQ.TEST queue exists.
echo "dis QLOCAL(*)" | runmqsc TSTDADQ1 | grep -i test
You have now added a local queue called Q.Test to the TSTDADQ1 queue manager.
DEFINE LISTENER(TSTDADQ1.listener) TRPTYPE (TCP) PORT(1414)
You can type the following command to ensure that your QM listener is running.
ps -ef | grep mqlsr
The result will be similar to the image below.
To create a default channel, you can run the following command.
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
We can now use a sample MQ program called amqsput which we can use to put and get a test message from a queue to ensure that our MQ configuration is working before we continue to configure WebSphere.
Type the following command to put a test message on the LQ.Test queue:
/opt/mqm/samp/bin/amqsput LQ.TEST TSTDADQ1
Then you can type a test message: Test Message and hit Enter; this will put a message on the LQ.Test queue and will exit you from the AMQSPUTQ command tool.
Now that we have put a message on the queue, we can read the message by using the MQ Sample command tool called amqsget. Type the following command to get the message you posted earlier:
/opt/mqm/samp/bin/amqsget LQ.TEST TSTDADQ1
The result will be that all messages on the LQ.TEST queue will be listed and then the tool will timeout after a few seconds as shown below.
We need to do two final steps to complete and that is to add the root user to the mqm group. This is not a standard practice in an enterprise, but we have to do this because our WebSphere installation is running as root. If we did not do this, we would have to reconfigure the user which the WebSphere process is running under and then add the new user to MQ security. To keep things simple, ensure that root is a member of the mqm group, by typing the following command:
usermod -a -G mqm root
We also need to change WMQ security to ensure that all users of the mqm group have access to all the objects of the TSTDADQ1 queue manager. To change WMQ security to give access to all objects in the QM, type the following command:
setmqaut -m TSTDADQ1 -t qmgr -g mqm +all
Now, we are ready to re-continue our configuring WebSphere and create the appropriate QCF and queue destinations to access WMQ from WebSphere.
Creating a WMQ connection factory
Creating a WMQ connection factory is very similar to creating a JMS QCF. However, there are a few differences which will be explained in the following steps. To create a WMQ QCF, log in to the Admin console and navigate to the JMS category of the Resources section found in the left-hand-side panel of the Admin console and click on Queue connection factories. Select the Cell scope and click on New. You will be presented with an option to select a message provider. Select WebSphere MQ messaging provider as shown below and click OK.
You will then be presented with a wizard which will first ask you for the name of the QCF. Type QCF.LQTest in the Name field and type jms/QCF.LQTest in the JNDI name field, as shown below.
Click on Next to progress to the next step of the wizard, where you will decide on how to connect to WMQ. As shown in the following screenshot, select the Enter all the required information into this wizard option and then click on Next.
In the Supply queue connection details screen, you will need to type TSTDADQ1 into the Queue manager or queue sharing group name field and click on Next.
On the next screen of the wizard, you will be asked to fill in some connection details. Ensure that the Transport field is set to Bindings then client. Type localhost in the hostname field and then add the value 1414 to the Port field, and type SYSTEM. ADMIN.SVRCONN into the Server connection channel field as shown below and then click on Next to move on to the next step of the wizard.
On the next page, you will be presented with a button to test your connection to WMQ. If you have set up WMQ correctly, then you will be able to connect and a results page will be displayed confirming a successful connection to WMQ. If you cannot connect at this stage, then you will need to check your MQ setup. Most often it is security that is the problem. If you find you have an issue with security, you can search Google for answers on how to change WMQ security. Once your test is successful, click on Next to move on to the final Summary page which will list your QCF configuration. On the final page of the wizard, click Finish to complete the WMQ QCF configuration and click Save to retain your changes. You will now see two QCF configurations, one for JMS and one for WMQ, as shown below:
Creating a WMQ queue destination
The next step after creating a QCF is to create a queue destination. We will use the queue named LQ.Test which we created on the TSTDADQ1 queue manager. To create a new queue, navigate to the JMS category of the Resources section in the left-hand-side panel of the admin console and click Queues. Click on New to start the queue creation wizard. In the provider selector screen, select WebSphere MQ messaging provider and click on Next. You will then be presented with a page that allows you to specify settings for the queue. In the Name field, type LQ.Test and then type jms/LQ.Test in the JNDI name field. In the Queue name field, type LQ.TEST which is the actual name for the underlying queue, as shown below.
Useful tip: Optionally, you can type the Queue Manager name, for example, TSTDADQ1 into the Queue manager or queue sharing group name field, but if you ever use WMQ clustering, it is not required and will stop MQ clustering from working correctly.
Click on Apply to submit the changes, and then click on Save to retain the changes to the WebSphere configuration repository. You will then be presented with a list of queues as shown below:
We have now configured a WebSphere MQ queue connection factory and a WebSphere MQ queue destination which our test application will use to send and receive messages from WMQ.
Reconfiguring the JMS demo application
Now that we have created a QCF and queue destination using WMQ as the message provider, we will need to reconfigure the JMS Test Tool application to point to the WMQ JNDI names as opposed to the Default Provider JNDI names. When we deployed the application, the installation wizard allowed us the option of re-pointing of the JNDI names. This was because the application's deployment descriptor declared resource references, which the installation wizard picked up and presented as configurable options in the installation wizard. Even after a deployment is complete, it is possible to reconfigure an application at any time by drilling down into the application configuration. We want to change the JNDI names the application is using for the QCF and queue destination. We are going to change jms/QCF.Test to jms/QCF.LQTest and jms/Q.Test to jms/LQ.Test. This re-mapping of the applications JNDI will allow the application to use WMQ instead of JMS via the SIB. To change the application's resource references, click Applications in the left-hand-side panel of the Admin console, and then expand the Application Types section and click WebSphere enterprise applications. Click on the JMS Test Tool from the application list. You will then be presented with the main application configuration panel. Look for a section called References as shown in the following screenshot:
Click on the Resource references link and change the Target Resource JNDI Name field to jms/QCF.LQTest as shown below and then click on OK to return back to the previous page.
Click on Continue if you get any warnings. We have now re-pointed the application's QCF reference to the new WMQ QCF configuration.
To change the queue destination, we click on the Message destination references link and change the Target Resource JNDI Name field to jms/LQ.Test as shown below.
We have now completed the re-mapping of resources. Click on Save to make the changes permanent and restart the application server. When you next use the JMS Test Tool application, the sending and receiving of messages will be using WMQ instead of the Default Messaging Provider.
You can use the following command to show the messages sitting on the LQ.TEST queue if you wish to see the queue depth (how many messages are on the queue):
echo "dis ql(*) curdepth where (curdepth gt 0)" | runmqsc TSTDADQ1
In this two-part article, we learned that WebSphere provides a level of abstraction to messaging configuration by allowing resources to be referenced by JNDI. We deployed a message-enabled application which required a queue connection factory and queue destination which it used to send and receive messages. We configured two different implementations of JMS. One implementation used the internal Default Messaging Provider, which required a SIB to be created, and we covered how to create the QCF and queue destinations and bound the applications resource references to those configured in WebSphere.
We then covered how to install WebSphere MQ and learned how to create a queue manager and a queue. Then, in WebSphere, we created a QCF and queue destination using the WebSphere MQ provider and demonstrated how to to re-map our applications resource references to re-point the application to use MQ messaging subsystem as opposed to the internal messaging subsystem.
There are many uses of messaging in enterprise applications and we have essentially covered the key areas for configuring WebSphere to facilitate resources for message-enabled applications.
If you have read this article you may be interested to view :
- Messaging with WebSphere Application Server 7.0 (Part 1)
- Deploying your Applications on WebSphere Application Server 7.0 (Part 1)
- Deploying your Applications on WebSphere Application Server 7.0 (Part 2)