Создание маршрутизатора WCF - Сеансы маршрутизаторов и транспортов
ОГЛАВЛЕНИЕ
Сеансы маршрутизаторов и транспортов
В случае транзитного маршрутизатора клиенты должны отправлять сообщения с помощью транспортного протокола и формата кодирования, ожидаемого маршрутизатором. Маршрутизатор должен перенаправлять сообщение службам приложения, используя транспотрный протокол и формат кодирования, ожидаемый службами. Все обсуждавшиеся до сих пор функции маршрутизации прекрасно работают, если на обе оконечности имеют тип HTTP — с сеансами или без сеансов. Однако, если вводится траспортный сеанс, например TCP, возникают некоторые интересные задачи. Все прекрасно в простейшем случае, когда режим безопасности отключен и нет надежных сеансов, но добавление этих функций привносит проблемы.
Как только для службы приложения включается режим безопасности, маршрутизатор должен предоставить подписанный заголовок To. Обычно это означает, что заголовок To остается нетронутым — в том виде, как он был отправлен клиентом. Но по умолчанию маршрутизатор изменяет заголовок To, чтобы он соответствовал адресу службы на момент отправки сообщений, если только не активирован режим адресации вручную. Если, например, для перенаправления сообщений службе маршрутизатор использует протокол TCP, адресация вручную не допускается, если канал выхода основан на контракте запрос-ответ.
Еще одна проблема возникает, если активированы надежные сеансы, и для вызова службы маршрутизатор использует протокол TCP. В этом случае асинхронные подтверждения отправляются обратно через маршрутизатор. Для этого требуется, чтобы маршрутизатор поддерживал сеанс со службой для получения этих асинхронных подтверждений. В результате клиент должен поддерживать дуплексный сеанс с маршрутизатором для получения этих же асинхронных подтверждений.
Обе проблемы можно разрешить частично посредством реализации маршрутизатора, поддерживающего сеансы и опирающегося на дуплексные входной и выходной каналы. Нет необходимости напрямую ставить об этом в известность ни вызывающий клиент, ни службу приложения — это реализуется в рамках маршрутизатора. Однако, существует зависимость от привязок, осведомленных о сеансе, и от дуплексной связи, если вводятся асинхронные подтверждения надежных сеансов.