如果你不多加小心，非常相似的情况会发生在web 应用程序上。所以，开发人员需要特别留意可 伸缩性和容错问题，在设计应用程序时应该能够适应未来的发展。维护用户状态是一个应用程序可伸缩性和容错的组成部分，你在站点设计阶段所做的决定对于将来站点的成功至关重要。
不对某些类型的状态进行维护，一个web 应用程序是不能存在的。比如，一个在线购物应用程序必须 要记住用户累积的定单，当用户在站点中一页一页地前进时，必须要往他们的购物筐中添加项目。 HTTP，客户机与所有web应用程序运行的服务器之间的连接，是一种无状态的协议。用户所请求的 每一页都是被独立地处理的。所以web应用程序必须要有一些东西、一些地方来记住用户的信息。
从用户到达某一页面的时刻开始，到他离开这一页面的时候，在他的活动过程中，活动服务器页 都使用允许用户与web站点之间进行交互作用的Session对象（或者等“租用时间到”后自动放弃 Session）。你只需要赋值：
Session( "numItems" ) = 3
Response.Write Session("numItems")
我相信，Session对象从某些方面说是傻瓜型的，因为它允许各种臃肿的编程－－－开发人员什么时 候想创建变量都可以，而且没有数据类型的限制。这样一来就很难发现Bug，而且如果有许多人一起做 一个项目的话就更糟糕了。一方面是协助和支持了臃肿编程法，另一方面Session对象还有一个 问题--可伸缩性和容错问题。
通常，测量一个web 应用程序的方法是用使用一系列的robin DNS在多个web 服务器上维护应用程序， 或使用一个负载平衡路由器来分配从客户端到其中一个web 服务器的请求。但是，一旦用户用web服务器 开始了一个ASP Session ，以后的所有请求就都要回到这个web 服务器，这就是说，如果这个服务器 关机了，用户就丢失了他们的session，如果服务器超载了，性能问题就出现了。有一个解决的办法： 不要使用Session 对象。
还有其它方法维护用户状态。你可以用隐含结构或表单将它们存储在客户端，但是我想，这样你就需要 一个安全的HTTP或者是冒将用户信息暴露给外界的风险。毕竟你是在客户端和服务器之间移动着多于 必要的数据。
你可以把Session 数据从应用程序本身转移开，从不同的服务器驱动它。就象数据库负责保持数据一样， 你需要另一种类型的服务器来管理动态数据。你可以有许多个从动态数据服务器驱动的web 服务器和 一个用在容错方面的动态数据服务器的复制品。或许，这个奇妙的动态数据服务器可以在站点服务器 上用Membership 服务器和一个ActiveX User Object (AUO)来执行。有关AUO的介绍可以参考 Active User Objects & The Membership Directory。
在你将AUO用于Session 数据之前，你必须已经具有一个配置了AUO的Membership服务器，并且分配给了一个 web 站点。这些准备好之后，还需要对Membership 目录和AUO做进一步的配置。
配置AUO
将AUO用于Session 状态的最困难的部分是配置它--并不是真的困难，而是在开始使用它之前要做一点 额外的工作。通过创建一个类和属性来定义状态信息看起来是什么样子，需要为类的例示设置存储的 地方。步骤是：
定义你所想要的Session 状态的属性。
为session 状态数据创建或选择一个类。
为动态数据创建一个容器。
配置一个第二AUO供应器。
在面向对象的领域内将一个属性看成是一个类的成员是有意义的。你必须将一个数据类型与每个属性 联系起来，比如说，维护购物筐中包含的项目个数的购物筐类作为numeric 属性。用站点服务器的 MMC把所有的属性增加到Membership 服务器的计划中。
定义了所有属性之后，就要把它们与一个类联系起来--一个类的例示作为一个对象--每个对象可以有 它自己的属性值。如果你已经有了一个用来代表Session 状态的类，就可以向它增加属性。否则你就 需要用Membership 目录管理器来创建一个新的类来代表Session 状态。在我们的例子中将使用一个 名为SessionStateClass的类。
现在你需要创建一个第二AUO供应器，其中包含主AUO供应器的辅助数据。它可以是一个ODBC兼容数据库、 其它目录服务或者Membership 目录中的另一个容器。在这个例子中，辅助数据是Session 状态信息， 存储在membership 目录中的一个容器内。
所以，在membership 根目录下创建容纳动态session 信息的容器并且命名它为ou=SessionStateData。 第二AUO供应器使用SessionStateData 容器来存储数据。用MMC创建一个有SessionState的第二AUO供 应器。它应该具有以下属性：
ADS path: computername:LDAPport/o=yourDirectory/ou=SessionStateData
Schema path: computername:LDAPport/o=yourDirectory/ou=Admin/cn=Schema/cn=SessionStateClass
现在你已经可以用AUO来存储session 信息了。虽然这看起来有点复杂，但是你所做的就是创建和例示 一个存在于Membership 目录范围内的对象：定义一个类，它具有代表用户session 状态的属性（或 成分）。每个用户都会得到这个类的一个例示（或对象）。所以现在我们让AUO开始工作。
设置AUO session 状态
现在第二AUO供应器已经准备好存储动态数据，现在需要设置一个属性的一个值。首先给请求web 页面 的用户约定一个对象：
Set objUser = Server.CreateObject("Membership.UserObjects")
仅仅通过引用你就可以存取任何静态属性。所以，要显示公共名称你要这样做：
Response.Write "Your login: " + objUser.cn
要设置动态信息，必须确保对象实际存在。因为它是个动态对象，所以你不能自动假设它存在。
If Not IsArray(objUser("SessionState").objectClass) Then
objUser("SessionState").objectClass =
Array("SessionState", "dynamicObject")
End If
然后设置一个存在时间值。这个时间过去后，对象就会终止并消失。在设置AUO Session 对象的任何 其它属性之前必须调用SetInfo。
objUser("SessionState").entryTTL = 900 '' specified in seconds
objUser("SessionState").SetInfo
最后，你可以设置值了。这里我设置一个定义为numItems的属性。注意这个属性必须存在于计划中， 并且所赋的值必须符合计划中的数据类型。
objUser( "SessionState" ).numItems = 3
objUser( "SessionState" ).SetInfo
你可以试着用一个不存在的属性，或者赋一个错误类型的值，看看你所得到的错误信息。
访问AUO Session 状态
我把最简单的例子留到了最后。访问属性的值与访问任何第二AUO供应器信息是一样的。指定用户对 象、第二AUO供应器名、属性名。
Response.Write objUser("SessionState").numItems
离开你的书桌，等待对象终止的时间到，然后再回来刷新页面以证实对象确实是动态的。如果对象 已经终止了，就不能显示任何东西了。
Session 和AUO 对象之间的区别
你可能已经注意到在使用AUO属性之前既要定义也要复制它们，我认为这就是相对于Session 对象的 最大优越之处。它强迫各个开发人员事先进行更多的设计，为多个人员共同开发的项目创建一个变量 声明的集中区域，这比让Session 变量分散在ASP文件各处要实用得多。
还有许多数据处理的可能性。可以使用ADSI 来访问存储Session 状态的组，然后在成组的用户及他们 的属性上进行各种显示处理，如哪些人在购买、他们取消了什么、一天的什么时间他们买什么东西等。
结论
所以不要成为你的成功的牺牲品--构造你的ASP应用程序，使它具有伸缩性和容错能力。伸缩性和容错 能力的关键一方面是维护用户session 状态信息的策略。如果你正在使用站点服务器，那么ActiveX 用户对象就是维护用户状态信息的很好的方式
