1. Evolution and Architecture of T24

Welcome to Evolution of T24’s Architecture learning unit. In this unit, you will learn how T24’s architecture has evolved over the years.

GEN1-Evolution And Architecture Of T24-R10.01

1

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


2

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

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.


8

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


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


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.


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


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


40


41

1. Evolution and Architecture of T24

Recommend Documents