History Lesson
Long, long ago.. in a galaxy far, far away… People once known as computer nerds started writing code… They walked 20 miles a day to get to the keyboard, and walked 20 miles more to copy a 3.5 inch floppy disk, remember those? 512k ram was huge! Well, back in those days people used to program applications with a procedural approach. Procedural programming was a logical, step by step approach to solving problems. Applications back then were much simpler, required much less complexity and were quite happy working within these boundaries.
Eventually, applications started to become interdependent, and grew degrees of magnitude in complexity. Data manipulation in various formats became central to portability. As new technologies, techniques and different information systems emerged, the importance of a pluggable, non monolithic approach to system architecture and design became more and more obvious, not just in hardware but also in the software itself.
Let me illustrate with this example – I’m going to say I have a server machine and it runs a single program that does everything. It serves web pages, keeps track of data, load balances, implements all my business logic, keeps track of customers that log on, EVERYTHING, on one machine. This is what I’d call “putting all your eggs in one basket.” If we learned anything from the 90s tech bubble, the housing bubble, the economic recession, it’s to diversify and do the exact opposite and not put all the eggs in one basket.
Why?
Because if anything were to happen – if there was a power surge, if the hard drive failed, if there was a bug in the software, if any one aspect of the application were to fail or go down for whatever reason, basically if ANYTHING went wrong, I’d be pretty much out of luck in trying to restore the system. There is no resilience because the system is far too tightly knit between all of its components for it to survive any kind stress outside a near perfect situation. To make things worse, if i wanted to upgrade system performance by updating one aspect, I’d have to be extra careful to not break the paradigm and compensate for all the interdependency. This becomes much more obvious the more complex the system becomes.
Think about it as if it were a studio apartment. If anything breaks in the studio, like a ceiling pipe that starts spewing water, then the whole room ends up flooding. This one pipe ends up affecting your living room, kitchen, bedroom, bathroom, everything because all of it is in one room. If you wanted to get new windows, or upgrade your electricity, or even paint the walls you’d have to figure out how you’re going to live with all the mess everywhere because everything is in one room. It’s not like a multi room house where you can partition off a room by closing the door and upgrade that one room without affecting the rest of the house Wait a minute, that sounds like a GREAT idea!
This concept is basically what n-tier architecture evolved into. The approach is to break out an application into an n number of tiers – essentially turning your one room studio apartment into a 6 room house, with each room in charge of one specialized task. N-tier architecture is usually broken up into 3 major sections: the presentation/front end tier, the business/application tier, and the data/backed tier. The image below is one example of a possible n-tier architecture layout:
Presentation Tier
In the presentation tier, the software is written to present the user with the application. Front end frameworks like Spring MVC, Seam, Struts, and JSF, are only some of the frameworks that aim to provide an extensible, modern day front end architecture for web based applications written in java. The end result is usually some kind of html page with javascript that validates data or handles some kind of user interaction. Presentation tier frameworks usually provide some kind of validation framework, some kind of implementation of the Model-View-Controller design pattern that’s become so famous in software, and usually some sort of layer of code that integrates with the application tier, allowing for easy communication with deeper levels of the application. It’s important to note that although the presentation tier is off by itself its still able to be “torn out” and replaced with another front end framework. A well written application will allow for this kind of upgrade without having to rewrite the entire application back to front. Only upgrade the parts you want, not the whole thing. If the presentation tier were a house, it might be the paint, furniture, appliances, big screen TV, everything that makes a house easy to use and live in.
Business Tier
The business tier is essentially the glue that holds the entire application together. All the logic is abstracted and broken down into layers of logic or composable services (as an SOA architecture would promote) that hook into the front end via simple function calls. Application servers like jboss, websphere, weblogic, jetty and others deploy and run all the logic used by web based applications. If the business tier were a house, it would be the house’s frame, plumbing, electrical system – the infrastructure that makes the house work.
Data Tier
Lastly, the data tier is the tier where all the data used by the application lives. A relational database, xml datastore, data grid, a file on a computer, anything that is designed to store data for use by the application could be considered part of the data tier. Postgres, Oracle, MySQL, and Microsoft SQL Server are only some of the well known relational database system. There are plenty others out there that have some kind of use in most applications. If we follow the house metaphor, I think the data tier might be the house’s natural resources, the land, trees, roads, fences, grass.. These are things that persist after the house has been torn down. Its not a perfect metaphor but hopefully it makes some kind of sense.
Further reading:
http://en.wikipedia.org/wiki/Multitier_architecture
http://www.exforsys.com/tutorials/client-server/n-tier-client-server-architecture.html
Related posts: