The Evolution of Client/Server Computing   

Several years ago, many computing environments consisted of mainframes hooked to dumb terminals that only did processing at the mainframe. Over the years, personal computers started to replace these dumb terminals but the processing continued to be done on the mainframe. The improved capacity of personal computers were largely ignored or used on an individual level. With so much computing power idle, many organizations started thinking about sharing, or splitting, some of the processing demands between the mainframe and the PC. Client/server technology evolved out of this movement for greater computing control and more computing value.
 

  Client/server refers to the way in which software components interact to form a system that can be designed for multiple users. This technology is a computing architecture that forms a composite system allowing distributed computation, analysis, and presentation between PCs and one or more larger computers on a network. Each function of an application resides on the computer most capable of managing that particular function. There is no requirement that the client and server must reside on the same machine. In practice, it is quite common to place a server at one site in a local area network (LAN) and the clients at the other sites. The client, a PC or workstation, is the requesting machine and the server, a LAN file server, mini or mainframe, is the supplying machine. Clients may be running on heterogeneous operating systems and networks to make queries to the server(s).

  Networks provide connectivity between client/server and the protocols that they use to communicate. The Internet provides connectivity between systems that function as clients, servers, or both. Many services used on the Internet are based on client/server computing model. File Transfer Protocol (FTP) for example uses client/server interactions to exchange files between systems. An FTP client requests a file that resides on another system. An FTP server on the system where the file resides handles the client’s request. The server gets access to the file and sends the file back to the client’s system.

  Market researchers have projected enormous growth in the client/server area. This growth seems to have come at the expense of the mainframe market, which has stagnated. While the movement towards migrating from the mainframe to client/server architecture is gaining momentum, there are several distinct drawbacks since most of the client/server tools and methodologies are not in place and the associated administration support is still undefined.

  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

  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

  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:

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

Figure 5. Four-Tiered Architecture with Server Load Balancing

The N-tiered approach has several benefits: