Компания IBM
Опубликован: 10.06.2008 | Доступ: свободный | Студентов: 733 / 55 | Оценка: 4.18 / 4.00 | Длительность: 26:27:00
Специальности: Системный архитектор
Лекция 6:

Технические основы организации очередей сообщений

< Лекция 5 || Лекция 6: 12345 || Лекция 7 >

6.1.3. MQCONN и MQCONNX

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

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

В MQI-интерфейс входят две функции подключения к менеджеру очередей сообщений: MQCONN и MQCONNX. Единственное различие между ними заключается в том, что вызову функции MQCONNX можно передать дополнительные параметры, объединенные в структуру параметров подключения (MQCNO).

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

Приложение может установить соединение с менеджером только в том случае, если оно на это уполномочено. В основе авторизации приложений лежит контекст идентификационных данных (identity context). Для приложений, выполняющих связывание, этим контекстом служит идентификатор пользователя операционной системы, от чьего имени выполняется приложение. Он же может выступать в роли контекста идентификационных данных для клиентских соединений; кроме того, в последнем случае менеджер очередей может быть сконфигурирован так, чтобы предоставлять клиенту конкретный идентификатор пользователя, существующий на удаленной машине, где работает менеджер.

В случае успешного подключения приложению выдается описатель (handle) соединения ( Hconn ), который им должен передаваться всем будущим вызовам MQI.

6.1.4. MQOPEN и MQCLOSE

Функция MQI MQOPEN служит для обращения к заданному объекту в составе менеджера, с которым приложение установило соединение. Для каждого из объектов (например, очереди) доступ к которому необходим приложению, должен производиться отдельный вызов. Любой вызов функции MQOPEN должен сопровождаться соответствующим вызовом MQCLOSE.

Приложение передает MQOPEN дескриптор объекта (MQOD). Он описывает объект, который планирует открыть приложение, и содержит его название. При работе с очередями также может задаваться название менеджера очередей сообщений. Это позволяет приложению переслать конкретное сообщение конкретному менеджеру в системе, информацией о котором располагает локальный менеджер. Подробнее об этом см. "Технические основы организации очередей сообщений" "Разрешение названия очереди".

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

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

Не все типы объектов доступны через MQI-интерфейс. Как правило, MQI служит для открытия объектов-очередей для размещения в них и изъятия сообщений. Типы объектов-очередей под управлением менеджеров и способы обращения к очередям удаленного менеджера мы обсудим в "Технические основы организации очередей сообщений" "Очереди".

При вызове MQOPEN приложение может запросить следующие возможные действия:

  • Запись ( Output ). Размещение в очереди сообщений функцией MQPUT. Доступно только для объектов-очередей.
  • Просмотр ( Browse ). Считывание из очереди сообщений функцией MQGET, при котором те сохраняют свою доступность для других приложений. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
  • Извлечение ( Input ). Считывание из очереди сообщений функцией MQGET, после которого сообщения не сохраняют свою доступность для других приложений. Может быть монопольным, что означает возможность открытия очереди для считывания лишь одним приложением одновременно. Доступно только для объектов-очередей под управлением того менеджера, к которому подключено приложение.
  • Запрос ( Inquire ). Возврат значений атрибутов объекта функцией MQINQ.
  • Установка ( Set ). Задание значений атрибутов объекта функцией MQSET.

6.1.5. MQPUT

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

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

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

При вызове функции 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. Это защитит сообщение от потери при сбое в линии связи между приложением и менеджером, который может произойти во время передачи менеджером сообщения приложению по клиентскому подключению.
< Лекция 5 || Лекция 6: 12345 || Лекция 7 >