Client-Server Models and N-Tier Applications

One of principal objective of Client-Server methods is to provide data to an end user. However, Client-Server architectural methodologies are much more complex. Client-Server describes the process wherein a client program generates contact with a separate server for a particular reason on a networked system. The client, in these cases, is the requester for a service that the server will theoretically provide.

In the course of the past two decades, we have witnessed the evolution of large scale, complex information systems. During this period, Client-Server computing models have come to be accepted as the preferred means of architecture for the design and deployment of applications.

Client-Server Models serve as the foundation of current enabling technologies such as workflow and groupware systems.

It is for certain that in the future, Client-Server technologies will have a major effect on technological transformations. They have already had a major effect on a recent transformation, in which network computing sawed in half monolithic applications that were based on MainFrames and split them in to two components – Client and Server.

In the past, Client-Server systems have been associated with a Desktop PC computer, which is connected via a network to an SQL database server of some sort. In actuality, however, the term “Client-Server ” refers to a logical model that serves to divide tasks in to two layers marked either “Client” or “Server”.

Within the Information Technology sector, a very simple form of Client-Server computing has been practicing since the inception of the MainFrame; a Single-Tier (One-Tier) System, which consists of a MainFrame host connected directly to a terminal.

In Two-Tier Client-Server architecture, however, the client is in direct communication with the database. The application logic or business logic thus resides on one of two servers in the form of stored procedures.

The Client-Server Models initially emerged alongside the applications that were being developed for local area networks in the latter half of the ‘80s and the first half of the ‘90s. These models were mostly based on elementary file sharing techniques that had been implemented by X base style products, such as Paradox, FoxPro, Clipper, and dBase.

Fat Clients and Fat Servers

At first, the Two-Tier model required a non MainFrame as well as an intelligent fat client, which is where most of the processing would take place. This configuration was not very scalable and hence larger systems could not be accommodated. If fifty or more clients were connected, it would not function properly.

The GUI (Graphical User Interface), then came in to being as the most common desktop environment. Alongside the Graphical User Interface technology, a new form of Two-Tier architecture emerged. The LAN file server, used for general purposes, was replaced by a new, specialized database server. Thus, new development tools emerged; these included Visual Basic, Delphi, and PowerBuilder.

While a lot of the major processing operations still took place on the fat clients, datasets of info could now be delivered on to the client by utilizing Structured Query Language techniques as a means of performing requests from a database server. The server would then merely report the results of queries made.

The more complex the application becomes, the fatter the client subsequently gets. The client hardware thus must become increasingly powerful in order to be able to support it. As a result, the cost of adequate client technology can become rather prohibitive. It may in fact defeat the affordability of the application.

What is more, the footprint of the network utilizing the fat clients is incredibly large, think Bigfoot here, so there is an inevitable reduction of the network’s bandwidth as well as the number of users who can use the network in an effective manner.

Another approach often invoked in Two-Tier architecture is the thin client <-> fat server configuration. In this configuration, the user will invoke procedures that are stored at the database server. The fat server model gains performance in a more effective fashion, as the network footprint, while heavy, is still a lot lighter than the fat client method.

The negative side to this approach is that stored procedures focus on proprietary coding and customization because they rely on only one vendor’s procedure of functionality. What is more, as stored procedures tend to be buried deep in the database, every database containing a procedure has to be modified whenever there is a change made to the business logic. This can lead to major issues in the management arena, particularly when it comes to large distributed databases.

In either case, a remote database transport protocol (SQL-Net, for example) will be used to carry out the transaction. Such models require a heavy network process in order to provide mediation between the Client and Server. What is more, query transaction speed and network transaction size will both be reduced in light of the heaviness of such a transaction.

Regardless of which technique is employed, Client-Server systems were still not able to scale beyond a hundred users. This form of architecture tends not to be very well suited for mission critical applications.