Why Wait for Asynchronous Web Services Calls

I was going through MSDN documentation on WebServices. Here and here, both these links talk about calling a webservice and wait for the response, which is 开发者_高级运维also a general trend that I have seen while asynch implementation.

I don't understand "why do we need to wait for service call to return"? And, if we are waiting why don't make an synchronous call. What is the difference between an "asynch call followed by wait" and a "synchronous call"?

To be useful, the asynchronous call needs to do its thing while you go do something else. There are two ways to do that:

1. Provide a callback method for the asynchronous handle, so that it can notify you when it is completed, or

2. Periodically check the asynchronous handle to see if its status has changed to "completed."

You wouldn't use a WaitHandle to do these two things. However, the WaitHandle class makes it possible for clients to make an asynchronous call and wait for:

• a single XML Web service (WaitHandle.WaitOne),
• the first of many XML Web services (WaitHandle.WaitAny), or
• all of many XML Web services (WaitHandle.WaitAll)

to return results.

In other words, if you use WaitOne or WaitAny on an asynchronous web service that returns several results, you can obtain a single result from your web service call, and process it while you are waiting on the remaining results.

One very practical use of asynchronous calls is stuff like this

http://i.msdn.microsoft.com/Bb760816.PB_oldStyle%28en-us,VS.85%29.png

If you want to update your UI while you're waiting for a 'server' to do something, you need to make an asynchronous call. If you make a synchronous call, your code will be stuck waiting, but if you make an asynchronous call you can update the UI or even let the user go do other stuff while you're waiting for the callback. This goes beyond UI, you may make an asynchronous call to start some non-critical task and continue on with your code and its possible you don't even register for a callback if the result is unimportant.

If you do NOTHING while waiting for the asyncronous call, then its less useful.

Using asynchronous call can free up your application to do other things while waiting for the response. Since there is a fairly large amount of time (in computer cycles) waiting for a web server to respond, that time can be used for better things such as displaying a status update or doing some other work.

For example, if you had a program that performed a complicated calculation and a step of that calculation included using some reference data from a remote web service. By calling the web service asynchronously at the start of the calculation, continuing the parts of computation that can be performed locally, and then using the result of the web service call when it is available to complete the computation you can reduce the overall time of the calculation.

Since your application code is not blocked waiting for the web service to respond, you are able to utilize that wait time to the benefit of the user.

Another reason is scaling, particularly in web sites that make calls to other web services. By using asynchronous page methods (or tasks), IIS can scale your application more effectively by deferring your pages that are waiting on asynchronous web requests to whats known as an "IO thread", freeing up the main ASP.NET worker threads to serve more web pages.

The first example you're linking to issues an async call and then immediately waits for the result. Other than forking off the job to another thread, there's little difference between this and a synchronous call as far as I can tell.

The other example, however, talks about doing multiple async calls at once. If this is the case, it makes sense to launch all calls and then wait because the calls may execute in parallel.

One of the possible uses of an asynchronous call followed by a wait is that asynchronous operations often support cancellation whereas blocking calls do not. Combined with the CancellationToken pattern in .NET 4.0 (or a similar custom pattern pre-.NET4) you can create an operation that appears to be synchronous but can be cancelled easily.