IBM WebSphere Developer Technical Journal: Make WebSphere MQ the JMS provider for applications deployed in WebSphere Application Server

Configure IBM® WebSphere® Application Server V6 to use IBM WebSphere MQ V5.3 as its Java™ Message Service (JMS) provider.

Bobby Woolf, WebSphere J2EE Consultant, IBM Software Services for WebSphere

Photo of Bobby WoolfBobby Woolf is a WebSphere J2EE Consultant for IBM Software Services for WebSphere (ISSW). Bobby assists clients in developing applications for WebSphere Application Server using WebSphere Studio Application Developer. He is a co-author of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion. He also has a blog on the IBM developerWorks web site called J2EE in Practice. Bobby is a frequent conference speaker.


developerWorks Master author
        level

11 May 2005

Also available in Chinese

Introduction

Many organizations have come to rely on IBM WebSphere MQ for enterprise messaging and IBM WebSphere Application Server to deploy their Java 2 Platform Enterprise Edition (J2EE™) applications. Naturally, these organizations wish to have the ability to employ these two products together, to use WebSphere MQ as the Java Message Service (JMS) provider for J2EE applications deployed in WebSphere Application Server.

This article helps fulfill this wish by demonstrating how to configure WebSphere Application Server V6 to use WebSphere MQ V5.3 as its JMS provider. We will assume that WebSphere Application Server and WebSphere MQ are installed on the same server computer (which is the preferred topology), and include a simple J2EE application to demonstrate and test JMS messaging for both point-to-point and publish/subscribe domains.

The application code used in this article can most easily be reviewed and tested using IBM Rational® Application Developer for WebSphere Software V6 (hereafter referred to as Application Developer). Alternatively, the tasks outlined here can also be performed using the WebSphere Application Server Toolkit (ASTK). Examples given are shown using the products on Microsoft® Windows® XP.


Examine the sample code

Before we look at how to configure the server, let's look at the sample code that will use the configuration outlined in this article. (Download the sample application below.)

Our sample application, JMSExample, is not a complete application, but rather several simple Enterprise JavaBean (EJB) components that demonstrate the sending and receiving of messages using JMS. A complete application would use classes like these to enable the application to use messaging. To understand how the example works, we will examine the classes and their deployment descriptor. A simple way to review the code is to import the EAR file into Application Developer (see Deploying message-driven beans and JMS applications into the Service Integration Bus).

Examine the classes

The classes in JMSExample implement the EJB components listed below, and shown in Figure 1.

Figure 1. EJBs in sample classes
Figure 1. EJBs in sample classes
EJBDescription
MessageProducerSSBBean A stateless session bean that creates and sends messages. Encapsulating this code in an EJB enables the code to have its own environmental references for accessing JMS resources. In a complete application, encapsulating the messaging code in an EJB component enables the EJB container to manage transactions between the messaging provider and other transactional resources such as a database.

The bean has two public methods, sendMessage(String) and publishMessage(String), which are used to add a message containing some text to the example's queue or topic, respectively. Since JMS 1.1 unifies the point-to-point and publish/subscribe messaging domains, to avoid duplicate code, these two methods simply call a third, private method, produceMessage(String, String, String), which does all of the work of creating the message and adding it to either a queue or a topic.

ReceiverMDBBean A message-driven bean (MDB) that will be configured to listen for messages on the example's queue. When it receives a message, it prints output to System.out that shows the message's contents.
SubscriberNDMDBBean An MDB that will be configured to listen for messages on the example's topic as a non-durable subscriber. Like ReceiverMDBBean, this bean also displays the contents of the messages it receives.
SubscriberDMDBBean An MDB, just like SubscriberNDMDBBean, that listens to the same topic but does so as a durable subscriber. Because we will have two bean classes associated with the topic, there will be two bean pools (two sets of MDB instances), each of which will receive any published message, showing that a topic indeed broadcasts each message to all subscribers.

Examine the deployment descriptor

The EJB components have been configured in the EJB deployment descriptor with environment references, which enable the EJBs to access server resources by their Java Naming and Directory Interface (JNDI) names. These references, below, can be seen in the EJB Deployment Descriptor editor (Figure 2).

Figure 2. EJB Deployment Descriptor editor
Figure 2. EJB Deployment Descriptor editor
EJBEnvironment references
MessageProducerSSBBean Has three environment references defined, enabling it to access the JMS provider resources it needs to send messages:
  1. jms/JMSExampleConnectionFactoryRef -- Reference to the JMS ConnectionFactory bound in the JNDI directory with the key jms/JMSExampleConnectionFactory.
  2. jms/JMSExampleQueueRef -- Reference to the JMS Queue bound in the JNDI directory with the key jms/JMSExampleQueue.
  3. jms/JMSExampleTopicRef -- Reference to the JMS Topic bound in the JNDI directory with the key jms/JMSExampleTopic.
ReceiverMDBBean Destination type = "Queue"
Listener port = "JMSExampleQueuePort"
SubscriberNDMDBBean Destination type = "Topic"
Subscription durability = "NonDurable"
Listener port = "JMSExampleTopicPort"
SubscriberDMDBBean Destination type = "Topic"
Subscription durability = "Durable"
Listener port = "JMSExampleTopicPort"

The two subscriber pools will share the same listener port.

MDB references to resources

The MDB classes do not need references defined because an MDB does not need user code to receive messages. However, if the MDB's user code also sends messages, such as to send a reply when the MDB receives a request or accesses other resources (like a database to store the contents of the message), then the MDB does need references to locate these resources via JNDI.

So how does an MDB know what destination to receive messages from? The EJB specification requires that each MDB must be associated with the destination or endpoint it will listen to -- but the specification does not stipulate how this association is made. WebSphere Application Server, both Versions 5 and 6, uses a listener port to associate an MDB class with a JMS destination in the WebSphere MQ provider.

J2EE 1.4 supports JMS API implementations that use the J2EE Connector Architecture (J2C). A JMS provider with this implementation, such as the Default Messaging provider in WebSphere Application Server V6, has an MDB associated with its JMS destination using an activation specification. However, the implementation of JMS in WebSphere MQ V5.3 is not built with the connector architecture, so the association is made instead with a listener port, the same as in WebSphere Application Server V5.


Configure WebSphere MQ

Now that we're familiar with the sample JMS application, we will setup WebSphere MQ so that WebSphere Application Server can use it as the JMS provider.

WebSphere MQ must already be installed to use the WebSphere MQ provider in WebSphere Application Server. We assume both WebSphere Application Server and MQ are installed on the same server, and that the application will connect using bindings transport mode. We assume this for two reasons:

  • Simplicity
    WebSphere MQ installed locally with the application server makes the example simpler. This enables WebSphere Application Server to connect to WebSphere MQ in bindings transport mode, which uses Java Native Interface (JNI) libraries to connect to the MQ queue manager directly, rather than client connection mode, where the connection is established over a TCP/IP network connection.
  • Practicality
    In general, using client mode to access WebSphere MQ is a necessary evil. Often, the messaging application (in this case, a J2EE application running in WebSphere Application Server) is not running on the same computer as WebSphere MQ, so the application must use a synchronous, less reliable TCP/IP network connection to connect to its asynchronous, highly-reliable messaging system. However, WebSphere Application Server V6 includes the Service Integration Bus and WebSphere MQ link; a combination that can be used as a bridge for connecting to WebSphere MQ, providing a much higher quality approach than using client mode. Therefore, either use WebSphere MQ in bindings mode, or use WebSphere MQ link instead of client mode.

Create the queue manager and queue

In the WebSphere MQ Explorer (Figure 3):

  1. Navigate to the Queue Managers folder.
  2. Create a new queue manager named QMGR with the default settings. (By convention, the TCP/IP listener port should be port number 1414, but the port is optional since we're using bindings transport mode.) When WebSphere Application Server connects the application to WebSphere MQ, it will connect the application to this queue manager.
  3. Navigate to the Queues folder for QMGR.
  4. Create a new local queue named EXAMPLE.QUEUE with the default settings. This is the queue the application will use to perform point-to-point messaging.
Figure 3. New queue manager and local queue
Figure 3. New queue manager and local queue

Configure WebSphere MQ for publish/subscribe

WebSphere MQ V5.3 does not include support for publish/subscribe messaging, but you can add that support by installing the MA0C SupportPac: WebSphere MQ (MQSeries) Publish/Subscribe, which we assume you will be using. Recent fix packs for WebSphere MQ, starting with CSD08, include the MA0C SupportPac. (Run mqver to see what version of WebSphere MQ you have.) If your install doesn't have the SupportPac, you can add it (see Resources to find where to download it). If you use a separate publish/subscribe product, such as WebSphere Business Integration Event Broker or Message Broker, some of the WebSphere Application Server configuration settings shown in this article will be different.

When the MA0C SupportPac is installed, you need to configure and start it:

  1. Define the JMS publish/subscribe administration queues:
    C:\WebSphere MQ\bin> runmqsc QMGR < ..\Java\bin\MQJMS_PSQ.mqsc
  2. Start the broker and confirm that it is running:
    C:\WebSphere MQ\bin> strmqbrk -m QMGR
    MQSeries Publish/Subscribe broker started for queue manager QMGR.
    
    C:\WebSphere MQ\bin> dspmqbrk -m QMGR
    MQSeries Publish/Subscribe broker for queue manager QMGR running.

The MA0C SupportPac is now installed, the admin queues are defined, and the broker is started. WebSphere MQ is now ready for the publish/subscribe feature, which implements the broker for the topic the application will use to perform publish/subscribe messaging.


Configure the application server

To configure WebSphere Application Server to use WebSphere MQ as its JMS provider, you will need to perform these general steps:

  1. Start the application server
  2. View the WebSphere MQ messaging provider panel
  3. Define the JMS connection factory
  4. Define the JMS queue
  5. Define the JMS topic
  6. Define the listener ports

1. Start the application server

  1. If you are using Application Developer to start WebSphere Application Server, switch to the Servers view, select the server, and press the Start button. (Figure 4)
    Figure 4. Start the server
    Figure 4. Start the server
    To start WebSphere Application Server from an OS command line, run the startServer script (assuming you created your server with the default profile and its name is server1):
    C:\WebSphere Application Server\bin> startServer server1

    When the server has started successfully, you will see this message in the Console view or in the SystemOut.log file (located in the <was_home>\profiles\server1\logs directory):
    WSVR0001I: Server server1 open for e-business

    If you are using Rational Application Developer, the Servers view shows the server's status as Started.
  2. Open the administration console. In Application Developer, select the server in the Servers view, right-click and select Run administrative console. The admin console can also be run by opening a Web browser on this URL (assuming the server is running on your local machine using the default port settings):
    http://localhost:9060/ibm/console
  3. Log into the console. Use the administrative console to perform the steps in the next sections, which are the same regardless of how you started WebSphere Application Server.

2. View the WebSphere MQ messaging provider panel

  1. In the administrative console, navigate to Resources => JMS Providers => WebSphere MQ (Figure 5) to display the main WebSphere MQ messaging provider panel (Figure 6).
    Figure 5. Navigate to WebSphere MQ
    Figure 5. Navigate to WebSphere MQ
    Figure 6. WebSphere MQ messaging provider
    Figure 6. WebSphere MQ messaging provider

    The default scope is Node, which is fine (scope doesn't really matter in this example since we're only using one server in one node of one cell; any scope will apply the configuration to our server). The General Properties are already set for you. The links in the Additional Properties section enable you to manage the following JMS administered objects:

    Link labelJMS class
    WebSphere MQ connection factoriesConnectionFactory
    WebSphere MQ queue connection factoriesQueueConnectionFactory
    WebSphere MQ queue destinationsQueue
    WebSphere MQ topic connection factoriesTopicConnectionFactory
    WebSphere MQ topic destinationsTopic

    The objects administered in WebSphere Application Server are bound in JNDI and enable the JMS code in your J2EE application to access the corresponding resources in WebSphere MQ. (Each of the WebSphere MQ provider objects has a variety of settings that can be configured, but we only cover the major ones needed to set to get the example working. See sections 10.6.3, "Configuring the WebSphere MQ JMS provider" and 10.6.4, "Configuring listener ports" in the WebSphere Application Server V6 System Management and Configuration Handbook for more information.)

3. Define the JMS connection factory

  1. We need to define the JMS connection factory our code will use to get JMS connections to WebSphere MQ. In the Additional Properties section of the dialog (Figure 6), select WebSphere MQ connection factories to display the WebSphere MQ connection factories panel (Figure 7).
  2. Press the New button. On the next panel, enter or select the following values:

    Field nameDescriptionValue
    NameAny string; by convention, we use the same name as its JNDI leaf.JMSExampleConnectionFactory
    JNDI nameThe same value used when defining the JNDI binding of the resource reference for the stateless session bean.jms/JMSExampleConnectionFactory
    Queue managerName of the WebSphere MQ queue manager that implements the queue and whose MA0C broker implements the topic that the application will use.QMGR
    Transport typeBindings indicates that WebSphere MQ and its queue manager are installed locally, on the same computer as WebSphere Application Server, and therefore can be accessed directly. Alternatively, the transport type could be Client, which uses TCP/IP to connect remotely to the queue manager; as explained earlier, though, WebSphere Application Server V6 applications should use WebSphere MQ link instead of Client mode to access WebSphere MQ remotely.Bindings
    Client IDRequired setting because the example includes a durable subscriber. JMS identifies each durable subscription uniquely using the combination of topic name, client ID, and subscriber name. This setting is the client ID required by JMS. It can be any string, but needs to be unique for each (topic) connection factory.client1
    Broker versionBasic means that we are using the MA0C SupportPac. The alternative setting, Advanced, would indicate that we are using a separate publish/subscribe product, WebSphere Business Integration Event Broker or Message Broker.Basic
    Broker message selectionIndicates what part of the messaging system implements message selectors. (This example does not use message selectors, but the setting has to be configured anyway.) The MA0C broker only supports performing message selection in the client.Client

    Accept the default values for all other settings. Specifically, there are several fields for specifying the various broker admin queues. As long as you used the MQJMS_PSQ.mqsc file to define those queues, the default names will have the proper values, so you can leave these fields blank in WebSphere Application Server and it will assume the default names.

    Figure 7. WebSphere MQ connection factories
    Figure 7. WebSphere MQ connection factories
  3. Press Apply at the bottom of the panel to submit the changes.

4. Define the JMS queue

We need to define the JMS queue that our code will use to perform point-to-point messaging using WebSphere MQ:

  1. In the Administrative console, navigate again to the WebSphere MQ messaging provider panel.
  2. In the Additional Properties section, select WebSphere MQ queue destinations.
  3. On the WebSphere MQ queue destinations panel, press the New button.
  4. On the next panel, enter or select the following values:

    Field nameDescriptionValue
    NameCan be any string; by convention, we use the same name as its JNDI leaf.JMSExampleQueue
    JNDI nameThe same value used when defining the environment reference for the stateless session bean.jms/JMSExampleQueue
    Base queue nameName of the queue inside WebSphere MQ (as opposed to this Java reference for accessing the queue). This is the same queue name used earlier when we configured WebSphere MQ.EXAMPLE.QUEUE

    Accept the default values for all of the other settings. Specifically, if Base queue manager name is left blank, its default value will be the Queue manager value of the connection factory used to connect to the queue.

    Figure 8. WebSphere MQ queue destinations
    Figure 8. WebSphere MQ queue destinations
  5. Press Apply to submit the changes.

5. Define the JMS topic

We need to define the JMS topic our code will use to perform publish/subscribe messaging using WebSphere MQ:

  1. In the Administrative console, navigate again to the WebSphere MQ messaging provider panel.
  2. In the Additional Properties section, select WebSphere MQ topic destinations to display the WebSphere MQ topic destinations panel.
  3. Press the New button.
  4. On the New WebSphere MQ topic destinations panel (Figure 9), enter or select the following values:

    Field nameDescriptionValue
    NameCan be any string; by convention, we use the same name as its JNDI leaf.JMSExampleTopic
    JNDI nameThe same value used when defining the environment reference for the stateless session bean.jms/JMSExampleTopic
    Base topic nameName of the topic inside of WebSphere MQ's MA0C broker. This name can be anything, but should be a unique and descriptive topic name.ExampleTopic

    Accept the default values for all other settings. Specifically, there are two fields for specifying durable subscription admin queues. As long as you used the MQJMS_PSQ.mqsc file to define those queues, the default values should be correct, so you can leave these fields blank in WebSphere Application Server and it will assume the default names.

    Figure 9. WebSphere MQ topic destinations
    Figure 9. WebSphere MQ topic destinations
  5. Press Apply to submit the changes.

6. Define the listener ports

Our sample code requires two listener ports, which we need to define in the server:

  • JMSExampleQueuePort
  • JMSExampleTopicPort.
  1. In the administrative console, navigate to Servers => Application Servers (Figure 10).
    Figure 10. Navigate to the Application servers panel
    Figure 10. Navigate to the Application servers panel
  2. In the Application servers panel, click on server1, which is the link for your server (the server is named server1 by default.) to display the Application server configuration panel (Figure 11).
    Figure 11. Application server configuration panel
    Figure 11. Application server configuration panel
  3. In the Communications section, navigate to Messaging => Message Listener Service, then select Listener Ports.
  4. On the Listener Ports panel, press the New button.
  5. On the New listener port panel (Figure 12), enter or select the following values:

    Field nameDescriptionValue
    NameThe same name specified in the configuration for ReceiverMDBBean. The listener port name can be any string, but the name in the MDB configuration must match..JMSExampleQueuePort
    Connection factory JNDI nameThe same value as the JNDI Name field in the connection factory defined earlier.jms/JMSExampleConnectionFactory
    Destination JNDI nameThe same value as the JNDI Name field in the queue defined earlier.jms/JMSExampleQueue

    Accept the default values for all other settings. Specifically, an Initial State of Started means that the listener port will start when the server starts.

    Figure 12. New listener port
    Figure 12. New listener port
  6. At the bottom of the panel, press Apply to submit the changes.
  7. Follow steps a through f again to create a second listener port with these settings:

    Field nameValue
    NameJMSExampleTopicPort
    Connection factory JNDI namejms/JMSExampleConnectionFactory
    Destination JNDI namejms/JMSExampleTopic
  8. Save your changes to the server's configuration files by selecting the Save link, then the Save button.
  9. Log out of the aministrative console and close the browser.

Deploy and restart

Now that the server is configured, we are almost ready to deploy and test the application. First, though, restart the server so that it runs with the configuration changes. (You can restart the server, then deploy the application, but then you won't see the application startup messages in the Console view or in SystemOut.log when you restart the server.)

In this section we will:

  1. Deploy the application
  2. Restart the server
  3. Examine the startup messages.

7. Deploy the application

To add our JMSExample application to the server:

  1. If you are using Rational Application Developer:
    1. Go to the Servers view, select the server, then Add and remove projects... from the pop-up menu.
    2. In the Add and Remove Projects dialog, add JMSExample to the list of configured projects, then press Finish. By associating the enterprise project with the server in this way, not only is the project deployed to the server, but future code changes in the project will automatically become available when you restart the server.
      Figure 13. Add and Remove Projects dialog in Rational Application Developer
      Figure 13. Add and Remove Projects dialog in Rational Application Developer
  2. For WebSphere Application Server:
    1. Open the administrative console and navigate to Applications => Install New Application.
    2. Use the Application Installation panels to install the JMSExample.ear file.
      Figure 14. Application installation WebSphere Application Server
      Figure 14. Application installation WebSphere Application Server

With either approach, when you deploy the application, unless you have already restarted the server, you will get errors on the console and in the SystemOut.log file that say the application cannot be started. This occurs because the configuration changes we made do not take effect until the server is restarted, so you can ignore these errors at this time. Once restarted, the server will start the application successfully with the resources we have configured for it.

8. Restart the server

You need to stop and start the server so it can re-read the configuration files we changed and run with the new configuration:

  1. In the Rational Application Developer Servers view, right-click the server and select Restart => Start. Alternatively, you can click the Stop button to stop the server, then the Start button to start it again. The Servers view shows the server's status as Started.
  2. If you're running WebSphere Application Server from an OS command line, run the stopServer and startServer scripts with these commands (assuming your server has the default profile and is named server1):
    C:\WebSphere Application Server\bin> stopServer server1
    C:\WebSphere Application Server\bin> startServer server1

    Once restarted, you will see this message in the console or in the SystemOut.log file:
    WSVR0001I: Server server1 open for e-business

9. Examine the startup messages

When you start the server, a number of status messages are printed to System.out (the console or in the SystemOut.log file). Let's examine the ones that pertain to our example:

  1. These messages show that our connection factory, queue, and topic have been bound into JNDI:
    WSVR0049I: Binding JMSExampleConnectionFactory as jms/JMSExampleConnectionFactory
    WSVR0049I: Binding JMSExampleQueue as jms/JMSExampleQueue
    WSVR0049I: Binding JMSExampleTopic as jms/JMSExampleTopic
  2. These messages show that our application (including its EJB JAR file) has been started:
    WSVR0200I: Starting application: JMSExample
    WSVR0207I: Preparing to start EJB jar: JMSExampleEJB.jar
    WSVR0037I: Starting EJB jar: JMSExampleEJB.jar
    WSVR0221I: Application started: JMSExample
  3. These messages show that the listener ports have started. (The message is printed once for each MDB class, which is why we see the message for the topic port twice.)
    WMSG0042I: MDB Listener JMSExampleTopicPort started successfully 
    for JMSDestination jms/JMSExampleTopic
    WMSG0042I: MDB Listener JMSExampleTopicPort started successfully 
    for JMSDestination jms/JMSExampleTopic
    WMSG0042I: MDB Listener JMSExampleQueuePort started successfully 
    for JMSDestination jms/JMSExampleQueue

Assuming that you see all of these messages and do not see any errors or exception stack dumps, your server and example application have started successfully.


Test the application

So far, we have configured the server, deployed the application, and successfully restarted the server. Now, we will test our application using the Universal Test Client (UTC), an IBM tool included with Rational Application Developer, the Application Server Toolkit (ASTK), and WebSphere Application Server. We will use the UTC to run our stateless session bean, and then watch System.out to see what the MDBs do.

In Rational Application Developer, we will run MessageProducerSSBBean on our server, which will open the UTC on an instance of the bean's home that is running in the server. To do this:

  1. From the Project Explorer, navigate to EJB Projects => JMSExampleEJB => Deployment Descriptor: JMSExampleEJB => Session Beans => MessageProducerSSB.
  2. Right-click on the bean, then select Run => Run on server... (Figure 15).
    Figure 15. Run stateless session bean
    Figure 15. Run stateless session bean
  3. In the Server Selection dialog, select the server you configured for this example, then Finish. This will start the server (if it isn't already running) and run the UTC on the stateless session bean's home.
  4. Switch to the Console view and scroll to the bottom so you can watch for output from the MDBs.

Starting the UTC without an IDE

The easiest way to start the Universal Test Client is to use Rational Application Developer or the Application Server Toolkit (ASTK) to run an EJB on the server. However, if you started WebSphere Application Server from the command line and simply want to run the UTC in a Web browser, you can do that too, with a little more effort.

The UTC is a J2EE application called IBMUTC. If the application is already running, open the UTC with a Web browser on this URL (assuming the server is running on your local machine using the default port settings):

http://localhost:9080/UTC/

If this URL doesn't work, verify that the application is deployed and running:

  1. In the administrative console, look for the IBMUTC application in the list of installed applications (by navigating to Applications => Enterprise Applications) and confirm that it has started.
  2. If the application is not in the list, you will need to install it (by navigate to Applications => Install New Application). The EAR file is located at <was_home>\deploytool\itp\plugins\com.ibm.etools.utc_6.0.0\IBMUTC.ear -- not in the <was_home>\installableApps directory. If you cannot find this file, WebSphere Application Server must be installed without the samples, in which case you should install and use either the ASTK or Rational Application Developer instead.
  3. When you open the UTC using its URL, you need to locate the home for the EJB component you wish to test. Using the JNDI Explorer, navigate to [Local EJB Beans] => ejb => com => ibm => examples => jms => MessageProducerSSBLocalHome, and select MessageProducerSSBLocalHome to add it to the EJB Beans section of the navigation panel. (Figure 16)
Figure 16. Locate EJB component to test
Figure 16. Locate EJB component to test

You can now use the UTC and the EJB's home to create and test an EJB, just as if you had chosen to run it on the server.

Test point-to-point messaging

For the first test, we will send a test message point-to-point and confirm that it is received successfully:

  1. In the UTC navigation panel, navigate to EJB Beans => MessageProducerSSBLocal => MessageProducerSSBLocalHome => MessageProducerSSBLocal create().
    Figure 17. Universal Test Client
    Figure 17. Universal Test Client
  2. Select the home's create() method.
  3. In the Parameters panel, click the Invoke button.
  4. In the Results panel, you will notice that an instance named MessageProducerSSBLocal 1 has been created. Press Work with Object to add the instance to the EJB Beans list.
    Figure 18. Setup Universal Test Client
    Figure 18. Setup Universal Test Client
  5. Under MessageProducerSSBLocal 1 in the EJB Beans list, select the bean's sendMessage(String) method.
  6. The Parameters panel now contains fields and a button for invoking sendMessage(String) on the stateless session bean. (We are getting ready to send a JMS message, so be sure you can see the text at the bottom of the Console view, or at the end of the SystemOut.log file.)
  7. For the String parameter, in the Value field, enter some simple text for testing, such as test queue 123, then Invoke.
    Figure 19. String parameter for testing point-to-point messaging
    Figure 19. String parameter for testing point-to-point messaging

The Results panel should show that the method completed successfully. Wait a few seconds, and if everything is working correctly, the Console (or SystemOut.log file) should show this output:

MESSAGE DRIVEN BEAN 'Receiver' CONSUMED MESSAGE: test queue 123

This test shows that our ReceiverMDB bean received the message that our MessageProducerSSB bean just sent onto our JMSExampleQueue queue. Point-to-point messaging works!

Test publish/subscribe messaging

For the next test, we will publish a test message and confirm that both subscribers receive it successfully.

In the UTC EJB Beans list, under MessageProducerSSBLocal 1, select the publishMessage(String) method. Enter some parameter value like test topic 456, and press Invoke.

Figure 20. String parameter for testing publish/subscribe messaging
Figure 20. String parameter for testing publish/subscribe messaging

The method completes successfully and in a few seconds you should see this output:

MESSAGE DRIVEN BEAN 'Non-durable Subscriber' CONSUMED MESSAGE: test topic 456
MESSAGE DRIVEN BEAN 'Durable Subscriber' CONSUMED MESSAGE: test topic 456

These messages show that our SubscriberNDMDB and SubscriberDMDB beans both received the message that our MessageProducerSSB bean just published onto our JMSExampleTopic topic. Publish/subscribe messaging works!

Test the durable subscriber

For the next test, we will show that the durable subscriber's subscription really is durable, and demonstrate the difference between a durable and non-durable subscription:

  1. Open an administrative console and navigate to Application servers => server1 => Message Listener Service => Listener Ports.
  2. Stop the JMSExampleTopicPort listener port by checking its box and selecting Stop.
    Figure 21. Stop listener port
    Figure 21. Stop listener port
    The status icon should change to a red X (indicating Stopped), and System.out should display:
    WMSG0043I: MDB Listener JMSExampleTopicPort stopped for JMSDestination jms/JMSExampleTopic

    This represents the subscriber applications being taken offline.
  3. Back in the UTC, run publishMessage(String) again with some sample text like "test durability 789." The results should show that the method ran correctly, and System.out should show nothing.
  4. Wait a minute to confirm that the MDBs will not receive the message; they shouldn't because their listener port isn't running and, therefore, isn't listening for any messages.
  5. Go back to the administrative console and start the listener port. System.out should again show that the listener port starts:

    Click to see code listing

    WMSG0042I: MDB Listener JMSExampleTopicPort started successfully for JMSDestination jms/JMSExampleTopic

    and then that one of the subscribers received the message you sent a minute ago:
    MESSAGE DRIVEN BEAN 'Durable Subscriber' CONSUMED MESSAGE: test durability 789

    Only one subscriber received the message, the durable one, whereas the other did not. This is the difference between a durable subscription and a non-durable subscription: the former queues messages while its subscriber is offline, then delivers them when the subscriber is back online; a non-durable subscription automatically unsubscribes when its subscriber goes offline.
  6. To show that both subscribers really are running again, run publishMessage(String) once more with sample text like test durability 000.
  7. System.out shows that both subscribers are now running:
    MESSAGE DRIVEN BEAN 'Durable Subscriber' CONSUMED MESSAGE: test durability 000
    MESSAGE DRIVEN BEAN 'Non-durable Subscriber' CONSUMED MESSAGE: test durability 000

Durable and non-durable subscribers work!


Conclusion

The information provided in this article has shown:

  • A very simple J2EE/JMS application that demonstrates both point-to-point and publish/subscribe messaging.
  • How to set up WebSphere MQ with the necessary queues and with the MA0C SupportPac for publish/subscribe.
  • How to configure a server in WebSphere Application Server to use WebSphere MQ as its JMS provider. We configured the MQ provider with the necessary connection factory, queue, topic, and listener ports to run the example application.
  • How the server starts the application and its resources.
  • Simple tests which demonstrate that the application works.

You should now be able to develop your own J2EE applications for WebSphere Application Server that use WebSphere MQ (with the MA0C SupportPac) as a JMS provider.


Acknowledgement

The author thanks Roland Barcia, Wayne Beaton, Tom Alcott, Don Fox, Paul Roubekas, and David Currie for their help with this article.


Download

DescriptionNameSize
Code sampleJMSExample.ZIP  ( HTTP | FTP )17 KB

Resources

IBM products and SupportPacs

Java specifications

Other documentation -- Books

Other documentation -- Articles

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=83247
ArticleTitle=IBM WebSphere Developer Technical Journal: Make WebSphere MQ the JMS provider for applications deployed in WebSphere Application Server
publish-date=05112005