Planning your design

 

When you have decided how your applications can take advantage of the platforms and environments available to you, we need to decide how to use the features offered by WebSphere MQ. Some of the key aspects are:

What types of queue should you use?

Do you want to create a queue each time that we 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.

Should you use shared queues and queue-sharing groups (WebSphere MQ for z/OS only)?

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 the WebSphere MQ for z/OS Concepts and Planning Guide for a full discussion of this topic.

What types of message should you use?

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.

How can you control your WebSphere MQ programs?

You might want to start some programs automatically or make programs wait until a particular message arrives on a queue (using the WebSphere MQ triggering feature, see Starting WebSphere MQ applications using triggers). Alternatively, you might want to start up another instance of an application when the messages on a queue are not getting processed fast enough (using the WebSphere MQ instrumentation events feature as described in WebSphere MQ Monitoring).

Will your application run on a WebSphere MQ client?

The full MQI is supported in the client environment and this enables almost any WebSphere MQ application to be relinked to run on a WebSphere MQ client. Link the application on the WebSphere MQ client to the MQIC library, rather than to the MQI library. The exceptions are:

  • An application that needs syncpoint coordination with other resource managers.

  • Get(signal) on z/OS is not supported.

An application running on a WebSphere 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 WebSphere MQ Clients for more information.

How can you secure your data and maintain 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 WebSphere 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 WebSphere MQ messages to assure the delivery of important messages.

How should you handle 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, set report options on MQPUT.

The remainder of this chapter introduces the features and techniques that WebSphere MQ provides to help you answer questions like these.

 

Parent topic:

Overview of application design


fg10400_