Multi-tiered Architectures and Applications Servers (Part 1)

By  David Smith

The last few years have seen a lot of change in the software industry. More and more software tools have become available to ease the job of the internal IT development staff. Typically these tools give a foundation of common functions that most applications use. This frees the developers to work on the real problems to be solved, often referred to as "business logic".

The "application server" is one of these foundation products. An application server provides a basic framework to run a business application in. It handles housekeeping chores like startup and shutdown, networking and failover. The programmer develops modules that execute within the application server's environment. In some ways, Oracle acts like an application server - it provides a framework for working with data and you can develop applications that execute inside of it.

Application servers have been around for six or seven years, however they were not heavily used until the introduction of Java and the Enterprise Java Beans (EJB) specification in 1998. Java really enabled application servers to take off; application servers based on C and C++ could be crashed too easily by poorly written code.

Multi-tiered architectures

In order to understand the role of an application server it helps to understand the kind of systems architecture it is designed to fit into. When designing large scale IT systems we talk about multi-tiered architectures today. A multi-tiered architecture is one where the functionality of the application is spread across multiple layers or tiers, each typically executing in its own server.

A single-tiered architecture is one where everything executes together in one monolithic server. A example of this is the classic Oracle configuration where users at dumb terminals interact with the SQL*Plus command line interface. In this example, the application is coded in PL/SQL and all of the application resides together in the Oracle RDBMS. First generation client-server systems are two-tiered architectures. The user has a PC or workstation that runs a client program that interacts with the RDBMS.

Also, many first generation web systems are two-tiered. The web server connects to an RDBMS and the code on the web server executes queries, inserts, etc. with the database.

Finally, more and more larger scale web sites and internal applications are moving to a three-tiered architecture. In this architecture, the web server or client program makes requests to a server that executes the application logic (often referred to as "business logic"). The intermediate server executes queries, inserts, etc. with the database. Using an application server allows a developer to concentrate on the "business logic" rather than all of the housekeeping details involved in that intermediate server.

Why would a developer want to move to a three-tiered architecture? Although the three-tiered architecture is more complex it also brings significant benefits.

First, scalability. In a single-tiered application, all of the business logic executes in the RDBMS. As the application logic grows more complex, more CPU power and memory must be added to the RDBMS server machine to handle processing the application logic, even if the number of actual database operations does not grow. In a two-tiered application, more of the processing can be pushed out to the client machines, however the client machines cannot share information. Also, updating the software on all of the client machines can be difficult.

Second, separation of functionality. The three-tiered model allows the data access logic (talking to the database) to be separated from the business logic. The presentation logic which interacts with the user is separated from the first two functions. This lets you split the project across multiple groups. If you have separated your functions properly, you also reduce the risk of making changes to the code. In a one or two-tiered application, changing the "presentation logic" (the part that formats data for the user and interacts with the user) runs the risk of breaking the core components because the presentation logic and the application logic are mingled together.

Third, security. Having the web server connect directly to the database can lead to major security holes. Putting an application logic server in between can allow you to make a much more secure architecture. For proper security you must design the API to the application logic properly (narrow range of functions, don't pass SQL code through the API) and place each tier onto its own network separated by firewalls.

Fourth, flexibility. It's possible to develop multiple clients for the application logic. One could be a GUI interface for internal users, another the web based interface and a third could be applications that do automated tasks.

Three-tiered applications aren't for everyone. Before diving into one you should have a clear design for what you are doing and a lot of programming and architecture expertise.

Next Time

Next time we will look at how the application server actually makes your life easier in the three-tiered environment.

© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.