Table of Contents
This chapter describes a UCS overview and functions.
Tmax Control Server (TCS) is a typical process control method that provides services only when a client requests them. This method is used by other middleware like Tuxedo, Entera, and TopEnd.
The TCS process is a server process that has three tiers. Tmax first sends a client request to the proper server, and the corresponding server process' service will process the request according to a set business logic. Results will be created and then sent to the client.
The following describes the TCS type server program flow:
Process On Demand (POD) is a process control method where a server process operates only when there is a client request.
The POD process is similar to a TCS. The difference is that even the process is not started when Tmax is started. If a request is received from a client, Tmax will start a corresponding process to let it handle the request, and if the operation completes, Tmax will terminate the process.
In general, a TCS and POD are passive processes that handle a request only when it is received from a client. In contrast, a User Control Server (UCS) can send data to a client even when the client didn't request it. If a client request is received, UCS also can handle it. UCS is Tmax's own function for TP-Monitors.
The following is a UCS type server program flow:
A User Control Server (UCS) is a proprietary Tmax program type that allows users to control program flow directly instead of middleware. The programs and processes that utilize this method are the UCS programs and UCS processes. The server process (UCS process) can generate an event actively to process a job and also support existing process method that a job is processed only by a client request (event).
A UCS is used for jobs that require information delivery even if a client didn't request it, such as stock price information, notifications, scheduled jobs, and integration with external institutions.
Necessity of UCS
A UCS is a user-controllable server. Jobs that have been operated in a daemon type in an existing method such as a job operation at a specific time, integration with other external institutions, and information delivery to a client can all be written in UCS. A program process written in this way will be managed by Tmax so additional separate process management (restarting due to an abnormal termination) is not required.
UCS can be used in the following cases.
-
Jobs that notify connected clients (specific clients or all clients) when information is changed.
-
Business Case 1
For stock businesses, clients can receive fast and accurate data by delivering continuously changing stock price information to clients without direct client requests.
-
Business Case 2
Software errors, schedule information and other notifications can be sent to administrators, developers, or users.
-
Business Case 3
For banking businesses, if an exchange transaction occurs, it can be notified to a client directly. Or if automation equipment is used, a specific state for the equipment can be informed to specific clients (ie: automation equipment administrator).
-
-
Job scheduling type businesses
-
Business Case
A batch job can be performed at a specific time, or a scheduled job can be performed.
-
-
Integration with external institutions.
-
Business Case
Provides an effective and simple program structure when implementing integration jobs with external institutions. The looping that is done to check the transaction flow of an async procedure or to check whether data is received can be eliminated so that programs can be written in a simple way and CPU resources can be saved. Various types of jobs can be implemented in a UCS, so it can be useful when a developer understands a program flow.
-
RDP (Real time Data Processor) works similarly to a server in a UCS. RDP is a process that is modified from a UCS process at the kernel level to send continuously changing data to clients, rapidly and effectively. RDP sends data to clients without passing through CLH, so it shows far better performance in process occupation or process speed than UCS when sending small volumes of data to multiple clients in short term intervals.
A RDP server must be unique in a node. All services of the node must send service results to the RDP server and the RDP server will sends the data to the client.
The number of channels (RSCPC) that will be used to retrieve results processed by other server processes must be set. The number of CLH and RDP server processes must be steady (the MIN value and the MAX value must be the same). The, MIN, and MAX of a RDP server process must always be bigger than those of CLH and usually double the values. In CLH, the number of MINCLH and MAXCLH must be the same.
The program structure and APIs are the same with UCS, with slight differences in the environment configuration and compilation method. For more information about RDP environment configuration and compilation method, refer to "5.3. RDP Environment Configuration and Compilation".