Message and queue fundamentals

Messaging is an essential part of every enterprise and involves two things: messages and queues. These intricate messaging objects have interesting properties that enable developers to carry out message exchanges in a variety of ways. So let’s now take the first step in understanding these fundamental messaging components.

Messages

A message is a distinct set of bytes that are transferred between two applications.

Parts of messages

Messages consist of two parts:

1. The message descriptor, which provides control information
2. The application data, which is simply the message payload

The message descriptor provides control information, but also contains a format field that specifies what part comes next in the message, which can be a header.

Message header

A header is an optional part of the application data. There are several types of headers, each with a specific purpose. The most commonly used headers are:

• MQRFH2: The Rules and Formatting Header 2 offers the same functionality as the MQRFH, as well as containing the message properties.
• MQXQH: The Transmission Queue Header prefixes messages that are on transmission queues.
• MQDLH: The Dead Letter Header prefixes messages that arrive on the dead letter queue due to being undelivered.

Message properties

Messages also contain message properties, which applications can use to retrieve messages for processing. Message properties can be used to provide business data or to state information, without having to store it in the application data.

Message properties will either be stored as part of the message descriptor or in an MQRFH2 header. For JMS applications, the logic of setting the message properties is handled by the client and is hidden from the application.

The following table shows the general properties that apply to all messages, but for details of more specialized properties you can head to this MQ doc.

• Position: The current position of the message in the queue.
• Message Type: This is the type of the message and may be any one of the following:
  • Datagram means that the message does not require a reply.
  • Request means that the message requires a reply.
  • Reply means that the message is a reply to an earlier request message.
  • Report means that the message is reporting on some expected or unexpected occurrence, usually related to some other message.
• Priority: The priority of the message. The lowest priority is 0.
• Persistence: Indicates whether the message is persistent or nonpersistent. If the message is persistent, it survives system failures and restarts of the queue manager.
• Put Date/Time: The period of time, in tenths of a second, after which the message becomes eligible to be discarded if it has not already been removed from the target queue. The expiry interval is set by the application that put the message.
• Reply-to queue: The name of the message queue to which the application that issued the get request for the message should send the reply and report messages.
• Reply-to queue manager: The name of the queue manager on which the reply-to queue is defined.
• Backout Count: The number of times the message has previously been returned by the MQGET call as part of a unit of work, and subsequently backed out.

Message queues

Messages are stored on queues, which are addressable locations that decouple applications. Queues are maintained by and stored in queue managers and this logic is hidden from the applications.

Types of queues

There are four types of queues:

• Local queues: These are queues owned by the queue manager that the application is connected to. Queue managers might also have special purpose local queues including transmission, initiation, and dead-letter queues. You can read more about these special purpose queues here.

• Model queues: These are templates of queue definitions used when creating dynamic queues during request-response exchanges, for example.

• Alias queues: This is an object that is used to access another queue or topic, which means that more than one program can work on the same queue and access it by using different names.

• Remote queues: These are queues owned by queue managers that the application is not connected to. While an application can put messages to a remote queue, it can’t get messages from them directly.

Opening queues

To use a queue, it has to be opened for a particular purpose. You can open a queue for these purposes:

• Browsing messages (not destructively getting them)
• Retrieving messages
• Putting messages on the queue
• Inquiring about the attributes of the queue
• Setting the attributes of the queue

Queue attributes

Queues have attributes that are specified when the queue is defined. The values of some of these attributes cannot be altered once defined, and different types of queues have different attributes.

The key attributes common to most queues are:

• QName: Name of the queue.
• QType: Type of the queue.
• QDesc: Text description of the queue.
• InhibitGet: Whether programs are allowed to get messages from the queue.
• InhibitPut: Whether programs are allowed to put messages on the queue.
• DefPriority: Default priority for messages put on the queue.
• DefPersistence: Default persistence for messages put on the queue.

You can find a complete list of queue attributes and the queues that they apply to in the MQ doc.

Summary

In this article, we looked at the fundamental components of enterprise messaging – messages and queues. We then broke these down and looked at the specific properties of these.

In the next article, we’ll look at how the message and queue properties are used to achieve sophisticated message exchange behaviors.