BT

Is Java EE 5 easier with EJB?

by Geoffrey Wiseman on Sep 05, 2007 |

Many enterprise Java developers gained some experience with Enterprise JavaBeans back in the era of EJB 1.X and 2.X, and many of these developers went on to choose technologies they deemed lighter-weight, such as the Spring framework, because they felt that building a solution by hand, or with a lighter-weight framework was easier and less time-consuming than Enterprise JavaBeans.

Both Java EE 5.X and EJB 3.X sought simplicity and lighter-weight development practices; is it still true that a POJO-solution is simpler, more-comprehensible code? Adam Bien doesn't think so:

Actually it is hard to simplify the EJB 3.0 (suggestions are really welcome).

The funny story is: Java EE 5 webapplications without EJB 3 Session Beans are more complicated.

He demonstrates with two code snippets, one with EJB 3 and one without, and concludes with:

The code not only simpler but also cleaner. The resources are managed and injected by the container. But with the introduction of a single Session Bean the manageability and monitoring can be significantly increased. With tools like Glassfish's call flow you can monitor the performance of the whole invocation stack. The coolest story - the XML-configuration is optional. In EJB 3.1 even the local interfaces will be optional.

Matt Corey adds:

Interesting topic, given that in EJB 3.1 it will also no longer be necessary to package your EJB's separately from your web application... From the JSR: "Support for direct use of EJBs in the servlet container, including simplified packaging options."

Jason Carreira provides some counterpoints:

The thing is, as much nicer as EJB3 is vs. EJB 2.1, Spring is that much nicer than EJB3. EJB3 dependency injection is pretty weak compared to the full power that Spring gives you to wire your stack together.

Plus, why do I want to depend on different app servers implementing the EJB3 spec compatibly when I could just bring the Spring jars with me and always have a consistent implementation? If I decide to stick with a particular implementation of Spring, I can bring that with me to any app server or servlet container, and, if the specs move on and change, I won't have to upgrade or change my code if I don't want to. Will the newest release of your app server still run your EJB3 application in 5 years? 10? Maybe, maybe not.

The comparison between Spring and EJB3 is a common one; many people left the complexities of EJB 1.X and 2.X for Spring and now find themselves wondering how EJB 3 compares, or a larger shift to Groovy and Grails or Ruby and Rails.

Is Java Enterprise Edition simpler with EJB3 than without? If you've used previous versions of Enterprise JavaBeans, does the new simplicity help to encourage you to use them again?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

To late by Vic C

Spring 2 and Hibernate(Java) should be compared to Ruby, C#/Mono, Flex+Gears, even php5(lots of large sites in silicon valley are LAMP), Lazarus, etc.
Compare readability, elegance, etc.

[Anotation] //like a macro?
Map <Map><String,Object> m = new HashMap.... // wtf?

XML, Hibrenate caching/treading intermittent issues for anything a big larger, Spring's aspects....
Java(Spring+Hibrenate) has gotten less readable relative to alternatives.

Java is lots of XML mapping, and harder to read. Anotations and Typing was added to base lang to make EJB product a bit less painful, but in the process Java got a bit worse. Where are days of KISS Struts and JDBC/iBatis.

(Groovy, T5, iBatis, Mina type projects are exceptions).

.V
ps: My Favorite now is D (wxD).

Re: To[o] late by Geoffrey Wiseman

I'm curious if approaches like Seam help to bring people back 'into the fold' as well.

I'm still not sure that I'd seriously consider EJB for my next Java project, although it might not in and of itself disqualify other approaches (e.g. Seam).

personal experience by Gerald Loeffler

hi,

as an experiment about a year ago we finished implementing a non-trivial SOAP service layer plus web-frontend using Java EE 5 (Hibernate via JPA, EJB3 stateless session beans, JAX-WS 2.0, JSF; on JBoss). My experiences in a nutshell:
- if you fully submit yourself to Java EE 5 it is a very clean, very concise programming model.
- the interplay between EJBs, the transaction manager and the JPA persistence manager is precisely defined by the spec and works correctly without needing to configure anything. Thus it's IMHO much easier to get a transactionally correct application up-and-running than with vanilla Spring and Hibernate. Having said that, the latter is not a big deal either (but it needs to be done and can be (and often is) done wrongly.)
- the single most severe restriction IMHO is that you can use DI only for JavaEE-supported resources (in contrast to the much more general Spring approach to DI). So all DAOs/Repositories need to be session beans; everything that calls an EJB must be an EJB (or JSF managed bean) itself (if you want to rely on JavaEE 5 DI). There is no indirection similar to Spring's proxy factory beans. In short, JavaEE 5 defines what can be injected and into which objects it can be injected.
- the feature i missed most was decent AOP support (rather than EJB3 Interceptors) ala what you get with Spring and the AspectJ pointcut language. Furthermore, there is no painless way to use the latter with EJB3, so that i ended up making do with interceptors.
- it was quite painful to work around gaps in JBoss' only partially compliant implementation of Java EE 5 (such as JSF 1.1 (instead of JSF 1.2) managed beans not being able to have session bean references injected; full JAX-WS 2.0 annotations not being available on session beans). That's a non-issue with a fully Java EE 5 compliant container (or the very latest JBoss versions) of course.
- better to not talk about testing EJB3 enterprise beans outside the container (although the idea of the JBoss microcontainer sounds good...)

regards,
gerald

www.gerald-loeffler.net

Re: personal experience by Alexandre Poitras


- better to not talk about testing EJB3 enterprise beans outside the container (although the idea of the JBoss microcontainer sounds good...)


This is my main beef against EJB3 : the spec doesn't state that the EJB container should be embeddable in the application (I think only JBoss offers this feature at the moment). This is one of the main selling point of Spring and I don't see what stop EJB vendors from doing it.

Re: personal experience by Steve Tekell


- better to not talk about testing EJB3 enterprise beans outside the container (although the idea of the JBoss microcontainer sounds good...)


This is my main beef against EJB3 : the spec doesn't state that the EJB container should be embeddable in the application (I think only JBoss offers this feature at the moment). This is one of the main selling point of Spring and I don't see what stop EJB vendors from doing it.


Is JBoss the only one even considering this? Right now their microcontainer is still "alpha, scarcely tested" software (according to JBoss).

Until EJB without a full JEE5 container is a more realistic possibility, it's not an option for the projects I work on. Without that how could EJB3 be easier when you consider the full development process?

I've recently been moving applications away from JBoss/Full-JEE containers to Spring/Tomcat. The startup time of JBoss is hideously long and a general nuisance to development and testing cycles. The idea of going back to having JBoss or any beast of a JEE server in the mix is repelling.

While EJB3 may be great for people already deploying to full JEE servers, moreso if they are migrating from EJB1/2. How great would EJB3 have to be to get people to switch from Tomcat or Jetty to JBoss?

And as others have mentions, in some respects, like DI, EJB3 is definitely inferior to Spring. So it's still a pay more, get less option for many people at this point.

Reasons to use EJB by Sato Tadayoshi

As far as I understand, there are only two things which EJB supports and Spring does not support:
- transaction propagation over multiple app servers,
- clustering with session replication.
If you have any (political or non-political) reasons you must adopt them above, the only choice would be EJB.

Otherwise, Spring is better. (If you work in Japan, Seasar - yet another famous DI container - is also an alternative.)

Re: Reasons to use EJB by Steven Devijver

As far as I understand, there are only two things which EJB supports and Spring does not support:
- transaction propagation over multiple app servers,
- clustering with session replication.
If you have any (political or non-political) reasons you must adopt them above, the only choice would be EJB.

Otherwise, Spring is better. (If you work in Japan, Seasar - yet another famous DI container - is also an alternative.)


Actually, starting from Weblogic 8 you can have transaction propagation between different servers with Spring, no EJB required.

Session replication ofcourse is something you can get with Terracotta, GigaSpaces, ...

Re: Reasons to use EJB by Sato Tadayoshi

Steven,

Nice advice. Thank you.

Re: Reasons to use EJB by Jason Carreira


Actually, starting from Weblogic 8 you can have transaction propagation between different servers with Spring, no EJB required.

Session replication ofcourse is something you can get with Terracotta, GigaSpaces, ...


Right, or you can deploy a Spring + Hibernate app in any full-fledged app server to get HTTP session replication with the easier programming model.

Re: personal experience by George Jiang


- the single most severe restriction IMHO is that you can use DI only for JavaEE-supported resources (in contrast to the much more general Spring approach to DI). So all DAOs/Repositories need to be session beans; everything that calls an EJB must be an EJB (or JSF managed bean) itself (if you want to rely on JavaEE 5 DI). There is no indirection similar to Spring's proxy factory beans. In short, JavaEE 5 defines what can be injected and into which objects it can be injected.


I noticed too that EJB calling EJB is no longer an anti-pattern in EJB3.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT