public string[] GetVendorNameList(string prefixText, int count)
{
if (count == 0)
{
count = 10;
}
int currentOperatorUserID = GetCurrentOperatorUserID();
string selectedOrderFrom = Session["SelectedOrderFrom"] != null ? Session["SelectedOrderFrom"].ToString() : null;
DataTable vendorTable = new AutoCompleteEntityMethod().GetAutoCompleteVendorTable(
prefixText, count, "VendorName", currentOperatorUserID, selectedOrderFrom);
List<string> items = new List<string>(count);
for (int i = 0; i < vendorTable.Rows.Count; i++)
{
items.Add(vendorTable.Rows[i][0].ToString());
}
return items.ToArray();
}
参考了下面两篇文章：
Web Service中保持ASP.net的状态
简介
网络程序开发者们遇到的最普遍的问题就是如何在无状态的基于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)＞ _ |
如你所料，如果你为一个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访问的权限，因此必须对之进行排序。
Web Service非Soap头(Session)身份验证方法
最近在做一个程序的Web Service，需要验证帐号才能使用Web Service提供的方法，首先想到把帐号信息附加在Soap头中传过去的方式，但在公司其他同事在使用非.net程序调用的时候发现有诸多不便。又Google了一镇子，发现一个使用Session的方式，说起来还是找“Web Service分段上传大附件”的时候看到的一个示例，难怪以前找Web Service验证的时候老找不到想要的结果。代码比较简单，主要代码如下：view plaincopy to clipboardprint?
/// <summary>
/// 授权验证，在调用Web Service的时候先调用这个方法，调用完成后就像普通网站登录一样，只要Session不超时就不需要再次调用此方法了
/// </summary>
/// <param name="appName">程序名称</param>
/// <param name="appAuthorizeCode">授权代码</param>
/// <returns></returns>
[WebMethod(EnableSession = true, MessageName = "授权验证")]
public bool CheckAuthorize(string appName, string appAuthorizeCode)
{
if (appName == "帐号名称" && appAuthorizeCode == "123456")
Session["Login"] = true;
else
Session["Login"] = false;
return (bool)Session["Login"];
}
/// <summary>
/// 添加档案，然后再调用
/// </summary>
/// <param name="model">档案实体类</param>
/// <returns></returns>
[WebMethod(EnableSession=true,MessageName="添加档案")]
public string AddArchive(Model.Archives model)
{
try
{
if (Session["Login"] != null && Session["Login"].Equals(true)) //这里就是判断Session值，即有没有通过验证。每个方法前都需要判断下
{
//以下代码为示例代码，可以根据需要放置自己的代码了
BLL.Archives bll = new BLL.Archives(); //档案操作类的实例化
if (bll.AddArchive(model)) //添加档案
return "档案添加成功";
else
return "档案添加失败";
}
else
return "未通过验证";
}
catch (Exception err)
{
return err.Message;
}
}
/// <summary>
/// 授权验证，在调用Web Service的时候先调用这个方法，调用完成后就像普通网站登录一样，只要Session不超时就不需要再次调用此方法了
/// </summary>
/// <param name="appName">程序名称</param>
/// <param name="appAuthorizeCode">授权代码</param>
/// <returns></returns>
[WebMethod(EnableSession = true, MessageName = "授权验证")]
public bool CheckAuthorize(string appName, string appAuthorizeCode)
{
if (appName == "帐号名称" && appAuthorizeCode == "123456")
Session["Login"] = true;
else
Session["Login"] = false;
return (bool)Session["Login"];
}
/// <summary>
/// 添加档案，然后再调用
/// </summary>
/// <param name="model">档案实体类</param>
/// <returns></returns>
[WebMethod(EnableSession=true,MessageName="添加档案")]
public string AddArchive(Model.Archives model)
{
try
{
if (Session["Login"] != null && Session["Login"].Equals(true)) //这里就是判断Session值，
即有没有通过验证。每个方法前都需要判断下
{
//以下代码为示例代码，可以根据需要放置自己的代码了
BLL.Archives bll = new BLL.Archives(); //档案操作类的实例化
if (bll.AddArchive(model)) //添加档案
return "档案添加成功";
else
return "档案添加失败";
}
else
return "未通过验证";
}
catch (Exception err)
{
return err.Message;
}
} 可以看到使用Session的方式来验证主要还是在于“EnableSession = true”这个属性。