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.
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.
Very high performance
No networking -- can't access remote services
Potential for spaghetti code
Clean, modular design
Less network traffic
Can separate UI from business logic
Must design/implement protocol
Must design/implement reliable data storage
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
Support multiple applications more easily
Must learn API (CORBA, RMI, etc.)
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.