[PJUG Javamail] Why EJB?

[Joe Hoffman]

Ah Richard,  what a great way to stir up the masses and generate some  
email for the  PJUG list....   great question.

I'm not a big fan of EJBs, never have been, never will be.   However  
your alternate solution (Hibernate) has it's own problems which I see  
very frequently.
For me, I look at these systems from a performance perspective,   and  
EJBs are frequently problem spots for performance, but Hibernate is  
even worse.

Most of the time, the problem with Hibernate is that people are using  
it incorrectly, and with a few adjustments and technique changes, they  
can resolve the problem.     But out of the box, it's a problem item  
almost 100% of the time.  Don't get me wrong,   I love the concept and  
the simplicity provided by a tool like Hibernate, it can just be a  
performance problem if not used wisely.

But to answer your question, I get asked a lot by customers, 'Should  
we use X or Y or Z in our Java enterprise app'.  With EJBs I always  
ask them the question back, 'What is it about EJBs that you need? What  
is it you expect them to do for you?',  'Are those features worth the  
complexity of using EJBs?'.   I rarely get an answer which indicates  
EJBs are the ideal solution.

On a slightly different note:  When I think of JEE (I still want to  
call it J2EE),  I include in that bucket lots of things related to  
Enterprise Computing, such as JDBC, JDO, EJB, Hibernate, Servlets,  
RMI, JMS, JTA, threading, etc, etc.   One can pick and choose from  
this list of technologies the things that make sense for their needs.   
One can skip EJBs and still be a J(2)EE app.  One can have Hibernate  
and JDBC and still be J(2)EE.  I don't see them as mutually  
exclusive.   Pick what you want!.   And of course pick the container  
that supports the components you picked.

$.02

joe Hoffman


On Sep 11, 2008, at 7:20 AM, Richard Johnson wrote:

> Hi all,
>
> At the risk of--no, make that desire to--start an argument ...
>
> How many of you have seen *in practice* a genuine need for JEE style
> data beans as opposed to jdbc, or jdbc with O/R mapping (like
> hibernate?)
>
> My experience says that in most cases JEE is overkill, with hundreds  
> of
> lines of code in dozens of objects and deployment artifacts, when  
> three
> or four straightforward classes would do. In almost every system I've
> seen, the DB box is on the same local network as the middleware  
> server,
> behind the same firewall.  Often it's on the same physical machine as
> the app server.  We specify the DB connection on the (remote but  
> local)
> machine in the db.xml file without issue. The DB manages its own
> connection pool. The O/R mapping tool handles reference<-->value  
> issues,
> and threading is handled in the straightforward POJO way.
>
> Of course, I've never had the um ... "pleasure" of working on a system
> that required an intermediary cache and/or JMS for data-to-program
> information flow, where my imagination tells me that beans really
> belong.
>
> ...
>
> Please, someone tell me some reasons why the next project I spec  
> should
> have JEE or EJB in it instead of JDBC and hibernate.
> -- 
> Richard Johnson
> _______________________________________________
> Web Site - http://www.pjug.org/
> Javamail mailing list
> Javamail at pjug.org
> http://www.pjug.org/mailman/listinfo/javamail