About this blog

IBM Messaging blog: Find out all the new and great things that are going on with IBM MQ as well as what our developers are doing and talking about. This blog follows the IBM Social Computing Guidelines.

Tags

Building a simple enterprise application for a payment system (WAS, DB2 and Multi-instance MQ integration)

In this blog post let's examine using Multi-instance WebSphere MQ queue manager for building a typical enterprise system with this improved availability feature. There are several aspects of transactions and request-response that's covered in this blog post.. Hope you enjoy reading :)

Most enterprise applications include messaging systems, application servers and a database systems. Its most common to update database and a messaging system in a transaction context of an EJB running in an application server. Here let's take an example of a payment system.

Use case
Let's consider an example of payment system, where a customer pays for some service he/she uses at a retail outlet. This could even be the electricity bill, telephone or mobile bill. At the back-end let's consider the following sequence of actions:

WebSphere MQ (WMQ) forms the messaging backbone and accepts the request in a particular queue.

The application that puts the requests to the queue waits for the response(or reply) message on another queue for the confirmation

The application server hosting an Message Driven Bean (MDB) receives this message and updates a database and sends a response back to another queue.

This is a typical flow for most of the payment systems. There are several other query and update flows that are required for payment systems which I have ignored.

There are some key error handling scenarios to consider also

If we have only one MQ queue manager on one system there is a chance of system failure

If any one of the actions like updating a data base while writing the reply message back to queue fails due to system issues, everything needs to be rolled back

The system hence requires improved availability for the MQ queue manager and automatic switching to a standby MQ server. Also the applications and the WebSphere Application Server needs to automatically reconnect to the MQ instance. There's another point of failure that's not considered in this blog, its the WAS and DB2 instance. Here is a diagram representing the setup required for this:

Configuring the WebSphere MQ queue manager
We need to setup a Multi-instance WMQ queue manager. The feature provide basic fail-over facility without a separate high availability(HA) coordinator. So two different system with a networked store (like NFS) that can share the queue manager data and logs can host a Multi-instance queue manager. The two instances of a queue manager can start of on different systems, but one has will be an active queue manager and the other passive. The 'active' queue manager as the name says owns the queue manager store files and will accept client connections also. On a fail-over the standby instance comes alive and the clients auto-reconnect to this.

Follow the instructions given here to setup a multi-instance queue manager.

Let's say the queue manager name is MQQM. Create a queue that's persistent for sending the requests, PAYMENT.REQUEST and a reply queue from which we'll get the messages, that is PAYMENT.REPLY. Also create and start a TCP/IP listener, say on port 1414.

Programming the Request-Response JMS application to connect to the Multi-instance queue manager
This is a typical JMS client application which sends the request and waits for a response on the other queue. Here are the points to consider

The messages have to be persistent to avoid any kind of loss

The connection name list containing the IP-addresses and the ports of the active and standby queue managers is required so that the client can auto-reconnect

The correlation ID is required so that the response is matched to request sent.

An appropriate time-out, chosen to wait for the response and also a message expiry of the request equal to the time-out to avoid messages piling up

Configuring a Database containing the customer records
Database forms a crucial part of the solution. Its required for maintaining the customer records. Here we'll be creating a sample database for demonstration purposes. Here are the DB2 commands for the command line processor

This creates a table CUST_ACCOUNT with two fields. Since our focus here in the blog is not get into the specifics of the database we are not defining primary key, etc. We'll be just inserting the records to this table.

Programming a Message Driven Bean in Rational Application Developer
Now let's write an MDB that can connect to this Multi-instance MQ queue manager. Important point here is that at the programming level one need not think about the existence of the Multi-instance queue manager. This will be handled during the configuration of the activation specification.

The application needs to consider the transaction context. WebSphere Application Server (WAS) provides a powerful transaction manager that kicks in and starts a transaction once a message is received from MQ Server in an MDB. Actions like adding/updating the database record, and sending the reply message can be done in the onMessage() implementation. All this will occur in the same transaction. The commit will occur only if all these actions succeed. This greatly simplifies the programming effort. The transaction manager will also ensure the consistency is maintained when the fail-over happens on the Multi-instance queue manager.