Layers and Tiers

Software architects are a confused lot. Communicating with each other is a challenge. There is always a discussion about what goes in what layer ( or tier) and logical vs Physical separation. Even the definition of Data Tier specially is open to interpretation.

Arnon is the first person I saw calling (potential) physical separation as Tier and (Definitely) logical separation as layer – and I believe its a good separation to have in our vocabulary.

So a Layer becomes a Tier if it could be physically separated from the layers consuming it. Or a Tier is a Layer which could be physically separated from the layers consuming it.

Now coming to a typical 3-Tierarchitecture. Here we talk about a UI “Layer”, Business Logic “Layer” and Data “Layer”.

We all agree that a UI layer takes care of presentation. Typical UI frameworks will also encourage you to do validations at this layer, presentation specific logic at this layer ( like selectively showing or hiding fields) and use the events and Data at the UI to invoke the appropriate business logic.

All this is fine, except for one confusion created by J2EE app servers. The Java App servers initial documentation tell you that manage the static files, images on the web servers and manage the JSP pages on the App server.

I would say that while creating a 3-tier application, ignore the existence of the web servers. The UI layer, Presentation layer whatever you want to call it is a part of a J2EE app server, or is a part of ASP.NET worker process and not a part of “pure” web server. If by any chance or coincidence it happens that the web servers contain other files apart from the plugin to the ASP/JSP runtime, just treat it outside of the presentation layer. If you feel these files are important, bring them in into your application distributable rather than keeping them outside.

Next is the Business Logic Layer or the App Layer.

The app layer contains all the business logic. This is the only interface that the web layer, UI layer or Presentation layer calls.

The conventional application architecture defines that the presentation layer and business logic layer should be kept on separate physical machines. Hence they should be “Tiers”. Why?

– Security engineers want to place one more firewall to create a “DMZ”. For some reason known only to them, they say that two firewalls are more secure than one – and that sounds perfectly reasonable to me. So they say that  All external connectivity requirements – including those to other systems in the same or a different datacenter must be behind the second firewall, which is either on the app tier or below. Just repeating what I said above – the App tier is the only interface that the web tier calls.

– Scaling: Web applications tend to be stateful, managing user sessions. The app tier tends to be stateless. Its not possible to distribute load evenly to statefull tiers – as you dont know if one session is heavier than the other session. However, by having a very small number of web servers and putting the bulk of processing on app servers which can have better load distribution, we get more optimal scaling.

So – It is good idea to have a web/ui/presentation layer as a tier.

Now lets come to Data Layer. This is where the architects around the world universally confuse each other. Some say the Data layer is the database or the file system ( i.e. Raw Data), some say that Data layer is the CRUD Data objects exposed to the app layer for editing, some say that Data layer is till the object end of my O-R mapping tool and some say that the Data layer is the Objects which know how to persist themselves – like entity beans.

Now this is here the distinction between A Tier and a Layer is most useful.

In a typical Architecture, We will have a DATA TIER. The data tier is the database, file system, search engine index – or the Amazon’s web data storage service –  whatever.

Then we have a Data Access Layer – which is a piece of code which helps the business logic Layer interact with the persistent data in the Data Tier. This Data access layer could be DAO objects, Entity beans, OR mapped objects or a layer of objects exposing CRUD functionality.

Typically the Data Access Layer is not a TIER, it is kept along with the business logic layer in the App Tier.

There are however a few exceptions – as their always will be. If your data store is not thread safe (yes its entirely possible) – then you might need to put a “locking” layer over it which allows only one person to write on it at a time. This piece of code becomes a part of data tier. It is entirely possible that in your design, your business layer directly interacts with this data tier object without going thru another data access layer in between, Or to put it in other words, for a non thread safe data store, the data layer – should be made a Tier.

Now there are two questions left to be answered

1) From a developer’s perspective whats the difference between a layer and a tier?

2) What about stored procedures ?

Layer and Tier:

The layers reside on the same machine, same runtime ( JVM or CLR) and any object visible to one layer can be passed to the other either by Value or by Reference.  However the tiers could be on different machines or on different runtimes, hence the data has to passed by Value only – as serialized objects. The other difference is a lookup – you need to allow UI Tier code to look up and call remote App tier methods. .NET remoting, web services, RMI, remote invocation of EJB’s all provide infrastructure for doing the same

Stored Procedure:

This is a really really murky discussion. I am sure most will not agree with what I say, but I will say anyway. The way I view it, when you call a stored procedure, you expect a data back, so it is a part of the Data tier. Fetching that data may require some processing. But the very reason why the logic is implemented in stored procedure is that the logic is data intensive, so it doesnot strike me as “unclean”. I have seen many implementations where SP are used for different very logical reasons.

1) stored procedures use very simple interfaces to expose a complex underlying data. This is almost like OR mapping ( like lets say you have a User object, which maps to 3 tables, user, userpreferences and userAddress, it will have crud methods exposed at User level by the stored procedure)

2) Containing frequently changing logic: changing stored procedure is easier than application installation. Some people keep such frequently changing logic as a stored procedure. This is definitely not business tier. This is what makes the separation murky. I think a rules engine is a better place to store the same.

3) Making App layer independant of data changes: Sometime the data store is used by more than one application. Any of the applications using it may impose a change on the schema. By having stored procedures for all consumers, it makes maintainability easier as the party changing the database can easily ensure that all stored procedures in the database continue to work as they were before the schema change.

Now coming to physical architecture:

a typical way to keep the tiers in a web application is

<Firewall> Web Tier <Firewall> App Tier (Business logic + Data access layers)  <> Data Tier (Database/file system).

It is entirely possible to load all tiers into the same machine, but it is important to take care of not being dependant on references when going across tiers.