How to manage a stateful webservice?

I am trying to learn about J2EE and web services (in GlassFish 3.1). This question is a bit of a follow up to this.

I have figured out how to use Stateless Session Beans and the Web Service. I am really only using the Web S开发者_开发技巧ervice (@WebService) out of convenience since I would rather not parse messages by hand. Although I would prefer something lighter than SOAP if possible. I have however run into a problem when I want to maintain a state of some sort (such as through Stateful Session Beans). I have searched this site and several others recommending me to avoid this because it can lead to difficult to find bugs and limits scalability.

Suppose I have a user who has just executed the "userLogin" method and it has succeeded. How do I then know on the server that the user has already logged in. For example, after logging in the user might call "getProfile()" through SOAP (without any arguments), and I would return the correct information for that user. I know this isn't possible by appending @WebService to my Stateful Session Bean since that's only valid with @Stateless.

I know how to store the state if I use an HttpSession (with an HttpServlet) along with Stateless Session Beans, but then I cannot use the nicely generated SOAP messages.

So my question is: how would I solve this problem of maintaining user state, or adapt the problem so that I do not require state?

WS can be stateful: use @Stateful annotation and WS-Addressing (see my old question for example)

There is nothing criminal in having a stateful server. After all, if statefulness is required, why avoid it? It is true that stateless are easier to scale and debug, but if you need to keep state (as in shopping card, for instance) -- then keep it.

Thing to consider though is the cleaning up the stateful service instance after a timeout. Use StatefulWebServiceManager instance and its setTimeout() method.

Also, state can be kept outside of WS (e.g. database) and the state (session) identifier passed as one of the parameters. Works just fine.

Using HTTP session is a pretty easy way to keep state for a stateless service, but I consider it outdated comparing to @Stateful. The rationale is that the request not necessary have to come via HTTP; @Stateful/WS-Addressing works for any channel, while HTTP session requires HTTP transport. In the real world, of course, HTTP is the prevailing one, so this argument is quite purist.

Exposing stateless bean as web service:

import javax.ejb.Remote;
import javax.jws.WebService;
import javax.jws.WebMethod; 


@WebService
/**
* This is an Enterprise Java Bean Service Endpoint Interface
*/
public interface HelloServiceInf extends java.rmi.Remote {

    /**
    * @param phrase java.lang.String
    * @return java.lang.String
    * @throws String The exception description.
    */
    @WebMethod
    java.lang.String sayHello(java.lang.String name) throws java.rmi.RemoteException;
}

Implementing Web service as a Stateless bean

import java.rmi.RemoteException;
import java.util.Properties;
import javax.ejb.Stateless;

/**
* This is a session bean class
*/
@Stateless(name="HelloServiceEJB")
public class HelloServiceBean implements HelloServiceInf {

    public String sayHello(String name) {
        return("Hello "+name +" from first EJB3.0 Web Service");
    }
}

You need to keep UserInfo (User details and profile information Object)in HttpSession, and if the there is no UserInfo in HttpSession, then you need to call the bean(Web service).