WCF Design вопросы

Question

Я проектирую сервис WCF. Я использую NetTCP привязки. Сервис может быть вызван из многопоточных клиентов. Многопоточные клиенты не используют прокси.

1. Вопрос по дизайну WCF Service.

Клиент должен отправлять эти 2 значения в каждом вызове: UserID и SourceSystemID. Это поможет Сервису идентифицировать пользователя и систему, которой он принадлежит. Вместо того, чтобы передавать эти 2 значения в каждом вызове, я решил кэшировать их с помощью Сервиса на время вызова от клиента. Я решил иметь параметризованный конструктор для Сервиса и сохранить эти значения в ChannelContext, как описано в этой статье. http://www.danrigsby.com/blog/index.php/2008/09/21/using-icontextchannel-extensions-to-store-custom-data/

Изначально я хотел сохранить значения в сеансе и иметь метод инициализации и завершения. Но там я обнаружил, что мне нужно вручную очистить сессию в каждом случае. Когда я сохраняю значения в контексте канала, мне не нужно очищать их каждый раз, и когда канал закрывается, сохраненные значения уже уничтожены. Может кто-нибудь убедиться, что я прав в своем предположении?

2. Должен ли я использовать SessionMode? Для своего контракта я использовал: [ServiceContract (SessionMode = SessionMode.Required)] и без этого атрибута сервиса.

Независимо от моего выбора, я всегда нахожу значение для: System.ServiceModel.OperationContext.Current.SessionId Как это можно объяснить?

Когда я говорю SessionMode.Required, мой InstanceContextMode автоматически меняется на PerSession?

3. InstanceContextMode для использования? Мой сервис не имеет состояния, за исключением того, что я храню некоторые значения в контексте канала, как упомянуто в (1). Должен ли я использовать Percall или PerSession в качестве InstanceContextMode?

Answer 1

Установка SessionMode в SessionMode.Required будет принудительно использовать привязки, которые поддерживают сеансы, такие как NetTcpBinding, WSHttpBinding и т. Д. Фактически, если вы попытаетесь использовать привязку без поддержки сеанса, среда выполнения выдаст исключение, когда вы попытаетесь открыть хостов.

Установка InstanceContextMode в PerSession означает, что только один экземпляр службы будет создан для каждой сессии, и этот экземпляр будет обслуживать все запросы, поступающие из этой сессии.

Если SessionId установлен во время выполнения, это может означать, что у вас может быть транспортный сеанс или надежный сеанс или сеанс безопасности. Их наличие не обязательно означает, что у вас есть сеанс приложения, то есть один объект службы, обслуживающий запросы для каждого прокси. Другими словами, вы можете отключить сеанс приложения, установив InstanceContextMode = PerCall, принудительно создавая новый объект службы для каждого вызова, сохраняя сеанс транспорта из-за использования netTcpBinding или сеанса надежного доступа или безопасности.

Думайте о сеансе приложения, который настроен InstanceContextMode и режимом сеанса, как сеанс более высокого уровня, полагаясь на сеанс более низкого уровня / безопасность, транспорт или надежный /. Сеанс приложения не может быть фактически установлен без наличия одного из других сеансов, отсюда требование для привязки.

Это становится немного длиннее, но для простых значений я бы рекомендовал вам передавать эти значения каждый раз вместо создания сеанса приложения. Это обеспечит короткий срок службы сервисных объектов, и на сервере не останется никаких ненужных ресурсов. Это имеет смысл с большим количеством клиентов или доверенных лиц, обращающихся к вашему сервису. И вы всегда можете кэшировать значения в клиентах, даже если хотите, передавать их как пользовательские заголовки.

Answer 2

В netTcp всегда идет сеанс транспортного уровня - вот почему у вас всегда есть SessionId.Таким образом, в основном, независимо от того, что вы выберете, с netTcp вы получите сеансовое соединение прямо с транспортного уровня и выше.

Что касается InstanceContextMode - если вам больше ничего не нужно отсеанс, за исключением SessionId - нет надежного обмена сообщениями и т. д. - тогда я бы обычно выбирал Per-Call - он более масштабируемый, он обычно работает лучше, он дает вам меньше «клея» для беспокойства и меньше кусков и кусочков, которые вам нужныmanage.

Я бы использовал явно необходимый сеанс, только если вам нужно включить надежный обмен сообщениями или что-то еще, что абсолютно требует сеанса WCF.Если вы этого не сделаете - тогда это просто ненужные накладные расходы, на мой взгляд.