Distributed Programming

Distributed Programming

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