Шаблон аварийного переключения JMS p2p для гарантии доставки - PullRequest
0 голосов
/ 26 октября 2011

Я веб-разработчик, занялся разработкой j2ee (новичок). Я искренне нуждаюсь в подтверждении этой теории.

Мне была предоставлена ​​привилегия доставлять сообщение от нашей системы (производителя) на сервисную шину SOA Предприятие (потребителю), когда пользователь нажимает кнопку сохранения. Информация не может быть пропущена или не доставлена, и заказ на доставку должен быть сохранен.

Окружающая среда:

  • Jboss EAP 5.1 в качестве производителя.
  • Сервер JNDI является ESB (возможно, стандартным).
  • Jboss ESB как потребитель.

Моё оружие выбора - JMS, p2p, из-за асинхронной природы.

Когда производитель может отправлять сообщение, могут возникнуть проблемы:

  • ESB не работает, вызывая исключение JNDI
  • Менеджер очередей по какой-то причине не активен или неправильно настроен. Это должно вызвать некоторое исключение JMS.
  • Сетевая ошибка, вызывающая ошибку JMS.

Так что я ищу какой-нибудь шаблон аварийного переключения. Вот мое предложение:

  1. Добавить внутреннюю очередь JMS, в которую изначально добавлено сообщение.
  2. Добавить MDB, который прослушивает внутреннюю очередь и пытается отправить ее в целевую очередь (ESB).
  3. Если что-то не получится, войдите в систему со смертельным исходом и отправьте электронное письмо интересным сотрудникам службы поддержки.

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

Пожалуйста, совет.

С наилучшими пожеланиями

DS

1 Ответ

1 голос
/ 27 октября 2011

Что ж, «временная» очередь - не совсем плохая идея, но в течение времени от перемещения данных из одной очереди до помещения их в другую у вас будет потенциальное окно риска. Даже если это окно близко к нулю, что произойдет, если у вас тут же случится какой-нибудь сбой? -Вы должны были бы поместить сообщение обратно в очередь (и там у вас возникнут проблемы с получением его в правильном порядке - неприятные вещи!) Или удерживать его каким-то образом, пока вы не поместите его в другую очередь. (что, в свою очередь, может быть громоздким, если вы, например, попали в какую-то ситуацию с ошибкой. Более стабильным решением было бы поместить данные в БД со столбцом очередности. Затем вы можете выбрать данные в правильном порядке, отправить их в новую очередь и, наконец, пометить их как «выполнено» или что-то еще, или даже (лучше?) Удалить данные в БД.

...