Keep the asp.net state in the Web service

Asp.net|web

Brief introduction

The most common problem the developers of Web programs encounter is how to maintain state information in stateless HTTP protocol based interactions. There are many clever ways to resolve stateless problems with HTTP protocols, such as repeatedly sending application packets to each request, using the HTTP authentication mechanism to map requests to specific users, using cookies to store a series of requests, and so on. The ASP.net technology provides a very effective solution to keep the state, which hides all the hard, challenging details of the job, and the user simply uses the System.Web.SessionState.HttpSessionState class. At the same time, you can use this class in the Web service method as in the Web page (. aspx) of the ASP.net program, only a little bit different.

Overview of ASP.net session objects

asp.net session state information is maintained through two mechanisms. One is to use cookies. When a client sends a request to the server side, the server sends back a response message with an additional HTTP Set-cookie header, and the value of the cookie is stored in the information as a key/value pair. In all synchronization requests to the same server, the client sends a cookie key/value pair in the HTTP cookie header. The server can then match concurrent requests to the original request. ASP.net uses a cookie that holds the session's ID to hold session state. The ID identification is used to find an instance of the corresponding HttpSessionState class for a particular user. Class HttpSessionState only provides a generic dataset where you can save any information you need.

Another mechanism used by asp.net to maintain state is the need not to use cookies. Some browsers are set by the user to prohibit the use of cookies or simply do not support cookie,asp.net provides a mechanism to solve this problem, its main principle is to redirect a request to a URL containing the asp.net status ID. When the request is accepted, the ID embedded in the URL is intercepted, and the server finds an instance of the appropriate HttpSessionState class through that ID. This approach works well in the HTTP protocol's request to use Get mode, but there is a problem in. NET's XML Web service code.

It must be noted that sometimes storing information directly in a cookie is better than storing it in a session. Avoiding sessions saves server resources, and you don't have to worry about annoying issues like locating a particular session object, the session object being removed because of a long delay in the request, or not having to be retained on the server until it expires. However, if you have some execution information that includes users you do not want to share with the service you provide, or some private data that you do not want to transmit through an unencrypted channel, or you think it is impractical to insert the data into the HTTP protocol header, Then you should use the HttpSessionState in ASP.net, which will make it easy for you to solve these problems. The HttpSessionState class returns an index key that maps a particular user to an instance of a HttpSessionState class that holds information for that user. In short, either the ASP.net httpsessionstate class or the HTTP cookie can be used in the ASP.net Web service.

Why use an HTTP based mechanism in an XML Web service to implement state retention?

There are many ways to maintain state in a SOAP request. A practical approach is to include information in the SOAP header that resembles the session ID in ASP, but the problem is that you have to: 1 still have to write the server-side code yourself, and 2 is sure that your client will be treated like HTTP Cookies, treat your SOAP header that contains the session ID and append it to each request and pass it back to you. Of course, there are many times when it is convenient to use the SOAP headers, but there are many times when you might as well use a method based on the HTTP protocol.

It is easy to use the session in ASP.net to keep state information, and the HttpSessionState class encapsulates the details of the memory session state. The vast majority of clients have been able to understand that they must return cookies to the server settings, and the HttpSessionState class also supports low-level transmissions commonly used in soap communications. Therefore, it is obvious that using the asp.net session mechanism would be a wise choice to meet state control requirements.

Enable the server to support session

In ASP.net, the state support for Web methods is turned off by default, and you must explicitly activate session support for each Web method that will use session state. The way to activate session support is to add a enablesession option to the WebMethod property of your function and set its value to true. The following code shows how to activate the session and Access session state information in the method.

[VB.net]

<webmethod (Enablesession:=true) > _
Public Function Incrementsessioncounterx () as Integer
Dim Counter as Integer
If context.session ("Counter") is nothing Then
Counter = 1
Else
Counter = context.session ("counter") + 1
End If
Context.session ("Counter") = Counter
Return counter
End Function


As you might expect, if you activate session support for a Web method, it does not mean that the session support of other Web methods is also activated. In fact, if the EnableSession option for the Web method is not explicitly set to True, then the value of the Context.session property will be null.

Assuming that the session is blocked by setting the Web.config file, the Context.session value will always be null even if you use the EnableSession option in the WebMethod attribute. The/configuration/system.web/sessionstate item in the Web.config file has a mode parameter that determines what method your ASP.net program uses to hold the session state. This parameter is set to "InProc" by default, when the HttpSessionState object is simply saved in the memory area of the asp.net process. If it is set to "off", the session support for the ASP.net program is closed.

[1] [2] [3] Next page