Woo hoo!

Can you smell that smell? That's the smell of a nice, smooth, clean sheet of ice down at your local rink... that's right, it's hockey season, baby, the best time of the year, and the Rangers are looking to make a run for the Cup (they also apparently sold out the entire season in less than an hour... as the great John Buccigross would say, "Holy Shnikies!")... My fantasy draft is tonight, and things start up next week, which means I'll have a reason to watch TV again (that is, if Time Warner still carries Versus -- I haven't checked since June... the NHL desperately needs to get back onto ESPN!)

I hope to take my son to several games of our local minor league team this year -- he's old enough now to at least sit through most of the game, and perhaps to learn some of the subtleties of the crosscheck and the one-timer (I'm holding out next year for the left wing lock)... well, he seems to think it's cool when someone gets checked into the glass, any way :)

So even if you hate hockey, sports, or whatever, at least go down to the rink to take in that smell... I swear, there's nothing like the smell of the ice!

M

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

Web Beans Sneak Preview

In case you didn't notice, Gavin King is offering a sneak preview of the Web Beans spec (JSR 299) so far in part 1, part 2, part 3 and part 4... It's been a whole day since his last post, so it appears like now is a good time to put out some thoughts... These are in no particular, but will hopefully serve to continue the conversation to make the eventual spec as useful as possible...

• Web Beans is not just about the web, as many people have already commented (including Gavin)... while I don't necessarily need it to be brought to JSE, I believe a name change is in order...
  
• If Web Beans becomes a generic Dependency Injection mechanism, then we would be left with at least three distinct DI systems in JEE -- the Web Beans DI, the @EJB/@Resource DI from JEE 5, and the Managed Bean mechanism from JSF... something will need to be done to address this (please don't say 'Unified DI', a la 'Unified EL' :) )...
• The @In annotation clearly comes from Seam, but there might be something more appropriate here -- in Seam, there is also an @Out annotation, representing 'outjection'... So far, Gavin hasn't given us a hint of whether this will be around in Web Beans, but if not, then I think @In should become something like @Inject, @Bean, @Component, etc
• The Guice influence appears to have replaced the String-based naming in Seam (i.e. -- @Name("myBean") ) with annotations (@MyBean)... while this requires a little more code, it seems to be a good call -- it should help prevent things like typo's in the Strings causing NullPointerExceptions at Runtime...
• Very flexible -- follows the JEE5 pattern of defining a default configuration with annotations, but allowing it to be overridden or changed with an XML configuration... alternately, the XML configuration could be used as a central configuration file, as in Spring...
• The various Component Types could be hugely useful for having multiple configurations for a single application, but I would like to see more ways of defining your components -- for example, I like to be able to keep my system configurations in the app server itself, so when I deploy an EAR from test to staging to production, I can simply copy an EAR that has passed QA -- if I have to change the web-beans.xml file, I can't do this (unless there is perhaps a default that you could configure in your server)
• I love the scopes, but Gavin mentions that the @ConversionScoped will be available from JSF managed beans, while request, session and application will be available from Servlets -- what about JSF makes it the only thing that is appropriate for the conversation scope? Any reason it couldn't be available to Servlets-based frameworks like Struts, etc.?
• Could we reduce some of the annotation chatter with something like @In (scope=ConversationScoped, new=true)? Hmm... actually that ends up with more chatter -- perhaps not :)
  

That's enough for now... So far all I can say is "Great work guys!"... oh, and keep the previews coming!

M

Did Guice beat Sprint to the punch?

There's been a lot of talk over the past few years that perhaps Interface 21 should push to formally make the Spring Framework a part of the JEE specs -- it seemed like it might be possible with Rod Johnson officially declaring his support for JEE 6... well it looks like "Crazy" Bob Lee and the team behind Guice may have found a back door to get themselves into the party first -- according to a new series of articles about the upcoming Web Beans, the new spec is actually influenced by a combination of Seam and Guice, rather than just Seam as previous reports had speculated...

This is not to say that Guice and Spring cover the same ground -- Guice is strictly a product that supports dependency injection, while Spring does that and much more, but I find these articles interesting in that Google has apparently taken the JBoss approach to supporting the JCP -- that is, create an independent product to fill a whole in the JEE specs, and then use the JCP to make that product into a spec itself (take a look at the JPA for a previous example)...

I personally think it's a very smart approach -- while it will perhaps create an opening for competitors to get into the market (more applicable when considering Hibernate and Seam than with Guice, admittedly), it opens up a clear opportunity to provide the first spec-compliant implementation (thus getting early adopters), and gives them a great opportunity to build and enhance their product while the competition is catching up (keeping the early adopters :) )...

We'll see where this goes, but so far it looks like an interesting spec -- I see some potential for overlap between some other specs, but that may not be a bad thing...

M