Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Is JSF, Hibernate 3 and Spring 2.5 integration good

 
Muhammad Ijaz
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to build a health care web application. It is supposed to to have concurrent access with more than 600 hundred users at a give time.
I am thinking to use JSF+Hibernate+Spring integration with mysql and jboss.

Would anyone please guide me, if this is the good combination?

Regards
Pomy
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Muhammad,

It is not a bad stack and can certainly handle your requirements. However, I would recommend investigating EJB 3 and JPA (perhaps with Seam) as another alternative and see if that might suit you better. I have often received feedback that it has an easier learning curve and involves less configuration/XML, especially with JSF. Also, if you are using Hibernate 3, you are probably best-off using it through JPA, especially if you plan on using annotations. Yet another alternative is to start with Java EE 5 including JSF, EJB 3 and JPA (without Seam) and integrating Spring if and when really needed. I personally really like this last approach. It keeps all options open and utilizes the strengths of EJB 3, JPA and Spring.

Hope it helps,
Reza
 
Muhammad Ijaz
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Reza for your useful comments.. and what about if I use EJB stateless session bean with hibernate.. I think this combination will reduce client to server resource calls, and there will be less network load..

Regards,
Pomy
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pomy,

Session beans are definitely a good choice if you are conscious about server resources. I would use Hibernate 3 through JPA. Native Hibernate does not offer anything as such and using annotations is a lot easier through JPA. Also, using JPA means you could switch out from Hibernate if you ever needed to.

Hope it helps,
Reza
 
Bijj shar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you build application with JSF, Hibernate and spring it means you are simply making complex application not easy to maintain.
If your application need transaction handling and according to you user load is 600 is not big so I would suggest use Struts and EJB. I will suggest don’t use Hibernate. You could integrate spring anytime to your application but I don’t think it is required. You can handle transaction either from ejb or store procedure. This will be very simple and you could build application very less time without highly expert coder.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is true that both Hibernate and JPA have a learning curve of their own, especially if you are already familiar with JDBC/SQL (we talk about this in the book). I have seen very successful applications written via stored procedures (perhaps with Spring JDBC template or iBATIS on the Java side). The trade-off is that you will need the skill-set on the DB end to maintain stored procedures and that you are more-or-less tied to a DB implementation. JDBC code also tends to be more verbose than JPA or other ORM solutions because of the hand-written translation code to/from Java to the SQL result set. If you used improperly, business logic can leach into stored procedures which is procedural, not object oriented and hence can be difficult to maintain/debug.

It is also true that Struts 1 or 2 can be simpler if you are already familiar with JSP and are unlikely to write a lot of components/page templates (JSF/Facelets are essentially designed for this). The trade-off with Struts is that you will typically have to write a form and an action instead of just a backing bean like in the case of JSF. If using Seam with JSF, you can directly populate domain objects from the page and use them as parameters to EJBs used as page controllers/backing beans. This can eliminate the backing bean layer altogether in a majority of cases.

Hope it helps,
Reza
 
Bijj shar
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rehman-
1. Where is question of writing JDBC code to handle transaction of you use EJB?
2. Why do you think that iterating result set is error prone?
3. Why do you think that if you handle transaction in store procedure you will have to write whole business logic in store procedure?
4. Why do you think that it is difficult to debug store procedure or enterprise java code?
5. Any way if use JSF on application layer then you will have to use jsp for client side.
6. Struts have plenty of in built custom tag to iterate object on jsp.
7. There is no need to write form and action for every jsp if use struts.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Brij,

Here are responses to your questions:

1. Where is question of writing JDBC code to handle transaction of you use EJB?
- Not sure what you mean? Do you mean hand-coding everything with JDBC yourself? This really isn't necessary any more with all the persistence tier choices. In fact, I'm not sure why you would ever want to do this really for a brand new application?

2. Why do you think that iterating result set is error prone?
- It could be error prone, but the point is that it is far more verbose than using an ORM solution.

3. Why do you think that if you handle transaction in store procedure you will have to write whole business logic in store procedure?
- That's not really what I said. It does not necessarily have to be, but it often is in practice and should really be avoided. The reason this often happens is the idea with some folks that stored procedures are suitable for business logic.

4. Why do you think that it is difficult to debug store procedure or enterprise java code?
- Not sure what you mean here either. Procedural code is simply a lot harder to maintain that anything in OO, not to mention development/testing/debugging tools like the ones available in Java IDEs are simply not available for anything on the DB end. The procedural paradigm also has not evolved much for a long time, while OO has evolved quite a bit around standards, patterns, tools and best practices.

5. Any way if use JSF on application layer then you will have to use jsp for client side.
- This isn't really true. Have you looked into Facelets? It's actually much better suited to JSF and has been included in the JSF 2.0 standard.

6. Struts have plenty of in built custom tag to iterate object on jsp.
- You mean JSTL? But that's not a component model, though. If you haven't looked into JSF/Facelets, it's best to check it out on your own to see how it differs from JSTL or even JSP custom tags. Like ASP.NET, JSF is component based; while Struts is controller/action based. Here is a good write-up from the Struts folks themselves on the differences: http://struts.apache.org/2.0.14/docs/what-are-the-fundamental-differences-between-struts-and-jsf.html.

7. There is no need to write form and action for every jsp if use struts.
- Yes, but that's most often the case. Again, it is best to take a look at JSF to see the difference or take a look at the article above and similar resources.

Hope it helps,
Reza

P.S.: It is OK to refer to me by my first name. Last names are so impersonal :-).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!