This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
On serverside.com, one of the points stated was that use EJB's only if you are using distributed transactions. I also heard this from our CTO. He also said that according to gartner report almost 80% of J2EE projects were failures.
What do you all architects think? I wonder if I should proceed with my certification or not?
Rei, 80% of ALL projects are failures (not just J2EE). EJB's are a good choice for non-distributed transactions as you can use local interfaces (massive performance gains). Sun's Blueprints also recommend EJB's when you need transactions.
This are some people around who currently prefer not to use entity beans (i.e. use JDO's instead). This could change with future releases as J2EE continues to improve.
Joined: Apr 25, 2003
I was also under the impression of using EJB's when using transactions but what is said is that use EJB's only when using 'Distributed transactions' involving more than 1 database. That's why I am confused. My CTO gave an example of porject where they got away with App server , EJB and all and used only servlets as they were not using distributed transactions. He said if transactions are not distributed then DB can pretty well handle them.
Joined: May 15, 2003
Rei, It is possible to use transactions with servlets and not have EJB's, as you CTO has proved to you. However, this is not the best practice advised by Sun in the Blueprints. Using transactions in EJB's is preferred because you do not have to do any transactional coding. You can set up transactional behavior outside of the code by using the deployment descriptors and letting the EJB container do the rest. This makes for simpler coding. The same things can be said about security (use DD's and no coding needed). By 'coding' transactional and security within the servlet, you are more liable to have errors.
I definitely agree with Ajith's assessment of this thread, it is not really about SCEA. Furthermore, I would like to add that any statistics that are touted about project failures are suspect. I am reminded of a very famous quote by Mark Twain:
"There are three kinds of lies: lies, damn lies, and statistics."
Who gathers these project failures statistics? Who determines whether a project is a success or a failure? With what criteria is this determination made?
For me it is actually very simple... if the project does not offer a positive Return on Investment (ROI) then it is a failure. Unfortunately, the simplicity ends there because we really don't have good means on which to measure ROI in software projects. For this reason most projects (that don't fall flat on their face) can be spun by management to be either a success or a failure depending on the politics surrounding the project. Case in point, I have been on a few projects that would not meet the my criteria for success (positive ROI) but were widely touted througout the organization as a huge success. Conversely, I led one project where we delievered a high-quality product on schedule and under-budget only to be canned by upper management due political forces that I hadn't foreseen. Basically, if you yell something loud enough and long enough then people will start to believe it.
Ultimately, it comes this... projects rarely fail for technical reasons. Almost all project failures occur because of social or political reasons. Choosing or not choosing EJB is not going to change this one bit.
Since someone mentioned Rod Johnson, you might be interested to know he has a new book coming out on doing J2EE without EJB. I attended TheServerSide Java Symposium, and Rod gave a presentation on J2EE programming without EJB (see some notes I made here).
Rod makes some very compelling arguments against EJB, especially when it comes to using them in Web applications. More specifically, he argues against distributed objects when we really don't need them. A lot of us need only certain services from J2EE, and there are more efficient ways to obtain them than through EJB.
I have only recently downloaded it and installed it, so I can't give too much testimony, but Rod was the initial creator of the Spring framework, a lightweight framework which seeks to provide some of what we need from EJB, without all the container overhead. Spring provides many things, but I have only set up the Inversion of Control method for obtaining DAO objects and setting the DataSource on the object rather than calling JNDI. I can tell you this has made the DAO/JDBC much easier to develop for my web application, as I can run it very quickly from the IDE, and don't have to redeploy the webapp, etc. to see results.