Отдельные детали организации MQI-интерфейса не связаны ни с одним из таких объектно-ориентированных или стандартизованных интерфейсов прикладного программирования (API), как Java Message Service (JMS), непосредственно. Однако эти API основаны на базовых возможностях MQI-интерфейса. Поэтому понимание объектов, сообщений WebSphere MQ и MQI не становится бесполезным даже при обращении к инфраструктуре через стандартизованные API. В этой лекции мы обсудим следующие вопросы:
Интерфейс очередей сообщений
Очереди
Применение триггеров
6.1. Интерфейс очередей сообщений
Интерфейс очередей сообщений (MQI – Message Queue Interface) служит процедурным интерфейсом отправки и получения сообщений через WebSphere MQ. Поэтому напрямую он может использоваться только из процедурных языков программирования, например C. В то же время немало приложений из числа созданных для обращения к инфраструктуре очередей сообщений WebSphere MQ используют объектно-ориентированный язык, такой как C++ или Java. Впрочем, извлечь выгоду из использования стандартизованных интерфейсов отправки и получения сообщений WebSphere MQ, включая Java Message Service (JMS) или Extended Message Service (XMS), могут и приложения, написанные на процедурных и объектно-ориентированных языках одновременно.
Как бы то ни было, все эти API используют MQI как основу реализации, либо вызывая функции модулей, написанных на языке C, либо посылая по клиентскому подключению менеджеру очередей сообщений команды MQI-интерфейса. Поэтому знание самого MQI может оказаться чрезвычайно полезным при написании приложений, использующих API, и при анализе потока сообщений в инфраструктуре.
MQI-интерфейс содержит 13 функций, а также структуры и типы данных. Они реализуют доступ к функциям менеджера, связанным с отправкой и получением сообщений по принципу межточечного обмена, заданием структуры сообщений WebSphere MQ и обеспечением возможности запроса и изменения атрибутов важнейших типов объектов.
6.1.1. Дескриптор сообщения WebSphere MQ (MQMD)
Дескриптор сообщения WebSphere MQ (MQMD) связан с каждым из сообщений, находящихся в очереди под управлением менеджера. Это – структура, содержащая ряд полей с описанием сообщения. Размещая сообщение в очереди, приложение передает менеджеру его дескриптор отдельно от его тела. При чтении из очереди приложение получает от менеджера очередей MQMD и тело сообщения отдельно.
Следующий список содержит перечень часто используемых полей дескриптора сообщения.
Тип сообщения ( MsgType ).В WebSphere MQ сообщения могут помечаться как относящиеся к типам, перечисленным ниже.
Дейтаграмма ( datagram ) – не требует обязательного ответа, но может требовать формирования отчета.
Запрос ( request ) – требует обязательного ответа.
Ответ ( reply ) – выдается как отклик на сообщение-запрос.
Отчет ( report ) – строится при обработке сообщения.
Отчет ( Report ) и обратная связь ( Feedback ).Поле "отчет" выступает признаком требования отчета, формируемого при обработке сообщения менеджером очередей сообщений или приложением-получателем. Например, приложению может требоваться отчет менеджера-приемника об успешной доставке сообщения или от приложения-получателя – о его успешном обслуживании. При формировании отчета приложением или менеджером в поле обратной связи помещается код с указанием причины для его построения.
Очередь ответов ( ReplyToQ ).Приложение, выдающее сообщение-запрос или определяющее варианты построения отчета, задает в этом поле название очереди ответов. Приложение, формирующее ответ на этот запрос или отчет как отклик на дейтаграмму, помещает его в ту очередь, которая имеет такое название.
Менеджер очереди ответов ( ReplyToQMgr ).Содержит имя менеджера очередей, управляющего очередью ответов. WebSphere MQ автоматически помещает в это поле название того менеджера, в который сообщение помещается изначально. Приложение должно модифицировать это поле только в том случае, если его ответы или отчеты необходимо пересылать в очередь на другом менеджере.
Идентификатор сообщения ( MsgId ).Может быть определен приложением или сгенерирован менеджером. Выдается приложению-отправителю менеджером очередей сообщений и может использоваться при последующей обработке.
Созданный менеджером очередей сообщений идентификатор является неповторяющимся во всей инфраструктуре WebSphere MQ. Однако это зависит от всех без исключения менеджеров в ее составе, имеющих уникальные в пределах первых 12 символов имена.
Корреляционный идентификатор ( CorrelId ).Это поле может использоваться приложениями для связи двух сообщений или связи сообщения и приложения. Чаще всего служит для сопоставления ответа с запросом при обмене сообщениями по принципу "запрос – ответ". Приложение, которое обрабатывает запрос, копирует его идентификатор сообщения в поле корреляционного идентификатора формируемого ответа. Если же в одну очередь приходят ответы сразу на несколько сообщений-запросов или ответы на запросы нескольких приложений, то приложение сможет прочитать ответ, обратившись лишь к сообщениям с нужным корреляционным идентификатором.
Признак постоянного сообщения ( Persistence ).Это поле определяет, относится ли сообщение к категории постоянных, речь о которых велась в разделе 3.4.1 "Постоянные и непостоянные сообщения". Будучи не заданным приложением-отправителем явно, оно наследует значение признака постоянных сообщений той очереди, в которой размещено.
Приоритет ( Priority ).Сообщениям может назначаться приоритет от 0 до 9. При этом WebSphere MQ можно настроить так, чтобы сообщения с большим приоритетом передавались приложениям раньше тех сообщений, чей приоритет ниже.
Идентификатор набора кодовых символов (CCSID – CodedCharSetId ).CCSID задает набор символов, который отображает определенные символы в те или иные байты или наборы байтов. Для данных, именуемых строковыми и представляющих текст, WebSphere MQ может производить конверсию из одного набора символов в другой так, что одни и те же символы будут представлены одними и теми же данными в сообщении. Мы говорили об этом в разделе 4.3.2 "Преобразование данных". По умолчанию поле имеет значение CCSID менеджера, которому передано конкретное сообщение; последнее же чаще всего равно CCSID соответствующего компьютера.
Кодировка ( Encoding ).От платформы к платформе порядок байтов в числовых данных меняется. WebSphere MQ использует поле "кодировка" для указания того, как эти данные представляют числовые значения. Как в случае CCSID, над числовыми данными в WebSphere MQ допустимо преобразование информации. По умолчанию поле "кодировка" имеет значение типа кодировки машины, где сформировано сообщение.
Формат ( Format ).Поле "формат" определяет тип данных, передаваемых в сообщении. Оно может задавать тип данных сообщения в целом: строковый, числовой, двоичный. Кроме того, оно может определять тип структуры WebSphere MQ, которая, в свою очередь, может всего лишь являться первой в числе структур, образующих цепь структур сообщения. Каждая из структур этого рода способна включать в себя различные типы данных. По умолчанию поле "формат" соответствует двоичному типу, преобразования которого в WebSphere MQ запрещены.
Время ( PutTime ) и дата ( PutDate ) размещения в очереди.В этих полях дескриптора сообщения менеджер сохраняет время и дату, представляющие момент прибытия сообщения в очередь, где оно пребывает в настоящее время.
Срок жизни ( Expiry ).Сообщениям может назначаться период существования, помещаемый в это поле и измеряемый в десятых долях секунды. Если сообщение остается в инфраструктуре очередей WebSphere MQ дольше этого времени, оно становится устаревшим, недоступным для приложений и пригодным для удаления менеджером очередей сообщений. Устаревшие сообщения удаляются исключительно при попытке извлечения или просмотра их приложением. WebSphere MQ V6.0 содержит в своем составе задание контроля срока существования (expiry task), которое периодически просматривает все сообщения всех без исключения очередей и принудительно удаляет устаревшие сообщения.
MQMD содержит сведения о приложении, поместившем сообщение в очередь, и идентификаторе пользователя, от чьего имени это приложение выполнялось.
Также в MQMD входит информация, относящаяся к сообщениям, входящим в группы, или сегменты. О сообщениях такого рода мы говорили в разделе 4.6.7 "Сегментация сообщений".
6.1.2. Коды завершения и причины
Вызов любой из функций MQI-интерфейса завершается возвратом кода завершения ( CompCode ) и причины ( Reason ):
Код завершения.Может иметь одно из трех следующих значений:
MQCC_OK: обращение к функции успешно завершено.
MQCC_WARNING: функция выполнена частично. Подробности отражены в коде причины.
MQCC_FAILED: вызов функции неудачен.
Код причины.По завершении вызова любой функции она может вернуть один из многих кодов причины; какие-то из них представляют признаки сбоя, какие-то – частичное выполнение. Подробнее см. раздел "Reason" описания полей (Fields) конкретных вызываемых функций в руководстве WebSphere MQ Application Programming Reference, SC34-6596.
Код причины – целочисленное значение. Для получения символьного представления десятичного или шестнадцатеричного числового значения или числового значения из символьного представления используйте команду WebSphere MQ mqrc. В следующем примере для кода причины MQRC_NO_MSG_AVAILABLE будет выдана одинаковая информация:
mqrc MQRC_NO_MSG_AVAILABLE
mqrc 2033
mqrc 0x7F1
mqrc 0x000007f1
Подробности см. в разделе 12.1.2 "Коды причины".
6.1.3. MQCONN и MQCONNX
Для отправки сообщений через инфраструктуру очередей каждое приложение или поток должно установить соединение с менеджером. Им может являться локальный менеджер, размещенный на той же машине, что и приложение, или же удаленный менеджер на другой машине сети.
Программный выбор способа подключения приложения – связывание с локальным менеджером или клиентское соединение с удаленным – в MQI невозможен. В программах на языке C, использующих MQI напрямую, выбор производится подключением к приложению библиотек связывания или клиентских соединений. При пользовании другими API метод выбора подключения к менеджеру зависит от самого API и обсуждается в документации WebSphere MQ к данному интерфейсу.
В MQI-интерфейс входят две функции подключения к менеджеру очередей сообщений: MQCONN и MQCONNX. Единственное различие между ними заключается в том, что вызову функции MQCONNX можно передать дополнительные параметры, объединенные в структуру параметров подключения (MQCNO).
При вызове любой из двух функций установления соединения ей требуется название того менеджера, к которому должно быть подключено приложение. Если это название не указано, а приложение использует подключение путем связывания, предполагается применение менеджера очередей сообщений по умолчанию, как это описано в разделе 5.3.5 "Менеджер по умолчанию".
Приложение может установить соединение с менеджером только в том случае, если оно на это уполномочено. В основе авторизации приложений лежит контекст идентификационных данных (identity context). Для приложений, выполняющих связывание, этим контекстом служит идентификатор пользователя операционной системы, от чьего имени выполняется приложение. Он же может выступать в роли контекста идентификационных данных для клиентских соединений; кроме того, в последнем случае менеджер очередей может быть сконфигурирован так, чтобы предоставлять клиенту конкретный идентификатор пользователя, существующий на удаленной машине, где работает менеджер.
В случае успешного подключения приложению выдается описатель (handle) соединения ( Hconn ), который им должен передаваться всем будущим вызовам MQI.
6.1.4. MQOPEN и MQCLOSE
Функция MQI MQOPEN служит для обращения к заданному объекту в составе менеджера, с которым приложение установило соединение. Для каждого из объектов (например, очереди) доступ к которому необходим приложению, должен производиться отдельный вызов. Любой вызов функции MQOPEN должен сопровождаться соответствующим вызовом MQCLOSE.
Приложение передает MQOPEN дескриптор объекта (MQOD). Он описывает объект, который планирует открыть приложение, и содержит его название. При работе с очередями также может задаваться название менеджера очередей сообщений. Это позволяет приложению переслать конкретное сообщение конкретному менеджеру в системе, информацией о котором располагает локальный менеджер. Подробнее об этом см. раздел 6.2.1 "Разрешение названия очереди".
Также приложение передает этой функции параметры, определяющие род действий, которые нужно осуществить над объектом.
Основываясь на информации из дескриптора и контексте идентификационных данных приложения, менеджер выясняет, уполномочено ли данное приложение на выполнение запрошенного им действия над данным объектом. Если полномочия есть, приложению возвращается описатель объекта ( Hobj ), который при работе с этим объектом должен передаваться им будущим вызовам MQI.
Не все типы объектов доступны через MQI-интерфейс. Как правило, MQI служит для открытия объектов-очередей для размещения в них и изъятия сообщений. Типы объектов-очередей под управлением менеджеров и способы обращения к очередям удаленного менеджера мы обсудим в раздел 6.2 "Очереди".
При вызове MQOPEN приложение может запросить следующие возможные действия:
Запись ( Output ). Размещение в очереди сообщений функцией MQPUT. Доступно только для объектов-очередей.
Просмотр ( Browse ). Считывание из очереди сообщений функцией MQGET, при котором те сохраняют свою доступность для других приложений. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
Извлечение ( Input ). Считывание из очереди сообщений функцией MQGET, после которого сообщения не сохраняют свою доступность для других приложений. Может быть монопольным, что означает возможность открытия очереди для считывания лишь одним приложением одновременно. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
Запрос ( Inquire ). Возврат значений атрибутов объекта функцией MQINQ.
Установка ( Set ). Задание значений атрибутов объекта функцией MQSET.
6.1.5. MQPUT
MQI-функция MQPUT служит для размещения сообщений в очередях, открытых для записи.
Вызов функции MQPUT завершается постановкой сообщения в очередь того менеджера, к которому подключено приложение. Впрочем, объект, открытый функцией MQOPEN, может представлять очередь назначения под управлением другого, удаленного менеджера. В этом случае очередью, в которой будет размещено сообщение, станет транспортная очередь (transmission queue) локального менеджера.
Доставка сообщения менеджеру, которому оно предназначено, как и любому другому менеджеру на маршруте его движения, осуществляется по каналам. Каналы передачи сообщений мы обсудим в разделе 7.4 "Распределенные каналы сообщений".
При вызове функции MQPUT ей передается структура дескриптора сообщения (MQMD). Во время работы функции менеджер заполняет дескриптор данными, возвращая их приложению в той же самой структуре.
Примечание Если одна и та же структура MQMD служит для выполнения нескольких вызовов MQPUT, поля, которые сформировал менеджер, между вызовами должны быть обнулены. Очистки, в частности, требует идентификатор сообщения; иначе он будет полностью совпадать у всех сообщений, размещенных с помощью этой структуры MQMD.
Для указания того, как именно выполняется обращение к MQPUT, ей также передается структура параметров размещения сообщения (MQPMO), в которой приложению возвращается определенная информация.
Обычно MQPMO служит для указания на то, что обращение к MQPUT должно произойти под управлением точки синхронизации. Это значит, что вся работа по размещению сообщения войдет в текущую единицу работы, а сообщение будет недоступно остальным приложениям для считывания и передачи менеджеру-получателю сообщения, пока не будет произведен вызов функции MQCMIT.
6.1.6. MQPUT1
MQI-функция MQPUT1 вызывает MQOPEN, за ней – MQPUT и завершает свою работу вызовом MQCLOSE. Приложение же должно передать ей достаточно информации для выполнения всех трех действий.
MQPUT1 – удобный и эффективный механизм вызова при постановке в очередь единичного сообщения. Нередко он служит для размещения в очереди сообщения-ответа или отчета.
6.1.7. MQGET
MQI-функция MQGET предназначена для считывания сообщений из очередей, открытых для просмотра или для извлечения.
На вход функции MQGET передается структура дескриптора сообщения (MQMD). В ней менеджер очередей возвращает дескриптор успешно считанного сообщения.
Для указания того, как именно выполняется обращение к MQGET, ей также передается структура параметров извлечения сообщения (MQGMO), в которой приложению возвращается определенная информация.
Структура MQGMO определяет, должен ли вызов функции MQGET просмотреть сообщения, оставив таковые доступными для других приложений, или извлечь с удалением их из очереди.
Приложение могут не интересовать все сообщения очереди. Например, ему могут быть интересны только отчеты или ответы на дейтаграммы или запросы, выданные им самим. Для упрощения своей задачи приложение может указать на тот факт, что ему интересны лишь сообщения с конкретным корреляционным идентификатором, поместив этот идентификатор в структуру MQMD, передаваемую функции MQGET. При этом оно может управлять тем, производится ли сопоставление с корреляционным идентификатором из структуры MQMD, используя для этого параметры сопоставления (match options) в структуре MQGMO. Такое считывание сообщения носит название извлечения по корреляционному идентификатору.
Используя этот же механизм, приложение может прибегнуть к извлечению по идентификаторам сообщений. Однако при работе с очередями, которые содержат множество сообщений, такое поведение менее эффективно, чем извлечение по корреляционному идентификатору, и при обычных условиях, как правило, не используется. Одна из целей извлечения по идентификаторам сообщений – решение таких задач администрирования системы, как извлечение с удалением или просмотр конкретного сообщения.
Структура MQGMO определяет, должно ли приложение ждать появления в очереди отвечающих его критериям сообщений, извлекая их по прибытии в течение установленного периода. При этом приложение может отказаться от ожидания, ждать неопределенно долгое время или до истечения заданного в миллисекундах периода ожидания. Ожидать прибытия сообщений в одну общую очередь могут сразу несколько приложений. В этом случае порядок извлечения сообщений из очереди не определен.
Вызывая функцию MQGET, приложение передает ей буфер и указывает его размер. Если сообщение слишком велико для размещения в буфере, приложение может использовать MQGMO, чтобы определить, как должен поступить менеджер: вернуть сообщение частично или сигнализировать об ошибке при вызове MQGET.
MQGMO определяет, должна ли функция MQGET выполняться под управлением точки синхронизации. Последнее означает, что вся работа по извлечению сообщения войдет в текущую единицу работы. Сообщение останется в очереди, но будет недоступно остальным приложениям для извлечения, пока не будет произведен вызов функции MQCMIT.
Примечание При написании приложений, которые извлекают постоянные сообщения с критичными для бизнеса данными по клиентским соединениям, рекомендуем вызывать функцию MQGET под управлением точки синхронизации, вслед за которой использовать вызов MQCMIT. Это защитит сообщение от потери при сбое в линии связи между приложением и менеджером, который может произойти во время передачи менеджером сообщения приложению по клиентскому подключению.
6.1.8. MQBEGIN
MQI-функция MQBEGIN применяется только в том случае, если менеджер очередей сообщений настроен так, чтобы координировать глобальные единицы работы, включающие операции в системе баз данных. При вызове функции MQBEGIN приложением в системе начинается новая единица работы, включающая обновления базы данных, корректно сконфигурированной для участия в координируемых WebSphere MQ единицах работы, и вызовы MQPUT/MQGET, производимые под управлением точки синхронизации.
Если координация единицы работы с участием WebSphere MQ осуществляется внешним менеджером транзакций, то для начала единицы работы приложению нужно обратиться к этому менеджеру.
Глобальные единицы работы мы обсуждали в разделе 4.5.5 "Глобальные единицы работы".
6.1.9. MQCMIT и MQBACK
MQI-функция MQCMIT предназначена для фиксации текущей единицы работы. Локальная единица работы, включающая только операции WebSphere MQ, содержит все вызовы функций MQPUT и MQGET под управлением точки синхронизации, произведенные с момента подключения приложения или последнего вызова MQCMIT или MQBACK. Глобальная единица работы, которая координируется WebSphere MQ и где содержатся операции в системе баз данных и WebSphere MQ, содержит все вызовы MQPUT и MQGET под управлением точки синхронизации с момента последнего обращения к MQBEGIN, MQCMIT или MQBACK.
MQI-функция MQBACK предназначена для отмены текущей единицы работы, которую образуют те же самые операции, что в случае с функцией MQCMIT. Отмена единицы работы аннулирует все операции, или производит откат. Изъятые с удалением сообщения возвращаются в очередь, а размещенные – удаляются из нее, так и не став доступными для других приложений.
6.1.10. MQINQ и MQSET
MQI-функция MQINQ служит для получения значений заданных атрибутов объектов, открытых в целях их запроса.
На вход функции MQINQ передается совокупность селекторов (selectors). Она содержит названия всех атрибутов, запрос значений которых осуществляется.
Для размещения значений, возвращаемых функцией, ей также передается ряд буферов, подразделяемых на буферы для хранения символьных (строковых) атрибутов, например описаний, и буферы для хранения числовых (целочисленных) атрибутов, таких как глубина очереди.
MQI-функция MQSET служит для установки значений заданных атрибутов объектов, открытых для их задания.
Входные параметры MQSET – набор селекторов и буферы с новыми значениями атрибутов.
6.1.11. MQDISC
Вызов функции MQDISC должен сопровождать каждый вызов MQCONN и MQCONNX со стороны приложения. Если приложение не смогло произвести обращение к MQDISC перед своим закрытием или было аварийно завершено, WebSphere MQ очищает соединение, обнаружив, что приложение больше не выполняется.
Если WebSphere MQ координирует локальные или глобальные единицы работы, при выполнении MQDISC менеджер предпринимает попытку вызова MQCMIT. Если вызов функции MQCMIT завершается неудачно, приложение уведомляется об этом кодом возврата функции MQDISC. Если перед своим закрытием приложение не выполнит MQDISC, менеджер очередей произведет вызов функции MQBACK, обнаружив, что приложение больше не выполняется.
6.2. Очереди
Понятие "очередь" (queue) встречается в терминологии WebSphere MQ довольно часто. Однако в разных контекстах оно имеет неодинаковые значения.
Объект-очередь.Объекты-очереди – объекты, определенные в составе менеджера очередей сообщений. При выполнении над менеджером функции MQOPEN могут определяться своим названием. Для описания и настройки служат MQSC или WebSphere MQ Explorer.
Объекты-очереди бывают нескольких типов. Они могут представлять саму очередь, содержащую сообщения, или метод поиска пункта назначения другой очереди в инфраструктуре WebSphere MQ.
Объекты-очереди всех типов могут отображаться MQSC, имея общий тип QUEUE. Подробнее каждый тип очереди мы рассмотрим ниже в этом разделе.
Очередь сообщений.Реально представлять очередь, которая входит в менеджер и может содержать сообщения, способен лишь один тип объекта – объект "локальная очередь" (local queue). Особый случай локальной очереди – транспортная очередь, которая служит промежуточной очередью, объединяющей менеджеры.
В составе менеджеров локальные очереди могут быть определены явно.
Кроме того, они могут быть определены динамически – на базе объектов модельных очередей (model queue) посредством вызова MQOPEN с названием модельной очереди в роли параметра. Обычно определенные динамически локальные очереди носят название динамических (dynamic queues). Они удаляются при вызове MQCLOSE. Временные динамические очереди могут автоматически удаляться менеджером очередей сообщений и при отключении приложения.
Известный локальному менеджеру кластерный экземпляр очереди.В большинстве случаев их называют кластерными очередями сообщений (cluster queues). Кластерная очередь – не настоящий объект-очередь под управлением локального менеджера, а локальное – по отношению к менеджеру – представление экземпляра объекта-очереди, существующего в любой точке кластера. Фактический объект-очередь может находиться под управлением локального менеджера, а может располагаться и на другом менеджере очередей в кластере. В составе менеджера с одним и тем же названием может существовать множество кластерных очередей сообщений. Подробнее кластеры менеджеров очередей и кластерные очереди сообщений мы обсудим в лекции 8 "Кластеры менеджеров очередей".
Примечание Все описанные ниже в этом разделе объекты-очереди имеют в кластере менеджеров специальное назначение и служат, в том числе, для того, чтобы соединить между собой кластеры менеджеров очередей сообщений или подключить кластер к инфраструктуре, где кластеры не используются.Заметим, что применение кластеров при создании новой инфраструктуры WebSphere MQ может устранить множество требований, которые предъявляются к этим типам объектов, а значит, упростить их администрирование. Подробнее о кластерах менеджеров очередей сообщений читайте в лекции 8 "Кластеры менеджеров очередей".
6.2.1. Разрешение названия очереди
При отправке сообщения из приложения местом назначения сообщения может являться очередь под управлением того же самого менеджера, к которому подключено приложение. Однако им может быть и другой менеджер очередей сообщений в инфраструктуре WebSphere MQ. Менеджер, к которому подключено приложение, должен знать, как направлять сообщения этому удаленному менеджеру. Больше того, в его составе должна быть очередь временного хранения сообщений, передаваемых к месту своего назначения, – транспортная очередь.
Между тем менеджером, к которому подключено приложение, и местом назначения сообщения может находиться несколько промежуточных менеджеров. Каждый менеджер на маршруте движения сообщения выбирает очередную целевую точку маршрута независимо от других. При этом он руководствуется своим собственным знанием инфраструктуры. Оно заключено в определенных на этом менеджере объектах WebSphere MQ и может быть дополнено знаниями, полученными от других менеджеров, входящих в этот же кластер.
Процесс определения очередного пункта доставки сообщения на маршруте по предоставленным приложением сведениям о месте назначения сообщения называется разрешением названия очереди (queue name resolution). Он производится менеджером очередей сообщений при каждом получении сообщения от приложения или другого менеджера.
Разрешение названия очереди выполняется и при каждом вызове MQOPEN для открытия очереди перед размещением сообщений. При этом, используя данные из структуры MQOD, переданной при вызове MQOPEN, – название объекта и название менеджера очередей объекта, – менеджер очередей сообщений пытается восстановить название нужной целевой очереди и менеджера для данного сообщения.
После разрешения названия очереди приложение может помещать в нее сообщения для отправки по установленному месту их назначения, используя вызовы MQPUT. В итоге при размещении сообщения менеджер совершает одно из перечисленных действий.
Если при разрешении названия оказалось, что очередь назначения локальна по отношению к данному менеджеру, то сообщение размещается непосредственно в ней.
Если при разрешении названия оказалось, что место назначения сообщения связано с другим – известным текущему – менеджером, то сообщение размещается в транспортной очереди для отправки этому известному менеджеру. Данный шаг требует включения в сообщение дополнительной информации, дабы при достижении им удаленного менеджера название очереди могло быть снова разрешено. Эту информацию называют заголовком транспортной очереди. О том, что происходит с сообщением после размещения в транспортной очереди, читайте в разделе 7.4.1 "Отправка сообщений".
Графическая схема разрешения названия приведена на рис 6.1. Все типы объектов-очередей, показанные на нем значками в прямоугольнике "Разрешение названия очереди", будут описаны нами в этой главе. Обратите внимание, что значки на рис 6.1 полностью соответствуют тем, что служат для представления объектов каждого типа в WebSphere MQ Explorer.
Объекты различных типов по-разному влияют на разрешение названия очереди. Иллюстрацией этого станут приведенные в следующих разделах аналогичные рисунки для объектов всех типов. На них будут продемонстрированы условия, в которых место назначения сообщения определяется тем, как именно объект конкретного типа описан в составе менеджера, к которому подключено приложение.
Примечание Влияние вхождения менеджера в кластер на разрешение названия очереди мы обсудим в разделе 8.1.7 "Совместный доступ к объектам-очередям в кластерах".
(рис 6.1) Разрешение названия очереди
6.2.2. Объекты локальных очередей и транспортные очереди
Объекты локальных очередей – единственный тип объектов-очередей, представляющих реальную очередь, содержащую сообщения. Объекты локальных очередей могут описываться вручную, – о чем мы расскажем в этом разделе, или быть созданы динамически – в соответствии с процедурой из раздела 6.2.4 "Объекты модельных очередей и динамическое создание локальных очередей сообщений".
Коль скоро содержать сообщения могут только объекты локальных очередей, их применение многогранно. В этой книге объекты локальных очередей – это чаще всего локальные очереди системы, поскольку именно ими в ней и представлена реальная очередь сообщений.
Простым примером применения локальной очереди является организация асинхронной коммуникации нескольких приложений на одной и той же машине. Используя одну локальную очередь, они могут размещать в ней сообщения и извлекать их оттуда.
Все остальные типы объектов-очередей могут рассматриваться как способы построения локальной очереди, разрешения названий и месторасположения локальных очередей либо маршрутизации сообщений между локальными очередями системы.
Рис 6.2 показывает, как приложение размещает сообщение в локальной очереди. Здесь разрешение названия очереди буквально переводит указанное название объекта в название локальной очереди при помощи описанного объекта локальной очереди системы.
(рис 6.2) Разрешение названия очереди в присутствии объекта локальной очередиТранспортные очереди
Атрибут USAGE объекта локальной очереди системы может использоваться, чтобы пометить локальную очередь как транспортную очередь. Для этого атрибут USAGE локальной очереди сообщений принимают равным XMITQ.
Если локальная очередь помечается как транспортная, приложения должны отказаться от попыток размещать в ней сообщения напрямую.
Передача сообщений из транспортной очереди удаленному менеджеру производится по каналу сообщений. Каналы сообщений мы обсудим в разделе 7.4.1 "Отправка сообщений".
Определение транспортной очереди обеспечивает менеджер очередей информацией, как именно направлять сообщения менеджеру целевой очереди. Все сообщения с тем же названием менеджера очередей объекта, что и название транспортной очереди, помещаются в эту очередь, так что названия транспортной очереди и удаленного менеджера должны – в общем случае – совпадать. Впрочем, если название менеджера не соответствует названию транспортной очереди, описанные в разделе 6.2.5 "Объекты удаленных очередей" объекты удаленных очередей позволяют задать маршрут явно.
Примечание Для передачи сообщений, являющихся ответом или отчетом, используется поле ReplyToQMgr дескриптора исходной дейтаграммы или запроса. Если менеджер очередей не знает, как направлять сообщения менеджеру очереди ответов, отправить ответ окажется невозможно.Чтобы менеджер очередей получил сведения о порядке маршрутизации, опишите одноименную менеджеру очереди ответов транспортную очередь.
Рис 6.3 показывает, как приложение отправляет сообщение и указывает название менеджера очередей объекта. С ним совпадает название транспортной очереди, а значит, именно в ней сообщение и будет размещено.
(рис 6.3) Разрешение названия очереди в присутствии транспортной очереди
Ручное задание локальных объектов
Принадлежащий локальной очереди атрибут "тип определения" ( DEFTYPE – definition type) дает возможность разделить все локальные очереди на те, которые описывались вручную, и те, что динамически сформированы из объектов модельных очередей. Атрибут "тип определения" ( DEFTYPE ) вручную созданных локальных очередей имеет значение PREDEFINED.
Примечание Атрибут "тип определения" ( DEFTYPE ) не проводит различий между локальными очередями, которые автоматически созданы WebSphere MQ при организации менеджера, и очередями, которые создал администратор.
Создать локальные очереди вручную можно, используя один из перечисленных методов.
При помощи MQSC-команды DEFINE QLOCAL.
При помощи WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Local Queue ;
следуйте указаниям мастера New Local Queue.
6.2.3. Объекты псевдонимов очередей
Объекты псевдонимов очередей являются представлениями других целевых объектов очередей, имеющих другие названия. Обращение к псевдониму очереди аналогично доступу к целевой очереди, чьим псевдонимом она является. Ссылки на псевдоним очереди переправляются целевой очереди, заданной как элемент описания псевдонима.
Атрибут "целевая (базовая) очередь" псевдонима ( TARGQ – target queue, base queue ) содержит имя целевого объекта-очереди.
Этот целевой объект-очередь должен иметь один из следующих типов.
Локальная очередь, заданная на том же менеджере очередей сообщений, что и псевдоним очереди.
Удаленная очередь, заданная на том же менеджере очередей сообщений, что и псевдоним очереди.
Экземпляр очереди, общий для того кластера менеджеров очередей сообщений, в который входит текущий менеджер. Обсуждению кластеров посвящена лекция 8 "Кластеры менеджеров очередей".
Примечание WebSphere MQ не требует, чтобы названию указанной при описании или модификации псевдонима целевой очереди соответствовал существующий объект-очередь. Если целевой объект-очередь некорректен, попытки вызова MQOPEN или маршрутизации сообщений через этот псевдоним закончатся неудачно.
Рис 6.4 показывает, как приложение размещает сообщение в локальной очереди через псевдоним очереди. Запрошенное приложением название объекта при разрешении указывает на целевой объект – локальную очередь, как это и вытекает из определения псевдонима.
(рис 6.4) Разрешение названия очереди в присутствии объекта псевдонима очереди со ссылкой на локальную очередьОписать псевдоним очереди можно, используя один из двух методов.
При помощи MQSC-команды DEFINE QALIAS.
При помощи WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Alias Queue ;
следуйте указаниям мастера New Alias Queue.
6.2.4. Объекты модельных очередей и динамическое создание локальных очередей сообщений
Объекты модельных очередей содержат атрибуты объектов – локальных очередей, которые могут создаваться приложением динамически. Очереди, которые построены динамически, являются экземплярами локальных очередей и могут содержать сообщения. В этой книге динамически созданный экземпляр локальной очереди сообщений обычно назван динамической очередью.
Задача динамической очереди – стать временным объектом для приложения в инфраструктуре очередей сообщений WebSphere MQ. Самым распространенным примером ее использования является организация собственной очереди ответов для приложения при обмене сообщениями по принципу "запрос – ответ". Об этом шла речь в разделе 4.6.14 "Реализация очереди ответов".
Приложение может динамически создать локальную очередь, просто указав имя объекта модельной очереди как название объекта в структуре M Q O D , передаваемой MQOPEN. Название созданной локальной очереди сообщений не связано с названием объекта модельной очереди.
Название динамической очереди выбирается приложением, вызвавшим MQOPEN. Для этого в MQOD входит поле "название динамической очереди" ( DynamicQName ).
В конце поля названия в составе MQOD можно указать символ маски. Он вынуждает менеджер очередей самостоятельно создать остальную часть ее имени. Это имя уникально в пределах менеджера. Для обеспечения уникальности всех 48 символов названия объекта-очереди размещать маску после 33-го символа в поле названия динамической очереди нельзя.
По умолчанию поле названия динамической очереди в MQOD принимает следующие значения.
В WebSphere MQ для z/OS:CSQ.*
В WebSphere MQ для всех прочих платформ:AMQ.*
После того как динамическая очередь создана, обращаться к ней можно так же, как и к локальной очереди, которая формировалась вручную. Приложения должны посылать такой очереди сообщения, используя ее динамически созданное название, а не название объекта модельной очереди.
Существует два разных типа динамических локальных очередей. Атрибут "тип определения" ( DEFTYPE ) объекта модельной очереди указывает, какого типа динамическая очередь создается, если открыть упомянутый модельный объект. Тип динамической очереди влияет на то, как ею можно будет воспользоваться и когда менеджер очередей ее удалит. Существующие типы задания перечислены ниже.
Динамический временный (TEMPDYN).Временная динамическая локальная очередь может содержать только непостоянные сообщения. Причина этого в том, что менеджер очередей сообщений может автоматически ее удалить. При этом не сохранится ни одно сообщение, которое в ней окажется. Временная динамическая локальная очередь удаляется менеджером при следующих условиях:
если приложение выполняет функцию MQCLOSE с описателем объекта ( Hobj ), полученного как результат вызова MQOPEN, создавшего эту очередь;
если приложение отключается от менеджера вызовом MQDISC;
после обнаружения менеджером закрытия приложения, если то завершилось без выполнения MQDISC;
при перезапуске менеджера.
Динамический постоянный (PERMDYN).Постоянная динамическая локальная очередь может содержать как постоянные, так и непостоянные сообщения. Такие очереди не удаляются менеджером очередей сообщений автоматически. Вручную постоянную динамическую локальную очередь можно удалить следующим образом:
вызовом MQCLOSE с опцией удаления ( MQCO_DELETE ) из приложения, не обязательно создавшего очередь изначально вызовом MQOPEN. Успешно вызов функции MQCLOSE завершится лишь при пустой очереди;
вызовом MQCLOSE с опцией удаления и очистки ( MQCO_DELETE_PURGE ) из приложения, не обязательно создавшего очередь изначально вызовом MQOPEN. Вызов функции MQCLOSE будет успешным даже при непустой очереди. Однако он завершится с ошибкой, если в составе очереди имеются сообщения, размещенные в ней или извлеченные из нее в рамках единицы работы, которая еще не зафиксирована, но и не аннулирована, – такие сообщения относят к незафиксированным;
удалением объекта-очереди из интерфейса администрирования, такого как WebSphere MQ Explorer или MQSC.
Для описания объектов модельных очередей используйте один из следующих методов:
Выполните MQSC-команду DEFINE QMODEL.
В WebSphere MQ Explorer:Щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
Выберите в меню New -> Model Queue ;
Следуйте указаниям мастера New Model Queue.
6.2.5. Объекты удаленных очередей
Объекты удаленных очередей служат для описания маршрутов к другим менеджерам очередей сообщений в инфраструктуре WebSphere MQ. В описание входит отображение названий менеджеров на транспортные очереди и названий очередей – на имена других различных очередей под управлением удаленных менеджеров очередей сообщений.
Для объектов удаленных очередей есть три способа применения.
Как локальное определение удаленной очереди сообщений.С его помощью приложение может открыть удаленный объект-очередь для того, чтобы помещать в эту очередь сообщения, явно не указывая название удаленного менеджера очередей, то есть аналогично тому, как оно помещает их в локальную очередь. В этом случае удаленным объектом-очередью можно воспользоваться затем, чтобы разместить очередь в составе удаленного менеджера, не внося изменений в приложение, созданное для работы с очередью локальной. Чтобы сформировать локальное определение удаленной очереди сообщений, создайте объект типа "удаленная очередь" с атрибутами, которые перечислены ниже.
Название объекта "удаленная очередь".Название очереди, в которую подключенные к менеджеру очередей приложения помещают свои сообщения.
Удаленное имя ( RNAME ).Название очереди, которой управляет целевой менеджер. Может полностью совпадать с названием объекта "удаленная очередь". Данное название очереди используется при разрешении названия очереди на удаленной машине.
Название удаленного менеджера очередей сообщений ( RQMNAME ).Название, которое имеет целевой менеджер, не обязательно являющийся очередным менеджером маршрута. Данное название менеджера используется при разрешении названия очереди на удаленной машине.
Транспортная очередь ( XMITQ ).Содержит название транспортной очереди, которая передает сообщения очередному менеджеру маршрута к месту их назначения. Если удаленный менеджер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться.
Рис 6.5 показывает, как приложение посылает сообщение, пользуясь локальным описанием очереди на удаленной машине. Название объекта, которое указано приложением, – это название объекта "удаленная очередь". При разрешении названия очереди сообщение будет размещено в заданной в описании удаленной очереди сообщений транспортной очереди. К сообщению при передаче будет прикреплен заголовок транспортной очереди с атрибутами, взятыми из описания объекта "удаленная очередь". Ими станут удаленное имя и название удаленного менеджера очередей сообщений. Когда сообщение достигнет места своего назначения, информация из заголовка транспортной очереди послужит для разрешения названия очереди в составе удаленного менеджера.
(рис 6.5) Разрешение названия очереди в присутствии локального определения удаленной очереди сообщений
Как псевдоним менеджера очередей сообщений.Служит для того, чтобы менеджер получил сведения о маршруте, ведущем к менеджеру целевой очереди. Применяется, если название менеджера целевой очереди отлично от названия используемой для направления сообщений этому менеджеру транспортной очереди. Также псевдонимы такого рода могут использоваться в целях отображения одного названия менеджера очередей на другое. Частным случаем этого является отображение на пустое название, которое обозначает локальный менеджер очередей или выступает как признак необходимости балансировки нагрузки при работе с кластером менеджеров.
Название объекта "удаленная очередь".Название менеджера очередей сообщений, для которого формируется псевдоним. В тех случаях, когда указанное название менеджера очередей объекта совпадает с названием объекта "удаленная очередь", он служит для разрешения названия.
Удаленное имя ( RNAME ).Применительно к псевдониму атрибут должен быть незаполнен.
Название удаленного менеджера очередей сообщений ( RQMNAME ).Название менеджера целевой очереди, не обязательно очередного менеджера маршрута. После направления сообщения очередному менеджеру маршрута с использованием указанной транспортной очереди данное название менеджера используется при разрешении названия. Может оставаться пустым для указания необходимости в разрешении названия очереди аналогично тому, как если бы название менеджера не было указано вовсе.
Транспортная очередь ( XMITQ ).Содержит название транспортной очереди, которая передает сообщения очередному менеджеру маршрута к месту их назначения. Если удаленный менеджер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться. Также он может не заполняться при описании псевдонима для локального менеджера.
Рис 6.6 показывает, как приложение посылает сообщение, используя псевдоним менеджера очередей сообщений. Название менеджера очередей объекта, которое указано приложением, преобразуется в другое название менеджера, для доставки которому сообщение будет размещено в транспортной очереди.
(рис 6.6) Разрешение названия очереди в присутствии псевдонима менеджера очередей сообщений
Как псевдоним очереди ответов.Псевдоним очереди ответов служит для настройки маршрутов, которыми ответы перемещаются к менеджеру по компонентам инфраструктуры. Влияет на название менеджера очереди ответов в дескрипторе сообщения при размещении сообщения приложением, но не на разрешение названия очереди при открытии таковой. Применение псевдонимов очереди ответов выходит за рамки книги. Подробнее об этом см. руководство WebSphere MQ Intercommunication, SC34-6587.
Для описания объектов удаленных очередей используйте один из следующих приемов.
MQSC-команду DEFINE QREMOTE.
В WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Remote Queue ;
следуйте указаниям мастера New Remote Queue.
6.2.6. Атрибуты по умолчанию и контроль полномочий
При открытии очереди WebSphere MQ производит проверку прав, определяя, уполномочена ли сущность выполнять действия, которые запросила. К обсуждению этой темы мы вернемся в разделе 11.2 "Предоставление доступа к ресурсам менеджеров очередей".
Также WebSphere MQ задает ряд значений по умолчанию для сообщений, которые впоследствии будут посланы открывшим очередь приложением. В дальнейшем приложение вправе заменить эти значения на свои собственные.
Такой контроль полномочий и значения по умолчанию основаны на атрибутах и разрешениях единственного объекта WebSphere MQ. Его можно считать первым среди объектов WebSphere MQ, к которым производится доступ при разрешении определенного приложением названия очереди.
Объект, который используется при отправлении сообщений, зависит от сочетания названий объекта и менеджера очередей объекта. Возможные комбинации показаны в табл. 6.1. В их число входят и сочетания для кластеров менеджеров очередей сообщений. Речь о таких кластерах пойдет в лекции 8 "Кластеры менеджеров очередей".
Объект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий
| Название объекта |
Название менеджера очередей объекта |
Объект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий |
|---|
| Название объекта – локальной, модельной, удаленной очереди или их псевдонима, определенное на локальном менеджере очередей сообщений |
Пусто или название локального менеджера |
Объект WebSphere MQ, имеющий заданное название |
| Любое |
Название удаленного менеджера, при разрешении которого может быть установлено название транспортной очереди |
Транспортная очередь |
| Название очереди, совместно используемой тем кластером менеджеров очередей сообщений, в который входит текущий менеджер |
Пусто |
Проверка наличия полномочий производится в отношении объектаSYSTEM.CLUSTER.TRANSMIT.QUEUE
Источником значений по умолчанию является определение объекта-очереди под управлением удаленного менеджера. Значения по умолчанию можно увидеть, отобразив атрибуты записи кластерной очереди, к примеру воспользовавшись командой DISPLAY QCLUSTER из состава MQSC |
Постоянство по умолчанию
Одним из часто используемых атрибутов объектов-очередей является атрибут постоянства по умолчанию ( DEFPSIST – default persistence). Установить, будет ли сообщение постоянным, приложение может при его размещении, задав параметр вызова MQPUT. Выбрав иной подход, приложение может оставить определение постоянства сообщений на откуп атрибуту соответствующей очереди.
Предположим, менеджер управляет локальной очередью local.psist с атрибутом DEFPSIST(YES). Пусть им же управляется псевдоним очереди alias.nonpsist с параметрами DEFPSIST(NO) и TARGQ('local.psist'). Сообщение, размещенное в очереди после открытия local.psist, окажется постоянным. Сообщение, размещенное после открытия alias.nonpsist, будет непостоянным. Между тем оба сообщения будут помещены в одну очередь.
Примечание Приведенная ситуация лишь пример, не являющийся рекомендуемой практикой. Наибольшую эффективность WebSphere MQ демонстрирует при условии, что в очереди содержатся исключительно постоянные или непостоянные сообщения.
6.2.7. Состояние и онлайновый мониторинг очередей
Локальные очереди – важнейший контролируемый менеджером ресурс, поскольку именно в них находятся все сообщения, которые он содержит.
Наблюдая за действиями обращающихся к менеджеру очередей приложений или выявляя проблемы, связанные с работой последних, администратор подчас испытывает потребность в сведениях о том, как происходит доступ приложений к конкретным очередям. Информация о потоке сообщений через определенную очередь также может оказаться полезной в обнаружении и разрешении проблем или при контроле производительности в ходе распределения ресурсов.
Удовлетворяя эту потребность, WebSphere MQ предоставляет данные мониторинга о состоянии каждой располагающейся на менеджере локальной очереди сообщений. В совокупности эти сведения, значительно расширенные в WebSphere MQ V6.0, таковы.
Количество находящихся в очереди сообщений.
Количество приложений, открывших очередь для просмотра или извлечения сообщений.
Дата и время последнего извлечения приложением сообщения из очереди.
Количество приложений, открывших очередь для размещения сообщений.
Дата и время последнего размещения приложением сообщения в очереди.
Количество находящихся в очереди незафиксированных сообщений. Таковыми считаются сообщения, которые были помещены в очередь или извлечены из нее в рамках незавершенной единицы работы.
Сведения о каждом соединении с менеджером открывшего очередь приложения, включая:название приложения, которое установило соединение;
идентификатор процесса приложения;
контекст идентификационных данных, в котором выполняется приложение;
действия, для выполнения которых приложение открыло очередь: просмотр сообщений, извлечение, размещение или запрос;
если соединение с менеджером является удаленным и происходит по клиентскому подключению, то информация об указанном подключении;
признак активности; выполняет ли приложение работу с менеджером;
Информация о производительности использующих очередь приложений. В нее в том числе, входят:кратко- и долгосрочная оценка среднего времени, которое сообщение проводит до извлечения из очереди. дается в микросекундах, поскольку срок пребывания сообщения в очереди может быть очень мал;
наибольший срок пребывания в очереди еще не покинувшего ее сообщения в секундах. в очередях с быстрым потоком сообщений большое значение может указывать на проблему с обработкой одного из поставленных в очередь сообщений.
Примечание Полученная в ходе контроля очередей информация о производительности является новшеством WebSphere MQ V6.0 и называется информацией онлайнового мониторинга (online monitoring). Используя атрибут MONQ объекта-менеджера очередей сообщений, вы можете наблюдать за всеми очередями, которыми менеджер управляет; используя же атрибут MONQ очереди – за требуемым набором локальных очередей. Подробности см. в руководстве Monitoring WebSphere MQ, SC34-6593. Или нажмите клавишу F1 и выберите раздел Online Monitoring страницы свойств, предварительно выделив менеджер очередей сообщений в WebSphere MQ Explorer.
Чтобы просмотреть информацию о состоянии очередей, используйте один из двух методов.
MQSC-команду DISPLAY QSTATUS.
WebSphere MQ Explorer. Обычно этот способ просмотра самый удобный:щелкните по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
щелкните правой кнопкой мыши по интересующей вас локальной очереди таблицы, представленной на панели содержимого Queues ;
выберите пункт меню Status.
6.3. Применение триггеров
Поступающие в очереди сообщения представляют происходящие в системе события. В большинстве случаев эти сообщения требуют обработки.
Для автоматического запуска обработки менеджером очередей сообщений в WebSphere MQ предусмотрен механизм "триггеринга" (triggering). По характеру обработки ею может являться открытие канала передачи сообщений из транспортной очереди удаленному менеджеру или инициирование работы экземпляра приложения для того, чтобы произвести действие над одним или несколькими сообщениями (пакетом).
С учетом назначения очереди приходящее в нее сообщение может представлять или не представлять событие, которое требует обработки. Саму очередь можно настроить на порождение триггерных событий (trigger events), соответствующих тому, для каких целей она используется.
6.3.1. Порождение триггерных событий
На порождение триггерных событий очередь можно настроить различным образом.
Для каждого сообщения.Триггерное сообщение будет порождено для каждого поступающего в очередь сообщения. Для выбора такого режима триггеринга в локальной очереди сообщений задайте следующие параметры:
активируйте триггеры: TRIGGER ;
установите тип триггера "для каждого сообщения": TRIGTYPE(EVERY).
Для первого сообщения.Триггерное событие порождает первое сообщение, поступающее в очередь после того, как она опустеет. Обычно триггерное событие возникает, если для извлечения сообщений очередь открывается каким бы то ни было приложением. Однако если через указанный триггерный интервал приходит сообщение, а ни одно приложение не открыло очередь на извлечение, то возникнет новое триггерное событие. Для выбора такого режима работы триггеринга в локальной очереди сообщений задайте следующие параметры:
активируйте триггеры: TRIGGER ;
установите тип триггера "для первого сообщения": TRIGTYPE(FIRST) ;
установите являющийся атрибутом объекта-менеджера очередей сообщений триггерный интервал, равный необходимому вам значению в миллисекундах: TRIGINT(5000).
Для заданной глубины.Триггерное событие порождает то сообщение, при поступлении которого общее количество сообщений, находящихся в очереди, становится выше определенного порогового значения. Триггерное событие не возникает, если есть приложение, открывшее эту очередь для извлечения сообщений. Чтобы настроить этот механизм триггеринга, задайте следующие атрибуты локальной очереди:
активируйте триггеры: TRIGGER ;
установите тип триггера "для заданной глубины": TRIGTYPE(DEPTH) ;
установите требуемый порог глубины очереди: TRIGDPTH(10).
Примечание Для того чтобы триггерное событие произошло, должна быть выполнена совокупность условий. Если триггерное событие не возникает, как запланировано, рекомендуем поочередно проверить выполнение всех условий, что даст возможность установить причину вашей проблемы. Полностью условия перечислены в разделе "Starting WebSphere MQ applications using triggers" руководства WebSphere MQ Application Programming Guide, SC34-6595.
6.3.2. Очереди инициации и триггерные сообщения
Когда в системе происходит триггерное событие, в очередь инициации (initiation queue) помещается сообщение. Это сообщение называется триггерным сообщением (trigger message). Название очереди, в которой будет размещено триггерное сообщение, содержится в атрибуте "очередь инициации" ( INITQ ) объекта – локальной очереди сообщений.
Как очередь инициации может быть обозначена любая из локальных очередей. Для того чтобы назначить ей эту роль, особой настройки локальной очереди не нужно. Единственное условие – такая очередь сообщений не может являться транспортной очередью.
Любое триггерное сообщение содержит сведения о том действии, которое должно быть выполнено в ответ на триггерное событие, и включает следующую информацию.
Название очереди.Название той очереди, откуда событие было порождено.
Подробные данные о запускаемом приложении.Подробности запуска приложений зависят от конкретной платформы. Для описания таковых в WebSphere MQ имеются объекты типа PROCESS. Их атрибуты содержат достаточно информации для запуска конкретного приложения в операционной системе. Если в атрибуте PROCESS очереди, которая породила событие, содержится название существующего объекта PROCESS, то все его атрибуты будут размещены в триггерном сообщении.
Данные триггера.Специальные данные из атрибута "данные триггера" ( TRIGDATA ) очереди, породившей событие.
6.3.3. Триггерный монитор
Приложения, ожидающие поступления сообщений в помеченную как очередь инициации локальную очередь сообщений, называют триггерными мониторами (trigger monitor).
Триггерные мониторы в WebSphere MQ
В составе WebSphere MQ есть триггерные мониторы для каждой платформы. Их функция – поддержка базовых возможностей выполнения приложений согласно определению PROCESS при каждом возникновении триггерного события. Его детальное описание передается приложению при запуске.
Подробнее о триггерных мониторах в WebSphere MQ читайте раздел "Writing Web Sphere MQ applications" руководства WebSphere MQ Application Programming Guide, SC34-6595.
Инициатор распределенных каналов WebSphere MQ
Инициатор распределенных каналов WebSphere MQ – это процесс WebSphere MQ, по умолчанию автоматически запускаемый менеджером очередей сообщений. Это особый триггерный монитор, открывающий каналы сообщений с названиями, которые содержатся в атрибутах TRIGDATA транспортных очередей, настроенных на применение триггеров. Подробности см. в разделе 7.4.13 "Инициирование канала".
Примечание Не смешивайте инициатор каналов в этом разделе с инициатором каналов в WebSphere MQ для z/OS из раздела 5.3.10 "Инициатор каналов WebSphere MQ для z/OS".Открытие каналов сообщений в WebSphere MQ для z/OS и WebSphere MQ для iSeries реализуют программы-слушатели каналов.
Отдельные детали организации MQI-интерфейса не связаны ни с одним из таких объектно-ориентированных или стандартизованных интерфейсов прикладного программирования (API), как Java Message Service (JMS), непосредственно. Однако эти API основаны на базовых возможностях MQI-интерфейса. Поэтому понимание объектов, сообщений WebSphere MQ и MQI не становится бесполезным даже при обращении к инфраструктуре через стандартизованные API. В этой лекции мы обсудим следующие вопросы:
Интерфейс очередей сообщений
Очереди
Применение триггеров
6.1. Интерфейс очередей сообщений
Интерфейс очередей сообщений (MQI – Message Queue Interface) служит процедурным интерфейсом отправки и получения сообщений через WebSphere MQ. Поэтому напрямую он может использоваться только из процедурных языков программирования, например C. В то же время немало приложений из числа созданных для обращения к инфраструктуре очередей сообщений WebSphere MQ используют объектно-ориентированный язык, такой как C++ или Java. Впрочем, извлечь выгоду из использования стандартизованных интерфейсов отправки и получения сообщений WebSphere MQ, включая Java Message Service (JMS) или Extended Message Service (XMS), могут и приложения, написанные на процедурных и объектно-ориентированных языках одновременно.
Как бы то ни было, все эти API используют MQI как основу реализации, либо вызывая функции модулей, написанных на языке C, либо посылая по клиентскому подключению менеджеру очередей сообщений команды MQI-интерфейса. Поэтому знание самого MQI может оказаться чрезвычайно полезным при написании приложений, использующих API, и при анализе потока сообщений в инфраструктуре.
MQI-интерфейс содержит 13 функций, а также структуры и типы данных. Они реализуют доступ к функциям менеджера, связанным с отправкой и получением сообщений по принципу межточечного обмена, заданием структуры сообщений WebSphere MQ и обеспечением возможности запроса и изменения атрибутов важнейших типов объектов.
6.1.1. Дескриптор сообщения WebSphere MQ (MQMD)
Дескриптор сообщения WebSphere MQ (MQMD) связан с каждым из сообщений, находящихся в очереди под управлением менеджера. Это – структура, содержащая ряд полей с описанием сообщения. Размещая сообщение в очереди, приложение передает менеджеру его дескриптор отдельно от его тела. При чтении из очереди приложение получает от менеджера очередей MQMD и тело сообщения отдельно.
Следующий список содержит перечень часто используемых полей дескриптора сообщения.
Тип сообщения ( MsgType ).В WebSphere MQ сообщения могут помечаться как относящиеся к типам, перечисленным ниже.
Дейтаграмма ( datagram ) – не требует обязательного ответа, но может требовать формирования отчета.
Запрос ( request ) – требует обязательного ответа.
Ответ ( reply ) – выдается как отклик на сообщение-запрос.
Отчет ( report ) – строится при обработке сообщения.
Отчет ( Report ) и обратная связь ( Feedback ).Поле "отчет" выступает признаком требования отчета, формируемого при обработке сообщения менеджером очередей сообщений или приложением-получателем. Например, приложению может требоваться отчет менеджера-приемника об успешной доставке сообщения или от приложения-получателя – о его успешном обслуживании. При формировании отчета приложением или менеджером в поле обратной связи помещается код с указанием причины для его построения.
Очередь ответов ( ReplyToQ ).Приложение, выдающее сообщение-запрос или определяющее варианты построения отчета, задает в этом поле название очереди ответов. Приложение, формирующее ответ на этот запрос или отчет как отклик на дейтаграмму, помещает его в ту очередь, которая имеет такое название.
Менеджер очереди ответов ( ReplyToQMgr ).Содержит имя менеджера очередей, управляющего очередью ответов. WebSphere MQ автоматически помещает в это поле название того менеджера, в который сообщение помещается изначально. Приложение должно модифицировать это поле только в том случае, если его ответы или отчеты необходимо пересылать в очередь на другом менеджере.
Идентификатор сообщения ( MsgId ).Может быть определен приложением или сгенерирован менеджером. Выдается приложению-отправителю менеджером очередей сообщений и может использоваться при последующей обработке.
Созданный менеджером очередей сообщений идентификатор является неповторяющимся во всей инфраструктуре WebSphere MQ. Однако это зависит от всех без исключения менеджеров в ее составе, имеющих уникальные в пределах первых 12 символов имена.
Корреляционный идентификатор ( CorrelId ).Это поле может использоваться приложениями для связи двух сообщений или связи сообщения и приложения. Чаще всего служит для сопоставления ответа с запросом при обмене сообщениями по принципу "запрос – ответ". Приложение, которое обрабатывает запрос, копирует его идентификатор сообщения в поле корреляционного идентификатора формируемого ответа. Если же в одну очередь приходят ответы сразу на несколько сообщений-запросов или ответы на запросы нескольких приложений, то приложение сможет прочитать ответ, обратившись лишь к сообщениям с нужным корреляционным идентификатором.
Признак постоянного сообщения ( Persistence ).Это поле определяет, относится ли сообщение к категории постоянных, речь о которых велась в разделе 3.4.1 "Постоянные и непостоянные сообщения". Будучи не заданным приложением-отправителем явно, оно наследует значение признака постоянных сообщений той очереди, в которой размещено.
Приоритет ( Priority ).Сообщениям может назначаться приоритет от 0 до 9. При этом WebSphere MQ можно настроить так, чтобы сообщения с большим приоритетом передавались приложениям раньше тех сообщений, чей приоритет ниже.
Идентификатор набора кодовых символов (CCSID – CodedCharSetId ).CCSID задает набор символов, который отображает определенные символы в те или иные байты или наборы байтов. Для данных, именуемых строковыми и представляющих текст, WebSphere MQ может производить конверсию из одного набора символов в другой так, что одни и те же символы будут представлены одними и теми же данными в сообщении. Мы говорили об этом в разделе 4.3.2 "Преобразование данных". По умолчанию поле имеет значение CCSID менеджера, которому передано конкретное сообщение; последнее же чаще всего равно CCSID соответствующего компьютера.
Кодировка ( Encoding ).От платформы к платформе порядок байтов в числовых данных меняется. WebSphere MQ использует поле "кодировка" для указания того, как эти данные представляют числовые значения. Как в случае CCSID, над числовыми данными в WebSphere MQ допустимо преобразование информации. По умолчанию поле "кодировка" имеет значение типа кодировки машины, где сформировано сообщение.
Формат ( Format ).Поле "формат" определяет тип данных, передаваемых в сообщении. Оно может задавать тип данных сообщения в целом: строковый, числовой, двоичный. Кроме того, оно может определять тип структуры WebSphere MQ, которая, в свою очередь, может всего лишь являться первой в числе структур, образующих цепь структур сообщения. Каждая из структур этого рода способна включать в себя различные типы данных. По умолчанию поле "формат" соответствует двоичному типу, преобразования которого в WebSphere MQ запрещены.
Время ( PutTime ) и дата ( PutDate ) размещения в очереди.В этих полях дескриптора сообщения менеджер сохраняет время и дату, представляющие момент прибытия сообщения в очередь, где оно пребывает в настоящее время.
Срок жизни ( Expiry ).Сообщениям может назначаться период существования, помещаемый в это поле и измеряемый в десятых долях секунды. Если сообщение остается в инфраструктуре очередей WebSphere MQ дольше этого времени, оно становится устаревшим, недоступным для приложений и пригодным для удаления менеджером очередей сообщений. Устаревшие сообщения удаляются исключительно при попытке извлечения или просмотра их приложением. WebSphere MQ V6.0 содержит в своем составе задание контроля срока существования (expiry task), которое периодически просматривает все сообщения всех без исключения очередей и принудительно удаляет устаревшие сообщения.
MQMD содержит сведения о приложении, поместившем сообщение в очередь, и идентификаторе пользователя, от чьего имени это приложение выполнялось.
Также в MQMD входит информация, относящаяся к сообщениям, входящим в группы, или сегменты. О сообщениях такого рода мы говорили в разделе 4.6.7 "Сегментация сообщений".
6.1.2. Коды завершения и причины
Вызов любой из функций MQI-интерфейса завершается возвратом кода завершения ( CompCode ) и причины ( Reason ):
Код завершения.Может иметь одно из трех следующих значений:
MQCC_OK: обращение к функции успешно завершено.
MQCC_WARNING: функция выполнена частично. Подробности отражены в коде причины.
MQCC_FAILED: вызов функции неудачен.
Код причины.По завершении вызова любой функции она может вернуть один из многих кодов причины; какие-то из них представляют признаки сбоя, какие-то – частичное выполнение. Подробнее см. раздел "Reason" описания полей (Fields) конкретных вызываемых функций в руководстве WebSphere MQ Application Programming Reference, SC34-6596.
Код причины – целочисленное значение. Для получения символьного представления десятичного или шестнадцатеричного числового значения или числового значения из символьного представления используйте команду WebSphere MQ mqrc. В следующем примере для кода причины MQRC_NO_MSG_AVAILABLE будет выдана одинаковая информация:
mqrc MQRC_NO_MSG_AVAILABLE
mqrc 2033
mqrc 0x7F1
mqrc 0x000007f1
Подробности см. в разделе 12.1.2 "Коды причины".
6.1.3. MQCONN и MQCONNX
Для отправки сообщений через инфраструктуру очередей каждое приложение или поток должно установить соединение с менеджером. Им может являться локальный менеджер, размещенный на той же машине, что и приложение, или же удаленный менеджер на другой машине сети.
Программный выбор способа подключения приложения – связывание с локальным менеджером или клиентское соединение с удаленным – в MQI невозможен. В программах на языке C, использующих MQI напрямую, выбор производится подключением к приложению библиотек связывания или клиентских соединений. При пользовании другими API метод выбора подключения к менеджеру зависит от самого API и обсуждается в документации WebSphere MQ к данному интерфейсу.
В MQI-интерфейс входят две функции подключения к менеджеру очередей сообщений: MQCONN и MQCONNX. Единственное различие между ними заключается в том, что вызову функции MQCONNX можно передать дополнительные параметры, объединенные в структуру параметров подключения (MQCNO).
При вызове любой из двух функций установления соединения ей требуется название того менеджера, к которому должно быть подключено приложение. Если это название не указано, а приложение использует подключение путем связывания, предполагается применение менеджера очередей сообщений по умолчанию, как это описано в разделе 5.3.5 "Менеджер по умолчанию".
Приложение может установить соединение с менеджером только в том случае, если оно на это уполномочено. В основе авторизации приложений лежит контекст идентификационных данных (identity context). Для приложений, выполняющих связывание, этим контекстом служит идентификатор пользователя операционной системы, от чьего имени выполняется приложение. Он же может выступать в роли контекста идентификационных данных для клиентских соединений; кроме того, в последнем случае менеджер очередей может быть сконфигурирован так, чтобы предоставлять клиенту конкретный идентификатор пользователя, существующий на удаленной машине, где работает менеджер.
В случае успешного подключения приложению выдается описатель (handle) соединения ( Hconn ), который им должен передаваться всем будущим вызовам MQI.
6.1.4. MQOPEN и MQCLOSE
Функция MQI MQOPEN служит для обращения к заданному объекту в составе менеджера, с которым приложение установило соединение. Для каждого из объектов (например, очереди) доступ к которому необходим приложению, должен производиться отдельный вызов. Любой вызов функции MQOPEN должен сопровождаться соответствующим вызовом MQCLOSE.
Приложение передает MQOPEN дескриптор объекта (MQOD). Он описывает объект, который планирует открыть приложение, и содержит его название. При работе с очередями также может задаваться название менеджера очередей сообщений. Это позволяет приложению переслать конкретное сообщение конкретному менеджеру в системе, информацией о котором располагает локальный менеджер. Подробнее об этом см. раздел 6.2.1 "Разрешение названия очереди".
Также приложение передает этой функции параметры, определяющие род действий, которые нужно осуществить над объектом.
Основываясь на информации из дескриптора и контексте идентификационных данных приложения, менеджер выясняет, уполномочено ли данное приложение на выполнение запрошенного им действия над данным объектом. Если полномочия есть, приложению возвращается описатель объекта ( Hobj ), который при работе с этим объектом должен передаваться им будущим вызовам MQI.
Не все типы объектов доступны через MQI-интерфейс. Как правило, MQI служит для открытия объектов-очередей для размещения в них и изъятия сообщений. Типы объектов-очередей под управлением менеджеров и способы обращения к очередям удаленного менеджера мы обсудим в раздел 6.2 "Очереди".
При вызове MQOPEN приложение может запросить следующие возможные действия:
Запись ( Output ). Размещение в очереди сообщений функцией MQPUT. Доступно только для объектов-очередей.
Просмотр ( Browse ). Считывание из очереди сообщений функцией MQGET, при котором те сохраняют свою доступность для других приложений. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
Извлечение ( Input ). Считывание из очереди сообщений функцией MQGET, после которого сообщения не сохраняют свою доступность для других приложений. Может быть монопольным, что означает возможность открытия очереди для считывания лишь одним приложением одновременно. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
Запрос ( Inquire ). Возврат значений атрибутов объекта функцией MQINQ.
Установка ( Set ). Задание значений атрибутов объекта функцией MQSET.
6.1.5. MQPUT
MQI-функция MQPUT служит для размещения сообщений в очередях, открытых для записи.
Вызов функции MQPUT завершается постановкой сообщения в очередь того менеджера, к которому подключено приложение. Впрочем, объект, открытый функцией MQOPEN, может представлять очередь назначения под управлением другого, удаленного менеджера. В этом случае очередью, в которой будет размещено сообщение, станет транспортная очередь (transmission queue) локального менеджера.
Доставка сообщения менеджеру, которому оно предназначено, как и любому другому менеджеру на маршруте его движения, осуществляется по каналам. Каналы передачи сообщений мы обсудим в разделе 7.4 "Распределенные каналы сообщений".
При вызове функции MQPUT ей передается структура дескриптора сообщения (MQMD). Во время работы функции менеджер заполняет дескриптор данными, возвращая их приложению в той же самой структуре.
Примечание Если одна и та же структура MQMD служит для выполнения нескольких вызовов MQPUT, поля, которые сформировал менеджер, между вызовами должны быть обнулены. Очистки, в частности, требует идентификатор сообщения; иначе он будет полностью совпадать у всех сообщений, размещенных с помощью этой структуры MQMD.
Для указания того, как именно выполняется обращение к MQPUT, ей также передается структура параметров размещения сообщения (MQPMO), в которой приложению возвращается определенная информация.
Обычно MQPMO служит для указания на то, что обращение к MQPUT должно произойти под управлением точки синхронизации. Это значит, что вся работа по размещению сообщения войдет в текущую единицу работы, а сообщение будет недоступно остальным приложениям для считывания и передачи менеджеру-получателю сообщения, пока не будет произведен вызов функции MQCMIT.
6.1.6. MQPUT1
MQI-функция MQPUT1 вызывает MQOPEN, за ней – MQPUT и завершает свою работу вызовом MQCLOSE. Приложение же должно передать ей достаточно информации для выполнения всех трех действий.
MQPUT1 – удобный и эффективный механизм вызова при постановке в очередь единичного сообщения. Нередко он служит для размещения в очереди сообщения-ответа или отчета.
6.1.7. MQGET
MQI-функция MQGET предназначена для считывания сообщений из очередей, открытых для просмотра или для извлечения.
На вход функции MQGET передается структура дескриптора сообщения (MQMD). В ней менеджер очередей возвращает дескриптор успешно считанного сообщения.
Для указания того, как именно выполняется обращение к MQGET, ей также передается структура параметров извлечения сообщения (MQGMO), в которой приложению возвращается определенная информация.
Структура MQGMO определяет, должен ли вызов функции MQGET просмотреть сообщения, оставив таковые доступными для других приложений, или извлечь с удалением их из очереди.
Приложение могут не интересовать все сообщения очереди. Например, ему могут быть интересны только отчеты или ответы на дейтаграммы или запросы, выданные им самим. Для упрощения своей задачи приложение может указать на тот факт, что ему интересны лишь сообщения с конкретным корреляционным идентификатором, поместив этот идентификатор в структуру MQMD, передаваемую функции MQGET. При этом оно может управлять тем, производится ли сопоставление с корреляционным идентификатором из структуры MQMD, используя для этого параметры сопоставления (match options) в структуре MQGMO. Такое считывание сообщения носит название извлечения по корреляционному идентификатору.
Используя этот же механизм, приложение может прибегнуть к извлечению по идентификаторам сообщений. Однако при работе с очередями, которые содержат множество сообщений, такое поведение менее эффективно, чем извлечение по корреляционному идентификатору, и при обычных условиях, как правило, не используется. Одна из целей извлечения по идентификаторам сообщений – решение таких задач администрирования системы, как извлечение с удалением или просмотр конкретного сообщения.
Структура MQGMO определяет, должно ли приложение ждать появления в очереди отвечающих его критериям сообщений, извлекая их по прибытии в течение установленного периода. При этом приложение может отказаться от ожидания, ждать неопределенно долгое время или до истечения заданного в миллисекундах периода ожидания. Ожидать прибытия сообщений в одну общую очередь могут сразу несколько приложений. В этом случае порядок извлечения сообщений из очереди не определен.
Вызывая функцию MQGET, приложение передает ей буфер и указывает его размер. Если сообщение слишком велико для размещения в буфере, приложение может использовать MQGMO, чтобы определить, как должен поступить менеджер: вернуть сообщение частично или сигнализировать об ошибке при вызове MQGET.
MQGMO определяет, должна ли функция MQGET выполняться под управлением точки синхронизации. Последнее означает, что вся работа по извлечению сообщения войдет в текущую единицу работы. Сообщение останется в очереди, но будет недоступно остальным приложениям для извлечения, пока не будет произведен вызов функции MQCMIT.
Примечание При написании приложений, которые извлекают постоянные сообщения с критичными для бизнеса данными по клиентским соединениям, рекомендуем вызывать функцию MQGET под управлением точки синхронизации, вслед за которой использовать вызов MQCMIT. Это защитит сообщение от потери при сбое в линии связи между приложением и менеджером, который может произойти во время передачи менеджером сообщения приложению по клиентскому подключению.
6.1.8. MQBEGIN
MQI-функция MQBEGIN применяется только в том случае, если менеджер очередей сообщений настроен так, чтобы координировать глобальные единицы работы, включающие операции в системе баз данных. При вызове функции MQBEGIN приложением в системе начинается новая единица работы, включающая обновления базы данных, корректно сконфигурированной для участия в координируемых WebSphere MQ единицах работы, и вызовы MQPUT/MQGET, производимые под управлением точки синхронизации.
Если координация единицы работы с участием WebSphere MQ осуществляется внешним менеджером транзакций, то для начала единицы работы приложению нужно обратиться к этому менеджеру.
Глобальные единицы работы мы обсуждали в разделе 4.5.5 "Глобальные единицы работы".
6.1.9. MQCMIT и MQBACK
MQI-функция MQCMIT предназначена для фиксации текущей единицы работы. Локальная единица работы, включающая только операции WebSphere MQ, содержит все вызовы функций MQPUT и MQGET под управлением точки синхронизации, произведенные с момента подключения приложения или последнего вызова MQCMIT или MQBACK. Глобальная единица работы, которая координируется WebSphere MQ и где содержатся операции в системе баз данных и WebSphere MQ, содержит все вызовы MQPUT и MQGET под управлением точки синхронизации с момента последнего обращения к MQBEGIN, MQCMIT или MQBACK.
MQI-функция MQBACK предназначена для отмены текущей единицы работы, которую образуют те же самые операции, что в случае с функцией MQCMIT. Отмена единицы работы аннулирует все операции, или производит откат. Изъятые с удалением сообщения возвращаются в очередь, а размещенные – удаляются из нее, так и не став доступными для других приложений.
6.1.10. MQINQ и MQSET
MQI-функция MQINQ служит для получения значений заданных атрибутов объектов, открытых в целях их запроса.
На вход функции MQINQ передается совокупность селекторов (selectors). Она содержит названия всех атрибутов, запрос значений которых осуществляется.
Для размещения значений, возвращаемых функцией, ей также передается ряд буферов, подразделяемых на буферы для хранения символьных (строковых) атрибутов, например описаний, и буферы для хранения числовых (целочисленных) атрибутов, таких как глубина очереди.
MQI-функция MQSET служит для установки значений заданных атрибутов объектов, открытых для их задания.
Входные параметры MQSET – набор селекторов и буферы с новыми значениями атрибутов.
6.1.11. MQDISC
Вызов функции MQDISC должен сопровождать каждый вызов MQCONN и MQCONNX со стороны приложения. Если приложение не смогло произвести обращение к MQDISC перед своим закрытием или было аварийно завершено, WebSphere MQ очищает соединение, обнаружив, что приложение больше не выполняется.
Если WebSphere MQ координирует локальные или глобальные единицы работы, при выполнении MQDISC менеджер предпринимает попытку вызова MQCMIT. Если вызов функции MQCMIT завершается неудачно, приложение уведомляется об этом кодом возврата функции MQDISC. Если перед своим закрытием приложение не выполнит MQDISC, менеджер очередей произведет вызов функции MQBACK, обнаружив, что приложение больше не выполняется.
6.2. Очереди
Понятие "очередь" (queue) встречается в терминологии WebSphere MQ довольно часто. Однако в разных контекстах оно имеет неодинаковые значения.
Объект-очередь.Объекты-очереди – объекты, определенные в составе менеджера очередей сообщений. При выполнении над менеджером функции MQOPEN могут определяться своим названием. Для описания и настройки служат MQSC или WebSphere MQ Explorer.
Объекты-очереди бывают нескольких типов. Они могут представлять саму очередь, содержащую сообщения, или метод поиска пункта назначения другой очереди в инфраструктуре WebSphere MQ.
Объекты-очереди всех типов могут отображаться MQSC, имея общий тип QUEUE. Подробнее каждый тип очереди мы рассмотрим ниже в этом разделе.
Очередь сообщений.Реально представлять очередь, которая входит в менеджер и может содержать сообщения, способен лишь один тип объекта – объект "локальная очередь" (local queue). Особый случай локальной очереди – транспортная очередь, которая служит промежуточной очередью, объединяющей менеджеры.
В составе менеджеров локальные очереди могут быть определены явно.
Кроме того, они могут быть определены динамически – на базе объектов модельных очередей (model queue) посредством вызова MQOPEN с названием модельной очереди в роли параметра. Обычно определенные динамически локальные очереди носят название динамических (dynamic queues). Они удаляются при вызове MQCLOSE. Временные динамические очереди могут автоматически удаляться менеджером очередей сообщений и при отключении приложения.
Известный локальному менеджеру кластерный экземпляр очереди.В большинстве случаев их называют кластерными очередями сообщений (cluster queues). Кластерная очередь – не настоящий объект-очередь под управлением локального менеджера, а локальное – по отношению к менеджеру – представление экземпляра объекта-очереди, существующего в любой точке кластера. Фактический объект-очередь может находиться под управлением локального менеджера, а может располагаться и на другом менеджере очередей в кластере. В составе менеджера с одним и тем же названием может существовать множество кластерных очередей сообщений. Подробнее кластеры менеджеров очередей и кластерные очереди сообщений мы обсудим в лекции 8 "Кластеры менеджеров очередей".
Примечание Все описанные ниже в этом разделе объекты-очереди имеют в кластере менеджеров специальное назначение и служат, в том числе, для того, чтобы соединить между собой кластеры менеджеров очередей сообщений или подключить кластер к инфраструктуре, где кластеры не используются.Заметим, что применение кластеров при создании новой инфраструктуры WebSphere MQ может устранить множество требований, которые предъявляются к этим типам объектов, а значит, упростить их администрирование. Подробнее о кластерах менеджеров очередей сообщений читайте в лекции 8 "Кластеры менеджеров очередей".
6.2.1. Разрешение названия очереди
При отправке сообщения из приложения местом назначения сообщения может являться очередь под управлением того же самого менеджера, к которому подключено приложение. Однако им может быть и другой менеджер очередей сообщений в инфраструктуре WebSphere MQ. Менеджер, к которому подключено приложение, должен знать, как направлять сообщения этому удаленному менеджеру. Больше того, в его составе должна быть очередь временного хранения сообщений, передаваемых к месту своего назначения, – транспортная очередь.
Между тем менеджером, к которому подключено приложение, и местом назначения сообщения может находиться несколько промежуточных менеджеров. Каждый менеджер на маршруте движения сообщения выбирает очередную целевую точку маршрута независимо от других. При этом он руководствуется своим собственным знанием инфраструктуры. Оно заключено в определенных на этом менеджере объектах WebSphere MQ и может быть дополнено знаниями, полученными от других менеджеров, входящих в этот же кластер.
Процесс определения очередного пункта доставки сообщения на маршруте по предоставленным приложением сведениям о месте назначения сообщения называется разрешением названия очереди (queue name resolution). Он производится менеджером очередей сообщений при каждом получении сообщения от приложения или другого менеджера.
Разрешение названия очереди выполняется и при каждом вызове MQOPEN для открытия очереди перед размещением сообщений. При этом, используя данные из структуры MQOD, переданной при вызове MQOPEN, – название объекта и название менеджера очередей объекта, – менеджер очередей сообщений пытается восстановить название нужной целевой очереди и менеджера для данного сообщения.
После разрешения названия очереди приложение может помещать в нее сообщения для отправки по установленному месту их назначения, используя вызовы MQPUT. В итоге при размещении сообщения менеджер совершает одно из перечисленных действий.
Если при разрешении названия оказалось, что очередь назначения локальна по отношению к данному менеджеру, то сообщение размещается непосредственно в ней.
Если при разрешении названия оказалось, что место назначения сообщения связано с другим – известным текущему – менеджером, то сообщение размещается в транспортной очереди для отправки этому известному менеджеру. Данный шаг требует включения в сообщение дополнительной информации, дабы при достижении им удаленного менеджера название очереди могло быть снова разрешено. Эту информацию называют заголовком транспортной очереди. О том, что происходит с сообщением после размещения в транспортной очереди, читайте в разделе 7.4.1 "Отправка сообщений".
Графическая схема разрешения названия приведена на рис 6.1. Все типы объектов-очередей, показанные на нем значками в прямоугольнике "Разрешение названия очереди", будут описаны нами в этой главе. Обратите внимание, что значки на рис 6.1 полностью соответствуют тем, что служат для представления объектов каждого типа в WebSphere MQ Explorer.
Объекты различных типов по-разному влияют на разрешение названия очереди. Иллюстрацией этого станут приведенные в следующих разделах аналогичные рисунки для объектов всех типов. На них будут продемонстрированы условия, в которых место назначения сообщения определяется тем, как именно объект конкретного типа описан в составе менеджера, к которому подключено приложение.
Примечание Влияние вхождения менеджера в кластер на разрешение названия очереди мы обсудим в разделе 8.1.7 "Совместный доступ к объектам-очередям в кластерах".
(рис 6.1) Разрешение названия очереди
6.2.2. Объекты локальных очередей и транспортные очереди
Объекты локальных очередей – единственный тип объектов-очередей, представляющих реальную очередь, содержащую сообщения. Объекты локальных очередей могут описываться вручную, – о чем мы расскажем в этом разделе, или быть созданы динамически – в соответствии с процедурой из раздела 6.2.4 "Объекты модельных очередей и динамическое создание локальных очередей сообщений".
Коль скоро содержать сообщения могут только объекты локальных очередей, их применение многогранно. В этой книге объекты локальных очередей – это чаще всего локальные очереди системы, поскольку именно ими в ней и представлена реальная очередь сообщений.
Простым примером применения локальной очереди является организация асинхронной коммуникации нескольких приложений на одной и той же машине. Используя одну локальную очередь, они могут размещать в ней сообщения и извлекать их оттуда.
Все остальные типы объектов-очередей могут рассматриваться как способы построения локальной очереди, разрешения названий и месторасположения локальных очередей либо маршрутизации сообщений между локальными очередями системы.
Рис 6.2 показывает, как приложение размещает сообщение в локальной очереди. Здесь разрешение названия очереди буквально переводит указанное название объекта в название локальной очереди при помощи описанного объекта локальной очереди системы.
(рис 6.2) Разрешение названия очереди в присутствии объекта локальной очередиТранспортные очереди
Атрибут USAGE объекта локальной очереди системы может использоваться, чтобы пометить локальную очередь как транспортную очередь. Для этого атрибут USAGE локальной очереди сообщений принимают равным XMITQ.
Если локальная очередь помечается как транспортная, приложения должны отказаться от попыток размещать в ней сообщения напрямую.
Передача сообщений из транспортной очереди удаленному менеджеру производится по каналу сообщений. Каналы сообщений мы обсудим в разделе 7.4.1 "Отправка сообщений".
Определение транспортной очереди обеспечивает менеджер очередей информацией, как именно направлять сообщения менеджеру целевой очереди. Все сообщения с тем же названием менеджера очередей объекта, что и название транспортной очереди, помещаются в эту очередь, так что названия транспортной очереди и удаленного менеджера должны – в общем случае – совпадать. Впрочем, если название менеджера не соответствует названию транспортной очереди, описанные в разделе 6.2.5 "Объекты удаленных очередей" объекты удаленных очередей позволяют задать маршрут явно.
Примечание Для передачи сообщений, являющихся ответом или отчетом, используется поле ReplyToQMgr дескриптора исходной дейтаграммы или запроса. Если менеджер очередей не знает, как направлять сообщения менеджеру очереди ответов, отправить ответ окажется невозможно.Чтобы менеджер очередей получил сведения о порядке маршрутизации, опишите одноименную менеджеру очереди ответов транспортную очередь.
Рис 6.3 показывает, как приложение отправляет сообщение и указывает название менеджера очередей объекта. С ним совпадает название транспортной очереди, а значит, именно в ней сообщение и будет размещено.
(рис 6.3) Разрешение названия очереди в присутствии транспортной очереди
Ручное задание локальных объектов
Принадлежащий локальной очереди атрибут "тип определения" ( DEFTYPE – definition type) дает возможность разделить все локальные очереди на те, которые описывались вручную, и те, что динамически сформированы из объектов модельных очередей. Атрибут "тип определения" ( DEFTYPE ) вручную созданных локальных очередей имеет значение PREDEFINED.
Примечание Атрибут "тип определения" ( DEFTYPE ) не проводит различий между локальными очередями, которые автоматически созданы WebSphere MQ при организации менеджера, и очередями, которые создал администратор.
Создать локальные очереди вручную можно, используя один из перечисленных методов.
При помощи MQSC-команды DEFINE QLOCAL.
При помощи WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Local Queue ;
следуйте указаниям мастера New Local Queue.
6.2.3. Объекты псевдонимов очередей
Объекты псевдонимов очередей являются представлениями других целевых объектов очередей, имеющих другие названия. Обращение к псевдониму очереди аналогично доступу к целевой очереди, чьим псевдонимом она является. Ссылки на псевдоним очереди переправляются целевой очереди, заданной как элемент описания псевдонима.
Атрибут "целевая (базовая) очередь" псевдонима ( TARGQ – target queue, base queue ) содержит имя целевого объекта-очереди.
Этот целевой объект-очередь должен иметь один из следующих типов.
Локальная очередь, заданная на том же менеджере очередей сообщений, что и псевдоним очереди.
Удаленная очередь, заданная на том же менеджере очередей сообщений, что и псевдоним очереди.
Экземпляр очереди, общий для того кластера менеджеров очередей сообщений, в который входит текущий менеджер. Обсуждению кластеров посвящена лекция 8 "Кластеры менеджеров очередей".
Примечание WebSphere MQ не требует, чтобы названию указанной при описании или модификации псевдонима целевой очереди соответствовал существующий объект-очередь. Если целевой объект-очередь некорректен, попытки вызова MQOPEN или маршрутизации сообщений через этот псевдоним закончатся неудачно.
Рис 6.4 показывает, как приложение размещает сообщение в локальной очереди через псевдоним очереди. Запрошенное приложением название объекта при разрешении указывает на целевой объект – локальную очередь, как это и вытекает из определения псевдонима.
(рис 6.4) Разрешение названия очереди в присутствии объекта псевдонима очереди со ссылкой на локальную очередьОписать псевдоним очереди можно, используя один из двух методов.
При помощи MQSC-команды DEFINE QALIAS.
При помощи WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Alias Queue ;
следуйте указаниям мастера New Alias Queue.
6.2.4. Объекты модельных очередей и динамическое создание локальных очередей сообщений
Объекты модельных очередей содержат атрибуты объектов – локальных очередей, которые могут создаваться приложением динамически. Очереди, которые построены динамически, являются экземплярами локальных очередей и могут содержать сообщения. В этой книге динамически созданный экземпляр локальной очереди сообщений обычно назван динамической очередью.
Задача динамической очереди – стать временным объектом для приложения в инфраструктуре очередей сообщений WebSphere MQ. Самым распространенным примером ее использования является организация собственной очереди ответов для приложения при обмене сообщениями по принципу "запрос – ответ". Об этом шла речь в разделе 4.6.14 "Реализация очереди ответов".
Приложение может динамически создать локальную очередь, просто указав имя объекта модельной очереди как название объекта в структуре M Q O D , передаваемой MQOPEN. Название созданной локальной очереди сообщений не связано с названием объекта модельной очереди.
Название динамической очереди выбирается приложением, вызвавшим MQOPEN. Для этого в MQOD входит поле "название динамической очереди" ( DynamicQName ).
В конце поля названия в составе MQOD можно указать символ маски. Он вынуждает менеджер очередей самостоятельно создать остальную часть ее имени. Это имя уникально в пределах менеджера. Для обеспечения уникальности всех 48 символов названия объекта-очереди размещать маску после 33-го символа в поле названия динамической очереди нельзя.
По умолчанию поле названия динамической очереди в MQOD принимает следующие значения.
В WebSphere MQ для z/OS:CSQ.*
В WebSphere MQ для всех прочих платформ:AMQ.*
После того как динамическая очередь создана, обращаться к ней можно так же, как и к локальной очереди, которая формировалась вручную. Приложения должны посылать такой очереди сообщения, используя ее динамически созданное название, а не название объекта модельной очереди.
Существует два разных типа динамических локальных очередей. Атрибут "тип определения" ( DEFTYPE ) объекта модельной очереди указывает, какого типа динамическая очередь создается, если открыть упомянутый модельный объект. Тип динамической очереди влияет на то, как ею можно будет воспользоваться и когда менеджер очередей ее удалит. Существующие типы задания перечислены ниже.
Динамический временный (TEMPDYN).Временная динамическая локальная очередь может содержать только непостоянные сообщения. Причина этого в том, что менеджер очередей сообщений может автоматически ее удалить. При этом не сохранится ни одно сообщение, которое в ней окажется. Временная динамическая локальная очередь удаляется менеджером при следующих условиях:
если приложение выполняет функцию MQCLOSE с описателем объекта ( Hobj ), полученного как результат вызова MQOPEN, создавшего эту очередь;
если приложение отключается от менеджера вызовом MQDISC;
после обнаружения менеджером закрытия приложения, если то завершилось без выполнения MQDISC;
при перезапуске менеджера.
Динамический постоянный (PERMDYN).Постоянная динамическая локальная очередь может содержать как постоянные, так и непостоянные сообщения. Такие очереди не удаляются менеджером очередей сообщений автоматически. Вручную постоянную динамическую локальную очередь можно удалить следующим образом:
вызовом MQCLOSE с опцией удаления ( MQCO_DELETE ) из приложения, не обязательно создавшего очередь изначально вызовом MQOPEN. Успешно вызов функции MQCLOSE завершится лишь при пустой очереди;
вызовом MQCLOSE с опцией удаления и очистки ( MQCO_DELETE_PURGE ) из приложения, не обязательно создавшего очередь изначально вызовом MQOPEN. Вызов функции MQCLOSE будет успешным даже при непустой очереди. Однако он завершится с ошибкой, если в составе очереди имеются сообщения, размещенные в ней или извлеченные из нее в рамках единицы работы, которая еще не зафиксирована, но и не аннулирована, – такие сообщения относят к незафиксированным;
удалением объекта-очереди из интерфейса администрирования, такого как WebSphere MQ Explorer или MQSC.
Для описания объектов модельных очередей используйте один из следующих методов:
Выполните MQSC-команду DEFINE QMODEL.
В WebSphere MQ Explorer:Щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
Выберите в меню New -> Model Queue ;
Следуйте указаниям мастера New Model Queue.
6.2.5. Объекты удаленных очередей
Объекты удаленных очередей служат для описания маршрутов к другим менеджерам очередей сообщений в инфраструктуре WebSphere MQ. В описание входит отображение названий менеджеров на транспортные очереди и названий очередей – на имена других различных очередей под управлением удаленных менеджеров очередей сообщений.
Для объектов удаленных очередей есть три способа применения.
Как локальное определение удаленной очереди сообщений.С его помощью приложение может открыть удаленный объект-очередь для того, чтобы помещать в эту очередь сообщения, явно не указывая название удаленного менеджера очередей, то есть аналогично тому, как оно помещает их в локальную очередь. В этом случае удаленным объектом-очередью можно воспользоваться затем, чтобы разместить очередь в составе удаленного менеджера, не внося изменений в приложение, созданное для работы с очередью локальной. Чтобы сформировать локальное определение удаленной очереди сообщений, создайте объект типа "удаленная очередь" с атрибутами, которые перечислены ниже.
Название объекта "удаленная очередь".Название очереди, в которую подключенные к менеджеру очередей приложения помещают свои сообщения.
Удаленное имя ( RNAME ).Название очереди, которой управляет целевой менеджер. Может полностью совпадать с названием объекта "удаленная очередь". Данное название очереди используется при разрешении названия очереди на удаленной машине.
Название удаленного менеджера очередей сообщений ( RQMNAME ).Название, которое имеет целевой менеджер, не обязательно являющийся очередным менеджером маршрута. Данное название менеджера используется при разрешении названия очереди на удаленной машине.
Транспортная очередь ( XMITQ ).Содержит название транспортной очереди, которая передает сообщения очередному менеджеру маршрута к месту их назначения. Если удаленный менеджер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться.
Рис 6.5 показывает, как приложение посылает сообщение, пользуясь локальным описанием очереди на удаленной машине. Название объекта, которое указано приложением, – это название объекта "удаленная очередь". При разрешении названия очереди сообщение будет размещено в заданной в описании удаленной очереди сообщений транспортной очереди. К сообщению при передаче будет прикреплен заголовок транспортной очереди с атрибутами, взятыми из описания объекта "удаленная очередь". Ими станут удаленное имя и название удаленного менеджера очередей сообщений. Когда сообщение достигнет места своего назначения, информация из заголовка транспортной очереди послужит для разрешения названия очереди в составе удаленного менеджера.
(рис 6.5) Разрешение названия очереди в присутствии локального определения удаленной очереди сообщений
Как псевдоним менеджера очередей сообщений.Служит для того, чтобы менеджер получил сведения о маршруте, ведущем к менеджеру целевой очереди. Применяется, если название менеджера целевой очереди отлично от названия используемой для направления сообщений этому менеджеру транспортной очереди. Также псевдонимы такого рода могут использоваться в целях отображения одного названия менеджера очередей на другое. Частным случаем этого является отображение на пустое название, которое обозначает локальный менеджер очередей или выступает как признак необходимости балансировки нагрузки при работе с кластером менеджеров.
Название объекта "удаленная очередь".Название менеджера очередей сообщений, для которого формируется псевдоним. В тех случаях, когда указанное название менеджера очередей объекта совпадает с названием объекта "удаленная очередь", он служит для разрешения названия.
Удаленное имя ( RNAME ).Применительно к псевдониму атрибут должен быть незаполнен.
Название удаленного менеджера очередей сообщений ( RQMNAME ).Название менеджера целевой очереди, не обязательно очередного менеджера маршрута. После направления сообщения очередному менеджеру маршрута с использованием указанной транспортной очереди данное название менеджера используется при разрешении названия. Может оставаться пустым для указания необходимости в разрешении названия очереди аналогично тому, как если бы название менеджера не было указано вовсе.
Транспортная очередь ( XMITQ ).Содержит название транспортной очереди, которая передает сообщения очередному менеджеру маршрута к месту их назначения. Если удаленный менеджер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться. Также он может не заполняться при описании псевдонима для локального менеджера.
Рис 6.6 показывает, как приложение посылает сообщение, используя псевдоним менеджера очередей сообщений. Название менеджера очередей объекта, которое указано приложением, преобразуется в другое название менеджера, для доставки которому сообщение будет размещено в транспортной очереди.
(рис 6.6) Разрешение названия очереди в присутствии псевдонима менеджера очередей сообщений
Как псевдоним очереди ответов.Псевдоним очереди ответов служит для настройки маршрутов, которыми ответы перемещаются к менеджеру по компонентам инфраструктуры. Влияет на название менеджера очереди ответов в дескрипторе сообщения при размещении сообщения приложением, но не на разрешение названия очереди при открытии таковой. Применение псевдонимов очереди ответов выходит за рамки книги. Подробнее об этом см. руководство WebSphere MQ Intercommunication, SC34-6587.
Для описания объектов удаленных очередей используйте один из следующих приемов.
MQSC-команду DEFINE QREMOTE.
В WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Remote Queue ;
следуйте указаниям мастера New Remote Queue.
6.2.6. Атрибуты по умолчанию и контроль полномочий
При открытии очереди WebSphere MQ производит проверку прав, определяя, уполномочена ли сущность выполнять действия, которые запросила. К обсуждению этой темы мы вернемся в разделе 11.2 "Предоставление доступа к ресурсам менеджеров очередей".
Также WebSphere MQ задает ряд значений по умолчанию для сообщений, которые впоследствии будут посланы открывшим очередь приложением. В дальнейшем приложение вправе заменить эти значения на свои собственные.
Такой контроль полномочий и значения по умолчанию основаны на атрибутах и разрешениях единственного объекта WebSphere MQ. Его можно считать первым среди объектов WebSphere MQ, к которым производится доступ при разрешении определенного приложением названия очереди.
Объект, который используется при отправлении сообщений, зависит от сочетания названий объекта и менеджера очередей объекта. Возможные комбинации показаны в табл. 6.1. В их число входят и сочетания для кластеров менеджеров очередей сообщений. Речь о таких кластерах пойдет в лекции 8 "Кластеры менеджеров очередей".
Объект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий
| Название объекта |
Название менеджера очередей объекта |
Объект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий |
|---|
| Название объекта – локальной, модельной, удаленной очереди или их псевдонима, определенное на локальном менеджере очередей сообщений |
Пусто или название локального менеджера |
Объект WebSphere MQ, имеющий заданное название |
| Любое |
Название удаленного менеджера, при разрешении которого может быть установлено название транспортной очереди |
Транспортная очередь |
| Название очереди, совместно используемой тем кластером менеджеров очередей сообщений, в который входит текущий менеджер |
Пусто |
Проверка наличия полномочий производится в отношении объектаSYSTEM.CLUSTER.TRANSMIT.QUEUE
Источником значений по умолчанию является определение объекта-очереди под управлением удаленного менеджера. Значения по умолчанию можно увидеть, отобразив атрибуты записи кластерной очереди, к примеру воспользовавшись командой DISPLAY QCLUSTER из состава MQSC |
Постоянство по умолчанию
Одним из часто используемых атрибутов объектов-очередей является атрибут постоянства по умолчанию ( DEFPSIST – default persistence). Установить, будет ли сообщение постоянным, приложение может при его размещении, задав параметр вызова MQPUT. Выбрав иной подход, приложение может оставить определение постоянства сообщений на откуп атрибуту соответствующей очереди.
Предположим, менеджер управляет локальной очередью local.psist с атрибутом DEFPSIST(YES). Пусть им же управляется псевдоним очереди alias.nonpsist с параметрами DEFPSIST(NO) и TARGQ('local.psist'). Сообщение, размещенное в очереди после открытия local.psist, окажется постоянным. Сообщение, размещенное после открытия alias.nonpsist, будет непостоянным. Между тем оба сообщения будут помещены в одну очередь.
Примечание Приведенная ситуация лишь пример, не являющийся рекомендуемой практикой. Наибольшую эффективность WebSphere MQ демонстрирует при условии, что в очереди содержатся исключительно постоянные или непостоянные сообщения.
6.2.7. Состояние и онлайновый мониторинг очередей
Локальные очереди – важнейший контролируемый менеджером ресурс, поскольку именно в них находятся все сообщения, которые он содержит.
Наблюдая за действиями обращающихся к менеджеру очередей приложений или выявляя проблемы, связанные с работой последних, администратор подчас испытывает потребность в сведениях о том, как происходит доступ приложений к конкретным очередям. Информация о потоке сообщений через определенную очередь также может оказаться полезной в обнаружении и разрешении проблем или при контроле производительности в ходе распределения ресурсов.
Удовлетворяя эту потребность, WebSphere MQ предоставляет данные мониторинга о состоянии каждой располагающейся на менеджере локальной очереди сообщений. В совокупности эти сведения, значительно расширенные в WebSphere MQ V6.0, таковы.
Количество находящихся в очереди сообщений.
Количество приложений, открывших очередь для просмотра или извлечения сообщений.
Дата и время последнего извлечения приложением сообщения из очереди.
Количество приложений, открывших очередь для размещения сообщений.
Дата и время последнего размещения приложением сообщения в очереди.
Количество находящихся в очереди незафиксированных сообщений. Таковыми считаются сообщения, которые были помещены в очередь или извлечены из нее в рамках незавершенной единицы работы.
Сведения о каждом соединении с менеджером открывшего очередь приложения, включая:название приложения, которое установило соединение;
идентификатор процесса приложения;
контекст идентификационных данных, в котором выполняется приложение;
действия, для выполнения которых приложение открыло очередь: просмотр сообщений, извлечение, размещение или запрос;
если соединение с менеджером является удаленным и происходит по клиентскому подключению, то информация об указанном подключении;
признак активности; выполняет ли приложение работу с менеджером;
Информация о производительности использующих очередь приложений. В нее в том числе, входят:кратко- и долгосрочная оценка среднего времени, которое сообщение проводит до извлечения из очереди. дается в микросекундах, поскольку срок пребывания сообщения в очереди может быть очень мал;
наибольший срок пребывания в очереди еще не покинувшего ее сообщения в секундах. в очередях с быстрым потоком сообщений большое значение может указывать на проблему с обработкой одного из поставленных в очередь сообщений.
Примечание Полученная в ходе контроля очередей информация о производительности является новшеством WebSphere MQ V6.0 и называется информацией онлайнового мониторинга (online monitoring). Используя атрибут MONQ объекта-менеджера очередей сообщений, вы можете наблюдать за всеми очередями, которыми менеджер управляет; используя же атрибут MONQ очереди – за требуемым набором локальных очередей. Подробности см. в руководстве Monitoring WebSphere MQ, SC34-6593. Или нажмите клавишу F1 и выберите раздел Online Monitoring страницы свойств, предварительно выделив менеджер очередей сообщений в WebSphere MQ Explorer.
Чтобы просмотреть информацию о состоянии очередей, используйте один из двух методов.
MQSC-команду DISPLAY QSTATUS.
WebSphere MQ Explorer. Обычно этот способ просмотра самый удобный:щелкните по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
щелкните правой кнопкой мыши по интересующей вас локальной очереди таблицы, представленной на панели содержимого Queues ;
выберите пункт меню Status.
6.3. Применение триггеров
Поступающие в очереди сообщения представляют происходящие в системе события. В большинстве случаев эти сообщения требуют обработки.
Для автоматического запуска обработки менеджером очередей сообщений в WebSphere MQ предусмотрен механизм "триггеринга" (triggering). По характеру обработки ею может являться открытие канала передачи сообщений из транспортной очереди удаленному менеджеру или инициирование работы экземпляра приложения для того, чтобы произвести действие над одним или несколькими сообщениями (пакетом).
С учетом назначения очереди приходящее в нее сообщение может представлять или не представлять событие, которое требует обработки. Саму очередь можно настроить на порождение триггерных событий (trigger events), соответствующих тому, для каких целей она используется.
6.3.1. Порождение триггерных событий
На порождение триггерных событий очередь можно настроить различным образом.
Для каждого сообщения.Триггерное сообщение будет порождено для каждого поступающего в очередь сообщения. Для выбора такого режима триггеринга в локальной очереди сообщений задайте следующие параметры:
активируйте триггеры: TRIGGER ;
установите тип триггера "для каждого сообщения": TRIGTYPE(EVERY).
Для первого сообщения.Триггерное событие порождает первое сообщение, поступающее в очередь после того, как она опустеет. Обычно триггерное событие возникает, если для извлечения сообщений очередь открывается каким бы то ни было приложением. Однако если через указанный триггерный интервал приходит сообщение, а ни одно приложение не открыло очередь на извлечение, то возникнет новое триггерное событие. Для выбора такого режима работы триггеринга в локальной очереди сообщений задайте следующие параметры:
активируйте триггеры: TRIGGER ;
установите тип триггера "для первого сообщения": TRIGTYPE(FIRST) ;
установите являющийся атрибутом объекта-менеджера очередей сообщений триггерный интервал, равный необходимому вам значению в миллисекундах: TRIGINT(5000).
Для заданной глубины.Триггерное событие порождает то сообщение, при поступлении которого общее количество сообщений, находящихся в очереди, становится выше определенного порогового значения. Триггерное событие не возникает, если есть приложение, открывшее эту очередь для извлечения сообщений. Чтобы настроить этот механизм триггеринга, задайте следующие атрибуты локальной очереди:
активируйте триггеры: TRIGGER ;
установите тип триггера "для заданной глубины": TRIGTYPE(DEPTH) ;
установите требуемый порог глубины очереди: TRIGDPTH(10).
Примечание Для того чтобы триггерное событие произошло, должна быть выполнена совокупность условий. Если триггерное событие не возникает, как запланировано, рекомендуем поочередно проверить выполнение всех условий, что даст возможность установить причину вашей проблемы. Полностью условия перечислены в разделе "Starting WebSphere MQ applications using triggers" руководства WebSphere MQ Application Programming Guide, SC34-6595.
6.3.2. Очереди инициации и триггерные сообщения
Когда в системе происходит триггерное событие, в очередь инициации (initiation queue) помещается сообщение. Это сообщение называется триггерным сообщением (trigger message). Название очереди, в которой будет размещено триггерное сообщение, содержится в атрибуте "очередь инициации" ( INITQ ) объекта – локальной очереди сообщений.
Как очередь инициации может быть обозначена любая из локальных очередей. Для того чтобы назначить ей эту роль, особой настройки локальной очереди не нужно. Единственное условие – такая очередь сообщений не может являться транспортной очередью.
Любое триггерное сообщение содержит сведения о том действии, которое должно быть выполнено в ответ на триггерное событие, и включает следующую информацию.
Название очереди.Название той очереди, откуда событие было порождено.
Подробные данные о запускаемом приложении.Подробности запуска приложений зависят от конкретной платформы. Для описания таковых в WebSphere MQ имеются объекты типа PROCESS. Их атрибуты содержат достаточно информации для запуска конкретного приложения в операционной системе. Если в атрибуте PROCESS очереди, которая породила событие, содержится название существующего объекта PROCESS, то все его атрибуты будут размещены в триггерном сообщении.
Данные триггера.Специальные данные из атрибута "данные триггера" ( TRIGDATA ) очереди, породившей событие.
6.3.3. Триггерный монитор
Приложения, ожидающие поступления сообщений в помеченную как очередь инициации локальную очередь сообщений, называют триггерными мониторами (trigger monitor).
Триггерные мониторы в WebSphere MQ
В составе WebSphere MQ есть триггерные мониторы для каждой платформы. Их функция – поддержка базовых возможностей выполнения приложений согласно определению PROCESS при каждом возникновении триггерного события. Его детальное описание передается приложению при запуске.
Подробнее о триггерных мониторах в WebSphere MQ читайте раздел "Writing Web Sphere MQ applications" руководства WebSphere MQ Application Programming Guide, SC34-6595.
Инициатор распределенных каналов WebSphere MQ
Инициатор распределенных каналов WebSphere MQ – это процесс WebSphere MQ, по умолчанию автоматически запускаемый менеджером очередей сообщений. Это особый триггерный монитор, открывающий каналы сообщений с названиями, которые содержатся в атрибутах TRIGDATA транспортных очередей, настроенных на применение триггеров. Подробности см. в разделе 7.4.13 "Инициирование канала".
Примечание Не смешивайте инициатор каналов в этом разделе с инициатором каналов в WebSphere MQ для z/OS из раздела 5.3.10 "Инициатор каналов WebSphere MQ для z/OS".Открытие каналов сообщений в WebSphere MQ для z/OS и WebSphere MQ для iSeries реализуют программы-слушатели каналов.
