Whenever I get together with Ted, the group we are in somehow gets onto the topic of EJBs. We got around to it this time as we had heard the CTO of Orbitz discuss their Service Oriented Architecture, and how they use EJBs. Almost sensing that people would gasp, and think that he must be a bad bad CTO, he clarified that they used EJB for transaction processing.
Fancy that, a use for EJB. Ted and I always end up with “EJB is good at TP and should stick with that”. It isn’t good at persistence, and shouldn’t probably be a distributed object system. EJB is very good at doing the right thing with respect to transactions. The containers are mature, and know how to enlist correctly…. and it all “just works”.
So, as time goes on and I ask myself “when would I ever use EJB in a project”, I find myself justifying it if I was building a truly enterprise system (which is 1% of the total systems that are built?) and I wanted it to handle my TX throughput. In this scenario I could be happy enough using Stateless Session Beans, and Message Driven Beans. For persistence I would not touch Entities with a barch pole, but would opt for transparent persistence (JDO/Hibernate).
The lightweight containers don’t seem to be quite there wrt efficiently doing the right thing with distributed TX, but I am pretty sure that they will catch up. In fact Ron Bodkin (AOP guru) has worked on some nice Aspects that can handle things quite nicely… so this could be promising for the future.
Bottom line? EJBs have a place…. but should focus on the E, and yeah, they aren’t for the majority of projects. I hope that EJB 3.0 gets this, and starts dealing with the requests that developers on these huge systems need, and don’t just slap on some JSR 175 metadata, claim that EJB is easy, and sing a song. If AOP really kicks into gear, I think it would be fun to see EJB be a group of standards around various service aspects.
And don’t get me started on the fact that messaging systems don’t seem to be used nearly enough on projects!