WebSphere Messaging

WebSphere Application Server 7.0 Administration Guide

As a J2EE (Enterprise Edition) administrator, you require a secure, scalable, and resilient infrastructure to support and manage your J2EE applications and service-oriented architecture services.

The WebSphere suite of products from IBM provides many different industry solutions and WebSphere Application Server is the core of the WebSphere product range from IBM.

WebSphere is optimized to ease administration and improve runtime performance. It runs your applications and services in a reliable, secure, and high-performance environment to ensure that your core business opportunities are not lost due to application or infrastructure downtime.

Whether you are experienced or new to WebSphere, this book will provide you with a cross-section of WebSphere Application Server features and how to configure these features for optimal use. This book will provide you with the knowledge to build and manage performance-based J2EE applications and service-oriented architecture (SOA) services, offering the highest level of reliability, security, and scalability.

Taking you through by examples, you will be shown the different methods for installing
WebSphere Application Server and will be shown how to configure and prepare WebSphere resources for your application deployments. The facets of data-aware and message-aware applications are explained and demonstrated, giving the reader real-world examples of manual and automated deployments.

WebSphere security is covered in detail showing the various methods of implementing federated user and group repositories. Key administration features and tools are introduced, which will help WebSphere administrators manage and tune their WebSphere implementation and applications. You will also be shown how to administer your WebSphere server standalone or use the new administrative agent, which provides the ability to administer multiple installations of WebSphere Application Server using one single administration console.

also read:

What This Book Covers

Chapter 1, Installing WebSphere Application Server covers how to plan and prepare your WebSphere installation and shows how to manually install WebSphere using the graphical installer and how to use a response file for automated silent installation. The fundamentals of application server profiles are described and the administrative console is introduced.
Chapter 2, Deploying your Applications explains the make-up of Enterprise Archive (EAR) files, how to manually deploy applications, and how Java Naming and Directory Interface (JNDI) is used in the configuration of resources. Connecting to databases is explained via the configuration of Java database connectivity (JDBC) drivers and data sources used in the deployment of a data-aware application.
Chapter 3, Security demonstrates the implementation of global security and how to federate lightweight directory access protocol (LDAP) and file-based registries for managing WebSphere security. Roles are explained where users and groups can be assigned different administrative capabilities.
Chapter 4, Administrative Scripting introduces ws_ant, a utility for using apache Ant
build scripts to deploy and configure applications. Advanced administrative scripting is demonstrated by using the wsadmin tool with Jython scripts, covering how WebSphere deployment and configuration can be automated using the extensive WebSphere Jython scripting objects.
Chapter 5, WebSphere Configuration explains the WebSphere installation structure and key XML files, which make up the underlying WebSphere configuration repository. WebSphere logging is covered showing the types of log and log settings that are vital for administration. Application Server JVM settings and class loading are explained.
Chapter 6, WebSphere Messaging explains basic Java message service (JMS) messaging concepts and demonstrates both JMS messaging using the default messaging provider and WebSphere Message Queuing (MQ) along with explanations of message types. Use of Queue Connection Factories, Queues, and Queue Destinations are demonstrated via a sample application.
Chapter 7, Monitoring and Tuning shows how to use TivoliPerformance Monitor, request metrics, and JVM tuning settings to help you improve WebSphere performance and monitor the running state of your deployed applications.
Chapter 8, Administrative Features covers how to enable the administrative agent for
administering multiple application servers with a central administrative console. IBM HTTP Server and the WebSphere plug-in are explained.
Chapter 9, Administration Tools demonstrates some of the shell-script-based utilities vital to the WebSphere administrator for debugging and problem resolution.
Chapter 10, Product Maintenance shows how to maintain your WebSphere Application Server by keeping it up-to-date with the latest fix packs and feature packs.

WebSphere Messaging

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


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.

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.

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.

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.

WebSphere MQ overview

WebSphere MQ formerly known as MQ Series is IBM’s enterprise messaging solution. In a nutshell, MQ provides the mechanisms for messaging both in point-to-point and publish-subscribe. However, it guarantees to deliver a message only once. This is important for critical business applications which implement messaging. An example of a critical system could be a banking payments system where messages contain messages pertaining to money transfer between banking systems, so guaranteeing delivery of a debit/credit is paramount in this context. Aside from guaranteed delivery, WMQ is often used for messaging between dissimilar systems and the WMQ software provides programming interfaces in most of the common languages, such as Java, C, C++, and so on. If you are using WebSphere, then it is common to find that WMQ is often used with WebSphere when WebSphere is hosting message-enabled applications. It is important that the WebSphere administrator understands how to configure WebSphere resources so that application can be coupled to the MQ queues.

Overview of WebSphere MQ example

To demonstrate messaging using WebSphere MQ, we are going to re-configure the previously deployed JMS Tester application so that it will use a connection factory which communicates with a queue on a WMQ queue manager as opposed to using the default provider which we demonstrated earlier.

Installing WebSphere MQ

Before we can install our demo messaging application, we will need to download and install WebSphere MQ 7.0. A free 90-day trial can be found at the following URL:


http://www.ibm.com/developerworks/downloads/ws/wmq/.

Click the download link as shown below.

Similar to Chapter 1, you will be prompted to register as an IBM website user before you can download the WebSphere MQ Trial. Once you have registered and logged in, the download link above will take you to a page which lists download for different operating systems.
Select WebSphere MQ 7.0 90-day trial from the list of available options as
shown below.

Click continue to go to the download page. You may be asked to fill out a questionnaire detailing why you are evaluating WebSphere MQ (WMQ). Fill out the question as you see fit and submit to move to the download page.

As shown above, make sure you use the IBM HTTP Download director as it will
ensure that your download will resume, even if your Internet loses a connection.

	If you do not have a high-speed Internet connection, you can try
	downloading a free 90-day trial of WebSphere MQ 7.0 overnight
	while you are asleep.


Download the trial to a temp folder, for example c:\temp, on your local machine. The screenshot above shows how the IBM HTTP Downloader will prompt for a location where you want to download it to. Once the WMQ install file has been downloaded, you can then upload the file using an appropriate secure copy utility like Winscp to an appropriate folder like /apps/wmq_install on your Linux machine. Once you have the file uploaded to Linux, you can then decompress the file and run the installer to install WebSphere MQ.

Running the WMQ installer

Now that you have uploaded the WMQv700Trial-x86_linux.tar file on your Linux machine, and follow these steps:

  1. You can decompress the file using the following command:
    gunzip ./WMQv700Trial-x86_linux.tar.gz
  2. Then run the un-tar command:
    tar -xvf ./ WMQv700Trial-x86_linux.tar
  3. Before we can run the WMQ installations, we need to accept the license agreement by running the following command:
    ./mqlicense.sh –accept
  4. To run the WebSphere MQ installation, type the following commands:
    rpm -ivh MQSeriesRuntime-7.0.0-0.i386.rpm
    rpm -ivh MQSeriesServer-7.0.0-0.i386.rpm
    rpm -ivh MQSeriesSamples-7.0.0-0.i386.rpm
  5. As a result of running the MQSeriesServer installation, a new user called mqm was created. Before running any WMQ command, we need to switch to this user using the following command:
    su – mqm
  6. Then, we can run commands like the dspmqver command which can be run to check that WMQ was installed correctly. To check whether WMQ is installed, run the following command:
    /opt/mqm/bin/dspmqver

The result will be the following message as shown in the screenshot below:

Creating a queue manager

Before we can complete our WebSphere configuration, we need to create a WMQ queue manager and a queue, then we will use some MQ command line tools to put a test message on an MQ queue and get a message from an MQ queue.

  1. To create a new queue manager called TSTDADQ1, use the following command:
    crtmqm TSTDADQ1
  2. The result will be as shown in the image below.
  3. We can now type the following command to list queue managers:
    dspmq
  4. The result of running the dspmq command is shown in the image below.
  5. To start the queue manager (QM), type the following command:
    strmqm
  6. The result of starting the QM will be similar to the image below.
  7. Now that we have successfully created a QM, we now need to add a queue called LQ.Test where we can put and get messages.
  8. To create a local queue on the TSTDADQ1 QM, type the following commands in order:
    runmqsc TSTDADQ1
  9. You are now running the MQ scripting command line, where you can issue MQ commands to configure the QM.
  10. To create the queue, type the following command and hit Enter:
    define qlocal(LQ.TEST)
  11. Then immediately type the following command:
    end
  12. Hit Enter to complete the QM configuration, as shown by the following screenshot.


You can use the following command to see if your LQ.TEST queue exists.

 
echo "dis QLOCAL(*)" | runmqsc TSTDADQ1 | grep -i test

You have now added a local queue called Q.Test to the TSTDADQ1 queue manager.

 
runmqsc TSTDADQ1
DEFINE LISTENER(TSTDADQ1.listener) TRPTYPE (TCP) PORT(1414)
START LISTENER(TSTDADQ1.listener)
End


You can type the following command to ensure that your QM listener is running.

ps -ef | grep mqlsr

The result will be similar to the image below.

To create a default channel, you can run the following command.

 
runmqsc TSTDADQ1
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
End


We can now use a sample MQ program called amqsput which we can use to put and get a test message from a queue to ensure that our MQ configuration is working before we continue to configure WebSphere.

Type the following command to put a test message on the LQ.Test queue:

/opt/mqm/samp/bin/amqsput LQ.TEST TSTDADQ1

Then you can type a test message: Test Message and hit Enter; this will put a message on the LQ.Test queue and will exit you from the AMQSPUTQ command tool.

Now that we have put a message on the queue, we can read the message by using the MQ Sample command tool called amqsget. Type the following command to get the message you posted earlier:

/opt/mqm/samp/bin/amqsget LQ.TEST TSTDADQ1

The result will be that all messages on the LQ.TEST queue will be listed and then the tool will timeout after a few seconds as shown below.

We need to do two final steps to complete and that is to add the root user to the mqm group. This is not a standard practice in an enterprise, but we have to do this because our WebSphere installation is running as root. If we did not do this, we would have to reconfigure the user which the WebSphere process is running under and then add the new user to MQ security. To keep things simple, ensure that root is a member of the mqm group, by typing the following command:

usermod -a -G mqm root

We also need to change WMQ security to ensure that all users of the mqm group have access to all the objects of the TSTDADQ1 queue manager. To change WMQ security to give access to all objects in the QM, type the following command:

setmqaut -m TSTDADQ1 -t qmgr -g mqm +all

Now, we are ready to re-continue our configuring WebSphere and create the appropriate QCF and queue destinations to access WMQ from WebSphere.

Creating a WMQ connection factory

Creating a WMQ connection factory is very similar to creating a JMS QCF. However, there are a few differences which will be explained in the following steps. To create a WMQ QCF, log in to the Admin console and navigate to the JMS category of the Resources section found in the left-hand-side panel of the Admin console and click on Queue connection factories. Select the Cell scope and click on New. You will be presented with an option to select a message provider. Select WebSphere MQ messaging provider as shown below and click OK.

You will then be presented with a wizard which will first ask you for the name of the QCF. Type QCF.LQTest in the Name field and type jms/QCF.LQTest in the JNDI
name
field, as shown below.

Click on Next to progress to the next step of the wizard, where you will decide on how to connect to WMQ. As shown in the following screenshot, select the Enter all the required information into this wizard option and then click on Next.

In the Supply queue connection details screen, you will need to type TSTDADQ1 into the Queue manager or queue sharing group name field and click on Next.

On the next screen of the wizard, you will be asked to fill in some connection details.
Ensure that the Transport field is set to Bindings then client. Type localhost in the hostname field and then add the value 1414 to the Port field, and type SYSTEM. ADMIN.SVRCONN into the Server connection channel field as shown below and then click on Next to move on to the next step of the wizard.

On the next page, you will be presented with a button to test your connection to WMQ. If you have set up WMQ correctly, then you will be able to connect and a results page will be displayed confirming a successful connection to WMQ. If you cannot connect at this stage, then you will need to check your MQ setup. Most often it is security that is the problem. If you find you have an issue with security, you can search Google for answers on how to change WMQ security. Once your test is successful, click on Next to move on to the final Summary page which will list your QCF configuration. On the final page of the wizard, click Finish to complete the WMQ QCF configuration and click Save to retain your changes. You will now see two QCF configurations, one for JMS and one for WMQ, as shown below:

Creating a WMQ queue destination

The next step after creating a QCF is to create a queue destination. We will use the queue named LQ.Test which we created on the TSTDADQ1 queue manager. To create a new queue, navigate to the JMS category of the Resources section in the left-hand-side panel of the admin console and click Queues. Click on New to start the queue creation wizard. In the provider selector screen, select WebSphere MQ messaging provider and click on Next. You will then be presented with a page that allows you to specify settings for the queue. In the Name field, type LQ.Test and then type jms/LQ.Test in the JNDI name field. In the Queue name field, type LQ.TEST which is the actual name for the underlying queue, as shown below.

	Useful tip: Optionally, you can type the Queue Manager name,
	for example, TSTDADQ1 into the Queue manager or queue
	sharing group name field, but if you ever use WMQ clustering,
	it is not required and will stop MQ clustering from working correctly.


Click on Apply to submit the changes, and then click on Save to retain the changes to the WebSphere configuration repository. You will then be presented with a list of queues as shown below:

We have now configured a WebSphere MQ queue connection factory and a WebSphere MQ queue destination which our test application will use to send and receive messages from WMQ.

Reconfiguring the JMS demo application

Now that we have created a QCF and queue destination using WMQ as the message provider, we will need to reconfigure the JMS Test Tool application to point to the WMQ JNDI names as opposed to the Default Provider JNDI names. When we deployed the application, the installation wizard allowed us the option of re-pointing of the JNDI names. This was because the application’s deployment descriptor declared resource references, which the installation wizard picked up and presented as configurable options in the installation wizard. Even after a deployment is complete, it is possible to reconfigure an application at any time by drilling down into the application configuration. We want to change the JNDI names the application is using for the QCF and queue destination. We are going to change jms/QCF.Test to jms/ QCF.LQTest and jms/Q.Test to jms/LQ.Test. This re-mapping of the applications JNDI will allow the application to use WMQ instead of JMS via the SIB. To change the application’s resource references, click Applications in the left-hand-side panel of the
Admin console, and then expand the Application Types section and click WebSphere
enterprise applications
. Click on the JMS Test Tool from the application list. You will
then be presented with the main application configuration panel. Look for a section called References as shown in the following screenshot:

Click on the Resource references link and change the Target Resource JNDI Name
field to jms/QCF.LQTest as shown below and then click on OK to return back to the
previous page.

Click on Continue if you get any warnings. We have now re-pointed the application’s QCF reference to the new WMQ QCF configuration.
To change the queue destination, we click on the Message destination references link
and change the Target Resource JNDI Name field to jms/LQ.Test as shown below.

We have now completed the re-mapping of resources. Click on Save to make the changes permanent and restart the application server. When you next use the JMS Test Tool application, the sending and receiving of messages will be using WMQ instead of the Default Messaging Provider.

	You can use the following command to show the messages sitting
	on the LQ.TEST queue if you wish to see the queue depth (how many
	messages are on the queue):
	
	echo "dis ql(*) curdepth where (curdepth gt 0)" |
	runmqsc TSTDADQ1

Summary

In this chapter, we learned that WebSphere provides a level of abstraction to messaging configuration by allowing resources to be referenced by JNDI. We deployed a message-enabled application which required a queue connection factory and queue destination which it used to send and receive messages. We configured two different implementations of JMS. One implementation used the internal Default Messaging Provider, which required a SIB to be created, and we covered how to create the QCF and queue destinations and bound the applications resource references to those configured in WebSphere.

We then covered how to install WebSphere MQ and larned how to create a queue manager and a queue. Then, in WebSphere, we created a QCF and queue destination using the WebSphere MQ provider and demonstrated how to to re-map our applications resource references to re-point the application to use MQ messaging subsystem as opposed to the internal messaging subsystem.

There are many uses of messaging in enterprise applications and we have essentially covered the key areas for configuring WebSphere to facilitate resources for message-enabled applications.

Comments

comments

Speak Your Mind

*