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
|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
|MessageProducerSSBBean||Has three environment references defined,
enabling it to access the JMS provider resources it needs to
send messages: |
|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.
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:
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.
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):
- Navigate to the Queue Managers folder.
- Create a new queue manager named
QMGRwith 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.
- Navigate to the Queues folder for QMGR.
- Create a new local queue named
EXAMPLE.QUEUEwith 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
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:
- Define the JMS publish/subscribe administration queues:
C:\WebSphere MQ\bin> runmqsc QMGR < ..\Java\bin\MQJMS_PSQ.mqsc
- 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:
- Start the application server
- View the WebSphere MQ messaging provider panel
- Define the JMS connection factory
- Define the JMS queue
- Define the JMS topic
- Define the listener ports
1. Start the application server
- 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
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.
- 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):
- 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
- 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 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 label JMS class WebSphere MQ connection factories ConnectionFactory WebSphere MQ queue connection factories QueueConnectionFactory WebSphere MQ queue destinations Queue WebSphere MQ topic connection factories TopicConnectionFactory WebSphere MQ topic destinations Topic
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
- 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).
- Press the New button. On the next panel, enter or
select the following values:
Field name Description Value Name Any string; by convention, we use the same name as its JNDI leaf. JMSExampleConnectionFactory JNDI name The same value used when defining the JNDI binding of the resource reference for the stateless session bean. jms/JMSExampleConnectionFactory Queue manager Name of the WebSphere MQ queue manager that implements the queue and whose MA0C broker implements the topic that the application will use. QMGR Transport type Bindings 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 ID Required 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 version Basic 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 selection Indicates 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
- 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:
- In the Administrative console, navigate again to the WebSphere MQ messaging provider panel.
- In the Additional Properties section, select WebSphere MQ queue destinations.
- On the WebSphere MQ queue destinations panel, press the New button.
- On the next panel, enter or select the following values:
Field name Description Value Name Can be any string; by convention, we use the same name as its JNDI leaf. JMSExampleQueue JNDI name The same value used when defining the environment reference for the stateless session bean. jms/JMSExampleQueue Base queue name Name 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
- 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:
- In the Administrative console, navigate again to the WebSphere MQ messaging provider panel.
- In the Additional Properties section, select WebSphere MQ topic destinations to display the WebSphere MQ topic destinations panel.
- Press the New button.
- On the New WebSphere MQ topic destinations panel (Figure 9), enter or
select the following values:
Field name Description Value Name Can be any string; by convention, we use the same name as its JNDI leaf. JMSExampleTopic JNDI name The same value used when defining the environment reference for the stateless session bean. jms/JMSExampleTopic Base topic name Name 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
- 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:
- In the administrative console, navigate to Servers =>
Application Servers (Figure 10).
Figure 10. Navigate to the Application servers panel
- 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. Application server configuration panel
- In the Communications section, navigate to Messaging => Message Listener Service, then select Listener Ports.
- On the Listener Ports panel, press the New button.
- On the New listener port panel (Figure 12), enter or select the
Field name Description Value Name The 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 name The same value as the JNDI Name field in the connection factory defined earlier. jms/JMSExampleConnectionFactory Destination JNDI name The 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
- At the bottom of the panel, press Apply to submit the changes.
- Follow steps a through f again to create a second listener port with
Field name Value Name JMSExampleTopicPort Connection factory JNDI name jms/JMSExampleConnectionFactory Destination JNDI name jms/JMSExampleTopic
- Save your changes to the server's configuration files by selecting the Save link, then the Save button.
- 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:
7. Deploy the application
To add our JMSExample application to the server:
- If you are using Rational Application Developer:
- Go to the Servers view, select the server, then Add and remove projects... from the pop-up menu.
- 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
Figure 13. Add and Remove Projects dialog in Rational Application Developer
- For WebSphere Application Server:
- Open the administrative console and navigate to Applications => Install New Application.
- Use the Application Installation panels to install the
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:
- 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.
- 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:
- 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
- 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
- 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:
- From the Project Explorer, navigate to EJB Projects => JMSExampleEJB => Deployment Descriptor: JMSExampleEJB => Session Beans => MessageProducerSSB.
- Right-click on the bean, then select Run => Run on
server... (Figure 15).
Figure 15. Run stateless session bean
- 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.
- 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):
If this URL doesn't work, verify that the application is deployed and running:
- 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.
- 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.
- 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
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:
- In the UTC navigation panel, navigate to EJB Beans =>
MessageProducerSSBLocal => MessageProducerSSBLocalHome =>
Figure 17. Universal Test Client
- Select the home's create() method.
- In the Parameters panel, click the Invoke button.
- 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
- Under MessageProducerSSBLocal 1 in the EJB Beans list, select the bean's sendMessage(String) method.
- 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.)
- 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
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
test topic 456, and press
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:
- Open an administrative console and navigate to Application servers => server1 => Message Listener Service => Listener Ports.
- Stop the JMSExampleTopicPort listener port by checking its box and
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.
- 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.
- 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.
- Go back to the administrative console and start the listener port.
System.out should again show that the listener port starts:
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.
- To show that both subscribers really are running again, run
publishMessage(String) once more with sample text like
test durability 000.
- 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!
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.
The author thanks Roland Barcia, Wayne Beaton, Tom Alcott, Don Fox, Paul Roubekas, and David Currie for their help with this article.
|Code sample||JMSExample.ZIP ( HTTP | FTP )||17 KB|
IBM products and SupportPacs
- WebSphere Application Server
- WebSphere MQ
- Rational Application Developer for WebSphere Software
- WebSphere Business Integration Event Broker
- WebSphere Business Integration Message Broker
- MA0C SupportPac - WebSphere MQ (MQSeries) - Publish/Subscribe
- Java Technology - Java 2 Platform, Enterprise Edition (J2EE)
- J2EE - Java Message Service (JMS)
- J2EE - Enterprise JavaBeans Technology (EJB)
- Core Java - Java Naming and Directory Interface (JNDI)
Other documentation -- Books
- WebSphere Application Server, Version 6 Information Center
- WebSphere MQ Information Center, V1.3
- WebSphere Application Server V6 System Management and Configuration Handbook (IBM Redbook SG24-6451-00; Feruuary 2005)
- WebSphere MQ Using Java (IBM Publication SC34-6066-02; January 2004)
- MQSeries Publish/Subscribe User's Guide (IBM Publication GC34-5269-09; June 2002)
- MQSeries Publish/Subscribe Applications (IBM RedBook SG24-6282-00; September 2001)
- WebSphere Application Server and WebSphere MQ Family Integration (IBM Redbook SG24-6878-00; October 2003)
- IBM WebSphere: Deployment and Advanced Configuration by Roland Barcia, Bill Hines, Tom Alcott, and Keys Botzum (IBM Press ISBN 0131468626; August 2004)
- Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf (Addison Wesley ISBN 0321200683; October 2003)
Other documentation -- Articles
- Introducing the Java Message Service by Willy Farrell (developerWorks tutorial; June 2004)
- JMS 1.1 simplifies messaging with unified domains by Bobby Woolf (developerWorks article; August 2002)
- Developing a standalone Java application for WebSphere MQ by Bobby Woolf (developerWorks article; February 2005)
- Deploying message-driven beans and JMS applications into the Service Integration Bus by Roland Barcia and Saravana Chandran
- Configuring and using XA distributed transactions in WebSphere Studio by Bobby Woolf (developerWorks article; June 2004)
- JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version 5 by Roland Barcia, Sree Ratnasinghe, and Benedict Fernandes (developerWorks article; October 2003)
- J2EE in Practice
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.