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
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.
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
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 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.
January , 2003
The Newsletter of the
Tokyo PC Users Group
Tokyo PC Users Group,
Post Office Box 103,
Shibuya-Ku, Tokyo 150-8691, JAPAN