What is a best practice tier structure of a Java EE 6/7 application?

Question

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?

Aftermath:

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.

Answer 1

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.

Answer 2

After doing more research, I found another answer.

In a Spring application, the services tier can combine the business logic with the data access, eliminating the need for DAO's. (Re: Apress Book: Pro Spring 3 page 50). This in effect takes the traditional 4 tiers of a J2EE application that I mentioned above into a 3 tier architecture. The picture below was how apps typically were structured in Java2EE that I worked on:

Then with the advent of the Spring Framework, services were added into the business logic middle tier and this is a typical structure for apps that I worked on later. This was what I thought had changed the structure of the Java applications, but really it was an evolving of the middle tier. The tiers themselves were still present.