ASP.NET application architecture: bet practice for lenghty background processes?

Question

I'll try to be brief.

What is the best practice for calling a routine from an asp.net web application that initiates a lengthy 'background' process that must be run?

For example, I want to click a button on my webpage that says "Run data conversion" (for example). This data conversion routine may take 20-40 minutes to run, so it seems to me putting all that code into a asp.net web page is not the way to go....there is no need to run this background process thru the IIS server. A sperate service or app etc seemx the way to go...

The web app, and the background process will both run on my dedicated Win2003 server so I have lots of options - but what is the best one?

Answer 1

If you control the server, I would suggest creating a windows service - take the data conversion task outside of ASP.NET altogether; you wouldn't want ASP.NET restarting halfway through a 40 minutes conversion routine.

Answer 2

There are quite a few options, basically it boils down to you needing any sort of process that you can communicate with. The options I can think of off the top of my head are; a web-service running under another application pool; a windows service; a command-line process started by your ASP.NET code.

The next question is how to communicate with the other process. If you're using a database you could set up two common-tables that both processes can access. The website would place the request for work into a table that the second process would monitor. A second table could then be used for the results, which the web-site would monitor. Another option would be to use something like the Windows Communication Foundation (WCF) or .NET remoting to send events between the processes.