I starting learning EJB recently. I have a simple but good question (please bear with me if it doesn't make sense).
Scnario: We need a factory to get a reference to the Remote Object (interface) because our EJB Object is a distributed object and client has no knowledge about where it is located. So, we have a Home Object that serves as a factory to provide the reference to the Remote Object. But the Home Object is also a distributed object. So, we use JNDI directory to look-up the Home Object. In order to do that, first, someone has to register our Home Object in the JNDI directory, thereby allowing the look-up.
Question: Why cant we directly register the Remote Object in the JNDI directory providing the home methods in the EJB Object? Why do we need another level of indirection?
By separating the home (lifecycle) methods and the business methods you are allowing the container to do optimizations like instance pooling etc.
Think of it this way: how are the remote stubs initialised in the first place? There are three immediate issues:
- You can't have every possible instance of an entity remote registered for use (terribly inefficient)
- SFSB remote stubs hold conversational state and cannot be looked up prior to a session (conversation)
- You would no longer have the beans encapsulated by a container, and would lose the services provided (such as instance optimisation, lifecycle management, transaction/persistence support)
The pattern that is used is therefore to register only the home stubs (in effect, factories) with the naming service. Arguably it would be possible to register SLSB remotes in the naming service, but it would still be less efficient than allowing the container to manage the bean.
The situation you describe (wanting direct access to a business object, no container) is actually the sort of thing that happens in RMI. But this is not very scaleable, and so it is extended and refined within the EJB framework.