4D Server Architecture

Using client/server architecture, 4D Server not only stores and manages the database, it also provides services to the clients. These services are managed over a network through a system of requests and responses.

To search for a set of records, for instance, a client machine sends a query request to the server. Upon receiving the request, the server executes the query operation locally on the server machine and, when the query is completed, returns the result (the records found).

4D Server’s architecture is based on the client/server model. For many years now, client/server architecture has surpassed its older counterpart, file sharing architecture, to become the most efficient model in multi-user databases.

4D Server’s implementation of client/server architecture is similar to that used in the world of minicomputers. However, 4D Server offers two significant innovations:

• A user-friendly, graphical interface at all levels of the database
• An integrated architecture that provides increased efficiency and speed

Before the introduction of client/server architecture, multi-user systems used the file sharing model of network architecture. In this model, all users share the same data, but data management is not controlled by a central database engine. Each client machine must store a copy of the database structure and engine, while the server maintains only the software needed to share files on the network.

Under the file sharing model, each workstation performs all data modification locally. This creates excessive network traffic as each request consists of numerous network passes. The following figure is an example of the traffic created over the network when a user searches the database for every person with the last name “Smith.”

Another disadvantage of the file sharing model is the inability to use a memory cache to keep records in memory. If records were kept in memory, different users could have different versions of the same record stored in cache, leading to data inconsistency. As a result, each time a user accesses a record, it must be downloaded from the file server. This causes network traffic and increases the time necessary to access a record.

In the minicomputer world, client/server architecture is widely used for large database systems because of its efficiency and speed. In this architecture, work is divided between the server machine and the clients to improve performance.

The server contains the central database engine, which stores and manages the data. The database engine is the only software accessing the data stored on disk. When a client sends a request to the server, the server sends the result. The result can be anything from a specific record that the client will modify to a sorted list of records.

In general, most client/server architectures are called heterogeneous architectures, because the front-end applications running on the client machines and the database engine running on the server machine are two different products. In this situation, a database driver is required to act as a translator between the clients and server.

To search for a record, for example, a client sends a query request to the server. Since the database is stored on the server, the server executes the command locally on the server machine and sends the result to the client. The following figure shows the traffic created over the network when a user requests the server to search for every person with the last name “Smith” and then display the first record found.

This example illustrates two important differences between file sharing architecture and client/server architecture:

• Client/server architecture allows the use of cache: Since the engine is the only software that physically accesses data, the server can maintain a cache that keeps modified records in memory until they are written to disk. Data is sent from one central location, so the clients are assured of always receiving the latest version of a record. In addition to the data integrity this assures, the use of a central cache mechanism accelerates database operations by replacing disk access with memory access. Under the file sharing model, all access is disk access.
• Low-level database operations are performed on the server: Client/server architecture offers dramatically increased speed because low-level database manipulations, such as browsing the index and address tables, are locally executed on the server machine at the speed of the machine. In file sharing architecture, the same operations are slowed by network transfers and the limitations of the client machine.

In most client/server architectures, the client and server software consist of two separate products that require a communication layer to “speak” to one another. With 4D Server, the client/server architecture is fully integrated. 4D Server and 4D are two applications that share the same structure and communicate directly.

Since 4D Server and 4D speak the same language, the query language does not need to be translated. The division of labor between the client and the server is transparent and is managed automatically by 4D Server.

The division of labor is organized so that one request yields one response. As you can see in the diagram, the client is responsible for:

• Requests: The 4D client machine sends requests to 4D Server. These requests can be performed using the built-in editors, such as the Query and Order By editors, using the integrated 4D language or via SQL. 4D provides editors in which methods can be created and modified. It also manages method components such as variables and arrays.
• Receiving responses: The 4D client machine receives replies from 4D Server and updates the user through the user interface (different records are displayed in a form, etc.). For example, if the client requests all records with the last name “Smith,” 4D receives the records from 4D Server and displays them in a form.

The server is responsible for the following:

• Scheduling: 4D Server uses multi-tasking architecture to schedule all simultaneous connections and processes created by clients.
• Structure and data objects: 4D Server stores and manages all data and structure objects, including fields, records, forms, methods, menus, and lists.
• Cache: 4D Server maintains a cache which contains records, as well as data objects specific to particular clients, such as selections and sets.
• Low-level database operations: 4D Server performs low-level database operations, such as queries and sorts, that involve using the index and address tables.

This division of labor is extremely efficient because of the unique integration of 4D Server and 4D. The integration of 4D Server’s architecture is present at every level:

• At the request level: When 4D sends a request to 4D Server, such as a query or a sort, 4D sends a description of the query or the sort operation using the same internal structures found in 4D Server.
• At the structure or data level: When 4D and 4D Server exchange a data or structure object, both applications use the same internal format. For instance, when 4D needs a record, 4D Server sends the data exactly as it finds it in the disk or memory cache. In the same way, when 4D wants to update a record, it sends the data to 4D Server, which stores the data in cache exactly as it was received.
• At the user interface level: When 4D displays a list of records, the form used to display the records plays a role in the client/server architecture. For example, the following figure shows the result of a query in the [Customers] table.

Since the window can display only twelve records and five fields at a time, 4D Server sends exactly twelve records. Instead of sending the entire set of records, 4D Server sends only the number of records and fields that can be displayed in the window. If the user were to scroll through the form, 4D Server would send the additional records or fields as needed. This optimization reduces network traffic by ensuring that records and fields are sent over the network only when necessary.