This article begins with a discussion of traditional 2-tier client/server architectures, along with their strengths and weaknesses. It continues by describing how hybrid 2-tier architectures can address some of the weaknesses of tradtional 2-tier architectures. Next, 3-tier/N-tier architecture are presented, along with their advantages and disadvantages. A hybrid 2-tier/3-tier architecture is then explored. This hybrid architecture derives most of the benefits of both 2-tier and 3-tier architectures.
The major topics in this article are as follows:
Traditional 2-Tier Model
The traditional 2-tier model is shown is Figure 1. It is fairly simple: client applications access the database directly. Related applications access the database directly (e.g. a separate Accounting application might need to access the Sales application's database).
Figure 1: Traditional 2-tier Application
In a traditional 2-tier application, all processing is done in the client application -- the database serves only as a repository for data. "Logic" in the server might include simple constraints (e.g. foreign key constraints, not null constraints). These database constraints disallow operations that would cause obvious data integrity problems.
The main advantages of the 2-tier model are as follows:
Applications with the following attributes are well suited to a 2-tier architecture:
The main disadvantages of the 2-tier model are as follows:
Modified 2-tier Model
A common approach that is used to improve business logic reusability is to place the business logic into triggers or stored procedures on the database. Validations are performed by calling an appropriate database stored procedure. In addition, dependent logic can be initiated by a trigger in the database. For example, the business logic might dictate that whenever a requisition is updated to "approved", a purchase order should automatically be created. This business rule could be effectively implemented with a database trigger on the requisition table.
The approach provides several advantages compared to the traditional 2-tier model:
The modified 2-tier approach addresses some of the concerns with the traditional 2-tier model but it still suffers from inherent 2-tier drawbacks. The most notable continued drawback is scalability which is addressed by the 3-tier model.
Pure 3-Tier / N-Tier Model
In the pure 3-tier / N-tier model, the application is divided into three formal tiers: the presentation tier (or GUI layer), the middle tier (or application server) and the data tier. Figure 2 shows a 3-Tier / N-Tier architecture. The key addition in this model is an application server which encapsulates the application's business logic (see sidebar on business logic). N-tier is used to describe this architecture since the application server may be implemented in one or more layers and it may be distributed in one or more places. For simplicity, the architecture will simply be referred to as "3-Tier", rather than N-Tier.
Figure 2: Pure 3-Tier/N-Tier Model
The presentation tier can include a variety of clients including standard clients (as part of a client/server application), Internet clients and reporting tools. Because business logic is implemented in the middle tier, there is relatively little duplicated effort should there be a need to provide the same function in two or more environments. For example, an Order details screen might be provided in both a client/server application and the Internet application while any business logic in the middle tier (application server) would be shared.
The presentation tier requests services from the application server but it is not limited to GUI clients. Items in the "top" tier might also include other applications that need to exchange information or data with this application.
Middle Tier (Application Server)
As mentioned earlier, the middle tier or application server might be implemented as several layers. Application servers can also be distributed on several host machines. A Transaction Processing (TP) monitor or an Object Request Broker (ORB) can be used to balance client requests across multiple database servers as well as start up/shutdown additional application server instances, as needed. Since the application server contains the business logic (where the bulk of the complex processing should occur), it is possible to support more users by adding more and faster application servers without needing to re-architect or rebuild the application.
It is not necessary to physically locate the middle tier on its own server from the beginning. In an early application release (which has a limited number of users), the middle tier might be deployed on the client machine or on the database server for simplicity. When the number of users grow (e.g. for later releases), the middle tier can then be moved onto separate server(s) so that the desired scalability benefits are obtained.
The data tier contains the database. It might also include data access procedures. The database can be placed in a single location or it can be distributed, if required.
The benefits of the 3-tier model are as follows:
The drawbacks of the 3-tier model are as follows:
Hybrid 2-tier / 3-tier model
The complexity concerns in the 3-tier model cannot be easily dismissed. In many environments, certain benefits of the 3-tier model are required. Consider a common situation where:
To meet these requirements, a hybrid 2-tier / 3-tier model could be employed (see Figure 3). In this situation, the bulk of the users would use Internet clients and/or simple client/server front ends to access data through application servers (see centre top of Figure 3) -- access through the application servers provides the scalability benefits. Similarly, related applications would exchange data through the application servers (top right of Figure 3) so that their interface could be better managed.
Figure 3: Hybrid 2-Tier / 3-Tier with Replicated Database
The bulk of the logic, however, would be built using a 2-tier model (see centre left of Figure 3). This would allow the many client/server tool productivity optimizations to be attained. 2-tier development is also easier to manage and coordinate.
One notable aspect of this model is a replicated database which is optimized for retrieval (including redundant and summarized data, where needed). This retrieval database could be used to more quickly satisfy certain requests from application servers. The retrieval database would also be the ideal place for users to access data with reporting tools.
Tool Dependence under These Models
A common issue when architecting an application is the need to avoid becoming overly dependent on the specific tools (e.g. Visual Basic or Oracle RDBMS) because these tools might need to be replaced in future. Tool dependency for the client, server and middle tier is discussed for each architectural alternative. Table 1 summarizes the dependency on tools for each architecture.
Table 1: Tool Dependency by Architecture
|Dependency||Client Tool||Server Tool||Middle Tier|
|Traditional 2-Tier||High||Low (if ANSI SQL)||N/A|
|3-Tier||Medium||Low (if ANSI SQL)||Low-to-Medium with COM or CORBA used|
In a traditional 2-tier application, both presentation and business logic is placed in the client tool. For this reason, the application is highly dependent on the client tool -- an application rewrite is essentially required if the client tool is changed. On the other hand, if standard ANSI SQL is used to access the database in a traditional 2-tier application, then it should be relatively easy to switch to a different database.
In the modified 2-tier application, triggers and stored procedures are used extensively for business logic. Since triggers and stored procedures are proprietary to each database vendor, it would be difficult to switch databases (without major rewrites). Even though the client is restricted to presentation in this model, a moderate effort would be required to port the many windows, controls, etc. to a new client tool. In general, switching the client tool in this model should require significantly less effort than a total application rewrite.
In a pure 3-tier application, considerable effort is put into keeping business logic in the middle tier or application server. If standard ANSI SQL is used to access the database (and trigger logic is minimized), then it should be relatively easy to switch the database. A client tool switch would require a fair amount of effort (like the modified 2-tier model) but the switch should require much less effort than a total application rewrite.
Does this mean that 3-tier attains the desired "tool independence"? No. The business logic is written in the middle tier language (which might include one or more of: C, C++, Java, VB/ActiveX, distributed PowerBuilder, etc.). If the middle tier language is changed, then middle tier logic must be rewritten in the new language. Fortunately, when the middle tier is developed within a standard object request paradigm (e.g. COM/DCOM or CORBA), middle tier language changes can be made transparently to the client or requester applications.
Location of Business Logic in 3-Tier Model
A key tenet of the 3-tier architecture is that "all" business logic is placed in the middle tier. In practice, it is difficult to remove all business logic from the presentation tier and data tier. Consider: the client may present a drop down list and immediately give an error message if an invalid value is selected (without referring to the application server which might want to provide a special message sometime in future). Similarly, the client may present the user with a set of radio buttons (or choices). In future, if another business option becomes available, the client presentation (and not solely the application server) will have to be changed. Another point: the client usually provides a visual cue to indicate which columns on the window are mandatory, optional, enterable and read-only. Changing a column that was previously optional so that it is now mandatory requires a change to the client and not simply a change to the validation rule in the application server.
Eradicating all business logic from the data tier is not always the best approach. Not null constraints and foreign key constraints can be considered "business rules" which should only be known to the application server. Most would agree that it is much safer/better to include such constraints in the database (and to change them, as the business rules evolve).
With the 3-tier model, the objective should be to maximize the business logic placed in the application server. There will be times when pragmatism dictates that small amounts of business logic be included in the presentation and data tiers.
... back to Architecture Topics