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?

      <<EAR-FILE-BASE-NAME/EJB-CLASS-NAME/local>>

      e.g.,

      <<EJB3Trail/StatelessCalculator/local>>

      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?