Как организовать веб-службы с поддержкой состояния WCF с пользовательской обработкой сеанса

Question

Рассмотрите компанию с большим набором функций, которые будут отображаться через веб-службы. Подмножество этой функциональности используется для создания сценариев с очень сложными и вычислительными сценариями и требует сохранения сеанса во время этого итеративного наращивания. Каждый сценарий нацелен на одну базовую структуру, представляющую, скажем, одного клиента. То есть, сценарий представляет собой серию тяжелых операций с единой структурой клиентов. Операции могут быть сгруппированы по какой области они нацелены, но в основном все операции в одном сценарии коренится в одной и той же структуре клиента.

Следующее решение дается снаружи и не может быть изменено: должен использоваться уже сделанный пользовательский обработчик сеанса, который в основном работает на сеансе, при условии, что простой идентификатор GUID должен быть отправлен/от клиента. Поэтому, с технической точки зрения, сеанс не должен ограничиваться одной службой, а может взаимодействовать с несколькими службами.

Помимо операций с состоянием, существует также ряд операций без гражданства.

Учитывая приведенное выше решение о пользовательском обработчике сеансов, возникает вопрос: как должны быть организованы все эти операции? Какая организация самая элегантная?

Некоторые возможности:

• Все операции с отслеживанием состояния собраны в одной службе с учетом состояния, в то время как все лица без услуги сгруппированы в произвольном наборе услуг, возможно, в какой области они ориентированы. Возможная проблема: единый сервис с поддержкой состояния может стать очень большим.

• Операции как состояния, так и состояния без учета состояния группируются в более мелкие службы, но операции с сохранением состояния и состояния без сохранения состояния все еще разделены, так что никакая служба не содержит как операции с состоянием, так и без состояния. Возможно, все сеансовое создание и завершение могут быть помещены в отдельную тонкую выделенную услугу, скажем SessionService. При таком подходе у нас нет огромного единого состояния. Но элегантная организация? Зачем вообще строгое разделение операций с состоянием и без гражданства?

• Группируйте все операции своей целью, игнорируя их состояние. Это дает ряд услуг со смешанными состояниями и состояниями без гражданства. Первый может принять токен GUID сеанса в качестве входного аргумента, и поведение службы может позаботиться о том, чтобы автоматически обрабатывать определение сеанса, учитывая какое-то соответствующее соглашение об именах для ключа сеанса/токена. Как и выше, отдельный выделенный сервис может заботиться о создании сеанса и его завершении.

• Что-то еще, не упомянуто выше?

Какая организация наиболее элегантная?

Answer 1

Я реализовал то, что в принципе является вашим третьим вариантом. У нас есть 20+ операций, некоторые из которых проверяют запрос на SessionID (GUID), некоторые из которых не работают (например, Ping() и Login (DeviceID)). Вся обработка сеанса является «Custom» в том смысле, что мы не используем постоянные сеансы WCF; скорее, мы создали функцию Login(), которая принимает идентификаторы GUID, ID, Password из клиентских запросов для аутентификации.

On Login(), мы проверяем идентификатор DeviceID, UserID и Pwd на БД, создавая строку в таблице Session, содержащую StartTime (только для < 8 часов) и DeviceID. Затем мы отправляем клиенту SessionID (GUID), который он использует во всех последующих подключениях, будь то загрузка или загрузка.

Что касается организации, подсистемы и методы организованы по типу устройства (iOS, ПК, Android) и типу операции, чтобы сохранить яблоки из апельсинов. Но каждая функция, связанная с сеансом, всегда аутентифицирует запрос, проверяя входящий SessionID. Это может показаться расточительным, проверяя каждую сессию с каждым запросом (снова и снова), но поскольку мы используем BasicHTTPBinding, мы вынуждены использовать модель без состояния.