Core Java

Websphere MQ Tutorial

1. Introduction

WebSphere MQ is an IBM product launched in March 1992. It was initially called MQ series and then renamed to WebSphere MQ(commonly called MQ) in 2002 in order to join collection of WebSphere products.

It is a messaging middleware that allows independent and potentially non-concurrent applications on a distributed system to securely communicate with each other regardless of where application resides as it is platform independent and is available for large number of operating systems including IBM and non-IBM, mainframe, AS/400, AIX, HP-UX, Solaris, Linux, Microsoft Windows and many others.

MQ facilitates the secure and reliable communication between applications, systems, services and file by sending and receiving message data via messaging queues. It provides high performance, reliable, secure, and scalable message transfer for messages.

1.1 Message

The message can contain simple character data, numeric data, complex binary data, and a request for information, a command, or a mixture of all of these.

MQ categorized messages into 2 categories.

  • Non-persistent messages: Non-persistent messages can be lost if network communication between queue managers fails, a queue manager is restarted to perform maintenance, or an abrupt failure occurs that ends a queue manager un-cleanly.
  • Persistent messages: WebSphere MQ assures exactly one delivery of persistent messages. This means that WebSphere MQ does not discard a persistent message through network failures, delivery failures, or planned restarts of the queue manager.

Note: Always mark messages containing business-critical data as persistent.

2. MQ Infrastructure

2.1 Queue Manager

A queue managers is a container of MQ objects. Multiple queue managers can run on a single physical server. The queue managers maintain the queues and all of the messages that reside on those queues.

Queue managers are tolerant to failures, maintaining the integrity of the business-critical data flowing through the queues. Queue managers can run on a large variety of different hardware and operating system combinations. Each queue manager provides facilities for reliable message queuing. Queue managers on all platforms provide facilities for message queuing using a point-to-point model.

2.2 Queues

A queue is a container of messages. New messages are placed at the end of the queue, and messages are usually retrieved from the front of the queue.

MQ allows asynchronous communication by placing a queue between the producer of a message and the consumer. The producer can send a message without knowing whether the consumer ofthat message is currently available. Consumer can then send a reply to that message back to the producer if required.

Types of Queues

2.2.1 Local Queue

Local queue objects are the only type of queue object that represent a real queue that holds messages. A simple example of using a local queue is where multiple applications communicate asynchronously on the same machine. Applications put messages to and get messages from that same local queue.

2.2.2 Transmission Queue

A local queue can be designated as a transmission queue. To do this, specify the usage attribute of the local queue as transmission (XMITQ). Applications should not attempt to put messages to this queue directly.

The transmission of messages from a transmission queue to a remote queue manager is performed by a message channel. Defining a transmission queue provides a queue manager with knowledge of how to route messages to a single destination queue manager. Any messages sent with an object queue manager name the same as the name of the transmission queue are placed on that transmission queue. For this reason, the name of the transmission queue and the name of the remote queue manager should generally match.

2.2.3 Alias Queue

An alias queue object is a representation of another target queue object, which has a different name. An alias queue can be accessed in the same way as the target queue object of which it is an alias. References to it are redirected to the target queue object specified as part of the alias queue definition.

Advantage of alias queue is that it allows multiple programs to work with the same queue but with different attribute or properties.

2.2.4 Model Queue

A model queue is not a real queue. Model queue objects provide the attributes of a local queue object that can be created dynamically by an application. Dynamically created queues are instances of local queues and can hold messages. Dynamic queues can be used to give an application a temporary identity within the WebSphere MQ message queuing infrastructure.

2.2.5 Remote Queue

Remote queue objects are used to define routes to other queue managers within the WebSphere MQ message queuing infrastructure. This involves mapping queue manager names to transmission queues, and mapping queue names to different queue names on remote queue managers. Remote queue holds the address of the remote queue manager where the message has to be sent or delivered.

Message flow from remote queue: Remote Queue → Transmission Queue → Channel → Network receiver channel → Local Queue (finally the message will reach here)

2.2.6 Dead Letter Queue

A queue called the SYSTEM.DEAD.LETTER.QUEUESYSTEM. Prefix in the WebSphere MQ Explorer.

2.3 Channels

The queue managers within the infrastructure are connected with channels.Messages automatically flow across these channels, from the initial producer of a message to the consumer of that message, based on the configuration of the queue managers in the infrastructure.

Types of Channels

2.3.1 Receiver Channel

Receiver channel objects are defined on a queue manager to define the attributes of a receiving MCA to which other queue managers can send messages. A receiver channel object cannot be used to initiate a channel.

2.3.2 Requester Channel

Requester channel objects are defined on a queue manager to define the attributes of a receiving MCA to which other queue managers can send messages.

2.3.3 Sender Channel

Sender channel objects are defined on a queue manager to define the attributes of a sending MCA that can send messages to other queue managers from a specified transmission queue. Only one sender or server channel MCA can be active at any time for the same transmission queue. A sender channel object can be used to initiate a channel.

2.3.4 Server Channel

Server channel objects are defined on a queue manager to define the attributes of a sending MCA that can send messages to other queue managers from a specified transmission queue. Only one sender or server channel MCA can be active at any time for the same transmission queue.

A server channel object can only be used to initiate a channel if a connection name is specified in its definition. If a connection name is specified, the server channel object is said to be fully qualified.

2.3.5 Sender-Receiver Channel

This form of channel can only be initiated from the sender side. Multiple sender channel objects, defined on different queue managers, can be used to connect to the same receiver channel object on a queue manager. Commonly, a single receiver channel object is defined on a queue manager, and all queue managers in the infrastructure has sender channels defined with the same name as that receiver channel to communicate with that queue manager.

2.3.6 Requester-Server Channel

This form of channel can be initiated from the requester side, or optionally also from the server side if that server is fully qualified with a connection name. This form of channel does not ensure that a requester initiating a channel is hosted at a particular connection name. This allows multiple requesters to be defined with the same name on different queue managers and for each to request messages from a single transmission queue on the same remote queue manager. However, only one channel to a requester can be active getting messages from the transmission queue at any time.

2.3.7 Requester-Sender Channel

This form of channel is similar to a requester-server channel with a fully qualified server. However, after the channel has been initiated by the requester, the channel is disconnected and re-initiated by the sender channel using the connection name in the sender channel object. This enables the sender channel to ensure that it is partnered with a requester channel hosted on a particular queue manager.

2.3.8 Server-receiver channels

This form of channel is functionally equivalent to a sender-receiver pair. The channel is initiated from the server side, so the server must be fully qualified with a connection name.

2.4 Listener

It is a service of MQ. Every Queue Manager will have a listener defined with unique port number. Default port number is 1414. Listener act as a mediator between external application or queue managers connecting to the queue manager. To contact queue manager we should approach through listener.

It is a component of a WebSphere MQ queue manager, or a WebSphere MQ client product, that forms one half of a channel, establishing network communications with, or corresponding to network communications from, a partner MCA.

3. WebSphere MQ control commands

Following are WebSphere MQ control commands on Microsoft Windows and UNIX to perform the administration of queue managers:

dspmq: Display a list of queue managers that exist on the machine and their status.

Example:

$ ./dspmq
QMNAME(QMANAGER) STATUS(Ended immediately)

crtmqm: Create a queue manager.

Example:

$ ./crtmqm QMGR1
WebSphere MQ queue manager created.
Directory ‘/var/mqm/qmgrs/QMGR1′ created.
The queue manager is associated with installation ‘Installation1′.
Creating or replacing default objects for queue manager ‘QMGR1′.
Default objects statistics : 71 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

strmqm: Start a queue manager on UNIX.

Example:

$ ./strmqm QMGR1
WebSphere MQ queue manager ‘QMGR1′ starting.
The queue manager is associated with installation ‘Installation1′.
5 log records accessed on queue manager ‘QMGR1′ during the log replay phase.
Log replay for queue manager ‘QMGR1′ complete.
Transaction manager state recovered for queue manager ‘QMGR1′.
WebSphere MQ queue manager ‘QMGR1′ started using V7.1.0.0.

endmqm: End (stop) a queue manager.

Example:

$ ./endmqm QMGR1
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete.

runmqsc

Interactive console for MQSC commands.

$ ./runmqsc QMGR1
Starting MQSC for queue manager QMGR1.

dspmqver

Report information about the current maintenance level of the WebSphere MQ installation.

Example:

$ ./dspmqver
Name: WebSphere MQ
Version: 7.1.0.0
Level: p000-L111024
BuildType: IKAP – (Production)
Platform: WebSphere MQ for Linux (x86-64 platform)
Mode: 64-bit
O/S: Linux 3.0.0-15-generic
InstName: Installation1
InstDesc:
InstPath: /opt/mqm
DataPath: /var/mqm
Primary: No
MaxCmdLevel: 710

3.1 Create a MQ Queue

Below example creates a MQ queue with queue name lets say MQ.REQUEST

Example:

Open MQ command line by giving the Queue Manager name
./runmqsc QMGR1
Starting MQSC for queue manager QMGR1.

define qlocal(MQ.REQUEST)
AMQ8006: WebSphere MQ queue created.

end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

3.2 Create a MQ Listener

Below example creates a listener on queue manager QMGR1 using TCP protocol on port 1414.

Example:

Add Listener definition using the following commands
./runmqsc QMGR1
DEFINE LISTENER(QMGR1.listener) TRPTYPE (TCP) PORT(1414)
START LISTENER(QMGR1.listener)
end

Output:

DEFINE LISTENER(QMGR1.listener) TRPTYPE(TCP) PORT(1414)
1 : DEFINE LISTENER(QMGR1.listener) TRPTYPE(TCP) PORT(1414)
AMQ8626: WebSphere MQ listener created.
START LISTENER(QMGR1.listener)
2 : START LISTENER(QMGR1.listener)
AMQ8021: Request to start WebSphere MQ listener accepted.
end
3 : end
2 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.

3.3 Create a MQ channel

Below example creates MQ channel channel_test with type as sevection channel SVRCONN.

Example:

runmqsc QMGR1
DEFINE CHANNEL(channel_test) +
CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
DESCR(‘WebSphere MQ Default Channel’) +
REPLACE
End

Output:

DEFINE CHANNEL(channel_test) +
1 : DEFINE CHANNEL(channel_test) +
CHLTYPE(SVRCONN) +
: CHLTYPE(SVRCONN) +
TRPTYPE(TCP) +
: TRPTYPE(TCP) +
DESCR(‘WebSphere MQ Default Channel’) +
: DESCR(‘WebSphere MQ Default Channel’) +
REPLACE
: REPLACE
AMQ8014: WebSphere MQ channel created.
end
2 : end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

4. Conclusion

This tutorial concludes the first part of this series. We saw basics about Websphere MQ and few fundamental control commands. In the next part we will learn about integrating MQ with java application code.

Dhruv Gupta

Dhruv holds Master degree in MCA and is OCPJP Certified Java EE Developer. He has been involved the wide variety of business application. Particularly always involved in J2EE technology and business domain as Finance. His areas of interest include Java EE, scalable architecture, object oriented design and In-Memory data grids. He loves writing about and evangelizing Java EE technologies. He is working as a software engineer in Finance domain where he is involved in projects based on Java J2EE technologies.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
tech
tech
6 years ago

Where can I find the next part of this about integrating MQ with java application code?

Deepak
Deepak
5 years ago

Could you please add more information about IBM MQ

Back to top button