EnableSession going bye-bye in ASP.NET 2.0?

Discussion in 'ASP .Net Web Services' started by MikeM, Mar 30, 2005.

  1. MikeM

    MikeM Guest

    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
     
    MikeM, Mar 30, 2005
    #1
    1. Advertising

  2. MikeM

    Brock Allen Guest

    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
     
    Brock Allen, Mar 30, 2005
    #2
    1. Advertising

  3. MikeM

    MikeM Guest

    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
    >
    >
     
    MikeM, Mar 31, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jonathan Trevor
    Replies:
    6
    Views:
    3,592
    sahar
    Nov 5, 2010
  2. Shawn Ferguson

    Good-bye to programmers...

    Shawn Ferguson, Nov 23, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    419
    Alvin Bruney - ASP.NET MVP
    Nov 24, 2005
  3. Daniel Albisser
    Replies:
    2
    Views:
    1,423
    Daniel Albisser
    Feb 24, 2004
  4. Jonathan Trevor
    Replies:
    1
    Views:
    296
    Sami Vaaraniemi
    Feb 12, 2004
  5. HHH

    Hello Ruby, bye PHP

    HHH, Feb 5, 2005, in forum: Ruby
    Replies:
    2
    Views:
    126
    BearItAll
    Feb 10, 2005
Loading...

Share This Page