Product Architecture

Product Architecture

Product Architecture

Product Architecture

Evolution of T24
T24 was previously called GLOBUS. The very early implementations of GLOBUS had
a simple client-server architecture. The database that was used was IBM
uniVerse. Prior to this, PRIMOS operating system was used.
1. In a typical client-server architecture, GLOBUS and uniVerse were installed on
one Server called the Application Server.
2. In this type of an architecture, the client PCs had to use a terminal emulation
software to access GLOBUS. A terminal emulation software allows users access
to a text terminal and all its applications such as command line interfaces (CLI)
and text user interface applications through telnet, ssh, or dial-up. There are lot of
terminal emulation software available like putty, reflection etc. All client machines
connected to the GLOBUS Server using telnet protocol.
3. uniVerse Database had a 2GB limitation i.e. Files that were larger than 2GB in
size became corrupted. Big files had to therefore be split into smaller files. Hence,
we moved on to support other Databases. In the current times, T24 can store data
in any database like oracle, db2, etc with the help of drivers. T24 also supports
various operating systems and can now be accessed from a internet based
browser.

Product Architecture

What you see here are sample screens of the Character User Interface, Globus
desktop and Browser
The character User Interface is also called Classic. This interface was used in the
initial stages, but you can still work with the Character User Interface of T24.
From 1995, GLOBUS moved away from its classic user front end to a GUI based front
end. The GUI based front end was called the GLOBUS Desktop. It was a client
software written in Visual Basic. In this architecture GLOBUS with its database
universe or jBASE used to exist on a server along (with the operating system Windows
or Unix). The GLOBUS Desktop had to be installed on all client machines and
connected to the server via a telnet connection. jBASE also supported a socket
connection to the server. It should be noted that the GLOBUS Desktop was a thin
client that needed to be deployed on all client machines and did not hold any business
logic.
You must remember that R7 and above do not have support for Globus Desktop. You
should either use the Classic Interface or a web browser to access T24.

Product Architecture

T24 stands for Temenos 24, with the 24 denoting the availability of the system 24x7,
as against other banking systems which typically were not available during end of day
processing. The current T24 system follows a multi-tiered architecture as depicted
here.
1. The client software used to access T24 can be any T24 Browser compliant
browser. You can use Internet Explorer, Mozilla Firefox etc as a client.
2. Any request which flows from the browser cannot be handled directly by the T24
Application Server. Therefore there needs to be some way of connection between
these two tiers. A Web server or an application server forms the second tier.
Standard J2EE Application servers such a Jboss, WebSphere and WebLogic are
used in this tier. They host Temenos components for displaying the web page on
the browser and connecting to the T24 application server. This tier receives
requests from the browser and passes it onto the T24 Application server.
3. The third tier consists of the T24 Application Server where the business
processing is carried out. This receives requests from the Application Server,
processes it and sends back a response.
4. The Database tier stores all the T24 data. Database servers such as jBase,
Oracle, SQL Server or DB2 can be used.
So how do these tiers work together? Lets say a user in a bank wants to update an
account.
1. The account details are displayed in the form of a web page on the web browser.
The user updates the account details and submits the page
2. The page is sent to the Application server as a web request. The application

Product Architecture

server takes the account details alone from the page and sends a request to the T24
server to update the account
3. The T24 server receives the request, and carries out the process to update the account.
On completion, it writes the data onto the database and sends a response back to the
application server.
4. The application server forms a web page using this information
5. The web page ie the response is displayed on the browser

Product Architecture

Temenos T24 is based on open standards. This means that clients can select the best
vendor or environment to suit their needs whether this is because of low cost, high
performance, local support or any other factor.
If this changes in the future, they can switch vendor without altering their investment in
TEMENOS T24.
This will provide true longevity to their chosen system.
T24 can run on jBase or on Oracle database or a variety of other database also.
Clients can choose a database they are comfortable with.

Large banks have also been concerned about scalability and also resilience of the
software. T24 has been able to address these concerns by an architecture which
provides for multiple application/database servers at various levels. Additional
processing capacity can be added by simply adding more servers. The architecture
also ensures that there is no single point of failure.
Thus, T24 is flexible through out. A Bank can buy only those business applications
they currently need. As it enters into new fields, for example a retail Bank decides to
enter into Private Banking domain also, it can buy the additional applications and
seamlessly continue its operations.
These business philosophies of scalability and flexibility are built into all facets of T24

Product Architecture

Product Architecture

The application server hosts a web based component which presents the user
interface for different clients. UI components are developed following a java standard
called servlet and are available in the form of a .war file. The standard UI component is
called BrowserWeb (shown here) or T24 Browser.
The UI component makes use of connectivity components to connect to the T24
Application server. The connectivity component deployed in the application layer is
called TOCF RA (Temenos Open Connectivity Framework Resource Adapter). This
adapter is often referred to as jRemote in T24 documentation. Resource Adapter
follows a java standard called JCA (Java Connector Architecture).
The corresponding connectivity component on the T24 Application server is called as
the TAFC Agent or by its older name jbase agent or jAgent in short.
T24 itself runs on top of a run time framework called Temenos Application Framework.
There are 3 different flavours of this runtime framework called TAFC , TAFJ or
TAF.net each representing the underlying stack or framework ie c, java or dotnet.

The runtime framework connects to the database layer using a database driver. For a
TAFC runtime these drivers are developed by Temenos and are called as Direct
Connect Drivers. TAFJ uses the standard java drivers known as JDBC. Note that
TAFC does not require DCD, if the database used is jBase.

Product Architecture

10

T24 Browser is web based interface to T24.

1)

T24 Browser is a java servlet running on a supported J2EE Application

server such as JBoss. It receives an HTTP request from the T24 Browser.
2) This HTTP request is transformed into an XML request by the T24
Browser Servlet and is sent to TOCF RA. The xml standard used is
referred to as Browser XML. It is used by Temenos internally and is not a
public standard.
3) TOCF RA than passes the XML request to the jAgent for processing.
jAgent then invokes a T24 module called OFS.
4) T24 is a message driven system. OFS (Open Financial Services) is the
gate way to T24 through which any message sent to T24 must pass.
5) The request is processed by T24 and the response sent back in the same
manner, ie via OFS. An XML response is generated as a result of the
request.
5) The XML response is then transformed using XSLT into HTML by the T24
Browser Servlet
6) A vanilla dynamic HTML is sent back as a http response to the users
browser

Product Architecture

11

To start T24:
a. Start the application server ie. Jboss in the standard model bank (This already has
the components mentioned previously installed)
Start -> All Programs -> Model Bank R13 -> Application Server start.
b. Start the desired agent T24 Branch, T24 Demo Branch, T24 Internet
c.

Launch the login page and make use of the user credentials to login

Note:

If the requirement is only to work with T24 Browser, then use the T24 lite option
shown above to start the application server. This would be faster , but supports only
T24 Browser.

The corresponding login page is launched automatically when we launch the

agents

T24 jBase Shell is used to start T24 classic.

T24 Installation

12

This sign in page should appear next . You now need to enter the user id and
password to login. On a vanilla Model Bank, this is typically INPUTT and 123456
respectively.

Product Architecture

13

Product Architecture

14

More on these advantages in the following slides.

Product Architecture

15

Let us understand stateless connection with an example. When we are engaged in a

mobile conversation, The speaker at one end, waits for a response, to proceed
further. The speakers at both ends stay connected .
In contrast, a stateless connection is one in which no information is retained by
either sender or receiver. The sender transmits a packet to the receiver and does not
expect an acknowledgment of receipt. The recipient receives the packet without any
prior connection setup. When we send a SMS, the recipient can read the SMS later &
respond at his convenience and the sender does not wait for a response .
Stateless Connection - a physical connection does not exist between the various
layers of the architecture. A stateless connection is one in which no information is
retained by either the sender or receiver. The sender transmits a packet to the receiver
and does not expect an acknowledgment of receipt. The recipient receives the packet
without any prior connection setup. For stateless interactions, it does not matter
whether different requests are processed by different servers. T24 Browser is a
stateless connection.

Product Architecture

16

Resilience: Since there are multiple servers in each layer, there is no single
point failure. There is always a failover mechanism available.

Product Architecture

17

Scalability:
The ability of a system to easily expand or contract its resource pool to accommodate
heavier or lighter loads. Alternatively, the ease with which a system or component can
be modified, added, or removed, to accommodate changing load.
In business terms it simply means the business model that T24 has can scale up its
product to increasing demands more efficiently by adding any number of servers at
any point

Product Architecture

18

To deploy T24 Browser, you must have BrowserWeb.war ( similar to a zip file)
deployed in the application server. For Jboss, this simply means copying to the
deploy folder. Similarly , ARCIB.war, has to be deployed for online banking. The
browser in both instances can be Internet Explorer or Mozilla FireFox.

Product Architecture

19

On the Technology end, T24 has open platform. The application server and the
database can be anything which suits the client requirements. Temenos also supports
Cloud Deployments. Cloud Deployments are a form of web-based tools or applications
that users can access and use through a web browser as if the programs were
installed locally on their own servers, while the business software and data are stored
on servers at a remote location. In some cases, legacy applications are delivered via a
screen-sharing technology, while the computing resources are consolidated at a
remote data center location.

Product Architecture

20

Product Architecture

21

Product Architecture

22

1. FALSE Web Browser like IE , Firefox can be used

2. True
3. True
4. False In the Jboss Application Server
5. True
6. True

Product Architecture

23

Product Architecture

24

Product Architecture

25