Async (Очередь) Сообщения и связанные с ними данные сеанса

Question

Я пытаюсь реализовать данные контекста сеанса для очереди сообщений.

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

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

Я вижу два возможных решения:

1. Помещенный связанные данные сессии в каждом заголовке сообщения
2. Хранить данные сессий версирована в базу данных и использовать идентификатор версии в заголовке сообщения.

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

Есть ли другие решения? Я предпочитаю использовать первое решение, но сначала хочу получить обратную связь.

Как другие справляются с этим (например, JMS/NServiceBus/Masstransit)?

Обновление от ответа: Я выбрал путь, чтобы убедить членов моей команды использовать данные сеанса только в интерфейсе и помещать его в сообщения, если это необходимо для обработчика сообщений.

Answer 1

Вы не вдавались в подробности о том, почему вы хотите связать пары ключ/значение с концепцией сеанса.

Исходя из рекомендаций NServiceBus и Udi Dahan по SOA и границам обслуживания, этот тип концепции сеанса имеет тенденцию втирать меня в неправильный путь. Я чувствую, что обработчики сообщений должны быть, по большей части, довольно детерминированными в отношении времени. То есть, он должен работать так же хорошо, как сейчас, или некоторое время сидеть в очереди и выполнять то же самое в какой-то момент в будущем.

Итак, мой совет будет состоять в том, что в целях безопасности, при необходимости используйте заголовки сообщений. В NServiceBus вы можете вводить обработчики сообщений из службы IT/Ops, которые настроены на выполнение первых в цепочке обработчиков, проверку безопасности и т. Д., Не зависящих от фактической бизнес-логики. В этом случае информация заголовка влияет только на то, обрабатывается или отклоняется сообщение.

Когда вы получите информацию о типе сеанса, я бы хотел тщательно проанализировать эти требования и поместить соответствующие фрагменты в схему сообщений.

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