Benefits of using the n-tiered approach for web applications

The concept of tiered architectures in application development is evolving from a 1- tier approach to an n-tiered approach. While all approaches have their benefits, the nature of web-based applications lend themselves to an n-tiered approach.

This article describes some basic tiered architectures and explains some of the benefits of adopting an n-tiered approach to web application development.

Before delving into explanations of the various tiered architecture, an important first step is to clarify what exactly "architecture" represents. In the context of this article, architecture refers to the blue print, or the underlying schematics used to map out or design a web application. The basic concept of a tiered architecture involves breaking up an application into logical chunks, or tiers, each of which is assigned general or specific roles. Tiers can be located on different machines or on the same machine where they are virtually or conceptually separate from one another. The more tiers used, the more specific each tier's role. How many tiers? A 1-tier architecture is the most basic setup because it involves a single tier on a single machine. Think of an application that runs on your PC: Everything you need to run the application (data storage, business logic, user interface, and so forth) is wrapped up together. An example of a 1-tiered application is a basic word processor or a desktop file utility program. Although the 1-tier approach is a simple design that's easy to distribute, it does not scale well. In addition, because you are limited to running the entire application (including the user interface) on single machine, a 1-tier architecture does not adequately address the needs of a web-based application. A 2-tier architecture is the basic terminal-to-server or browser-to-server relationship. You could have a "smart" client that performs most of the work talking to a "dumb" server; or, more commonly, a "dumb" client talking to a "smart" server. Sometimes you have both. In essence, the client handles the display, the server handles the database, and the business logic is contained on one or both of the two tiers. An example of a 2-tier approach is the basic web model where a web server serves pages to a web browser. Another example of a 2-tier approach is a specialized terminal-to-server application. Although the 2-tier approach increases scalability and separates the display and database layers, it does not truly separate the application into highly specialized, functional layers. Because of this lack of specialization, most applications quickly outgrow this model. A 3-tier architecture is the most common approach used for web applications today. In the typical example of this model, the web browser acts as the client, an application server (such as Macromedia ColdFusion) handles the business logic, and a separate tier (such as Oracle or MySQL database servers) handles database functions. Although the 3-tier approach increases scalability and introduces a separation of business logic from the display and database layers, it does not truly separate the application into specialized, functional layers. For prototype or simple web applications, a 3-tier architecture may be sufficient. However, with complex demands placed on web applications, a 3-tiered approach falls short in several key areas, including flexibility and scalability. These shortcomings occur mainly because the business logic tier is still too broad- it has too many functions grouped into one tier that could be separated out into a finer grained model.

This is where an n-tier architecture can provide a suitable structure for your application. The letter "n" stands for any number of tiers. Traditionally, it starts with a basic 3-tier model and expands on it to allow for greater performance, scalability, and a host of other benefits. The single most important benefit of an n-tiered architecture, compared to a 3-tier approach, is breaking up the business logic from the application-server level into a more fine-grained model. More details on this and other benefits of an n-tiered architecture are discussed below. Example of an n-tiered architecture This example shows a generic shopping-cart web application. The tiers used for this example include the client, presentation, business logic, integration, and data. The client tier represents how the user interacts with your sample application. Because this is a web-based application, the client will use a browser for this task. For a rich user experience, you might use Macromedia Flash MX. Additionally, the Macromedia Flash MX footprint is small and you can include auto-detection and auto-installation so that requiring it in your application is seamless to the user. The presentation tier represents the dynamic creation of display code (HTML) that is sent to the user's browser. This layer dynamically displays information, such as merchandise and the contents of your shopping cart. It communicates with the other tiers by way of outputting the results to the client tier (browser) and all other tiers by calling custom tags, calling database stored procedure, invoking ColdFusion components (CFCs), calling Enterprise JavaBeans (EJBs), calling web services, and so forth. This layer is the glue that holds the entire application together. It binds all of the tiers and ensures that the client sees what was requested in the browser. A typical tool for this tier is an application server, such as Macromedia ColdFusion or Macromedia JRun. As I mentioned before, you may want to use Macromedia Flash MX. The business logic tier represents the core functionality of your application. It performs low-level code and number crunching. In the shopping-cart example, business logic calculates sales tax and shipping costs and performs credit card authorizations. Pull this logic out of the presentation tier and place it into its own tier. Common tools you can use to encapsulate business logic include EJBs, web services, database stored procedures, CFCs, or very specialized JavaServer Pages (JSP) or ColdFusion custom tags or templates. The integration tier encapsulates the functionality required for an application to talk to the data tier, or sometimes the business logic tier, in an easy-to-use format. This way, a developer working on the presentation tier can focus on HTML and output, and simply call the custom tag, CFC, EJB, web service, and so forth, without knowing the low-level details of database interaction or object invocation. Furthermore, if you change database vendors you won't break any presentation tier code that may include vendor-specific functionality. Simply adjust your custom tag library and let the presentation-tier developers focus on presentation content. Some common tools you can use to build the integration tier are CFCs, web services, ColdFusion custom tags, or JSP custom tags. For example, in a shopping-cart application, you might have a simple custom tag that hides all of the complexities of querying a database to get detailed inventory information. The data tier is the final tier of your application. The most common solutions for this level are database servers such as Oracle, MySQL, and Microsoft SQL Server. Pulling your data into its own tier is one of the most important steps you can take to break up an application. Not only does it keep the data neutral (not tied into your application server or business logic, and so forth), but it has the added benefit of improved performance and scalability. As your data needs increase, you can move this tier to its own (or a more powerful) machine and eventually to its own cluster of machines. Applying an n-tiered architecture to a sample application The following example illustrates how all of the tiers would work together in the fictional shopping-cart application. This example focuses specifically on what takes place behind the scenes to calculate and display sales tax for an order. First, the presentation tier calls a business tier custom tag, EJB, CFC, and so forth that performs a series of calculations on the contents of the shopping cart to compute a total sales price. The business logic tier pulls up the appropriate tax rate from the database by working with the integration tier (a custom tag, CFC, and so forth). A simple call to the integration tier masks the complexities of talking to the data tier and retrieves the required tax rate so that the business logic can finish its task. Once the business logic tier calculates the sales tax, the presentation tier takes over and formats the results and passes it to the client tier (web browser) for display.

Benefits of an n-tiered model Separating the responsibilities of an application into multiple tiers makes it easier to scale the application. For example, look again at the sample shopping-cart application. If you are on a limited budget, begin by running all the tiers on a single machine. As traffic increases and performance starts to suffer, separate each tier on its own machine and eventually cluster some or all of the tiers on multiple machines. An n-tiered architecture allows you to separate the workload better for developers. By breaking design into tiers, developers with different specialties can focus on a tier that best suits their skill set. You can let your graphic artists and Macromedia Flash experts focus on the presentation tier, while the Oracle database administrator focuses on the data tier and database-stored procedures. An n-tiered model also makes an application more readable and its components more reusable. By separating an application into tiers you make it much harder to fall into the trap of writing spaghetti code-which refers to huge line counts of code with a complex, tangled control structure and deeply nested if-then statements. Simply put, you can only place so much logic on a single template before readability and maintainability suffer. Also, it's easier to port a custom tag library, CFC, or EJB to a new application than directly by cutting and pasting logic from a messy template. Finally, an n-tiered approach makes your applications more robust by eliminating a single point of failure. For example, if you decide to change database vendors you won't have to hunt through every single template of your application to make the necessary changes. Simply replace the data tier and adjust the applicable portions of the integration tier to query the new database. You will not break the business logic or, more importantly, presentation tier code. Suppose your user interface requirements change. To take advantage of Macromedia Flash in the new user interface, simply replace the applicable portions of the presentation layer. No other tiers are broken or need to be modified based on the presentation layer changes. If you were still using a 3-tier architecture where your business logic is intermingled with your presentation logic, you would have to hunt and pick over most of your code in order to implement this type of a change. The concept of tiered architectures in application development has evolved from one tier to n tiers. While all approaches have their benefits, the nature of web-based applications lend themselves to an n-tiered approach. You can let specific parts of your team focus on their specialties and create highly scalable, reusable, and robust applications.