Introduction to Tmax
This chapter describes the Tmax concepts, its architecture, features, characteristics, and issues.
1. Overview
Tmax stands for Transaction Maximization, which means the maximization of the transaction handling ability. Tmax is a TP-Monitor product that handles transactions (for heterogeneous systems in a distributed environment), distributes loads, and takes a proper action when an error occurs.
Tmax provides an efficient development environment with optimized solutions used in the client/server environment. It also improves performance and handles all failures.
Tmax complies with the X/Open DTP (Distributed Transaction Processing) model, the international standard for distributed transaction processing. Tmax was developed to meet the API, services, and X/Open model transaction model components standards created by the international standard organization OSI (Open Systems Interconnection group). Tmax transparently handles the applications of heterogeneous systems in a distributed environment. It also supports OLTP (On-Line Transaction Processing) and meets ACID (Atomic, Consistent, Isolated, Durable: Transaction Properties) for transaction processing.
Tmax dramatically enhances performance by transparently handling applications. Tmax also provides an efficient development environment for creating new applications by facilitating the processing of mission-critical legacy applications. In all industries, Tmax guarantees system reliability by controlling loads and preventing failure in critical systems in which large numbers of transactions are handled. It can be utilized to develop large-scale OLTP applications and used in various industries (for example, airlines, hotels, hospitals, and banks) and businesses (for example, online jobs, credit card approval, and customer and sales management).
|
For more information about transactions, refer to Transactions in Tmax Application Development Guide. |
2. Architecture of Tmax
This section describes the system configuration and features.
2.1. System Configuration
The following figure shows the system configuration of Tmax.
-
Tmax Manager (TMM)
A core process that operates and manages the Tmax system. TMM manages all shared information in the Tmax system and the following server processes: Client Listener (CLL), Client Handler (CLH), Transaction Management Server (TMS), and Application Program (AP).
The following are the major features of TMM:
Major Feature Description Shared memory allocation
When configured environment information is compiled with the cfl command, a binary file is created. TMM loads the binary file into shared memory and manages the Tmax system using the loaded information.
Process management
TMM is the main process for the operation and termination of all systems.
Log management
TMM manages Tmax system logs (slog) and user logs (ulog).
-
Client Listener (CLL)
A process for the connection between clients and Tmax. It receives requests from clients by setting PORT Listener for managing client connections.
-
Client Handler (CLH)
Mediates between clients and servers, requests a service from a server that handles tasks, connects to a server, and manages the connection.
Delivers requests from clients through a function (for example, tpcall) to a proper server, and transmits requests for XID numbering and commit/rollback in the XA service environment.
-
Transaction Management Server (TMS)
Manages databases and handles transactions while operating in a database-related system. Delivers commit/rollback requests of XA services to the Resource Manager (RM).
-
Transaction Log Manager (TLM)
Saves transaction logs in tlog before CLH commits when a transaction occurs.
-
Reliable Queue Server (RQS)
Manages the disk queue of the Tmax system and executes reads/writes from/to a file.
-
Gateway Process (GW)
Handles inter-domain communication in the environment in which multiple domains exist.
-
Tmax Administrator (Tmadmin)
Monitors Tmax-related information and manages changes in the configuration file.
-
Remote Access Control Daemon (RACD)
Remotely controls all domains in which Tmax is installed.
-
Tmax Control Server (TCS)
Handles business logic at the request of CLH and returns the results.
-
User Control Server (UCS)
Handles business logic at the request of CLH and returns the results. A corresponding process maintains control.
-
Tmax Information Provider (TIP)
Checks system environment and statistics information, and operates and manages the system. (boot/down only)
The following figure shows the services performed by the Tmax system.
The following describes how Tmax system performs a service:
-
When a client executes tpstart, the CLL process handles the connection request to connect to the CLH process.
-
If there is a service request, CLH handles all services.
-
CLH receives a client service request (tpcall), analyzes the service, and maps the service to the proper business server process (svr2).
-
The business server process (svr2) handles the service and then returns the result (tpreturn) to CLH.
-
CLH receives the result and sends it to the client.
2.2. TIM
Tmax Information MAP (TIM) is core information required to operate the Tmax system. TIM is created by the TMM process, and located in the shared memory managed by Tmax.
TIM can be divided into the following according to the role:
-
Information for setting the Tmax system
Loaded to shared memory and referred to if necessary to manage <tmconfig.m>, the Tmax configuration file.
-
Information for operating the Tmax system
Manages information to operate the Tmax system. The information includes the following: how to respond to a failure that occurs in the system, base information for load balancing, naming service information to access each service if a system consists of multiple pieces of equipment, and application location.
-
Information for application status
Manages the status (Ready, Not Ready, Running, etc.) of application processes loaded in a system.
-
Information for distributed transactions
Manages information for operating a database that mediates communication with RM, and manages numbering information for transaction processes.
2.3. Socket Communication
Tmax uses the UNIX domain socket communication method. This method uses the socket API without any changes, and enables communication between processes by using a file. It is more stable and faster than an external communication method based on ports. Both this method and FIFO (Named Pipe) use a file and manage messages from kernels. However, the socket communication method has a two-way communication feature and unlike FIFO, it is easy to build multiple client/server environments.
The following figure shows the process of UNIX domain socket communication of CLL, CLH, and TLM. The application server (PSR) connects to CLL, CLH, and TLM.
3. Features of Tmax
Tmax has the following features:
-
Process management
To provide an optimized environment, Tmax adjusts the number of the server’s application handling processes created for each client. Tmax provides a 3-tier based client/server environment.
-
Transaction management
Tmax guarantees data integrity by supporting Two-Phase Commit for distributed transactions. Tmax also facilitates the use of global transactions by providing simple functions such as tx_begin, tx_commit and tx_rollback. It also improves efficiency with the transaction manager that uses multi threads, and guarantees stability with recovery/rollback by rapidly responding to errors with dynamic logging. Transactions can be easily scheduled and managed because all transactions are centrally managed.
-
Load balancing
Tmax provides the load balancing feature with the following 3 methods to increase throughput and reduce handling time.
-
System Load Management (SLM)
-
Data Dependent Routing (DDR)
-
Dynamic Load Management (DLM)
-
-
Failure handling
Tmax can operate normally by using failover through load balancing and service backup even when a hardware failure occurs. Even if a software failure occurs due to a down server process, services are provided continuously.
-
Naming service
Naming service provides service location information in distributed systems by providing transparency and a name for easy service calls.
-
Process control
Tmax provides three methods of data transmission processes. For more information, refer to Process Control.
-
Tmax Control Server (TCS)
-
User Control Server (UCS)
-
Processing On Demand (POD)
-
-
Reliable Queue (RQ) feature
Data is maintained and reliably handled with a disk queue that prevents requests from disappearing due to a failure.
-
Security feature
Tmax provides a data protection feature based on the Diffie-Hellman algorithm, supports the following 3-step security feature, and includes the UNIX security feature.
-
Step 1: System connection authentication
A unique password is set for the entire Tmax system (domain). Only clients who registered the password can connect to the Tmax system.
-
Step 2: User authentication
Tmax services can be used with user IDs that are registered in the Tmax system after authentication.
-
Step 3: Service access authentication
Services that require special security can be used by users who have the corresponding privileges. Tmax 4.0 and later versions support this.
For more information about security, refer to Security System in Tmax Application Development Guide.
-
-
Convenient API and various communication methods
Tmax supports the following communication methods: Synchronous communication, Asynchronous communication, Conversational communication, Request Forwarding, Notify, and Broadcasting. Tmax provides a convenient API for these methods.
-
System and resource management
-
The following statuses of the entire system can be monitored: process status, service queuing status, the number of handled services, and the average time of handling a service. System status and queue management system statistics can be analyzed, and a report can be created.
-
Resources are efficiently managed because applications and databases are integrated and managed.
-
-
Multiple domains and various gateway services
Remote distributed systems can exchange data; heterogeneous platform based systems can be easily integrated; and various gateway modules, such as SNA CICS, SNA IMS, TCP CICS, TCP IMS, and OSI TP, are supported. It is possible to handle a transaction service and route to multiple domains.
-
Various client agents
Tmax provides various agents to easily change a 2-tier system into a 3-tier system.
Classification Description Raw Client Agent (RCA)
Supports multiple ports that efficiently handle processes with the multi-threading method.
Simple Client Agent (SCA)
Supports multiple ports that can handle both non-Tmax and Tmax clients.
-
Various development methods
Classification Description Real Data Processor (RDP)
Supports direct data delivery using UDP communication data, not via the Tmax system.
Window control
Handles concurrent bundled data by providing the WinTmax library, the client library for multiple windows settings.
-
Extensibility
-
Integration with the web
If the client/server environment and the web environment are integrated using Java Applet/Servlet, PHP, etc., response time can be decreased and system performance can improve. For the service integration, Tmax provides WebT. For more information about WebT, refer to Tmax WebT User Guide.
-
Integration with mainframe
Host-link enables access to application services in a legacy system, such as IBM mainframe, like those in the client/server environment.
-
Easy to change other middleware
Systems developed with other middleware, such as Tuxedo, TopEnd, and Entera, can be easily integrated with Tmax without any changes to the source code. This easy integration can improve performance, provide high level technical support, and reduce costs.
-
3.1. Process Management
The existing 2-tier client/server environment is the most general environment for developing applications. A single server process is created for a single client in this environment. As the number of clients increases, the number of server processes also increases. For this reason, it takes a long time to create processes and to open/close files and databases. Furthermore, since a server can be used only by a client who is connected to the server, usage of a server process is very low and the maintenance cost is very high.
The 3-tier client/server structure using TP-Monitor is adopted to solve the problems. Tmax, the TP-Monitor product, enables a system to be optimized and operated as it adjusts the number of created processes, schedules idle server processes, and tunes server processes.
The following figure shows the 2-tier client/server structure:
The following figure shows the 3-tier client/server structure:
Better systems can be built in the 3-tier environment compared to the 2-tier environment in terms of performance, extensibility, management, and failover.
The following are comparisons of 2-tier and 3-tier client/server environments.
-
Application
2-tier Environment 3-tier Environment -
Unit business of a small scale department
-
A single server
-
Small number of users (less than 50)
-
Batch applications
-
Enterprise business
-
Multiple servers
-
Large number of users (50 or more)
-
OLTP applications and large number of transactions
-
-
Advantages
2-tier Environment 3-tier Environment -
Short program development period (easy to test)
-
Low initial adoption cost
-
Easy to develop simple programs
-
Modularization for application development
-
Integration is possible in heterogeneous hardware and in a database environment.
-
Improved performance by making the best use of system resources
-
Easy expansion
-
Can implement security features including system management, load balancing, and failover
-
-
Disadvantages
2-tier Environment 3-tier Environment -
Dramatically lower performance as the number of transactions increases
-
Integration is impossible in heterogeneous platforms and in a database environment
-
Difficult to be expand
-
Impossible to implement the security feature including system management, load balancing, and failover
-
Long application development periods (client/server integration test)
-
High initial adoption cost
-
A program must be separately developed for a client and a server even if the program is simple
-
3.2. Distributed Transaction
A transaction utilizes various resources by handling a single logical unit and maintains data integrity among distributed resources. A distributed transaction is a transaction among distributed systems in the network, and it must be meet the ACID (Atomicity, Consistency, Isolation, Durability) transaction properties. The Tmax system guarantees ACID for distributed transactions in heterogeneous DBMSs and multiple homogeneous DBMSs.
| Classification | Description |
|---|---|
Atomicity |
All-or-nothing proposition. All work in a transaction is performed, or nothing is performed. |
Consistency |
The successful result of a transaction must be maintained in a consistent status in shared resources. |
Isolation |
While a transaction is performed, another operation cannot be performed for the transaction. The result cannot be shared before it is committed. |
Durability |
The result of a transaction is always maintained after it is committed. |
Tmax manages distributed transactions and complies with the X/Open DTP model that consists of Application Program (AP), Transaction Manager (TM), Resource Manager (RM), and Communication Resource Manager (CRM). Tmax supports the ATMI function, which is the set of standard functions that comply with the X/Open DTP model. Tmax binds and handles transactions that occur in a heterogeneous DBMS that complies with the X/Open DTP model.
The following figure shows the X/Open DTP structure.
-
Application Program (AP)
Provides the DT boundary (Distributed Transaction).
-
Resource Manager (RM)
Provides a feature to access resources such as a database.
-
Transaction Manager (TM)
Creates an ID for each DT, manages the progress, and provides a recovery feature for both completion and failure.
-
Communication Resource Manager (CRM)
Controls communication between distributed APs.
-
Open System Interconnection-Transaction Processing (OSI-TP)
Handles communication with a separate TM section.
When distributed transactions are handled, 2 step (two-phase) commit is supported for data integrity and APIs are provided for global transactions. Distributed transactions are managed using multiple heterogeneous hardware platforms and databases in a physically distributed environment.
-
Two-phase commit (2PC) protocol
2PC is used to guarantee transaction properties for global transactions related to more than one homogeneous or heterogeneous database. 2PC handles a transaction with 2 steps to guarantee ACID properties when more than one database is integrated.
-
Step 1: Prepare Phase
Checks that all databases related to a transaction are prepared to handle the transaction. If all databases are prepared, a signal is delivered. In this step, whether each database, network, or server combined with a single global transaction can commit or rollback is checked and databases are prepared.
-
Step 2: Commit Phase
If all databases send a normal signal, the transaction is committed. If one or more databases send an abnormal signal, the global transaction is completed by performing rollback. It is the step that sends a commit message to all nodes and performs the commit request with RM. Notice that a data change job is complete when all nodes that participated in Commit Phase finish, and notify of the successful commit to the node that requests tx_commit().
The following figure shows how a 2PC (Two-phase commit) is performed.
2PC (Two-phase commit)
-
-
Global transaction
Multiple heterogeneous hardware and databases are handled as a single logical unit (transaction). A global transaction related to a DBMS located in more than one homogeneous or heterogeneous system is handled by supporting two-phase commit to guarantee data integrity. The Tmax system supports global transactions by providing simple functions such as tx_begin, tx_commit, and tx_rollback. When a global transaction is handled, communication between nodes is handled by a client handler.
The following describes how a global transaction is executed.
-
Step 1: Prepare Phase
A node that starts a distributed transaction (global coordinator) checks whether it can perform commit or rollback for other nodes that are participating in the distributed transaction.
-
Step 2: Commit Phase
The global coordinator receives replies from other nodes and performs commit. If one or more nodes send a message indicating the node is not prepared, the transaction is rolled back.
-
-
Recovery / Rollback
If a transaction fails, the previous transaction is recovered even if RM is changed.
-
Transaction managed from a central location
A transaction is centrally managed and controlled even if nodes are physically separated.
-
Transaction scheduling
A transaction is controlled with priority and concurrency.
3.3. Load Balancing
Tmax provides the load balancing feature to increase throughput and reduce handling time by using the following 3 methods: System Load Management (SLM), Data Dependent Routing (DDR), and Dynamic Load Management (DLM).
Load Balancing by SLM
System Load Management (SLM) uses a defined load ratio to distribute loads. The load value is set according to hardware performance. If the number of service requests of a node exceeds the load value, the service connection is switched to another node. The load value can be set for each node.
The following describes how SLM is handled.
-
CLH receives a client request.
-
CLH determines whether it is a SLM service using TIM and checks the throughput of each server.
-
CLH performs scheduling for a proper server group.
The following figure is an example of load balancing by SLM. If the load values of Node 1, Node 2, and Node 3 are 1, 5, and 2, respectively, Node 1 handles 1 job, the next job is handled by Node 2, and the next job by Node 3. The next 3 consecutive jobs are handled by Node 2.
Load Balancing by DDR
Data Dependent Routing (DDR) uses data values to distribute loads. If multiple nodes provide the same service, routing is possible among the nodes within the data range. Any entered field value is checked, and a service is requested from the proper server group.
The following describes how DDR is handled.
-
CLH receives a client request.
-
CLH determines whether it is a DDR service using TIM and checks the classified field value.
-
CLH performs scheduling for the defined server group.
The following figure is an example of load balancing by DDR. In the following figure, customers aged between 0 and 9, between 10 and 19, and 20 or over are handled in Node 1, Node 2, and Node 3, respectively.
Load Balancing by DLM
Dynamic Load Management (DLM) dynamically selects a handling group according to load ratio. If loads are concentrated at a certain node, Tmax distributes the loads with this method, which dynamically adjusts the load sizes. System loads can be checked with the queuing status of a running process.
The Tmax system manages a memory queue for each process and saves a request service to this queue if there currently is no process to be mapped. The number of transactions in the memory queue is the system load.
The following describes how DLM is handled.
-
CLH receives a client request.
-
CLH determines whether it is a DLM service using TIM and checks the number of queuing requests by server.
-
If the threshold is reached, CLH performs scheduling for the next server group.
The following figure is an example of load balancing by DLM. In the following figure, it is assumed that Node 1 and Node 2 have the same services. If service requests are concentrated at Node 1, Tmax distributes the loads by using the dynamic distribution algorithm.
3.4. Failure Handling
Tmax guarantees high availability of system resources by providing continuous services even if a failure occurs. Failures can be hardware or software failures.
Hardware Failure
Tmax can normally operate with load balancing or a service backup even if a hardware failure occurs.
Since Tmax is a peer-to-peer system in which nodes monitor each other, a failure can be handled in the same condition regardless of the number of nodes.
A hardware failure can be handled in 2 methods:
-
Load balancing
In an environment in which a certain service is provided by multiple nodes, if a failure occurs in a node, another node provides the service without a break. A client connects to a backup node and requests the service from the node.
Failover by Load Balancing -
Service backup
If a failure occurs in a node, another node runs a prepared backup process and handles the service.
-
Before a Failure (Normal operation)
A failure that can occur in any node can be handled because it is a peer-to-peer system.
Failover by Service Backup - Before a Failure -
After a Failure (Normal operation)
The specified backup node provides the service without a break.
Failover by Service Backup - After a Failure
-
Software Failure
If a server process terminates abnormally due to an internal software bug or a user error, it can automatically restart. Notice that if a system process, such as TMS, CAS, and CLH, restarts endlessly without any conditions and it is abnormally terminated, a running server process can be terminated together.
3.5. Naming Service
Tmax guarantees location transparency with a naming service, which enables easy service calls by providing service location information in distributed systems. Although a client does not know the server address, the user can get server information with a service name. The naming service makes programming easy because a service can be easily and clearly called and the desired service can be provided with only the service name.
3.6. Process Control
Tmax supports the following 3 server processes:
-
Tmax Control Server (TCS)
Passively executed by a client request. It must be booted in advance to handle a request. TCS is the most typical method for handling a client request, receiving a caller request from a Tmax handler, handling the job, returning the result to Tmax, and waiting for another request.
-
User Control Server (UCS)
Actively transfers data without a caller request. It is a unique feature of Tmax. It must be booted in advance to handle a request. It can periodically transfer data to a client without a request as well as handle a client request like TCS. That is, UCS can handle client requests like TCS with added functions that can process applications actively and voluntarily.
-
Processing On Demand (POD)
Executed only when there is a client request and then terminated after handling the job. It is appropriate for seldom performed tasks.
|
For more information about how to control server processes, refer to Server Programs in Tmax Application Development Guide. |
3.7. RQ Feature
Reliable Queue (RQ) enables a service to be handled reliably by preventing a request from being deleted due to a failure. A requested job is saved to disk and then handled, if the job requires a long period of time or needs reliability. Even if there is a system failure or other critical error, the job can be normally handled after system recovery.
Whether a requested service was saved correctly to disk can be checked with the return value of the tpenq() function. A queuing job does not affect other jobs because it is independently handled by Queue manager (Qmgr). Whether Qmgr successfully completes the job can be checked with the tpdeq() function.
3.8. Security Feature
Tmax provides a data protection feature based on the Diffie-Hellman algorithm and supports a 5-step security feature, which includes the UNIX security feature.
3.9. System and Resource Management
System Management
The following statuses of the entire system can be monitored: process status, service queuing status, the number of handled services, and the average time of handling a service. System status and queue management system statistics can be analyzed and a report can be created.
The following features are supported:
-
Static system management
The general system environment is set according to the user environment for the Tmax system components such as a domain, node, server group, server, service, etc.
-
Dynamic system management
The following components can be changed while Tmax is running:
Component Description Domain
Service timeout, transaction timeout, node (machine) live check time, etc. can be changed.
Node
Message queue timeout can be set.
Server group
The load value by node, the load balancing method, etc. can be changed.
Server
Max queue count, server start count during queuing, server restart count, the number of servers, server priority, etc. can be changed.
Service
Service priority, service timeout, etc. can be changed.
-
Monitoring and administration
-
The dynamic environment setting can be changed.
-
Various reports can be displayed and various statistical information is provided such as transaction throughput of a server, the number of handled jobs by service, average processing time, etc.
-
Resource Management
Resources are efficiently managed because applications and databases are integrated and managed.
In existing systems, resources are wasted because the whole system cannot be managed. Tmax manages applications using the centralized monitoring feature for the entire distributed system.
If homogeneous or heterogeneous databases are used together for a single application, Tmax integrates and manages them in the dimension of applications.
3.10. Multiple Domains and Various Gateway Services
The Tmax domain is the top level unit that is independently managed (started / terminated) by Tmax. Even if a system is distributed by region or application and it is managed in multiple domains, the domains can be integrated. Additionally, the multi-domain 2PC function is supported through a gateway.
Remote distributed systems can exchange data, heterogeneous platform systems can be easily integrated, and various gateway modules, such as SNA CICS, SNA IMS, TCP CICS, TCP IMS, and OSI TP, are supported. It is possible to handle a transaction service and route it to multiple domains.
Multiple domains solve problems, such as difficulty in managing all nodes and the rapid increase of communication traffic between nodes, that may occur when multiple nodes are managed from a single domain. Furthermore, a requested service can be handled in any system. Service methods in a multiple domain environment are different according to service handling, routing, and transactions between multiple domains.
The following figure shows the flow of calling a service in a multi-domain environment. Multiple domains are connected via gateways. A domain gateway acts as a server or client when connecting to another gateway. There is no start order for gateways.
Tmax provides various gateways, such as TCP/IP, X.25, and SNA, for easily integration with systems for other business and external organizations. A gateway enables efficient communication and provides convenient management by separating business logics and related modules. Since gateways are managed by Tmax, they can be automatically recovered after a failure and do not need to be managed by an administrator.
The following figure illustrates the role of a gateway. If a client requests a service, it receives the result from a domain, which provides the proper service. At this time, inter-domain routing is possible via a gateway according to transaction services or service values.
3.11. Various Client Agents
Tmax provides various agents to facilitate easy conversion from a 2-tier system to a 3-tier system.
Raw Client Agent (RCS)
RCA connects to an existing communication program, which cannot use the Tmax client library, by using the TCP/IP socket and enables the program to use services provided by the Tmax system. It supports services in REMOTE or LOCAL mode. A single client library like the existing Tmax client library can be used by a single client program. However, a single thread acts as a single Tmax client because RCA is developed using the multi-thread method. Up to 32 ports can be specified to support various clients.
RCA provides the reliable failover feature with RCAL, which controls user connections, and RCAH, which was created with user logic. It also supports administration tools such as rcastat and rcakill.
The following figure shows the RCA structure:
Simple Client Agent (SCA)
SCA connects to an existing communication program, which cannot use the Tmax client library, via TCP/IP and enables the program to use services provided by the Tmax system. It consists of a customizing routine and the CLH library, which is linked with CLH.
Jobs on the network, such as connect/disconnect to a client and data transmission/reception, are internally handled in the system. A developer can connect to a client by setting the client and the predefined port number in the Tmax configuration file; and change and complement the received data and data to be transferred.
Up to 8 ports can be specified to support various clients. The SCA module can directly transfer data to the CLH module and simultaneously handle both non-Tmax clients and Tmax clients. SCA provides services using a TCP/IP raw socket or the Tmax client library.
The following figure illustrates how to call a service using Client Agent (CA), a type of SCA.
3.12. Various Communication Methods
A client requests communication with a server using one of the following 4 methods:
-
Synchronous communication
A client sends a request to a server and waits while blocked until the reply is received.
Synchronous Communication -
Asynchronous communication
A client can perform other tasks after sending a request to a server, while waiting for the reply. The client can receive the reply using a function.
-
Conversational communication
When a client wants to send a request to a server, a connection is made and the service request is sent. When the client receives a message from the server, a conversational communication function is used. The client and the server send and receive messages by sending and receiving control through local communication. A control owner can send a message. When communication is made, a connection descriptor is returned. The returned connection descriptor is used to verify that the message was transferred.
Conversational Communication -
Forwarding Type
-
Type A
Type A improves the efficiency of each module by modularizing business logic and handling services step by step. Problems can be systematically analyzed and corrected. Synchronous and asynchronous communication can be used together.
Forwarding Type - Type A -
Type B
Type B integrates existing legacy systems like external organizations. A server process is not in blocking status in order to continuously handle any service requests received. This type supports a service that transfers a reply from a legacy system to a caller.
Forwarding Type - Type B
-
3.13. Various Development Methods
Real Data Processor (RDP)
Data can be directly transferred from RDP to a client instead of via Client Handler (CLH) to rapidly handle data that is continuously changing in real time. Therefore, RDP improves performance of the Tmax system by reducing the loads of CLH. It is supported only for the UDP data type, and it is configured as a form of UCS server process.
Window Control
Libraries are provided that can be conveniently used in a Windows client program. The two libraries provided, which operate based on threads, are WinTmax and tmaxmt.
-
WinTmax
WinTmax is the Windows client library and it can set multiple windows.
It consists of manager and worker threads. Since up to 256 windows can be set, it is useful to handle data that arrives simultaneously.
Classification Description Manager thread
Connects to the Tmax system, receives data, manages worker threads, and releases the connection to the Tmax system.
Worker thread
Receives data and transfers data to a specific window.
The following figure shows the structure of the WinTmax library.
Structure and Features of the WinTmax Library -
tmaxmt
It enables a client program to act as threads. A developer must develop a program using threads. Each thread sends and receives data using specified functions such as WinTmaxAcall() and WinTmaxAcall2(). Each function internally creates threads, calls a service, and transfers the result to a specified window or function.
WinTmaxAcall sends data to a specified window using SendMessage while WinTmaxAcall2 sends data to a specified callback function.
3.14. Reliable Message Transfer
Tmax reliably transfers messages using Hybrid Messaging System (HMS). Tmax HMS has the following characteristics:
-
Hybrid architecture
TP-Monitor (Tmax) and Messaging Oriented Middleware (MOM) exist together. 2PC is supported between MOM and RM. Tmax HMS enables each module to be flexibly integrated with each other in order to provide MOM features. It has the structure in which TMS, TP-Monitor (basic feature of Tmax), and MOM exist together.
-
Reliable failover
Uses DBMS to save persistent messages.
-
High availability
-
Responds to a failure by specifying a backup node. It guarantees reliable failover and message transfers by using storage. It uses DBMS to guarantee failover reliability and recovers a persistent message from the DBMS if a failure occurs.
-
Responds to a system failure by configuring High Availability (HA) of Active-Standby.
High Availability of HMS
-
-
JMS Messaging Model Adoption
Adopts the JMS messaging model to support P2P and Publish/Subscribe, and provides C language APIs similar to the JMS specification for convenience.
API Compatibility of JMS
HMS, a Tmax feature, is the communication medium for a loosely coupled sender and receiver. It supports the Queue and Topic methods.
-
Queue method (Point-to-Point)
Each message is transferred to a single consumer. There is no timing dependency between transmission and reception.
HMS-Queue Method -
Topic method (Publish/Subscribe)
Each message is transferred to multiple consumers. Reliability is guaranteed by sending the message through a durable subscription.
HMS-Topic Method
|
For more information about HMS, refer to Tmax HMS User Guide. |
4. Characteristics of Tmax
Tmax adopts the peer-to-peer structure instead of the existing master/slave method. RACD (Remote Access Control Daemon) exists in each node. Tmax prevents Queue Full by using the stream pipe communication method. By blocking heavy transactions in network processes, the stream pipe communication method provides more reliable communication between processes than the message queue method. With these characteristics, Tmax minimizes the memory resource waste, supports rapid failover, and enables an administrator to actively respond to a failure.
The following are the characteristics of Tmax.
-
Complies 100% with various DTP international standards such as X/Open and ISO-TP
-
Complies with the X/Open Distributed Transaction Processing (DTP) model, the international standard for processing distributed transactions, and specifies a compatible API and system structure based on the application program (AP), transaction manager (TM), resource manager (RM), communication resource manager (CRM), etc.
-
Specifies the framework for the following: features of a DTP service specified by Open Systems Interconnection (OSI) group, the international standard organization; API for the features; the feature for supporting distributed transactions; and the feature for adjusting multiple transactions that exist in a distributed open system.
-
Supports transparent business handling between heterogeneous systems in a distributed environment and On-Line Transaction Processing (OLTP).
-
-
Enhances the efficiency of protection and multiplexing
Enhances the efficiency of protection and multiplexing by implementing Inter Process Communication (IPC) of the stream pipe method.
-
Provides various message types and communication types
-
Supports various message types such as integer, long, and character
-
Supports various communication types such as synchronous communication, asynchronous communication, conversational communication, and forwarding type communication
-
Supports Field Definition Language (FDL) and structure array
-
-
Fault tolerance and failover
-
TP-Monitor with the peer-to-peer method
-
Handles H/W and S/W failures
-
Supports various features for preventing failure
-
-
Scalability
-
Ensures stable system performance even if the number of clients increases
-
Efficiently changes from a 2-tier model to a 3-tier model using Client Agent (CA)
-
Provides various protocols for legacy systems
-
Provides services in the web environment using WebT
-
Provides various protocols for legacy systems such as TCP/IP, SNA, and X.25
-
Supports various process control methods
-
-
Flexibility
-
Supports various process control methods
-
Supports customized features if necessary
-
-
High Performance
-
Efficiently utilizes system resources
-
Provides an API to enhance productivity for simple and clear development
-
Provides the system monitoring feature that is convenient and easy to use.
-
-
Supports various H/W platforms
-
Supports for IBM OS/390, most UNIX systems, Linux systems, Windows NT system, etc.
-
-
Supports almost all 4GL such as PowerBuilder, Delphi, Visual C/C++, Visual Basic, and .NET(C#, VB)
5. Issues on the Tmax Adoption
5.1. System Environment
Supported Environment
The following shows the basic environment of the Tmax system.
| Classification | Description |
|---|---|
Protocol |
Application API: XATMI and TX |
Integrating API: XA |
|
Network: TCP/IP, X.25, and SNA (LU 0/6.2) |
|
OS |
Server: All UNIX, NT, and Linux |
Client: All UNIX, Windows, MS-DOS, etc. |
|
Platform |
All H/W that support IBM OS/390, UNIX, Linux, and Windows NT |
Development language for servers |
C, C++, and COBOL |
Development language for clients |
Supports interfaces for C, C++, and various 4GL (Power Builder, Delphi, Visual C/C++, Visual Basic, .NET (C#, VB), etc.) |
DBMS |
Oracle, Informix, Sybase, and DB2 (UDB) |
Server Requirements
The following table shows requirements for a server when adopting Tmax:
| Classification | Description |
|---|---|
Hardware |
Memory: 0.50 MB Disk (Tmax client): 0.277 MB (Include - 83 KB, DLL - 86 KB, and Type Compiler - 108 KB) |
Software |
IBM OS 390, UNIX, Linux, and Windows NT |
C, C++, or COBOL Compiler |
|
Network protocol |
TCP/IP |
Client Requirements
The following table shows requirements for a client when adopting Tmax:
| Classification | Description |
|---|---|
Hardware |
Memory: 0.537 MB + 0.2 - 0.5 MB / application Disk (Tmax client): 0.277 MB (Include - 83 KB, DLL - 86 KB, and Type Compiler - 108 KB) An additional 203 KB (DLL, PBD) for Power Builder is required. |
Software |
Linux, Windows NT, Windows (2000, XP), MS-DOS, and UNIX |
Power Builder, Delphi, Visual Basic, Visual C++, C, and .NET (C#, VB) |
|
Network protocol |
TCP/IP |
5.2. Issues
There are issues in terms of features, performance, reliability, etc. when adopting Tmax.
The following are the details of the issues of the features.
| Issues | Details |
|---|---|
Basic features of TP-Monitor |
|
Additional features |
|
The following are the details of the issues besides features.
| Issues | Details |
|---|---|
Performance |
|
Reliability (failure handling) |
|
Education and technical support |
|
Risk management |
|
Convenience for development and operation |
|
User satisfaction |
|
Compatibility |
|
Business Size |
|
Other |
|