Queues: Point to Point Messaging
Remote Queue Definition: IBM MQ v9.2
Message Oriented Middleware(MOM) and Asynchronous communication
Scope
This article talks about IBM MQ v9.2 messaging middleware. The following components are covered:
a. Queue Manager
b. Queues (Local, Transmission)
c. Sender, Receiver and Server connection channel
d. Listeners
e. System Objects for Authentication
f. Remote Queue Definition
Audience
This article would help beginners and intermediate learners to understand and configure IBM MQ and get started to send and receive messages asynchronously.
Prerequisites
a. IBM MQ v9.2 server (Download IBM MQ 9.2.2 Continuous Delivery)
b. A simple Java Client with JMS API to send and receive messages.
Install IBM MQ v9.2 server
a. The download contains a compressed zip folder.
b. Extract the compressed zip.
c. Launch Setup and complete the installation.
d. Open MQ Explorer.
What is point to point messaging ?
In point-to-point messaging, each message travels from one producing application to one consuming application. Messages are transferred through the producing application putting messages onto a queue and the consuming application gets them from that queue.
I. Queue Manager
A queue manager is a system program that provides queuing services to applications. It provides an application programming interface so that programs can put messages on, and get messages from, queues. A queue manager provides additional functions so that administrators can create new queues, alter the properties of existing queues, and control the operation of the queue manager.
To have message queueing services available a queue manager must be running. Multiple queue managers can be running in the same system to exchange messages through remote queue definition.
1. Create Queue Manager: QM1 and QM2
In this exercise, we create, configure and understand the following:
Two queue managers QM1 and QM2 to demonstrate remote queue definition. It means, sending message from one queue manager QM1 to another queue manager QM2.
II. Queue
A named destination to which messages can be sent. Messages accumulate on queues until they are retrieved by programs that service those queues.
1. Create Local Queue Q1 in QM1
If you see the below configuration, the local queue is configured to transmit the message.
2. Create Remote Queue Q2 in QM1
If you see the below configuration, the remote queue is configured to send message to [QM2, queue Q2] through transmission queue [Q1 of QM1].
Also the remote queue name Q2 of QM1 should match local queue Q2 of QM2.
3. Create Local Queue Q2 in QM2
The below configuration shows the local queue Q2 has been configured as the destination to receive messages.
III. Channels
Channels are objects that provide a communication path from one queue manager to another. Channels are used in distributed queuing to move messages from one queue manager to another and they shield applications from the underlying communications protocols. The queue managers might exist on the same, or different, platforms.
Message channel agent(MCA)
A message channel agent is one end of a channel. A pair of message channel agents, one sending and one receiving, make up a channel and move messages from one queue manager to another. We create a sender channel in QM1 and a receiver channel in QM2 with the same name as shown below:
Sender channel with port number 1414, and receiver channel with port number 1415.
The below configuration shows, Sender channel connection name is set to point to hostname and port number of the destination queue manager QM2.
IV. Listeners
A listener is an IBM® MQ process that listens for connections to the queue manager.
Each listener object in MQ Explorer represents a listener process; however, if you start a listener process from the command line, the listener is not represented by a listener object in MQ Explorer. Therefore, to administer the listener process from MQ Explorer, create the listener object in MQ Explorer. When you start the listener object in MQ Explorer, the listener process starts.
There are different types of listener available in IBM MQ, depending on the transport protocol that the Message Channel Agent (MCA) uses to send and receive messages through the message channels:
- LU6.2
- TCP/IP
- NetBIOS
- SPX
The below configuration shows, TCP/IP transport protocol and port numbers of sender and receiver in QM1 and QM2 respectively.
V. System Objects for Authentication
1. What is MQ Connection Authentication ? (CONNAUTH)
Prior to MQ V8.0, MQ did not authenticate user ids and/or passwords out-of-box, MQ ‘assumed’ that if the operating system was OK with the user-id connecting to the queue manager then all was well, the only way to implement user-id/password authentication was by writing exits.
MQ V8.0 introduced Connection authentication (CONNAUTH) which allows user id/password authentication when an application or user connects to a queue manager and for connection requests to be rejected when the user cannot be authenticated.
MQ Connection authentication provides the ability for an MQ application to provide a user and password for both MQ Local Bindings (cross memory — same host) and MQ Client Connection Channel connections.
2. The new Authentication Information objects
MQ V8.0 introduces two new Authentication Objects for use with Connection Authentication system default objects for both of these new types can be seen in MQ Explorer for a queue manager in the ‘Authentication Information’ folder:
The two new AUTHINFO objects type are defined on a new queue manager as ‘SYSTEM.DEFAULT.AUTHINFO.IDPWOS’ and ‘SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP’ the other two — ‘SYSTEM.DEFAULT.AUTHINFO.CRLLDAP’ and ‘SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP’ were introduced in an earlier version of MQ and for use with SSL certificate revocation checking.
When a new V8.0 or later queue manager is created it will be configured by default to use the ‘SYSTEM.DEFAULT.AUTHINFO.IDPWOS’ AUTHINFO object as can be seen via the queue managers extended properties in MQ Explorer:
Authentication information: Mandatory vs Optional
You can configure the Authentication objects as shown above, to make the application send authentication information (or) you can make it optional by not sending it from application.
Lets see how to configure:
In the SYSTEM.DEFAULT.AUTHINFO.IDPWOS, system object, you have the option to select whether authentication can be set to mandatory or optional. Based on that the Operating system will authenticate with OS credentials passed by the application client.
Create a simple Java Client
Run Application and see Console Output
Conclusion
We learnt to install and configure IBM MQ v9.2.
This article showed how to configure Queue managers, Queues, Channel, Listeners, and Remote queue definition. We also executed a Java Client application to send and receive messages to and from Queue managers through remote queue definition.
Published on 11th June 2021
Other medium articles, by Ganesh Nagalingam
Kubernetes Pods & Docker Containers: Spin VM using Virtual Box in Windows 10 Home
INTEGRATE KERBEROS WITH SPRING SECURITY: IDENTITY AND ACCESS MANAGEMENT(IAM)
Integrate IBM Business Process Manager with Hybrid MobileFirst application
Integrate Service providers(SPs) with OKTA Identity provider(IdP)
Integrate IBM WebSphere Service Registry and Repository with IBM Process Server
Federate OKTA IdP with WSO2 API Manager as Gateway to Spring boot Microservices Integration
