Ответы:
JMS (ActiveMQ - реализация JMS-брокера) может использоваться в качестве механизма, позволяющего обрабатывать асинхронные запросы. Возможно, вы захотите сделать это, потому что запрос занимает много времени или потому, что несколько сторон могут быть заинтересованы в фактическом запросе. Другая причина его использования - позволить нескольким клиентам (возможно написанным на разных языках) получать доступ к информации через JMS. ActiveMQ является хорошим примером здесь, потому что вы можете использовать протокол STOMP, чтобы разрешить доступ из клиента C # / Java / Ruby.
Примером из реальной жизни является веб-приложение, которое используется для размещения заказа для конкретного клиента. В рамках размещения этого заказа (и сохранения его в базе данных) вы можете выполнить ряд дополнительных задач:
Для этого код вашего приложения должен опубликовать сообщение в очередь JMS, содержащее идентификатор заказа. Одна часть вашего приложения, прослушивающая очередь, может отреагировать на событие, взяв orderId, просмотрев порядок в базе данных, а затем разместив этот заказ в другой сторонней системе. Другая часть вашего приложения может быть ответственна за получение идентификатора заказа и отправку клиенту электронного письма с подтверждением.
Используйте их все время для асинхронной обработки длительных операций. Веб-пользователь не захочет ждать обработки запроса более 5 секунд. Если у вас есть один, который работает дольше, чем один, один дизайн должен отправить запрос в очередь и немедленно отправить обратно URL-адрес, который пользователь может проверить, чтобы увидеть, когда работа будет завершена.
Публикация / подписка - еще один хороший метод для отделения отправителей от многих получателей. Это гибкая архитектура, потому что подписчики могут приходить и уходить по мере необходимости.
У меня было так много удивительных применений для JMS:
Веб чат общение для обслуживания клиентов.
Отладка логов на бэкэнде. Все серверы приложений транслировали сообщения отладки на разных уровнях. Затем можно запустить клиент JMS, чтобы отслеживать сообщения отладки. Конечно, я мог бы использовать что-то вроде системного журнала, но это дало мне всевозможные способы фильтрации вывода на основе контекстной информации (например, по имени сервера приложения, вызову API, уровню журнала, идентификатору пользователя, типу сообщения и т. Д.). Я также раскрасил вывод.
Отладка записи в файл. То же, что и выше, только определенные части были извлечены с использованием фильтров и записаны в файл для общей регистрации.
Alerting. Опять же, установка, аналогичная описанной выше регистрации, отслеживания конкретных ошибок и оповещения людей с помощью различных средств (электронная почта, текстовые сообщения, IM, всплывающее окно Growl ...)
Динамическая настройка и управление программными кластерами. Каждый сервер приложений будет передавать сообщение «configure me», а затем демон конфигурации, который будет отвечать сообщением, содержащим все виды информации о конфигурации. Позже, если все серверы приложений нуждаются в изменении своих конфигураций одновременно, это можно сделать из демона config.
И обычные - поставленные в очередь транзакции для отсроченных действий, таких как выставление счетов, обработка заказов, обеспечение, генерация электронной почты ...
Замечательно везде, где вы хотите гарантировать доставку сообщений асинхронно.
Распределенные (а) синхронные вычисления.
Примером из реальной жизни может служить структура уведомлений для всего приложения, которая отправляет письма заинтересованным сторонам в различные моменты в ходе использования приложения. Таким образом, приложение будет действовать как Producerсоздание Messageобъекта, помещая его в определенный объект Queueи двигаясь вперед.
Там будет набор Consumerс, которые подпишутся на Queueвопрос, и будет заботиться о обработке Messageотправленных через. Обратите внимание, что в ходе этой транзакции, Producers отделены от логики того, как данный Messageбудет обрабатываться.
Платформы обмена сообщениями (ActiveMQ и подобные) действуют как основа для облегчения таких Messageтранзакций, предоставляя MessageBrokers.
Я использовал его для отправки внутридневных сделок между различными системами управления фондами. Если вы хотите больше узнать о том, что такое отличная технология обмена сообщениями, я могу порекомендовать книгу « Шаблоны интеграции предприятия ». Есть несколько примеров JMS для таких вещей, как запрос / ответ и публикация / подписка.
Обмен сообщениями является отличным инструментом для интеграции.
Мы используем его для запуска асинхронной обработки, которую мы не хотим прерывать или конфликтовать с существующей транзакцией.
Например, скажем, у вас есть дорогой и очень важный элемент логики, такой как «купить вещи», важной частью покупки будет «уведомить магазин вещей». Мы делаем вызов notify асинхронным, чтобы любая логика / обработка, участвующая в вызове notify, не блокировала ресурсы и не конкурировала с ними с помощью бизнес-логики покупки. Конечный результат, покупка завершена, пользователь доволен, мы получаем наши деньги, и, поскольку очередь гарантирована, магазин получает уведомление, как только он открывается, или как только в очереди появляется новый товар.
Я использовал его для своего академического проекта, который был интернет-магазином, похожим на Amazon. JMS использовался для обработки следующих функций:
У нас было также несколько удаленных клиентов, подключенных к основному Серверу. Если соединение доступно, они используют для доступа к основной базе данных или, если не используют свою собственную базу данных. Для обеспечения согласованности данных мы внедрили механизм 2PC. Для этого мы использовали JMS для обмена сообщениями между этими системами, то есть одной, действующей в качестве координатора, который будет инициировать процесс, отправив сообщение в очередь, а другие ответят соответствующим образом, отправив обратно сообщение в очередь. Как уже упоминали другие, это было похоже на модель pub / sub.
Я видел, как JMS использовался в различных коммерческих и академических проектах. JMS может легко войти в вашу картину, когда вы захотите иметь полностью отделенные распределенные системы. Вообще говоря, когда вам нужно отправить запрос с одного узла, и кто-то в вашей сети позаботится об этом без / с предоставлением отправителю какой-либо информации о получателе.
В моем случае я использовал JMS для разработки промежуточного программного обеспечения, ориентированного на сообщения (MOM), в моей диссертации, где конкретные типы объектно-ориентированных объектов генерируются на одной стороне как ваш запрос, а компилируются и выполняются на другой стороне как ваш ответ ,
Apache Camel, используемый в сочетании с ActiveMQ, является отличным способом создания шаблонов корпоративной интеграции.
Мы используем JMS для связи с системами в огромном количестве удаленных сайтов по ненадежным сетям. Слабая связь в сочетании с надежным обменом сообщениями создает стабильный системный ландшафт: каждое сообщение будет отправлено, как только это станет технически возможным, большие проблемы в сети не будут влиять на весь системный ландшафт ...