xBase application migration to the terminal architecture

Below there has been described features of Terminal software and the methodology of xBase application migration (CA-Clipper/Harbour/xHarbour) to the terminal architecture.

Traditional architecture of xBase application

The biggest drawback of systems created in xBase tools is the lack of a separation between a data management functions and an application. Management functions are shared among all the workstations where applications are executed. In consequence, a damage of one of the stations may cause essential damages in the stored data, and even make the work of other computers impossible. It is very difficult to keep the consistency between data and indexes, and the decentralization of data management functions practically hinders their successful protection against unauthorized access. Processing data is realized exclusively by workstations generating huge network traffic, which excludes a rational use of applications in WANs.

Client - server

The client - server architecture has been considered as the best solution for database applications for many years. It assumes that tasks are divided between a workstation and a server. It enables significant decrease of network traffic, and the centralization of database management functions increases the security level of the whole system.
Thanks to the introduction of transactions, keeping the data consistency stopped to be a problem. Nowadays, most of transaction systems work in a client-server mode. Beside many advantages, the client- server architecture has also several disadvantages. These are, first of all, big requirements for a workstation power responsible for processing and the presentation of inquiry results and high costs of the administration of the whole system.
Network traffic, although significantly lower than in systems with a file server, remains big enough to hinder using of an application in WANs with little throughput. The terminal architecture is free from many of these disadvantages.

Terminal and an application server

In the terminal architecture, the most important element is an application server, which may simultaneously play the role of database server. It must be powerful in opposition to terminals, which the main task is operating the keyboard, the display and the realization of communicative functions. The cost of such terminals is low. The responsibility for the system security practically lays on a server, that is why the system administrator's tasks are limited mainly to operating a server and maintaining the network communication.
The costs of the administration only minimally depend on the number of the attached terminals. Network traffic generated by terminals is so little that it makes possible the work of many terminals on low transfer links. It gives an opportunity to attach all company branches to the central database server. It does not concern only newly created systems. Thanks to Terminal software, also CA-Clipper applications may be run in a terminal mode with an application server. These applications work very effectively and are much more safer than the traditional ones both in LANs and WANs.

OTC Terminal

OTC Terminal pack is made for running in a terminal mode both traditional Ca-Clipper or/and Harbour/xHarbour applications, and applications, which use Mediator software for cooperation with a relational database server.
Both versions of Terminal pack use Windows NT/2000/XP/2003 server as an application server. The equipment configuration depends on the nature of an application and the number of users. Any PC computers (even i286) working under MS DOS, Windows 95/98/ME/NT/2k/XP may be terminals. The software consists of three elements:

• Terminal Manager (terminal.exe) - an agent working on a server, responsible for running a given application on a terminal request.


• Terminal (te.exe) - a program run on a workstation, responsible for the operating of the keyboard, the display, printing, file transmission and communication with an application being executed on a server.


• The libraries to be linked with CA-Clipper applications, which realize communication with a terminal and the extensions of the architecture, described further.

The principle of the software opereation resembles TELNET protocol, known from UNIX systems. A user, starting his/her work on a workstation, runs terminal software (te.exe), giving information which is indispensable for a localization of a required application on a server. The terminal sends this information to an agent (Terminal Manager) installed on an application server , which starts the required program and sends back the information indispensable for communication with the started application. After disconnecting from the agent, the terminal connects to the application. This connection is used for sending information about the state of the keyboard (from the terminal to the application) and screen updates (from the application to the terminal). The data sent via the network is initially compressed, which additionally limits the network traffic. The application devoted for work in a terminal mode must be initially adjusted by linking the libraries, which realize the communication functions and which contain useful language extensions. In practice, it is enough to get run the application ready for terminal mode; but if a user wants to use the available language extensions, she should make certain modifications in the source code of a program.

What do we gain?

In comparison with the traditional architecture of CA-Clipper application with a file server, the terminal architecture has many advantages:

1. A higher level of data security stemming from placing applications and data on the same server, the use of transactional extensions which guarantee completing the run operation and the independence from a damage of individual terminals.


2. The increased efficiency of an application gained by local performance of all operations requireing file access.


3. Effective work in WAN, which enables the attachment of individual stations or all LANs to the central server via a low-throughput links.


4. Low costs of an installation and computer equipment operation , which are mainly limited to the central server - the costs of terminals and networks are very low because of the little equipment requirements and the possibility of using old equipment.


5. The simplicity of creating network applications which integrate the data of the whole, even multi-branch company - the use of complicated and ineffective replication mechanisms becomes redundant.

In order to increase at most the security and comfort of using an application, the linked libraries contain many useful functions which realize transactional extensions, ability to call procedures attached to the terminal (RPC), operating of printers on the terminal, and managing of the application priorities.

Data security

In order to explain why the terminal work increases data security, one should identify the main problems occurring in traditional architecture with a file server. Assuming that we use an efficient file server, the following data damage happen the most often:

1. Inserting nonsense information (a random byte sequence) to a data table or an index. The reason for this may be a damaged workstation, a network card, switching on or off of the station while sending a message.


2. A disturbance of the DBF files consistency with the associated indexes. The reason - a connection break up between an application and a file server after the modification of DBF file and before updating all indexes. A connection break up usually stems from a network damage or disconnecting a workstation or a server form the network or from a damage or switching off of the station.


3. A disturbance of the logical consistency of data. Assuming that the program is written correctly, the consistency disturbance may be the result of a sudden abortion of a running program, which makes the ending of logically related operations impossible (a code part, which realizes dependent changes in data). A sudden abortion of a running program is usually a consequence of a connection abortion between an application and a file server (the reasons like in point 2).

With the terminal work, the damage of type 1 cannot occur, as the application is not executed on a physical workstation but in DOS window of Windows NT system. Possible problems with a workstation will cause a terminal disconnection, or in the worst case, a distortion of the picture shown on a terminal.

Terminal software has been structured in such a way that executing an application cannot be stopped while the indexes are being updated, which eliminates the possibility of a consistency disturbance of indexes and DBF databases, even when a terminal is suddenly disconnected.
Because of the fact that with the work in terminal architecture both data (DBF,NTX) and applications are on the same computer, a connection abortion between an application and the data is practically impossible on the server. There is one issue left - a connection between an application and a terminal. By default, an application working in a terminal mode ends its activity when it finds out that a connection with a terminal has been aborted. It may cause a disturbance of the logical consistency of data. In order to avoid such a possibility, a mechanism of a terminal transaction has been introduced.

Terminal transactions

A programmer who uses TrmTsBegin() and TrmTsEnd() functions can mark in xBase program code fragments which cannot be aborted (Listing 1). If a connection between a terminal and an application is aborted at the moment when the application is in a terminal transaction mode, the disconnection will be ignored until TrmTsEnd() function is run, which means until the end of the transaction. The terminal transaction guarantees a complete execution of a marked application fragment. Correct inserting of terminal transactions to an application eliminates a possibility that a disturbance of the logical consistency of data may occur. Working in terminal architecture and using terminal transactions, you can achieve a system stability and the level of data security normally unavailable in traditional installations with a file server. The stability of one only element - an application server becomes the factor that decides about the stability and data security in entire system. In traditional installations data security depends on many elements:

• the stability of a file server


• the stability of all the workstations


• the network


• the workers' discipline

LISTING 1

&& terminal transactions

FUNCTION book
PARAMETERS Account1, Account2, sum

TrmTsBegin() && starting of terminal transactions

&& transfer Sum from account1 to account2 -
&& the operation is done in a transaction and it is secured
&& against a disconnection even when the connection between an
&& application and a terminal is broken up

. . .

TrmTsEnd() && transaction end
RETURN


RPC Mechanism (Remote Procedure Call)

The classical terminal architecture unevitably states the task share - an application executes itself completely on a server, the terminal operates the screen, keyboard and possibly printers. Because of the fact that Terminal software uses a PC computer as a terminal, it has become possible to introduce RPC mechanism, which enables executing code fragments not in an application but on a terminal. A programmer may attach his/her own functions to te.exe program executed on a terminal and then call them out from an application with the help of TrmTrmRPC() function, handing over possible call parameters. After finishing the operation, the procedure (function) may return the result to the application (Listing 2a, 2b). RPC mechanism is completed by two functions (TrmPutFile(), TrmGetFile()), which allow to send files between a server and a terminal in both directions. RPC is a very general mechanism which enables an effective realization of all untypical functions which have to be executed on a terminal.

LISTING 2a

&& reading info from the sensor attached
&& to the terminal with the help of RPC mechanism

&& the function connected to te.exe program, executed on the terminal
&& reads the temperature value for conventional coordinates xc, yc

FUNCTION GetTemp
PARAMETERS xc, yc

tempVal = LowGetTemp(xc,yc) && reading the temperature form the sensor

RETURN tempVal && sending the value back to the application


LISTING 2b

&& reading info from the sensor attached
&& to the terminal with the help of RPC mechanism

&& remote execution of GetTemp() function on the terminal
&& with the parameters 10, 50

tempVal = TrmTrmRPC("GetTemp",10,50)

? "The temperature read by the terminal is ", tempVal

. . .

A typical use of RPC mechanism is operating of untypical peripheral devices, such as:

• operating of magnetic card readers,


• operating of bar code readers,


• operating of fiscal printers,


• untypical operating of printers (e.g. an application generates a printout to a file, compresses it, sends to a terminal, the terminal decompresses the file and prints it on the printer),


• the implementation of own methods of the access authorization,


• reading the data from sensors attached to a terminal.

Printers

Printings generated by an application are awaited on a terminal or on a network printer. Independently form the possibility of printing by RPC, there are two other methods available in Terminal software:

1. Operating of printers via captured LPTx port.
   The simplest printing method is using the default mechanism of capturing the printer ports LPT1, LPT2 and LPT3. If te.exe program is run without additional parameters describing the options of capturing, then all of the three ports (LPT1-LPT3) seen by an application on Windows NT server are automatically captured and redirected to the LPT1-LPT3 ports on the workstation running te.exe program.CA-Clipper application printing to LPT ports should work with TERMINAL software without changes. In order to use this method, one should give additional parameters to te.exe program which influence LPT ports capturing:
   
   
   • /NOP - means that LPT ports capturing should be turned off
   
   
   • /NOPn - means that LPTn port capturing in Windows NT is given up. This option is useful when some LPT ports for Windows NT are redirected to the printer (net use lptx command), and we want to use this redirecting in CA-Clipper/Terminal application, simultaneously keeping capturing of other ports
   
   
   • /Pn=m - means that LPTn port for Windows NT is to be captured and redirected to LPTm port on a workstation. The option /P2=1 means that all the printouts sent by an application to LPT2 port will be printed on LPT1 port on a workstation
   
   
   • /Tn - defines the time in seconds, after which the procedure printing on a workstation being unable to print the required information, will display the "Printer not ready. Continue printing (y/n)?" message. The default time is 60 seconds. /T0 option results in infinite time. It means that the message will not be displayed, and the printing attempts will be repeated until a successful completion
   
   
   
   


2. The printers of Windows NT
   One of the printing possibilities via an application which executes itself on Windows NT server is using the printers defined in the system. These may be printers directly connected to NT server or available via the network, and physically connected to other computers with Windows NT, Windows 95, Novell NetWare, workstations or printer servers. TERMINAL software provides the following functions which enable using of Windows NT printers:
   
   
   • TrmPrList() - getting information about the printers available in the system
   
   
   • TrmPrFile() - printing file contents on a specified printer
   
   
   • TrmPrOpen() - opening of a printing session
   
   
   • TrmPrPut() - sending a string of characters to be printed within an open session
   
   
   • TrmPrPutFl() - sending file contents to be printed within an open session
   
   
   • TrmPrSubmt() - sending a printout prepared in the result of calling out TrmPrPut() and TrmPutFl() to the printing queue
   
   
   • TrmPrCancl() - removing a printout from the printing queue
   
   
   • TrmPrClose() - the close up of a printing session
   
   

All the mentioned functions, apart from TrmPrList() and TrmPrFile(), are session functions - they work on a printer opened as the result of calling out TrmPrOpen() function. A typical call sequence for a session mode is as follows:

• TrmPrOpen() - opening of a session - it returns the ID of a printer


• multiple calling out of TrmPrPut() and TrmPrPutFl() functions, which send data to the file associated with a printer


• TrmPrSubmt() - the actual start up of printing by loading a created file to the printing queue


• if necessary, you can interrupt printing by calling out TrmPrCancl() function


• closing the printing session by calling out TrmPrClose() function

Many printing sessions, concerning the same or different printers, may be open simultaneously.

The application execution priorities

By default, every terminal application executes itself on Windows NT server with a normal priority. By using TrmGetPrty() and TrmSetPrty() functions, the application may manipulate with its own execution priority (Listing 3). For example, with a big number of terminal sessions, performing complicated calculations and reports by several applications may influence the comfort of work of other, interactive sessions. Lowering of an application priority for the time of performing complex calculations will cause that they will be done only when other sessions do not use the processor fully - the interactive applications will work without delays.

LISTING 3
&& An application priority management

&& A symbolic marking of priorities
#define PRIORITY_LOW 0
#define PRIORITY_NORMAL 1
#define PRIORITY_HIGH 2
#define PRIORITY_RLTIME 3

FUNCTION ZestRok

oldPrty = TrmGetPrty() && storing the current priority
TrmSetPrty(PRIORITY_LOW) && setting a low execution priority

&& performing long-lasting calculations
&& with a low priority

. . .

TrmSetPrty(oldPrty) && returning to the initial priority
RETURN