One of the biggest advantages of ASP.NET AJAX is the ability to call server-side methods from within the client browser using JavaScript. Instead of posting a form to get back a brand new version of the current page, you can now take control yourself of the operations and invoke a specific method defined on the same server as the application. Input parameters for the method, and any return values, are serialized back and forth. The ASP.NET AJAX infrastructure takes care of data transfer and serialization on both the client and the server. You can define the server API that the client can invoke either using a specialized ASP.NET Web service or using static methods defined on the page's code-behind class.
The method call is executed asynchronously with respect to the client. This fact has a few positive repercussions on the page.
First and foremost, the page is not frozen during the execution of the method. The user can continue his interaction with the page and type in new data or even command a second method call. Good feedback and progress screens can be displayed to the user. The feedback screen is not limited to static text and markup. You can use marquees as well as animated GIFs. Because the current page is not killed waiting for a brand new one to be downloaded, the background thread that animates the image is still alive and can continue doing its own job. When the remote method invocation is completed and results are ready to be processed on the client, a user-defined JavaScript callback is called to merge received data with the current page tree. It looks like a simple and effective model with no downsides. Is it really true? Let's find out.
It is essential to notice that an AJAX asynchronous call is asynchronous only with the respect to the client browser. As far as the ASP.NET runtime engine is concerned, it remains a synchronous call. Is this a problem? It can become a problem; and a big one indeed. Let's examine what happens internally when a server method is invoked through a wrapper Web service.
When you expose the client-callable server API, you create an ASMX Web service. The ASP.NET AJAX framework then creates a JavaScript proxy class for the service. Whenever you call a method on the proxy class, a request for the ASMX resource hits the Web server. In the end, the ASP.NET runtime receives a request for an ASMX resource. In the ASP.NET runtime, these requests can only be served synchronously. This means that the ASP.NET pooled thread in charge of the request can't do much more than waiting for the method to terminate. If the Web service method takes a while, the thread is blocked. When too many threads get blocked, you have a potential problem of scalability. An asynchronous HTTP handler for ASMX resources is not in ASP.NET 2.0. You can write your own, but it wouldn't be a picnic.
ASP.NET AJAX is not necessarily a friendly framework if you have strong scalability requirements and the need to invoke lengthy server methods. Solutions? The most obvious is avoiding the method call from the client. Make a postback, or even a partial postback, and mark the ASP.NET page as asynchronous. ASP.NET pages can be processed asynchronously on the server; ASP.NET Web services cannot.
