Question

How does a three tiered system work in Java?

Can someone explain this to me with some simple examples?

Answer 1

Here’s the basic idea, which can actually be derived more or less from first principles, ie, Parnas’s rule that modules should conceal one secret:

• the “front end” tier holds the secrets of making a visible presentation

• the “middle tier” holds the secrets of managing the behavior of the system

• the “back end” holds the secrets of how data is held persistently.

In a Java based system, this means

Front end

There is a web server and the presentation is constructed with HTML, CSS, and Javascript. There are several technologies for this, but the most Java-centered one is Java Server Pages, which effectively generate HTML from a script with embedded Java. One well-known way to manage JSPs on a higher level is called Struts.

There are a number of tools to simplify this; perhaps the most common is Spring. (Spring provides some other things that are more applicable to the middle tier as well.)

The other option, which is very uncommon nowadays, is to have a Java application front end that runs on the client’s machine.

Middle Tier

The middle tier is there to provide the data in a useable form for the front end. In the Java world, this is often done with an “application server” which presents “objects” to the front end. The really hard-core solution to this is called Enterprise Java Beans (EJBs) but that turned out to be too complex for any but the biggest systems; it’s now more often done with a persistence layer like Hibernate, that provides Java Data Access Objects to the rest of the middle tier. (To learn more about this, you want to look into what’s called the “impedance mismatch problem for objects and relation databases.”)

Back End

The usual back end in a 3-tier system is an off-the-shelf data base, although it could conceivably be anything from Hadoop and BigTable to something that uses Java serialization to store state as text files. The back end is responsible for keeping that state so it persists and can be found again. Tools like Hibernate exist essentially exist to provide a clearer, more general interface to a data base, but Java has had the JDBC interface from the first (well,nearly the first, Java 1.1) to make databases useable.

n tier Systems

In large scale systems, this subdivision can be broken down further. For example, the “front end” can be seen as two layers: a presentation layer in the browser and a presentation support layer in the server. In that kind of breakdown, the server side might, for example, manage sessions and authentication. Similarly, you can look at the interface between middle tier and back end as a layer in itself, an “impedance matching layer”. Now, Hibernate gets its own layer.

On the other hand, it’s not uncommon for systems to have a presentation layer generatng HTML or implemented as a Java client application talking to a data base back end directly, In that case, you have a “two tier system”.

Java is not the reason

The last thing to note here is that Java isn’t the reason or the basis for having 2, 3, or 5 (or more — is the browser itself a tier?) tiers. It’s instead an architectural decision made because you want to tie parts that are likely to change together into the same components. In real life, the business is fairly stable; once you’ve converged on a domain model, it doesn’t change much. When the presentation changes, the domain model often won’t — so separate that into a presentation layer. On the other hand, you may choose a different database implementation without changing either the business model (domain moel) or the presentation — so make that a separate tier. This leads to a more robust system, because a change doesn’t then mean code breaks throughout the system.

This desired robustness is the reason for a multi-tier system.