3 tire architecture in a web application development

After reading this article you can get the basic idea about three tire architecture in a web application.

A web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment (e.g. a Java applet) or coded in a browser-supported language (such as JavaScript, combined with a browser-rendered markup language like HTML) and reliant on a common web browser to render the application executable.

Web Applications are usually broken into logical chunks called "tiers", where every tier is assigned a role. We know Traditional applications consist only of 1 tier, which resides on the client machine, but  in case of web applications lend themselves to a n-tiered approach by nature.

Though many variations are possible in web application developments, the most common structure is the three-tiered application.

In its most common form, the three tiers are called presentation, application and storage, in this order.

A web browser is the first tier (presentation),For presentation tire you can use HTML,XHTML,DHTML,CSS,JavaScript (client site scripting).

An engine using some dynamic Web content technology (such as ASP, ASP.NET, CGI, ColdFusion, JSP/Java, PHP, Perl, Python, Ruby on Rails or Struts2) is the middle tier (application logic), and a database is the third tier (storage. Such as MySQL)

See the picture to know more about 3 tire architecture



The web browser sends requests to the middle tier, which services them by making queries (SQL) and updates against the database and generates a user interface.



For more complex applications, a 3-tier solution may fall short, and you may need a n-tiered approach, where the greatest benefit is breaking the business logic, which resides on the application tier, into a more fine-grained model Or adding an integration tier that separates the data tier from the rest of tiers by providing an easy-to-use interface to access the data. For example, you would access the user data by calling a "list_users()" function instead of making a SQL query directly against the user_info table on the database. That allows you to replace the underlying database without changing the other tiers.

The client would handle the presentation tier, the server would have the database (storage tier), and the business logic (application tier) would be on one of them or on both.

While this increases the scalability of the applications and separates the display and the database, it still doesn't allow for true specialization of layers, so most applications will outgrow this model.