I really like what the on10 guys did with the on10 website. The login UI is the best I've seen and I really like the mashup they do on the profile page. I like it all so much that I've been working hard to duplicate a lot of it for use on some of my hobby sites.
I've emailed back and forth with the on10 team about how they did certain things and they have been very generous with their answers. One of the things I was curious about was how they handled the background tasks for the user profiles. Obviously, when you update your profile they don't make you wait while they lookup your location, blog, blog posts, and other details for that page. There is no point in snappy AJAX if you make the user wait for a process like that to happen. So how do they handle it?
Duncan suggested that a windows service would work pretty well or a console application that you schedule (which is something I've used in the past). However, for on10 they use a form of background processing tasks based on some of Rob Howard's work (see these slides and demo code for some examples of background threads in ASP.Net). This works well for them and the setup they have with the on10 web servers.
However, what if you didn't want to deal with spawning off threads and putting timers into your ASP.Net application? Is there some other way to do background processing with ASP.Net? What about Windows Workflow Foundation (WF)?
First off, why would you want to use a workflow for something like this? Well, I think workflows are nice because when you come back to the code six months later and want to do one more thing when the user signs up, it is very easy to look at the process and add something more. So the workflow is a nice addition for things like this.
So what are the options with a workflow? Well if you read this article by Dino you will get a good idea about how to use workflows in ASP.Net. However, there is one problem with the code in the article: it is being executed while the user waits for the response to come back. This is fine in a lot of cases, but what if you're looking at the case I'm talking about?
In this case you need to use the DefaultWorkflowSchedulerService instead of the ManualWorkflowSchedulerService. The Default service will allow WF to manage the execution of your workflow and it will spin up threads as needed to process it (and the user won't wait). However, ASP.Net doesn't like other processes spinning up a bunch of threads. I posted a question about using this method to the Advanced Workflow blog and as I was working on this post my question was answered. :)
So while I was able to get this working (and I fell in love with workflows in the process), it is not the recommended solution. In fact, the recommended solution is to put the workflow in a windows service and map to it with Indigo (Windows Communication Foundation).
I guess this means I'm going to learn Indigo, because I definately like workflows...
Update: From Moustafa Khalil Ahmed I found another article on ASP.Net workflows from Paul Andrews. Apparently the WF team has made some changes to the ManualWorkflowSchedulerService so that it can run as a background process (meaning it will work much like the default scheduler) in ASP.Net. This is great news! I have actually already coded my solution as a Windows Service that is called via Indigo. However, I'm definately going to change it back because the whole windows service thing really complicates my project when it comes to testing and deployment. Thanks guys, it worked out perfectly, I was forced to learn more about Indigo and then I get to go back to my simple solution!