EnableSession going bye-bye in ASP.NET 2.0?

[MikeM]

For the life of me I can't find anything online to backup what I thought I
read a few months back regarding session access from web methods.

In an ASP.NET 1.0 app we make use of web methods that have the
WebMethodAttribute EnableSession set to "true". We are revamping most all of
this application. We were going to wait for VS 2005, but end user needs
wouldn't allow the wait. Anyway, we thought it would be good to make sure we
did not code anything that would not be backward compat if/when we do move to
ASP.NET 2.0 with the release of VS 2005. I could have sworn months ago I came
across an article/architecture doc/recommended guidelines type of document
that stated you should not rely on EnableSession being available in 2005 or,
at least, it was not a good idea to use it. I don't know if it was a BETA 1
document either.

In any case, we've been going forward under the assumption EnableSession and
session state access in general would not be available. We've had to do
creative coding to get things to work the way we want now. It was just so
easy before to set a simple attribute and be done with it so I decided to
search again for that article I thought I read to see if maybe I was
mistaken. I can find no such article anymore.

So...is accessing session state data, variables we store in the Session, etc
still "safe" in the next release? By the way, these are not cross AppDomain
calls from client to web service/method we are doing. We want to avoid
postbacks on certain pages so we make use of web service Behavior files (HTC)
so some JavaScript on a specific ASPX page can invoke a function which calls
through to a web method in a service via the HTC file in the same web app to
return data to populate other screen controls without the need for a
postback. Don't know if that would make a difference, but thought I'd throw
it out there.

Thanks!
-Mike

 

[Brock Allen]

I would argue that it wasn't safe in 1.x. Using session relies upon cookies,
which replies upon HTTP. WebServices were originally meant to be protocol
agnostic. If your design replies upon cookies, then it would fail when used
over TCP, MSMQ, FTP, SMTP or any other non-HTTP protocol. It was a horrible
design flaw by Microsoft to allow that attribute in the first place.

Also, if you're going for interop (which is what web services are all about)
then this is a broken design, since WSDL doesn't make any mention of cookies.
That's an out of band agreement between the client and server to utilize
cookies, which falls outside the scope of the web services spec. Thus falls
outside of the intended goal of interoperability.

If you want operations on your web service to have coorelation, then build
it into your contract:

[WebMethod]
string PlaceOrder(...); // returns an OrderID (string, int, GUID, whatever
unquie ID)
[WebMethod]
Status GetOrderStats(string OrderID);
[WebMethod]
bool CancelOrder(string OrderID);

The coorelation has now been built into the contract via the OrderID and
1) doesn't reply upon out of band info like cookies, and 2) can work over
any protocol.

I know this is probabaly completely counter to your current design. Sorry
about that. Shame on Microsoft.

 

[MikeM]

Brock,

Thanks for the response and I agree. It is not really a big deal. We've
got ways to work around it. It was just handy to use before, but I guess
just because something is handy or easy, doesn't mean it is wise!

Thanks again.

-Mike