Wednesday, February 25, 2009
EJB 3.0, Really?
EJB 3.0 has been out for a long while and I must say that I feel the same way about it now as I did when it first came out – I really couldn’t care less. It took me a long time to even take a look at EJB 3.0 to see what was new. Surely this is due in part to Sun’s refusal to drop the EJB moniker. A move I would consider an abysmal marketing mistake given the reputation of EJB 1 & 2. I’m sure there are plenty of people who eagerly adopted Sun’s new EJB offering the instant it was released. These are the people that like to blindly gobble up everything Sun has to offer and proclaim said offerings as de facto standard. However, I’m guessing there are a lot of people out there that feel the same way I do. We remember spending countless hours thinking there must be a better way while working with Sun’s first two attempts at EJB. At some point during this painful experience we cautiously looked around and found out we weren’t the only ones who noticed that the emperor had no clothes. We realized it was ok to move on to using other solutions for things like remoting, ORM, transaction control and object security and we never looked back. Sure, I’ll admit that there’s a small part of me that would like to have all of my tools come in one nice little package from the same vendor. This is the same part of me that wants all of my stereo components to be the same brand. Unfortunately for that part of me, I think EJB 3.0 is to Hibernate what JDK logging is to Log4J - too little, too late.
It’s not that I dislike Sun as a company. I really like them. Java is cool, so is the servlet specification; Sun has done some great things. EJB is just not one of those things, at least not the first couple of tries. Granted, EJB 3.0 is a huge departure from and drastic improvement over the previous approach. It's not bad technology. However, I really don’t think it offers any huge advantages over similar options provided by frameworks such as Spring and Hibernate. If Sun really wanted to make a run at bringing EJB back from the dead it should have offered a significant improvement over the other industry standard tools that solve the same problems. Basically the Java community had found alternatives to a technology that was over sold and EJB 3.0 is Sun’s response to those products. Not that I disagree with that approach from a business standpoint; by all means, if you’re not getting something right, copy the guys who are. However, given the widespread adoption of EJB alternatives couldn’t Sun just let EJB die? If all Sun was going to offer was a “me too” product, the development community would probably have been better served if they did. I suppose an argument can be made for having multiple options but I really don't see that much value in yet another ORM or remoting technology.
I know there are plenty of projects out there using EJB 3.0. Given this rant, I’m sure I won’t be spared the irony of being dropped on one in the near future. However, I haven’t had the, ah, pleasure of using EJB 3.0 on a large project yet. I’ll be the first to admit that my perception derived from reading docs and playing with tutorials could be way off base. So, if anyone has been on a wildly successful EJB 3.0 project that convinced them to swear off using anything other than EJB, I would love to hear about the features and functionality that made you an EJB convert.
Subscribe to:
Post Comments (Atom)
Please read this article:
ReplyDeleteEJB 3.0 Transaction