Customizing WebSphere MQ V7 for small and medium businesses

This article describes common challenges you may encounter when implementing WebSphere MQ based solutions at small and medium businesses (SMBs), and shows you how to overcome these challenges.

Mohit Arora (arora.mohit@in.ibm.com), Solutions Developer, IBM

Photo of Mohit AroraMohit Arora is a Staff Software Engineer on the Lab Services team at the IBM Software Lab in Bangalore, India. He has worked for IBM for six years in various middleware technologies. You can contact Mohit at arora.mohit@in.ibm.com.



Amit M. Mangalvedkar (amitmangalvedkar@in.ibm.com), Senior Staff Software Engineer, IBM

Photo of Amit M. MangalvedkarAmit M. Mangalvedkar is a Senior Staff Software Engineer on the Lab Services team at the IBM Software Lab in Bangalore, India. He has worked for IBM for ten years in product development and customer engagements involving various middleware technologies. You can contact Amit at amitmangalvedkar@in.ibm.com.



22 June 2011

Also available in Chinese Spanish

Introduction

To show you how to deal with common challenges when implementing IBM® WebSphere® MQ based solutions at small and medium businesses (SMBs), this article uses the common scenario of a single head office and multiple branch offices or stores, each one with its own WebSphere MQ server. For many SMBs, investment in back-end infrastructure may be constrained, and therefore you face challenges of network downtime or slow connectivity. But before delving into the challenges of such an environment, consider the characteristics of a robust or ideal environment for WebSphere MQ:

  • VPN infrastructure
  • Static IP addresses
  • Single ISP
  • High-bandwidth network speed
  • Monitoring tools such as IBM Tivoli® OMEGAMON for XE Messaging
  • Recommended hardware configurations

As mentioned, two of the most common network challenges at an SMB are:

  • Internet connectivity breakdowns -- SMBs who do not invest in a dish-based wireless Internet connection will generally opt for multiple connections from different service providers with static IP addresses. When there is a breakdown in one of the connections, the SMB switches (sometimes manually) to another service provider.
  • Slow communication between head office and stores -- For this issue, an SMB often optimizes applications to send minimal data to branch servers and defers additional communications to overnight or other low-usage periods. This arrangement may require significant application customization.

The rest of the article describes the following sub-optimal conditions and how to address the related problems, as well as how to use the WebSphere MQ Performance Monitor (SupportPac MP08).

  • Dynamic IP addresses
  • Multiple ISPs
  • Low-bandwidth speeds between head office and stores

Configuring WebSphere MQ between two remote servers

Dynamic IP address at receiver end

Consider a typical interqueue communication scenario between two WebSphere MQ servers, one at a central office and one at a store, with a sender-receiver channel:

Interqueue communication
Interqueue communication

In this scenario, the queue manager HQ.QM sends a message to the queue manager STORE.QM. The queue manager HQ.QM has the following WebSphere MQ objects:

  • REMOTEQ (remote queue)
  • TRANSQ (transmission queue)
  • HQ.STORE.CNL (sender channel from HQ.QM to STORE.QM)

Similarly, the queue manager STORE.QM has the following WebSphere MQ objects:

  • LOCALQ (local queue)
  • HQ.STORE.CNL (receiver channel from HQ.QM to STORE.QM)

The mqsc commands to configure this setup are shown below (1414 is the listener port number):

Sender channel definition
define channel (HQ.STORE.CNL) chltype(SDR) + 
conname('192.168.1.2(1414)') +
xmitq(TRANSQ)
Receiver channel definition
define channel (HQ.STORE.CNL) chltype(rcvr)

If the receiver (store server in our case) has a dynamic IP address assigned to it, it is virtually impossible for the sender system to communicate with the receiver system, and the sender channel will remain in retry mode -- a common issue with SMBs.

Sender-receiver channel

The hostname / IP address of the destination system in a sender-receiver channel, should be known up front and should be configured in the sender channel.

Sender channel unable to communicate
Sender channel unable to communicate

You can resolve this issue by making the receiving system initiate the communication, which you do in WebSphere MQ by using the requester-server channel:

Requester-server channel

The hostname / IP address of the sending system in a requester-server channel, should be known up front and should be configured in the requesting channel (the destination system of the messages)

Requester-server channel
Requester-server channel

In case of a requester-server channel, the receiving system (store server) initiates the connection. Once the initiation is successful, the message flows from head office server to store server. The queue manager HQ.QM has the following WebSphere MQ objects:

  • REMOTEQ (remote queue)
  • TRANSQ (transmission queue)
  • HQ.STORE.CNL (server channel)

Similarly, the queue manager QM2 has the following WebSphere MQ objects:

  • LOCALQ (local queue)
  • HQ.STORE.CNL (requester channel)

Here are the mqsc commands to create this configuration:

Server channel definition
define channel (HQ.STORE.CNL) chltype(SVR) +
xmitq(TRANSQ)
Requester channel definition
define channel (HQ.STORE.CNL) chltype(RQSTR) +
conname('192.168.1.1(1414)')

Other possible channel combinations

Apart from Sender-Receiver and Requester-Server, other possible combinations include Cluster Sender - Cluster Receiver, Server-Receiver and Requester-Sender channels.

There is a major difference in function between a sender-receiver channel pair and a requester-server channel -- for more information, see the WebSphere MQ V7 information center.

Multiple ISPs at the head office

The above scenario involving a requester-server channel works fine as long as the IP address of the sender system (192.168.1.1) is unchanged. But what if the sender system has multiple ISPs and one goes down, and the system switches over to another ISP. In that case, even if the sender side has a static IP address, each ISP would assigning an IP address from a different domain. Once again the requester channel will be unable to initiate the request to the server channel, and would go into retry mode because the IP address of the HQ Server system would have changed.

Requester channel for changed IP address
Requester channel for changed IP address

You can solve this problem by providing multiple IP addresses and the port number in the CONNAME, which is a new feature of WebSphere MQ V7 Refresh 1 (WebSphere MQ V7.0.1). The channel definition for the server channel remains the same:

Server channel definition
define channel (HQ.STORE.CNL) chltype(SVR) +
xmitq(TRANSQ)

However, the channel definition for the requester channel gets modified to:

Requester channel definition
define channel (HQ.STORE.CNL) chltype(RQSTR) + 
conname('192.168.0.1(1414),192.168.0.3(1414)')

Thus, even if there are multiple ISPs serving the sender side, you can add them, separated by commas, to the CONNAME settings of the requester channel:

Multiple ISPs at the sender side
Multiple ISPs at the sender side

In this configuration, all of the IP addresses will be attempted in a round-robin manner. As soon as the requester channel makes a connection with the server channel, it goes in a binding state and eventually into running mode.

Low bandwidth speed

By default, WebSphere MQ allows messages up to 4 MB long to be posted to a queue, and you can increase this limit up to 100MB without using segmentation. Also by default WebSphere MQ allows up to 5000 messages, and again you can increase this limit. Suppose 300 4MB messages are sent over a network with a broadband speed of 1 Mbps. Transmission would take approximately 9600 seconds or about 2 hours and 40 minutes. Time increases drastically as bandwidth speed falls: if bandwidth speed falls to 256 Kbps, transmission time increases to 10 hours 40 minutes.

Such situations make channel-level compression very valuable. It does not involve many configuration changes, and greatly increases the transfer speed. Consider a compression ratio of 95% (which is feasible if the WebSphere MQ message is in ASCII text). In that case, a 4 MB message is compressed to 200 KB, and the above transfer of 300 4MB messages would require only about 8 minutes at 1 Mbps and 32 minutes at 256 kbps.

To implement compression, you must apply the same compression algorithm to the sender, the receiver or requester, and the server channel, which you can do using either WebSphere MQ Explorer or runmqsc scripts:

Compression using WebSphere MQ Explorer

By default, channels do not have any compression algorithm enabled, as shown below:

Modifying channel properties for compression
Modifying channel properties for compression

To enable compression, click the Edit button next to Message Compression, which opens a drop-down that shows various compression algorithms:

Multiple compression algorithms supported
Multiple compression algorithms supported
  • RLE -- Run-length encoding compression. If the same data value occurs in a contiguous block, that block is replaced by a number that denotes the runs and the data.
  • ZLIBFAST -- Faster compression algorithm
  • ZLIBHIGH -- Higher ratio of compression
  • ANY -- Any of the above three algorithms can be used

You can also select multiple compression algorithms, which are tried in order of preference. The same compression algorithm must be used at the other end.

Order of preference for compression
Order of preference for compression

Compression using runmqsc scripts

You can achieve the same result using runmqsc. The following runmqsc scripts modify the channel definitions for the requester and server channel:

Requester channel definition
alter channel(HQ.STORE.CNL) +
chltype(RQSTR) +
COMPMSG(ZLIBFAST,ZLIBHIGH,RLE,NONE)
Server channel definition
alter channel(HQ.STORE.CNL) +
chltype(RQSTR) +
COMPMSG(ZLIBFAST,ZLIBHIGH,RLE,NONE)

Although the requester channel allows all compression algorithms (ZLIBHIGH, ZLIBFAST, RLE, ANY, and NONE), the server channel does not allow ALL.

Compression Algorithms

Not all channels allow all compression algorithms. The requester channel allows ZLIBHIGH, ZLIBFAST, RLE, and ANY.

Monitoring tools

This section shows you how to use WebSphere MQ Performance Monitor (WebSphere MQ SupportPac MP08).

Installation and configuration

  1. Download WebSphere MQ Performance Monitor.
  2. Install and configure WebSphere MQ Performance Monitor by following the instructions in the WebSphere MQ Performance Monitor documentation.

Monitoring

The WebSphere MQ Performance Monitor lets you collect and analyze performance data for queues, channels, and MQI calls for queue managers. System administrators can use WebSphere MQ Explorer itself to monitor the system status of WebSphere MQ for short periods.

The WebSphere MQ Performance Monitor contains the following two components:

  • Performance Monitor Agent for WebSphere MQ for Windows -- Install this component on the HO Queue manager server. It gets the queue manager data from the WebSphere MQ server and sends it across to the Performance Monitoring plug-in. If there are multiple queue managers on the HO server, then each queue manager needs to have the agent running, which means that once this component is installed, it needs to be configured for each queue manager that you want to monitor.
  • Performance Monitor Plug-in for WebSphere MQ for Windows and Linux -- This component gets the data from the monitoring agent and displays in graphical format for short-term trend analysis. This plug-in is installed on the server where WebSphere MQ Explorer resides.

The WebSphere MQ Performance Monitor provides short-term trend analysis in WebSphere MQ Explorer for:

  • Recent application accounting (for queue managers)
  • Recent MQI statistics (for queue managers)
  • Recent queue statistics (for queues)
  • Recent queue accounting (for queues)
  • Recent MQI queue statistics (for queues)
  • Recent channel performance (for channels)
  • Recent MQI channel statistics (for channels)

For more details about these plug-ins and agents, see the WebSphere MQ Performance Monitor documentation.

Listed below are some snapshots of the analysis performed by the plug-in:

Channel-level monitoring

Channel-level monitoring provides a graphical representation of various attributes, such as bytes and buffers sent and received, transmission speed, and short-term and long-term compression rates for various time intervals.

Channel level monitoring
Channel level monitoring

Queue level monitoring

Queue-level monitoring provides a graphical representation of various frequency attributes, such as open rate, close rate, get byte rate, put byte rate, and browse rate, for any given time interval:

Queue-level monitoring 1
Queue level monitoring 1

Queue-level monitoring also provides attributes such as current depth, highest depth, messages put, messages read, and messages browsed:

Queue-level monitoring 2
Queue level monitoring 2

Conclusion

This article described some common scenarios when using WebSphere MQ in SMB environments, and discussed the issues of dynamic IP addresses at the destination end, multiple ISPs, and low bandwidth. The article also explained some troubleshooting techniques for SMB environments, and showed you how to do monitoring using the WebSphere MQ Performance Monitor.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=680714
ArticleTitle=Customizing WebSphere MQ V7 for small and medium businesses
publish-date=06222011