In this section, I’ll show you how to make use of asynchronous Web methods on the server side to create high performance ASP.NET Web services.

1. Responsiveness of ASP.NET Web services

A typical communication scenario is shown below.

A client calls Web service 1 and Web service 1 might need to get data from a remote database through a Web service call. Four components might sit on different machines and the calls made might be lengthy network calls.

In this section, we focus on the responsiveness of Web service 1. The scenario here is similar to the scenario where we make Web service calls from ASPX pages. So the user experience we focus on Web service 1 is to provide the (almost) same user experience in cases where heavy loads on Web service 1 happen, as experience that users normally have. Normally the thread pool is in fact the bottleneck. We need some ways to allow the thread that serves the original request to return to the thread pool while it’s doing a long-running task (making a lengthy Web service call, for example). This allows one more of the limited number of threads in the thread pool to execute, enhancing overall performance and scalability of the system. As we discussed before, this only works for a set of long-running tasks that there is a dedicated group of threads that is responsible to queue and handle the long-running tasks. Web service calls fall into the set.

The asynchronous PreRequestHandler execution approach works for making Web service calls from Web services, but the asynchronous page approach doesn’t work because Web services use the ASMX handler. However, there is an asynchronous support built into the ASMX handler. This is called asynchronous Web methods. Asynchronous Web methods were documented in [17]. Matt Powell discussed them in more details in [2]. Next I discuss asynchronous Web methods. See [2] and [17] in more details.