To be J2EE/EJB or not?

[D. Rose]

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?

[Ramon Gill]

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.

Ray

[D. Rose]

Hi,

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.

[Ramon Gill]

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.

Ray

[Serge Adzinets]

I would say declarative transactions are among the few benefits EJB really provides. Usually, EJB only makes simple things more complex.

Speaking about security, what exactly are the benefits of EJB? If you don't have EJB, you don't have security problems with them.

There is an interesting discussion of when to use EJB in Wrox "Expert One-on-One J2EE Design and Development" by Rod Johnson.

[Ramon Gill]

Hi Serge,
I've got a copy of chapter one of the book. I haven't looked at it for a while, but I will have another look tonight. I remember Rod being anti-entity beans.

Ray

[Ajith Kallambella]

Moving this discussion to "EJB and Other J2EE Technologies" forum...

[D. Rose]

Hi Ajith,

I posted it in Architect forum as to clarify concept from Architecture point of view.
Did you move it because I expressed my doubt about certification?

[Ajith Kallambella]

No, I moved this thread since I felt this topic might interest the general J2EE/EJB audience and not just the people taking the SCEA test. Sorry for the confusion.

[Chris Mathews]

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.

[Bill Pearce]

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.