#jms #system #message-queue #messaging
#jms #система #очередь сообщений #обмен сообщениями
Вопрос:
У нас есть проект, в котором мы хотим связать 2 корпоративные системы вместе с помощью JMS. В двух словах, система 1 отправляет сообщение в очередь. Systems2 получает это сообщение, выполняет всю загрузку обработки в фоновом режиме в течение примерно 30 минут, а затем отправляет сообщение обратно в очередь для получения System1.
Можем ли мы обойтись 1 очередью или нам нужны 2? Если у нас есть 2 очереди, тогда System1 выполняет запись в queue1, System2 отвечает. Когда system2 готова, она записывает данные в queue2, а System1 принимает их.
Какой подход был бы лучшим? Если кто-нибудь знает о каких-либо ограничениях этих подходов или о каких-либо лучших решениях, пожалуйста, поделитесь
Спасибо, Дэмиен
Ответ №1:
Вы можете использовать селекторы в очереди, но я бы посоветовал упростить это и использовать 2 очереди, как вы описали. Я предпочитаю распределять типы сообщений по отдельным очередям, и я думаю, вы обнаружите, что это также проще всего в управлении.
Очередь — это в основном просто логическое название для корзины сообщений и небольшая, если вообще какая-либо дополнительная нагрузка, чем все сообщения в одной очереди.
Комментарии:
1. Да, я только что бегло взглянул на селекторы, но я полностью согласен с тем, чтобы все было просто. Я не думаю, что нам нужно чрезмерно усложнять этот проект с помощью селекторов
Ответ №2:
Если это выделенный одноранговый интерфейс и ни одно из этих приложений не действует как сервер, то вы могли бы обойтись одной очередью. Однако эта модель не поддерживает шаблон клиент-сервер. С другой стороны, шаблон клиент-сервер поддерживает одноранговый интерфейс, а также интерфейс клиент-сервер, и реализовать его не сложнее, так почему бы не использовать его?
В частности, сервер прослушивает хорошо известную очередь. Любое приложение, желающее управлять этой службой, отправляет сообщение в хорошо известную очередь. Сообщение содержит адрес получателя ответа, и сервер отправляет ответ этому получателю. Таким образом, серверное приложение может обрабатывать запросы от множества относительно анонимных (или прошедших проверку подлинности, если это необходимо) клиентов в любом месте сети.
Этот подход также поддерживает, чтобы клиентская и серверная очереди не находились в одном и том же механизме обработки сообщений. Она поддерживает доступ к очередям в режиме FIFO, который должен быть более производительным. Он обрабатывает классический случай асинхронного обмена сообщениями с быстрым производителем и медленным потребителем лучше, чем с одной очередью. Она поддерживает динамический ответ адресатам. Это позволяет перемещать приложения независимо друг от друга. И если то, что у вас есть, действительно является одноранговым без элементов шаблона клиент-сервер, то эта архитектура поддерживает и это.