Designing Two-Tier IIS Applications

Typically, any application that communicates with resources can be categorized as either a client or a server application. The client application requests services and data from the server application, and the server application responds to client's request.

Early two-tier (client/server) applications were developed to access large databases where the client application contained a user interface and knew about the rules used to manipulate the data, and the server's task was simply to process as many requests for data storage and retrieval as possible.

Two-tier applications perform many of the functions of stand-alone systems:

  1. They present a user interface.

  2. They gather and process user input.

  3. They perform the requested processing.

  4. They report the status of the request.

This sequence of commands can be repeated as many times as necessary. Because servers provide only access to the data, the client uses its local resources to perform most of the processing. The client application must contain information about where the data resides and how it is organized in the database. Once the data has been retrieved, the client is responsible for formatting and displaying it to the user. For example, every teller at a bank uses the same client application to update a bank account, but the account information (balance, transaction dates) is stored in a database managed by a single server application.

One major advantage of the client/server model was that by allowing multiple users to simultaneously access the same application data, updates from one computer were instantly made available to all computers that had access to the server. However, as the number of clients increased, the server would quickly become overwhelmed with client requests. Also, because much of the processing logic was tied to a monolithic suite of applications, changes in business rules led to expensive and time-consuming alterations to source code. Although the ease and flexibility of two-tier products continue to drive many small-scale business applications, the need for faster data access and more rapid developmental timelines has persuaded systems developers to seek out a new way of creating distributed applications.