Layered architecture in Java EE

I have a question that I have never been able to solve:

Considering these two architecture

1st

UI layer
    |
Application layer
    |
Domain Layer
    |
Infrastructure Layer

2nd

Client Tiers
    |
Presentation Tiers
    |
Business Tiers
    |
Integration Tiers
    |
Resources Tiers

What are the difference between them.

Where do entity beans lie in these architecture. If I have a business layer with object that implements business logic, why would I have to add behavior in entity beans. I read somewhere that it is an anti pattern to have domain model objects without behavior.

Thanks

Update

This is actually a project(training) that I need to do to get my msc in distributed systems.

These are actually the technologies I'm using

Struts 2 JPA HSQLDB

So if I understand well

My application consist of

A client layer (web browser) A presentation Layer (struts 2 ) A business Layer (POJOs + JPA) An integration layer (with hibernate DAOs) A resource layer (HSQLDB)

But as the presentation, business and integration layer are implemented on the same server (tomact) I only have a three tiers architecture. Am I right ?

As far as including behavior in my JPA objects, usually this is what I used to do : Have a dao for each JPA entity. Have a bean (like an EJB) that would manage the business l开发者_如何学运维ogic required. So I never put beahvior on JPA objects.

Say for example I wanted to make a purchase request. I would have a CatalogueManager that would help me interact with items, suppliers. I would have also an EmployeeManager that would help me interact with employees. And finally a PurchaseRequestManager that would use the two previous business objects to make a PurchaseRequest.

Now what you are telling me is to put the methods that I have in the PurchaseManager in the PurchaseRequest JPA entity, and do the same for methods in EmployeeManager => to put them in the Employee JPA entity.

But what would happen if my employee object would also be used for the human ressources department, I would also need to put other methods there. For a big application I would have a lot of methods in the employee JPA entity. Wouldn't that be counter productive?

thanks

In my mind, "Layers" are a logical separation, with no implication of a deployment topology.

"Tiers" are about physical deployment. For example the UI Layer logic could be implemented completely in a thick client, deployed to a Client Tier on the desktop and no separate Presentation Tier, or could be a Web 2.0 Browser based app, with the UI Layer spread between a Javascript UI Client in the Browser and Presentation Tier in a Server.

Now onto Entitiy Beans. First, Entity Beans are in EJB 3 replaced with JPA - we annotate objects to control their persistence.

I think that you've got two kinds of business logic, that which is concerned with the behaviour of individual persistent Classes such as Customers, Orders, Employees, Shipments, Students, Courses or whatever, and then their is logic which is at some higher level than that, dealing with combinations of these classes.

It seems reasonable to me that logic concerned with behaviour of, say, a Customer should be in the Customer class. Such behaviour might be quite trivial, for example some kinds of validation and summarisation (e.g. total Order Value) but it's Domain logic and can reasonably be in those Domain objects. So our JPA objects have two roles, implementing domain logic and also managing persistence by virtue of their annotation. The architectural status of those annotations is interesting, they are effectively the "glue" between Domain and Infrastructure.

From Wikipedia:

The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.

Basically, there are 3 "parts" to address:

1. Client - this is where presentation happens, and where client side programming exists (Javascript) for dynamic interaction with your application.

2. Business - this is where all your business logic exists. Algorithms, domain models, the "meat" of your application. EJBs live here, if you use them.

3. Data - usually your database which you access from your business layer.

Your (deprecated) entity beans exist in business layer. But don't use then, use JPA because it's more modern and much less cumbersome.

You can use JPA entities also for business logic, since they're pretty "lightweight", so there is no need for total separation.

Strive for simplicity, not for overuse of "architecture", "design patterns", "enterprise pattern" or anything else that sounds too enterprisey.