5 tier Architecture in Java

[Matt Cao]

Dear All,
I have two major fight over the proposals sample from 2 major groups of developer. Could you help me to sort out which one is more closer to the 5 tier Architecture in practicality?
Group 1 version:
1. Client Tier- Browser, Applet, Client Applications
2. Presentation Tier- Servlets, JSP
3. Business Tier- EJB or Some Business Objects
4. Integration Tier- JDBC
5. Backend Tier- Databases, JMS
Group 2 version:
1. Client Tier- Browser, Applet, Client Applications
2. Presentation Tier- Servlets, JSP
3. Business Tier- Business Objects(Session EJB, Business Classes)
4. Integration Tier- Data Access Library(Entity EJB, JDO, SQL)
5. Backend Tier- Databases, JMS
Thanks,
MCao

[Mark Herschberg]

Hmm, there's no ideal place for this, but I think you'll get the best responses in Java in General (Advanced), so I'm moving this there.
--Mark

[John Smith]

Well, there are actually 2 questions that you are asking. The first one is what is the purpose of each tier, and the second is what Java technologies should be used in each tier.
I think a more or less universal answer to the first question is this:
1. Client Tier -- interface to the system
2. Web Tier -- presentation logic
3. Business Tier -- core business logic
4. Persistence Tier -- storage
5. Integration Tier -- for legacy systems, resource planning, etc.
Now, the second question is much harder to answer, -- a particular Java technology may be used in several tiers. For example JMS may be appropriate in 1), 3), and 5). JDBC seems suitable for 4) and 5). I can see Servlets/JSP in 2) and 5), EJB in 3) and 4).
Ultimately, an architect (or a group of architects) make a decision based on the well known and defined factors, such as performance, scalability, availability, extensibility, maintainability, security, reliability, etc. Derive a weighted average of these factors for your system, and the answers come easy.
Eugene.

[Edy Yu]

Matt:
Actually, the terminology of the names of those tiers and which part of the system belongs to which tier are still open to debate now. Wording is not important. But I guess you are seeking some sort of tutoring/educational answers.
Here are my thoughts.
If I were you, I would take the group 1 version as the starting point:
Group 1 version:
1. Client Tier- Browser, Applet, Client Applications
2. Presentation Tier- Servlets, JSP
3. Business Tier- EJB or Some Business Objects
4. Integration Tier- JDBC
5. Backend Tier- Databases, JMS
But I'd like to move JMS from backend to integration tier.
Back-end tier should also be called EIS(Enterprise Information Services, including databases, legacy system ...). JMS is a way just like JDBC to integrate your apps to EIS.
Entity beans should resides in business logic tier because entity bean could and alsways does contain business logics. Remember, entity beans are coarse-grained...
Hope this helps.
[ April 27, 2003: Message edited by: Edy Yu ]
[ April 27, 2003: Message edited by: Edy Yu ]

[Chris Mathews]

Originally posted by Edy Yu:
Entity beans should resides in business logic tier because entity bean could and alsways does contain business logics. Remember, entity beans are coarse-grained...

Not trying to hijack the thread or anything but...
putting business logic in Entity Beans is generally discouraged. Entity Beans should be used for persistance, all business logic should be in components such as Session Beans and Message Driven Beans.
Also, Entity Beans can be course-grained however this is not a requirement. Actually, it is recommended to stick with fine-grained Entity Beans since the introduction of Local Interfaces and CMR in EJB 2.0. The Composite Entity Bean pattern is pretty-much deprecated.

[Edy Yu]

Chris:
I was trying to convey that entity beans reside in the business logic tier because it is hard to me to agree entity beans are in the integration tier.
It is better to put business logic into session beans or other Java objects. But is it possible and even sometimes applicable to put some business logic into entity beans. The object-oriented design encourages flexibility.
An example:
Should database contain some business logic? Yes. That's what stored procedures are for.

[Stan James]

Is "5-tier architecture" an emerging formal definition? I did a quick Google search and got as many different tiers as hits.
A few comments - I find "persistence" a good layer, and entity beans a good fit. Products like TopLink could go there, too.
I also find "integration" a good layer, as there can be many integration strategies, protocols, middleware products, etc.
Of course that puts me over 5. Oops.

[Matt Cao]

Hi Stan,
Remembered in the days client/sever was in the spot light, the networks architecture infrastructure had variety of formations.
Now, we are dealing with software wise. The formation of software.
Dear All,
Thanks for the inputs, I know what to do now.

Regards,
MCao

[Stan James]

There are many ways to carve up architectures and many types of layers you can talk about. On my site I made a page about architectural layering with some ideas and pictures borrowed from Clemens Szyperski and Ratio. They talk about:
1. Application
2. Libraries
3. Operating System
4. Device Drivers
5. Hardware
or
1. Interface
2. Application
3. Domain
4. Infrastructure
5. Platform
or from IBM San Fransisco
1. Application
2. Common Business Objects
3. Foundation
4. Platform
Interesting there's no data there!
[ April 30, 2003: Message edited by: Stan James ]