【IT168技术文档】

  本文的目的在于提供一种可行的解决方案通过Web Service技术来整合和管理现有的Asp程序到Asp.Net。 此应用解决

  方案尽可能从实际出发以迭代更新方式的策略把Asp Web服务器内存中的当前Session更新到Asp.Net。

  背景:

  现有公司的产品OA是采用asp早先的技术开发，需要与目前最新的asp.net产品进行数据交互的应用。现有的asp应用程序

往往采用“ASP sessions”，这是一种经典的asp内置模式，即允许数据临时暂存在web服务器内存中，其最大的限制因素就

是asp的session状态是依赖具体的服务器。而另一个更宽范围的解决方案就是很多web服务器都可能别用于根据请求而指向的

任何网络服务器。实际上就是所有的web服务器都像在一个农场中，因而任何在内存中的session状态将不会自动跟随请求。每

个asp服务器提供自己的session状态，除非用户很凑巧的返回统一服务器，造成系统session丢失。

  通过使用服务器管理产品（如bigip）来强制用户会同意服务器内的web农场来解决内存中asp seesion因服务器关系而造

成的问题。为了达到这个目的，采用一个cookie在客户端工作，在服务器端来使用，让用户直接可以回到同一个服务器上的

每个reqeust。这样可以限制扩展性，提高可维护性，避免服务器故障的风险（例如：session丢失服务器 失败）。

  微软Asp.net技术的出现终于解决了这个问题，可以让我们来存储session信息到web server和database或者其他域

server。不错，问题解决了，我们还有必要用asp代码吗？全部扔掉？如果这样做的话就会需要很大代价去重新使用.net来

重写asp。看来还是不可行。另一种比较好的解决方案就是用迭代方法来部分移植代码到新的模型胜过重写asp代码，在这

个过程中如果旧的ASP代码和新的asp.net代码可以有一个共同的session状态而保持正常的工作，那么在整个生命周期中

将会有益于你更好的规避风险.以下提供了几个解决方案从此略上来解决当采用经典的asp sesssion因服务器关系而造成的

问题。

  1、用户自定义组或者使用Asp/ADO脚本去实现直接读写用户session数据到数据库；

  2、用户自定义组件去直接访问asp.net seesion数据；

  3、通过web servieces建立asp到asp.net的桥共享session；

  在本文中，我们将讨论最后一种方案，其中也会包括一些web services与asp/ADO定制数据库，和asp session 池的基本

性能数据比较，呵呵...看完后你自己选择用哪个。

  ASP to ASP.NET Bridge / Web-Service 方案

  此方案中只是简单的实现了一个从asp到asp.net的web services桥梁，如果你需要用数据库，只需要进行简单的配置（web.

congfig和aspState 数据库）。代码中用来获得和设置session数据的方法写在一个javascirpt中，该文件必须保存在本地asp

程序中。

  此javascirpt实现MSXML， http功能以便和server端交互，并负责将这些cookie回收给用户工作站。

  优点：

  支持与服务器无关的web-farm部署，提高可扩展性简单的实现asp和asp.net的共同session状态松耦合，以sessioni管理

（无连接的HTTP接口， 80端口，可防火墙等）利用久经时间考验的asp.net session实施。

  缺点： 比asp session 内存池实现和数据库实现会慢。