9 Replies Latest reply on Mar 27, 2006 2:48 PM by Ezra Epstein

    Are EJB3 Stateless Session beans as boneheaded as they look?

    Ezra Epstein Newbie

      OK, now that the flame baits out of the way.... Following the EJB3 trail I read:

      <<Since the container-generated stub object routes the call from the client to the service object, the client does not need to know the actual implementation class of the bean inside the container.>>

      OK, sounds reasonable and might even be 1/2 as useful as old-fashioned Objective-C / SmallTalk dynamic method invocation, but the kicker is the example.

      You look up the stateless session bean via JNDI. And what do you pass to JNDI?




      Now lets see, StatelessCalculator is the name of a CLASS that implements the Calculator interface. Is it just me or does this famous "decoupling" seem entirely missing. "Look ma, I can finally lookup a class via a String, see it's not C++, it really is a dynamic language!" Aww shucks. Thanks reflection. It really ain't even 50% of Obj-C it's like 15% of it. What's the point? What's the big deal? And where's even the modest promise of looking up the bean by its interface? this clearly shows looking it up by a part of its class name!

      OK, now that there's more fuel, in some honesty: what am I missing? Is this just a bad example or are the folks behind the specs still chasing their tails as they were with EJB 1 and EJB 2?