ejb 3.0 vs ejb 2.0 vs Hibernate revisited

[Ronald Heukers]

Hello all,

Ok I know the rules here, first look in the forums if you can already find the answer and also look with Google. I did. So be kind to me.

The answer is not clear to me, when you look at criteria like installed base, stability, performance and caching, ease of maintenace, scalablity, and transaction management I can not figure out from the former discussions when which technology to use. In the former discussion they most of the time focus on one point. I would like to know when you use which technology.

For an architect it seems to me there must be objective criteria of when to use Hibernate, when to use EJB 2.0, when to use EJB 3.0. Which are these criteria and how do the different technologies score on it? Or is just all a matter of individual preference? This cannot be true can it?

Regards,

Ronald

By the way also the many other persistency products like TopLink, JDO etc. etc. I'm interested in.

[Paul Sturrock]

OK maybe a little bit of a glib answer, but currently I'd say:

When to use EJB 3.0 (assuming you mean as persistance technology)? When the specification is released and major app. server vendors (IBM I'm looking at you here) have added support for it to their products.

When to use EJB 2.0 (assuming you mean as persistance technology)? Never.

When to use Hibernate? Now, if you need a proven, simple, reliable ORM product.

[Gregg Bolinger]

I was actually thinking about this this morning but in a bit broader way. I wasn't thinking about the persistant technology specifically but more the container. So my delimah was when to use Spring (with hibernate, ibatis, jdo, etc) and when to use EJB3.

[Ronald Heukers]

Hi,

Thanks for your replies, and yes sorry I meant it as a persistency technology.

Paul: why never to use EJB 2.0? From EJB 3.0 is the specification not yet released is it?

regards,

Ronald

[Paul Sturrock]

JRS 220 is in public review. But it is not a final release yet. Even when it is, you still need the app. server vendors to catch up.

Why not use EJB 2.0 (as persistance technology)? Reasons (feel free to disagree):

Your persistance technology requires a container.

You can only access you persistance layer from an EJB

You cannot pass an Entity Bean to a client

Your persistance technology includes the baggage of all the other container services which make then nnedlessly complex. Why do you need declarative security in you persistance layer when you can only access it from an EJB (which includes declarative security).

Entity Beans are not portable between app. servers, despite claims to the contrary. You can't do much useful with Entity Beans without using vendor specific features.

EJB-QL is a subset of SQL, and as such you are constantly struggling to work round its limitations.

Entity Beans either dilute your Object model, or enforce bad ER modelling.

They are really designed from CRUD operations, and as such are a poor choice for producing large, read only result sets.

Slow to code, without an IDE which does much of the configuration work.

There is no option to use SQL directly.

You can't map an Entity Bean against a stored procedure.

[Ronald Heukers]

Hi Paul,

Is it in EJB 3.0 possible to map an Entity Bean against a stored procedure?
That is something we really need in our organization.

regards,

Ronald

[Ronald Heukers]

What went wrong here? I'll ask the question again:

Is it possible to map an entitybean on a stored procedure?

regards,

Ronald

[Paul Sturrock]

Not as far as I'm aware. Don't take my word for it though - read the JSR.

Hibernate supports them though.
[ September 20, 2005: Message edited by: Paul Sturrock ]

[Ronald Heukers]

Ok, thanks!

[Pj Murray]

Originally posted by Paul Sturrock:
JRS 220 is in public review. But it is not a final release yet. Even when it is, you still need the app. server vendors to catch up.

I agree, it's still too early to consider using EJB 3.0 for Java persistence.

In fact, given that it's a fairly major specification, there's a good chance that it won't be "perfect" the first time. If you really want to play it safe, you would wait until 3.1 and benefit from early adaptors testing the first version of the new specification.

It's very rare for a new specification to get it 100% right the first time.

With regard to EJB 2.0 for Java persistence, there are some (rare) circumstances when you could consider using it. For example, EJBs might be mandated for all development with a particular organization.

[Mike Keith]

Ronald,

If you looked at previous threads on the topic of evaluating persistence products and technologies then you may have already noticed that objectivity can be in short supply on this site.

I would recommend that the safest way to determine the persistence product that is best for you is for you to evaluate them based upon the type of application that you are building. Like any range of products each will have its own strengths and weaknesses, and you will find yourself trading off performance for price, or ease of use for scalability, standards for specialized features, etc. etc. Some factors will be more important to you than others, and they may not be the ones that matter to other people.

Also, many of the people who post on this site seem to either be Hibernate-leaning (which is perfect if you are just looking for an excuse to use Hibernate), even though they have not tried the other solutions, or shilling their own product.

The only way for you to choose the best solution for your application is to look at your own criteria and base your decision on it. This means that you have to look around and find out what these products have to offer by evaluating them. Unless I was building an app to store my personal address book I wouldn't bet 40% of my application code on some random person's opinion. :-(

-Mike

P.S. To answer your question, EJB 3.0 supports mapping to an entity any raw SQL that returns a JDBC result set. Other types of SQL can still be executed.

P.S.S. If you are just starting your project then now is the time to start using EJB 3.0 and lots of people are doing just that.

[Pj Murray]

Originally posted by Paul Sturrock:
[QB]JRS 220 is in public review. But it is not a final release yet. Even when it is, you still need the app. server vendors to catch up.

Hi Paul,

I wrote a blog entry recently on the appropriate timing for starting to use EJB 3.0 recently:

http://www.codefutures.com/weblog/corporate/archives/2005/09/ejb_30_persiste.html

However, it's very important for the whole standards process in Java that some early adoptors with spare time use the technology previews of new specifications.

Before you correct me, I'm not suggesting that anyone should risk using EJB 3.0 in a real commercial project.

[Mark Spritzler]

Well not talking about EJB 3.0 Persistence part, but we are already using EJB3 Session Beans in our production application here at Gateway. I wouldn't want to go back to EJB 2.1. They definitely got the Session Beans right, and it is really nice. There is literally no extra work except adding that @Session to your interface. Using JBoss's implementation of EJB 3.0 is simple too.

Goodbye EJB 2.1

Mark

[Pj Murray]

Originally posted by Mark Spritzler:
They definitely got the Session Beans right, and it is really nice. There is literally no extra work except adding that @Session to your interface.


Mark

Thanks, good to know.

Also, it's an example of how it can take multiple iterations of an industry specification to get things right.

It's only with people like you, willing to try out new implementations of new specifications, will Java remain competitive and relevant.

[Mike Keith]

They definitely got the Session Beans right, and it is really nice.

Thanks, we think so, too. Try the persistence API and I think you will come to the same conclusion.

There is literally no extra work except adding that @Session to your interface.

I think you mean adding @Stateless or @Stateful on the session bean, not the interface. (That is part of the beauty of it -- you don't need any special kind of interface or session bean impl class.)

Using JBoss's implementation of EJB 3.0 is simple too.

*Every* implementation of EJB 3.0 is simple. That's the point.
JBoss just happened to be the first one you picked up. Try some others and you will find them simple, too.

-Mike