In case you haven't seen it, there's an article on OnJava by Michael Yuan entitled POJO Application Frameworks: Spring Vs. EJB 3.0.
I've met Michael (he's a friend of a friend) and I can say that he's a really nice and sharp individual. But as a proponent of Spring, I can't let this article go by without making some small comment.
I really wish I had the time to go into all of the details of his article and respond, but I simply have too much on my plate today. But here's a few tidbits I'd like to respond to:
- "Spring has a proprietary XML format for configuration files and a proprietary programming interface. Of course, this type of lock-in happens to any non-standard product; it is not specific to Spring." -- Okay...granted Spring has it's own configuration file format and API. But how is that different from EJB 3? Sure, EJB 3 is standard, but you are still locked into EJB 3. Not that this is a bad thing (in some ways I like EJB 3), but if you think that choosing a "standard" protects you from risk, you should think about what's going to happen to all of those EJB 2.x projects when backwards-compatibility quits being supported in the EJB-spec.
- "But still, the long-term viability of your Spring application depends on the health of the Spring project itself (or Interface21 Inc., which hires most of Spring's core developers)." -- Given the recent announcements from BEA, I think Spring is stronger than ever. Again, I question the long-term viability of EJB 2.x applications.
- "if you need to switch the persistence service provider (e.g., change from JDBC to Hibernate) for a Spring application, you will need to refactor your application code to use the new helper classes" -- That's only somewhat true. Sure, you'd need to rewrite your DAO and you'd have to make a minor change to your configuration file. But if you're decoupling your persistence code from the rest of your application (as you should), this is such a minor impact. I'll admit ignorance on how EJB 3.0 handles this...can you even switch out persistence mechanisms in EJB 3.0?
- Use of XML vs. annotations -- First off let me admit that I'm a strange sort of developer who actually doesn't mind XML. Flame me if you want, but I think XML is a suitable mechanism for configuration. I also like annotations. I think both XML and annotations have their place. Spring recognizes that as well. In Spring you can use XML exclusively or you can opt to use annotations for things like declarative transactions and security. That said, I think it is just as wrong to use annotations exclusively (like EJB 3.0) as it is to use XML exclusively. Each has their place.
- Spring makes it much easier to choose which components go into your application stack a la carte. But, as Michael pointed out, JBoss also supports a modular design to enable you to skinny-down your app-server. So, in the flexibility in service assembly column, Michael gives EJB 3.0 no point, Spring 1 point, and JBoss 1 point.
- Michael's example of using annotations to apply declarative transactions is good, but the Spring example is skewed toward heavy use of XML. With a bit of though, you can dramatically reduce the XML in his example and even use annotations to apply transactions in Spring.
Again...I really wish that I had more time to comment on this article. I'm not bashing Michael, EJB 3.0, or JBoss. Michael's a sharp guy. EJB 3.0 is a huge step forward compared to EJB 2.x. And, unlike many, I don't find it all that fashionable to bash JBoss.
But in my opinion, there's room in this world for both Spring and EJB 3.0. And Michael's article definitely had an EJB 3.0/JBoss slant to it. I couldn't let that slide by without make a few comments.
I invite (read that as "beg") other Spring folks to respond to Michaels article in more detail than I did. I'd love to read a Spring-slanted response to this article (just to balance things out).
