use SOAP header for asp.net session state

[InvalidLastName]

As far as I known, ASP.NET relies on HTTPcookie for session state management (I am excluding the cookie-less option here because I don't think it is compatible with Web service)


I just want to verify that there is no build-in session management, which supports using SOAP headers for session management, provides by ASP.NET 2.0. Is there any workaround ? Some workarounds mentioned to use ASP.NET cache for session management. However, the cache approach won't work in the web-farm environment. Can someone provide any reference or best practices about using SOAP header to maintain session state in ASP.NET 2.0 ?


Thanks

 

[John Saunders]

I'd say that the preferred best practice is to write web services in a Service-Oriented, stateless manner.

If you need to maintain state across method calls, then you could certainly use a SOAP header to maintain a session state key. I haven't gotten into the 2.0 features, but I seem to remember something about an extensible session state provider in ASP.NET 2.0.

John

As far as I known, ASP.NET relies on HTTPcookie for session state management (I am excluding the cookie-less option here because I don't think it is compatible with Web service)


I just want to verify that there is no build-in session management, which supports using SOAP headers for session management, provides by ASP.NET 2.0. Is there any workaround ? Some workarounds mentioned to use ASP.NET cache for session management. However, the cache approach won't work in the web-farm environment. Can someone provide any reference or best practices about using SOAP header to maintain session state in ASP.NET 2.0 ?


Thanks

 

[Steven Cheng[MSFT]]

Thanks for John's input.

Hi InvalidLastName,

I agree with John, actually XML webservice is designed as stateless and
connectionless. As for both application Cache or SessionState, they're
specific to the ASP.NET web application, ASP.NET include it in case both
the client and server-side use .net framework. When use SessionState, if
you use .net framework to generate the client proxy, it will use the
HttpWebRequest class to send/receive webservice request/response SOAP
message. And for HttpWebRequest class, it has a Cookie property which is of
CookieContainer type. This is how .net webservice client proxy keep the
cookie returned from server-side ASP.NET webservice(if we've used).

So the problem here is whether your webservice will be consumed by any
other non-dotnet platform? If so, using cookie is not a good idea, and so
far I haven't found any standard specification on use SOAP Header to
maintain cookie since it is not included in the webservice standard.

BTW, would you provide some further details on your scenario and why you
would use cookie (to keep any state) in your webservice client & server? I
think we may have a look for some other alternative approachs.

Please feel free to post here if you have any questions or other concerns.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[InvalidLastName]

Thank for all your responses.

Some background here. We are creating web services for our customer to get data in and out of the system. The web services can be consumed by any type of applications.

I totally agree the web services should stateless, and currently we actually don't need to maintain state between the calls.

We are planning to create a custom authentication ticket, which will be passed within SOAP header. I am not looking for a solution to use SOAP header to maintain "cookie", I am just want to make sure ASP.NET doesn't support SOAP header based session management, and we won't encounter any compatibility issue in the future if we do need to maintain session state for some odd reasons.

Interesting enough, I believe SQL server 2005 web services is actually using SOAP header to maintain session state. The SQL Server Reporting Services also saves execution ID, which is equivalent to session id, in SOAP header to maintain session state. That's why I really want to make sure SOAP header is not a valid session state management option is ASP.NET 2.0

Other alternative approaches, which provide minimum state management, are very welcome.


Thanks

 

[John Saunders]

Thank for all your responses.

Some background here. We are creating web services for our customer to get data in and out of the system. The web services can be consumed by any type of applications.

I totally agree the web services should stateless, and currently we actually don't need to maintain state between the calls.

We are planning to create a custom authentication ticket, which will be passed within SOAP header. I am not looking for a solution to use SOAP header to maintain "cookie", I am just want to make sure ASP.NET doesn't support SOAP header based session management, and we won't encounter any compatibility issue in the future if we do need to maintain session state for some odd reasons.

Interesting enough, I believe SQL server 2005 web services is actually using SOAP header to maintain session state. The SQL Server Reporting Services also saves execution ID, which is equivalent to session id, in SOAP header to maintain session state. That's why I really want to make sure SOAP header is not a valid session state management option is ASP.NET 2.0

Other alternative approaches, which provide minimum state management, are very welcome.

The best approach, as has been stated, is "don't do that". Pretend that you've never heard of session state and develop your service that way.

John

 

[Steven Cheng[MSFT]]

Hello InvalidLastName,

Yes,SQL Server reporting service use an executionID to maintain a session
to a certain report/snapshot at server-side, and this is actually depend on
the server-side's executionID manager( like the SessionState manager in
ASP.NET).

For your scenario, I think you can go through the custom SOAPheader
approach for session management, however, you may need to implement your
own server-side ID manager (such as how to create a new sessionID and
determine the lifecycle and expiration of a certain ID). For SoapHeader,
we only use it to store and pass the sessionID from client to server. Here
are some reference about how to use custom soapheader in ASP.NET webservice
and client and sample article of passing authentiate info through soap
header:

#Using SOAP Headers
http://msdn2.microsoft.com/en-us/library/77hkfhh8.aspx

#Soap Headers Authentication in Web Services
http://aspalliance.com/805_Soap_Headers_Authentication_in_Web_Services

For your scenario, you can let the client always call a authenticate
webmethod first which will retrieve a ticket ID from your server-side
authentication manager, then, in sequential requests, client proxy will set
the ID in the soapheader .... How do you think so?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi InvalidLastName,

Have you got any further ideas or progress on this issue? If there is
anything else you wonder, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.