Your Web service is now ready to be called asynchronously. That wasn't so bad, was it? One final thing to note is that you may want to capture the result from the BeginMethodName call. In Listing 3 I captured the result to my BeginGetUsers call in an object called MyResult of type IAsyncResult. It's important to note that this result object will not contain the results from your Web service's Web method. Instead this object will contain information about the specific Web service call that is currently being processed. Specifically, if you need to abort that call, this is the object you would use to do that. See Listing 4 to look at the code that would abort that call.

As discussed earlier, if you wanted to allow the users to enter search criteria and with every key press start an asynchronous Web service call to get more real-time search results, you can do that with the callback technique. One thing you'd need to remember to do, however, is with each key press, abort the previous call before you call the BeginGetUsers method again. Otherwise, you'd have as many active searches as you have key presses and the Web server would quickly become overloaded. In Listing 4, we see that to abort the Web method call, you simply cast the IAsyncResult object (this object is the return value from our BeginGetUsers method) as a WebClientAsyncResult object (you'll need a using statement for System.Web.Services.Protocols for this) and call Abort( ) on it. Your Web service call will then have been cancelled and you can then call it again with the new data in the search criteria fields.

You've now seen exactly how to call a Web service method asynchronously with the callback technique. One other popular way of calling asynchronous Web service methods is the WaitHandle technique. To do this, you must first add a using statement for the System.Threading namespace. See the code for the WaitHandle approach in Listing 5.

As you can see here, the callback technique and the WaitHandle technique are fairly similar. One thing to notice is that when we call BeginGetUsers with the WaitHandle technique, we simply pass in null to the additional parameters (the last two parameters). Also notice that we use the MyResult object of type IAsyncResult to capture the return value from BeginGetUsers and that we then use that same object to call WaitOne( ) to wait for our Web service call to be finished. Finally, we use that same object to pass into the EndGetUsers method to fetch our results.

The WaitOne call will block execution of the current thread (the client app) until the WaitHandle receives a signal (meaning that our Web service call has completed). At that point we can pull the results from our Web service object and continue. You are still able to abort your asynchronous call the same way as before at any time before you call WaitOne( ) (see Listing 4).

There are a number of other techniques for calling Web services asynchronously. You can loop in your client application and call the IAsyncResult object's IsCompleted property. You can also simply call the EndMethodName call whenever your application is ready for the results. The trick is identifying the differences between the techniques and selecting the one that best fits your application.

For example, with the callback technique, your client application is notified by the Web service when the call is completed. This is nice because you don't ever have to "freeze" your application while waiting for results. However, in order for your application to ever accept that signal from the Web service, your application requires idle time. Essentially, this means that if your client application calls the Web service and then jumps into some intense, lengthy processing, the Web service results will not be processed until your processing on the client side is finished (even if your Web method results are ready long before your client side processing is complete).

While the Web service instigates the processing of results in the callback technique by calling your client's callback method, that is not the case with the WaitHandle technique. With the WaitHandle approach, the Web service will finish processing and not notify anybody that it has completed. Instead, it's all up to the client application to drive the fetching of results. The advantage of this is that you don't require idle time to process results from your Web service call. Your client application can perform heavy, lengthy processing and pull the results from the Web service call at any point during that processing. However, the disadvantage is that you have to essentially guess as to when the appropriate time would be to ask for the results from your Web service. As soon as you call WaitOne( ) your application will perform much like a typical, synchronous Web service call and wait for the results (while freezing up the client application).

This isn't a problem if you call WaitOne( ) after or near the point at which the Web service has completed its work. However if you call WaitOne( ) too early in the process, your client app will freeze and wait for the Web service to do it's thing.

As you can see, there are a number of ways to handle Web service calls ranging from simple, synchronous Web calls to a variety of options on the asynchronous side. If you're looking for a more powerful approach to Web service calls and a way to provide a more real-time interface to an architecture built on Web services, hopefully this article has given you a few good ideas. Try the different approaches and play with whichever technique offers more for what you're trying to do in your application. When used properly, asynchronous Web service calls can make a big difference in the performance of service-based applications.