Description of 1-Tier ,2-Tier and 3-Tier Web Applications

Description of 1-Tier and 2-Tier Web Applications

Client-Server environments. Perhaps the most influential Client-Server environment is the Internet and its global users. With the increasing use of web applications, an examination of the best architecture to support web applications is timely. The architectural component of this discussion will focus on the underlying structures and schematics that best build web applications. Specifically, we will be discussing tier architecture, which is the breaking down of an application into logical chunks that are called Tiers. Tiers can exist on the same computer and be connected virtually or logically or on different machines.

The simplest examples of tier architecture are enumerated as 1-Tier, 2-Tier, and 3-Tier. 1-Tier Architecture is the simplest, single tier on single user, and is the equivalent of running an application on a personal computer. All the required component to run the application are located within it. User interface, business logic, and data storage are all located on the same machine. They are the easiest to design, but the least scalable. Because they are not part of a network, they are useless for designing web applications. 2-Tier Architectures supply a basic network between a client and a server. For example, the basic web model is a 2-Tier Architecture. A web browser makes a request from a web server, which then processes the request and returns the desired response, in this case, web pages. This approach improves scalability and divides the user interface from the data layers. However, it does not divide application layers so they can be utilized separately. This makes them difficult to update and not specialized. The entire application must be updated because layers aren’t separated.

3-Tier Architecture is most commonly used to build web applications. In this model, the browser acts like a client, middleware or an application server contains the business logic, and database servers handle data functions. This approach separates business logic from display and data. But, it does not specialize functional layers. Its fine for prototypical or very simple web applications, but it doesn’t measure up to the complexity demanded of web applications. The application server is still too broad, with too many functions grouped together. This reduces flexibility and scalability. N-Tier Architectures provide finer granularity, which provides more modules to choose from as the application is separated into smaller functions.

"Tier" can be defined as "one of two or more rows, levels, or ranks arranged one above another". So from this, we get an adapted definition of the understanding of what N-tier means and how it relates to our application architecture: "Any number of levels arranged above another, each serving distinct and separate tasks." To gain a better understanding of what is meant, let's take a look at a typical N-tier model.

The Data Tier

Since this has been deemed the Age of Information, and since all information needs to be stored, the Data Tier described above is usually an essential part. Developing a system without a data tier is possible, but I think for most applications the data tier should exist. So what is this layer? Basically, it is your Database Management System (DBMS) -- SQL Server, Access, Oracle, MySql, plain text (or binary) files, whatever you like. This tier can be as complex and comprehensive as high-end products such as SQL Server and Oracle, which do include the things like query optimization, indexing, etc., all the way down to the simplistic plain text files (and the engine to read and search these files). Some more well-known formats of structured, plain text files include CSV, XML, etc.. Notice how this layer is only intended to deal with the storage and retrieval of information. It doesn't care about how you plan on manipulating or delivering this data. This also should include your stored procedures. Do not place business logic in here, no matter how tempting.

The Presentation Logic Tier

Let's jump to the Presentation Logic Layer in Figure 1.1. You probably are familiar with this layer; it consists of our standard ASP documents, Windows forms, etc. This is the layer that provides an interface for the end user into your application. That is, it works with the results/output of the Business Tier to handle the transformation into something usable and readable by the end user. It has come to my attention that most applications have been developed for the Web with this layer talking directly to the Data Access Layer and not even implementing the Business Tier. Sometimes the Business Layer is not kept separated from the other two layers. Some applications are not consistent with the separation of these layers, and it's important that they are kept separate. A lot of developers will simply throw some SQL in their ASP (using ADO), connect to their database, get the recordset, and loop in their ASP to output the result. This is usually a very bad idea. I will discuss why later.

The Proxy Tier and the Distributed Logic

There's also that little, obscure Proxy Tier. "Proxy" by definition is "a person [object] authorized to act for another". This "object," in our context, is referring to any sort of code that is performing the actions for something else (the client). The key part of this definition is "act for another." The Proxy Layer is "acting" on behalf of the Distributed Logic layer (or end-user's requests) to provide access to the next tier, the Business Tier. Why would anyone ever need this? This facilitates our need for distributed computing. Basically it comes down to you choosing some standard method of communication between these two entities. That is, "how can the client talk to the remote server?"

This is where we find the need for the Simple Object Access Protocol (SOAP). SOAP is a very simple method for doing this. Without too many details, SOAP could be considered a standard (protocol) for accessing remote objects. It provides a way in which to have two machines "talking" or "communicating" with each other

The Client Interface

In this section of Figure 1.1 we notice that the end-user presentation (Windows forms, etc.) is connected directly to the Business Tier. A good example of this would be your applications over the Local Area Network (LAN). This is your typical, nondistributed, client-server application. Also notice that it extends over and on top of the Distributed Logic layer. This is intended to demonstrate how you could use SOAP (or some other type of distributed-computing messaging protocol) on the client to communicate with the server and have those requests be transformed into something readable and usable for the end user.

The Business Tier

This is basically where the brains of your application reside; it contains things like the business rules, data manipulation, etc. For example, if you're creating a search engine and you want to rate/weight each matching item based on some custom criteria (say a quality rating and number of times a keyword was found in the result), place this logic at this layer. This layer does NOT know anything about HTML, nor does it output it. It does NOT care about ADO or SQL, and it shouldn't have any code to access the database or the like. Those tasks are assigned to each corresponding layer above or below it.

We must gain a very basic understanding of Object-Oriented Programming (OOP) at this time and make sure you understand the important benefits of OOP. To clarify, let's look at another example, such as a shopping cart application. Think in terms of basic objects. We create an object to represent each product for sale. This Product object has the standard property getters and setters: getSize, getColor, setSize, setColor, etc. It is a super simple implementation of any generic product. Internally, it ONLY knows how to return information (getters) and understands how it can validate the data you pump into it (ONLY for its limited use). It is self-contained (encapsulation). The key here is to encapsulate all the logic related to the generic product within this object. If you ask it to "getPrice," it will return the price of the single item it represents. Also if you instruct it to "validate" or "save," it has the brains to be able to handle this, return any errors, etc.

We can plug this Product object into another object, a "Cart" object. This cart can contain and handle many Product objects. It also has getters and setters, but obviously on a more global scale. You can do something like "for each product in myCart", and enumerate (loop through) each product within. (For more information on enumeration, Now, when you call "getPrice" for the Cart object, it knows that it must enumerate each product that it has, add up the price for each, and return that single total. When we fire the "saveCart" method, it will loop for each "product" and call its "saveProduct" method, which will then hit the Data Access Tier objects and methods to persist itself over to the Data Tier.

We could also take our simple Product object, and plug it into our "Sale" object. This Sale object contains all of the items that are available for a particular sale. And the Sale object can be used for things like representing all the items on sale at a given outlet or the like. I'm sure you are beginning to understand the advantage of using an OOP environment.

Data Access Tier

This layer is where you will write some generic methods to interface with your data. For example, we will write a method for creating and opening a Connection object (internal), and another for creating and using a Command object, along with a stored procedure (with or without a return value), etc. It will also have some specific methods, such as "saveProduct," so that when the Product object calls it with the appropriate data, it can persist it to the Data Tier. This Data Layer, obviously, contains no data business rules or data manipulation/transformation logic. It is merely a reusable interface to the database.

Applying N-Tier Architecture and Example

Let’s now apply N-Tier Architecture to our shopping cart example. In this example, we will demonstrate how sales tax is calculated and displayed. The presentation tier calls the business logic tier to perform computations on the data in the shopping cart to calculate total price. The business logic tier communicates with a database (data tier) to extract the sales tax amount based on the total price.

he business logic tier is able to communicate with the data tier through the integration tier. Through encapsulation, the integration tier is able to conceal the complexities of communication. It also retrieves the right tax rate and returns it to the business logic tier. The business logic tier completes its calculations. The presentation tier formats the response through HTML and forwards it to the client or web browser, where it is displayed to the user.

Benefits of N-Tier Architecture

There are many business benefits to N-Tier Architecture. For example, a small business can begin running all tiers on a single machine. As traffic and business increases, each tier can be expanded and moved to its own machine and then clustered. This is just one example of how N-Tier Architecture improves scalability and supports cost-efficient application building.

N-Tier model also make applications more readable and reusable. It reduces the amount of spaghetti code. Custom tag libraries and EJBs are easier to port to readable applications in well-maintained templates. Reusability multiplies developer productivity and improves application maintainability. It is an important feature in web applications.

N-Tier Architectures make application more robust because there is no single point of failure. Tiers function with relative independence. For example, if a business changes database vendors, they just have to replace the data tier and adjust the integration tier to any changes that affect it. The business logic tier and the presentation tier remain unchanged. Likewise, if the presentation layer changes, this will not affect the integration or data layer. In 3-Tier Architecture all the layers exist in one and affect each other. A developer would have to pick through the entire application code to implement any changes. Again, well-designed modules allow for applications or pieces of applications to be customized and used across modules or even projects. Reusability is particularly important in web applications.

As demonstrated N-Tier Architecture offers innovations in the standard Client-Server technology that spawned the Internet itself. It is but one of many web application frameworks. These are used to develop dynamic web sites, web applications or web services. They provide database access libraries, templates, and, as previously stated code re-use. Most web application frameworks follow the Model View Controller (MVC) which separate the user interface, the business rules and the data model. They provide authentication and authorization to provide security. This allows the web server to restrict user access based on pre-determined criteria. Web application frameworks also provide a unified API (Application programming Interface). This allows web application to work with various databases without requiring any code change. These frameworks also maintain a web template system.

Finally, N-Tier Architecture helps developers build web applications because it allows developers to apply their specific skill to that part of the program that best suits their skill set. Graphic artists can focus on the presentation tier, while administrators can focus on the database tier