mq Authors: RealWire News Distribution, Charles Rich, Application Security, Daniel Thompson, Kevin Benedict

Related Topics: mq

mq: Article

Message-Driven Beans in WebSphere

Use MQ Messaging for Many Processes

With WebSphere Application server 5.0+ you can now add Message-Driven Beans (MDBs) to your WebSphere arsenal. These beans are handy for many processes. I recently had to write a MDB using MQ Series. WebSphere Application Server (WAS) 5.0 had the same functionality built-in, but I had a hard time learning how to use it. I also encountered some issues while configuring it to run in a load-balanced environment.

First of all, there's no real way of balancing the load in a clustered environment for MDBs. All nodes in the cluster will fight for the messages as they enter the queue. This is a limitation that can't be worked around.

There's another pitfall that will affect you even if you don't plan to use load balancing. If for any reason the queue manager connection fails, your MDB will be rendered useless until someone restarts the message listener service on the application server.

That said let's build an MDB. First you'll want to get some information about the queue you're attaching to. The Queue Manager name, Host, Port, Channel name, and Queue name will most likely be enough information. You'll have to create both a Destination and a Connection Factory.

To create a destination you'll want to go to the WebSphere Console and go to: Resources - WebSphere MQ JMS Provider - a WebSphere MQ Queue Destinations. At this point you'll want to decide at which level you'd like this information to be available. If you're in a load-balanced environment there's only one that will allow all the cells to play nicely together, and that's the cell level. Choose a JNDI name and note it for later use. Then populate the appropriate queue info on the next screen.

Once you've done that we'll have to create the Queue Connection Factory. This is found at: Resources - WebSphere MQ JMS Provider - a WebSphere MQ Queue Connection Factories. Here again, if you're in a load-balanced environment, make sure to create these at the cell level. Choose a JNDI name and note it for later use. Then, on the next page, populate the queue information.

At this point we're ready for the final piece of the puzzle, we have to create a Listener Port. All this really does is take the factory and bind it to the destination, and then manage the two. To create a port, go to Application Servers - (your server's name) - Message Listener Service. Here you'll create a port and assign it a JNDI name. This JNDI name will be used by your application to talk to the port. The guts of the port is pretty straightforward, just give it the JNDI names for the Connection Factory and Destination. The rest should work with the default values. Once you have that created, go back to the Listener Ports screen.

It's here that you'll probably want to add a little extra info in case your queue manager ever needs to be rebooted or taken down for short periods. We're going to add two custom properties: "MAX.RECOVERY.RETRIES" and "RECOVERY.RETRY.INTERVAL." This will let the Listener Port retry for the specified number of tries, and wait for however long you've set the interval to between tries. The interval value is in seconds.

I've created a simple MDB that will print the contents of a message to the console. This would be a good app to start your testing with. It can be found with this article, see zip.html.

More Stories By Jonathan Forck

Jonathan Forck is a
J2EE developer who has
done key work on several
online banking applica-
tions developed for a
group of banks. Jonathan
has written his own imple-
mentation of the security
interface for WAS 5.1
and is currently working
on a plug-in to the Eclipse
Framework that will be a
clear-text TCP/IP monitor
for SSL-encrypted Web

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.