Асинхронные сценарии с использованием HTTP, TCP или именованного канала
В этом разделе описываются действия и перенаправления для различных асинхронных сценариев типа запрос-ответ (с многопотоковыми запросами с использованием HTTP, TCP или именованного канала).
Асинхронный запрос-ответ без ошибок
В этом разделе описываются действия и перенаправления для асинхронного сценария типа запрос-ответ (с многопотоковым клиентом).
Действие вызывающего завершается, когда возвращается значение beginCall
и endCall
. При осуществлении обратного вызова возвращается обратный вызов.
Вызываемое действие завершится, когда возвращается значение beginCall
и endCall
или когда возвращается обратный вызов, если он был вызван из данного действия.
Асинхронный клиент без обратного вызова
Распространение включено для обеих сторон (с использованием HTTP)
Если propagateActivity=true
, ProcessMessage указывает, в какое действие ProcessAction необходимо передать.
Для сценариев, основанных на HTTP, для первого отправляемого сообщения вызывается действие ReceiveBytes, которое сохраняется на время существования запроса.
Распространение отключено для обеих сторон (с использованием HTTP)
Если propagateActivity=false
на обеих сторонах, ProcessMessage не указывает, в какое действие ProcessAction необходимо передать. Таким образом, вызывается новое временное действие ProcessAction с новым идентификатором. Если асинхронный ответ соответствует запросу в коде ServiceModel, идентификатор действия может быть получен из локального контекста. Фактическое действие ProcessAction может быть передано с данным идентификатором.
Для сценариев, основанных на HTTP, для первого отправляемого сообщения вызывается действие ReceiveBytes, которое сохраняется на время существования запроса.
Действие "Действие процесса" создается на асинхронном клиенте при вызове или вызывающем объекте, а также, propagateActivity=false
когда ответное сообщение не включает заголовок Действия.
Распространение включено для обеих сторон (с использованием TCP или именованного канала)
Для сценария, основанного на именованном канале или TCP, действие ReceiveBytes вызывается при открытии клиента и сохраняется на время существования подключения.
Аналогично первому изображению, если propagateActivity=true
, ProcessMessage указывает, какое действие ProcessAction необходимо передать в.
Распространение отключено для обеих сторон (с использованием TCP или именованного канала)
Для сценария, основанного на именованном канале или TCP, действие ReceiveBytes вызывается при открытии клиента и сохраняется на время существования подключения.
Аналогично второму изображению, если propagateActivity=false
на любой стороне ProcessMessage не указывает, какое действие ProcessAction необходимо передать. Таким образом, вызывается новое временное действие ProcessAction с новым идентификатором. Если асинхронный ответ соответствует запросу в коде ServiceModel, идентификатор действия может быть получен из локального контекста. Фактическое действие ProcessAction может быть передано с данным идентификатором.
Асинхронный клиент с обратным вызовом
В данном сценарии добавляются действия G и A’ для обратного вызова и endCall
, а также их передачи в обратном вызове и вне его.
В этом разделе демонстрируется только использование HTTP с propagateActivity
=true
. Однако дополнительные действия и передачи также применяются к другим случаям (т propagateActivity
=false
. е. с помощью TCP или Именованного канала).
Обратный вызов создает новое действие (G), когда клиент вызывает пользовательский код для уведомления о готовности результатов. Затем пользовательский код вызывает endCall
в обратном вызове (как показано на рисунке 5) или вне обратного вызова (рисунок 6). Так как не известно, из какого действия вызывается действие пользователя endCall
, это действие помечено A’
. Действие A’ может быть одинаковым или отличаться от действия A.
Асинхронный сервер с обратным вызовом
Стек каналов выполняет обратный вызов клиента при получении сообщения: трассировки для данной обработки выдаются в самом действии ProcessRequest.
Асинхронный запрос-ответ с ошибками
Во время endCall
получаются сообщения об ошибке. В противном случае действия и передачи аналогичны предыдущим сценариям.
Асинхронная односторонняя связь с ошибками или без них
Ответ отсутствует или клиенту возвращается ошибка.