OSGi without the Eclipse
It's become common to equate OSGi with Eclipse or Equinox, but in fact other OSGi implementations exist. This post from JW blogger Oleg Mikheev fills a much needed gap - walking through the process of developing a Hello World bundle with Apache Felix and the IDE of your choice.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

One, two, three, or n tiers?

Should you hold back the tiers of your application?

By Alex Chaffee, JavaWorld.com, 01/21/00

I 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.

Resources