简介
网络程序开发者们遇到的最普遍的问题就是如何在无状态的基于HTTP协议的交互中保持状态信息。有许多聪明的办法可以解决HTTP协议的无状态问题，例如对每个请求重复发送应用程序数据包、使用HTTP认证机制来将请求映射到特定的用户、使用Cookie来存储一系列请求的状态等。在ASP.net技术中提供了一个非常有效的方案来保持状态，该方案隐藏了所有高难度的，具有挑战性的工作的细节，用户只需简单地使用System.Web.SessionState.HttpSessionState类。同时，你也可以像在ASP.NET程序的Web页面（.aspx）中那样在Web Service的方法中使用这个类，只有一点小小的不同。
ASP.net的Session对象概述
ASP.net的Session状态信息是通过两个机制保持。其一是使用Cookie。当客户端发送一个请求到服务器端时，服务器将发回一个附加HTTP Set-Cookie头的响应信息，而Cookie的值就是以键/值对的形式保存在该信息里边。在对同一服务器的所有的同步请求中，客户端在HTTP Cookie头中发送Cookie键/值对。然后服务器可以将并发的请求同初始的请求对应起来。ASP.net使用一个保存会话的ID的cookie来保持会话状态。该ID标识被用来为特定的用户找到与其对应的HttpSessionState类的实例。类HttpSessionState仅仅提供了一个通用的数据集，你可以在其中保存你需要的任何信息。
ASP.net用来保持状态的另外一种机制是无须使用Cookie。一些浏览器被用户设置为禁止使用Cookie或者干脆就不支持Cookie,ASP.net提供了一种机制来解决这个问题，它的主要原理是将一个请求重定向到一个包含ASP.net状态ID的URL。当该请求被接受到时，这个嵌在URL中的ID被截取下来，服务器通过该ID找到合适的HttpSessionState类的实例。这种方式在HTTP协议的使用GET方式的请求中工作的很好，但是在.net的XML Web Service代码中会出现问题。
必须指出的是，有些时候把信息直接存储在Cookie中要比存储在Session中更好。避免使用Session可以节省服务器资源，而且你也无须考虑一些烦人的问题，比如定位一个特定的Session对象、Session对象因为请求的长时间的延迟而被移除或者在服务器上没必要地保留直到过期。然而，如果你有一些包含你不希望与你提供的服务的使用者共享的执行信息，或者有一些你不希望通过未加密的信道传输的私有数据，或者你认为将这些数据插入HTTP协议头中是不切实际的，那么你就应该使用ASP.net中的HttpSessionState，它将使你轻松解决这些问题。HttpSessionState类返回一个索引键，用以将一个特定的用户映射到一个为该用户保存信息的HttpSessionState类的实例。总之，无论是ASP.net的HttpSessionState类还是HTTP的Cookie都可以在ASP.net Web Service中使用。
为什么要在XML Web Service中使用基于HTTP的机制来实现状态保持呢？
在SOAP请求中有许多方法来保持状态。一个切实可行的方法就是在SOAP头中包含一些像ASP中的会话ID的信息，然而问题在于你不得不：1) 仍然要自己编写服务器端代码，并且 2) 确信你的客户会像对待HTTP Cookie一样对待你的包含会话ID的SOAP头并且将它附加到每个请求中回传给你。当然有很多时候使用SOAP头的方法会很方便，但是也有很多时候还不如使用基于HTTP协议的方法。
很容易在ASP.net中使用Session来保持状态信息，HttpSessionState类为你封装了存储Session状态的细节问题。绝大多数的客户端已经能够明白他们必须返回服务器设置的cookie，而且HttpSessionState类也支持在SOAP通信中常用的底层传输。因此，很明显，使用ASP.net的Session机制会是满足状态控制要求的明智的选择。
使服务器支持Session
在ASP.net中，对Web方法的状态支持默认是关闭的，你必须为每个要使用Session状态的Web方法显式地激活Session支持。激活Session支持的方法是添加一个EnableSession选项到你的函数的WebMethod属性中，并且将其值设置为true。下面的代码演示了如何激活Session并且在方法中访问Session状态信息。
[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
如你所料，如果你为一个Web方法激活了Session支持，并不意味着其它的Web方法的Session支持也被激活。事实上，如果Web方法的EnableSession选项没有被显式地设置为true，那么Context.Session属性的值将是null。
假设通过设置web.config文件禁止session，那么即使你在WebMethod属性中使用了EnableSession选项，Context.Session的值也将一直是null。web.config文件中的/configuration/system.web/sessionState项有一个mode参数，它决定了你的ASP.net程序使用何种方法来保持Session状态。该参数默认设置为“InProc”，这时HttpSessionState对象将简单地保存在ASP.net进程的内存区。如果被设置为“Off”，那么ASP.net程序的Session支持就被关闭了。
从服务器端看来，ASP.net的session状态的有效范围仅仅是某一个给定的ASP.net应用程序，这就意味着一个HttpSessionState类的实例只能被一个特定用户向某一个虚拟目录发出的所有Session被激活的ASP.net请求所使用，也就是说，使用同一个会话ID的向其它的虚拟目录的请求将导致ASP.net不能找到对应的session对象——因为会话ID不是为该ASP.net应用程序设定的。ASP.net并不区分对ASPX和ASMX文件的请求，直到该请求需要使用Session对象，因此，理论上你可以在一个Web方法调用和一个普通的ASPX文件之间共享Session状态信息。然而，我们将看到也有些客户端的问题使这个想法变得不那么容易实现。
当设置一个HTTP cookie，你可以指定其过期时间。过期时间指定在多久的时间内，客户端应该将该cookie回传给服务器。如果一个cookie没有被设置过期时间，那么它仅仅在该进程处理请求的时间内被回传。例如，IE将一直回传cookie，除非你关闭了浏览器的特定窗口。ASP.net的用来保存会话ID的Cookie没有过期时间，因此，如果一台客户机上的多个进程向你的服务器上发送HTTP请求，它们也不会共享同一个HttpSessionState对象，甚至两个进程同时运行也是这样。
如果你要处理来自同一个进程的并发的Web Service调用，那么这些请求将在服务器上被排序，从而使得在某一时刻只有一个请求被执行。ASP.net的Web Service不像普通.ASPX页面，支持允许多请求的并发进程的对HttpSessionState对象的只读访问，所有Session被激活的Web方法调用都具有read/write访问的权限，因此必须对之进行排序。
客户端的问题
在你的WebService中成功的使用HttpSessionState的功能事实上依赖于对用户的一些假设。首先，也是最重要的一点，如果你是用默认的HTTP Cookie模式来保存Session状态，你的客户端就必须支持cookie；如果你是用无cookie的机制来支持Session，那么你的客户端必须能够并且愿意重定向到一个新的URL，该URL由原来的URL中插入会话ID而得到。结果将表明，这并不是一个无足轻重的问题，它关系到你能否成功地部署你的程序。
所有工作都依赖于浏览器
如果你是用Microsoft Visual Studio.net来开发ASP.net Web Service应用程序，那么默认的调试方法就是打开IE访问你的.asmx文件。通常，系统将提供一个可以调用你的Web方法的友好的界面，这是一个调试你的Web Service代码的很好的途径。如果你已经将Web方法的EnableSession选项设置为true，它被非常漂亮地支持，甚至如果你打开了无cookie的Session支持，客户端浏览器也可以完美地完成这项工作，你的Session对象将如你所愿地工作。
然而，大多数的Web Service请求不是来自浏览器，而是来自应用程序中的Web引用。我们如何使用.net框架的“添加Web引用”的特性呢？让我们来看一看。
添加Web引用的问题
我将使用我们前面看到的代码段来创建一个简单的XML Web Service。记起来了吧？这个Web方法被称作IncrementSessionCounter，它仅仅是简单地把一个整数存储在HttpSessionState对象中，然后每次调用则将它加1，并且返回当前值。从客户端浏览器我们可以看到这个数字的值随着调用次数的增加而增加。
下一步，我创建了一个简单的WinForm应用程序，并且将上述的Web Service添加到Web引用中。下面就是调用我的Web Service的代码：
' 这里并没有与Session打交道
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Dim proxy As New localhost.Service1()
Dim ret As Integer
ret = proxy.IncrementSessionCounter()
Label1.Text = "Result: " & CStr(ret)
End Sub
当我第一次调用Web Service时，一切正常，Web方法返回1，这就是那个Session变量的应有的初始值。现在我点击Button1来再次调用这个Web方法，我希望看到的返回值是2。可惜的是，无论我点击多少次Button1，返回值一直都是1。
你也许会怀疑原因就是我每次都创建了一个新的proxy类的实例去调用Web方法，因此每次我点击按钮，都会丢失上一次调用时的cookie。不幸的是，即使你将proxy类的初始化代码移到窗体的构造函数中，然后对每次Web方法调用使用同一个proxy类的实例，你还是不可能看到返回值有增加的迹象。
问题在于cookie。Web Service代码并未从调用请求中发现有效的会话ID，因此它每次被调用都创建一个全新的HttpSessionState对象，并且返回它的初始值1。因为作为客户端的proxy类是从类System.Web.Service.Protocols.SoapHttpClientProtocol继承的，它不包含System.Net.CookieContainer类的实例，因此，没有地方来存放返回的cookie。为了解决这个问题，我对代码做了如下一些修改：
' 使用了ASP.NET的session
' 但是并不是无Cookie的session.
Private Cookies As System.Net.CookieContainer
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Dim proxy As New localhost.Service1()
Dim ret As Integer
' 为proxy类设置cookie容器
If Cookies Is Nothing Then
Cookies = New System.Net.CookieContainer()
End If
proxy.CookieContainer = Cookies
ret = proxy.IncrementSessionCounter()
Label1.Text = "Result: " & CStr(ret)
End Sub
现在代码工作正常了！每点击一次Button1，我都可以看到返回值增加1。注意到我并不是在函数中声明变量Cookies的，它是窗体类的一个私有成员，因为如果希望每次都返回同一个会话ID给服务器的话，就必须在每次请求中使用CookieContainer类的同一个实例。这就解释了为什么SoapHttpClientProtocol类默认不自动地设置的cookie容器。正应为此，你可以在多个SoapHttpClientProtocol类的实例中共享一个cookie容器，而不是为其每个实例自动地创建一个新的cookie容器。
无cookie的Session
从Web Service的开发者的角度来看，你可以想到相当多的人在试图使用你的Web服务时忘记在客户端代理类中添加Cookie容器。聪明的开发者或许灵光一闪，就会发现无cookie的Session应该可以出色地解决这个问题。如果将web.config文件中sessionState元素的cookieless参数设置为“true”，你将会发现，通过浏览器界面调用Web方法时，session变量工作正常，但是如果你在Visual Studio.net中通过“添加Web引用”来调用它时，依然存在着一些问题。
为了研究无cookie的session，我决定使用上面已经使用过的代码，看看它能否在session状态被设置为cookieless的服务器环境中能否工作正常。我也不想费心去删除cookie容器的相关代码，因为我希望得到能在两种session状态下都正常工作的代码。作为一个天生的乐观主义者，我一个字也不改就直接运行它。令人失望的事发生了——不过也不是完全没有想到，我不得不面对这个异常：
An unha
