Обработка сообщения ровно один раз

Question

Пожалуйста, рассмотрите сценарий, как показано на приложенном изображении:

1. Портал (производитель) отправит некоторое сообщение на шину, на которую должны быть обработаны несколько приложений (потребитель) - PAYROLLAPP, HELPDESK и т. Д.
2. Может быть запущено несколько экземпляров пользовательских приложений, также эти экземпляры могут быть добавлены / удалены динамически
3. Теперь важно убедиться, что сообщение обрабатывается только один раз для каждого приложения, т. Е. Если PAYROLLAPP -1 обрабатывает сообщение, PAYROLLAPP -2 НЕ должно его обрабатывать; конечно, на приведенной выше диаграмме HELPDESK - 1 должен ее обработать. Короче говоря, в случае нескольких экземпляров, один раз должен обработать сообщение, один раз
4. Когда я искал ответы, большинство вещей касалось создания "выборочного потребителя" - потребителя, который принимает / отклоняет сообщение на основе некоторой логики - обратите внимание, что для приложений, показанных в схема; логика должна находиться где-то в провайдере, который управляет шиной

Пожалуйста, руководство примерно так же.

Добавление более подробной информации после ответа Петтера:

1. Пункты слева от левой пунктирной линии являются "подходами" - Pure JMS,ESB,EAI
2. Элементы справа от пунктирной линии являются "реализациями"

Теперь большая часть - ВОПРОСЫ:

1. Независимо от решения (чистый JMS, ESB, EAI), должна ли быть реализована часть ниже горизонтальной пунктирной линии (очереди для конкретного приложения)?
2. Как помогает / препятствует использование ESB(JBoss ESB и т. Д.) Вместо "чистого" JMS(Active MQ и т. Д.)? Предоставляет ли ESB какое-либо преимущество перед JMS, которое доступно только для java (?). Я в замешательстве - "ESB или JMS", даже после ссылки на такие темы: JMS и ESB - как они связаны?, В нем есть один ответ, в котором говорится: "JMS плохо подходит для интеграции служб REST, файловых систем, S/FTP, электронной почты, Hessian, SOAP и т. Д., Которые лучше обрабатываются с помощью ESB, который изначально поддерживает эти типы. Например, если у вас есть процесс, который выдает файл CSV размером 500 МБ в полночь, и вы хотите, чтобы другая система взяла файл, проанализировала CSV и импортировала в базу данных, это может быть легко достигнуто с помощью ESB - тогда как решение с помощью простого JMS будет плохим. Точно так же интеграция служб REST с балансировкой нагрузки / переключением при сбое к нескольким серверным экземплярам может быть лучше реализована с помощью ESB, изначально поддерживающего HTTP/S ". Это только добавило моего замешательства!!!
3. Является ли использование инфраструктуры EAI (Apache Camel и т. Д.) Подходом, полностью отличным от подхода на основе чистого JMS или ESB? Если да, как и каковы плюсы / минусы?
4. Мне сказали, что только ESB не поможет, BPM(или что-то еще?) Нужно использовать для определения и хранения логики "маршрутизации" - это правда?

Answer 1

Я вижу смысл. Это может быть немного сложно с "чистым" JMS.

По сути, вы хотите разрешить порталу публиковать сообщения в теме, но не разрешать подписчикам PAYROLLAPP подписываться на эту тему (поскольку все они получат копию сообщения). Так что вам понадобится некоторая логика между ними, которая распределяет сообщение из подписки на тему в одну очередь для каждого типа приложения. Из этой очереди с помощью JMS может быть реализована нормальная балансировка нагрузки (шаблон конкурирующего потребителя).

Различные JMS-провайдеры имеют специальные реализации, которые могут выполнить эту задачу. ActiveMQ имеет свои виртуальные места назначения, а WebSphere MQ имеет свои подписки на стороне сервера, которые могут подписываться от темы к очереди. В случае, если ваш JMS-провайдер не имеет никакого способа справиться с этим, вы можете посмотреть на добавление некоторого промежуточного программного обеспечения маршрутизации в вашу топологию. Apache Camel - хороший, легкий, но есть много других, которые могут настроить некоторую маршрутизацию в середине, не затрагивая реальные приложения.

Обновление для подробных вопросов

1. Очереди под линией должны быть точно (если ваши приложения используют обмен сообщениями). Поле "Некоторая распределенная логика" не должно быть необходимым. Поле "Некоторая логика маршрутизации" может представлять собой ESB или, в этом случае, быть реализованным на сервере обмена сообщениями, например, ActiveMQ с виртуальными адресатами (или WebSphere MQ или, возможно, RabbitMQ среди прочих).

2. В области интеграции много словечек. Упрощенно (в зависимости от того, кого вы спрашиваете - ESB также можно рассматривать как архитектурный паттерн, но давайте будем его упрощать), ESB - это серверное приложение (или на практике топология с несколькими серверами), которое является центральным элементом интеграционного ландшафта. Сервер ESB просто содержит логику и небольшие потоки сообщений, которые принимают сообщения (файлы или что-либо еще) из одного приложения и направляют их во многие приложения, преобразуют их в другие форматы, шифруют, преобразуют из одного транспортного протокола, такого как HTTP/SOAP, в файл и т. Д.,

JMS - довольно запутанное и неправильно используемое слово. В последние годы Java в некоторой степени доминировал в области корпоративных сообщений, поэтому JMS иногда используется в качестве синонима Messaging. Однако обмен сообщениями (или организация очередей сообщений, асинхронный обмен сообщениями, MOM= промежуточное программное обеспечение, ориентированное на сообщения и т. Д.) Следует просто рассматривать как семейство похожих транспортных протоколов, имеющих центральный сервер ретрансляции. Это вовсе не единственная вещь Java. Множество успешных настроек ESB, с которыми я работал, на самом деле использовали магистраль обмена сообщениями

1. В вашей ситуации я бы не стал углубляться в академические / философские различия между программным обеспечением ESB и EAI. Скорее всего, они сделают для вас одно и то же. Вместо этого посмотрите на такие неопровержимые факты, как цена, поддержка, использование ресурсов, мониторинг, технологии. особенности, кривая обучения и т. д. Будь то Camel/ServiceMix, Mule, JBoss ESB, Microsoft BizTalk, IBM Message Broker, Tibco и т. д.

2. Хах! Может быть, это продавец? ESB будет хорошо. Сервер обмена сообщениями подойдет и в вашем случае, например ActiveMQ, как уже указывалось. Подходы BPM хороши для организации полуавтоматизированных бизнес-процессов или если на уровне интеграции присутствует основная бизнес-логика. В противном случае, избегайте этой дополнительной сложности.

Answer 2

1. Независимо от решения (чистый JMS, ESB, EAI), должна ли быть реализована часть ниже горизонтальной пунктирной линии (очереди для конкретного приложения)?

Потребители должны быть реализованы таким образом, чтобы они работали с выбранным вами решением, но вам не нужно беспокоиться о создании очереди для каждого потребителя или логике распределения (при условии, что потребители могут потреблять напрямую из выбранной технологии).

1. Как помогает / препятствует использование ESB(JBoss ESB и т. Д.) Вместо "чистого" JMS(Active MQ и т. Д.)? Предоставляет ли ESB какое-либо преимущество перед JMS, которое доступно только для java (?). Я в замешательстве - "ESB или JMS", даже после ссылки на потоки, подобные этим: JMS и ESB - как они связаны?. В нем есть один ответ, в котором говорится: "JMS плохо подходит для интеграции служб REST, файловых систем, S/FTP, электронной почты, Hessian, SOAP и т. Д., Которые лучше обрабатываются с помощью ESB, который изначально поддерживает эти типы. Например, если у вас есть процесс, который выдает файл CSV размером 500 МБ в полночь, и вы хотите, чтобы другая система взяла файл, проанализировала CSV и импортировала в базу данных, это может быть легко достигнуто с помощью ESB - тогда как решение с помощью простого JMS будет плохим. Точно так же интеграция служб REST с балансировкой нагрузки / переключением при сбое к нескольким серверным экземплярам может быть лучше реализована с помощью ESB, изначально поддерживающего HTTP/S ". Это только добавило моего замешательства!!!

Мое мнение таково, что ESB усложнит это решение. Он разработан (помимо прочего) для содействия интеграции с различными технологиями, но и более простые решения делают это, например, - Apache Camel обеспечивает очень простой способ связи с использованием огромного разнообразия транспортов (включая ActiveMQ).

Не все реализации JMS обеспечивают связь с другими языками, но ActiveMQ использует свой соединитель STOMP.

1. Является ли использование инфраструктуры EAI (Apache Camel и т. Д.) Подходом, полностью отличным от подхода на основе чистого JMS или ESB? Если да, как и каковы плюсы / минусы?

Apache Camel и JMS, как и JMS и ESB, являются взаимодополняющими технологиями. Camel (и Spring Integration) легкие, простые и портативные. ESB гораздо тяжелее и обычно приводят к большей связи с ESB/ сервером приложений.

1. Мне сказали, что только ESB не поможет, BPM(или что-то еще?) Нужно использовать для определения и хранения логики "маршрутизации" - это правда?

Это зависит от вашей логики "маршрутизации", мне кажется, вам не нужна логика маршрутизации, вам просто требуется гарантированная доставка потребителю 1 платежа и 1 потребителю службы поддержки. BPM был бы более полезен, когда вы хотите выборочно публиковать данные / вызывать сервис на основе некоторой характеристики этих данных.

Я настоятельно рекомендую прочитать http://activemq.apache.org/virtual-destinations.html, используя их, вы бы:

1. Отправлять сообщения брокеру ActiveMQ на VirtualTopic, например VirtualTopic.X
2. Зарегистрируйте потребителей Payroll и Helpdesk как потребителей в очередях, которые ActiveMQ динамически создает по теме - например, Consumer.Payroll.VirtualTopic.X. Оба получателя зарплаты должны быть зарегистрированы с одинаковой строкой.
3. ActiveMQ автоматически сохранит маркер, представляющий то, что не потреблял каждый набор потребителей. Это означает, что 100% сообщений будет обработано получателем платежной ведомости, но сообщение никогда не будет отправлено> 1 получателю платежной ведомости.
4. Добавить / удалить потребителей по желанию.

NBI полагают, что другие продукты, например, Apache QPID, предоставляют аналогичную функциональность - я просто больше всего осведомлен об ActiveMQ и добился успеха при таком подходе