Layers and Tiers

September 15, 2006

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.

28 Responses to “Layers and Tiers”

  1. Vinay R Says:

    I like your style of writing. Kept it simple and is obviously practical. Look forward to reading more blogs from you.

  2. Pranshu Jain Says:

    Thanks Vinay,
    Limited language skills has its use. Check out the link below on use of Plain language for government work.

  3. Superb explanation of software architecture – I will be pointing clients toward it.

  4. G Huff Says:

    Thanks for the explanation. This poses a question regarding system interfaces. How do you, and in which layer, depict interfaces to other systems? These systems can be importing or exporting data or both. Shall there be an Interface layer (tier) that is subordinate to the data layer.

    The example is a Reporting Web System, that in its own right can be defined as you have described, but also receives and sends data.


  5. Pranshu Jain Says:

    Thanks for your comment Greg.
    Though I am not sure whether I understood your example fully, but I have been thinking about whether it is fair to classify the web services, or other services which we “interface” to as a tier. What if all these services are hosted on the same runtime?
    And what if various components of the “App Tier” are hybrid – i.e. web service for external world but exposed as a local call for elements within the same runtime?

    In one of the more complex applications I worked on, I was required to delegate some parts of the processing to remote machines – either because they had the correct network access, or because of licensing restrictions ( i.e. the software vendors wouldnt let us have a 1 CPU license on an 8 CPU machine even though we would use it very lightly), although they would have been app layer functionalities.

    All said and done – in my opinion, these external systems as long as the can work alone( Whether servers or consumers)are different systems in their own right.

    But if they are completely contained, integral part of this system, they should be counted as seperate tiers.

  6. Harpreet Singh Says:

    Thnaks for the superb explanation i was always looking for the brief but exact defination about difference between layer and tier in context of application architecture.i will forward this article to my team members for their reference.

  7. abhinav Says:

    Nice explanation.Do keep up the good work

  8. Sathappan Says:

    Good articale.

  9. Tomas Says:

    This comment is a reaction to the used terminology for “business logic layer” and the phrase “The app layer contains all the business logic”.

    Sometimes you can also see descriptions about two layers instead of the one App layer you describe:
    – Application Layer (= Service Layer according to Fowler, writing “Application Layer [his name for Service Layer]” at
    – Domain Layer (= Business Layer, Model Layer, Application Logic Layer, according to “Applying UML and Patterns”, page 203 [AUaP])

    [AUaP] (page 203) defines “Application Layer” as the first layer after the UI layer, and then the “Application Logic Layer” (aka Domain/Business) as the next layer.
    On the other hand, if we should consider your “Business Logic Layer” as equivalent (alternative term) to “App Layer”, i.e. “Application Layer” then you see that

    Your “Business Logic Layer” (“App layer”) will be the first layer after the UI Layer and then the “Business Layer” after that layer
    You now might (below) see that the word “logic” seem to “move” the layer up or down depending on the word “logic” is applied to the word “Business” or “Application”.
    Below, you can see what I mean, when I write the three layers from [AUaP], after having “merged” them with your (Pranshu Jain [PJ]) equivalent layers:
    Layer 1 : UI Layer [AUaP]
    Layer 2 : Application Layer [AUaP] & [PJ], Business Logic Layer [PJ]
    Layer 3 : Business Layer [AUaP], Application Logic Layer [AUaP]

    (if we above insert the “Logic” word after “Application” then that layer will go down, while inserting “Logic” after “Business” above will move it up)

    In other words, these may seem to be potentially equivalent definitions:
    “Application = Business Logic” AND “Business = Application Logic”
    (no wonder that terminology causes confusion…)

    Regarding the content of the domain and application layers, there is a GRASP Controller in [AUaP], which is explicitly written (page 308) as being “part of the Domain Layer”, while the same GRASP controller also is defined (page 302) as the “first object beyond the UI layer” (which receives and coordinates a system operation).
    Though, as already mentioned (page 203) there is an application layer between the UI layer and Domain Layer, so the Domain layer (GRASP controller) can not contain the first object beyond the UI layer in a strictly layered system when there is such an application layer.

    Finally, while writing about semantic confusiion regarding layer terminology, I would also like to mention that the Application Layer which Fowler calls Service Layer, can contain services, but so can the Domain Layer and also the Infrastructure Layer (which can implement persistence, kind of like the Data Layer), according to the following quote from “Domain-Driven Design quickly” ( )
    “It is easy to get confused between services which belong to the domain layer, and those belonging to the infrastructure. There can also be services in the application layer”.

    So, in other words, when you see a class using a suffix “Service”, the implied semantic will not be obvious since it just might belong to any of these layers:
    – Service/Application Layer
    – Domain/Business Layer
    – Infrastructure/Data Layer

    Also, the “DDD quickly” book (page 30), explicitly writes the following about “Application Layer”:
    “It does not contain business logic”, which is in direct conflict with the following quote
    from this page above: “The app layer contains all the business logic.”

    / Tomas

  10. Tomas Says:

    Sorry about the Fowler quote, which was refering to the wrong URL. The quote “Application Layer [his name for Service Layer]” was picked from this URL:

  11. very nice information you posted, very useful for me as a beginner.

  12. Nice post. Very good summary of the application layers, although weve started to think about a 4th layer – web controller layer, for obvious reasons – yet still use MVC lingo to avoid confusion.

  13. […] With Skyway Builder CE, Java developers get an open source Eclipse-based plugin that offers a seamless blend of coding and modeling for delivering RIAs and Web Services in Spring. Unlike any other modeling tool, Skyway Builder CE provides comprehensive modeling capabilities at four distinct application layers: […]

  14. Siddharth Says:

    Hi Pranshu,
    Can you give some practical pointers on how does one achieve having the presentation and business layers on seperate machines , specifically i have a need to have Struts for the presentation tier and Spring for the business layer seperated by a firewall, what frameworks / technologies could help acheive this , some links to resources would be great

  15. […] Layers and Tiers, por Pranshu Jain, 15 de setembro de 2006, em seu blog.   […]

  16. […] some colleagues introduced me to the concept of writing code in layers to try and separate the various parts of the application I was working on. It improved my approach […]

  17. […] [pra2006] pranshujain. 2006, “Layers and Tiers”, Software Architecture and Content Management [online] available at […]

  18. […] [pra2006] pranshujain. 2006, “Layers and Tiers”, Software Architecture and Content Management [online] available at […]

  19. […] Weiterlesen… This entry was posted in Uncategorized. Bookmark the permalink. […]

  20. You are the first Google hit when searching for ‘layer or tier’. That says alot. Your article is well-written and very accurate. Appreciated!

  21. girish Says:

    well written. Thank you for the post.

  22. Tom Says:

    Explained very well, thanks. And I’ve actually done this: “some “App Tier” are hybrid – i.e. web service for external world but exposed as a local call for elements within the same runtime”. I’m not crazy about the solution, however, because I like things to work “one way”.

  23. Louanne Says:

    Hey there! This is the third time visiting now and I personally just wanted to say I truley get pleasure from reading
    through your site. I have decided to bookmark it at stumbleupon.
    com with the title: Layers and Tiers Software Architecture and Content
    Management and your Web address: http://pranshujain. I hope this is all right with you,
    I’m trying to give your wonderful blog a bit more publicity. Be back soon.

  24. It’s genuinely veгy difficult in this Ƅusy life to listen news on Telеvision, thus I simply use internet for that reason, and take the most up-to-dаte

    Ya deja de escribir o ponte a llevar a cabo algo porque escribir creo que no
    es únicamente lo tuyo.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: