How to manage a stateful webservice?

up vote1down votefavorite

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 Service (@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? java java-ee glassfish ejb stateful-session-bean share|improve this question asked Jun 28 '11 at 2:45 Level9000 184

add comment

1 Answer

activeoldestvotes

up vote2down vote

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. share|improve this answer edited Jun 28 '11 at 3:37 answered Jun 28 '11 at 3:31 Vladimir Dyuzhev 9,68822536

another thing to consider with stateful stuff is if your system gets big enough to be clustered. You either have to have a way to transmit state between boxes or a way to garentee that requests from the same source end up on the same box. All quite doable, but it's a consideration. –  drekka Jun 28 '11 at 3:52 Thanks, but unfortunately it doesn't appear to do the job I want. It may just be my unfamiliarity with the API, but I read here ([blogs.oracle.com/sujit/entry/…) about the @Addressing annotation and found that it provides the user with access to a cached resource. Want I wanted was something that I could easily access without the user knowing that is is tracked. –  Level9000 Jun 28 '11 at 22:49  Even HTTP session requires a cookie. User will know. In case of WS user (client) will have to read and add cookie explicitely, via not less than hacks. Comparing to that @Stateful is neat. –  Vladimir Dyuzhev Jun 29 '11 at 2:33 add comment