Design techniques for messages

Considerations to help you design messages, including considerations for selectors and message properties.

Things to consider at the design stage

Type of message to use

Are you designing a simple application in which we can send a message, then take no further action? Or are you asking for a reply to a question? If we are asking a question, you might include in the message descriptor the name of the queue on which we want to receive the reply.

Do you want your request and reply messages to be synchronous? This implies that you set a timeout period for the reply to answer your request, and if we do not receive the reply within that period, it is treated as an error.

Or would you prefer to work asynchronously, so that your processes do not have to depend upon the occurrence of specific events, such as common timing signals?

Another consideration is whether you have all your messages inside a unit of work.

Assigning different priorities to messages

We can assign a priority value to each message, and define the queue so that it maintains its messages in order of their priority. If you do this, when another program retrieves a message from the queue, it always gets the message with the highest priority. If the queue does not maintain its messages in priority order, a program that retrieves messages from the queue will retrieve them in the order in which they were added to the queue.

Programs can also select a message using the identifier that the queue manager assigned when the message was put on the queue. Alternatively, you can generate your own identifiers for each of our messages.

Effect of restarting queue manager on messages

The queue manager preserves all persistent messages, recovering them when necessary from the IBM MQ log files, when it is restarted. Nonpersistent messages and temporary dynamic queues are not preserved. Any messages that we do not want discarded must be defined as persistent when they are created. When writing an application for IBM MQ for Windows or IBM MQ on UNIX and Linux systems, make sure that you know how the system has been set up in respect of log file allocation to reduce the risk of designing an application that will run to the log file limits.

Because messages on shared queues (only available on IBM MQ for z/OS ) are held in the coupling facility (CF), nonpersistent messages are preserved across restarts of a queue manager as long as the CF remains available. If the CF fails, nonpersistent messages are lost.

Giving information about yourself to the recipient of messages

Usually, the queue manager sets the user ID, but suitably authorized applications can also set this field, so that we can include your own user ID and other information that the receiving program can use for accounting or security purposes.

Amount of receiving queues

If a message might need to be put on several queues, we can publish to a topic or a distribution list.

If a message might need to be put on several queues, we can publish to a topic.

Selectors and message properties

Messages can have metadata associated with them alongside the main message payload. These message properties can be useful in supplying additional data.

• The properties are not subject to Advanced Message Security (AMS) protection. To use AMS to protect your data, then put it in the payload and not the message properties.
• The properties can be used to perform the selection of messages.

It is important to note that using selectors breaks the standard message convention of first in first out. As the queue manager is optimized for this workload, providing complex selectors is not advised for performance reasons. The queue manager does not store indexes of the message properties, therefore searching for a message must be a linear search. The deeper the queue, the more complex the selector, and the lower probability that the selector matching a message will adversely affect performance.

If complex selection is required, it is suggested to filter the messages by using any application or processing engine, such as IBM Integration Bus, to different destinations. Alternatively, the use of a topic hierarchy might be useful.