The Artima Developer Community
Sponsored Link

.NET Buzz Forum
Going Beyond AJAX - What's Really Needed for Asynchronous Web Development

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Brendan Tompkins

Posts: 158
Nickname: brendant
Registered: Apr, 2005

Brendan Tompkins is .NET Developer and founder of CodeBetter.Com
Going Beyond AJAX - What's Really Needed for Asynchronous Web Development Posted: Apr 18, 2006 3:03 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Brendan Tompkins.
Original Post: Going Beyond AJAX - What's Really Needed for Asynchronous Web Development
Feed Title: Brendan Tompkins
Feed URL: /error.htm?aspxerrorpath=/blogs/brendan.tompkins/Rss.aspx
Feed Description: Blog First. Ask Questions Later.
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Brendan Tompkins
Latest Posts From Brendan Tompkins

Advertisement

To me, you can’t get too far into the whole Web2.0/Ajax/Mashup/Whatevr discussion without coming up with a method of handling long running web requests.  Yes, AJAX is about providing a responsive UI while you’re posting back to the server, but the more we begin to mash together all these remote webservice calls, fetch  xml data to display and perform lots of real work in our web applications, we’re going to have to go beyond AJAX and use real-life honest to goodness asynchronous method invocation on the server. 

What? I thought AJAX was Asynchronous?

In a sense, AJAX isn’t really asynchronous at all when it comes to HTTP requests.  An AJAX web request is a synchronous web request just like any other.  All AJAX solutions really are doing is using the browser’s built in threading (via JavaScript) to make multiple web requests for you, and then updating the HTML when the server responds.  These are really client-side hat-tricks, and will only get you so far and requires that the data you’re fetching on the servers is readily available.  What happens when the server doesn’t respond for ten minutes or even more?

You will run into problems with page requests that bump up against ASP.NET’s ScriptTimeout (which is set at 90 seconds by default).  AJAX or no AJAX, if your web method takes longer than your ScriptTimeout, you’re going to have problems.  You could try to guess the length of time that this will take and set your script timeout to some really large value, but here you’re just guessing what will work, and you run into other problems as well.  This article here nicely describes the general problem you’re faced with with requests timing out.

Consider the following Code

protected void Button_Click(object sender, EventArgs e)
{
       int totalSeconds = 5;
      
Thread.Sleep(totalSeconds * 1000);
       Label2.Text =
"Our Long Running Method finished at " + DateTime.Now.ToLongTimeString() + " and took " + totalSeconds + " seconds to complete";

}

If you crank your RequestTimeout down by adding this line to the Web.Config file:

<httpRuntime executionTimeout="1"/>

… you’ll see this screen, AJAX or no AJAX:

So How Do I Build Truly Asynchronous Web Applications?

As far as I can see it, and you should never trust me, but you have two good choices for making applications that can properly handle long running requests:

1) Use a message queue.  This is often a good choice where you need a guarantee that the process completed. You could use MSMQ or something else to make sure you’ve got the ability to reliably process requests on the server. 

2) Use Asynchronous Method Delegation on the server, create a polling mechanism  let the user know when the method has finished.  This “Fire and Forget” method of server side processing is a good, simple, straightforward method of doing work on the server. In fact, the most basic method of doing this is so simple, that you can implement this with very little code:

protected void Button1_Click(object sender, EventArgs e)
{
        LongRunningMethodAsync();
}

private delegate int LongRunningMethodDelegate();

/// <summary>
/// The Long running method async call.
/// </summary>
private IAsyncResult LongRunningMethodAsync()
{
   
LongRunningMethodDelegate longRunningDelegate = new LongRunningMethodDelegate(LongRunningMethod);
   
IAsyncResult ar = longRunningDelegate.BeginInvoke(new AsyncCallback(LongRunningMethodCallback), null);
   
return ar;

/// <summary>
/// The long running method callback.
/// </summary>
private void LongRunningMethodCallback(IAsyncResult ar)
{
   
AsyncResult aResult = (AsyncResult)ar;
   
LongRunningMethodDelegate longRunningDelegate = (LongRunningMethodDelegate)aResult.AsyncDelegate;
   
int totalSeconds = longRunningDelegate.EndInvoke(ar);
}

/// <summary>
/// The long running method.
/// </summary>
private int LongRunningMethod()

   
Random rand = new Random(Guid.NewGuid().GetHashCode());
    int mseconds = rand.Next(90000, 100000);
    Thread.Sleep(mseconds);
    
   
long totalTime = DateTime.Now.Ticks - startTicks;
   
return (int) (mseconds / 1000);
}

So Do we need AJAX?

YES!  Ajax is a very important piece of the puzzle, and solves many of the problems faced with creating responsive web User Interfaces.  In fact, the combination of AJAX using something like ATLAS with Asynchronous Method Delegation can really add up to some powerful stuff.  I’ve put together a small sample application that shows how to use ATLAS to create a progress bar that shows the status of the long running method, called using Asynchronous delegation on the server.

This application uses ATLAS to provide the AJAX user interface, and presents three link buttons that call methods both asynchronously and synchronously on the server with the ScriptTimeout property set really low to simulate long running request problems.   It also uses a cool feature of ATLAS, the TimerControl, to provide the polling code necessary to update the UI and show a progress bar.  Download the code here to try it out for yourself.  I’ve had to rip out the ATLAS script stuff because of the ATLAS eula, but download ATLAS, and copy the Microsoft.Web.Atlas.dll to the bin directory, and the ATLAS Scripts to the ScriptLibary directory and you should be able to experiment with this code.

Further Reading

Fritz Onion has a great MSDN article titled Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code and also mentions that the above solution actually uses a thread from the thread pool, so it wont help with issues of scaling an application that has a lot of long running operations. To get around this you’d want to create your own threads, pool and manage them by hand, something I’m not comfortable doing on my own .  But if you need to scale an application AND provide lots of long running processes at once, you’ll want to look there.

-Brendan

Share this post: Email it! | bookmark it! | digg it! | reddit!

Read: Going Beyond AJAX - What's Really Needed for Asynchronous Web Development

Topic: This is a best practice Previous Topic   Next Topic Topic: Filling the pipeline...

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use