Hi people ,
I am toying with the idea of having a Java client calling a stateless SessionBean method. Within that method , the bean will create a stateful SessionBean and return the remote reference (not the Home reference) to the client. The client then request the stateless Session Bean to remove() and further interacts with the created stateful SessionBean. I'm wondering if this is a good idea.
The reason for this is I am trying to implement a client login framework. The Java client creates a stateless SessionBean (any one has the permission to create this object) , and then calls a method on the session bean that performs the authentication and authorization. When the authentication succeeds , the method will create a stateful SessionBean (that acts something like a Facade , and only creatable by the login stateless SessionBean) and return this stateful SessionBean's reference to the client. From there onwards , any interaction between the client and the server will be via this stateful SessionBean.
I have tested this method on Weblogic 5.1 and JBoss 2.2 and it seems to work without a glitch. I'm not sure if this violates EJB 1.1 specs or if there are any hidden loopholes with this method. I've looked into EJB specs and it does not seem to mention anything regarding this behaviour.
Thanks for reading this.
There is nothing to "violated" by designing your system that way...However, you might want to consider "hiding" direct session bean access from your clients. For example, consider having a (Controller pattern) ControllerServlet object that handles all incoming web requests and calls the appropriate session beans, etc., then uses a (Dispatcher pattern) Dispatcher to handle the correct "view" to be returned to the client (wireless, HTML, etc.). The ControllerServlet could store some (Value Object pattern) UserVO and PermissionsVO associated with the user in the HttpSession for use in the appropriate "view" for handling client interaction, navigation options/permissions, etc.
Just something to think about...
Thanks for the feedback. One of the client requirement is it needs to be a Java application and not a servlet/JSP. Hence I was thinking of employing the stateful SessionBean as the FrontController/Facade object.
I think passing back the Handle is a better idea (by calling getHandle() method from the EJBObject), because it the API it stated that:
"A handle is an abstraction of a
network reference to an EJB object. A handle is intended to be used as a "robust" persistent
reference to an EJB object."
Using handle is great. However , when invoking a method via the hanlde , the EJB gets look up again before the method gets executed. This is a problem when I want to prevent the EJB from being look up by certain client with restricted role. This is the reason I need a front end EJB that runs as a system role which authenticates clients before creating the EJB on behalf of the client and pass the reference to the client.