Design considerations for IBM MQ applications

When you have decided how your applications can take advantage of the platforms and environments available to you, you need to decide how to use the features offered by IBM® MQ.

When designing an IBM MQ application consider the following questions and options:
Type of application
What is the purpose of your application? See the following links for information about that different types of application you can develop:
  • Server
  • Client
  • Publish/subscribe
  • Web services
  • User exits, API exits, and installable services

Additionally, you can also write your own applications to automate administration of IBM MQ. For more information, see Introduction to the IBM MQ Administration Interface (MQAI) and Automating administration tasks.

Programming language
IBM MQ supports a number of procedural and object-oriented programming languages for writing applications. For more information see, Developing applications.
Applications for more than one platform

Will your application run on more than one platform? Do you have a strategy to move to a different platform from the one that you use today? If the answer to either of these questions is yes, ensure that you code your programs for platform independence.

For example if you are using C, code in ANSI standard C. Use a standard C library function rather than an equivalent platform-specific function even if the platform-specific function is faster or more efficient. The exception is when efficiency in the code is paramount, when you should code for both situations using #ifdef. For example: 

#ifdef _AIX
    AIX specific code
#else
    generic code
#endif
Types of queues
Do you want to create a queue each time that you need one, or do you want to use queues that have already been set up? Do you want to delete a queue when you have finished using it, or is it going to be used again? Do you want to use alias queues for application independence? To see what types of queues are supported, refer to Queues.
[z/OS]Using shared queues, queue-sharing groups, and queue-sharing group clusters ( IBM MQ for z/OS® only)
[z/OS]You might want to take advantage of the increased availability, scalability, and workload balancing that are possible when you use shared queues with queue-sharing groups. See Shared queues and queue-sharing groups for more information.

You might also want to estimate the average and peak message flows and consider using queue-sharing group clusters to spread the workload. See Shared queues and queue-sharing groups for more information.

Using queue manager clusters
You might want to take advantage of the simplified system administration, and increased availability, scalability, and workload balancing that are possible when you use clusters.
Types of messages
You might want to use datagrams for simple messages, but request messages (for which you expect replies) for other situations. You might want to assign different priorities to some of your messages. For more information about designing messages, see Design techniques for messages.
Using publish/subscribe or point-to-point messaging
Using publish/subscribe messaging, a sending application sends the information that it wants to share in an IBM MQ message to a standard destination managed by IBM MQ publish?subscribe, and lets IBM MQ handle the distribution of that information. The target application does not have to know anything about the source of the information it receives, it just registers an interest in one or more topics and receives that information when it is available. For more information about publish/subscribe messaging, see Publish/subscribe messaging.

Using point-to-point messaging, a sending application sends a message to a specific queue, from where it knows a receiving application will retrieve it. A receiving application gets messages from a specific queue and acts on their contents. An application will often function both as a sender and a receiver, sending a query to another application and receiving a response.

Controlling your IBM MQ programs
You might want to start some programs automatically or make programs wait until a particular message arrives on a queue (using the IBM MQ triggering feature, see Starting IBM MQ applications using triggers ). Alternatively, you might want to start another instance of an application when the messages on a queue are not getting processed fast enough (using the IBM MQ instrumentation events feature as described in Instrumentation events ).
Running your application on an IBM MQ client
The full MQI is supported in the client environment, and almost any IBM MQ application written in a procedural language can be relinked to run on an IBM MQ MQI client. Link the application on the IBM MQ MQI client to the MQIC library, rather than to the MQI library. [z/OS]Get(signal) on z/OS is not supported.
Note: An application running on an IBM MQ client can connect to more than one queue manager concurrently, or use a queue manager name with an asterisk (*) on an MQCONN or MQCONNX call. Change the application if you want to link to the queue manager libraries instead of the client libraries, as this function will not be available.

See Running applications in the IBM MQ MQI client environment for more information.

Application performance
Design decisions can impact your application performance, for suggestions for enhancing performance of IBM MQ applications, see Application design and performance considerations [IBMi]and Design and performance considerations for IBM i .
Advanced IBM MQ techniques
For more advanced applications you might want to use some advanced IBM MQ techniques such as correlating replies, and generating and sending IBM MQ context information. For more information, see Design techniques for advanced applications.
Securing your data and maintaining its integrity
You can use the context information that is passed with a message to test that the message has been sent from an acceptable source. You can use the syncpointing facilities provided by IBM MQ or your operating system to ensure that your data remains consistent with other resources (see Committing and backing out units of work for further details). You can use the persistence feature of IBM MQ messages to assure the delivery of important messages.
Testing IBM MQ applications

The application development environment for IBM MQ programs is no different from that for any other application, so you can use the same development tools as well as the IBM MQ trace facilities.

[z/OS]When testing CICS® applications with IBM MQ for z/OS, you can use the CICS Execution Diagnostic Facility (CEDF). CEDF traps the entry and exit of every MQI call as well as calls to all CICS services. Also, in the CICS environment, you can write an API-crossing exit program to provide diagnostic information before and after every MQI call. For information about how to do this, see Using and writing applications on IBM MQ for z/OS.

[IBMi]When testing IBM i applications, you can use the standard Debugger. To start this, use the STRDBG command.

Handling exceptions and errors
You need to consider how to process messages that cannot be delivered, and how to resolve error situations that are reported to you by the queue manager. For some reports, you must set report options on MQPUT.