From Distributed Systems by Coulouris:
Tiered architectures are complementary to layering. Whereas layering deals with the vertical organization of services into layers of abstraction, tiering is a technique to organize functionality of a given layer and place this functionality into appropriate servers and, as a secondary consideration, on to physical nodes.
Let us first examine the concepts of two- and three-tiered architecture. To illustrate this, consider the functional decomposition of a given application, as follows:
the presentation logic, which is concerned with handling user interaction and updating the view of the application as presented to the user;
the application logic, which is concerned with the detailed application-specific processing associated with the application (also referred to as the business logic, although the concept is not limited only to business applications);
the data logic, which is concerned with the persistent storage of the application, typically in a database management system.
Now, let us consider the implementation of such an application using client-server technology. The associated two-tier and three-tier solutions are presented together for comparison in Figure 2.8 (a) and (b), respectively.
In the two-tier solution, the three aspects mentioned above must be partitioned into two processes, the client and the server. This is most commonly done by splitting the application logic, with some residing in the client and the remainder in the server (although other solutions are also possible). The advantage of this scheme is low latency in terms of interaction, with only one exchange of messages to invoke an operation. The disadvantage is the splitting of application logic across a process boundary, with the consequent restriction on which parts of the logic can be directly invoked from which other part.
In the three-tier solution, there is a one-to-one mapping from logical elements to physical servers and hence, for example, the application logic is held in one place, which in turn can enhance maintainability of the software. Each tier also has a well-defined role; for example, the third tier is simply a database offering a (potentially standardized) relational service interface. The first tier can also be a simple user interface allowing intrinsic support for thin clients (as discussed below). The drawbacks are the added complexity of managing three servers and also the added network traffic and latency associated with each operation.
In figure a), supposedly for two tier solution
On client side, what is there "data manipulation" with each "view and control"? Does it belong to presentation logic, application logic, or data logic?
On server side, why is there "data management" with each "application"? Does each "data management" mean a database management system, so there are four database management systems? Do all the database management systems have to keep their databases consistent with each other?
Why does the server have two "application and data management"s, instead of one? Are there two independent applications?
Do two "application and data management"s share a database system as in b)
The quote says "in the two-tier solution, the three aspects mentioned above must be partitioned into two processes, the client and the server. This is most commonly done by splitting the application logic, with some residing in the client and the remainder in the server (although other solutions are also possible)." What is partitioned into client and server in the figure? Is the application logic split between client and server in the figure? If not, is "data management" split between client and server in the figure?
In figure b)
- Why does the server have two "application logic"s, instead of one?
