Web Development
by geert pante
IMHO, session variables are not appropriate in an environment where Web Services are typically used.
Their only purpose is to maintain an illusion of a serie of correlated messages in a conversation. However, since sessions are volatile, and usually kept in memory at one server, they introduce state at the server side, and create an often underestimated level of complexity at the server.
You can have sessions stored in a database, off course, but in that case, you could as well manage the conversation actively, and create persistent objects instead, sending correlation id's in your conversation body's, instead of using HTTP-specific cookies.
If your Web services relies on session time-out, then there is probably something wrong in your web service design.
In the example, a session variable is used to determine the fact that a user has logged in. Why can't you just include authentication information in the 'real' Web service request, or use Secure Soap signatures.
greetings, greyfairer.
In the opening paragraph I state that the use of session variables is "in general" not good practice.
However being an open-minded architect I believe in upholding both sides of the argument. If all you mention were true and session variables were in fact a complete nightmare and uterly useless, I don't believe Microsoft would have including the feature to begin with.
Every development experience is unique, and keep in mind that although you may not have come across a scenario where usingsession state is warranted, there are surely many developers who have.
This discussion is closed to new replies.
Sort by Trending