I am a beginner in Web services, so this question may be trivial. In the J2EE paradigm, much discussion has been...
devoted to stateful vs. stateless beans. When we talk about Web services, do we have a similar concern at all? My simple understanding is that a Web services just gets a request and responds. So it is stateless. Is this correct? Does it even make sense to ask for a stateful Web service?
Suppose it makes sense to ask for a Web service to maintain states, then, I suppose my client needs to remember some kind of session id. Which layer is responsible for the session id? Is it SOAP or http or something else? Any real life example of the use of stateful Web services?
SOAP-based Web services like to be considered as black boxes, hiding their implementation details from interested parties. This typically leads us to regard them as stateless animals.
In J2EE environments, Web services are often implemented using servlets that handle incoming requests from Web service clients in much the same manner that servlets handle HTTP requests; receive the request, dispatch the request to business logic components and return the response to the client. With this in mind, we can ask ourselves the question: Who saves the session's state?
Saving the state of a client's session is a vital element in a useful distributed application. State-saving techniques for HTTP-based applications currently use a lightweight cookie that is passed between the browser and server. This cookie is then used by the server as a type of index into a list of objects that contain more in-depth information about the client. The list of "state" objects is stored in a number of ways; in the HttpSession object, in a database, in a flat file, in a stateful session bean, etc. Choosing the correct method is a decision that should be made based on application constraints and needs. SOAP-based Web services that are implemented using servlets and J2EE technologies could, theoretically, use these same techniques to store state about a Web service client. However, there is no standard for passing cookies between Web services and Web service clients. This "deficiency" constrains a Web services provider to delivering data and functionality to a client without regard to state. Until this constraint is addressed in a standard way, Web services will typically remain stateless.
So, to answer your original question, "Does it even make sense to ask for a stateful Web service?" I respond, at this point, no. The argument between stateful and stateless EJBs has no relevance to this discussion. EJBs are useful components in an RMI/IIOP environment, but are of little used for fielding HTTP/SOAP requests.