EJB 3.0 or Spring framework

[John King]

Which technology is better?

[Reid M. Pinchback]

Yes.



I don't think it is a better-or-worse. Each has strengths and weaknesses. "Better" is likely to depend on what you are trying to do. It also clearly depends on whether or not you have choice of which vendor's J2EE appserver you work with, since 3.0 support varies.

[Mark Citizen]

Based on my own experience Spring is better for simple web applications (quick deployment, relatively easy to code), while EJB is better for B2B services, and complex distributed apps.
One thing: if you know you need to use EJBs, I wouldn't recommend mixing them with Spring, since you'd need to maintain both application descriptors and Spring xml config files (not to mention the coding part). Regardless of what Spring framework website says, it's not a walk in the park.
HTH,

Mark

[Reid M. Pinchback]

Originally posted by Mark Citizen:
If you know you need to use EJBs, I wouldn't recommend mixing them with Spring, since you'd need to maintain both application descriptors and Spring xml config files (not to mention the coding part). Regardless of what Spring framework website says, it's not a walk in the park.

Hmmm, this sounds interesting. I can guess at some possible issues, but that isn't as good as hearing real war-stories straight from the trenches. Was it simply just needing to remember which issues you dealt with in which XML files, or was it something more subtle, like maybe having Spring behaviour play properly in an EJB context?

[Michael Duffy]

Originally posted by Mark Citizen:
Based on my own experience Spring is better for simple web applications (quick deployment, relatively easy to code), while EJB is better for B2B services, and complex distributed apps.

I don't agree with this. There's nothing in Spring that puts a limit on complexity. Maybe simple web apps and easy to code is all you've used Spring on, but I don't think that's a limitation that Spring imposed on you.

One thing: if you know you need to use EJBs, I wouldn't recommend mixing them with Spring, since you'd need to maintain both application descriptors and Spring xml config files (not to mention the coding part).

Since the whole point of Spring is to make it possible to do Java EE without EJBs, I'd agree that it makes less sense to deploy Spring with EJBs. But there's no reason a legacy app that already has EJBs can refactor or add new functionality using Spring that co-exists with EJBs.

Maintaining descriptors and config files aren't the worst part of complex systems. I think that's what XDoclet and annotations are for. Generate them.

Regardless of what Spring framework website says, it's not a walk in the park.

Indeed, but that's true of all complex, enterprise systems. EJBs aren't a walk in the park, either. We still haven't hit on a single technology that reduces complexity to the point where it writes itself.