Contents


Write Java Message Service programs using WebSphere MQ Version 6 and Rational Application Developer Version 6, Part 2

WebSphere MQ configurations and publish/subscribe

Comments

Content series:

This content is part # of # in the series: Write Java Message Service programs using WebSphere MQ Version 6 and Rational Application Developer Version 6, Part 2

Stay tuned for additional content in this series.

This content is part of the series:Write Java Message Service programs using WebSphere MQ Version 6 and Rational Application Developer Version 6, Part 2

Stay tuned for additional content in this series.

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.

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:

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 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 Related topics 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.

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.

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
    Creating new server-connection channel
    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
    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
    Select config profile
    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
    Creating new MQQueueConnectionFactory
    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.

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
    Creating new queue
    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
    Configuring queue for transmission usage
    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
    Configuring remote queue
    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
    Creating receiver channel
    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
    Sender channel properties
    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
    Starting sender channel

Run the sample programs

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
    QReceiverUI arguments
    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
Client access and remote queuing combined
Client access and remote queuing combined

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.

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
    Preparing WebSphere MQ message broker
    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 Downloadable resources 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();
   } catch (Throwable e) {
      publisher = null;
      subscriber = null;
      setExceptionMessage(e);
      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);
   } catch (Throwable e) {
      setExceptionMessage(e);
      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();
   } catch (Throwable e) {
      setExceptionMessage(e);
      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());
   } catch (Throwable e) {
      setExceptionMessage(e);
      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
    Creating new MQTopicConnectionFactory
    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
    Creating new MQTopicConnectionFactory
    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:
Linuxcomputers/Linux
AllComputerscomputers/*
Cyberpunkbooks/cyberpunk
Poetrybooks/poetry
AllBooksbooks/*
AllTopics*

Run the sample programs

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.WMQInitialContextFactory
    • -Djava.naming.provider.url=Ender
    • -Dsun.boot.library.path=C:\RAD\eclipse\jre\bin;C:\WSMQ\Java\lib
    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 press Enter or click Set.
  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 press Enter or click Set.
  43. Send a message from that chat window.
  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.

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
    Creating new JMS topic
    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
NameJNDI nameTopic name
Linuxjms/Linuxcomputers/Linux
AllComputersjms/AllComputerscomputers/*
Cyberpunkjms/Cyberpunkbooks/cyberpunk
Poetryjms/Poetrybooks/poetry
AllBooksjms/AllBooksbooks/*
  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.

Run the sample programs

  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 press Enter or click Set.
  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.
  31. Send a message from that chat window.
  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.
  34. Send a message from that chat window.
  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.

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.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps, Middleware
ArticleID=128400
ArticleTitle=Write Java Message Service programs using WebSphere MQ Version 6 and Rational Application Developer Version 6, Part 2: WebSphere MQ configurations and publish/subscribe
publish-date=06132006