Client/Server Architecture

The most common model of a distributed application is the client/server application model:

A client/server application runs the client processes separately from the server processes, usually on a different computer. The main points of a client/server application are:

• The client processes provide an interface for the user, and gather and present data, usually either on a screen on the user's computer or in a printed report. This part of the application is also called the user tier or the presentation layer.
• The server processes provide an interface with the data store. It is, for this reason, also called the data tier or the data layer.
• The logic that validates data, monitors security and permissions, and performs other business rules can be contained on either the client or the server, or split between the two.

This type of distributed application may be executed over more than one computer, although it doesn't have to be - both user tier and the data tier may be run on a single machine. The client/server model is often used with database programs where a front end program, often designed in Visual Basic or Microsoft Access, is used to present the user with data that is acquired from a database server.

A client/server application is an example of a 2-tier distributed application. The logic for client/server applications can also be designed to form a separate middle tier instead of running either in the client or the server or being split between the two applications. This middle tier is often called the business tier or the business logic layer. Client/server applications that are designed this way have three logical tiers but run in two physical tiers. The middle tier may be contained in either the client or the server.

The Fat and Thin Client Models

Client/server applications that are designed to run the user and business tiers of the application on the client, and the data tier on the server are known as fat client applications.

On the other hand, client/server applications that are designed to run the user tier on the client and the business and data tiers on the server are known as thin client applications. As you can see, even though such applications may be intended to run on two computers, they may implement three logical tiers.

3-Tier and n-Tier Architecture

The next logical step is to separate the tiers so that the application can be run on three separate computers. This implementation, where the user interface, business rules and data services are designed to run as three separate tiers, is known as a 3-tier application (although all 3 tiers could, if we wished, be run on a single machine).

Further refinement of the application may lead to more than three tiers being implemented. For example, the administrative functions in the case study that's designed in this book can be implemented as a separate user interface tier, or a Web interface may be provided as an alternate interface to a client based interface.

Applications that are designed to run in two or more separate tiers are known as n-tier applications, where n is the number of separate tiers (although the term is most frequently used to refer to applications that are divided into three or more tiers).

It's important to understand these models if we are to appreciate the design and programming presented in this book, since the application we'll develop is based on the 3-tier model. Let's just recap on the structure of the standard model for a 3-tier application:

• User tier - This tier presents the user interface (UI) for the application, displays data and collects user input. This tier also sends requests for data to the next tier. This tier is often known as the presentation layer.
• Business tier - This tier incorporates the business rules for the application. This middle tier receives requests for data from the user tier, evaluates them against the business rules and passes them on to the data tier. It then receives data from the data tier and passes this back to the user tier. This tier is also known as the business logic layer.
• Data tier - This tier communicates directly with the data store (SQL Server database, other type of database such as Oracle, Exchange data store, Excel workbook, etc.) and passes data between the data store and the business tier. This tier is also known as the data layer.

Benefits of N-Tier Development

One benefit of separating applications into distinct pieces is that it enables parallel development of the different tiers of the application. For example, one developer (or a team of developers) can work on the user tier, while another writes the business tier, while yet another works on the data tier.

This separation also provides encapsulation for the different tiers and components, which can result in a more robust application. Each tier (or layer) is treated as a black box by the other tiers. Only clearly defined inputs and outputs from each tier can be seen by any of the other tiers.

Using these tiers also allows for easier maintenance and support, since it's easier to change and upgrade a single specific component than to make changes in a monolithic application. If the business rules of an n-tier application are changed, it's only necessary to change the software in the business tier on one server. In a monolithic application, a change in the business rules would mean updating the software on every computer that was running the application.

Most importantly, these logical layers offer the greatest flexibility in distribution, as the tiers could reside anywhere from a single desktop to servers and clients around the world (in other words, it's easy to turn the logical tiers into physical tiers). This enables the application to scale easily from the desktop or workgroup application level to the enterprise or Web application level. It also offers the side benefit of being able to place the different tiers on computers that are optimized for roles as servers or as clients, which enhances the performance of the application.

The principal benefit of a well-designed distributed application is an application that can scale well: handle more throughput with the same performance only by adding more hardware (so no code changes are required).

Developing complex applications is not a trivial undertaking, and several studies have shown that, unfortunately, the failure rate for large software projects is unacceptably high. Using a methodical approach to developing applications can reduce the failure rate. This kind of approach is called a software development process.