При синхронном обмене данными делается вызов на удаленный сервер, блокирующий всю работу вплоть до завершения операции. При асинхронном обмене данными вызывающая сторона перед тем, как вернуть управление, не будет дожидаться завершения операции и даже может не беспокоиться о ее завершении.
Проще рассуждать о синхронном обмене данными. Мы знаем, когда все завершается удачно, а когда — нет. Асинхронный обмен данными может оказаться весьма полезным для продолжительных заданий, где долговременное удержание открытым подключения между клиентом и сервером непрактично. Оно также хорошо себя проявляет, когда не нужны большие задержки, при которых вызов блокирует работу в ожидании результата, что может замедлить весь процесс. Вследствие особенностей, присущих мобильным сетям и устройствам, выдача запросов при условии, что все продолжает работать (если не указано обратное), может гарантировать сохранение отзывчивости пользовательского интерфейса, даже если сеть будет сильно тормозить. В то же время, как мы вскоре узнаем, технология управления асинхронным обменом данными может быть несколько сложнее.
Эти два разных режима обмена данными могут допускать два различных идиоматических стиля совместной работы: «запрос — ответ» или «опора на события». При применении стиля «запрос — ответ» клиент инициирует запрос и ждет получения ответа. Эта модель полностью вписывается в синхронный обмен данными, но может работать и при асинхронном обмене. Можно начать операцию и зарегистрировать обратный вызов, обращаясь к серверу с просьбой дать знать о том, когда операция будет завершена.
При совместной работе, основанной на применении событий, все наоборот. Вместо того чтобы клиент инициировал запросы на выполняемые действия, он говорит о том, что случилось нечто конкретное, и ожидает того, что другие стороны знают, что им следует делать. О том, что нужно делать, никому другому никогда не говорится. По своей природе системы, основанные на использовании событий, относятся к асинхронным. Интеллектуальные решения распределяются более равномерно, то есть бизнес-логика не централизована в основных интеллектуальных ядрах, а вытеснена в различные совместно работающие сервисы. Кроме того, совместная работа на основе событий обладает высокой степенью разобщенности. Клиент, выдающий событие, не имеет возможности узнать, кто или как на него среагирует, что также означает: вы можете добавить новых подписчиков на эти события без необходимости уведомлять об этом клиента.
