| Lesson 4 | Three-tier architecture |
| Objective | Describe the Architectural Layering in a Three-Tier Approach. |
Describe the Architectural Layering in a Three-Tier Approach
The move to three tiers
In the lesson on two-tier architecture you learned how a system could be partitioned into two segments.
The reasoning that guided the partitioning process followed the principles of high cohesion and loose coupling. This reasoning identified a problem with the two-tier approach.
The problem is that the logic that controls the system was split between the client applicati0on and the central computer. This setup resulted in redundancy between the two tiers and between systems. Furthermore, a great deal of the logic in a system is very standard in the form of transactions; the same standard transactions may be used by many client applications. Following our simple pattern, why not split the system again and put all of this commonly used logic into its own partition?
Then you could provide an interface to it for all of the client applications.
The reasoning that guided the partitioning process followed the principles of high cohesion and loose coupling. This reasoning identified a problem with the two-tier approach.
The problem is that the logic that controls the system was split between the client applicati0on and the central computer. This setup resulted in redundancy between the two tiers and between systems. Furthermore, a great deal of the logic in a system is very standard in the form of transactions; the same standard transactions may be used by many client applications. Following our simple pattern, why not split the system again and put all of this commonly used logic into its own partition?
Then you could provide an interface to it for all of the client applications.
The result is a high degree of reuse (of the business logic) and simpler, less intelligent client applications. The client application does not need to know very much business logic.
They only need to know what transactions (or services) are available and valid for what they are helping the user accomplish.
Systems Analysis Design
Choosing between Two-Tier and Three-Tier
| Three-Tier | Two-Tier |
|---|---|
| Number of users | |
| Large or unknown number of users: The users may be unknown in advance or the number of users is very large. Either situation makes it difficult to anticipate the user interface design requirements. | Limited number of users: Few users will require access to the application. This might be because the application is very specialized or because there is a need for a higher degree of security. |
| Interfaces | |
| Diverse users requiring alternative interfaces: The users are diverse and consensus would be difficult if not impossible. The interface needs to provide some degree of versioning or customization. The best way to provide this is to separate the interface from the application logic. | Standard interface: The user interface is well-defined and standardized. Changes are limited or easily controlled through access to the known group of users. |
| Implementation | |
| Distributed implementation: The application needs to be installed in a number of locations. Likewise, the data might be separated by location. For example, regional sales may be stored in the regions rather than centralized. | Local implementation: The application will only be used in one, or a few, predetermined locations. |
| Workstation configurations | |
| Unknown or uncontrollable user workstation configurations: You have no control over the type of workstation or the configuration of the workstations. | Control of the user workstation configurations: The client resources will be configured to handle most of the processing for the application. The resources can be controlled if the application requirements change. |
Encapsulation
Another benefit arises from this approach to system architecture. Each partition encapsulates a discrete set of functions. The internal workings of each partition are hidden from other parts of the system. Hiding the internal design allows developers to alter
the internal design of one partition without interfering with other partitions. For example, the database could change or the business logic service could be rerouted to another server without the client application ever knowing or caring.
