Зачем ждать асинхронных вызовов веб-сервисов

Question

Я просматривал документацию MSDN на WebServices. Here и here, обе эти ссылки говорят о вызове веб-службы и ожидают ответа, что также является общей тенденцией, которую я видел во время асинхронной реализации.

Я не понимаю, «почему нам нужно ждать возврата служебного вызова»? И, если мы ждем, почему бы не сделать синхронный звонок. В чем разница между «асинхронным вызовом с последующим ожиданием» и «синхронным вызовом»?

Answer 1

Чтобы быть полезным, асинхронный вызов должен выполнять свою задачу, пока вы идете делать что-то еще. Есть два способа сделать это:

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."

Вы не использовали бы WaitHandle, чтобы сделать эти две вещи. Тем не менее, класс WaitHandle позволяет клиентам сделать асинхронный вызов и ждать:

• один XML веб-службы (WaitHandle.WaitOne)
• первый из многих XML Web-сервисов (WaitHandle.WaitAny), или
• все веб-сервисов многие XML (WaitHandle.WaitAll)

возвращать результаты.

Другими словами, если вы используете WaitOne или WaitAny на асинхронной веб-службы, которая возвращает несколько результатов, вы можете получить один результат от вашего вызова веб-службы, и процесс его пока вы ждете от остальных результатов.

Answer 2

Использование асинхронного вызова может освободить ваше приложение, чтобы делать другие вещи, ожидая ответа. Поскольку существует довольно большое количество времени (в компьютерных циклах), ожидающих ответа веб-сервера, это время можно использовать для улучшения таких вещей, как отображение обновления состояния или выполнение какой-либо другой работы.

Например, если у вас была программа, которая выполняла сложный расчет, и шаг этого расчета включал использование некоторых справочных данных из удаленной веб-службы. Вызывая веб-службу асинхронно в начале вычисления, продолжая части вычисления, которые могут выполняться локально, а затем используя результат вызова веб-службы, когда он доступен для завершения вычисления, вы можете уменьшить общее время расчет.

Поскольку ваш код приложения не является заблокирован, ожидая ответа веб-службы, вы можете использовать это время ожидания в интересах пользователя.

Еще одна причина заключается в масштабировании, особенно на веб-сайтах, которые совершают звонки на другие веб-службы. Используя асинхронные методы страниц (или задачи), IIS может более эффективно масштабировать ваше приложение, откладывая ваши страницы, ожидающие асинхронных веб-запросов, на то, что называется «поток IO», освобождая основные рабочие потоки ASP.NET, чтобы обслуживать больше веб-страница.

Answer 3

Первый пример, на который вы ссылаетесь, выдает асинхронный вызов, а затем немедленно ждет результата. Насколько я могу сказать, что вместо работы в другой поток, разница между этим и синхронным вызовом невелика.

Другой пример, однако, говорит о том, что нужно выполнить несколько асинхронных вызовов одновременно. Если это так, имеет смысл запускать все вызовы, а затем ждать, потому что вызовы могут выполняться параллельно.

Answer 4

Один очень практическое использование асинхронных вызовов вещи как этот

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

Если вы хотите обновить пользовательский интерфейс, пока вы ждете «сервер», чтобы сделать что-то, что вам нужно сделать асинхронный вызов. Если вы совершаете синхронный вызов, ваш код будет стоять в ожидании, но если вы выполните асинхронный вызов, вы можете обновить интерфейс или даже позволить пользователю идти делать другие вещи, пока вы ждете обратного вызова. Это выходит за пределы пользовательского интерфейса, вы можете сделать асинхронный вызов, чтобы запустить некритичную задачу и продолжить работу с вашим кодом, и, возможно, вы даже не регистрируетесь для обратного вызова, если результат неважен.

Если вы НЕ НИЧЕГО, ожидая асинхронного вызова, то это менее полезно.

Answer 5

Одним из возможных применений асинхронного вызова, за которым следует ожидание, является то, что асинхронные операции часто поддерживают отмену, тогда как блокировка вызовов не выполняется. В сочетании с шаблоном CancellationToken в .NET 4.0 (или аналогичным пользовательским шаблоном pre-.NET4) вы можете создать операцию, которая кажется синхронной, но может быть легко отменена.