[PJUG Javamail] Why EJB?

[Michael Phoenix]

Hi Richard,

I've been looking into this because we had a presentation on Hibernate in
July where one of the presenters suggested actually using Hibernate with
EJB3, but didn't give a lot of details. However, I don't believe this always
the case. I just started looking at it again because some of the JBoss
documentation I have been looking at discusses the two technologies. There's
tons of opinions on how the two technologies compare. What it seems to boil
down to is that Hibernate provides persistence and object-relational
mapping. EJB 3.0 provides persistence though its Entity Manager and also
provides other services such as clustering, messaging, and transaction
management. Also, it appears that EJB3.0 is a specification which is
implemented differently by different applicaiton servers. Hibernate is an
actual implementation of a persistence engine which is compliant with EJB
standards.

In setting up Jboss 4.2.3, I am playing with one of the sample applications
I discovered that their imlementation of EJB3 uses Hibernate as its
persistence manager. Glassfish implements EJB3 differently. As recently as
January of this year you could not use Hibernate as a persistence engine
with EJB3. However, it is my understanding that steps are being taken to
correct this situation.

I'm pretty much a newbie with this stuff, so if anybody sees where I may be
in error, let me know.

Mike

On Thu, Sep 11, 2008 at 7:20 AM, Richard Johnson <richardj at lingosys.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pjug.org/pipermail/javamail/attachments/20080914/8430a93d/attachment.html