Подсистема Java Message Service (JMS), появившаяся в уже далеком 2001-м году, завоевала заслуженную популярность у разработчиков и архитекторов. Действительно, с помощью JMS можно легко реализовать сценарии интеграции путем асинхронного обмена сообщениями с гарантированной доставкой, а так же в модели "публикация/подписка" еще и в отношении один-ко-многим: одно сообщение из системы источника может быть доступно нескольким системам-приемникам.
В данной же заметке хотелось бы рассмотреть сценарии использования JMS вне контекста системной интеграции, т.е. ответить на вопрос: "А что может дать использование JMS в рамках одного приложения?".
Итак, приступим.
1. Нотификация пользователей. Понятно, что отправка сообщений пользователям по электронной почте, SMS, WebSocket и другим каналам может быть длительным процессом. Например у нас медленная сеть или сильно загруженный сервер отправки почтовых сообщений. Поэтому неверно отправлять уведомления из основного потока приложения, т.к. данный поток будет блокирован на время отправки и не сможет обрабатывать пользовательские запросы. Можно положить данные для отправки в очередь и продолжить работу, а уже слушатель очереди будет формировать уведомления и осуществлять нотификацию пользователей. Если требуется отправлять уведомления разными способами, то можно использовать топики.
2. Частный случай предыдущей задачи - распространение логов. Логи публикуются в топики, а оттуда распространяются подписчиками в файлы, на почту и т.д.
3. Распространение конфигурационной информации между серверами кластера. Данный подход используется в сервере приложений WebLogic при включении основанного на СУБД хранилища безопасности (RDBMS Security Store). Для передачи изменений всем экземплярам сервера в домене используется топик.
4. Частным случаем предыдущей задачи является распространение заданий агентам распределенного приложения. При этом возможно интересное решение: координатор задач может не знать сколько у него агентов и по каким очередям они принимают задания. Он может слушать очередь запросов на задания. При получении запроса вида "дай мне задание" координатор может сформировать задание и отправить его в очередь, указанную в свойстве JMSReplyTo запроса. При необходимости привязать ответ к запросу координатор может проставить значение свойства JMSCorrelationID ответа равное значению свойства JMSMessageID запроса. Данный подход используется при реализации псевдо-синхронного взаимодействия через JMS.
5. Организация параллельной обработки некоторой очереди задач. Хороший пример - отложенная обработка картинок в сервисах подобных Instagram. Сервер принимает картинку от пользователя, сохраняет ее в каком-либо хранилище и записывает в очередь задачу на ее обработку. После этого сразу же возвращает ответ пользователю. Сама обработка картинки осуществляется в отдельном потоке, после считывания соответствующей команды из очереди.
6. Организация потока работ (WorkFlow) и жизненного цикла какого-либо объекта. Например, мы строим автоматизированный документооборот компании. Документ за время своего жизненного цикла проходит ряд состояний. При этом на каждом состоянии он обрабатывается неким агентом. Агентом может быть человек, другая компания, автоматическая система, принтер и т.д. JMS довольно удачно моделирует ситуацию с классическим бумажным документооборотом: у каждого сотрудника (агента) есть два ящика: для входящих документов и для исходящих. Он берет поступившие ему входящие документы, обрабатывает их и кладет в ящик для исходящих. Различные маршруты реализуются переключением очередей.
Мы рассмотрели несколько примеров использования JMS в рамках одного приложения. Как видим, данный сервис довольно полезен и с его помощью можно решать широкий класс задач. При этом использование JMS и, если шире, Message Oriented Middleware (MOM) не ограничивается приведенными примерами. Буду очень рад, если вы в комментариях напишите о своем опыте использования очередей сообщений.
Понравилось сообщение - подпишитесь на блог и Twitter
В данной же заметке хотелось бы рассмотреть сценарии использования JMS вне контекста системной интеграции, т.е. ответить на вопрос: "А что может дать использование JMS в рамках одного приложения?".
Итак, приступим.
1. Нотификация пользователей. Понятно, что отправка сообщений пользователям по электронной почте, SMS, WebSocket и другим каналам может быть длительным процессом. Например у нас медленная сеть или сильно загруженный сервер отправки почтовых сообщений. Поэтому неверно отправлять уведомления из основного потока приложения, т.к. данный поток будет блокирован на время отправки и не сможет обрабатывать пользовательские запросы. Можно положить данные для отправки в очередь и продолжить работу, а уже слушатель очереди будет формировать уведомления и осуществлять нотификацию пользователей. Если требуется отправлять уведомления разными способами, то можно использовать топики.
2. Частный случай предыдущей задачи - распространение логов. Логи публикуются в топики, а оттуда распространяются подписчиками в файлы, на почту и т.д.
3. Распространение конфигурационной информации между серверами кластера. Данный подход используется в сервере приложений WebLogic при включении основанного на СУБД хранилища безопасности (RDBMS Security Store). Для передачи изменений всем экземплярам сервера в домене используется топик.
4. Частным случаем предыдущей задачи является распространение заданий агентам распределенного приложения. При этом возможно интересное решение: координатор задач может не знать сколько у него агентов и по каким очередям они принимают задания. Он может слушать очередь запросов на задания. При получении запроса вида "дай мне задание" координатор может сформировать задание и отправить его в очередь, указанную в свойстве JMSReplyTo запроса. При необходимости привязать ответ к запросу координатор может проставить значение свойства JMSCorrelationID ответа равное значению свойства JMSMessageID запроса. Данный подход используется при реализации псевдо-синхронного взаимодействия через JMS.
5. Организация параллельной обработки некоторой очереди задач. Хороший пример - отложенная обработка картинок в сервисах подобных Instagram. Сервер принимает картинку от пользователя, сохраняет ее в каком-либо хранилище и записывает в очередь задачу на ее обработку. После этого сразу же возвращает ответ пользователю. Сама обработка картинки осуществляется в отдельном потоке, после считывания соответствующей команды из очереди.
6. Организация потока работ (WorkFlow) и жизненного цикла какого-либо объекта. Например, мы строим автоматизированный документооборот компании. Документ за время своего жизненного цикла проходит ряд состояний. При этом на каждом состоянии он обрабатывается неким агентом. Агентом может быть человек, другая компания, автоматическая система, принтер и т.д. JMS довольно удачно моделирует ситуацию с классическим бумажным документооборотом: у каждого сотрудника (агента) есть два ящика: для входящих документов и для исходящих. Он берет поступившие ему входящие документы, обрабатывает их и кладет в ящик для исходящих. Различные маршруты реализуются переключением очередей.
Выводы
Мы рассмотрели несколько примеров использования JMS в рамках одного приложения. Как видим, данный сервис довольно полезен и с его помощью можно решать широкий класс задач. При этом использование JMS и, если шире, Message Oriented Middleware (MOM) не ограничивается приведенными примерами. Буду очень рад, если вы в комментариях напишите о своем опыте использования очередей сообщений.
Материалы по теме
- Real world use of JMS/message queues?
- Теория и практика Java: Есть ли необходимость в использовании JMS в новом корпоративном приложении?
Понравилось сообщение - подпишитесь на блог и Twitter
Комментариев нет:
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!