1. gen1 evolution and architecture of t24-r10.01

GEN1-Evolution And Architecture Of T24-R10.01 1 1

Welcome to Evolution of T24’s Architecture learning unit. In this unit, you will learn how

T24’s architecture has evolved over the years.


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 3

T24’s 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 IBM’s 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

3

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.

4


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.

5


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.

6


T24’s 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 T24’s 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

7


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

7


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.


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

9


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

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.

11


1. Application server exposes business logic and business processes for use by third-

party 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

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.

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

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

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.

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.

17


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

18


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

19


Temenos has introduced two different architectures with GA R09.00 – The agent

architecture and the JMS architecture.

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.

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

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

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 isn’t this called Ease Of Deployment!

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.

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.

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.

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 user-defined 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.

28


T24, here refers to the T24’s 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.

29


Temenos Application Framework (TAF) provides connectivity to T24. TAFC is the jbase

runtime environment that is used.

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.

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

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.


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

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

35


3. tocflistener-ejb.jar

4. tocfplugin-ra.rar

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.

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.

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.

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

39


In this learning unit, you learnt about the Evolution of T24’s 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