Использование в реальном мире очередей JMS/сообщений?

Ответ 1

JMS (ActiveMQ - реализация брокера JMS) может использоваться как механизм, позволяющий обрабатывать асинхронные запросы. Вы можете сделать это, потому что запрос занимает много времени, или потому что несколько сторон могут быть заинтересованы в фактическом запросе. Еще одна причина для его использования - разрешить нескольким клиентам (потенциально написанным на разных языках) доступ к информации через JMS. ActiveMQ - хороший пример, потому что вы можете использовать протокол STOMP для доступа к клиенту С#/Java/Ruby.

Пример реального мира - это пример веб-приложения, которое используется для размещения заказа для конкретного клиента. В рамках размещения этого заказа (и сохранения его в базе данных) вы можете выполнить ряд дополнительных задач:

• Сохраните заказ в какой-то сторонней серверной системе (например, SAP)
• Отправьте электронное письмо клиенту, чтобы сообщить им, что их заказ был размещен.

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

Ответ 2

Используйте их все время для обработки длительных операций асинхронно. Веб-пользователь не захочет ждать более 5 секунд для запроса на обработку. Если у вас есть тот, который работает дольше, один проект должен отправить запрос в очередь и немедленно отправить обратно URL-адрес, который пользователь может проверить, чтобы увидеть, когда задание завершено.

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

Ответ 3

У меня было так много замечательных применений для JMS:

• Связь с веб-чатом для обслуживания клиентов.

• Отладка журнала на бэкэнд. Все серверы приложений транслировали отладочные сообщения на разных уровнях. Затем можно запустить JMS-клиент для просмотра отладочных сообщений. Конечно, я мог бы использовать что-то вроде syslog, но это дало мне всевозможные способы фильтрации вывода на основе контекстной информации (eq по имени сервера приложения, вызову api, уровню журнала, идентификатору пользователя, типу сообщения и т.д.). Я также раскрасил результат.

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

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

• Динамическая настройка и управление кластерами программного обеспечения. Каждый сервер приложений будет транслировать сообщение "настроить меня", а затем демон конфигурации, который будет отвечать сообщением, содержащим все виды информации о конфигурации. Позже, если все серверы приложений нуждались в их настройках, они сразу менялись, это можно было сделать из демона конфигурации.

• И обычные - очереди транзакций для отложенной деятельности, такие как биллинг, обработка заказов, предоставление, генерация электронной почты...

Это отлично, где бы вы хотели гарантировать доставку сообщений асинхронно.

Ответ 4

Распределенные (а) синхронные вычисления.
Примером реального мира может служить общесистемная система уведомлений, которая отправляет письма заинтересованным сторонам в разных точках в ходе использования приложения. Таким образом, приложение будет действовать как Producer, создав объект Message, разместив его на определенном Queue и продвигаясь вперед.
Там будет набор Consumer, который будет подписаться на Queue, и будет заботиться о передаче Message, отправленного через. Обратите внимание, что в ходе этой транзакции Producer отделены от логики того, как будет обрабатываться данный Message.
Механизмы обмена сообщениями (ActiveMQ и т.п.) выступают в качестве основы для облегчения таких транзакций Message, предоставляя MessageBroker s.

Ответ 5

Я использовал его для отправки внутридневных сделок между различными системами управления фондами. Если вы хотите узнать больше о том, что такое отличная технология обмена сообщениями, я могу полностью рекомендовать книгу " Шаблоны интеграции предприятия". Есть несколько примеров JMS для таких вещей, как запрос/ответ и публикация/подписка.

Сообщения - отличный инструмент для интеграции.

Ответ 6

Мы используем его для инициирования асинхронной обработки, которую мы не хотим прервать или конфликтовать с существующей транзакцией.

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

Ответ 7

Я использовал его для своего академического проекта, который был онлайн-магазином, похожим на Amazon. JMS использовалась для обработки следующих функций:

• Обновить позицию заказов, размещенных клиентами, поскольку пересылка отправляется из одного места в другое. Это было сделано путем непрерывной отправки сообщений в очередь JMS.
• Предупреждение о любых необычных событиях, таких как отгрузка, отложенная, а затем отправка электронной почты клиенту.
• Если доставка достигнет пункта назначения, отправка события доставки.

У нас было несколько удаленных клиентов, подключенных к главному серверу. Если соединение доступно, они используют для доступа к основной базе данных или если не используют свою собственную базу данных. Для обеспечения согласованности данных мы реализовали механизм 2PC. Для этого мы использовали JMS для обмена сообщениями между этими системами, то есть выступая в качестве координатора, который инициирует процесс, отправив сообщение в очередь, а другие ответят соответствующим образом, отправив обратно сообщение в очередь. Как уже упоминалось, это было похоже на pub/sub model.

Ответ 8

Я видел JMS, используемую в различных коммерческих и академических проектах. JMS может легко войти в вашу фотографию, когда вы хотите иметь полностью развязанные распределенные системы. Вообще говоря, когда вам нужно отправить свой запрос с одного node, и кто-то из вашей сети позаботится об этом без/с предоставлением отправителю любой информации о получателе.

В моем случае я использовал JMS для разработки ориентированного на сообщения промежуточного программного обеспечения (MOM) в моей тезисе, где конкретные типы объектно-ориентированных объектов сгенерированы с одной стороны в качестве вашего запроса и скомпилированы и выполнены с другой стороны как ваш ответ.

Ответ 9

Мы использовали обмен сообщениями для создания онлайн-котировок

Ответ 10

Apache Camel, используемый в сочетании с ActiveMQ, - отличный способ сделать шаблоны интеграции предприятия

Ответ 11

Мы используем JMS для связи с системами на огромном количестве удаленных сайтов по ненадежным сетям. Свободное соединение в сочетании с надежным обменом сообщениями создает стабильный системный ландшафт: каждое сообщение будет отправлено, как только это будет технически возможно, большие проблемы в сети не будут влиять на весь ландшафт системы...