2-tier - also called client/server applications which consist of two separate applications, one server
application (typically a database server like Oracle, MSSQL or any other standalone database) and a client application. suppose you want to have many different clients for front-end would be unwise to copy all the business logic (all the rules of your application) to each client app. so its better to create a middle layer containing the business logic, and then let the clients talk with this middle
layer. Thus the clients can relatively easily be changed for other types of clients, without need for remembering. how was the business logic put together.
3-tier architeture where one tier is the backend database engine, one is the front end client and one is just in between them, also named the application server or business logic node.Its uses mainly Load balancing and Fault tolerance.
A good example of a tier follows the jerarquical model where responsibilities are carefully addressed to the appropriate people. For example, a common business has Commercial, Marketing, Systems, Development and Test department (for example), which represent tiers of business. That way, responsibilities are clear, Development provides the product, Testing test it, Marketing promote it and Commercial sell it, all that while systems keep the infrastructure running (is just an example).
This metaphor was first approached with the 3-tier model, where three tiers are identified. Usually this tiers are Database Abstraction Layer, which is in charge of communication and abstraction over the database, Business Rules Layer, which holds the rules that describe the business process and User Interface Layer which abstracts the interaction of the user with the system.
That way, we have roles for the responsibilities of each layer, so that if the user needs to interact with the system he will communicate with one layer, not mess up across the hole system.
N-tier represent an evolution of the former concept by using more tiers to address specific needs. Usually user interface layer and database abstraction layer are left untouched, as their roles are pretty clear while business rules layer is further refined.
For that, we always take into account the characteristics of the problem as well as the features we want to provide now and in the future. For example, if an application will need to work with smart clients or its foreseen to work with smart clients then business layer is usually divided into a proxy layer and a back-end layer, the first routing the calls where they should go.
In the end, what's important is the concept of abstracting responsibilities among different layers, and centralizing all related operations from a semantic view in the same place.
Note that, in addition, n-tier architecture allows for distribution of those "responsibilities" among developers. That way, a given team can have responsibility over the Database Abstraction Layer while other team works on the Proxy Layer and another one works on the Graphics Abstraction Layer. When a member of a team needs to access the database he look up the DAL documentation and use one of the facilities provided or ask the DAL team to provide with the functionality he needs, so that he does not address directly the database but through the people that better known the design and intricacies of the database itself.
Business applications today all access data as part of their core functionality. As relational database servers gained in popularity 20 years ago, the industry moved from a one tier (mainframe) model to a client server model where we had a client performing the presentation logic and most of the business logic and the server with the data storage and some business logic in the form of stored queries. By the early 1990s this model broke down due to high maintenance costs and a lack of a separation of concerns and we moved to a three-tier architecture as shown in Figure 1.
Figure 1. A 3-tier architecture. (Source: Wikipedia)
A three-tier architecture enforces a logical (and sometimes physical) separation of three major concerns:
- Presentation-the user interface components.
- Business Logic-processes commands requested by the users, makes logical decisions such as calculations and computations. Retrieves data from the data tier.
- Data storage and retrieval-storage and retrieval of data for the system and passes the data to the business layer for processing and ultimate rendering to the user by the presentation tier. In theory this tier can be file storage, XML, or a relational database, however, a relational database is by far the most common usage.
The goal of separating the logic is twofold. First there is a performance gain by having the database server focus only on database storage and retrieval. Specific hardware and topologies (such as RAID) are used for database storage and access that are different from an “application server” or middle tier of business objects and logic. In addition with powerful client machines it made sense to push UI processing down to the client.
Second was the separation of concerns principle. By separating out the logic of a system, you can easier maintain the overall system, reuse code, and keep associated logic and code in one location.
By the later 1990s, the industry extended the three-tier model to a multi-tier approach. The model is logically the same but what forced it to change was that the Internet became an important part of many applications.
Tiers started to get blurred ever further with the addition of stored procedures by all the major database vendors and open source databases. This spread some business logic from the business tier to the database tier, creating tiers within tiers. For example a business component inside of Microsoft Transaction Server (an Object Request Broker or ORB) is a logical business tier; however, it most likely calls a stored procedure, which is a logical business tier inside of the database tier.
As tiers got more blurred due to the Internet, technology innovations and services, the three-tier model evolved to the n-tier model as shown in an example in Figure 2.
Figure 2. An n-tier architecture. (Source MS Patterns and Practices)
The n-tier architecture has been very successful. Most sophisticated applications today use some form of the n-tier model. Years ago to support this model, enterprises would have as many as five different job titles around the data centric business application. The job titles were:
- Data Modeler
- Database Administrator
- SQL Programmer
- Object Modeler
- Application Developer
The data modeler would design the physical tables and relationships. The DBA would create the tables, maintain them and come up with an index and physical disk strategy and maintenance plan. The object modeler would build and object model (or API) and map behaviors to methods. The SQL programmer would work with the object modeler and application developer and write stored procedures and views under the guidance of the DBA. The application developer would use the object model components and would “glue” the application together.
That was then. While some large organizations still develop this way the advent of RAD tools in the late 1990s, the agile/XP movement in the early part of this decade, the .com boom, and ultimately offshoring and budget cuts, most firms do not organize this way anymore. Many smaller shops have one “database guy” (if at all) and one “code guy.” Some only have one person in total. Companies then push most of the modeling and procedure creation to the “db guy” and application developer.
With budget cuts, smaller teams, and the rise of cross-function teams there are not enough “database guys” to go around. Developers complain that they spend over 30% of an application’s code on database access code. This only exacerbates the object-relational impedance mismatch.
In 2-tier, the application logic is either buried inside the User Interface on the client or within the database on the server (or both). With two tier client/server architectures (see Two Tier Software Architectures), the user system interface is usually located in the user's desktop environment and the database management services are usually in a server that is a more powerful machine that services many clients. Processing management is split between the user system interface environment and the database management server environment. The database management server provides stored procedures and triggers
In 3-tier, the application logic (or) process lives in the middle-tier, it is separated from the data and the user interface. 3-tier systems are more scalable, robust and flexible. In addition, they can integrate data from multiple sources. In the three tier architecture, a middle tier was added between the user system interface client environment and the database management server environment. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. The middle tier can perform queuing, application execution, and database staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. In addition the middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach. Flexibility in partitioning can be a simple as "dragging and dropping" application code modules onto different computers in some three tier architectures. A limitation with three tier architectures is that the development environment is reportedly more difficult to use than the visually-oriented development of two tier applications. The most basic type of three tier architecture has a middle layer consisting of Transaction Processing (TP) monitor technology. The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client.
In a 4-tier architecture, all of the data storage and retrieval processes are logically and usually physically located on a single tier. A 4-tier architecture allows an unlimited number of programs to run simultaneously, send information to one another, use different protocols to communicate, and interact concurrently. This allows for a much more powerful application, providing many different services to many different clients. In this application we will have following 4-Tiers
1. Business Object [BO]
2. Business Access Layer [BAL]
3. Data Access Layer [DAL]
4. UI (4-Tier) folder [UI]