Rate this:

Whenever a bank purchases a Core Banking System (CBS) it definitely calculates the TCO of the software and hardware required to run the new CBS.  The cost of software products, of late, has been pegged with the specifications of the server, especially the type of processor being used, and the number of cores in it.  This factor increases the prices of such software manifold if they are being used in a hi-fi environment.  Imagine what a bank like HSBC would have to pay for the licenses of WebSphere MQ, versus what a community bank would pay for the exact same product.  I have observed that this factor has a direct implementation in the way organizations would deploy WebSphere Application Server (WAS), IBM HTTP Server (IHS) and MQ Server (MQ).

In an ideal situation, the web server (IHS) should be separate from WAS.  Since WAS (hosting the Java application) would pass messages to the underlying main application server (like T24), thereby necessitating having MQ installed at WAS and T24 server machines.  Take a look at the image below.

Ideal Implementation: IHS, Firewall, WAS+MQ and T24+MQ

While the IHS-WASMQ-T24MQ installation is ideal, it is expensive: you have to buy MQ licenses; lots of them.  Usually, a middle-ground is sought so that the licensing costs can be rationalized.  The first option is to separate out MQ completely as a new server.  This certainly has its implications in that the messages can still be lost at WAS and T24 servers.  The image below shows this setup.

IHS+WAS, MQ and T24

Another option could be a setup where MQ is installed on the WAS and IHS server.  But in this setup, T24 is still without MQ.

IHS, WAS+MQ, T24

Yet another option is to install IHS, WAS and MQ on the same server.  This means that the server specifications should be sufficient to handle three server applications, especially WAS and MQ.  The newer versions of T24, such as R8 onwards, have extensive front-end developments, which are bound to put pressure on WAS.  Therefore, the server has to be equipped proportionately.

A Good Alternate: IHS+WAS+MQ, and T24+MQ

But as stated earlier in this post, having MQ installed at T24 server would inflate the bill.

I mentioned in a previous MQ related post that if a server/software component goes down, and the timeout setting for the channel (to which that server belongs) is set to the number of seconds during which the server/software component may not recover (such as 180 seconds) then there’s not much that MQ can do to help anyway.  This is because if the server/component becomes operable after the timeout duration, then even if it picks up messages from MQ, they would not be processed as the session would have timed out.

In the end, I would repeat what I mentioned in the beginning of this post: your architecture depends on your budget.  Ideally, MQ should be there whenever information leaves one physical server and enters into another.

Imran Adeel Haider
imran.adeel@gmail.com

This post is also available at www.sapphirecs.net/scsblog/

Advertisement