JMS API

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

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
chapter 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.

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:

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.

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.

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.

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.

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.

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.

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.

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

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 www.packtpub.com 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 chapter 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 using the instructions in Chapter 2 as a guide. 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.

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.

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.

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.

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
http://www.packtpub.com. To launch the deployed application, you can use the
following URL:

http://<host_name>:9080/JMSTester/.

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.

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.

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.

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.

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

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.

Comments

comments