Создание приложений для доступа к инфраструктуре WebSphere MQ

4.6.11. Синхронный обмен по принципу "запрос – ответ"

Действия, связанные с отправкой сообщения-запроса и ожиданием ответа, в WebSphere MQ асинхронны и независимы. Тем не менее, если того требует приложение, их можно свести в одну синхронную операцию.

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

Приложение указывает ту очередь ответов (reply-to queue), в которой ждет появления реакции на запрос. Эта очередь может принадлежать одному, а может – совместно использующим ее нескольким приложениям. К обсуждению этого мы вернемся в "разделе 4.6.14" "Реализация очереди ответов". Название очереди ответов размещается в дескрипторе сообщения-запроса.

Также в дескрипторе сообщения может присутствовать название менеджера очереди ответов. Впрочем, обычно это поле автоматически заполняет WebSphere MQ. В этом случае оно принимает значение имени менеджера очередей, к которому подключено приложение.

Сообщение с запросом действия службы и требованием вернуть ответ по адресу приложения-отправителя в WebSphere MQ помечается как запрос ( request ).

Сообщение с ответом службы на сообщение-запрос приложения-отправителя в WebSphere MQ помечается как ответ ( reply ).

4.6.12. Частично синхронный обмен по принципу "запрос – ответ"

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

Отдельные синхронно выполняемые приложениями запросы могут относиться к тем данным, которые уже надежно хранятся внутри системы. Работая с такими запросами, приложение может не захотеть неопределенно долгое время ожидать отклика службы, установив тайм-аут фиксированной длины. Реализация функций тайм-аута и отклонения запроса до получения ответа возможна благодаря асинхронности приема и отправления сообщений в WebSphere MQ.

Для осуществления тайм-аута приложение может заявить о готовности ждать сообщений в очереди ответов в течение некоего периода ожидания ( wait interval ). По его истечении WebSphere MQ уведомляет приложение об отсутствии сообщений, доступных для обработки в очереди ответов, и приложение продолжает свою работу.

В случае, если это необходимо, приложение может неоднократно возвращаться к ожиданию сообщений в очереди ответа, выполняя свою работу до и после каждой попытки. Также приложение может периодически проверять наличие поступающих в очередь сообщений, передав WebSphere MQ сведения о том, что совершенно не желает тратить время на ожидание при отсутствии сообщений, и вынуждая WebSphere MQ запрашивать ( poll ) появление ответа.

4.6.13. Истечение срока существования сообщений

Если приложение работает по тайм-ауту, оно должно указать срок существования ( expiry time ) сообщения в дескрипторе отправляемого запроса. Описанное значение в десятых долях секунды устанавливает приложение-инициатор запроса, WebSphere MQ сокращает его для отражения времени, проведенного сообщением в инфраструктуре. Сюда относится время, проведенное в очереди по адресу назначения до приема сообщения службой на обработку, и время во всех транзитных очередях. Когда же срок существования истекает, сообщение уже не смогут принимать приложения, и оно станет пригодным для удаления инфраструктурой.

Обычно в дескриптор сообщения-ответа служба копирует текущее время существования запроса. Однако с учетом конкретной реализации время существования ответа может приниматься равным заранее установленному значению или не выставляться для сообщений-ответов вовсе.

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

4.6.14. Реализация очереди ответов

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

• Использование единой очереди ответов для всех запросов, адресованных службе.

  В дескрипторе каждого сообщения в WebSphere MQ содержится идентификатор ( message identifier ), который генерируется WebSphere MQ и может быть уникальным в пределах инфраструктуры.

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

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

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

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

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

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

  С целью организации для приложения уникального объекта в пределах инфраструктуры WebSphere MQ дает возможность создать очередь динамически. Временная динамическая очередь (temporary dynamic queue) существует ровно то время, пока к ней обращается конкретное приложение. WebSphere MQ автоматически удаляет временные динамические очереди из менеджера, как только приложение заявляет, что связанная с очередью обработка завершена, или приложение, выдавшее запрос, закрывается.

  Этот подход приемлем только для результатов запросов данных, содержащихся в непостоянных (nonpersistent) сообщениях. Во временной динамической очереди не могут содержаться постоянные сообщения с критичной для бизнеса информацией, поскольку они автоматически удаляются из менеджера очередей WebSphere MQ при завершении приложения, даже если оно вызвано сбоем и в очереди есть сообщения.

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

  Системные ресурсы для поддержания каждой временной динамически создаваемой и удаляемой очереди довольно невелики.
• Использование постоянной динамической очереди.

  Постоянная динамическая очередь (permanent dynamic queue) организуется при тех же условиях, что и временная, и может использоваться аналогично. Однако WebSphere MQ не удаляет ее из менеджера автоматически, в том числе при закрытии приложения, отправившего запрос. Вместо этого приложение обязано самостоятельно удалить очередь из менеджера очередей после завершения обработки. Этот подход наделен теми же преимуществами, что и работа с временными динамическими очередями, но годится и для использования тогда, когда в составе сообщения-ответа содержится критичная для бизнеса информация.

  Если, как в случае с единой очередью ответов, приложение закрывается, не получив ответа на выданный им запрос, сообщение-ответ и постоянная динамическая очередь сообщений продолжают существование, пока для обработки сообщения и удаления очереди не будут приняты определенные меры.

4.6.15. Обработка сообщений службой

Действия службы по согласованной обработке сообщений и генерации ответов и отчетов на дейтаграммы и сообщения-запросы вкратце иллюстрирует следующий список шагов.

1. Начать глобальную единицу работы, если таковые используются.
2. Извлечь сообщение из очереди. При этом может понадобиться учесть сегментацию сообщения или порядок в логической группе. Если потребность в этом имеется, уведомить WebSphere MQ о необходимости извлечь сообщение целиком или извлекать сообщения в составе группы с учетом порядка следования. Дополнительно выяснить, нужно ли конвертировать данные, – если да, потребовать от менеджера очередей осуществления перевода. При пользовании единицей работы указать, что данное действие производилось под управлением точки синхронизации.
3. Проверить тип, формат сообщения и запрошенные варианты отчета в его дескрипторе. Если они не отвечают функциональности службы, принять необходимые меры. К ним может относиться проверка указания очереди возврата и перенос сообщения в эту очередь.
4. Если при обработке сообщений используются единицы работы и очереди возврата, то по возможности проверить счетчик числа возвратов. Если его значение превышает порог возврата для очереди, то поместить сообщение в очередь возврата.
5. Согласно бизнес-логике службы произвести работу над сообщением, предоставив запрошенные услуги. Сюда может входить взаимодействие с иными продуктами, такими как базы данных, и передача сообщений для других служб, которые реализует система.
6. По итогам обработки данного сообщения установить результат, определив, была ли обработка успешно завершена.
7. Если с учетом типа полученного сообщения и результата его обслуживания необходим отчет или ответ, сформировать таковой. Набор традиционных шагов здесь выглядит так.
   • Получить данные для ответа.
   • Создать дескриптор ответа или отчета либо использовать дескриптор исходного сообщения.
   • Убедиться в том, что в дескрипторе должным образом установлены все поля, относящиеся к содержимому сообщения, включая его формат и способ представления данных. Задание их как значений по умолчанию вынуждает WebSphere MQ выбирать те значения, которые соответствуют локальному представлению.
   • Установить тип сообщения как ответ или отчет.
   • Из дескриптора исходного сообщения скопировать идентификатор сообщения в корреляционный идентификатор дескриптора ответа или отчета.
   • Очистить идентификатор сообщения в дескрипторе ответа или отчета, побудив WebSphere MQ сформировать новый идентификатор сообщения для ответа.
   • Использовать время существования, указанное в дескрипторе исходного сообщения, или установить его равным предопределенной величине.
   • При генерации сообщения-отчета выбрать соответствующий код обратной связи в его дескрипторе.
   • Убедиться, что признак постоянности, а также приоритет ответа или отчета те же, что и в исходном сообщении.
   • Отправить ответ или отчет, используя названия очереди ответов и управляющего ей менеджера, взятые из исходного сообщения. При пользовании единицей работы указать, что данное действие производилось под управлением точки синхронизации.
   Примечание Эти действия могут включаться в единицу работы. Именно так мы и советуем поступать при передаче постоянных сообщений с критичной для ведения бизнеса информацией.
8. Фиксировать единицу работы.