Stateful vs. stateless Web services?

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?

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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.