Это не Spring Integration 2?
В любом случае, я несколько дней назад сделал для себя «доказательство концепции», занимаясь тем, что вы хотите архивировать.См. https://github.com/knalli/task-worker
Относительно вашего первого вопроса: Ну, это зависит.Это зависит от того, что именно вы хотите.Не вижу проблем с настройкой в обоих проектах - хозяина проекта и ведомого проекта - имени центральной очереди.Конечно, это не должно быть жестко закодировано, а вариант конфигурации.И вы можете предоставить обеим запущенным программам одни и те же внешние свойства, которые будут использоваться в качестве компонента-заполнителя свойства в контексте конфигурации Spring.
Второй вариант немного странный: возможно, у вас был старый пример, или это Spring Ingegration1.х .. я не знаюВ любом случае: вам не нужно указывать имя ответа.Потому что это будет автоматически обрабатываться Spring Integration для вас, если вы используете AMPQ Gateway Beans.
Я процитирую порт конфигурации Inbound AMQP Gateway для конфигурации моего демона (это ваш «ведомый»):
<int-amqp:inbound-gateway
connection-factory="connectionFactory"
request-channel="requestChannel"
reply-channel="replyChannel"
error-channel="errorChannel"
queue-names="${rabbitmq.queue}"/>
Каждый из упомянутых каналов - requestChannel, replyChannel, errorChannel - регистрируется только в контексте интеграции Spring через простой
<int:channel id="requestChannel"/>
Для AMQP - имеется в виду Message Brokerконфигурация - больше нет необходимости в дополнительных частях конфигурации, кроме элемента <rabbit:queue>
.
Кроме того, я бы использовал аннотации Java для связи сообщений с интерфейсами служб (@Gateway) и классами служб (@ServiceActivator),Это значительно уменьшает конфигурацию.