ASP.NET PageLife Cycle along HttpHandlers and HttpModules

A very common argument/assumption is the ignorance of managers w.r.t to technical details or subject matter. Not sure whether the argument needs to be defended or agreed but I would like to throw some light on it from my perspective and then delve into detail of ASP.Net, as promised in the above title.

Most of the times managers are caught up in activities like Planning, Resource estimating and forecasting, budget issues, tracking the plans and various quality parameters, various reports to various stakeholders and various other organizational initiatives (making proposals, recruitment drives, ISMS 27001 audit, appraisals, etc). This leaves the managers with little time to flaunt with any of the technical skills, they may possess. Having said that, to certain extent and in some cases there is ignorance on technical subject matters on behalf of managers which is definately not laudable.

So to bridge the gap of the common opinion/argument and also enhance my understanding on technical matters, I will try and write on my blog about technical subjects, every now and then.

Introduction:

Every request that comes to IIS is routed to the appropriate ISAPI dll. For instance a request for “.ASPX” page is sent to “aspnet_isapi.dll”. Now if this is the first page being called for a particular dot net site/application, then an App Domain is created for the requested site. Creation of App Domains for each site/application restricts the access of the site to its app domain and thus protects other sites/app domain from its failure/errors.

After the creation of App Domain various .Net creates hosting environment HttpRunTime and then te other core ASP.Net objects likeHttpContext, HttpRequest, HttpResponse .

Once the core objects are created then HttpApplication object is created (or picked up from pool) to serve the request. It is then assigned to the core ASP.Net objects to process the pages.

Having the app domain in place and the creation of core ASP.Net objects completed, it is time for execution of events for the requested page/files.

Event cycle

The event cycle in summary is as depicted in the diagram below:

Before the events of page cycle execute, certain generic event handlers like Http Module Events and Http Handler events are executed.

Module events like BeginRequest, AuthenticateRequest, AuthorizeRequest, ResolveRequestCache , AcquireRequestState, PreRequestHandlerExecute, etc are executed first giving the chance for anything generic like Authencation, Authorization to be executed before the actual page starts to execute.

After the Module events, the baton is handed over to any processing of any Handler events that may have been registered. Handlers are registered for one or more file extensions and are hence extension based processors.

After the handler events the actual page events are executed (detailed below).

Once the page events are executed and the page is unloaded from memory, certain post page execution events of HttpModule are executed i.e. 'PostRequestHandlerExecute', 'ReleaserequestState', 'UpdateRequestCache' and 'EndRequest'.

(PostRequestHandlerExecute, i think should be executed after the Handler has executed and not after the end of page life cycle events).

Page Events

Let’s discuss the various Page Events and in the order in which they occur.

Init	Used to create server controls from the received HTML. Server controls canot be accessed here. Can be used to create dynamic controls, if any
LoadView State	View State is applied to the server controls. Can access view state here
PostBackData	Data posted from client is applied to the controls here. Can access form data here
Load	Can use any of the page controls and write desired logic
Validate	Validators are executed here
Event	Execution of any of the events that triggered the post back i.e button click, drop down change, etc
Pre-render	Any final changes to UI objects
SaveViewState	Saving of control data to view state
Render	Rendering of controls. Custom HTML output, if you want to add.
Unload	Any clean that one needs to do

References:

Following are the references used for understanding and presenting the information above

http://www.codeproject.com/KB/aspnet/ASPDOTNETPageLifecycle.aspx

http:// www.15seconds.com/Issue/020417.htm

Estimation Example - From a Single Line (VB6 to VB.Net)

Introduction: Many a times, we have to estimate pratically with thin air i.e no information available except for a line or two.

Cannot blame anyone for this, in this fast pace life and industry.

Below is a hypothetical example (but not impractical) that i have taken and tried to work out. The aim of example below is to give direction and get one started in the thought flow. It is not intended to be a complete proposal or solution in anyways.

Any comments, criticism and remarks would be appreciated and helpful.

Input: The only input is that the client had 1.2 million line of VB code that needed to be migrated to .Net. And the reason was that the application was quite old and maintenance was becoming an issue as well as retaining the talent of VB skills.

Approach: Ideally it would have been nice to talk to client and understand the exact reason for migration and also if any value added services could be provided while migration like, Need to host part or entire application on Web; Availability of the application on both Desktop and Web; Any part of the application that needed to be exposed as service for other application, etc.

But with no provision to clarify the above details and with just the scope of submitting a proposal to the one line input, below is a possible approach. ( Was aided by a colleague too in brainstorming the approach).

Instead of going the typical numeric way by dividing the number of LOC with productivity, we went about defining the various stages that would be required in the project, estimating for each stage and then totalling it up.

Now there are a couple of tools available in the market that migrate code from VB6 to Vb.Net and they are as follows:
1. Microsoft upgrade wizard that comes along with the Visual Studio IDE.
2. VB Migration Partner (http://www.vbmigration.com/overview.aspx)
3. VB Upgrade Companion (http://www.artinsoft.com/pr_vbcompanion.aspx)

Some do the job better than the other and that’s need to be investigated. But generally no tool does a complete job and also it is good practise to check the existing code to see if it can be tweaked for better migration like upgrade of DAO/RDO to ADO to avoid data binding issues during migration, strong typing of variables, etc.

The approach proposes a 2 phase split for executing the project:
Phase-1: Understanding the existing project and migrating the code as much as possible
Phase-2: Doing the necessary architectural changes and migrating manually the remaining code that could not be migrated with the tool.

Phase-1:
The Phase-1 would consist of following 4 stages:
1. Understanding the application
2. Determining the changes needed along with any POCs
3. Modifying the application code to prepare it for migration
4. Using the upgrade wizard to migrate the application

The output of this phase would be the following:
1. Architecture re-design document explaining the architecture of the migrated application
2. Reworked UI Specifications
3. Dot net compatible source code, 50% to 60%
4. Upgrade report generated by the upgrade wizard


Assuming that understanding the application and making the Architecture and UI specs could be done at a rate of 800 LOC per day, the phase would take 1500 man-days i.e. 75 man-months. A team of 10 people would take 7.5 months to complete this phase and the composition of team would be:
1. One Project Manager: for co-ordinating overall as well guiding technical decisions
2. One Architect: for creating the re-design document and actually migrating the code with the help of team members
3. Five team members of Analyst/Sr Developer capability
4. One UI lead and
5. Two UI members : for creating the UI specs.

Phase-2:
The outputs of the previous phase would feed into this phase. This phase would consist of the following stages:
1. Modifying code based on the architectural re-design
2. Migrating the remaining code base that could not be achieved via migration tools
3. Testing and defect fixing

Assuming that 500000 (approx 40%) lines of code would need to be modified and the end to end productivity is 100 lines of code per day (assuming on higher side as we have done One Phase), we get:
Number of man days = 500000 / 100 = 5000 man-days
Number of man months = 5000/ 20 = 250 man-months
Considering risk elements of 20%, we upgrade this value to 300 man months.

Conclusion: Thus we see that that total migration of the project would take about 375 man-months i.e. 7500 man-days, giving a productivity of 160 LOC per person per day, which is a higher value compared to Industry standards of 70-80 LOC per person per day. But one has to consider that there is fair bit of automation using the available tools.(assumed to be 60%).

Just a couple of points more before i end:

1. Just as the cost of building a one storey is not the same as building a 100 storey, similarly the effort/cost too varies with the change in size. In software this is largely due to the increase in communication channels with the increase in team size.

2. Cone of Uncertainity: At the initial stages, according to Caper Jones, the estimate could vary from +4x to -.25x (assuming x is the exact estimate). This usually tapers down in later stages and is around 1.2x during designs stage. So either do not give an early commitment on estimate or be on your best if you have to do it.