Архитектура обмена сообщениями MQ для управления отклоненными сообщениями

Question

У меня возникли трудности с выбором между 2x подходами к управлению отказом от сообщений на клиенте MQ. По общему признанию, это скорее идеологический аргумент, чем технический.

Рассмотрите это: сообщение (XML) в очереди считывается клиентом. Клиент проверяет цифровую подпись (и, в добавлении, соответствует ли сообщение определенной схеме), перед дальнейшей обработкой. Предположим, что проверка цифровой подписи не удалась. Я не хочу, чтобы сообщение было обработано. Ему нужно вернуться к источнику и быть отсортированным «вручную».

Насколько я могу видеть, есть 2x подходы я мог бы принять:

Вариант 1

• Клиент читает сообщение
• Клиент подтверждает получение
• Клиент обнаруживает сообщение как-то недействительный

• Клиент записывает недопустимое сообщение в очередь «reject»

      CLIENT MQ CLIENT 
          READ +-------+  +----+ 
      OUT Q | --- | --------> |PROCESS| -----> |NEXT| 
       | --- |   |MESSAGE|  |STEP| 
       +-----+   +-------+  +----+ 
             | 
             | 
  REJECT Q | --- | <-------------+ 
       | --- |  FAILURE 
       +-----+ 
  

Вариант 2

• Клиент читает сообщение
• клиент обнаруживает сообщение как-то недействительна
• Клиент не подтверждает получение сообщения

• MRRTY = 0 (?), поэтому QM пишет сообщение об ошибке Q

      CLIENT MQ CLIENT 
          READ +-------+  +----+ 
      OUT Q | --- | --------> |PROCESS| -----> |NEXT| 
        | --- | <-------- |MESSAGE|  |STEP| 
        +-----+ FAILURE +-------+  +----+ 
        | 
        | 
        V 
  REJECT Q | --- | 
        | --- | 
        +-----+ 
  

Я склоняюсь к варианту 2, где QM отвечает за запись потерпел неудачу на обменивались сообщениями очереди отбраковки, как мне кажется, чтобы быть аккуратным решением. Это также означает, что связь с клиентом только в одном направлении. Я понимаю, что CLIENT_ACKNOWLEDGE предназначен для получения всех сообщений до момента подтверждения: я ошибаюсь в том, что ACKing для каждого сообщения будет механизмом, который позволил бы мне написать сообщение с ошибкой QM, переданное на отклоненный Q на параметр MRRTY?

Любое мнение/обсуждение re стандартные образцы/архитектура высоко ценится.

Answer 1

Благодаря как Morag, так и Attila за их помощь и помощь.

Что это сводилось к, по существу это:

Приложение должно обрабатывать ошибки приложения, и уродливое сообщение об ошибке приложения. Менеджер очереди должен обрабатывать только транспортные ошибки. (Attila)

и этот ...

Не существует механизма, чтобы диспетчер очереди направлял сообщение об ошибке в сторону очереди. Это ответственность приложения. (Morag)

Таким образом, в случае ошибки приложения сам клиент будет ожидать писать неудачные/искаженные сообщения обратно на отдельной очереди вне зоны.