CST Architecture

First generation systems are 2-tiered architectures where a client presents a graphical user interface (GUI) to the user, and acts according to the user's actions to perform requests of a database server running on a different machine.
2-Tier Architectures
Client/server applications started with a simple, 2-tiered model consisting of a client and an application server. The most common implementation is a 'fat' client - 'thin' server architecture, placing application logic in the client. (Figure 1) The database simply reports the results of queries implemented via dynamic SQL using a call level interface (CLI) such as Microsoft's Open Database Connectivity (ODBC).

Figure 1. Traditional Fat Client/Server Deployment
An alternate approach is to use thin client - fat server waylays that invokes procedures stored at the database server. (Figure 2) The term thin client generally refers to user devices whose functionality is minimized, either to reduce the cost of ownership per desktop or to provide more user flexibility and mobility. In either case, presentation is handled exclusively by the client, processing is split between client and server, and data is stored on and accessed through the server. Remote database transport protocols such as SQL-Net are used to carry the transaction. The network 'footprint' is very large per query so that the effective bandwidth of the network, and thus the corresponding number of users who can effectively use the network, is reduced. Furthermore, network transaction size and query transaction speed is slowed by this heavy interaction. These architectures are not intended for mission critical applications.
Figure 2. Thin Client/Server Deployment
Development tools that generate 2-tiered fat client implementations include PowerBuilder, Delphi, Visual Basic, and Uniface. The fat server approach, using stored procedures is more effective in gaining performance, because the network footprint, although still heavy, is lighter than that of a fat client.
Advantages of 2-Tier System
Good application development speed
Most tools for 2-tier are very robust
Two-tier architectures work well in relatively homogeneous environments with fairly static business rules
A new generation of client/server implementation takes this a step further and adds a middle tier to achieve a '3-tier' architecture. Generally, client-server can be implemented in an 'N-tier' architecture where application logic is partitioned. This leads to faster network communications, greater reliability, and greater overall performance.
3-Tier Architectures
Enhancement of network performance is possible in the alternative 'N-tier' client-server architecture. Inserting a middle tier in between a client and server achieves a 3-tier configuration. The components of three-tiered architecture are divided into three layers: a presentation layer, functionality layer, and data layer, which must be logically separate. (Figure 3) The 3-tier architecture attempts to overcome some of the limitations of 2-tier schemes by separating presentation, processing, and data into separate distinct entities. The middle-tier servers are typically coded in a highly portable, non-proprietary language such as C. Middle-tier functionality servers may be multithreaded and can be accessed by multiple clients, even those from separate applications.
Figure 3. 3-Tiered Application Architecture
The client interacts with the middle tier via a standard protocol such as DLL, API, or RPC. The middle-tier interacts with the server via standard database protocols. The middle-tier contains most of the application logic, translating client calls into database queries and other actions, and translating data from the database into client data in return. If the middle tier is located on the same host as the database, it can be tightly bound to the database via an embedded 3gl interface. This yields a very highly controlled and high performance interaction, thus avoiding the costly processing and network overhead of SQL-Net, ODBC, or other CLIs. Furthermore, the middle tier can be distributed to a third host to gain processing power capability.
Advantages of 3-Tier Architecture
RPC calls provide greater overall system flexibility than SQL calls in 2-tier architectures
3-tier presentation client is not required to understand SQL. This allows firms to access legacy data, and simplifies the introduction of new data base technologies
Provides for more flexible resource allocation
Modularly designed middle-tier code modules can be reused by several applications
3-tier systems such as Open Software Foundation's Distributed Computing Environment (OSF/DCE) offers additional features to support distributed applications development
As more users access applications remotely for business-critical functions, the ability of servers to scale becomes the key determinant of end-to-end performance. There are several ways to address this ever-increasing load on servers. Three techniques are widely used:
Upsizing the servers
Deploying clustered servers
Partitioning server functions into a "tiered" arrangement
N-Tier Architectures
The 3-tier architecture can be extended to N-tiers when the middle tier provides connections to various types of services, integrating and coupling them to the client, and to each other. Partitioning the application logic among various hosts can also create an N-tiered system. Encapsulation of distributed functionality in such a manner provides significant advantages such as reusability, and thus reliability.
As applications become Web-oriented, Web server front ends can be used to offload the networking required to service user requests, providing more scalability and introducing points of functional optimization. In this architecture (Figure 4), the client sends HTTP requests for content and presents the responses provided by the application system. On receiving requests, the Web server either returns the content directly or passes it on to a specific application server. The application server might then run CGI scripts for dynamic content, parse database requests, or assemble formatted responses to client queries, accessing dates or files as needed from a back-end database server or a file server.
Figure 4. Web-Oriented N-Tiered Architecture
By segregating each function, system bottlenecks can be more easily identified and cleared by scaling the particular layer that is causing the bottleneck. For example, if the Web server layer is the bottleneck, multiple Web servers can be deployed, with an appropriate server load-balancing solution to ensure effective load balancing across the servers (Figure 5).
Figure 5. Four-Tiered Architecture with Server Load Balancing
The N-tiered approach has several benefits:
Different aspects of the application can be developed and rolled out independently
Servers can be optimized separately for database and application server functions
Servers can be sized appropriately for the requirements of each tier of the architecture
More overall server horsepower can be deployed
The client's responsibility is usually to:
Handle the user interface.
Translate the user's request into the desired protocol.
Send the request to the server.
Wait for the server's response.
Translate the response into "human-readable" results.
Present the results to the user.
The server's functions include:
Listen for a client's query.
Process that query.
Return the results back to the client.
A typical client/server interaction goes like this:
The user runs client software to create a query.
The client connects to the server.
The client sends the query to the server.
The server analyzes the query.
The server computes the results of the query.
The server sends the results to the client.
The client presents the results to the user.
Repeat as necessary.
A typical client/server interaction
This client/server interaction is a lot like going to a French restaurant. At the restaurant, you (the user) are presented with a menu of choices by the waiter (the client). After making your selections, the waiter takes note of your choices, translates them into French, and presents them to the French chef (the server) in the kitchen. After the chef prepares your meal, the waiter returns with your diner (the results). Hopefully, the waiter returns with the items you selected, but not always; sometimes things get "lost in the translation."
Flexible user interface development is the most obvious advantage of client/server computing. It is possible to create an interface that is independent of the server hosting the data. Therefore, the user interface of a client/server application can be written on a Macintosh and the server can be written on a mainframe. Clients could be also written for DOS- or UNIX-based computers. This allows information to be stored in a central server and disseminated to different types of remote computers. Since the user interface is the responsibility of the client, the server has more computing resources to spend on analyzing queries and disseminating information. This is another major advantage of client/server computing; it tends to use the strengths of divergent computing platforms to create more powerful applications. Although its computing and storage capabilities are dwarfed by those of the mainframe, there is no reason why a Macintosh could not be used as a server for less demanding applications.
In short, client/server computing provides a mechanism for disparate computers to cooperate on a single computing task.