I Mqrad2 PDF

Write Java Message Service programs using
WebSphere MQ Version 6 and Rational

Application Developer Version 6, Part 2:
WebSphere MQ configurations and
publish/subscribe
Skill Level: Intermediate
Willy Farrell (willyf@us.ibm.com)

Senior Software Engineer
IBM
13 Jun 2006
In this second installment in the series, use IBM Rational® Application Developer and
IBM WebSphere® MQ configurations to make your Java™ Message Service (JMS)
programs more flexible. And while you're at it, learn more about JMS
publish/subscribe programming.
Section 1. Before you start

In the following section, find out how to get the most benefit from this tutorial.
About this tutorial

In this tutorial, you get a step-by-step approach to configuring WebSphere MQ and
Rational Application Developer for client transport, remote queuing, and JMS
publish/subscribe programming. Sample applications along with instructions for
running those applications are provided to demonstrate and test these capabilities
and features.
WebSphere MQ configurations and publish/subscribe

© Copyright IBM Corporation 1994, 2008. All rights reserved. Page 1 of 36
developerWorks® ibm.com/developerWorks
Objectives
In this tutorial, you learn how to:
• Configure and test WebSphere MQ client transport

• Configure and test WebSphere MQ remote queuing
• Configure and run JMS publish/subscribe applications
Prerequisites
If you are a Java programmer who needs to understand how to write and test JMS
programs using WebSphere MQ and Rational Application Developer, this tutorial is
for you. It's assumed that you have intermediate knowledge of Java and an
introductory knowledge of JMS. The instructions in this tutorial also assume that you
have performed the instructions in Part 1, since they build on the configurations and
sample code created and tested in that tutorial.
System requirements
The instructions in this tutorial are for use in a Windows® environment, although
users knowledgeable in other operating systems can probably adapt them for use in
their operating system.
The system requirements for the products used in the tutorial can be found through
the following links:
• WebSphere MQ
• Rational Application Developer
Section 2. Introduction
Continuing from Part 1
In Part 1 of this tutorial series, you get a brief overview of enterprise messaging
systems and JMS. And you get descriptions of the latest tools from IBM for JMS
development and testing, including detailed instructions on obtaining, installing, and

Page 2 of 36 © Copyright IBM Corporation 1994, 2008. All rights reserved.
ibm.com/developerWorks developerWorks®
configuring those tools. You're provided with sample programs and instructions to
help you use the tools and understand how they work.
This tutorial picks up where Part 1 left off, to further explore WebSphere MQ and
JMS programming with Rational Application Developer (Application Developer). The
instructions in this tutorial assume you have performed the instructions in the first
tutorial, since they build on the configurations and sample code created and tested
in that tutorial.
A note about SupportPac ME01

Since Part 1 was published, a new version of WebSphere MQ SupportPac ME01 -
WebSphere MQ Initial Context Factory has been released. You need to download
and install this newest version for the sample code in this tutorial to work correctly.
Go to Resources for a link.
Acknowledgements
I want to acknowledge and thank Mr. Gareth Matthews of IBM Hursley Labs, author
of this SupportPac, for making this new version available in time for this tutorial.
Section 3. WebSphere MQ configurations
Enhancing capabilities of the sample code

In the next two sections, you explore different ways to configure objects
administered by WebSphere MQ and JMS to enhance the capabilities of the sample
code provided in the first tutorial. You are going to change how the messages flow
between the programs, but you'll make all the changes using administrative tools --
with no changes being made to the programs. That's a key strength of JMS because
JMS uncouples the application program from the underlying messaging
implementation, allowing the messaging system configuration to be significantly
changed without requiring changes to the application.

Section 4. WebSphere MQ client transport

WebSphere MQ provides two types of communication from the Java program to a
queue manager: bindings and client. These communication types are called
transport types in WebSphere MQ. The transport type of bindings requires that the
Java program execute on the same computer as the queue manager and uses a
native interface to the queue manager from the Java code. The sample programs
executed in the preceding tutorial use bindings transport. Client transport allows a
Java program to run separately on a workstation or other computer, apart from the
computer where the queue manager is running. The queue manager must have a
server connection channel defined to communicate with the Java client, and a
dedicated network pathway must be available for the Java client to connect to the
queue manager.
Create the server-connection channel

You use WebSphere MQ Explorer to define the server-connection channel required
for Java clients.
1. Launch WebSphere MQ Explorer from the Start menu. (From here

forward, the instructions assume that WebSphere MQ Explorer is
running).
2. Click the + sign next to Ender.
3. Click the + sign next to Advanced.
4. Right-click on Channels and select New > Server-connection Channel.

(See Figure 1.)
Figure 1. Creating new server-connection channel

5. Type java.channel in the Name: field, and click Finish.
Create JMS administered object

Now you can use JMSAdminGUI to create a QueueConnectionFactory that uses
client transport over the server-connection channel you just defined.
1. Launch Application Developer from the Start menu. (From here on, the
instructions assume that Application Developer is running.)
2. Use C:\workspace as your workspace directory.
3. Switch to the Java perspective using the perspective switch button in the
top right corner. (See Figure 2.)
Figure 2. Perspective switch button

4. From the main menu, select Window > Run History > JMSAdminGUI.
5. Select the Open a recent config profile: button. Next, select

C:\workspace/JMSAdminGUI/WMQ.config. (See Figure 3.)
Figure 3. Select config profile
6. Click OK.
7. From the main menu, select Object > New>

MQQueueConnectionFactory.
8. Type ClientEnder in the Object Name: field.
9. Click Standard properties tab.
10. Select Client from the Transport: drop-down.
11. Type Ender in the Queue Manager: field.
12. Type 1414 in the Port: field.
13. Type java.channel in the Channel: field.

14. Type localhost in the HostName: field. The dialog should look like
Figure 4.
Figure 4. Creating new MQQueueConnectionFactory
15. Click OK.
16. Exit JMSAdminGUI.
Run the sample programs

Run the sample programs to test accessing WebSphere MQ through client transport.
Note that the programs are using the same queue as before, even though they are
using a different queue connection factory.
1. In Application Developer, select Run > Run History > QReceiverUI from
the main menu.
2. Type ClientEnder in the Connection: field and press Enter or click

Set.
3. Type EnderQ in the Queue: field and press Enter or click Set.

4. From the main menu, select Run > Run History > QSenderUI.
5. Type ClientEnder in the Connection: field and press press Enter or

click Set.
6. Type EnderQ in the Queue: field and press Enter or click Set.
7. Make both the Queue Sender and Queue Receiver windows visible.
8. Type text into the Message: field of Queue Sender and press Enter or
click Send.
9. The message text should appear in the Queue Receiver window.
10. When finished, close both windows by clicking the X in the top right
corner.
These instructions are for use on a single computer. I encourage you to run the
QReceiverUI and QSenderUI programs on another computer where WebSphere MQ
is not installed to truly demonstrate client transport. Make sure that the host property
of the QueueConnectionFactory has the name of the computer where WebSphere
MQ is installed and that the name can be resolved to an IP address through DNS or
the operating system HOSTS filed. You can also provide an IP address for the host
property. The queue manager that JMSAdminGUI uses as its provider URL will also
have to be configured for client transport.
Section 5. Remote queuing

Up to now, the messages you've been transmitting have been placed on one queue
and read from the same queue. Although there are situations that require this
configuration, the real power of enterprise messaging systems lies in their ability to
move messages from one computer to another, relieving the application programmer
from having to know the details of networking and communications protocols. In
WebSphere MQ, this message flow takes place between queue managers. Unlike
the client configuration described in the preceding section, a dedicated network
connection is not required between the queue managers; a sending queue manager
can store messages when the connection to a receiving queue manager is
unavailable, and then forward accumulated messages as soon as communications
are restored.

Local definition of a remote queue

The configuration for this scenario requires a local definition of a remote queue,
called a remote queue for short. To an application, the remote queue appears no
different than a normal local queue. However, WebSphere MQ "knows" that
messages placed on the remote queue are actually destined for a queue on another
queue manager; it then takes the necessary steps to move messages to the
destination queue. The configuration also requires a transmission queue, a type of
local queue that the queue manager uses to hold messages destined for another
queue manager.
This is where you will define a second queue manager on your computer and a local
queue on that queue manager, which will be the destination for the remote queue.
1. In WebSphere MQ Explorer, right-click on Queue Managers and select

New > Queue Manager.
2. Type Petra in the Queue manager name: field.
3. Type SYSTEM.DEAD.LETTER.QUEUE in the Dead letter queue: field.
4. Click Next three times.
5. Type 1415 in the Listen on port number: field (queue manager Ender is
already using the default port of 1414, so this queue manager must use a
different one).
6. Click Finish.
7. Click the + sign next to Petra.
8. Right-click on Queues and select New > Local Queue. (See Figure 5.)
Figure 5. Creating new queue
9. Type PetraQ in the Name: field. Click Finish.

Now, on the original queue manager, you need to create a transmission queue and
a remote queue, pointing it to the destination queue on the second queue manager.
1. Right-click on Queues under Ender and select New > Local Queue.
2. Type Petra in the Name: field. (By convention, transmission queues are
named for the remote queue manager for which they will be used to
communicate.)
3. Click Next.
4. Select Transmission from the Usage: drop-down. (See Figure 6.)
Figure 6. Configuring queue for transmission usage
5. Click Finish.
6. Right-click on Queues under Ender and select New > Remote Queue
Definition.
7. Type RemotePetraQ in the Name: field.
8. Click Next.

9. Type PetraQ in the Remote queue: field.
10. Type Petra in the Remote queue manager: field.
11. Type Petra in the Transmission queue field. (See Figure 7.)
Figure 7. Configuring remote queue
12. Click Finish.
Communications channels
The mechanism for transporting messages between queue managers is called a
communications channel. To create a communications channel, a channel definition
must be created on each queue manager -- a sender channel, on the queue
manager which is sending messages, and a receiver channel on the queue
manager, which is receiving messages. Each end of the communications channel
has the same name, usually indicating the direction of message flow.
1. In WebSphere MQ Explorer, click the + sign next to Advanced under

Petra.

2. Right-click on Channels and select New > Receiver Channel. (See

Figure 8.)
Figure 8. Creating receiver channel
3. Type Ender_2_Petra in the Name: field.
4. Click Finish.
5. Right-click on Channels under Ender and select New > Sender

Channel.
6. Type Ender_2_Petra in the Name: field.
7. Click Next.
8. Type localhost(1415) in the Connection name: field.
9. Type Petra in the Transmission queue: field. (See Figure 9.)
Figure 9. Sender channel properties

10. Click Finish.
11. Right-click the Ender_2_Petra sender channel and select Start. (See
Figure 10.)
Figure 10. Starting sender channel


Now you can run the sample programs to test remote queuing. Because we are
using SupportPac ME01, you do not need to explicitly create JMS-administered
objects; implicit JMS-administered objects are available for the queue managers and
queues we created. You will have to change the receiving program to use the Petra
queue manager as its provider URL, since that's where the receiving queue is
located.
1. In Application Developer, select Run > Run from the main menu.
2. Select QReceiverUI in the Configurations: list.
3. Click the Arguments tab.
4. Change the java.naming.provider.url to Petra. (See Figure 11.)
Figure 11. QReceiverUI arguments
5. Click Apply. Next, click Run.
6. Type Petra in the Connection: field and press Enter or click Set.
7. Type PetraQ in the Queue: field and press Enter or click Set.
8. From the main menu, select Run > Run History > QSenderUI.

9. Type Ender in the Connection: field and press Enter or click Set.
10. Type RemotePetraQ in the Queue: field and press Enter or click Set.
11. Make both the Queue Sender and Queue Receiver windows visible.
12. Type text into the Message: field of Queue Sender and press Enter or
click Send.
13. You should see the message text appear in the Queue Receiver window.
14. When you are finished, close both windows by clicking the X in the top
right corner.
To more effectively demonstrate remote queuing, I encourage you to set up

WebSphere MQ on two different computers and run QSenderUI on one and
QReceiverUI on the other. The connection name for the sender channel must be a
name that can be resolved to an IP address or be an actual IP address. Each queue
manager on each of the computers can use port 1414, the WebSphere MQ default,
and you won't have to put the port number in parentheses after the connection
name.
Before concluding the discussion of WebSphere MQ configurations, you should

understand that client access and remote queuing can be combined. Thus, an
application on one computer can use client access to put a message on a remote
queue of a queue manager running on a second computer. This queue manager can
transport the message to a destination queue on a queue manager running on a
third computer. An application running on a fourth computer can then retrieve the
message from the destination queue using client access. This scenario is illustrated
in Figure 12.
Figure 12. Client access and remote queuing combined

Section 6. Publish/subscribe
In the next two sections, you configure and run sample programs demonstrating
JMS publish/subscribe capabilities. In the first section, you will run the programs
using WebSphere MQ as the JMS provider. In the second section, you will run the
programs using the built-in JMS provider provided with the WebSphere test
environment included with Application Developer.
Section 7. Run the sample programs with WebSphere

MQ
Configure the WebSphere MQ run-time environment

WebSphere MQ comes with a built-in message broker to support publish/subscribe

applications. You will run a supplied command file to set up the broker and then start
the broker for operation.
1. Open a command prompt and change to directory C:\WSMQ\Java\bin.
2. Type runmqsc Ender<mqjms_psq.mqsc. (See Figure 13.)
Figure 13. Preparing WebSphere MQ message broker
3. Press Enter.
4. Type strmqbrk -m Ender and press Enter.
5. Close the command prompt.
Install the sample code
1. Download the sample code file named i-mqrad2.zip. (I renamed it to

mq6rad6_2.zip after downloading it.) (Click Downloads for a link).
2. Extract this file to a folder on your system. (On my system, I extracted it to

a folder named mq6rad6_2 on my Windows desktop.) There will be two
files in this folder: MQPubSub.zip and EMQPubSub.zip.

3. In Application Developer, from the main menu select File > Import.
4. Select Project Interchange as the import source and click Next.
5. In the From zip file: field, enter the location of the MQPubSub.zip file
extracted previously.
6. Select the checkbox next to the MQPubSub project, and click Finish.
Review the sample code

Before setting up, running, and testing the sample code, take a look at what the
code is doing. As in Part 1, we won't spend any time going over the user interface
classes, just the classes with JMS code.
ChatUser class
The ChatUser class is used by the ChatUserUI to publish messages to, to

subscribe to, and to receive messages from the entered topic. In the point-to-point
sample programs, one class is used for sending messages and another class is
used for receiving messages. Both sending and receiving are handled by
ChatUser. The methods that use JMS programming in ChatUser are similar to the
methods in the point-to-point classes. These are setConnection(), setTopic(),
publishMessage(), and onMessage(). Look at setConnection() shown in
Listing 1 first.
Listing 1. setConnection method
public void setConnection(String connectionName)

throws JMSException, NamingException, Throwable {
try {
close();
TopicConnectionFactory factory =
(TopicConnectionFactory) getInitContext().lookup(connectionName);
connection = factory.createTopicConnection();
publisherSession =
connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
subscriberSession =
connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
} catch (Throwable e) {
setExceptionMessage(e);
throw e;
}
}
The call to close() ensures that any active JMS objects have been properly shut

down. Then, a lookup is done through JNDI to get the TopicConnectionFactory

with the name passed in as the connectionName parameter. Once the
TopicConnectionFactory has been retrieved and a TopicConnection
created, two TopicSession parameters are created, one for publishing and one for
subscribing. It is possible to both publish and receive messages from a single
session, but only if asynchronous message delivery is not activated for the session.
Because ChatUser depends on asynchronous message delivery, we need two
sessions.
The next method to look at is setTopic(). This method is called when a Topic
name is entered in the GUI, as shown in Listing 2.
Listing 2. setTopic() method
public void setTopic(String topicName)

throws JMSException, NamingException, Throwable {
try {
stop();
Topic topic = (Topic) getInitContext().lookup(topicName);
publisher = publisherSession.createPublisher(topic);
subscriber = subscriberSession.createSubscriber(topic);
subscriber.setMessageListener(this);
connection.start();
sendEnterMessage();
publisher = null;
subscriber = null;
throw e;
}
}
The call to stop() ensures that the TopicConnection is stopped and that any
active TopicPublisher and TopicSubscriber objects are closed. The Topic
object is then retrieved from JNDI using the topicName parameter. Next, the
TopicPublisher and TopicSubscriber objects are created using the
respective TopicSession objects. The message listener for asynchronous
message delivery is set for the TopicSubscriber; ChatUser implements the
MessageListener interface, and the onMessage() method of ChatUser will be
called asynchronously as messages arrive for the subscribed topic. The
TopicConnection is then started and sendEnterMessage() is called, which
publishes the message announcing that the user has entered the chat room.
When a message is published, the publishMessage() method is called, as shown

in Listing 3.
Listing 3. publishMessage() method
public void publishMessage(String message) throws JMSException, Throwable {

try {
internalPublishMessage(getUserName() + ": " + message);
throw e;
}
}
As you can see, publishMessage() simply takes the String passed in,
prepends the user name to it, and passes the String to a private method,
internalPublishMessage(). In internalPublishMessage(), a
TextMessage is created with the text parameter, and the TopicPublisher is
used to publish the message.
The last method to look at in ChatUser is onMessage(), shown in Listing 4.
Listing 4. ChatUser onMessage method
public void onMessage(Message message) {

String msgText = null;
try {
msgText = ((TextMessage) message).getText();
msgText = getExceptionMessage();
} finally {
setMessage(msgText);
}
}
This method is called by JMS each time a message is published to the subscribed
topic . The text of the message is used to set the message property of the
ChatUser object. This code should look familiar as it is exactly the same code as
the onMessage() method in QReceiver. With JMS programming, receiving a
message sent to a queue and receiving a message published to a topic are exactly
the same.
ChatMonitor class
The ChatMonitor class is very similar to the ChatUser class, except that it has no
message-publishing facilities. The setConnection() and setTopic() methods
are much like those in ChatUser, except for the absence of code pertaining to
publishing, so we won't go over those in detail. However, let's take a look at the
onMessage() method, shown in Listing 5.
Listing 5. ChatMonitor onMessage method
public void onMessage(Message message) {

String msgText = null;

try {
msgText =
(((Topic) message.getJMSDestination()).getTopicName()
+ ": "
+ ((TextMessage) message).getText());
msgText = getExceptionMessage();
} finally {
setMessage(msgText);
}
}
First, the getJMSDestination() method is called on the Message object that is

passed in. Because it is known that the message came from a Topic, the
Destination is cast to Topic. Then, a call is made to getTopicName() on the
Topic, the topic name is prepended to the message text, and the resulting String
is used to set the message property of ChatMonitor.
Create JMS administered objects

Now, you will use JMSAdminGUI to define the TopicConnectionFactory and a
set of hierarchical Topics for use by the chat programs.
1. In Application Developer, select Run > Run History > JMSAdminGUI.
2. Click the Open a recent config profile: button, select

C:/workspace/JMSAdminGUI/WMQ.config, and click OK.
3. From the main menu, select Object > New >

MQTopicConnectionFactory.
4. Type EnderTCF in the Object Name: field.
5. Click the Standard properties tab.
6. Type Ender in the Queue Manager: field.
7. Type Ender in the Broker QMgr: field. (See Figure 14.)
Figure 14. Creating new MQTopicConnectionFactory

8. Click OK.
9. From the main menu, select Object > New > Topic.
10. Type Java in the Object Name: field.
11. Click the Standard properties tab.
12. Type computers/Java in the Topic: field. (See Figure 15.)
Figure 15. Creating new MQTopicConnectionFactory

13. Click OK.
14. Follow steps 9 through 13 to create additional topics as shown in Table 1.

When finished, exit JMSAdminGUI.
Table 1. Additional topics

Object Name: Topic:
Linux computers/Linux
AllComputers computers/*
Cyberpunk books/cyberpunk
Poetry books/poetry
AllBooks books/*
AllTopics *

Now you can run the sample programs to test publish/subscribe. You will need to set
the VM arguments and classpath for each program as you did with the point-to-point
programs.

1. Right-click ChatUI in the MQPubSub project, and select Run > Run.
2. Select Java Application in the Configurations: list.
3. Click New.
4. Click the Arguments tab.
5. In the VM arguments: text area, type the following arguments, each

separated by a space.
• -Djava.naming.factory.initial=com.ibm.mq.jms.context.WMQInitia
• -Djava.naming.provider.url=Ender
• -Dsun.boot.library.path=C:\RAD\eclipse\jre\bin;C:\WSMQ\Java\li
Other than the space between the arguments, there should be no other
spaces or carriage returns. Be sure to include the hyphen before each
argument. The arguments will wrap in the VM arguments: text area. This
is OK as long as you do not type spaces (other than the ones between
the arguments) or insert carriage returns.
6. Click the Classpath tab.
7. Click Bootstrap Entries in the Classpath: list.
8. Click Add External JARS.
9. Navigate to the MQTools folder and select the following JAR files:
• com.ibm.mq.pcf.jar
• mqcontext.jar
10. Click Open.
11. Click Add External JARS again.
12. Navigate to C:\WSMQ\Java\lib and select the following JAR files:

• com.ibm.mq.jar
• com.ibm.mqjms.jar
• connector.jar
• dhbcore.jar
• jms.jar

13. Click Open.
14. Click Run.
15. Type User1 in the User Name: field of the Chat window and press Enter
or click Set.
16. Type EnderTCF in the Connection: field and press Enter or click Set.
17. Type Java in the Topic: field and press Enter or click Set.
18. The message "User1 has entered the chat room" should display.
19. In Application Developer, from the main menu, select Run > Run
History>ChatUI.
20. In this second Chat window, type User2 in the User Name: field and
press Enter or click Set.
21. Type EnderTCF in the Connection: field and press Enter or click Set.
22. Type Java in the Topic: field and press Enter or click Set.
23. You will see the message "User2 has entered the chat room" in both chat
windows.
24. In the Message: field of either window, type any text and press Enter or
click Send. The message text displays in both windows, prepended with
the name of the user that published the message.
25. Try changing the topic in each of the windows to one of the other topics
created with JMSAdminGUI. Don't try AllComputers, AllBooks, or
AllTopics, however, because publishing is not allowed to wildcard (*)
topics, only subscribing.
26. Also, try running additional instances of ChatUI with different user
names.
27. Change the topic on one of the Chat windows to Java before proceeding
with the next steps.
28. Return to Application Developer.
29. From the main menu, select Run > Run.
30. Right-click ChatUI in the Configurations: list, and select Duplicate.

31. Rename ChatUI (1) to ChatMonitorUI.
32. Change the Main class field to

com.ibm.qbda.mq.pubsub.ChatMonitorUI.
33. Click Apply.
34. Click Run.
35. Type EnderTCF in the Connection: field of the chat monitor window and
36. Type AllComputers in the Topic: field and press Enter or click Set.
37. Switch to the chat window with the Java topic in use, ensuring that the
chat monitor window is visible and send a message.
38. The message text will display in the chat monitor window, prepended with
the topic to which the message was published and the user that published
the message.
39. Switch to the chat window with the Java topic in use, and type Linux in
the Topic: field, then press Enter or click Set.
40. Send a message from that chat window.
41. The message text will display in the chat monitor window.
42. In the chat window with the Linux topic in use, type Cyberpunk and
44. You will not see the message in the chat monitor window.
45. In the chat monitor window, type AllTopics and press Enter or click
Set.
46. Switch to the chat window with the Cyberpunk topic in use, and send a
message.
47. You will see the message in the chat monitor window.
48. When you are finished, close all chat and chat monitor windows by
clicking the X in the upper-right corner.

Section 8. Run the sample programs with the

WebSphere Test Environment
Now you can run the sample programs using the built-in JMS provider provided by
the WebSphere test environment included in Application Developer.
Install the sample code

As with the point-to-point programs, I have repackaged the pub/sub programs as
application clients in order to run using the WebSphere test environment.
1. In Application Developer, from the main menu, select File > Import.
2. Select Project Interchange as the import source and click Next.
3. In the From zip file: field, enter the location of the EMQPubSub.zip file
extracted previously.
4. Click Select All, and click Finish.
Create JMS Administered objects
1. Switch to the J2EE perspective in Application Developer.
2. In the Servers view, right-click WebSphere Application Server v6.0 and

select Start.
3. Wait for the status of the server to change to Started.
4. Right-click the server and select Run administrative console.
5. When the console appears, log in with any user ID.
6. Click Resources from the navigation bar to the left.
7. Click JMS Providers.

8. Click Default messaging.
9. Click JMS topic connection factory from the Connection Factories list.
10. Click New.
11. Type BeanTCF in the Name field.
12. Type jms/BeanTCF in the JNDI name field.
13. Select BeanBus from the Bus name drop-down.
14. Click OK.
15. Click Save at the top of the screen.
16. Click Save.
17. Click Default messaging from the navigation bar to the left.
18. Click JMS topic from the Destinations list.
19. Click New.
20. Type Java in the Name field.
21. Type jms/Java in the JNDI name field.
22. Type computers/Java in the Topic name field.
23. Select BeanBus from the Bus name drop-down.
24. Your screen should look like Figure 16.
Figure 16. Creating new JMS topic


25. Click OK.
26. Follow steps 19 through 25 to create additional topics, all using the
BeanBus bus, as shown in Table 2.
Table 2. Additional topics

Name JNDI name Topic
name
Linux jms/Linux computers/Linux
AllComputersjms/AllComputers
computers/*
Cyberpunk jms/Cyberpunk
books/cyberpunk
Poetry jms/Poetry books/poetry
AllBooks jms/AllBooks books/*
1. When you have created all of the topics, click Save at the top of the
screen.
2. Click Save.
3. Exit the admin console.
4. Right-click WebSphere Application Server v6.0 in the Servers view and

select Restart > Start.
1. Right-click EChat in the Project Explorer view and select Run > Run.
2. Select WebSphere v6.0 Application Client in the Configurations: list.
3. Right-click and select New.
4. Type EChat in the Name: field.
5. Click Apply, then click Run.
6. Type User1 in the User Name: field of the chat window and press Enter
or click Set.

7. Type jms/BeanTCF in the Connection: field and press Enter or click

Set.
8. Type jms/Java in the Topic: field and press Enter or click Set.
9. The message, "User1 has entered the chat room" will display.
10. In Application Developer, from the main menu, select Run > Run
History>EChat.
11. In this second chat window, type User2 in the User Name: field and
12. Type jms/BeanTCF in the Connection: field and press Enter or click
Set.
13. Type jms/Java in the Topic: field and press Enter or click Set.
14. You will see the message, "User2 has entered the chat room" display in
both chat windows.
15. In the Message: field of either window, type any text and press Enter or
click Send. The message text displays in both windows, prepended with
the name of the user that published the message.
16. Try changing the topic in each of the windows to one of the other topics
created with JMSAdminGUI. Don't try jms/AllComputers or jms/AllBooks,
however, because publishing is not allowed to wildcard (*) topics, only
subscribing.
17. Also, try running additional instances of EChat with different user names.
18. Change the topic on one of the chat windows to Java before proceeding
with the next steps.
19. Return to Application Developer.
20. From the main menu, select Run > Run.
21. Right-click EChat in the Configurations: list and select Duplicate.
22. Rename EChat (1) to EChatMonitor.
23. Change the Application client module: field to EChatMonitor.
24. Click Apply.

25. Click Run.
26. Type jms/BeanTCF in the Connection: field of the chat monitor window
and press Enter or click Set.
27. Type jms/AllComputers in the Topic: field and press Enter or click
Set.
28. Switch to the chat window with the jms/Java topic in use, ensuring that
the chat monitor window is visible and send a message.
29. The message text will display in the chat monitor window, prepended with
the topic to which the message was published and the user that published
the message.
30. Switch to the chat window with the jms/Java topic in use, and type
jms/Linux in the Topic: field. Next, press Enter or click Set.
32. The message text will display in the chat monitor window.
33. In the chat window with the jms/Linux topic in use, type jms/Cyberpunk
and press Enter or click Set.
35. You will not see the message in the chat monitor window.
36. When you are finished, close all chat and chat monitor windows by
clicking the X in the top-right corner.
37. Stop the server test environment before closing Application Developer.
Section 9. Summary
In this tutorial, you picked up where the preceding tutorial left off and explored some
additional topics in JMS programming, including WebSphere MQ client transport,
WebSphere MQ remote queuing, and JMS publish/subscribe programming.
In the next tutorial, you'll look at using WebSphere MQ as the JMS provider in

WebSphere Application Server. You will also explore JMS programming using the
unified domain interfaces provided in JMS 1.1.

Downloads
Description Name Size Download method
sample code i-mqrad2code.zip 47KB HTTP
Information about download methods

Resources
Learn
• In "Introducing the Java Message Service" (developerWorks, June 2004), learn
the basics for writing JMS applications.
• Learn more about Java Message Service at Sun's site.
• Visit the "WebSphere MQ Roadmap" to learn more about WebSphere MQ.
• Check out the "Rational Application Developer Roadmap."
• Learn more about remote queuing in the WebSphere MQ Intercommunication
manual.
• In "Deploying publish and subscribe applications into the Service Integration
Bus" (developerWorks, Aug 2005), learn how to configure IBM WebSphere
Application Server V6 to use the Service Integration Bus as its Java Message
Service (JMS) provider for publish/subscribe applications.
• "Developing a standalone Java application for WebSphere MQ"
(developerWorks, Feb 2005) shows how to develop an application that sends
and receives messages using WebSphere MQ that does not require being
deployed in a J2EE application server.
• In "Using WebSphere MQ with WebSphere Application Server Community
Edition" (developerWorks, Jan 2006), learn how to configure WebSphere
Application Server Community Edition to use WebSphere MQ as its JMS
provider.
• "Grouping messages using the WebSphere MQ Java and JMS APIs"
(developerWorks, Feb 2006) provides examples of WebSphere MQ's message
group support using JMS.
• Stay current with developerWorks technical events and webcasts.
Get products and technologies
• Download a free trial version of WebSphere MQ Version 6.0.
• Download a free trial version of Rational Application Developer Version 6.0.
• Download the SupportPac MS0N - GUI version of the existing JMS Admin tool.
This page also has download links to the other SupportPacs used in this
tutorial: ME01 - WebSphere MQ Initial Context Factory and MS0B - Java
classes for PCF.
• Download the newest version of SupportPac ME01 - WebSphere MQ Initial
Context Factory. This newest version is required to run the sample code in this
tutorial.

• Build your next development project with IBM trial software, available for
download directly from developerWorks.
Discuss
• Participate in the discussion forum for this content.
• Participate in developerWorks blogs and get involved in the developerWorks
community.
About the author

Willy Farrell
Willy Farrell is a Senior Software Engineer in the IBM Developer Skills Program. As
part of the developerWorks team, he provides relevant technical information and
insight to developers on the latest e-business and industry trends and technologies
through Web content, articles, speaking engagements, and consulting to faculty at
IBM Academic Initiative member universities. He has been programming computers
for a living since 1981, began using Java in 1996, and joined IBM in 1998. You can
reach Willy at willyf@us.ibm.com.


I Mqrad2 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

I Mqrad2 PDF

Uploaded by

Copyright:

Available Formats

Write Java Message Service programs using

WebSphere MQ Version 6 and Rational

Willy Farrell (willyf@us.ibm.com)

Section 1. Before you start

About this tutorial

WebSphere MQ configurations and publish/subscribe

• Configure and test WebSphere MQ client transport

WebSphere MQ configurations and publish/subscribe

A note about SupportPac ME01

Section 3. WebSphere MQ configurations

Enhancing capabilities of the sample code

WebSphere MQ configurations and publish/subscribe

Section 4. WebSphere MQ client transport

Create the server-connection channel

1. Launch WebSphere MQ Explorer from the Start menu. (From here

2. Click the + sign next to Ender.

3. Click the + sign next to Advanced.

4. Right-click on Channels and select New > Server-connection Channel.

Figure 1. Creating new server-connection channel

WebSphere MQ configurations and publish/subscribe

5. Type java.channel in the Name: field, and click Finish.

Create JMS administered object

2. Use C:\workspace as your workspace directory.

Figure 2. Perspective switch button

WebSphere MQ configurations and publish/subscribe

5. Select the Open a recent config profile: button. Next, select

Figure 3. Select config profile

7. From the main menu, select Object > New>

8. Type ClientEnder in the Object Name: field.

9. Click Standard properties tab.

10. Select Client from the Transport: drop-down.

11. Type Ender in the Queue Manager: field.

12. Type 1414 in the Port: field.

13. Type java.channel in the Channel: field.

WebSphere MQ configurations and publish/subscribe

Figure 4. Creating new MQQueueConnectionFactory

15. Click OK.

16. Exit JMSAdminGUI.

Run the sample programs

2. Type ClientEnder in the Connection: field and press Enter or click

WebSphere MQ configurations and publish/subscribe

5. Type ClientEnder in the Connection: field and press press Enter or

9. The message text should appear in the Queue Receiver window.

Section 5. Remote queuing

WebSphere MQ configurations and publish/subscribe

Local definition of a remote queue

1. In WebSphere MQ Explorer, right-click on Queue Managers and select

2. Type Petra in the Queue manager name: field.

3. Type SYSTEM.DEAD.LETTER.QUEUE in the Dead letter queue: field.

4. Click Next three times.

7. Click the + sign next to Petra.

Figure 5. Creating new queue

9. Type PetraQ in the Name: field. Click Finish.

WebSphere MQ configurations and publish/subscribe

4. Select Transmission from the Usage: drop-down. (See Figure 6.)

Figure 6. Configuring queue for transmission usage

7. Type RemotePetraQ in the Name: field.

WebSphere MQ configurations and publish/subscribe

9. Type PetraQ in the Remote queue: field.

10. Type Petra in the Remote queue manager: field.

Figure 7. Configuring remote queue

12. Click Finish.