Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Stateful vs. stateless Web services revisted

In a previous response you indicated that Web services will remain stateless in the short term because there is no mechanism similar to cookies or URL encoding for a client to pass session info to the server on subsequent calls. This seems to ignore an obvious implementation of passing the session or state information back and forth between the client and server within the SOAP XML. This has been the common implementation of stateful workflow using XML over http for a number of years. This is also how orchestration across multiple Web services will occur, the state and session info required will be transferred as parameters in the XML. Since the Web service wants to encapsulate its data and smarts, this is the easiest way to guide a multi-step service through its process. Why do you recommend against this practice?

You raise a good point. I do not recommend against this practice, and orchestration across multiple Web services will certainly need to use this type of mechanism; however, I do want to point out that the standards, as they exist today, do not support this intrinsically. For example, passing session state information back and forth requires a tighter coupling between services than is specified in the SOAP specification. I agree that orchestration across multiple Web services will need to use this type of mechanism, but, to use a Web service in a dynamic fashion restricts functionality to underlying standards.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.