Table of Contents
This chapter describes the internal architecture, system architecture, administration, and directory structure of Tmax.
In a client-server-centric computing environment, an increase in the number of clients has caused problems such as machine diversification, systems running a mixture of different operating systems and databases, data incompatibility, and deterioration of server performance.
Tmax, a transaction processing middleware solution, resolves such problems and provides functions such as process and transaction management, load balancing, resource management in a heterogeneous environment, etc.
-
Process management
Tmax manages server instance (server process) loading, task distribution, and automatic process creation.
-
Transaction management
Tmax ensures the ACID properties of each transaction (Atomicity, Consistency, Isolation, and Durability).
-
Load balancing
– Tmax provides optimal system performance and efficient processing.
-
Heterogeneous resource management
Tmax resolves various problems that arise from integrating heterogeneous platforms/resources.
The Tmax system is made up of nine system operation processes (TMM, TMS, CLL, CLH, RQS, GW, CAS, TLM, and HMS) and four management tools (tmadmin, racd, tmboot, and tmdown).
-
System Operation Processes
-
TMM, the Tmax Manager, manages the overall operations of Tmax. It manages system operation information and CLL, CLH, TMS, and RQS processes as well as various Tmax application processes. TMM is the first component to load when Tmax starts up, and the last to be terminated when Tmax shuts down.
If a Tmax system contains multiple nodes, the TMM on each node maintains session connections with the others to monitor their heartbeats and provide fault tolerance for the server group. TMM is also responsible for logging each process and updating all shared data. TMM ensures normal system operation when a problem occurs that disrupts logging, such as lacking disk space, by temporarily suspending logging until the problem is resolved.
-
CLH, the Client Handler aka the client manager, serves as a mediator between client and server processes. CLH controls data flow by connecting to application server process, gateway, RQ process, and Tmax process. When a service is requested by a client, the CLH forwards the request to the appropriate application server process. Once it receives the results from the application server process, it returns them to the client.
-
TMS (Transaction Management Server)
TMS, Transaction Management Server, is responsible for managing database and distributed transactions. While TMM, CLL, and CLH are critical processes that always gets loaded into memory, the TMS is only responsible for database management and distributed transaction processing. It is implemented by using the database libraries.
-
The RQS, Reliable Queue Server, manages Tmax disk queues. Generally, all data stored within a system is at some level of risk, and the data stored in memory waiting to be processed can be lost in the event of a system failure. The RQS resolves this problem by storing data on the disk before and after service requests to preserve the stored data and resume services when the system is restarted.
The RQS is only loaded when it is specified in the configuration file since an active RQS process can negatively impact the service processing performance.
-
In a Tmax system that consists of multiple domains, the GW (Gateway) handles inter-domain communications. By using communication methods such as TCP/IP, SNA/LU0, SNA/LU6, and X.25, GW can facilitate communication and integration not only between different Tmax domains, but also between Tmax system and various other systems.
Gateways are only loaded when they are specified in the configuration file. The actual name of a process may vary depending on the setting in the configuration file, and some gateways may require settings to be added to or modified in the configuration file. GW is an optional process that runs only when it is specified in the configuration file.
-
TLM (Transaction Log Manager)
TLM, Transaction Log Manager, monitors pending transactions and performs transaction logging, which was previously performed by TMM (earlier than 4.0).
-
HMS (Hybrid Messaging System)
HMS, Hybrid Messaging System, serves as the communication mediator that enables loose coupling between a sender and a receiver. Even though a sender and a receiver do not know each other, the messaging system enables them to communicate with one another with only virtual channel information of the destination. HMS ensures reliability in message transmission in order to allow delayed data processing by providing the ability to distinguish between the time the message is sent and received.
-
-
Management Tools
-
racd (Remote Access Control Daemon)
Racd is a daemon process that runs on each node (machine) in the system. When a Tmax system is comprised of multiple nodes in a single domain (group of nodes that share a single configuration file), racd can be used to enable the central monitoring and management of the entire system and nodes from a single node through tmadmin. It can also be used to ensure that changes in the configuration file are applied to all nodes of the domain without having to copy the file each time.
-
Tmboot is used to start up Tmax using the configuration file. It first loads the system processes, including TMM, CLL, and CLH, and then the RQ, TMS, and GW processes for additional environment configuration, and lastly it loads the application server processes. Tmboot can be used with various options to start Tmax.
-
A domain is the highest modular unit of a Tmax system that uses a single configuration file. Domains can be composed of a single or multiple nodes, which are connected in a peer-to-peer relationship. In a domain with multiple nodes, the nodes communicate with each other at a constant time interval and share configuration information. Thus, all nodes of the domain possess information about all the other nodes and the overall domain status, which means that clients can access all services offered by the domain from any node.
Clients can connect to a particular node of the domain. If possible, a service requested by the client gets processed by the node that the client is connected to. However, if the service is provided by a different node, the node that the client is connected to will forward the request to that node. Once the request has been processed, the result will be returned to the client.
If the requested service is not provided by the node it is connected to, (refer to Figure 1.3.) the request is processed as follows:
The node (Node A), which the client is connected to (1), communicates with the node that provides the service (Node B) to forward the request for processing (2). Node A will then receive the result from Node B (3) and then pass the result back to the client (4).
The following figure is a detailed architecture of Tmax system.
Tmax system can be managed either statically or dynamically.
-
Dynamic management refers to manipulating the system while it is running to perform administrative tasks that may influence the state or performance of a running system, such as starting or shutting down (tmboot/tmdown), management through Tmax administration, or the modification of environment variables.
Static management of the system is done through environment configuration.
The following must be completed before configuring Tmax system.
-
Creating Tmax Configuration File
Before starting a Tmax system or configuring the environment, the configuration file for the system must be created. This is one of the key responsibilities of Tmax administrators. Once created, the Tmax configuration file will contain general information about a single domain that makes up an independent system unit, gateways that provide inter-domain connections or communication with legacy systems, nodes that make up the system, services of each node, server processes that provide services, and the logical groups of servers called a server group.
For more information about creating the configuration file, refer to "Chapter 3. Environment Configuration".
-
Configuration File Compilation
Once the configuration file has been created, it will need to be compiled. If there are no errors in the configuration file, it will be compiled into a binary file. This binary file will be referred to whenever Tmax starts up or shuts down.
-
Service Table Creation
A complete configuration file is required before the service table can be created. The service table informs Tmax about the type and location of services available in the system. The service table should contain a separate table for each service defined in the configuration file. Executable programs must be linked to the service table in order for Tmax to recognize and execute them. The service table is used to compile program source codes written by developers to create server-side application programs.
The following describes how to dynamically manage system operation and system startup and shutdown.
-
Startup and Shutdown
After completing environment configuration, the administrator can start up Tmax. This involves starting various components of the Tmax engine, such as the TMM, CLL, and CLH (as well as TMS if database is involved, and RQS if RQ is involved) processes and the application server processes that will process client requests. It is important to note that normally servers are not started and terminated separately. They are managed by Tmax and are started and terminated when the Tmax engine components are started.
-
System Operation Management
The administrator can monitor the status of each system components while Tmax is running, and take appropriate actions if necessary. Dynamic management of the system is performed through tmadmin, an interactive monitoring program that can be accessed through the console.
-
Information Display
Administrators can use tmadmin commands and options to collect information about clients (names and locations), servers (location, server group, availability, and execution count), server processes (location, status, processing time, execution count, and data backlog) and networking (connected nodes and partitioned nodes), as well as information on transactions and application program parameters.
-
Dynamic Modification of Tmax Configuration
Administrators can dynamically modify Tmax system environment, including adjusting time-out values, priorities and load balancing, restarting dead processes, terminating processes, restarting terminated processes, and adding new services to an active server process.
Caution
Environment variables that are modified during system operation will revert back to the values defined in the configuration file when the system shuts down (tmdown) and is rebooted (tmboot).
-
The following is the basic structure of the Tmax installation directory. This directory will be referred by several environment variables within the configuration file.
$Tmax HOME
|---- appbin
|---- bin
+---- sample
+---- client
+---- server
+---- sdl
+---- fdl
|---- config
|---- lib
|---- license
+---- log
|---- slog
|---- tlog
|---- ulog
|---- path
|---- svct
|---- usrinc
|---- bk_appbin
- $Tmax HOME
-
Tmax parent directory. (System variable: TMAXDIR, Configuration item: TMAXDIR )
- appbin
-
Contains files for activating server processes. (Configuration item: APPDIR)
- bin
-
Contains Tmax commands and utilities.
- sample
-
Contains sample client/server files.
Sub directory Description client Contains sample client program files. server Contains sample server program files. sdl (optional) Contains structure related files. (System variable: SDLFILE) fdl (optional) Contains field key related files. - config
-
Contains configuration files.
- lib
-
Contains Tmax library files.
- license
-
Contains license files.
- log
- path
-
Contains named pipe files for internal communication between processes. (Configuration item: PATHDIR)
- svct
-
Contains service table files.
- usrinc
-
Contains Tmax header files.
- bk_appbin (optional)
-
Contains the new process that is installed to replace the existing server process. (System variable : TMAX_BKAPPDIR)