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:
http://www.ibm.com/developerworks/downloads/ws/wmq/.
Click the download link as shown below.
Similar to Chapter 1, 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:
gunzip ./WMQv700Trial-x86_linux.tar.gz - 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:
./mqlicense.sh –accept - 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:
/opt/mqm/bin/dspmqver
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:
crtmqm TSTDADQ1 - The result will be as shown in the image below.
- We can now type the following command to list queue managers:
dspmq - The result of running the dspmq command is shown in the image below.
- To start the queue manager (QM), type the following command:
strmqm - 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:
runmqsc TSTDADQ1 - 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:
define qlocal(LQ.TEST) - Then immediately type the following command:
end - 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.
runmqsc TSTDADQ1
DEFINE LISTENER(TSTDADQ1.listener) TRPTYPE (TCP) PORT(1414)
START LISTENER(TSTDADQ1.listener)
End
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.
runmqsc TSTDADQ1
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
End
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
Summary
In this chapter, 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 larned 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.
October 3, 2009
Uncategorized