We know that Temenos T24 has a browser component, which offers the web-based UI for the core banking system. This component connects to the core through a module called TC Client, which is installed as a Java WAR file on the web server (the web server is typically IBM WebSphere Application Server). On the server side, there is a component that acts as T24’s window to the outside world, called TC Server, which is installed on the T24 Application Server. To facilitate message passing between the server and web browser, there is a queuing server in between (which is typically IBM WebSphere MQ Server).
By design, Temenos T24 doesn’t actually need an MQ server. One would rather need MQ for guaranteed message delivery from the browser/TC Client to TC Server. I have seen a bank run T24 without having MQ at all. This is so because TC Client can talk to TC Server via TCP/IP as well. The downside of having this arrangement is that there is no message persistence, and in case of a disaster, the server may not receive a request, or a client may not receive a response at all. The sample Channels.xml file that comes with TC Server has (by default) enabled TCP based channels between TC Client and TC Server.
As long as a bank is willing to take this risk, it is ok to not use MQ Server at all.
But then, things are not as simple in real world. I’ll explain that in detail in the next entry.