Классический вариант использования - это Enterprise Service Bus с JMS в качестве одного из доступных транспортов.В этом случае любое количество ИТ-систем может запросить вызов службы, поместив сообщение в известную очередь.Поставщик услуг, прослушивающий эту очередь, динамически определяет ответ на основе полей Reply-To сообщения JMS.Примером типичной услуги является запрос или обновление демографической информации клиента.Для целей запроса это определенно соответствует вашему требованию задействовать как минимум 3 ИТ-системы, поскольку практически все, что связано с клиентами, должны запрашивать эту услугу.
Другой пример с широким применением - ведение журнала.У меня есть несколько клиентов, использующих сообщения JMS для сбора записей журналов по всей сети и пересылки их на центральные серверы.Поскольку это JMS, центральный концентратор может быть высокодоступным благодаря использованию избыточных серверов и может масштабироваться горизонтально для поглощения сезонных нагрузок.
Для паба / юга пример, который мне действительно понравился, - это страховая компания.Они публикуют события на темы, которые подписаны в различных колл-центрах, внутренних новостях и для деловых партнеров.Во время урагана, произошедшего несколько лет назад, эти события включали в себя обновления прогнозов выхода на сушу, а затем, после того как шторм прошел, обновления включали в себя местоположения мобильных регуляторов претензий и других служб поддержки.Pub / Sub - отличный способ скоординировать эту массовую мобилизацию персонала и связаться с наземной службой поддержки в штаб-квартире.
Более обыденный вариант использования Pub / Sub с широкой применимостью - управление системами.Инструментированные приложения могут публиковать свой статус, и заинтересованные стороны могут получать эти уведомления.Если в Production что-то странно работает, администратор может динамически включить подписку на поток диагностики.Обычно без подписчиков, диагностика не производится.Тем не менее, без каких-либо перерывов в работающей системе, просто подписавшись, диагностические сообщения из приложения создаются по требованию.
На самом деле труднее найти примеры, в которых JMS-сообщения должны не использоваться.Наиболее распространенными противопоказаниями являются действительно синхронный обмен сообщениями и требование обрабатывать сообщения в строгой последовательности.Все поставщики JMS, о которых я знаю, в той или иной степени учитывают эти требования, и мне известно о многих развертываниях систем с этими требованиями.Однако идеальными вариантами использования для обмена сообщениями JMS являются действительно асинхронная или псевдосинхронная связь и сообщения, которые являются атомарными (то есть сообщения не зависят друг от друга или от конкретных экземпляров посредника).