Опубликован: 10.06.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Компания IBM
Лекция 4:

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

< Лекция 3 || Лекция 4: 123456 || Лекция 5 >

4.6. Межточечный обмен сообщениями

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

В этом разделе мы подробно опишем возможности межточечного обмена по действующим в инфраструктуре WebSphere MQ принципам "отправил – забыл" и "запрос – ответ". Здесь же на уровне реализации мы рассмотрим организацию служб и доступ к ним приложений.

4.6.1. Извлечение сообщений из очереди

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

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

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

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

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

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

4.6.2. Размещение служб на основе очередей сообщений

Приложение может предоставлять очередь как интерфейс к реализуемой службе и извлекать вновь поступающие в очередь сообщения для индивидуальной их обработки.

Запросы к службе, размещенной на основе очереди, может посылать произвольное количество приложений, которые подключены к инфраструктуре очередей и не владеют данными о доступности службы при отправлении сообщений. Очередь буферизирует сообщения в порядке их постановки, в котором затем эти сообщения могут быть обработаны. Такой порядок работы именуют FIFO (first-in first-out – "первый вошел, первый вышел").

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

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

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

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

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

4.6.3. Счетчики и очереди возврата

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

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

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

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

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

Примечание WebSphere MQ не переносит сообщения в очереди возврата автоматически.

4.6.4. Службы с управлением по событиям

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

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

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

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

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

4.6.5. Обмен по принципу "отправил – забыл"

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

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

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

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

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

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

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

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

4.6.6. Списки распространения

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

Примечание Эта возможность недоступна в WebSphere MQ для z/OS. Подробности см. в руководстве WebSphere MQ Application Programming Guide, SC34-6595.

4.6.7. Сегментация сообщений

Максимальная длина отдельного сообщения в инфраструктуре WebSphere MQ составляет 100 Мб. Однако по умолчанию очереди не принимают сообщений длиннее 4 Мб. Сообщения длиной свыше 100 Мб или 4 Мб – при том что очередь, через которую сообщение проходит, двигаясь по маршруту к пункту своего назначения, не настроена на прием сообщений большей длины – могут дробиться на фрагменты меньшие по размеру.

Сегментация при отправке и повторная сборка при получении сообщений может осуществляться приложением самостоятельно, а может – автоматически менеджером очередей сообщений.

Примечание Эта возможность недоступна в WebSphere MQ для z/OS. Подробности см. в руководстве WebSphere MQ Application Programming Guide, SC34-6595.

4.6.8. Логическая группировка сообщений

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

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

4.6.9. Отчеты

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

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

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

4.6.10. Отчеты "подтверждение доставки" и "подтверждение прибытия"

Также менеджер очередей WebSphere MQ может автоматически строить отчеты в следующих ситуациях.

  • Подтверждение прибытия (COA – confirm on arrival). Сообщение прибывает в очередь назначения, которой управляет менеджер целевой очереди.
  • Подтверждение доставки (COD – confirm on delivery).

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

Эти отчеты приходят по назначению, указанному приложением, отсылающим сообщение, для чего служит тот же механизм, что при обмене по принципу "запрос – ответ".

< Лекция 3 || Лекция 4: 123456 || Лекция 5 >
Михаил Завалко
Михаил Завалко
Беларусь, Минск
Artem Bardakov
Artem Bardakov
Россия