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.
Where can I find the next part of this about integrating MQ with java application code?
Could you please add more information about IBM MQ