Spring vs EJB

[Lady]

Hi all,
I am trying to understand when is better Spring instead EJB

the documentation says:

Spring does not support propagation of transaction contexts across remote calls, as do high-end application servers. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature. Normally, we do not want transactions to span remote calls.

Can somebody help me to understand it?
If I chose spring and then I realize that I should have used EJB, How do you recommend to implement my application in order to modify this easily?

Thanks for any comment,

[Andreas Senft]

When your application properly separates interfaces from implementation then there is no problem at all.

Your client still uses the interfaces as before (just the configuration inside the application context has to be modified slightly).

The existing serverside POJOs can be wrapped by EJBs while reusing the existing interfaces.

The overhead of transforming a POJO based remoting application into an EJB based remoting application is quite small. So rest assured.

Regards,
Andreas

[karldmoore]

Indeed, one of the beauties of developing an application in this way! I've not yet come across a problem where I had to go with EJB as it was the only option. I've typically found EJB to be a minor part of an application (in real terms).

[Paul Newport]

I'm assuming we are talking about session beans here.

The question is, what does your application need to do ? If it just needs to call transactional services then Spring is hugely simpler and easier to use than EJBs.

The main advantages are speed of development and performance, reduced code complexity and volume, ability to test code outside of a container, and being able to run your application in something as simple as Tomcat, i.e. no need for a fully blown (expensive) app server.

The disadvantage is you can't do a remote EJB call, but in probably 99.99% of the time, why would you want to anyway ? And even if you did, do that for the 0.01% of the application that requires this, and do the rest in Spring.

[Andreas Senft]

The disadvantage is you can't do a remote EJB call

The only benefit of EJB remoting is the possibility to propagate a transactional context. Though this is a rarely used feature.

The alternative remoting capabilities provided by spring should suffice normally.

Regards,
Andreas

[dr_pompeii]

hi guys
(sorry for my grammar)

why until now or in these years, spring doesn't has added this feature???

The only benefit of EJB remoting is the possibility to propagate a transactional context.
Though this is a rarely used feature.

yes, rarely used, but, ..... why not finish to avoid in a 100% the EJB???

or am i wrong in concepts???

regards

[wpoitras]

Spring doesn't reinvent things that work fine the the way they are. If you need to propagate a transaction over a remote connection use EJBs. If you don't, there are other remoting to choose from if you want. If you don't even need remoting, then use a POJO works fine. Spring can help in any of those scenarios.

[Andreas Senft]

Spring doesn't reinvent things that work fine the the way they are.

+1

After all, it is not the goal of Spring to replace EJBs (as far as I know ). Spring is good in encouraging good programming practice and I think, client controlled transactions don't fit this category.

Just my 2 cents,
Andreas

[dr_pompeii]

After all, it is not the goal of Spring to replace EJBs (as far as I know )

well,
maybe no replace,
but maybe avoid use the cumbersome world of ejb working with pojo sounds better

it seems everybody are happy with the mentioanted feature of j2ee

Spring doesn't reinvent things that work fine the the way they are

i am agree, not reinvent,
but maybe has a better solution/performance could be the objective

regards

[Rod Johnson]

It would not be particularly hard for us to add this feature. But it's not really good practice, as previous posters have explained. We are not interested in checkbox-inspired implementation of questionable features in other technologies. I cannot recall a case where I've seen propagation of tx contexts over the wire which couldn't have benefited from better design.

If you use Spring remoting via JNDI RMI in WebLogic, at least, you should get tx propagation, as it's part of their clustered RMI not EJB.