Асинхронный (в очереди) обмен сообщениями и связанные данные сеанса - PullRequest
Новая
       28

Асинхронный (в очереди) обмен сообщениями и связанные данные сеанса

0 голосов
/ 15 декабря 2011

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 16 декабря 2011

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

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

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

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

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

...