WebSphere MQ summary
WebSphere MQ middleware is IBM product and it can be installed on any of IBM servers: zServer, Pserver, iServer and xServer.¬† MQ middleware has the mechanism of data integrity in it, so applications do not need to check data validity and integrity. MQ is applied in the scenario where large data block or data file is transferred and less or no interactions between two servers are needed. This is the general architecture of MQ middleware:
In an installed MQ system there are some queues for management purpose. Applications do not need to access them. And even developers do not need to configure them ‚Äď MQ administrators work them. But developers need to design the queues where their application data is transmitted.
On iServer, command WRKMQMQ is used to create/delete/maintain an MQ. This command integrates a lot of functions.
Usually any organization has control of MQ authority, especially for creating/deleting/updating MQ and Queue manager. So you need to have appropriate authority before you do these things.
Usually one server is configured with one queue manager. All the MQ queues in this server are governed by this queue manage. In the above screen shot, if type is *LCL, this means the queue is local queue. If type is *RMT, this is remote queue. Remote queue means a local queue in the counterpart server and we want to send data to it. The remote queue needs to be linked to a transmit queue, so the data can be sent out.
Also, when a new queue is created, the parameter Maximum number of messages should be sufficient. Or when the maximum number is reached, the new coming-in messages will be automatically put into the DEAD LETTER QUEUE.¬† Therefore, the dead letter queue should be monitored when MQ is applied.
The best practice for developing MQ application is to separate the business logic with the MQ operations. This implies business logic and MQ operations are managed in different components. ¬†Thus the MQ operation components can be reused by other components.
The above diagram describes the process applying MQ.¬† On Server 1 we assume 3 applications access the same MQ queue. On server 2 there is a message monitor program to checking if there is a coming-in message. And the monitor program relays the message to the application program if a message exists. Then the application program returns the process result to server 1 by sending a message to a MQ queue.¬† This is a little complex application scenario.¬† Usually we do not have that complexity: on Server 1 there is only one application using MQ queue. On Server 2 there is no message monitor. An application program retrieve message by scheduling. And even there is no reply but just sending data in one direction.
MQ middleware provides some APIs. Application program apply MQ by calling these APIs. These APIs are defined in MQ user manual.¬† From the below APIs we can see that the most APIs are same for sending data and receiving data. The only difference is that sending data needs API MQPUT, while getting data needs API MQGET. ¬†When we send or get data via MQ, we need to apply all the 5 APIs sequentially in the left column or the right column to complete one operation on an MQ queue.
There are a lot of parameters used in MQ APIs. In every API, there is completion code and Reason code. Completion code is used to show if the API call is complete. Reason code is to show the error reason if the API call fails. Get message options are used to show what operations are taken when getting a message. For an example, when reading a message, if there is not a message, it we wait; if we want to read first or next message etc. Put message options are used to show that operations are taken when sending a message. We often use the combination of the options of MQGET or the combination of the options of MQPUT.
We list some frequently used parameters here.
Get Message Options
Put Message Options