JMS между корпоративными приложениями

Question

У нас есть проект, в котором мы хотим связать две корпоративные системы вместе с JMS. В двух словах система 1 отправляет сообщение в очередь. Systems2 собирает это сообщение, выполняет всю нагрузку обработки в фоновом режиме около 30 минут, а затем отправляет сообщение обратно в очередь для получения System1.

Можем ли мы сойти с 1 очереди или нам нужно 2? Если у нас есть 2 очереди, System1 записывает в queue1, System2 выбирает. Когда system2 готов, он записывает в queue2, а System1 выбирает его.

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

Благодаря Damien

Answer 1

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

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

Answer 2

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

В частности, сервер прослушивает известную очередь. Любое приложение, желающее управлять этим сервисом, отправляет сообщение в известную очередь. Сообщение содержит адрес отправителя ответа и сервер отправляет ответ этому получателю. Таким образом, серверное приложение может обрабатывать запросы от многих относительно анонимных (или аутентифицированных, если это необходимо) клиентов в любой точке сети.

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