TxServer is the modernist approach to building client/server applications for transaction processing. It is the only completely integrated system providing application development, transaction management, database management and server communications in one seamless package.
TxServer eliminates or minimizes many of the integration and support complexities that are associated with the other approaches on the market, which all require many different products from multiple vendors.
TxServer was built precisely with the requirements of high-end mainframe based transaction systems in mind, so that issues like performance, database integrity, backup and recovery, transaction journaling, and concurrency management are all addressed by the system, not by the application.
And TxServer achieves this on minimal hardware - it is a truly low cost solution. Naturally, it can be scaled up to systems having over 128 clients, but the hardware required is always relatively low in cost.
In order to make all these benefits available automatically to the deployed application, TxServer includes a complete development toolkit designed specifically for the client/server environment. The toolkit provides everything needed to create the database, define the required screens and reports, and generate all the procedural code necessary to complete the application.
TxServer is a generic toolset that has been used to develop and run many different applications in a wide variety of industries. Typical applications include inventory control, customer service, billing, order entry, parts service, and appointment scheduling. TxServer has proved itself in industries ranging from health care to financial services, from retailing to education, from manufacturing to government services.
Some end users have chosen the TxServer platform to downsize from mainframe environments, and have realized significant gains in productivity, flexibility, and deployability. At the other end of the scale, TxServer has been the system of choice for many smaller businesses going to true enterprise-wide computerization for the first time. For users of all sizes, TxServer provides unparalleled ease of use and streamlined support.
The authors of TxServer set out to build an integrated, high performance, high integrity transaction processing system on the client/server paradigm, where the applications were easy to build and maintain at minimum cost. They understood from their experiences in the mainframe and desktop worlds that a superior product offering would require every aspect of the application, the database, the communications and systems services, to be tailored to the demands that mission critical transaction processing makes on its platform.
The leading database server products (Sybase, Microsoft SQL server, Oracle DBMS) all require major functionality beyond the database management system itself in order to create and run an actual application. Front-end tools, such as VB, PowerBuilder and Visual FoxPro, are required to build the actual application. Even with all of these tools deployed, the quality of the interface between the client application and the database is left up to the application writer, resulting in frequent problems with data or transaction integrity. In TxServer, by contrast, there is no gulf between the client application and the database - TxServer tightly binds the application and database together, covering the most important data and transaction integrity issues by virtue of its underlying set of system services.
Through the TxServer development tools and the power of its innate runtime support infrastructure, many of the complexities of application development and database design are hidden from the designers and programmers, and handled instead by the underlying TxServer system. Using the data definition facility, the user describes the data required by the application. Screen and report formats are defined in a similar manner, and the visual layout built in a WYSIWYG GUI format definer. The data and screen definitions are used to design a database, and as a result, much less application code needs to be written by the programmers, and application code is prevented from compromising the integrity of the database. The result is an application which is smaller, simpler, easier to maintain, and fails much less often than one built by other methods.
Using the data definition facility, the end-user analyst defines the data required by the application and the relationships between the data. From these definitions, TxServer automatically builds the database schema and acquires the knowledge necessary to store and retrieve the data requested by the application at runtime.
Using the Format Definer (TxSFD) tool, the user builds the visual screens and reports.
Procedural logic is written in TxServer's fourth-generation application language, TDL. This high level language is natural and easy to use. With it the user defines the flow of the entire application, and defines all data manipulation, arithmetic, and decision logic. The TDL compiler emits interpretive pseudo-code which is stored on the server.
When the application is run, the compiled application logic is executed interpretively by TxS in the client. The user application controls all presentation to the user, and directs all the database retrieval and update. But it does this at an extremely high level, making the application code very compact.
An important feature of the completed application is that is a single program. Naturally, it is separated into as many source modules as the designer wants, but it is a single monolithic program with well-defined flow. This contrasts favorably with forms-based applications where the business logic of the application is fragmented. In these applications, the business logic is hidden in a myriad of tiny separate action procedures called during data entry. Such forms-based applications can be very difficult to maintain.
The TxServer architecture is unique. The system architects sought ways to utilize all the power of the client workstations, the network, and the server to deliver the high performance, integrity, and flexibility that transaction processing requires.
When the application is being developed, TxServer captures detailed information about it in tables for use by the server and client supervisor. With this information the client and server can cooperate so that the client's runtime needs are well understood in advance by the server, and can often be anticipated and executed "ahead of the wave".
The TxServer server is a proprietary OS and application/database manager designed specifically to service TxServer applications. It is not a general-purpose OS burdened with providing a hugely complex API to service every imaginable type of application, so it can be very streamlined and efficient. Neither is it is simply a database server that must service arbitrary clients - so it can provide many extra performance-enhancing services to the client that are impossible in traditional client/server environments.
TxServer takes advantage of the extreme speed of modern networks to smooth the interactions of the client with the server. Many types of data are demand paged between the client and server, and on-screen database queries are done over the network at a special high priority.
TxServer applications are not free-standing code. Instead, the procedure is compiled into pseudo-code executed in the client supervisor, TxS. This approach has numerous advantages.
The client supervisor is tightly bound to the support services in the server. The net result is that cooperation between client and server is smooth and fast, yielding very high efficiency.
TxS provides a tightly controlled environment for the running application. This limits the number and severity of programming errors, making it faster and easier to develop new applications or enhance existing ones.
The entire application (forms, procedure code, reports, database schema) is part of the database rather than being stored on individual clients or fetched as an EXE file from a network file server. The application is demand paged into the client by the client supervisor. This is a performance benefit since the entire application does not need to be loaded every time it runs.
But demand paging is also a very important integrity feature. Because the application is part of the database, it creates a single source point for distribution of the application (so less work for system managers), and makes it impossible for clients to be running the wrong version of the application. System managers responsible for application distribution to upwards of 100 client workstations are very appreciative of this feature.
TxServer caches data and applications at a variety of levels. In the server, database data is massively cached at both the sector and record levels.
Database data fetched by clients is fetched ahead and demand paged into the clients as they need it, rather than having to be delivered all at once - another significant performance benefit that greatly improves the smoothness of application execution as seen on the client screens. The feature is even more important on slow remote networks, where in traditional client/server applications fetching a large collection of data causes the client to be unresponsive for many seconds or minutes - with TxServer the first data is visible almost instantly.
Equally importantly, data delivered to the client for an ongoing request is cached "behind" in the server so that the client is not required to cache the entirety of the request - for very large requests this improves performance noticeably.
Every large transaction processing environment needs some level of batch processing. There are several different types. One is the typical end-of-day or end-of-month type of process, such as daily accounting calculation and roll. Another is "back-end" processing that is done to finish the processing of data entry transactions that must be done in real time.
TxServer provides a way of handling batch processing unattended (without involving a client workstation) : the drone process.
A drone is a special instance of application execution that runs under a special client supervisor in the server - it has no user interface but otherwise is a perfectly normal part of the application. Drones can be set to start a particular times of the day (for daily and month-end processing) or can be always present, but quiescent until triggered by a database event (for back-end processing of entered transactions).
The system manager can assign as many drones as needed to these types of processing.
Once an application is built, (or even before it is finished), requirements will change. TxServer provides the flexibility needed to deal with change rapidly, while helping to minimize the impact the changes may have on the application as a whole. Most importantly, TxServer ensures the integrity of installed databases when the new version of the application is deployed.
Database structure
When changes to the data definitions source code require changes to the database, TxServer automatically requires the database to be restructured to match the new schema. But in the real world of application distribution, not every server running a given application is running the same version of that application - in fact, it is very common for a large set of customers to be running 3 or 4 different versions of the same application. So, it is not sufficient to simply upgrade the database - TxServer must also track which version of the application is installed. TxServer automatically tracks database versions - when a new version of the application ( database schema) is installed at a site, TxServer upgrades the database from its current version to the version being installed. All this tracking is automatic, making it impossible for the system manager to have mismatched schema and database.
Procedure
Application procedure and data are defined separately, and in many cases database changes do not affect application logic. In cases where there is an effect, TxServer forces recompilation of the affected procedures to ensure compatibility at all times between procedure runtime and database structure.
Presentation
When database changes require corresponding changes to the forms and reports, TxServer automatically adjusts the existing forms and reports to bring them in line with the changes.
Presentation logic is largely independent of the procedure, so that changing the appearance of forms and reports often requires no changes to the application. In fact, some TxServer applications are specifically designed to take advantage of this, and have different versions of the forms (but the same database and procedure) for different users.
Scalability
As the size of the database grows, or the transaction volume increases, or the number of client workstations increases, no changes to the application are required. A TxServer starter system with 4 clients can be upgraded to a full-blown 256-user system with no changes to the application whatsoever. Applications developed for the smallest TxServer systems can be run on any sized runtime system. This scalability is built in.
TxServer insulates the application and database from hardware and software failures in a variety of ways.
True transaction processing
The TDL language provides for true transaction bundling of multiple updates to the database. Any failure during the execution of a transaction leaves the database in the state it was in prior to beginning the transaction. This is a common feature of modern databases. What is unusual in client/server systems is that transactions are bundled in the client also - after a failure the application state is restored to that of the beginning of the transaction.
Operating system failure protection
In most modern client/server systems, software failure of the underlying operating system usually results in the equivalent of the infamous "blue screen" - application databases are not closed cleanly and must roll themselves back to an internal restore point. In TxServer, a system crash closes all database files cleanly, so the database needs no rollback.
Journaling protects against hardware failures
To protect against power failure or hardware errors, TxServer journals database transactions to a medium separate from the database. After a system failure, the system manager restores a previous database backup and rolls the journal forward.
Hot backup
With TxServer, system managers do not need to shut down the database when performing backup - databases can be backed up while the application is running normally. This type of backup can therefore be run continuously if desired, creating up-to-the-hour restore points in case of hardware failure.
Concurrency
In situations where multiple clients request access to the same data, the system must ensure integrity of this concurrent data. TxServer has no complicated locking schemes, unlike virtually all other database systems in the market. TxServer does not lock records in the database, since this is extremely costly in terms of performance. Instead, TxServer uses what is called "optimistic locking", which gives each client its own copy of the data when requested. This is similar to the way airline reservation systems operate. Prior to executing a transaction, the server checks to ensure that the submitted data has not been modified by another process since this client fetched it. In the rare case where this is true, the transaction is aborted and the client retries it. If this is an on-screen operation, the user is informed and shown the new data, just as in airline reservations. Applications which are designed from the ground up to utilize this paradigm handle the rare transaction aborts gracefully, and execute much faster than those which use locking.
TxServer is TCP/IP-compliant, so it integrates perfectly with existing networks, as well as using all the remote addressability inherent in the IP protocol. Servers and clients can be located on a local network and/or distributed over a WAN.
TxServer servers can be configured to intercommunicate. This very useful in in corporate environments, where clients can connect to one server but run an application located on another server, thus allowing clients a single "entry point" into the corporate network.
Servers can also be configured to use a single external or TxServer server as a time server, not only getting date and time information but also daylight saving rules from the time server. Readers in the USA will recall the recent change of daylight saving rules in 2007, which caused so much grief for system managers nationwide as they were forced to configure non-TxServer clients and servers individually to conform to the new rules. One large TxServer customer, who has a large corporate network with a variety of server software vendors, ended that weekend by saying "TxServer was the only system that got this right and allowed me configure a single server with the new rules".
Getting good performance with client/server on a speedy local network is one thing. But today's reality is that many corporate networks include large populations of remote users - in locations which are geographically remote from the server, and whose connection to the server lacks the bandwidth of the local network.
Other modern client/server products will function remotely, usually by means of some remote-access feature in the underlying OS. But in every case there is a substantial loss of performance, because the application runtime system is not designed to handle this kind of configuration.
TxServer, on the other hand, was designed specifically to avoid performance loss over slow networks. It does this by offering a "split" version of the client supervisor TxS. One end of the pair runs in the server (or in another server on the local network), where it is within local network reach of the server's client services; this part runs the portions of the application that need high-speed interaction with the database. The other end runs in the client, and handles all the presentation. Communication between the two ends is optimized for high performance. The bottom line is that over slow networks this configuration is the speediest in the marketplace.
The best part of TxServer remote access is that no application changes whatsoever are required - the application is not even aware of being run in this configuration. This is only possible because of TxServer's high level of integration - TxS provides a complete environment for the running application, making it insensitive to whether it is running in the server or client.
TxServer systems have extremely low cost of ownership.
The development suite allows applications to be constructed in less time and with fewer people, and with very low application maintenance costs.
Because TxServer is an integrated system, users are saved the effort and ongoing expense of integrating operating system, database server, transaction manager, communications facilities and front-end client tools as is required on other platforms.
The unique architecture produces higher throughput, which allows TxServer installations to use less server hardware, and less expensive client hardware (TxS is a 32-bit application which runs on Windows, but it uses resources very sparingly and so can run on relatively thin clients).
TxServer is the only complete product in the marketplace specifically designed for mission critical transaction processing in a client/server environment. It is the only transaction processing product to supply a robust runtime environment together with an integrated set of development tools.
TxServer delivers the superior performance, flexibility, and integrity needed for mission-critical applications - and it delivers this at very low cost.