Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Web Services > EnableSession going bye-bye in ASP.NET 2.0?

Reply
Thread Tools

EnableSession going bye-bye in ASP.NET 2.0?

 
 
MikeM
Guest
Posts: n/a
 
      03-30-2005
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

 
Reply With Quote
 
 
 
 
Brock Allen
Guest
Posts: n/a
 
      03-30-2005
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.

-Brock
DevelopMentor
http://staff.develop.com/ballen



> 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




 
Reply With Quote
 
 
 
 
MikeM
Guest
Posts: n/a
 
      03-31-2005
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

"Brock Allen" wrote:

> 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.
>
> -Brock
> DevelopMentor
> http://staff.develop.com/ballen
>
>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Blocking problem/bug with enableSession=true and asynchronous web service calls? Jonathan Trevor ASP .Net 6 11-05-2010 04:18 PM
Firefighters at the site of WTC7 "Move away the building is going to blow up, get back the building is going to blow up." Midex Python 24 05-07-2007 04:23 AM
Blocking problem/bug with enableSession=true and asynchronous web service calls? Jonathan Trevor ASP .Net Web Services 1 02-12-2004 12:37 PM
floppy drive just keeps on going and going and ... Weylon Bulloch Computer Support 1 09-07-2003 07:17 AM
VPN going up but traffic going one way PLP Cisco 1 07-11-2003 08:28 AM



Advertisments