Please comment on the application design

[Nitin Mehhta]

Hi,

I�m developing a system which will facilitate in conducting online tests for the various software streams. The major challenge while designing this application is of a large number (say 200) of concurrent users. This would be a web application built on J2ee framework. I�m using struts framework which will take care of the viewer and the controller aspects of the application. As there will be a high transaction rate (due to various simultaneous tests) I have chosen EJBs (Stateless session beans) to get the benefit of the application server transaction handler. My Action Servlet will call an Action class which will delegate the work to a facade class. The facade class will serve as the EJB client and call the EJB business methods. I have made a database helper class which has methods to facilitate various database interactions like selects, inserts, updates etc. Inside the EJB business method I�m calling methods from this database helper class to do the database interaction. I�m passing the result back to the web server (fa�ade class) via Value Objects. I�m at the architecture design phase for the application. As this is my first venture in developing an EJB compliant web application please let me know if the architecture I have followed is correct or flawed. Also I would really welcome any suggestions\improvements in the design.

Thanks in Advance.

[Stan James]

Overall looks pretty solid - and pretty conventional.

Using EJB might be something to examine in more detail. EJB containers provide a number of services. If you're only taking advantage of one or two, like transaction management, you could greatly simplify life by writing Plain Old Java Objects instead.

If you do find enough reason to use EJB, I like your idea of a Facade exposed to your clients. I'd use POJOs from there on, though. The system I work on now has essentially one session bean to provide access from any client and POJOs from there on.

I'd look carefully at Spring for its JDBC abstractions and transaction management. I have no hands on (yet) but the design ideas look very attractive.

The Spring style of dependency injection is a great thing to learn, too. You can make most or all of your classes with zero dependency on Spring, in contrast to EJB where you have to extend framework classes and implement interfaces.

The single bean idea and Spring both focus on reducing the binding between your business classes and the framework. It's sweet to have Java classes you can test from the command line (maybe JUnit) without starting the server and hooking up the database and the UI.

Any of that sound interesting?

[Chris Mathews]

I would also second Stan's comment on dropping the EJB layer. It isn't gaining you anything at this point.

[kri shan]

Use Spring instead of EJB Transaction, use Hibernate for O-R mapping. Hibernate + Spring is the good combination. It's light weight, hence no need of Application server.

[Nitin Mehhta]

Thanks Stan, Chris and Shan for the valuable comments. We also explored the idea of POJO first but then we thought of utilizing EJB out of the box facility. I would go back and look again at the real worth vs weight of EJB. As far as Hibernate is considered we did a EJB vs Hibernate analysis and found out that performance for connection pooling and transaction management using Hibernate was not up to mark. Moreover in our design ORM was not as valuable as transaction management (so we chose Session EJB). I would seriously give a solid cosideration to Spring now. Again thanks for the review and suggestions.

[Chris Mathews]

As far as Hibernate is considered we did a EJB vs Hibernate analysis and found out that performance for connection pooling and transaction management using Hibernate was not up to mark. Moreover in our design ORM was not as valuable as transaction management (so we chose Session EJB).

How did you make this comparison? Comparing EJB vs Hibernate is like comparing Apples to Monkeys. It doesn't make sense, EJB is primarily for building Distributed Components and Hibernate is an ORM tool... the use of one does not exclude the other. If you are saying that you compared Entity Beans to Hibernate then that is a valid comparison, however I doubt you would have made the conclusion that you did.

Let's talk about the two things you mentioned: Connection Pooling and Transaction Management...

Regardless of EJB vs. Hibernate, Connection Pooling can and should be managed by the Application Server. Both EJB (here I am talking about Session Beans using straight JDBC or Entity Beans) and Hibernate can use a JNDI Datasource which is created and managed by the Container.

Transaction Management is also a fairly trivial subject for the type of application you describe. I assume you only have a single datasource and no need for distributed transactions. This is the case in 99% of J2EE Applications and is actually fully supported by the standard JDBC specification... no need for JTA or XA Transactions, no need for EJB Transaction Management (though this makes transaction composition easier sometimes).

So basically what it comes down to is not EJB vs. Hibernate... but plain JDBC vs. Hibernate. This is a valid question and the answer really depends on your particular development needs. Do you have a Rich Domain Model with complex associations and little desire to hand-write SQL? If not then Hibernate probably isn't for you... however I wouldn't necessarily recommend going down the straight JDBC path either. Take a look at the Apache IBatis Project... it is a good mix of pedal to the metal SQL and ORM Mapping... at least I quite like it. Plus, as Stan mentioned, it is worth it to look into Spring for its abstractions on top of plain JDBC or even ORM tools like Hibernate and IBatis.

Finally, I would like to touch briefly on the subject of performance. It actually doesn't seem to me (based on your description) that this application needs much in the way of performance. In reality concurrent users is not a very good indication of total volume. What we actually want to know is the total number of concurrent transactions that the system will be processing. So let's take a shot at that metric with some concrete (and made up) numbers...

Number of Concurrent Users = 500 (shooting high here)
Average Think Time between Requests = 10 seconds (we need time to think before answering a question right?)
Average Transactions Per Second Per User = .1 tps (based on 10 seconds think time)
Average Total Transactions Per Second = 500 users * .1 tps per user = 50 TPS

So even being pretty conservative with these numbers, you are looking at 50 TPS. My thought is that the production volume will actually be much lower than this (ie. less users and probably a greater think time). As you can see, this isn't very high and I personally don't think you should be overly concerned about performance at this point in time. Put together a solid design, execute on it in build, and setup some time throughout the project to test performance and adjust the code as necessary. Rinse, Repeat.
[ April 27, 2006: Message edited by: Chris Mathews ]

[Nitin Mehhta]

Thanks Chris for elaborate response to my query. I really appreciate your taking time out for this. Let me correct my self when I said EJB vs Hibernate. I actualy ment EJB Entity Beans vs Hibernate. Sorry for the confusion caused. As far as my analysis over there is concerned I read in one of the articles (http://www.roseindia.net/hibernate/hibernate_architecture.shtml) that Hibernate comes with its own Connection Pooling module and transaction Manager module which does not have the desired performance. Your assumption of 50 TPS holds true for our application. What I did not know was that this figure does not qualify as high TPS. That would certainly change things a bit. I was not aware of the IBatis project and would certainly have a look there. Just to summarize from the discussion, my concerns were mainly about a) connection pooling - for which you have advised to make use of the App server,(instead of hibernate connection pooling module or any other) b) transaction - which in this case can be managed by JDBC itself and c) performance - which again is not a major factor with the given TPS value. Once again thanks for the insight.

[Stan James]

Hey, this conversation has gone great. From what I read everywhere, the suggestions are pretty mainstream with nothing risky or weird.

At the top I admitted no hands on with Spring, just reading the docs as I get time. How is everyone's real life experience with it? Is there a tutorial track or sample app or something I can use to get started? I'm thinking about rewriting a mid-sized personal project just to practice DI and maybe the JDBC parts.

[Robert Hayes]

Originally posted by Stan James:
Hey, this conversation has gone great. From what I read everywhere, the suggestions are pretty mainstream with nothing risky or weird.

At the top I admitted no hands on with Spring, just reading the docs as I get time. How is everyone's real life experience with it? Is there a tutorial track or sample app or something I can use to get started? I'm thinking about rewriting a mid-sized personal project just to practice DI and maybe the JDBC parts.

So far (about 6 months in), my experience with Spring in the real world has been eye-opening. My designs and code have become much purer, and my frustration level has dropped a few notches when working with projects using Spring.

I would recommend the books J2EE without EJB and Professional Java Development with the Spring Framework. The latter has been invaluable although it is largely documentation included with the framework.