This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes Spring and EJB 3.0 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Spring and EJB 3.0" Watch "Spring and EJB 3.0" New topic
Author

Spring and EJB 3.0

Regis Santos
Ranch Hand

Joined: Mar 23, 2004
Posts: 31
Hello Authors,

Spring came to solve many problems caused by EJB. Now, the JCP works to approve the new spec EJB 3.0, that promisses to bring the power with less effort to developers (like Spring).

Do you think that the developers will migrate from Spring to EJB 3.0 in a near future?

Bye!


Regis Santos
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Regis Santos:

Do you think that the developers will migrate from Spring to EJB 3.0 in a near future?


First a disclaimer: This is all my opinion...no hard and fast facts will follow.

Some developers may embrace EJB 3.0, but IMO, EJB 3.0 is "too little, too late".

In the "too little" department: EJB 3.0 is a huge step in the right direction, but it still doesn't match the simplicity of Spring and POJOs. Furthermore, EJBs will still require a much heavier (and typically more costly) container.

As for "too late", a lot of developers have been burned by EJB and probably aren't interested in picking it back up again, no matter how much better it is now.

For me, I will probably invest a little time getting to know EJB 3.0, but I'm not making it a priority.


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Originally posted by Craig Walls:

In the "too little" department: EJB 3.0 is a huge step in the right direction, but it still doesn't match the simplicity of Spring and POJOs. Furthermore, EJBs will still require a much heavier (and typically more costly) container.


What do you mean by heavier & costly? Heavier as in the fact that a container is required? Or the container would require more resources like memory & processing power? Costly because you've to purchase license & hence pay for the container? Or costly in terms of processing power & memory usage incurred?


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Chengwei Lee:


What do you mean by heavier & costly? Heavier as in the fact that a container is required? Or the container would require more resources like memory & processing power? Costly because you've to purchase license & hence pay for the container? Or costly in terms of processing power & memory usage incurred?


"Heavy" in that you need a full-blown application server. EJBs have always been (and still are) designed with the assumption that you're going to buy an application server with all sorts of bells and whistles. Maybe your application needs that, but many don't. In contrast, Spring doesn't require an application server. Spring's container is lightweight and you can even write command-line applications whose objects are wired together in a Spring container. Of course, if your Spring application is a web application, then you'll need a servlet container such as Tomcat. But Spring itself isn't dependent on any form of application server.

"Costly" may have been an inappropriate jab at how most app servers come at a price. JBoss being one exception, most EJB containers are packaged within a costly (in $$$) application server. Spring, in contrast, is a free download, requiring no application server.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Hello Craig,

How easy will it be to port to EJB 3.0 from Spring? How do we write Spring application if we have portability to EJB 3.0 in mind. Please reply. Thanks.


Groovy
danny liu
Ranch Hand

Joined: Jan 22, 2004
Posts: 185
Craig,

Spring's container is lightweight.

Does that mean its functionalities are also limited, such as transaction, security support?

Spring, in contrast, is a free download, requiring no application server.

Does any IDE support Spring framework?

Thanks.

Dan
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Pradeep Bhat:
Hello Craig,

How easy will it be to port to EJB 3.0 from Spring? How do we write Spring application if we have portability to EJB 3.0 in mind.


Hide things nicely behind a dao !
Sorry if this has become too repetitive these days. I couldnt think of anything else.

If its about persistance, Spring allows you to use Hibernate for persistance. It does not provide anything out of its own. EJB3.0 is providing a persistance solution.I think as long as you can hide your stuff nicely behind a DAO, things should? be fine.
Hiding things behind a DAO is probably a safe solution with/wo Spring. Currently we have HibernateDaoSupport class. Guess it should not be a big deal for Spring folks to give us a EJB30DAOSupport class.
But then you will obviously need to add persistance related markup / annotations / whatever to your pojo to migrate to ejb 3.0. Its not a Spring issue in this case.
Its more of Hibernate -> ejb 3.0 problem. I mean there will be some pain obviously since you will be switching the technology beneath.

+ yes ejb3.0 is jdk 5.0 based since they use annotations extensively.
As long as you are ok with using jdk5 in production , it should? be ok.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by danny liu:

Does that mean its functionalities are also limited, such as transaction, security support?


Far from it. One of Spring's biggest wins is that it provides declarative transaction support to POJOs (plain-vanilla JavaBeans). But it accomplishes this using aspects instead of a full-blown application server. This means that if your reasons for using EJBs are primarily because of their transaction support (as is often the case), then you should really consider using Spring instead.

As for security, Spring itself does not provide declarative security. But fear not, Acegi (http://acegisecurity.sf.net) is a security framework based on Spring that provides declarative security for POJOs and for web applications. Again, as with transactions, security is provided by Spring's AOP framework.

Originally posted by danny liu:
Does any IDE support Spring framework?


I've already given a fairly long list of Spring tools here.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
    
    5
Originally posted by Karthik Guru:
Hide things nicely behind a dao !


That's right. The best approach to flexibility is to hide actual implementation behind an abstraction. For entity beans, this is a DAO.

Even with EJB 2.x, Spring provides an abstraction (known as "SimpleRemoteStatelessSessionProxyFactoryBean") such that you can wire references to EJBs into your Spring-managed beans. In the end, the bean that is the client of the EJB isn't even aware that it's talking to an EJB. As far as it knows, it's talking to another POJO. The abstraction even deals with the RemoteException.
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Originally posted by Craig Walls:


"Heavy" in that you need a full-blown application server. EJBs have always been (and still are) designed with the assumption that you're going to buy an application server with all sorts of bells and whistles. Maybe your application needs that, but many don't. In contrast, Spring doesn't require an application server. Spring's container is lightweight and you can even write command-line applications whose objects are wired together in a Spring container. Of course, if your Spring application is a web application, then you'll need a servlet container such as Tomcat. But Spring itself isn't dependent on any form of application server.

"Costly" may have been an inappropriate jab at how most app servers come at a price. JBoss being one exception, most EJB containers are packaged within a costly (in $$$) application server. Spring, in contrast, is a free download, requiring no application server.


Like you said it yourself, JBoss is free. In fact, so is Jonas, & its certified J2EE compliant too. With two open-source options, we could also switch to them instead of using commercial products. So I would say, money isn't really a strong selling point for Spring anymore.

Yes, Spring is lightweight. But unless we're working with extremely tight hardware specifications, such as a slow server with minimum memory & CPUs, whats the added advantage thrown in for using Spring? Using a decent server, we could always throw in an open-source application server with no fears of hardware limitations.

Of course, if we can see some benchmark performance results of Spring framework against J2EE certified, application servers from some independent parties, it would be more compelling for people to consider moving over to Spring. Perhaps its time the Spring community presents some factual statistics as well as a list of things that Spring can do, while EJB/application servers cannot do. This would definitely answer a lot of queries/doubts people have in mind.
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Originally posted by Chengwei Lee:

Of course, if we can see some benchmark performance results of Spring framework against J2EE certified, application servers from some independent parties, it would be more compelling for people to consider moving over to Spring.


Correct me if i'm wrong. Can we even compare Spring that provides abstraction on top of services to an application server that actually provides those services?

Yes doing the following makes sense to me -

Comparing Spring + Hibernate + ACEGI performance to Jonas EJB Performance.
Now I dont want to get to who provides the jdbc driver implementation. For now we can assume that both hibernate and Jonas will use Oracle's implementation.

Spring AOP Vs JBoss AOP.

But Spring Vs Jonas/Jboss doesnt make sense to me because Spring just by itself is nothing but a DI/IOC container (ok + AOP + MVC).
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
Hi Karthik,

You're right. It won't be a fair comparison. Not that kind of apple to apple comparison.

Thanks for pointing it out.
 
 
subject: Spring and EJB 3.0