Messaging with WebSphere Application Server 7.0 (Part 1)

Messaging in a large enterprise is common and a WebSphere administrator needs to understand what WebSphere Application Server can do for Java Messaging and/or WebSphere Message Queuing (WMQ) based messaging. Here, we will learn how to create Queue Connection Factories (QCF) and Queue Destinations (QD) which we will use in a demonstration application where we will demonstrate the Java Message Service (JMS) and also show how WMQ can be used as part of a messaging implementation.

In this two-part article by Steven Charles Robinson, we will cover the following topics:

  • Java messaging
  • Java Messaging Service (JMS)
  • WebSphere messaging
  • Service integration bus (SIB)
  • WebSphere MQ
  • Message providers
  • Queue connection factories
  • Queue destinations

Java messaging

Messaging is a method of communication between software components or applications. A messaging system is often peer-to-peer, meaning that a messaging client can send messages to, and receive messages from, any other client. Each client connects to a messaging service that provides a system for creating, sending, receiving, and reading messages. So why do we have Java messaging? Messaging enables distributed communication that is loosely-coupled. What this means is that a client sends a message to a destination, and the recipient can retrieve the message from the destination. A key point of Java messaging is that the sender and the receiver do not have to be available at the same time in order to communicate. The term communication can be understood as an exchange of messages between software components. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only what message format and what destination to use. Messaging also differs from electronic mail (email), which is a method of communication between people or between software applications and people. Messaging is used for communication between software applications or software components. Java messaging attempts to relax tightly-coupled communication (such as, TCP network sockets, CORBA, or RMI), allowing software components to communicate indirectly with each other.

Java Message Service

Java Message Service (JMS) is an application program interface (API) from Sun. JMS provides a common interface to standard messaging protocols and also to special messaging services in support of Java programs. Messages can involve the exchange of crucial data between systems and contain information such as event notification and service requests. Messaging is often used to coordinate programs in dissimilar systems or written in different programming languages. By using the JMS interface, a programmer can invoke the messaging services like IBM's WebSphere MQ (WMQ) formerly known as MQSeries, and other popular messaging products. In addition, JMS supports messages that contain serialized Java objects and messages that contain XML-based data.

A JMS application is made up of the following parts, as shown in the following diagram:

  • A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features.
  • JMS clients are the programs or components, written in the Java programming language, that produce and consume messages.
  • Messages are the objects that communicate information between JMS clients.
  • Administered objects are preconfigured JMS objects created by an administrator for the use of clients. The two kinds of objects are destinations and Connection Factories (CF).

    WebSphere Application Server

As shown in the diagram above, administrative tools allow you to create destinations and connection factories resources and bind them into a Java Naming and Directory Interface (JNDI) API namespace. A JMS client can then look up the administered objects in the namespace and establish a logical connection to the same objects through the JMS provider.

JMS features

Application clients, Enterprise Java Beans (EJB), and Web components can send or synchronously receive JMS messages. Application clients can, in addition, receive JMS messages asynchronously. A special kind of enterprise bean, the message-driven bean, enables the asynchronous consumption of messages. A JMS message can also participate in distributed transactions.

JMS concepts

The JMS API supports two models:

Point-to-point or queuing model

As shown below, in the point-to-point or queueing model, the sender posts messages to a particular queue and a receiver reads messages from the queue. Here, the sender knows the destination of the message and posts the message directly to the receiver's queue. Only one consumer gets the message. The producer does not have to be running at the time the consumer consumes the message, nor does the consumer need to be running at the time the message is sent. Every message successfully processed is acknowledged by the consumer. Multiple queue senders and queue receivers can be associated with a single queue, but an individual message can be delivered to only one queue receiver. If multiple queue receivers are listening for messages on a queue, Java Message Service determines which one will receive the next message on a first-come-first-serve basis. If no queue receivers are listening on the queue, messages remain in the queue until a queue receiver attaches to the queue.

WebSphere Application Server

Publish and subscribe model

As shown by the above diagram, the publish/subscribe model supports publishing messages to a particular message topic. Unlike the point-to-point messaging model, the publish/subscribe messaging model allows multiple topic subscribers to receive the same message. JMS retains the message until all topic subscribers have received it. The Publish & Subscribe messaging model supports durable subscribers, allowing you to assign a name to a topic subscriber and associate it with a user or application. Subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber knows about each other.

WebSphere Application Server

By using Java, JMS provides a way of separating the application from the transport layer of providing data. The same Java classes can be used to communicate with different JMS providers by using the JNDI information for the desired provider. The classes first use a connection factory to connect to the queue or topic, and then populate and send or publish the messages. On the receiving side, the clients then receive or subscribe to the messages.


The JMS API is provided in the Java package javax.jms. Below are the main interfaces provided in the javax.jms package:

ConnectionFactory interface


A WebSphere configured resource object that a client uses to create a connection to the JMS provider. JMS clients access the connection factory through interfaces so the code does not need to be changed if the underlying JMS implementation changes. Administrators configure the connection factory's which have JNDI names so that JMS clients can look them up. These resources in WebSphere these are known as JMS Resource references.


Connection interface


Once a connection factory is obtained, a connection to a JMS provider can be created. A connection represents a communication link between the application and the messaging system. Depending on the connection type, connections allow users to create sessions for sending and receiving messages from a queue or topic.


Destination interface


A WebSphere configured resource object that serves as the identity of a message destination, which is where messages are delivered and consumed. It is either a queue or a topic. The WebSphere administrator creates these resource references, and client applications discover them using JNDI.


MessageConsumer interface


A Java object created by a session. It receives messages sent from a destination. The consumer can receive messages synchronously or asynchronously for both queue and topic-type messaging.


MessageProducer interface


A Java object created by a session that sends messages to a destination. The user can create a sender to a specific destination or create a generic sender that specifies the destination at the time the message is sent.

Messaging applications use the above listed interfaces in the Java code to implement JMS. The demo JMS Test Tool application contains code which you can look into to see how the above interfaces are used. We will cover the JMS Test Tool later in the article when we demonstrate how to deploy an application which uses messaging.

WebSphere messaging

WebSphere Application Server implements two main messaging sub-systems. The default-messaging-provider is internal to WebSphere and the WebSphere MQ messaging provider which uses WebSphere MQ. First, we will cover the default messaging provider which is implemented by using a SIB. Then, we will move onto the WebSphere MQ messaging provider. To demonstrate use of the SIB and the default Messaging provider, we will deploy an application which will use JMS via the SIB. Before we deploy the application, we will need to set up the JMS resources required for the application to implement Java messaging using the Java Message Service (JMS).

Default JMS provider

WebSphere Application Server comes with a default JMS provider as part of its installation and supports messaging through the use of the JMS. The default JMS provider allows applications deployed to WAS to perform asynchronous messaging without the need to install a third-party JMS provider. This is a very useful feature which runs as part of the WebSphere Application Server. The default JMS provider is utilized via the SIB and you can use the Administrative console to configure the SIB and JMS resources.

Enterprise applications use JMS CF to connect to a service integration bus. Applications use queues within the SIB to send and receive messages. An application sends messages to a specific queue and those messages are retrieved and processed by another application listening to that queue. In WebSphere, JMS queues are assigned to queue destinations on a given SIB. A queue destination is where messages can be persisted over time within the SIB. Applications can also use topics for messages. Applications publish messages to the topics. To receive messages, applications subscribe to topics. JMS topics are assigned to topic spaces on the bus. The JMS topics are persisted in the SIB and accessed via appropriate connection factories which applications use to gain access to the bus.

The following table gives a quick overview of the types of resource available for configuring JMS resources for the Default JMS provider running in the SIB.

JMS Resource Type


JMS Provider

A JMS provider enables messaging based on the Java Messaging Service (JMS). It provides J2EE connection factories to create connections for JMS destinations.

JMS activation specification

A JMS activation specification is associated with one or more message-driven beans and provides the configuration necessary for them to receive messages and is specific to SIB implementation.

JMS connection factory

A JMS connection factory is used to create connections to the associated JMS provider of JMS destinations, for both point-to-point and publish/subscribe messaging.

JMS queue connection factory

A JMS queue connection factory is used to create connections to the associated JMS provider of JMS queues, for point-to-point messaging.

JMS queue

A JMS queue is used as a destination for point-to-point messaging.

JMS topic connection factory

A JMS topic connection factory is used to create connections to the associated JMS provider of JMS topics, for publish/subscribe messaging.

JMS topic

A JMS topic is used as a destination for publish/subscribe messaging.

WebSphere SIB

Before our applications can be installed and set up to use the default messaging provider, we must create a service integration bus. In a way, the SIB provides the backbone for JMS messaging when you are using the default provider. The default provider is internal to WebSphere Application Server and no third-party software is required utilize it.

A service integration bus supports applications using message-based and service-oriented architectures. A bus is a group of interconnected servers and clusters that have been added as members of the bus. Applications connect to a bus at one of the messaging engines associated with its bus members.

Creating a SIB

To create a Service Integration Bus (SIB), log into the admin console and navigate to the Service integration section within the lefthand side panel and click on Buses, as shown in the following screenshot:

WebSphere Application Server

Click New to enter the Create a new Service Integration Bus page where we will begin our SIB creation. Type InternalJMS in the Enter the name of your new bus field and uncheck the Bus security checkbox as shown below and then click Next.

WebSphere Application Server

On the next screen, you will be prompted to confirm your SIB settings. Click Finish to complete the creation of the SIB. Once the wizard has completed, click Save to retain your configuration change. You will be returned to a screen which lists the available SIBs installed in your WebSphere configuration. Now that the SIB has been created, you can click on the SIB name to configure settings and operation of the SIB. We will not be covering managing a SIB in this book as it is beyond our scope. All we need to do is create a SIB so we can demonstrate an application using the default JMS provider which requires a SIB to operate.

To complete the configuration, we must add an existing server as a member to the SIB so that we have a facility for message persistence. The SIB is just a service integration bus, almost like a connecting conduit, however we need and actual members, which in our case will be our application server called server1, which contain the actual implementation for the message store.

To add a server as a bus member, click on the bus name called InternalJMS in the SIB list and then navigate to the Topology section and click Bus members as shown below.

WebSphere Application Server

You will now be presented with a screen where you can add bus members. Click Add and you will be able to select the server you wish to add as a member to the bus. You will notice that the server is already pre-selected as shown below.

WebSphere Application Server

Click Next to the final screen, where you will select the File store option from the option group field labeled Choose type of message store for the persistence of message state. Click Next to view the next configuration page where we will use the page defaults. Click Next to enter the Tune performance parameters page where we will also use the defaults. Clicking Next again will take you to the final summary page where you will click Finish to finalize adding the application server as a bus member. Click Save to retain the changes. You will now see the application server called server1 listed as a bus member. Now we can move on to configure the JMS resources.

Configuring JMS

Once we have created a SIB, we can configure JMS resources. The types of resources we need to create depend entirely upon the application you are deploying. In our demo JMS application, we are going to demonstrate putting a message on a queue using a sending Servlet which places messages on a queue, known as the sender, and then demonstrate receiving a message on the receiving Servlet, known as the receiver. This exercise will give you a detailed enough overview of a simple implementation of JMS. To continue, we will need to set up a queue connection factory which the application will use to connect to a message queue and an actual queue which the application will send messages to and receive messages from.

Creating queue connection factories

To create a queue connection factory, navigate to the Resources section of the left-hand-side panel in the Administrative console and click Queue connection factories from the JMS category as shown below.

WebSphere Application Server

Select a scope of cell from the cell-scope pick-list and then click New to create a new QCF. In the Select JMS resource provider screen as shown below, select Default messaging provider from the available provider options and click OK.

WebSphere Application Server

On the next page, you will be asked to fill in configuration settings for the QCF. We will only need to fill in a few fields. As shown below, type QCF.Test in the Name field, jms/QCF.Test in the JNDI name field and select the bus called InternalJMS from the Bus name field.

WebSphere Application Server

Click Apply and then Save when prompted to do so in order to retain the changes. You will now see the QCF listed in the list of configured QCF.

Creating queue destinations

To create a queue, we will follow a similar process to creating a QCF. Select Queues from the JMS category located in the Resources section found in the left-hand-side panel of the Admin console.

Select Default messaging provider from the list of messaging providers and then click on OK to enter the queue configuration page.

On the queue configuration page, enter Q.Test in the Name field and jms/Q.Test in the JNDI name field.

Select InternalJMS from the Bus name field found in the Connection section and select Create Service Bus destination from the Queue name field and click Apply. You will then be prompted to create a queue destination.

In the Create a new queue for point-to-point messaging screen, type QD.Test in the identifier field and click Next.

In the following screen of the wizard labelled Assign the queue to a bus member, you will see that server1 sis already pre-selected in the field called Bus member. The bus mentioned in the Bus member field is where the actual queue destination will be created Clicking Next will present you with the final step, a summary screen where you can click Finish and then Save to retain your queue configuration.

To view your queue destination, you need to select the bus called InternalJMS from the list of buses found by navigating to the Service integration section of the left-hand-side panel from the Admin console and then click Buses. You will recognize this screen as the main bus configuration page we used when we created the SIB. Click the Destinations link located in the Destination resources section shown in the Destinations page as shown in the screenshot below.

WebSphere Application Server

You will then be presented with a list of queue destinations in the SIB.

WebSphere Application Server

To create Topics Connection Factories (TCF) and Topic Destinations (TD) for publish/subscribe messaging, you can follow a similar process. Publish/subscribe messaging will not be demonstrated in this book; however, you can use the process defined for creating QCF and QD as an example of how to create TCF and TD.

Installing the JMS demo application

To demonstrate the use of QCF and QD in the SIB, we will manually deploy an EAR file which contains two servlets that can be used to test JMS configurations.

The JMS Test Tool application is a web application which provides a controller Servlet, which will process requests from an input page, which allows a user to put a simple message on a queue then get the message. The application is not industrial strength; however, it goes a long way to demonstrating the basics of JMS. The application can be downloaded from and it also contains all the source code, so you can look into the mechanics of simple JMS programming. We will not explain the code in this article as it detracts from administration; however, feel free to change the code and experiment in your learning of JMS.

After you have downloaded the JMSTester.ear file to your local machine, use the Admin console to deploy it. We will take you through some screens to ensure you correctly configure the appropriate resources as part of the installation.

When you start the installation (deployment) of the EAR file, ensure you select the option called Detailed from the How do you want to install the application? section on the Preparing for the application installation screen as shown below to expose the configuration steps required by the EAR file, otherwise you will be given the default JMS configuration and you might not understand how JMS has been configured in the application. Another good reason for selecting the Detailed option is that the wizard will present extra screens which will allow you to optionally override the JNDI mappings for resource references.

WebSphere Application Server

On the Install New Application screen, change the application name to JMS Test Tool, and then keep clicking Next until you come to Step 6, the Bind message destination references to administered objects page. When you get to this page, type jms/Q.Test in the Target Resource JNDI Name field, which means you want to bind the application's internal resource reference called jms/Queue to the WebSphere configured JMS queue destination called jms/Q.Test (which we created earlier) as shown below.

WebSphere Application Server

Using this level of JNDI abstraction means that the application does not need to know the actual JMS implementation technology, which in this case happens to be the internal WebSphere Default JMS provider. Click Next to proceed to the next step of the wizard. The next screen of the wizard will be the Map resource references to resources screen where you will be given the option of binding the applications JNDI resource declarations to the actual JNDI implementation as configured in WebSphere. In the image below you can see that the application has been configured to point to a QCF called jms/QCF, however in our configuration of WebSphere we have called our connection factory jms/QCF.Test. Type jms/QCF.Test into the Target Resource JNDI Name field.

WebSphere Application Server

This concept of abstraction which WebSphere offers to J2EE applications which utilize indirect JNDI naming is a very powerful and very important part of configuring enterprise applications. Using indirect JNDI allows for the decoupling of the application from the application server actual implementation of JMS. The application is then pointed to the JNDI which it will use to look up the actual resource reference that has been configured in WebSphere. So, in simple words, the administrator decides what messaging sub-system the application will be using and is transparent to the application.

We have now completed the configuration elements that require user intervention, so we can keep clicking Next until the application wizard is complete. If you get any warning as shown below, you can ignore it; the warnings come up due to WebSphere telling you that you have configured the QCF and queue destinations at cell level, and that other applications could be referencing them as well. Just click Continue to move on to the next steps.

WebSphere Application Server

When you come to the Context root page, take note that the EAR file has been configured to use JMSTester as the web applications context root. We will leave this as defaulted for our demonstration; however, you could override it by typing in another context root. When you get to the Summary page of the wizard, click on Finish and Save to retain the applications deployment.

JMS Test Tool application

The JMS Test Tool application provides a simple test harness to send and receive messages to and from queues. The application can be downloaded from To launch the deployed application, you can use the following URL:


If the application is deployed and has started error-free, you will be presented with the JMS Test Tool interface, which is a set of three HTML frames, as shown below.

WebSphere Application Server

The main frame is the top-most frame where you enter a test message as shown below. The left-hand-side bottom frame provides help on how to use the tool, and the right-hand-side frame will show the results of a send or get message action.

WebSphere Application Server

If you click Put Message, you will see that the left-hand-side bottom frame displays the status of the message being sent as shown below. Each time you click Put Message, a new message will be put on the queue.

WebSphere Application Server

If you click Get Message, you will see that the left-hand-side bottom frame displays the contents of a given message retrieved from the queue as shown below.

WebSphere Application Server

Each time you click Get Message, the next message will be read from the queue until there are no more messages.

WebSphere Application Server

You can use this application to test both JMS and local MQ queue managers. This concludes our overview of using JMS and the default messaging provider.

In the next part we will cover:

  • WebSphere MQ
  • Message providers
  • Queue connection factories
  • Queue destinations

>> Continue Reading: Messaging with WebSphere Application Server 7.0 (Part 2)


If you have read this article you may be interested to view :

You've been reading an excerpt of:

WebSphere Application Server 7.0 Administration Guide

Explore Title