This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
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
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.
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 ]
<i><br />Sun Certified Programmer for Java 2 Platform (SCJP)<br />Sun Certified Developer for Java 2 Platform (SCJD)<br />Sun Certified Web Component Developer for Java2 Platform, Enterprise Edition (SCWCD)<br />Sun Certified Business Component Developer for Java2 Platform, Enterprise Edition (SCBCD)<br />Sun Certified Enterprise Architect for J2EE (SCEA)<br />IBM Certified Enterprise Developer, WebSphere Studio V5.0<br /></i>
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.
Joined: Nov 21, 2000
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.
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.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Apr 03, 2003
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.
Joined: Jan 29, 2003
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 ]