I understand that the current XXXX reporting site is too mission critical to allow a whole scale conversion to ASP.Net but that they do want to migrate it to ASP.Net. So, one way to reduce the risk involved in conversion to ASP.Net is to run the ASP script site side by side with an ASP.Net site while transferring components from ASP script to ASP.Net in a staged timeline.
I do not have architecture specifics for the XXXX ASP script reporting site to give details on how to do this, but most web reporting sites contain the following common components:
1. A Security token to indicate the user has been authenticated and authorized to access the site.
2. A connection to the reporting database.
3. Report query criteria.
4. Report data.
5. Control information.
I’ll discuss each of the above components with regard to how a dual Asp script / ASP.Net site may work with them.
The security token is an indicator that the current user has been authenticated by the application and is authorized to use it. This token is normally stored in session state although some sites may store it in a web cookie.
There are at least two recognized solutions to allow session state interoperation between ASP script and ASP.Net:
1. Storing the session state in a common state server. The ideal state server would be a SQL Server database which contains all of the active sessions. In order for the sites to distinguish their session state from another session state in the database, the two sites would maintain a cookie key and use it to extract their appropriate session.
2. This solution requires two special pages:
a. An ASP script form to extract session objects and write them to a dummy form as hidden input types. This dummy form would have an ACTION pointing to the ASP.Net page described below.
b. This ASP.Net page would iterate through the hidden input types written above and store them into the ASP.Net session object.
If the security token were contained in a cookie that cookie would have a very near term expiration and it would be simple for both the ASP script and the ASP.Net site to access the same cookie.
Reporting Database Connection
There would be no value gained from trying to share the same database connection between the two sites. Although at a deep level, the connection object is simply a series of network TCP packets sent to and from the SQL Server, at the level the web sites use the connection, it varies greatly. ASP.Net uses an ADO.Net connection and ASP script uses an ADODB connection.
Report Query Criteria
This is information such as the date range and additional query criteria chosen by the user to extract their report data. Usually, the user is presented with a single page where they enter this criteria and then push a button which submits the page and returns their report data. This operation, where the criteria data is submitted and a report page is returned could be performed quite easily between an ASP script page and an ASP.Net page or vice versa. The data would be transferred between the two using the request header of the page.
Sharing the report data between the sites is probably one of the trickiest things to do and I don’t believe there would be a need to do it. One use for it that I can think of is for a drill-down report. Perhaps levels one and two of the drill down report would be implemented with ASP script but levels three and four would be done with ASP.Net. It is my opinion that if a situation arose where report data needed to be shared between the two sites, that entire report should be migrated to ASP.Net.
Control information is the type of information that glues the pages together so that they form a single consistent experience for the user. For example, it may contain the user’s preferences, or their navigation history so that they can easily navigate back, or it may contain their security role which allows them access to a filtered set of reports. This information is best stored in the database, the session, or cookies. All three of which can be easily shared between the sites.