EJB design: Why stateless-sessionbeans need HOME?
In an application, I have a stateless sessionbean as the facade of my subsystem. And I only need to let other sub-systems to call methods in the remote interface. In this case, the home interface contains only a "create" method with no parameter.
- Posted by: Bin Sun
- Posted on: September 25 2001 03:43 EDT
So, why should we get the stateless sessionbean through creating method in its home object instead of retrieving a remote object directly from JNDI?
If using JNDI can we get the bean object itself, we can easily use java class reflection to call its method without having to reference to the client interface classes.(In WLS 6, reflection will not provide a way to use the bean without client-side interfaces.
Further more, in that every home interface for a stateless sessionbean is similar to this one containing only a simple create method, why not obviate it and just get remote interface by looking up JNDI?
I can't speak for the authors of the spec, but here are two reasons I can think of:
1. Keep a standard convention that all EJBs have a home interface which controls life-cycle.
2. Keep statefulness of a session bean an implementation detail. A client doesn't have to know whether or not a session bean is statful. All it needs to know is that it gets the work done.
I don't get your point about how eliminating the home interface would help use reflection. You would still get just a stub from JNDI, and in the case of IIOP this will still not be the actual "runtime type" stub. You would still need to narrow it down, so exactly what did you gain here?