Синхронные сценарии с использованием HTTP, TCP или именованного канала

В этом разделе описываются действия и перенаправления для различных сценариев синхронных запросов/ответов (с однопотоковым клиентом, с использованием HTTP, TCP или именованного канала). Дополнительные сведения о многопоточных запросах см . в асинхронных сценариях с помощью ПРОТОКОЛА HTTP, TCP или Именованного канала .

Синхронный запрос/ответ без ошибок

В этом разделе описываются действия и перенаправления для реального сценария синхронных запросов/ответов (с однопотоковым клиентом).

Клиент

Установка связи с конечной точкой службы

Создается и открывается клиент. Для каждого из этих шагов внешние действия (A) передаются в действие "Конструктор клиента" (B) и "Open Client" (C) соответственно. Для каждого действия, которому оно перенаправляется, внешнее действие приостанавливается до момента обратного перенаправления (т. е. до выполнения кода ServiceModel).

Создание запроса для конечной точки службы

Внешнее действие передается в действие ProcessAction (D). В рамках этого действия отправляется сообщение запроса и принимается сообщение ответа. Действие прекращается, когда управление возвращается пользовательскому коду. Поскольку этот запрос является синхронным, внешнее действие приостанавливается до возврата управления.

Закрытие связи с конечной точкой службы

Действие «закрыть» (I) клиента создается из внешнего действия. Оно идентично действиям "создать" и "открыть".

Сервер

Настройка узла службы

Действия «создать» и «открыть» (N и O) узла ServiceHost создаются из внешнего действия (M).

Действие прослушивания (P) создается при открывании узла ServiceHost для каждого прослушивателя. Действие прослушивания ожидает получения и обработки данных.

Получение данных по сети

При поступлении данных на проводную передачу создается действие "ReceiveBytes", если оно еще не существует (Q) для обработки полученных данных. Это действие можно использовать повторно для нескольких сообщений в пределах одного соединения или очереди.

Действие ReceiveBytes запускает действие ProcessMessage (R) при наличии достаточной информации для формирования сообщения действия SOAP.

При действии R обрабатываются заголовки сообщений и проверяется заголовок activityID. Если этот заголовок имеется, идентификатору действия присваивается значение ProcessAction. В противном случае создается новый идентификатор.

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

Закрытие узла службы

Действие "закрыть" (Z) узла ServiceHost создается из внешнего действия.

В <A: имя>A — это ярлык, описывающий действие в предыдущем тексте и в таблице 3. Name представляет собой сокращенное имя действия.

Если propagateActivity=trueдействие процесса для клиента и службы имеет один и тот же идентификатор действия.

Синхронный запрос/ответ с ошибками

Единственное отличие от предыдущего сценария заключается в том, что в качестве ответного сообщения возвращается сообщение об ошибке SOAP. Если propagateActivity=trueидентификатор действия сообщения запроса добавляется в сообщение об ошибке SOAP.

Синхронная односторонняя связь без ошибок

Единственное отличие от первого сценария заключается в том, что на сервер не возвращается сообщение. Для протоколов, основанных на HTTP, на клиент все же возвращается состояние (допустимое или ошибка). Это связано с тем, что ПРОТОКОЛ HTTP является единственным протоколом с семантикой ответа запроса, которая является частью стека протокола WCF. Так как обработка TCP скрыта от WCF, подтверждение не отправляется клиенту.

Синхронная односторонняя связь с ошибками

Если произошла ошибка при обработке сообщения (Q или далее), клиенту не возвращается уведомление. Эта логика идентична сценарию «Синхронная односторонняя связь без ошибок». Если требуется получить сообщение об ошибке, использовать сценарий с односторонней связью не рекомендуется.

Duplex

Отличие от предыдущих сценариев заключается в том, что клиент выполняет роль службы, создавая действия ReceiveBytes и ProcessMessage, подобно сценариям для асинхронной связи.