• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Spring and EJB 3.0

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Craig Walls
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 884
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic