So JSR220 (EJB 3.0) is out for public review now. It has some neat new features in it to try to simplify EJB development.

I've been working with EJBs for a long time (back since 2000 or something). I've always discounted Entity EJBs for being terribly ineffective. For a 2000-2003 a typical interview question was "When would you use Entity beans?" with the correct answer being "Never" and the incorrect answer being Sun's blargh about how great they are.

Stateful beans were also kind of a waste, I've only seen one instance where you would actually use a stateful bean instead of some other more lightweight cache (like HttpSession for instance).

That left Stateless EJBs which were handy for transaction control and distributed apps. EJB2.0 brought us MDBs which are pretty handy for async processes (way better than the old db or file pollers).

In my current architecture that my company is using, we implement SOA with EJB service implementations. We did this for 3 reasons: 1) we get remote access to services and can distribute services across physical servers 2) we get container managed transactions 3) our previous technical director told the board of directors we were using EJBs so we had to.

So we have a bunch of services with EJB implementations. I was thinking about why we need the overhead of EJBs. I mean we never have remote access to our apps. There's no way we'd ever run the war and EJBs in separate JVMs. And our web service framework will provide remote access when someone really needs it (SOAP is just as fast as RMI). That kills issue #1.

A lot of our access goes to legacy systems that don't support J2C. So the EJB can't really control transactions. We have to code it ourselves. This kills #3.

Finally, number 3 isn't really relevant since the technical director is gone and the board has changed a lot since his edict.

So I'm thinking of just scrapping our EJBs and making our web apps call out to the standard, plain java classes. The service impls won't be distributable (away from the war) and they won't doa ny transaction magic for us, but they will be quick and easy to deploy. No more JNDI bindings and clustering settings. No more bean pools and crap like that. And now we can run in TomCat, which makes life easier (and cheaper).

I wonder if the spread of Web Services is really going to kill EJB. As most of the EJB features are overlapping with features provided by WS engines. Let me know if you're using EJBs and if so, why.

Oh yeah, IntelliJ 5.0 from IDEA just came out. It's the best IDE in the world (for any language). I know it's better than Eclipse 3.1, but I can't really remember why. I know it's more than Eclipse's stupid compiler.