An introduction to web applications architecture

1.2 Multi-tier architecture

The approach of splitting an application into tiers can be taken further. Both the client and the server parts can be further subdivided if this is appropriate for the application. The client, for example, may be responsible both for some processing of data received and for the presentation of information. In the example of a bookshop, we may need to calculate the total cost of an order and display sample content of books. These two functions might be separated into two tiers at the client end.
The server software might include one or more data stores (for instance, in the form of a database system). In the example of a bookshop, one data store might include the images, cost and reviews of a book; another might be used to store more dynamic information, such as the current stock levels or order time for each book. Splitting data up in this way would, for example, allow occasional backups of the more static data with more frequent backups of the dynamic data.
So, an architecture used over the internet might look in outline like that shown in Figure 2. Here we have added two more tiers on the server side: a data tier and another tier that handles interactions with the data tier, such as retrieving requested information or validating data that is put into the data stores. This tier, between the data tier and the server tier, is sometimes termed the ‘middle tier’ or middleware. An application that uses middleware to handle data requests between a user and a database is said to employ multi-tier architecture.
Start of Figure

Figure 2 Example of multi-tier architecture
View description - Figure 2 Example of multi-tier architecture
End of Figure
Quite commonly, ‘multi-tier architecture’ refers to what should more specifically be called three-tier architecture (client, server and data tiers). More tiers than this, however, can be used (as in Figure 2) and so the term ‘N-tier architecture’ is used generally to mean any architecture that has more than two tiers.
As in the two-tier approach, there are advantages to breaking down the application into multiple tiers. Each tier can be changed more easily as it is less dependent on the precise details of the other tiers with which it interacts. This again depends on how careful we are to adopt an approach that ensures the tiers or components are truly loosely coupled. Simply breaking the application into chunks doesn’t guarantee this; we also need to adopt suitable standards, and specify precise and limited interactions between the tiers. N-tier architecture has almost become an all-pervasive approach, and is certainly very mainstream. Many more clients besides web browsers are now available that can realistically be interchanged without prohibitive effort, including databases and web servers.