One, two, three,
or n tiers? - JavaWorld January 2000
Tutorial Details:
One, two, three, or n tiers?
One, two, three, or n tiers?
By: By Alex Chaffee
Should you hold back the tiers of your application?
hate articles that make you wade through mountains of text before getting to the point. Accordingly, here is a chart summarizing the pros and cons of different architectures for distributed applications discussed in this article.
On tiers
In the beginning, life was simple. Computers were separate, individual devices. Programs had access to all the computer's input and output through computer-connected devices. With the invention of networks, life became more complicated. Now we have to write programs that depend on other programs running on faraway computers. Often, we have to write all those faraway programs as well! This is what's called distributed programming.
A brief definition: a distributed application is a system comprised of programs running on multiple host computers. The architecture of this distributed application is a sketch of the different programs, describing which programs are running on which hosts, what their responsibilities are, and what protocols determine the ways in which different parts of the system talk to one another.
Architecture
Pros
Cons
One tier
Simple
Very high performance
Self-contained
No networking -- can't access remote services
Potential for spaghetti
code
Two tiers
Clean, modular design
Less network traffic
Secure
algorithms
Can separate UI from business logic
Must design/implement protocol
Must design/implement reliable data
storage
Three tiers
Can separate UI, logic, and storage
Reliable, replicable
data
Concurrent data access via transactions
Efficient data
access
Need to buy database product
Need to hire DBA
Need to learn new
language (SQL)
Object-relational mapping is difficult
N tiers
Support multiple applications more easily
Common protocol/API
Quite inefficient
Must learn API (CORBA, RMI, etc.)
Expensive
products
More complex; thus, more potential for bugs
Harder to balance loads
The concept of tiers provides a convenient way to group different classes of architecture. Basically, if your application is running on a single computer, it has a one-tier architecture. If your application is running on two computers -- for instance, a typical Web CGI application that runs on a Web browser (client) and a Web server -- then it has two tiers. In a two-tier system, you have a client program and a server program. The main difference between the two is that the server responds to requests from many different clients, while the clients usually initiate the requests for information from a single server.
A three-tier application adds a third program to the mix, usually a database, in which the server stores its data. The three-tier application is an incremental improvement to the two-tier architecture. The flow of information is still essentially linear: a request comes from the client to the server; the server requests or stores data in the database; the database returns information to the server; the server returns information back to the client.
An n-tier architecture, on the other hand, allows an unlimited number of programs to run simultaneously, send information to one another, use different protocols to communicate, and interact concurrently. This allows for a much more powerful application, providing many different services to many different clients.
It also opens a huge can of worms, creating new problems in design, implementation, and performance. Many technologies exist that help contain this nightmare of complexity, including CORBA, EJB, DCOM, and RMI, and many products based on these technologies are being furiously marketed. However, the leap from three-tier to n-tier -- or the leap from one- to two-tier, or from two- to three-tier, for that matter -- must not be taken lightly. It's easy to open a can of worms, but you always need a bigger can to put them back in. The proponents of these technologies are infatuated with their advantages, and often fail to mention the disadvantages of jumping to a more complicated architecture.
In this article, I will discuss the advantages and disadvantages of each style of architecture, and give you some information that will help you choose the right architecture for your application. Consider these reasons before choosing a product because its fact sheet promises to make your life easier.
One-tier architectures
A one-tier application is simply a program that doesn't need to access the network while running. Most simple desktop applications, like word processors or compilers, fall into this category.
The advent of the Web complicates this definition a bit. As I mentioned earlier, a Web browser is part of a two-tier application (a Web server being the other part). But what happens if that Web browser downloads a Java applet and runs it? If the applet doesn't access the network while running, is it a one-tier or two-tier application? For present purposes, we will say that the self-contained applet is a one-tier application, since it is contained entirely on the client computer. By this definition, a program written in JavaScript or VBScript and deployed inside an HTML page would also qualify as a one-tier application.
One-tier architecture has a huge advantage: simplicity. One-tier applications don't need to handle any network protocols, so their code is simpler. Such code also benefits from being part of an independent operation. It doesn't need to guarantee synchronization with faraway data, nor does it need exception-handling routines to deal with network failure, bogus data from a server, or a server running different versions of a protocol or program.
Moreover, a one-tier application can have a major performance advantage. The user's requests don't need to cross the network, wait their turn at the server, and then return. This has the added effect of not weighing down your network with extra traffic, and not weighing down your server with extra work.
Two-tier architectures
A two-tier architecture actually has three parts: a client, a server, and a protocol. The protocol bridges the gap between the client and server tiers. The two-tier design is very effective for network programming as well as for GUI programs, in which you can allocate functionality to the host. Traditionally, GUI code lives on the client host, and the so-called business logic lives on the server host. This allows user feedback and validation to occur on the client, where turnaround is quick; in the process, precious network and server resources are preserved. Similarly, logic lives on the server, where it is secure, and can make use of server-side resources (though here we're approaching a three-tier application).
The prototypical two-tier application is a client-server program with a GUI front-end written in a high-level language like Java, C++, or Visual Basic. In the two-tier program, you can see the clear division between front and back tiers. The first tier, the client, needn't worry about data storage issues or about processing multiple requests; the second tier, the server, needn't worry about user feedback and tricky user interface (UI) issues. For example, a chat application contains a client that displays messages and accepts input from the user, and a server that relays messages from one client to another. Specialization is good: divide and conquer.
Note that the Web again complicates the picture. Let's say you have a CGI program that calculates a mortgage. (It may be implemented as a Java servlet or a Perl script.) All of its input is provided by the HTTP get request, via an HTML form which the user fills out. Its output is one or more HTML files. All the calculation occurs on the server. Is this a one-tier or a two-tier application?
The definition is tricky. I prefer to call it a one-and-a-half-tier application. Even though its function incorporates a Web browser to display the output and accept user input, all of the actual program execution occurs on the server. Since the programmer is only responsible for writing a single running program, and not code that must execute on the client, then it's not truly a two-tier application. However, this is highly debatable, and you could easily argue that the HTML form is actually a primitive form of program code. Note also that the addition of any JavaScript or other client-side code promotes it to a two-tier application.
The reason for haggling over whether standard CGI programming results in a one- or two-tier architecture is that it has implications for your application's design and performance. A one-tier application combines all functions into a single process; a two-tier application must separate different functions. On the bright side, this means that a one-tier application has the ability to mix different functions; however, the programmer must make sure that the program doesn't become a mass of spaghetti code. Many Perl and Python CGI scripts are total pasta.
In some cases, you can write a two-tier application without writing a server or designing a protocol. For example, you can write a Web browser that speaks to a Web server using the (already designed) HTTP protocol. However, if you have to write your own server, or design and implement your own protocol, you can spend more time writing your program than you would if you were writing a one-tier application. The tradeoff is usually worth it, unless time-to-market is a crucial factor.
Three-tier architectures
Often, a two-tier app will need to store data on a server. Usually, the information is stored on the filesystem; however, data integrity issues arise when multiple clients simultaneously ask the server to perform tasks. Since filesystems generally have rudimentary concurrency controls at best (lock files are found on only some platforms, and are often flawed), the most common solution is to add a third program, or database.
Databases specialize
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: One, two, three,
or n tiers? - JavaWorld January 2000
View Tutorial: One, two, three,
or n tiers? - JavaWorld January 2000
Related
Tutorials:
 SQLJ: The 'open
sesame' of Java database applications
SQLJ: The 'open
sesame' of Java database applications
|
Accelerate your RMI
programming
Accelerate your RMI
programming
|
Will Big Blue
eclipse the Java
tools market?
Will Big Blue
eclipse the Java
tools market?
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Create your own type 3 JDBC driver, Part 2
Create your own type 3 JDBC driver, Part 2
|
Test networked
code the easy way
Test networked
code the easy way
|
Good
introduction to JDO
Good
introduction to JDO
|
Comparison between the two major JDO architectures
Comparison between the two major JDO architectures
|
Check out three
collections libraries
Check out three
collections libraries
|
Datastructures and algorithms, Part 1
Datastructures and algorithms, Part 1
|
Picture
this
Picture
this
|
Impressive
!
Impressive
!
|
Clustering and Load Balancing in Tomcat 5, Part 1
The latest version of the Tomcat servlet container provides clustering and load balancing capabilities that are essential for deploying scalable and robust web applications.
|
JAligner
JAligner
JAligner is an open source Java implementation of the Smith-Waterman algorithm with Gotoh's improvement for biological local pairwise sequence alignment using the affine gap penalty model.
|
An Intelligent Nim Computer Game, Part 1
An Intelligent Nim Computer Game, Part 1
In this article, you learn how to play Nim, and discover tools for creating an intelligent computer player. In the next article, you apply those tools to the creation of that player, while building console and G
|
NIO Tutorials
NIO Tutorials
Introduction
In the words of Gregory Pierce, "NIO is one of the most important but least understood APIs that came along for the ride with JDK1.4". Couldn't have put it better myself :). The aim of this series of articles is to help you
|
Java Application Instrumentation with Log4J
Java Application Instrumentation with Log4J
Application metrics, such as performance metrics, are key to understanding and improving application efficiency. Profiling and monitoring tools yield valuable information on CPU and resource usage, including OS
|
JTimepiece
JTimepiece is the advanced library for working with dates and times in Java. Many easy-to-use methods in this API make it easy for any developer, from beginner to expert, to use JTimepiece.
|
What is Web Hosting
What is Web Hosting
What is Web Hosting?
What is Web Hosting?
If you have a company and want web presence than you need a website. With the website any one from the world must be able to view your pages, images etc.
Website is actually a
|
New Technical Articles: 64-bit Programming on Solaris 10 OS for x86 Platforms
Four technical articles describe the new Sun Studio 10 software's 64-bit programming features on the Solaris 10 OS for x86 and AMD64 platforms. Important issues regarding the AMD64 ABI (Application Binary Interface), debugging, migration to 64-bits, and p
|
|
|
|
