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

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

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

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

Клиент

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

Создается и открывается клиент. Для каждого из этих шагов внешнее действие (A) перенаправляется действиям «Создать клиент» (B) и «Открыть клиент» (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: name> символ A — ссылочный символ, описывающий действие в приведенном выше тексте и в таблице 3. Name — сокращенное имя действия.

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

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

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

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

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

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

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

Дуплекс

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