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

Advertisements

Rethinking Best Practices

Ah, J2EE best practices — the community’s way of figuring out how to work with flawed technologies… You know, the Session Facade, Data Transfer Objects, etc. — they are ingrained in so many developers’ brains to the point of being second nature… It feels almost instinctual to design your system with them — putting your data over here in these classes, putting your logic over there in those classes…

Problem is, now that JEE 5 is becoming more common, those best practices are all wrong… ok, in most cases they won’t necessarily cause any harm (at least not of the magnitude of not following best practices about 5 years ago), but there are now better ways of doing things — we just need to learn what they are…

I’ll touch on a number of these in future posts, but I find that the area I have a lot of trouble with is getting rid of my habit to separate my data from my logic… the Session Bean/Entity Bean separation, in my opinion, is one of the more damaging patterns that was literally forced upon developers who went down the EJB path in the early days, and it’s a pattern that I’m not convinced is completely fixed yet… more on that in a later post…

Personally, my ‘toy’ projects are partially intended to get me thinking away from this — when it comes down to it, it’s all about trying to relearn those object oriented design principals, incorporate some newer techniques like Domain Driven Design, and just experiment in whatever way suits my fancy…

The first thing I do is put together my initial design in some form — either code, UML, a drawing, whatever… then I do it again, and look for specific flaws, like classes with only data and no behavior and vice-versa… of course, these scenarios aren’t always wrong, or even bad, but each time I go through this retrospective, I get a little better at identifying these issues to start with…

Do you have similar experiences? Spill the beans, let us know!