Product Architecture
1
Product Architecture
2
Product Architecture
3
Product Architecture
4
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
5
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
6
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 W eb 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? Let’s 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
7
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
7
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
8
Product Architecture
9
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 it’s 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 user’s 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 s t a t e l es s c o n n e c t i o n 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
