Design considerations for IBM MQ applications

When you have decided how the applications can take advantage of the platforms and environments available to you, we 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 the application? See the following links for information about that different types of application we can develop:

    • Server
    • Client
    • Publish/subscribe
    • Web services
    • User exits, API exits, and installable services

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

    Programming language
    IBM MQ supports a number of different programming languages for writing applications. For more information see, Developing applications for IBM MQ.

    Applications for more than one platform

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

    For example if we 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 we should code for both situations using #ifdef. For example: 
    #ifdef _AIX
    AIX specific code
#else
    generic code
#endif

    Types of queues
    Do we want to create a queue each time that we need one, or do we want to use queues that have already been set up? Do we want to delete a queue when you have finished using it, or is it going to be used again? Do we want to use alias queues for application independence? To see what types of queues are supported, refer to Queues.

    Use shared queues, queue sharing groups, and queue sharing group clusters ( IBM MQ for z/OS only)
    We might want to take advantage of the increased availability, scalability, and workload balancing that are possible when we use shared queues with queue sharing groups. See Shared queues and queue sharing groups for more information.

    We 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.

    Use queue manager clusters
    We might want to take advantage of the simplified system administration, and increased availability, scalability, and workload balancing that are possible when we use clusters.

    Types of messages
    We might want to use datagrams for simple messages, but request messages (for which you expect replies) for other situations. We might want to assign different priorities to some of our messages. For more information about designing messages, see Design techniques for messages.

    Use publish/subscribe or point-to-point messaging
    Use 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.

    Use 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.

    Control the IBM MQ programs
    We 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 the 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. 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 we 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 the application performance, for suggestions for enhancing performance of IBM MQ applications, see Application design and performance considerations and Design and performance considerations for IBM i applications .

    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
    We can use the context information that is passed with a message to test that the message has been sent from an acceptable source. We 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). We 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 we can use the same development tools as well as the IBM MQ trace facilities.

    When testing CICS applications with IBM MQ for z/OS, we 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, we 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 Use and writing applications on IBM MQ for z/OS.

    When testing IBM i applications, we can use the standard Debugger. To start this, use the STRDBG command.

    Handling exceptions and errors
    We 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, we must set report options on MQPUT.


Related concepts


Related information