Application programming

 


WebSphere MQ supports the IBM Message Queue Interface (MQI) and the Application Messaging Interface (AMI). The MQI includes a set of calls with which you can send and receive messages, and manipulate MQSeries objects. The Application Messaging Interface (AMI), a simpler interface than the MQI, may be sufficient in some cases. Further information about the AMI is outside the scope of this book. For full details, refer to WebSphere MQ Application Messaging Interface.

 

Call interface

The MQI calls allow you to:

  • Connect programs to, and disconnect programs from, a queue manager

  • Open and close objects (such as queues, queue managers, namelists, and processes)

  • Put messages on queues

  • Receive messages from a queue, or browse them (leaving them on the queue)

  • Inquire about the attributes (or properties) of WebSphere MQ objects, and set some of the attributes of queues

  • Commit and back out changes made within a unit of work, in environments where there is no natural syncpoint support, for example, UNIX systems

  • Coordinate queue manager updates and updates made by other resource managers

The MQI provides structures (groups of fields) with which you supply input to, and get output from, the calls. It also provides a large set of named constants to help you supply options in the parameters of the calls. The definitions of the calls, structures, and named constants are supplied in data definition files for each of the supported programming languages. Also, default values are set within the MQI calls.

 

Design for performance - hints and tips

Here are a few ideas to help you design efficient applications:

  • Design your application so that processing goes on in parallel with a user's thinking time:

    • Display a panel and allow the user to start typing while the application is still initializing.

    • Don't be afraid to get the data you need in parallel from different servers.

  • Keep connections and queues open if you are going to reuse them instead of repeatedly opening and closing, connecting and disconnecting.

  • However, a server application which is putting only one message should use MQPUT1.

  • Keep your messages within a unit of work, so that they can be committed or backed out simultaneously.

  • Use the nonpersistent option for messages that do not need to be recoverable.

 

Programming platforms

For details of supported programming platforms, please refer to the product announcements at

http://www.ibm.com/software/ts/mqseries/library/#announce

 

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 you use today? If the answer to either of these questions is "yes", you need to make sure that you code your programs for platform independence.

If you are using C, make sure that you 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 code for both situations using #ifdef. For example:

#ifdef _AIX
     AIX specific code
#else
     generic code
#endif

When the time comes to move the code to another platform, you can now search the source for #ifdef with the platform specific identifiers, in this example _AIX, and add or change code as necessary.

It is worth considering keeping portable code in separate source files from the platform-specific code, and using a simple naming convention to split the categories.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

AIX is a trademark of the IBM Corporation in the United States, other countries, or both.