As noted earlier, the generated proxy class provides a pair of methods prefixed with Begin and End to call the Web service asynchronously.
Before retrieving the results of an Asynchronous Web service call, the application must first determine that the call has completed. An application can choose to be notified of completion, use WaitHandles or can poll to determine if the Web service call has completed.
Notification
In most cases, notification is the best choice as it allows the application to initiate the call to the Web service and then proceed without any other special handling.
The application passes an AsyncCallback delegate to the BeginDelayedResponse method. The delegate will automatically be called when the Web service call completes.
Note that the call to BeginDelayedResponse does not directly call the Web service but instead queues the actual Web service call then returns immediately. No information from the Web service itself is available when the call returns.
Using notifications can be very efficient if you are making a lot of simultaneous Web service calls.
The callback function will run on a thread pool thread. So you should use Control.Invoke to send the response to the UI thread. Using notifications is the only option to allow you to release the thread you are currently executing in.
Polling
In some rare occasions, an application may wish to continue processing while periodically checking on the Web service call.
Using IAsyncResult.IsCompleted, the application can determine if the Web service call has completed. If EndDelayedResponse is called before the request has completed, it will simply block until the request does complete.
One of the problems you need to watch out for when using polling to determine if your call has completed is that you can end up using a lot of your machine's CPU cycles if you are not careful.
Using WaitHandles
WaitHandles are convenient for scenarios where you need to make asynchronous calls, but you do not want to release the thread you are currently executing in. With WaitHandles you can do some processing after your Web service call has been made and then block until the Web service call has completed.
When the Web service call completes, the AsyncWaitHandle is signaled. Using the WaitOne method on the AsyncWaitHandle will cause the calling thread (normally the main application thread) to block until the Web service completes.
There are also static methods called WaitAll and WaitAny in the WaitHandle class. These two static methods take arrays of WaitHandles as parameters, and either return when all the calls have completed, or as soon as any of the calls have completed, depending on which function you call. WaitAll allows multiple Web service calls to execute at the same time.
The WaitOne, WaitAll, and WaitAny methods all have the option of taking a timeout as a parameter. This allows you to control just how long you are willing to wait for a Web service to complete.
Many times, applications will combine WaitHandles with one of the other asynchronous approaches. I’ll show you an example later.
6. A synchronous Web service call with an asynchronous delegate vs. an asynchronous Web service call
Asynchronous Web service calls are more efficient, especially for an infrequent call or multiple calls. Two approaches are almost the same for a frequent call.
The best way to make Web service calls from Windows Forms clients is to make asynchronous Web service calls or combine asynchronous Web service calls with an asynchronous delegate.
7. Asynchronous Web service calls with asynchronous delegates
Many times, applications will combine asynchronous Web service calls with an asynchronous delegate. For example, you want to generate a report. Report data are from a remote database and a Web service. Both calls might be lengthy calls.
Using an asynchronous delegate sends the task from the UI thread to a thread pool thread. Using an asynchronous Web service call allows to retrieve data from the database and the Web service simultaneously.
