Take the 2-minute tour ×

I was attempting to find a best practice for modeling the tiers in a Java EE application yesterday and couldn't come up with anything current. In the past, say java 1.4, it was four tiers:

  1. Presentation Tier
  2. Web Tier
  3. Business Logic Tier
  4. DAL (Data Access Layer ) which I always considered a tier and not a layer.

After working with Web Services and SOA I thought to add in a services tier, but that may fall under 3. the business logic tier.

I did searches for quite a while and reading articles. It seems like Domain Driven Design is becoming more popular, but I couldn't find a diagram on it's tier structure.

Anyone have ideas or diagrams on what the proper tier structure is for newer Java EE applications or is it really the same, but more items are ranked under the four I've mentioned?


Really, I should have reworded my question as my real intent was to ask where to put the business logic in a Java EE application? In thinking along those terms, I somehow concluded that the tier structure had changed, when it had not. However, with the advent of POJO programming and lightweight frameworks that I was using in my day to day work, I lost sight of all this.

The tier structure of Java EE apps still holds to the same, but now instead of heavy weight EJB2 type business logic in the middle tier I was using POJO's with services to implement business logic.

share|improve this question
Surely nothing has changed. –  Rig Jun 28 '12 at 18:47
I agree, now it's just more things that go into the technology stack. –  James Drinkard Jul 6 '12 at 13:08
add comment

1 Answer

up vote 2 down vote accepted

I believe the answer to your question will vary depending on the type of an application you are developing. Since I am more familiar with Web Based desktop (vs mobile) applications I will try to answer for this type.

The most prevalent architecture of JEE web apps these days is based on MVC (Model View Controller) design patter. This pattern breaks out your app into View layer designated to be consumed by the Client Tier, Model and Controller layers reside in your server side app tier. Additionally most app frameworks rely on application Services layer (not WebServices) for your application specific logic (business logic, etc). Besides these layers application may consume or produce a WebService (either SOAP based or REST(RESTlike) ). And finally most web apps read and write to a Database (or other persistent storage).

I would consider breaking up your architecture diagram into three main tiers: Client-Server-Data (where data tier could have both a database and a set of webservices to read/write data) I know this isn't traditional SOA architecture break out - but that is how most apps that I have seen actually work.

Hope this helps. Dmitry.

share|improve this answer
It does. I'm doing a jsp/servlets/web app with Spring and Hibernate. I just found a diagram using EJB's (which I don't really work with anymore) in the Java EE 6 Tutorial, so I'm concluding that while there are more things in the technology stack, the basic tier structure is still the same. SOA, Web Services, REST, apparently don't change that. –  James Drinkard Jun 28 '12 at 18:50
Agreed. EJBs were pretty much replaced by the JPA spec + WebServices for remote data. By the way we have been using Grails for some time and absolutely love the simplification of the Spring/Hibernate stack. –  DmitryB Jun 28 '12 at 19:04
add comment

Your Answer


