Can EJB's be used as more than facades?

In the 'good old days' of EJB 2.x, we were trained to design systems such that the 'facade' was created with EJB Session Beans (usually stateless), while everything behind it could be regular Java classes... there were exceptions, of course, as it may have been necessary to access an occasional EJB from behind the facade if it was located remotely, it had different transactional requirements, or if we were simply dealing with a third party component, but for the most part, this is the mantra that we followed... at some point, Spring came along and made us realize that we didn't really need the heavy-weight EJB's at all, so we threw them out all together... and there was much rejoicing...

Now we have EJB 3, which improves on the old spec in pretty much every way... While I won't suggest that EJB 3 will be usurping Spring usage anytime soon, there are certainly places where EJB's are now at least as good a design choice, if not better... The problem is, we lose the nice Dependency Injection that Spring gives us in these cases...

But hold on -- take a step back and look at your design... if you're designing your app with the old Session Facade in mind, the previous statement is certainly true -- you can't use DI to assemble your domain objects beyond the outer layer -- but I think I can make a case for bringing EJB's back into the heart of your application...

Let's look at reason number one for the original Session Facade -- creating a Session Bean used to be tedious, and it caused us to alter the way we program (ok, reasons 1 and 2, I guess)... but this isn't true anymore -- it's no longer tedious to create a Session Bean -- you just add '@Stateless' to your class... it's also no longer necessary to alter the way we program, at least in many cases -- we don't have to work with Service Locators or Business Delegates, we don't have to manually look anything up in JNDI -- all we have to do is add '@EJB' or '@Resource' to our member fields...

So by allowing any and/or all of our domain objects to be EJB's, we gain the Dependency Injection benefits of acquiring other resources as well... for example, if your Repository or DAO is created as an EJB, you can inject your EntityManager into it quite naturally...

Of course, it's not a perfect scenario... there's some overhead involved in an EJB method call -- security and transaction management, for example -- that could potentially cause your app to be slowed down a bit... personally, I'm not convinced that the slight performance decrease would outweigh the benefits you get from the very natural DI system, but that's purely my opinion... If anyone has any hard data on the kind of performance profile you'd be looking at, I'd be interested in seeing it... additionally, I believe it would be possible for a container to intelligently optimize the calls out in many cases -- I'm not sure how much of this is technically allowed by the spec, but it should be extremely quick to check for an existing, open transaction, for example...

As an aside, the recent Web Beans sneak previews from Gavin lead me to believe that we will be able to get the benefits that I describe above without the drawbacks -- of course, Web Beans may end up signaling a return to the Session Facade for transaction management, while our Domain objects are assembled with the Seam-and-Guice-like Dependency Injection, but hey, it's always good to question what we 'know' occasionally, right?

So is it time to throw away our prejudices against EJB's? I think for a lot of us, it's at least time to reevaluate them...

M