webservice 保留状态
简介 有许多聪明的办法可以解决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中使用。
很容易在ASP.net中使用Session来保持状态信息,HttpSessionState类为你封装了存储Session状态的细节问题。绝大多数的客户端已经能够明白他们必须返回服务器设置的cookie,而且HttpSessionState类也支持在SOAP通信中常用的底层传输。(问题)因此,很明显,使用ASP.net的Session机制会是满足状态控制要求的明智的选择。 使服务器支持Session [VB.net] _
假设通过设置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访问的权限,因此必须对之进行排序。 客户端的问题 所有工作都依赖于浏览器 然而,大多数的Web Service请求不是来自浏览器,而是来自应用程序中的Web引用。我们如何使用.net框架的“添加Web引用”的特性呢?让我们来看一看。 添加Web引用的问题 下一步,我创建了一个简单的WinForm应用程序,并且将上述的Web Service添加到Web引用中。下面就是调用我的Web Service的代码: ' 这里并没有与Session打交道 当我第一次调用Web Service时,一切正常,Web方法返回1,这就是那个Session变量的应有的初始值。现在我点击Button1来再次调用这个Web方法,我希望看到的返回值是2。可惜的是,无论我点击多少次Button1,返回值一直都是1。 你也许会怀疑原因就是我每次都创建了一个新的proxy类的实例去调用Web方法,因此每次我点击按钮,都会丢失上一次调用时的cookie。不幸的是,即使你将proxy类的初始化代码移到窗体的构造函数中,然后对每次Web方法调用使用同一个proxy类的实例,你还是不可能看到返回值有增加的迹象。
' 使用了ASP.NET的session Private Sub Button1_Click(ByVal sender As System.Object,_ 现在代码工作正常了!每点击一次Button1,我都可以看到返回值增加1。注意到我并不是在函数中声明变量Cookies的,它是窗体类的一个私有成员,因为如果希望每次都返回同一个会话ID给服务器的话,就必须在每次请求中使用CookieContainer类的同一个实例。这就解释了为什么SoapHttpClientProtocol类默认不自动地设置的cookie容器。正应为此,你可以在多个SoapHttpClientProtocol类的实例中共享一个cookie容器,而不是为其每个实例自动地创建一个新的cookie容器。 无cookie的Session 为了研究无cookie的session,我决定使用上面已经使用过的代码,看看它能否在session状态被设置为cookieless的服务器环境中能否工作正常。我也不想费心去删除cookie容器的相关代码,因为我希望得到能在两种session状态下都正常工作的代码。作为一个天生的乐观主义者,我一个字也不改就直接运行它。令人失望的事发生了——不过也不是完全没有想到,我不得不面对这个异常: An unhandled exception of type 'System.Net.WebException' occurred in system.web.services.dll Additional information: The request failed with the error message: Object moved to here.发生了什么呢?原来HTTP请求收到的不是“200 OK”响应。如果你熟悉HTTP协议,你或许可以从响应中的HTML代码中发现这是一个“302 Found”响应,这意味着该请求被重定向到超链接中指定的地址。返回HTML代码是很明智的,这样如果一个浏览器因为某些原因不支持重定向的话,它可以把代码显示出来,或者在重定向过程中显示这些代码直到重定向完成。注意到超链接中包含了一个有趣的字符串“(l2z3psnhh2cf1oahmai44p21)”,显然,我们可以推断这就是ASP.net的会话ID,它被嵌入了我们要重定向到的位置的URL中。在客户端代理中,我们需要做的仅仅是重新发送请求到这个新的URL。 无须再在Win32 WinInet API编程中跋涉,我们可以直接找到proxy类的一个属性允许自动重定向。用外行人的说法,就是如果我们接收到一个“302 Found”响应,就直接将请求重新发送到相应中HTTP位置头所指示的URL。当Visual Studio.net的智能提示显示proxy类的AllowAutoRedirect属性时,我感到这东西真是机灵得可爱。我马上就在代码中加上如下一行: proxy.AllowAutoRedirect = True 我认为这仍然比创建一个CookieContainer类并关联到proxy类要容易得多,于是我又一次运行程序。很不幸,我遭遇了如下异常(为了简洁起见有所删节): An unhandled exception of type 'System.InvalidOperationException' occurred Additional information: Client found response content type of 'text/html; charset=utf-8', The request failed with the error message: … 如果你看到错误消息的内容,你会发现你所看到的HTML页面跟你浏览.ASMX文件的页面一样。问题是,为什么当我传送XML(以SOAP封装了的形式)到Web Service服务器时它返回的却是HTML代码?结果证实,你并没有在SOAP封装中发送HTTP POST请求,而仅仅发送了一个简单的没有内容的HTTP GET请求,因此你的Web Service服务端理所当然地假设这个请求来自浏览器,于是它返回普通的HTML响应。为什么会这样呢? 如果你了解HTTP协议,你会发现一个HTTP客户端在收到“302 Found”响应时发送HTTP GET请求到响应中指定的地址是合情合理的,即使初始请求是HTTP POST。这种方式下浏览器工作得很好,因为开始几乎所有的请求都是HTTP GET类型的,只有当你试图传递数据到一个URL时,才会出现上述失败的结果。 理由是在传送的数据中可能包含潜在的敏感数据,因此你需要确认是否用户真的想向新的资源传送数据。显然如果你转向基于重定向设置的新地址,你就没能确认用户是否真的允许将他们的数据发送到新的地址。因此数据并没有被发送,而代之以简单的HTTP GET请求。 我对代码做了如下修改,捕获“302 Found”异常,提示用户同意重定向他们的请求,然后再次在新的位置调用我的Web方法。 ' 同时使用基于Cookie和Cookie的Session Private Sub Button1_Click(ByVal sender As System.Object,_ 现在ASP.net的Session工作正常了。在你的应用程序中,你可以根据情况自行决定是否提示用户重定向HTTP POST请求。举一个例子,如果你正在调用一个Web Service,你也许就不希望出现任何可见的对话框。 这样看来,要使ASP.net的Session完全正常地工作还真不是很容易。但是,应该意识到上面的代码所展示的原理在其他情况下一样的有用。例如,任何平台上的任何Web Service,只要它使用HTTP cookie,都需要一个cookie容器,类似地,也许有很多其他的原因导致当你向一个Web Service服务器发送请求时收到“302 Found”响应。在一个复杂的应用程序中调用Web Service时,可能有许多特殊的情形需要你去处理,cookie和重定向的问题就是两种这样的情形,你应该将之作为你的Web Service调用代码中最基本的部分。 结 论 在你调用Web方法的过程中,ASP.net对状态保持是非常有用的,你必须意识到,当你使用手边的浏览器界面测试你的Web Service时,你并没有面对客户端程序必须处理的问题。幸运的是,这些问题并不是很难解决。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |