Introduction to IBM MQ – Part 3

Brief Technical Introduction, IBM, IBM MQ, Technology / August 1, 2018 / 5 minutes of reading
Post Views: 1,461

Introduction to IBM MQ

Part 3

MQ Objects : Queue Manager, Queues and Channels

IBM MQ provides three primary interfaces for managing MQ queue managers and MQM resources such as queues, processes, namelists, and channels.

  • MQ script commands (MQSC) and MQ control commands are command-line interfaces that used to create and modify queue managers and queue manager resources.
  • IBM MQ Explorer is a graphical user interface that runs on Linux and Windows. It can connect to, control, and configure MQ on all operating systems. MQ Explorer is described in detail later in this course.

Queue Manager

  • A queue manager is the subsystem software which controls access to the individual queues assigned to it. The queue manager logs all activity with each individual queue thus creating an audit trail. Multiple queue managers can coexist with each other. The limiting factor is the availability of system resources.

Following are some of the functions of queue managers :

  • Manages queues of messages for applications
  • Uses existing network facilities to transfer messages
  • Segments messages and assembles them
  • Allows message grouping and disassembling
  • Coordinates database and queue data updates
  • Can send message to more than one destination
  • Provides administrative functions on objects
  • Generates special events like triggers and instrumentation events
  • Provides application programming interface MQI

Each queue manager is assigned a unique TCP/IP port. The default TCP port for a queue manager is 1414. The port number 1414 is assigned to MQ by the Internet Assigned Numbers Authority. When the server contains more than one queue manager, each queue manager must have a different port number.

Queue managers can be referenced as local or remote. Whether a queue manager is local or remote depends on whether the administrator or application is directly connected to a queue manager.

Queues

An MQ queue is a named object on which applications can put messages, and from which applications can get messages. Messages are stored on a queue, so that if the putting application is expecting a reply to its message, it can do other work while it waits for the reply. Applications access a queue by using the Message Queue Interface (MQI).

When an application opens a queue, the queue manager to which the application is connected determines whether the queue is a local queue owned by the queue manager, or is a remote queue owned by another queue manager.

Local Queue : the message is placed directly on the queue

Remote Queue : the queue manager places the message instead on a special queue called a transmission queue.

There are some local queues that have special purposes in IBM MQ:

Dead letter queue
A designated queue upon which a queue manager will put messages that cannot otherwise be delivered. It is not mandatory for a queue manager to have a dead letter queue, but it is strongly recommended.

Initiation queue
Used to implement triggering.

Transmission queue
A transmission queue works with message channels to enable queue manager-to-queue manager communication. The Usage attribute indicates that a local queue is used as a transmission queue.

Command queue
Receives WebSphere MQ commands from an administration application running locally or remotely.

Event queue
When a queue manager detects an instrumentation event, which is some significant occurrence in a queue manager, such as an error or a warning, it puts an event message describing the event on an event queue.

Default queues
Identify the default values of attributes of any new queue that is created.

Channels

An MQ channel is a one way link between two queue managers for the transmission of messages. It consists of a message channel agent (MCA) at the sending end, an MCA at the receiving end, and a communications
protocol between the two.

Each end of a message channel has a separate definition. Both definitions contain the name of the message channel. Among other things, the definition at each end indicates whether it is the sending or receiving end of the channel, and the communication protocol to be used. A transmission queue is required for each message channel, but is actually located at the sending end of the channel. As a result, only the definition of the message channel at the sending end contains the name of the transmission queue. A common practice is to name the transmission queue the same name as the destination queue manager.

Every channel must be defined at both sides of MCA. The name of the channel must be the same at both ends. The channel must be defined as a specific type during its definition at both ends.

The channel types could be :

  • Sender
  • Receiver
  • Requester
  • Server
  • Svrconn
  • Clntconn
  • Cluster Sender
  • Cluster Receiver

During the definition of a channel at both ends of the communication link, their types should be defined. Generally channels work in combinations such as those listed below :

1)Sender – Receiver  : The sender starts the channel so that it can send messages to the other system. The sender requests the receiver at the other end of the channel to start. The sender sends messages from its transmission queue to the receiver. The receiver puts the message on the destination queue.

 

2) Requester – server : A requester starts the channel so that it can receive messages from the other system. The requester requests the server at the other end of the channel to start. The server sends messages to the requester from the transmission queue defined in its channel definition.

3) Requester – Sender: The requester starts the channel and the sender terminates the call. The sender then restarts the communication according to information in its channel definition (callback). It sends messages from
the transmission queue to the requester.

4) Server – Receiver : This is similar to sender-receiver but applies only to fully qualified servers. Channel startup must be initiated at the server end of the link.

5) Clntconn – svrconn : This combination is reserved for use only in the MQI client environment. The client initiates the connection when the MQCONN is issued. Data flows in both directions. The connection is terminated when the MQDISC is issued.

6) Cluster Sender – Cluster Receiver : This is similar to a Sender – Receiver channel functionality but works within the MQ cluster environment.

 

Scroll to Top