ASP to ASP.Net Session Bridge Using a Web Service

• Download source - 6Kb
• Online ASP Demo
• Online Web Service Demo

Introduction

This article considers a possible solution for migrating the session management of an existing ASP application into ASP.Net using a simple web service. This solution might be pragmatic for an existing ASP web farm that is currently enforcing server-affinity due to the in-memory session usage and provides a strategy for iteratively upgrading to ASP.Net.

Background

Existing ASP applications often make use of “ASP sessions? a feature built into classic ASP that allows data to be temporarily stored within the memory of the web server. The well-documented limitation is that ASP session state is machine specific. For larger solutions a number of web servers are likely to be used and requests directed to any of the web servers in the farm, therefore any in-memory session state will not automatically follow subsequent requests. Each ASP server provides its own session state and unless the user is lucky and happens to return to the same server, the session state is lost.

A solution to this server-affinity caused by in-memory ASP sessions has been to use server management products (such as BigIP) to force users back to the same server within a farm. One way in which this is achieved is by using a cookie on the client workstation, which the server manager uses to direct the user back to the same server on each request. This can limit scalability, incurs a higher level of maintenance and has a higher risk of errors due to server failures (e.g. the session is lost if the server fails).

ASP.Net finally addressed these problems and allowed us to store the session information off of the individual web servers and on a central database or state server. Wonderful, problem solved. Errrm, but what about that very large investment in the existing ASP code-base? Throw it away and start again in .Net?

Rather than try to sell a big-bang approach of re-writing everything in ASP.Net to your stakeholders, an alternative solution is to come up with an iterative method of migrating code to the new model as part of your normal lifecycle. It would therefore be very helpful if the old ASP code and the new ASP.Net code could share a common session state during this process. You manage your risk and hopefully keep your job.

There are a few solutions that come to mind and might serve as a strategic solution to this problem of server-affinity when using classic ASP sessions, which include:

As can be seen, the in-memory ASP sessions performance is faster than both the ADO and ASP.Net / web service database session solutions. This can be offset significantly by accessing the session using the grouped methods given the higher cost of the round-trips. Whilst the web-service method is slower than the direct-database solution, it not as significant as one might expect (for a grouped get, twice as slow).

Intrinsic ASP

The use of built-in ASP sessions that are likely being used within your ASP applications will look something like the following:

Session("Sky") = "Blue";

On subsequent pages these values are read and the application has access to these values:

var skyString = Session("Sky");

New API Syntax

The following syntax would need to be used instead of the normal ASP session syntax, so that the JavaScript functions that encapulate the session bridge is used.

Setting One Key-Value Pair

In setting one key-value pair of session data, the syntax would be very similar to the current syntax of the built-in ASP sessions above. The following code would replace the current code that utilises intrinsic ASP sessions.

To set session data:

SetSessionValue("Sky", "Blue");

To get session data:

var SkyString = GetSessionValue("Sky");

This method would be recommended when relatively few key-value pairs (three or less) are set or retrieved on a single ASP.

Setting Multiple Key-Value Pairs

The cost of the above method is that for each setting or retrieving of a key-value pair, a round-trip to the web service is made. Given this can be a relatively costly operation in terms of response time, the following method is recommended on an ASP where a significant number (more than 3) key-value pairs are set or retrieved.

To set session data:

var sessionInfo = NewSession();
sessionInfo.Add(“Sky? "Blue");
sessionInfo.Add(“Grass? “Green?;
.
.
.
SetSession(sessionInfo);

To get session data:

var sessionInfo = GetSession();
var skyString = sessionInfo.Item(“Sky?;
var grassString = sessionInfo.Item(“Grass?;
.
.
.

Java Script Example

<%@ Language="JScript" %>

<script language="JScript" runat="server" src="ASPSessionWS.js" />

<%
	var sessionInfo = NewSession();
	sessionInfo.Item("Sky") = "Blue";
	sessionInfo.Item("Grass") = "Green";
	SetSession(sessionInfo);				

	var retrievedSession = GetSession();
	var sSky = retrievedSession.Item("Sky");
	var sGrass = retrievedSession.Item("Grass");

	Response.Write(sSky + "<br>");
	Response.Write(sGrass + "<br>");
%>

Visual BASIC Example

<%@ Language="VBSCRIPT" %>

<script language="JScript" runat="server" src="ASPSession.js" />

<%
	Dim sessionInfo 		
	Set sessionInfo = NewSession()
	sessionInfo.Item("Sky") = "Blue"
	sessionInfo.Item("Grass") = "Green"
	SetSession(sessionInfo)				

	Dim retrievedSession
	Set retrievedSession = GetSession()
	Dim sSky
	sSky = retrievedSession.Item("Sky")
	Dim sGrass
	sGrass = retrievedSession.Item("Grass")

	Response.Write(sSky & "<br>")
	Response.Write(sGrass & "<br>")
%>

Web Service Implementation

The web service consists of four simple methods, which supports getting / setting individual values within the ASP.Net session, and the slightly (but not much) more complex methods of getting / setting groups of session variables by the use of an XML payload.

public string getSessionValue(string sessionVariable)
public bool setSessionValue(string sessionVariable, string sessionValue)
public string getSessionValues()
public bool setSessionValues(string xmlSessionValues)

For the ASP.Net web service to support the creation and maintenance of sessions, then the following attribute is included in each of the methods. This then returns the ASP.Net_SessionId cookie into the responses, which can be used to bridge the session to the ASP code.

[WebMethod(EnableSession=true)]

That's pretty much it. You might want to include some more sophisticated implementation to integrate other server-side state information into the same interfaces. This version of the web service also has no authentication or other restriction on use, which given the open nature of a web service, might not be appropriate for your environment - therefore you might want to use a GUID or some other identification to show that a user is logged on as a parameter in each of the web service interfaces. Nice and simple.

ASP Bridge Implementation

The ASP side of the bridge is basically depdendent on the MSXML2.ServerXMLHTTP COM interface to perform calls to the web service server-side and the Scripting.Dictionary to provide a hash-table for maintaining a temporary (lifetime of page) copy of the session. Before the call is made to the web-service, it is important to ensure that if there is already an ASP.Net_SessionId cookie on the client workstation, it is passed as part of the server-side web service request. Likewise, that any cookies received from the web service are then included in the ASP response so that they are written to the client workstation for subsequent requests.

var xmlHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP");
xmlHTTP.open("POST", sURL, false);	
var clientCookie = "" + Request.Cookies("ASP.Net_SessionId");
xmlHTTP.setRequestHeader("cookie", "ASP.NET_SessionId=" + clientCookie + "; path=/;");
.
.
.
Response.Cookies("ASP.NET_SessionId") = httpCookie;

The dictionary object is used to convert to and from a simple XML payload (basically just a collection of <SessionItem> nodes).

var dctSession = new ActiveXObject("Scripting.Dictionary");
var re = new RegExp("<SessionItem ", "g");

So, perhaps not the most elegant implementation, but it makes good use of what is available in ASP without resorting to rolling our own component. Again, nice and simple.

Deployment

A JavaScript file “ASPSessionWS.js?must be copied locally to where the ASP application is run. Include this script tag in any ASP file that utilises the ASP.Net sessions:

<script language=”Jscript?runat=”server?src=”\Script\ASPSessionWS.js?></script>

The web server only needs port 80 access available and the URL of where you have copied the web service updated in this script file (see below). The web service deployment is a simple matter of just copying your .asmx file to the web server that will be maintaining the session state, which in turn will need to change the web.config file to reflect wherever your database has been deployed (MSDN has tutorials for setting this up here).

function GetWebService(Function, Parameters)
{
	var xmlPayload = "";
	var sURL = "http://www.fullerdata.com/ASPBridge/bridge.asmx" + "/" + Function;

Summary

Using a web service as a bridge from legacy ASP sessions to new ASP.Net sessions provides a pragmatic means of migrating your applications to new technologies, allowing the old and the new to share a single session context. The performance cost is significant, but might be a "good enough" solution as an interim for migration completely to .Net, especially within web-farm environments where the removal of web server affinity is a priority.

Links

There are already a number of other articles about using ASP.Net session state on CodeProject, of which the following are notable (IMHO):