Design techniques for advanced applications

When designing more advanced applications, there are some techniques that you might want to consider such as waiting for messages, correlating replies, setting and using context information, starting applications automatically, generating reports and removing message affinities when using clustering.

For a simple IBM MQ application, you need to decide which IBM MQ objects to use in our application, and which types of message you want to use. For a more advanced application, you might want to use some of the techniques introduced in the following sections.


Waiting for messages

A program that is serving a queue can await messages by:

  • Waiting until either a message arrives, or a specified time interval expires (see Waiting for messages ).
  • On IBM MQ for z/OS® only, setting a signal so that the program is informed when a message arrives. For more information, see Signaling.
  • Establishing a callback exit to be driven when a message arrives; see Asynchronous consumption of IBM MQ messages.
  • Making periodic calls on the queue to see whether a message has arrived (polling). This is not typically advisable because it can have performance implications.


Correlating replies

In IBM MQ applications, when a program receives a message that requests it to do some work, the program typically sends one or more reply messages to the requester.

To help the requester to associate these replies with its original request, an application can set a correlation identifier field in the descriptor of each message. Programs then copy the message identifier of the request message into the correlation identifier field of their reply messages.


Set and using context information

Context information is used for associating messages with the user who generated them, and for identifying the application that generated the message. Such information is useful for security, accounting, auditing, and problem determination.

When you create a message, we can specify an option that requests that the queue manager associates default context information with your message.

For more information about using and setting context information, see Message context.


Starting IBM MQ programs automatically

Use IBM MQ triggering to start a program automatically when messages arrive on a queue.

We can set trigger conditions on a queue so that a program starts to process that queue:

  • Every time that a message arrives on the queue
  • When the first message arrives on the queue
  • When the number of messages on the queue reaches a predefined number

For more information about triggering, see Starting IBM MQ applications using triggers. Triggering is just one way of starting a program automatically. For example, we can start a program automatically on a timer using non-IBM MQ facilities.

On Multiplatforms, IBM MQ can define service objects to start IBM MQ programs when the queue manager starts; see Service objects.


Generating IBM MQ reports

We can request the following reports within an application:

  • Exception reports
  • Expiry reports
  • Confirm-on-arrival (COA) reports
  • Confirm-on-delivery (COD) reports
  • Positive action notification (PAN) reports
  • Negative action notification (NAN) reports

These are described in Report messages.


Clusters and message affinities

Before starting to use clusters with multiple definitions for the same queue, examine our applications to see whether there are any that require an exchange of related messages.

Within a cluster, a message can be routed to any queue manager that hosts an instance of the appropriate queue. Therefore, the logic of applications with message affinities can be upset.

For example, you might have two applications that rely on a series of messages flowing between them in the form of questions and answers. It might be important that all the questions are sent to the same queue manager and that all the answers are sent back to the other queue manager. In this situation, it is important that the workload management routine does not send the messages to any queue manager that just happens to host an instance of the appropriate queue.

Where possible, remove the affinities. Removing message affinities improves the availability and scalability of applications.

For more information, see Handling message affinities.