Welcome to Evolution of T24s Architecture learning unit.

In this unit, you will learn how

T24s architecture has evolved over the years.

GEN1-Evolution And Architecture Of T24-R10.01

After completing this learning unit, you will be able to:

1. Describe the changes to T24 Architecture
2. Identify the components of the T24 multi-tier architecture
2.1 Client Layer
2.2 Application Server Layer
2.3 T24 Application Server Layer
2.4Database Server Layer

3. Analyze the optional components of the T24 multi-tier architecture

3.1 Network Dispatcher
3.2 Message Queuing software

GEN1-Evolution And Architecture Of T24-R10.01

T24s architecture has undergone major changes so far. You will now learn about
how these changes came into being. What you see here is a very simple T24
architecture. T24 was previously called as GLOBUS. The very early
implementations of GLOBUS had a simple client-server architecture. The database
that was used previously was uniVerse. It is an IBMs product.
1. In a typical client-server architecture, GLOBUS and uniVerse was installed on one
Server called the Application Server.

2. In this type of an architecture, the clients PCs had to use a terminal emulation
software to access GLOBUS. A terminal emulation software will allow the 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.
3. All client machines connect to the GLOBUS Server using a telnet protocol

GEN1-Evolution And Architecture Of T24-R10.01

What you see here are sample screens of the Character User Interface. This character
User Interface is also called as Classic. Though this type of an architecture was used in
the initial stages, this architecture is not completely washed away, you can still work with
the Character User Interface of T24.
1. This is the sign on screen where a user can provide username and password to
login.
2. This is the first screen that a user will see after login, the initial screen might differ
depending upon the user profile settings of the logged in user. What you see here is
the Application prompt.
3. This is a sample application screen.

GEN1-Evolution And Architecture Of T24-R10.01

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 too 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.

GEN1-Evolution And Architecture Of T24-R10.01

What you see here are sample screens of the Graphical User Interface, Globus
Desktop.
1. This is the sign on screen
2. This is a sample Application screen
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.

GEN1-Evolution And Architecture Of T24-R10.01

T24s architecture changed drastically from release R04 . A web browser software like
IE or Mozilla Firefox can now be used as the User Interface. This change, introduced a
lot of new layers to the T24s architecture. From release R4 onwards, Globus was
renamed as T24 due to its massive improvement in the technology front. T24 stands for
Temenos 24. 24 denoted 24 hour non stop processing. Along this time, T24 started
working on a front end known as T24 Browser. T24 Browser is an Intranet based
browser solution, which was initially designed as an accompaniment to the existing
GLOBUS Desktop software. It was not a replacement for Desktop then, but rather a
complementary product that offers basic functionality like contract capture and enquiries,
needed for large-scale implementations - without the need to install software on client
PCs. Now, T24 Browser is the standard front end for T24. With the advent of T24
Browser, there will exist many layers in the T24 technical architecture. These layers are
built in for resilience so that there is no single point of failure henceforth.
What you see here is a simple architecture drawn to understand the advent of T24
Browser
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. This has to be
installed on all client PCs

2.

The Web Server layer can hold one or more web servers. A Web Server will serve
the client. Any request coming from a client will be processed by the Web Server.
The Web Server receives the request from the client and forwards it to the T24
Application Server. It also sends back the processed response to the client.

3.

Like the Web Server Layer, the T24 Application Server Layer can have one or more
T24 Application Servers. It will receive the requests from the Web Server, processes
it and sends back a response to the Web Server. Each of the T24 Application Server
will have jBASE installed because it provides the run-time for T24

GEN1-Evolution And Architecture Of T24-R10.01

4. The Database Server Layer is where all the T24 data is stored.

GEN1-Evolution And Architecture Of T24-R10.01

What you see here are sample T24 Browser Screens.

1. This is the T24 Sign on screen for a client accessing T24 via a Web Browser.
2. This is the home page for the logged in user, this might differ from user to user,
depending upon the User profile settings.
3. This a sample Application screen.

GEN1-Evolution And Architecture Of T24-R10.01

You will now be introduced to the new changes in T24 architecture.

GEN1-Evolution And Architecture Of T24-R10.01

Before you get to know the new architecture, it is important to understand the new
terminologies introduced. You will have a brief introduction about the following
terminologies used,

1. JCA
2. Application Server
3. Resource Adapter
4. Enterprise Java Bean
4.1 Message Driven Bean
5. JNDI

GEN1-Evolution And Architecture Of T24-R10.01

10

1,2 Java Connector architecture is a Java based technology for connecting application
servers to different information systems including relational databases
3. JCA is a more generic architecture for connecting to Enterprise Information
Systems(including databases).
4. JCA will be an alternative connection method to the existing TCServer because it
does not depend on proprietary connection methods.

GEN1-Evolution And Architecture Of T24-R10.01

11

1. Application server exposes business logic and business processes for use by thirdparty applications. Application server can be used to serve application programs,
generally in a n-tier architecture through interfaces.
2. Application servers can host applications that respond to requests, perform business
logic, and coordinate updates to shared data. It is primarily a deployment environment.
3. Generally, all application servers contain a web server in them or you can say that a
web server is a small subset of what comprises of an application server. Generally, all
application server comes with two types of containers:
Web Container
EJB(Enterprise JavaBeans) Container
4. JBoss, Weblogic and WebSphere are some of the popular application servers

GEN1-Evolution And Architecture Of T24-R10.01

12

1. Resource adapters allow external systems to link to the J2EE platform. To enable
seamless integration with an application server, a resource adapter must abide by
guidelines that are defined by JCA. A resource adapter is a J2EE component that
implements JCA for a specific enterprise application.
2. A resource adapter is a system-level software driver that a Java application uses to
connect to an enterprise information system (EIS).
3. A resource adapter is an archive file format defined in the JCA specification. It is
similar to a JDBC driver. Both provide a standard API through which an
application(T24) can access a resource that is outside the J2EE server.
4. Resource adapters can also be referred as connectors. A resource adapter plugs into
an application server and provides connectivity between the EIS, the application
server, and the enterprise application.

GEN1-Evolution And Architecture Of T24-R10.01

13

1. Enterprise Java Beans or EJB for short is the server-side component architecture for
the Java 2 Platform, Enterprise Edition (J2EE)
2. EJB is a server-side model that encapsulates the business logic of an application.
3. The EJB specification intends to provide a standard way to implement the back-end
'business' code typically found in enterprise applications . These server side
components provide remote services to clients distributed throughout the network.
4. Enterprise Java Beans are software components that run in a special environment
called EJB container. The container hosts and manages an enterprise bean in the same
manner that the Java web server hosts a servlet. An enterprise bean cannot function
outside of an EJB container.
5. There are 3 types of EJBs Session beans, Entity beans and Message driven beans

GEN1-Evolution And Architecture Of T24-R10.01

14

1. Message driven beans are the light weight components used for communication
2. Message Driven Beans or MDB is an enterprise bean that allows J2EE applications
to process messages asynchronously
3. MDB acts as a JCA message listener
4. The messages may be sent by any J2EE component an application client , or a
web component or by non-J2EE applications

GEN1-Evolution And Architecture Of T24-R10.01

15

1. Java Naming and Directory Interface is an application programming interface (API)

that provides naming and directory functionality to applications written using Java.
2. A naming service helps you to associate names with distributed objects and devices
so that they can be located on the network using simple names instead of cryptic
network addresses. An example of a naming service is the DNS, which converts an
Internet hostname like www.oreilly.com into a network address that browsers use to
connect to web servers.

3,4 JNDI allows you to look up for naming service and obtain references to data files and
devices. Using JNDI, clients can browse a naming service and obtain references to
data files and devices, without knowing the details of the naming service or how it is
implemented. Often the access to the data files and devices are obtained using a
URL, which points to the physical location of the data files and devices.

GEN1-Evolution And Architecture Of T24-R10.01

16

The R09 architecture has introduced new changes in T24 architecture. A web browser
software like IE or Mozilla Firefox can now be used as the User Interface. Let us look
into changes in each layer of this architecture,
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. This has to be
installed on all client PCs
2. The next Layer is an application server. Now why do we need an application server
instead of a web server? A web server receives HTTP requests and responds with
HTTP response. The delegation model of a web server is fairly simple, it just hands
over the request to an application best able to handle it. The web server does not
support transaction or database connection pooling features. On the other hand, an
application server provides access to the business logic for use by client application
programs. An application server provides more features than a web server. For
example Load Balancing, Deployment API, connection pooling and so on.
3. T24 application server receives the requests and processes it. It sends back a
response to the other application Server.
4. The Database Server Layer is where all the T24 data is stored. T24 is database
independent.

GEN1-Evolution And Architecture Of T24-R10.01

17

The T24 application server with jBASE runtime environment is known as TAFC.

GEN1-Evolution And Architecture Of T24-R10.01

18

The T24 application server with java runtime environment is known as TAFJ.

GEN1-Evolution And Architecture Of T24-R10.01

19

Temenos has introduced two different architectures with GA R09.00 The agent
architecture and the JMS architecture.

GEN1-Evolution And Architecture Of T24-R10.01

20

Let us first discuss about the agent architecture:

AGENT allows the T24 Browser to connect directly to T24 using the TAFC JCA
(currently called jremote) and the jbase_agent .
Lets now look into the components of TAFC:
Jremote The T24 Browser sends requests to T24 using jremote. TAFC JCA
is distributed as jremote. Jremote is the client side jBASE component that sends
requests to T24. Lets now see which component handles the incoming requests.
jbase_agent Jremote communicates to T24 using the jbase_agent. Jbase_agent is a
server-side jBASE component responsible for accepting and processing incoming client
requests. This executable is the process you will see running on the T24 server for each
connection the application server has created. Communication is established via TCP
socket connections. Jbase_agent is a socket server listening on a user-defined TCP port
and has the capability to serve a wide range of client applications.

GEN1-Evolution And Architecture Of T24-R10.01

21

You will understand the features of a browser in detail as you proceed. Now you will look
have an overview of the features.
1. Stateless Connection is 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 which is not the
case in a stateful interaction
2. Resilience: Being Resilient the system has the ability to provide and maintain an
acceptable level of service in the face of various faults and challenges to normal
operation. Since there are multiple servers in each layer, there is no single point
failure. There is always a failover mechanism available.
3. Scalability: T24 has the ability to handle growing amounts of work in a graceful
manner. 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

GEN1-Evolution And Architecture Of T24-R10.01

22

You will now try to understand the different layers of the agent architecture
1. Client
1.1 Web Browser
2. Application Server Layer
2.1 Application Server Software
2.1 T24 Browser Servlet
2.3 jremote
3. T24 Application Server Layer

3.1 jbase agent

3.2 T24 Runtime TAFC
3.3 Direct Connect Drivers
4. Database Server Layer
4.1 Oracle / DB2 / SQL

GEN1-Evolution And Architecture Of T24-R10.01

23

1. In the current T24 architecture, to access T24, a web browser needs to be used.
This is the front end that the client PCs will be using to access T24. All that the user
needs to do is to supply a url that will enable the user to connect to T24.
1.1 It forms the top most layer of the T24 architecture.
1.2 The Standard web browsers that T24 supports are Internet Explorer and
Mozilla Firefox
Since the front end is a web browser, no special software installation or
configuration needs to be done on the client PCs. All that is required is a
web browser to be installed, and nowadays all the operating systems are
shipped with the web browser. Now isnt this called Ease Of Deployment!

GEN1-Evolution And Architecture Of T24-R10.01

24

The next layer that you will learn about is the Application Server Layer. The application
server will consist of three main components, first, an application server software,
second, a T24 Browser and third, jremote. You will first understand what an application
server is.
An application server is a server that hosts an API to expose business logic and
business processes for use by third-party applications. It provides access to the
business logic for use by client application programs. An application server provides
more features than a web server. For example, Load Balancing, Deployment API,
connection pooling and so on. You can use application servers like JBoss, IBM
Websphere Application Server or Web logic server.

GEN1-Evolution And Architecture Of T24-R10.01

25

The Temenos Browser component supplied by Temenos is shipped as

a .war file, which contains the T24 Browser logic. It transforms the incoming HTTP
request into a BROWSER XML request. Passes on the request to jremote.

GEN1-Evolution And Architecture Of T24-R10.01

26

jremote, as the name suggests is the client component that sits on the
Application Server. Jremote is the resource adapter that enables T24Browser to
communicate with the T24 Application Server. The main job of jremote will be to
forward the request to the T24 Application Server.

GEN1-Evolution And Architecture Of T24-R10.01

27

T24 Application Server Layer can have more than one T24 Server.
1. Jremote communicates to T24 using the jbase_agent. Jbase_agent is a server-side
jBASE component responsible for accepting and processing incoming client
requests. This executable is the process you will see running on the T24 server for
each connection the application server has created. Communication is established
via TCP socket connections. Jbase_agent is a socket server listening on a userdefined TCP port and has the capability to serve a wide range of client applications.
A request coming from the jremote is sent to the jbase agent.

GEN1-Evolution And Architecture Of T24-R10.01

28

T24, here refers to the T24s business logic. T24 comes with an OFS module. OFS
stands for Open Financial Services. If any other system had to interact with T24, then it
has to happen only though OFS. OFS works on Request Response based approach.

GEN1-Evolution And Architecture Of T24-R10.01

29

Temenos Application Framework (TAF) provides connectivity to T24. TAFC is the jbase
runtime environment that is used.

GEN1-Evolution And Architecture Of T24-R10.01

30

Direct Connect Drivers are used to communicate with external databases such as
Oracle, DB2, SQL Server. This driver is not required when the database used is jBASE.
It converts all T24 requests into SQL/DML/DDL statements and sends it to the external
database. Performs the vice versa for responses. It needs to be installed on each of the
T24 application servers. It contains the database details of the external database such
as Database name, User name and password (encrypted) to log on to the external
database, Schema name, Table space name, Role name etc. (When Oracle is used).It
establishes connection to the external database residing on the database server.

GEN1-Evolution And Architecture Of T24-R10.01

31

Database Server
T24 is database independent, and supports several different databases, including
Oracle,DB2,SQL Server. It is in this database server that Oracle/DB2/SQL ServerJ4 is
installed. This is where the T24 data will reside in XML format. Oracle/DB2 databases
support clustering and therefore a single Oracle/DB2 installation can be done across
multiple servers. Jbase 4 releases prior to 1.5 do not support clustering and therefore
only one database server can be used if Jbase 4 releases prior to 1.5 are being used

1. The Database Server layer holds all the data. Multiple database servers are used
for resilience. When a database supports clustering, multiple database servers can
be used, otherwise only one database can be used. Clustering is a concept where
multiple copies of the same database is maintained, where if one fails, the other
copy can take replace it. jBASE release1.5 and above supports clustering.
2. Oracle, DB2, SQL Server or jBASE can be used as the database
3. Oracle RAC installation is done for support of multiple servers and data stored in a
Storage Area Network Disk

GEN1-Evolution And Architecture Of T24-R10.01

32

T24 can handle three types of message formats.

1.

Browser XML: This message format can be used only when the T24 Browser is
used. It is not a published format, so external interfaces cannot use this message
format to interact with T24.

2.

OFSML: It is a published format. Any external interface that wants to interact with
T24 can use this.

3.

OFS: It is the native T24 message format. It is available for the external interfaces
to use. As it is a native message format, an OFS message can be sent directly to
T24.

GEN1-Evolution And Architecture Of T24-R10.01

33

1. From the web browser to the App Server the message is sent as a HTTP Request.
2. T24 Browser transforms HTTP request to Browser XML request.
3. jremote sends the Browser XML request to jbase agent, jbase agent sends the
Browser XML request to T24. Finally T24 processes the request
4. T24 builds BROWSER XML response and passes it on to jbase agent and jbase
agent sends the response to jremote
5. jbase agent sends the Browser XML response to jremote, jremote sends the
Browser XML response to T24 Browser
6. T24 Browser converts the Browser XML response to a HTTP response

GEN1-Evolution And Architecture Of T24-R10.01

34

Lets now have a look at the JMS architecture.

Java Messaging Service is a feature provided by J2EE application servers like JBoss,
WebSphere and Weblogic. The JMS architecture is introduced for enhanced resilience
and reliable message processing.
Let us first look into the components of JMS architecture :
1. T24 BrowserServlet
2. OFSMessageMDB The OFSMessageMDB can be found inside the tocfee.ear file.
3. TAFC JCA jremote
3. jbase_agent

An Enterprise ARchive, or EAR, is a file format used by Java EE for packaging one or
more modules into a single archive so that the deployment of the various modules onto
an application server happens simultaneously and coherently. It also contains XML files
called deployment descriptors which describe how to deploy the modules.
The following components can be found in tocfee.ear:
1. ofsmessage-ejb.jar
2. tocfcommon.jar

GEN1-Evolution And Architecture Of T24-R10.01

35

3. tocflistener-ejb.jar
4. tocfplugin-ra.rar

GEN1-Evolution And Architecture Of T24-R10.01

35

Lets now see how the requests are handled in the JMS architecture
JMS architecture is mainly introduced for reliable delivery of messages. It makes use of
queue management feature of the J2EE application server. JMS is a specification and
as such it does not have any physical components. IBM or SUN MQ also implements
JMS thus enabling you to use any queues which can be accessed using JMS APIs.
Lets have a brief introduction of the components used in JMS architecture,
Request and Response Queues These queues are configured in the J2EE application
server and they play a major role in processing the messages.
OFSMessageMDB OFSMessageMDB is a message driven bean that acts as a
gateway for other components like T24 Browser. It consumes messages from the
request queue and forwards it to T24 using the TAFC JCA i,e jremote
jremote jremote also known as TAFC JCA is responsible for forwarding the request to
T24.

GEN1-Evolution And Architecture Of T24-R10.01

36

You will now understand how the requests are processed in the JMS architecture,
1. The T24 BrowserServlet drops the request onto the request queue. Also other
external interfaces can drop requests onto the request queue.
2. Once the request is dropped onto the request queue, the OFSMessageMDB will be
triggered. The OFSMessageMDB acts as a listener and it will take the request
dropped onto the request queue.
3. Inorder to process the request it should be forwarded to the T24 application server.
Therefore OFSMessageMDB will forward the request to jremote (TAFC JCA),
because only jremote can communicate to the T24 application server.
4. Jremote communicates to the T24 application server with the help of jbase_agent.
T24 processes the request and the response is forwarded to the jbase_agent.
5. Jbase_agent will hand over the response to jremote
6. The OFSMessageMDB will pick up the response form jremote.
7. The next step is to drop the response in the response queue of the J2EE application
server. This task is done by the OFSMessage MDB
8. Finally the response will be forwarded to the T24BrowserServlet.

GEN1-Evolution And Architecture Of T24-R10.01

37

Prior to R09, requests were sent to the T24 application server with the help of TCServer.
Now the R09 architecture can also be configured to communicate with TCServer. This
feature is provided for backward compatibility. Lets now take a look at the components
that are required for this,
TOCF Plugin - TOCF Plugin resource adapter hosts all TOCF(EE) listeners such as the
BatchFileListener. This resource adapter wraps the existing TCS plugins and allows
custom listeners to be used without any code modifications. This resource adapter
contains the familiar tcserver.xml to define and configure the listener interfaces.
TOCF Listener MDB - TOCF Listener Message Driven Bean is an EJB that is called
when a message arrives on the resource adapter it has been configured to activate. In
R09, this bean is responsible for activating the TOCF listener plugins as defined within
TOCFPlugin-ra.rar. When TOCFPlugin-ra.rar receives a message on any of its listeners
the TOCF Listener MDB will be called upon to perform processing. This processing
involves placing a message onto the OFS request queue and waiting for a response on
the OFS response queue.

Note: From R10 the tocf plugin resource adapter and the tocflistenerMDB are packaged
inside the tocfee.ear file.

GEN1-Evolution And Architecture Of T24-R10.01

38

Network Dispatcher: This is a third party software that can be used to distribute HTTP
requests among the available web servers. In other words, it acts as a load balancing
product. It performs intelligent load balancing by using server availability, capability,
workload, and other user definable criteria to determine which server the TCP/IP request
is sent to. A network dispatcher is generally configured with a backup to eliminate it as a
single point of failure. The advantage that the network dispatcher provides are that
It improves the performance of servers by distributing the incoming TCP/IP requests (
in our case, HTTP requests)

It improves the throughput by enabling multiple servers and CPUs to handle the client
workload

GEN1-Evolution And Architecture Of T24-R10.01

39

In this learning unit, you learnt about the Evolution of T24s architecture
You will now be able to:
1. Describe the changes to T24 Architecture
2. Identify the components of the T24 multi-tier architecture
2.1 Client Layer
2.2 Application Server Layer

2.3 T24 Application Server Layer

2.4Database Server Layer
3. Analyze the optional components of the T24 multi-tier architecture
3.1 Network Dispatcher
3.2 Message Queuing software

GEN1-Evolution And Architecture Of T24-R10.01

40

GEN1-Evolution And Architecture Of T24-R10.01

41