A tiered architecture emphasizes structuring of an application into tiers that implement distinct features such as the presentation logic or the application logic. The architecture is typically supported by middleware frameworks that provide functions tailored to particular tiers. An example of a tiered architecture is illustrated on Figure 1.1, “Tiered Architecture Example”.
A distinct case of a tiered architecture is the two-tier architecture, which distinguishes the client tier and the server tier. The client tier implements the presentation logic, the server tier stores the application data. The application logic is split between the client and the server tier, with the case where the client tier contains most of the logic denoted as a thick-client architecture, and the case where the server tier contains most of the logic denoted as a thin-client architecture. Thick-client architectures have the potential of minimizing network communication and server workload, whereas thin-client architectures have the potential of simplifying client maintenance.
The three-tier architecture introduces a middle tier between the client tier and the server tier. The middle tier implements the application logic, which was split between the client tier and the server tier in the two-tier architecture.
Rather than being limited to two or three tiers, the architecture of a distributed application can distinguish more tiers. To give a few examples, a user tier can handle the authentication and authorization, a workspace tier can establish sessions, a resource tier can manage resource sharing resources, etc. The benefits of introducing more tiers, such as having explicit application architecture and providing increased reuse potential, are weighted against the drawbacks, most notably the architecture complexity and the associated overhead.