For many years DP4 has had an extremely well modularised and portable structure which lends itself to distributed processing. Until recently this has primarily been used to create applications with a typical client/server architecture with a database distributed between one or more servers, and perhaps also held locally on each client to provide resilience. The typical DP4 components are shown in the diagram on the left.
With the decreased cost and increasing power of PC based servers, as well as the increasing complexity and cost of deployment of PC based software a new type of solution has become popular - "Thin Client", or "Ultra Thin". In this architecture the absolute minimum of software is deployed on client PCs and applications run primarily on the server with the client computer acting more or less solely as a terminal (possibly a very sophisticated one).
In fact this largely represents a return to the typical model of computer systems before the invention of the PC. Thin Client solutions should offer cost savings through reduced cost of deployment and administration, and savings on hardware costs through reuse of legacy hardware for clients and reduced cost of new hardware.
From version 4.523/4.619 DP4 can run in this type of configuration. Existing applications are able to run with little or no modification using the new DP4 Terminal Server.
The original thin client software was probably Telnet - this allowed any computer to act as a dumb terminal to any other computer running as a Telnet server to which it could connect. Telnet is still a very useful program - its primary disadvantage is that it can only run text based programs. Later on the Unix X Windows system allowed GUI based programs to run in a similar fashion, though this does not seem to have become very commonly used as yet (at least in the commercial environment).
In recent years two more types of technology have emerged:
DP4 systems can already be deployed using most, if not all, of these technologies. However the DP4 Terminal Server architecture has unique advantages over all of them. Before going into this in more detail a few terms will be defined:
Here then are the advantages of the DP4 Terminal Server Architecture:
The DP4 Terminal Server will be based around the existing DP4 API. As such an application might be running on a Unix or Linux based Server, but the client machine might be running Windows 9x,Windows CE (or even Windows 3.1). To the user on such a device the application will appear exactly like an ordinary Windows application. In due course GUI execution on Linux will be supported. Text based execution is also be supported - a major strength of the DP4 API is that is almost completely indifferent to the type of display device in use. Thus an existing text based Unix based QAB system will automatically use the mouse correctly when run with a GUI DP4 Terminal Server.
The Application Host will need to be sufficiently powerful to run the expected maximum number of DP4 programs simultaneously. However typically a machine previously acting as a DP4 server in a client server architecture will already be sufficiently powerful to run as the application host, though possibly some extra RAM will be required, particularly if a large number of different executables are used. Typically the additional processing required for running the application programs on the server will be largely offset by reduced network traffic, though this will of course depend on the application to some extent. An important point to note is that no special operating system version will be required for running as a DP4 Application Host - in particular there will be no need for the machine to run Windows NT/2000 Server rather than workstation (unless it is felt that additional CPUs are required beyond the two supported by NT Workstation). If desired the Application Host can run one of the MS Architecture terminal server operating systems so that a mix of client architectures can be used. Deploying an application using the DP4 Terminal Server will offer the benefits in terms of reduced cost of deployment typical of Thin Client Solutions. In particular upgrading a system and making database changes should be much easier in a Terminal Server environment.
Any PC capable of running DP4 in client server mode can be used as a client. An absolute minimum spec would be a 386 DOS PC with FTP TCP/IP protocol, or a Windows 3.1 PC with Microsoft TCP/IP. Any higher spec will be sufficient. Non PC hardware such as Winterms will not be supported, though these can of course be used if the Application Host is also an MS Architecture Terminal Server.
With most existing Thin Client architectures programs typically have no access to devices on the client. For example in the Telnet client there is no facility to save a file from the server to the client and the FTP program must be used instead. Access to specialised hardware such as retail devices is out of the question. In Web Based architectures it may be possible to gain access to the local machine, but typically there are difficult security issues to be addressed, and unpleasant cross language software has to be written - for example to bridge from Java classes to an existing device driver with a C/C++ interface. In some cases even if access to devices is possible existing devices drivers may have to be completely rewritten.
With the DP4 Terminal Server is possible to use an existing OSDI more or less unchanged, as the OSDI is an interface between the DP4 terminal manager and the hardware, and not between the application and the hardware.
The DP4 Terminal Server architecture should offer improved performance compared with Remote Display Protocol type servers (X Servers and MS Terminal Servers). This is because the DP4 API is much more abstract than most RDP architectures. For example when a user is selecting options from a menu an MS Terminal Server will typically have to send many messages across the network for the client to to tell the application server where the mouse is, and from the server to the client to repaint the display. In the DP4 architecture this will be accomplished by a single API executed entirely on the client, with a one time transfer of the text in the various menus from the database on the server. In this respect the DP4 architecture is more like a Web architecture where client side processing reduces the load on the server. On the other hand the DP4 architecture does not suffer from the high round trip cost for going back to the server inherent in current web based architectures. The vast majority of processing is carried out on the most appropriate computer - display, editing and device handling on the client, database and business logic on the server.
To understand the DP4 Terminal Server Architecture it is only really necessary to understand the basics of the regular DP4 architecture.
A pure DP4 application program never interacts with any devices on the computer directly. All such interaction is done via one of two interfaces - the DP4 database interface, and the DP4 terminal interface. The DP4 database interface implements the calls necessary to access and update a DP4 database. The DP4 terminal interface implements a set of APIs which is sufficient for all typical application needs - it contains calls to display screens, collect data from the user, access and create non database files, and print to regular or special printers or files. Specialised hardware is via the terminal interface accessed using abstract devices.
The word interface was used advisedly above. It is common to speak of a program "calling" the database manager, but this is not strictly accurate, it is an interface that is called, and the components that implement that interface can be extremely varied - anything from a standalone DP4 database residing locally through to a mixture of DP4 and non DP4 databases residing on different servers running different operating systems on different and incompatible processor architectures and accessed through differing network protocols. The application need not care about the implementation of the DP4 database at all.
Internally this is achieved by defining a simple protocol which is common to all calls to the database interface. This protocol is completely independent of the operating system and hardware used by the program. All calls to the DP4 database interface work by constructing a simple parameter block which describes the function to be called and the data to be passed in and out of the function. In the simplest case calling the interface will send some kind of message directly to the DP4 database manager. In a more complicated set up the same message may be picked up and passed through one or more ADC components and then passed into one of the DP4 network requesters. This then communicates with a DP4 network manager (receiver) running on another server and transfers to it the parameter and data associated with the call. The call can then be handed on to the DP4 database interface on that server. From the point of view of whatever is implementing the DP4 interface on the server computer the call is more or less identical to one made by a DP4 application running locally - so the same process may be repeated to pass the call through several more layers. Eventually (usually almost instantaneously) the destination will be reached, the call will be processed and the answer will be returned to the calling application, which will have no idea where or what actually did the processing. The DP4 networking components function much like software equivalents of electrical extension cables and adapters that convert British to Continental plugs or vice versa. (A slightly better analogy might be with surge protector type adapters or UPS as the DP4 networking software also contains logic to deal with network problems of various types)
The DP4 terminal interface is logically identical to the DP4 database interface. In exactly the same way a parameter block is constructed to describe the function to be called and its input and output data.
Indeed the format of the parameter block is compatible, and in principle exactly the same network components can be used to transfer a call from one machine to another. (The same interface is now also used for calling the DP4 SQL Engine and will be used for any future interface components). The implementation of the DP4 terminal server, shown in the diagram on the right, is almost as simple as replacing the regular DP4 terminal manager component with the existing network requester and making the existing DP4 network receiver accept and pass on Terminal Interface calls as well as Database Interface calls.
In fact things are not quite as simple as this as there do need to be some additional "components" and there are some minor changes required to the regular DP4 network architecture. For example the client machine has to have some program running that is capable of starting an application on a remote server, and at the same time creating an instance of the "terminal receiver" that will execute its client side code. Whereas the regular DP4 network requester is completely single threaded a separate "terminal requester" is created for each application (since otherwise all the applications on the server could be blocked if a remote user went to lunch with a DP4 program sitting in a data entry screen). The regular DP4 Network Receiver is used as the program which processes requests from clients to launch applications. Each application is supplied with an environment variable that tells its terminal requester which client machine to connect to.
The diagram shows the networking components as using TCP/IP protocol. In principle there is no reason why other protocols could not be supported.
The Terminal Requester is built into the regular DP4 Terminal Manager. An application will automatically select whether to use the regular terminal manager code, or the requester version. Thus there is no problem with running DP4 applications locally on the application host.
No additional components are required on the application host. On the client side you can choose either to install a simple client configuration (which comfortably fits on a single diskette) without installing any other DP4 components, or you can install the client as an additional package. This might be convenient where you want to deploy some, but not all of an application locally. You can run almost any mix of local,client-server, and DP4 terminal server applications all at once, connecting to as many servers as you want!
The two special components for the client side are :
The program to launch applications on the application host. This is a simple command line utility which can easily be replaced by a customised version - you can launch applications yourself by directly calling the same API that TSRUN uses.
The terminal receiver program TSTCPx. This is the program that communicates with the remotely running application. An initial copy of this program must be loaded as part of the DP4 service, (which will be started automatically when a request to start a DP4 program is made).
In addition to this a skeleton DP4 installation is required - the install program for the client will do this automatically. For example on Linux the files tcp3,trm3 and userdata.sys are required. On Windows a few additional DLLs are also required and the DP4 service program srvw32.exe . The OSDI must be installed on the clients if required.