В этой лекции мы обсудим следующие вопросы:
Каналы
Запуск и останов каналов
Клиентские каналы
Распределенные каналы сообщений
Автоопределение каналов
7.1. Каналы
Все сетевые взаимодействия в WebSphere MQ производятся по каналам (channels). Как и понятие "очередь", слово "канал" регулярно встречается в терминологии WebSphere MQ и в разных контекстах может иметь различное толкование. Возможные его значения таковы.
Установленное сетевое соединение двух менеджеров очередей сообщений или клиентского приложения и менеджера.После установки WebSphere MQ сетевого соединения, по которому могут передаваться сообщения или команды MQI-интерфейса, оно обозначается как канал.
Канал, который соединяет два менеджера очередей и по которому могут передаваться сообщения, называется каналом сообщений (message channel).
Канал, который соединяет клиентское приложение и менеджер очередей сообщений и по которому могут передаваться вызовы MQI, называют клиентским (client channel), или MQI-каналом (MQI-channel).
Канальный объект.Канальные объекты – это объекты, описанные в составе менеджера очередей сообщений. Каждый объект-канал имеет свое название и тип (channel type). Атрибуты канального объекта определяют, как именно происходит коммуникация. От них, к примеру, может зависеть необходимость аутентификации по SSL-протоколу (Secure Sockets Layer) при установлении канала.
Одни типы канальных объектов предназначены для задания порядка установления каналов сообщений для своего менеджера. Другие – служат для описания порядка установления каналов сообщений, ведущих к другим менеджерам очередей сообщений в инфраструктуре.
Одни типы канальных объектов позволяют присоединить менеджер очередей к кластеру. Как только необходимые для подключения канальные объекты описаны, каналы сообщений, направленные к другим менеджерам очередей в кластере и обратно, будут автоматически сформированы.
Другие типы каналов служат для описания прямого подключения приложений к менеджеру очередей по сети.
Канальный агент (MCA).Любой канал WebSphere MQ – это сетевая связь двух канальных агентов (MCA – message channel agent).
Любое соединение, как установленное, так и в процессе попытки установления, ведущее от менеджера очередей и обратно, контролируется канальным агентом. Соединение, установленное подключившимся к менеджеру очередей приложением, хотя и не исходит из менеджера, также выполняется средствами MCA.
7.1.1. Введение в клиентские каналы
Если для подключения к менеджеру используется клиентский канал, при каждом функциональном вызове WebSphere MQ со стороны приложения для связи с удаленным менеджером очередей сообщений вызывается агент MCA. Его реализует используемый для подключения к менеджеру API-интерфейс клиента.
Клиентский API может являться частью базового клиента WebSphere MQ. Однако он может быть и клиентом JMS (Java Message Service), поставляемым с WebSphere Application Server, или другим клиентом, например поставляемым в составе Extended Message Service (XMS).
Хотя команды, передаваемые клиентским каналом менеджеру, являются командами MQI, к клиентскому MCA может иметься объектно-ориентированный, например WebSphere MQ C++ или Java API, или стандартизованный интерфейс, такой как JMS или XMS API. Функциональные вызовы перечисленных интерфейсов, которые отсылают или принимают сообщения в инфраструктуре WebSphere MQ, на самом деле в MCA выполняют команды MQI-интерфейса.
7.1.2. Канальные агенты (MCA)
Агент MCA устанавливает канал с агентом-партнером под управлением менеджера очередей сообщений, используя слушатель, предоставленный этим менеджером.
Название обоих агентов и атрибуты обычно определяют заданные в составе менеджера объекты-каналы. Однако те приложения, где применяется клиентский канал, могут определять название и атрибуты своих MCA-агентов самостоятельно.
Для обеспечения возможности получения менеджером очередей сообщений соединения и запуска MCA, если в составе менеджера отсутствует канальный объект с соответствующим названием, возможно автоопределение канала. Объект-канал с соответствующим названием и типом в составе менеджера задается автоматически и остается после разрыва соединения канала. Автоопределение каналов мы обсудим в разделе 7.5 "Автоопределение каналов".
Чтобы канал был создан, два MCA-агента должны договориться (negotiate), или связаться (bind) между собой. Ряд действий на этапе "переговоров" агентов приведен в следующем списке.
Агент, который решает, принимать ли соединение, должен удостовериться, что канальный объект известен менеджеру очередей сообщений с соответствующим названием и типом, и лишь затем разрешить подключение удаленного MCA. Для создания такого объекта может использоваться автоопределение канала, описанное в разделе 7.5 "Автоопределение каналов". Атрибуты такого объекта влияют на процедуру "переговоров".
Канальные объекты могут блокироваться. Если, по меньшей мере, один объект заблокирован, канал не сможет начать работу. Описание способа блокировки канала см. в разделе 7.2.1 "Понятие состояния канала".
Согласно настройке каждого из агентов возможно квитирование соединения по SSL-протоколу. Агент, который принимает соединение, либо каждый из MCA предоставляет партнеру сертификат, который в процессе квитирования тот должен удостоверить. При этом любой агент можно настроить так, чтобы он принимал соединения исключительно от сущности, имеющей в подтвержденном сертификате определенное отличительное имя (distinguished name).
Далее для партнерского MCA будет установлен контекст идентификационных данных, что важнее всего для клиентских каналов, где этот контекст служит для подтверждения подлинности каждого MQI-вызова. Контекстом может являться идентификатор пользователя, от чьего имени выполняется клиентское приложение (или агент-партнер), или принудительно выбран конкретный пользовательский идентификатор, назначенный менеджером очередей сообщений на основе атрибута канала.
Ряд атрибутов канала должен быть согласован обоими MCA, что даст возможность найти значения, приемлемые для каждого. Примером подобного атрибута служит размер пакета, описанный в разделе 7.4.2 "Пакеты". Обычно атрибуты такого рода являются числовыми и принимают меньшее из значений, предложенных каждым из MCA.
На рис 7.1 процесс установления канала двумя агентами MCA сведен воедино.
(рис 7.1) Установление канала, соединяющего два менеджера или приложение с менеджером
7.2. Запуск и останов каналов
Запуск канала означает запуск агента для подключения к MCA удаленного менеджера и установление канала. Остановом канала называют прекращение коммуникации двух агентов, которые установили канал.
Клиентские каналы запущены, как только приложение подключено к менеджеру, и остаются активными до его отключения.
Для запуска и останова соединяющих менеджеры каналов сообщений могут использоваться команды MQSC START CHANNEL и STOP CHANNEL. Дополнительно они служат для блокировки канальных объектов и ее снятия, а значит, определяют, могут с их помощью запускаться каналы или нет.
Аналогичные функции доступны в WebSphere MQ Explorer. Выберите в навигаторе папку Channels менеджера очередей сообщений, щелкните правой кнопкой мыши по объекту-каналу и укажите пункт меню Start или Stop.
Команда запуска объекта-канала сообщений, который осуществляет связь одного менеджера с другим, приводит к переходу канала в активное состояние. При этом он начинает передавать сообщения из транспортной очереди одного менеджера очередям сообщений другого.
Впрочем, каналы сообщений также могут запускаться автоматически – при появлении сообщения в транспортной очереди, – для чего служит инициатор каналов (channel initiator). Каналы сообщений в кластере менеджеров автоматически запускаются менеджером с помощью инициатора каналов, если это необходимо.
Команда останова канала имеет две функции.
Остановить все каналы, связанные с канальным объектом, и дать возможность их перезапуска клиентскому приложению, модулю "переговоров" каналов или кластеру менеджеров, когда это необходимо.В MQSC это действие выполняется при помощи атрибута MODE(INACTIVE) команды STOP CHANNEL. В WebSphere MQ Explorer выберите из выпадающего списка New state окна Stop Channel значение Inactive.
Блокировать канальный объект, препятствуя установлению использующих его каналов, пока канал не будет разблокирован снова и вручную запущен командой запуска.В MQSC это действие выполняется при помощи атрибута MODE(STOPPED) команды STOP CHANNEL. В WebSphere MQ Explorer выберите из выпадающего списка New state окна Stop Channel значение Stopped.
7.2.1. Понятие состояния канала
Менеджер очередей сообщений содержит записи состояния, связанные с канальными объектами, о существовании которых ему известно. Таковыми являются канальные объекты, заданные на этом менеджере вручную, описанные в ходе автоопределения автоматически либо известные благодаря кластеру менеджеров.
Для тех типов каналов, которые могут принимать подключения от приложений или от других менеджеров, может существовать несколько записей состояния, связанных с одним канальным объектом. Причина этого в том, что, пользуясь таким канальным объектом, менеджер в состоянии принять несколько подключений.
Для доступа к записям состояния предназначена команда MQSC DISPLAY CHSTATUS. Важнейшим атрибутом записи состояния является атрибут STATUS, представляющий состояние канала в целом.
Примечание В WebSphere MQ Explorer можно отобразить все записи состояния, которые соответствуют объекту – распределенному каналу сообщений или клиентскому каналу. Для этого выделите в навигаторе папку Channels, подчиненную менеджеру очередей сообщений, щелкните правой кнопкой мыши по интересующему каналу и выберите в меню Status -> Current status.
Если для канального объекта не существует ни одной записи состояния, канал, который связан с таким объектом, считается неактивным, или находящимся в состоянии INACTIVE.
Атрибут STATUS записи состояния может принимать следующие значения.
RUNNING: работающий канал – канал, в котором "переговоры" MCA-агентов успешно завершены и по которому можно передавать сообщения или команды MQI-интерфейса.
STOPPED: связанный с записью состояния канальный объект блокирован. Это означает, что установленный с помощью канального объекта канал не станет работать, пока канал не окажется разблокирован. Состояние STOPPED можно вводить, вручную остановив канал MQSC-командой STOP CHANNEL или через интерфейс WebSphere MQ Explorer. Разблокировать канальный объект можно, воспользовавшись командой START CHANNEL в MQSC или WebSphere MQ Explorer. Для канальных объектов, которые устанавливают канал, такое действие означает запуск канала. Запись о состоянии STOPPED сохраняется и после перезапуска менеджера.
RETRYING: для каналов, производящих установку соединения, это признак того, что попытка осуществить запуск канала закончилась неудачно. Через определенные промежутки канал автоматически пытается установить соединение снова. Подобное поведение определяется атрибутами короткого интервала между попытками (SHORTTMR – short retry interval), счетчика "коротких" попыток (SHORTRTY – short retry count), длинного интервала между попытками (LONGTMR) и счетчика "длинных" попыток (LONGRTY), заданными для объекта-канала. После того как будет предпринято указанное число повторных попыток, канал перейдет в состояние STOPPED и должен быть запущен вручную. Запись о состоянии RETRYING сохраняется и после перезапуска менеджера.
STOPPING, STARTING, BINDING, REQUESTING, INITIALIZING: промежуточные состояния, в которые каналы могут переходить в процессе установления и закрытия соединения.
PAUSED: состояние относится к каналам сообщений, повторно предпринимающим попытку доставить сообщение. Оно будет описано нами в разделе 7.4.11 "Ошибки доставки сообщений".
7.2.2. Названия каналов
Названия каналов могут содержать до 20 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов ".", "/", "_", "%".
Длина названия канала значительно меньше предельной длины названия очереди на всех платформах, кроме WebSphere MQ для z/OS, равной 48 знакам. Для упрощения администрирования название канала должно адекватно отражать его назначение.
Если длина названий всех менеджеров очередей сообщений в системе не превышает 17 символов, для всех каналов в системе может использоваться такая схема именования:
TO.Менеджер_назначения
Такое соглашение об именах способно работать с распределенными и кластерными каналами сообщений. Его гибкость определяется тем, что к одному менеджеру очередей сообщений, используя одно название канала, может подключиться целый ряд менеджеров, тогда как каждый канал конкретного менеджера подключается лишь к одному менеджеру очередей назначения.
7.3. Клиентские каналы
Благодаря клиентским каналам приложения, которые не работают на той же самой машине, что и менеджер, могут подключаться к нему и выполнять те же действия с ним, как будто они подключены к данному менеджеру локально.
Кроме того, клиентские каналы могут использоваться для подключения приложений, работающих на той же самой машине, что менеджер очередей сообщений, с целью воспользоваться стабильностью, которую обеспечивают такие каналы. Подключение к менеджеру очередей сообщений, используя клиентский канал, гарантирует наивысшую изоляцию приложения от менеджера, работа которого с наименьшей вероятностью пострадает в том случае, если приложение даст сбой и повредит те ресурсы, к которым имеет доступ.
7.3.1. Функционирование каналов
Если приложение соединяется с менеджером, используя механизм подключения из выбранного для разработки API, то оно запускает MCA-агент интерфейса API клиента, обозначенный в этой книге термином клиентского MCA (client MCA).
Упомянутый MCA обеспечивает связь с менеджером очередей сообщений, используя клиентский канал и предоставленный менеджером объект-слушатель. Для установления соединения MCA вызывает MQI-функции работы с каналом MQCONN и MQCONNX.
Каждый дальнейший вызов функции для работы с очередью сообщений, пришедший от приложения, которое использует данный менеджер, адресуется MCA. Агент же обращается к менеджеру очередей сообщений по клиентскому подключению через MQI-интерфейс.
На своей стороне менеджер запускает агент серверного подключения (server connection MCA). Используя локальное соединение с менеджером, он выполняет направленные MCA клиента вызовы MQI
Атрибуты MCA серверного подключения могут быть получены из описанного в составе менеджера объекта-канала серверного подключения, а могут – автоматически задаваться в ходе автоопределения канала – процесса, описанного в разделе 7.5 "Автоопределение каналов".
7.3.2. Канальные объекты серверных подключений
Канальный объект серверного подключения описывает название канала, которым для подключения к менеджеру может пользоваться клиент, и атрибуты агента, который управляет соединением.
Чтобы задать канальные объекты серверных подключений, используйте один из двух методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(SVRCONN).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Server-connection Channel.
Одним из важных аспектов использования канальных объектов серверных подключений является контекст идентификационных данных, который используется агентом серверного подключения при выполнении команд MQI-интерфейса.
7.3.3. Замечания о безопасности
По умолчанию контекст идентификационных данных – это идентификатор пользователя, от чьего имени на удаленной машине выполняется приложение. Однако с передачей идентификаторов пользователей между машинами под управлением разных операционных систем связан ряд следующих сложностей.
Слушатель менеджера очередей сообщений прослушивает TCP/IP-порт машины, где располагается менеджер. Ограничить обращение к порту только машинами конкретной сети или связанных с нею сетей, которым разрешено подключение к менеджеру, может оказаться непросто. Одно из этих приложений может работать от имени администратора mqm локальной машины, а в результате получит право на подключение к удаленной машине с привилегиями доступа этой учетной записи.
В то время как количество подключающихся к менеджеру очередей приложений может быть чересчур велико, сами приложения могут работать на разных машинах под разными учетными записями. При этом для успешного подключения приложений к менеджеру очередей сообщений каждое имя пользователя необходимо определить и поддерживать на машине, где работает менеджер.
WebSphere MQ для Windows поддерживает более длинные идентификаторы пользователей, чем WebSphere MQ для UNIX. Если приложение Windows по клиентскому подключению соединяется с менеджером, работающим под UNIX, контекстом идентификационных данных данного приложения, как правило, делаются 12 переведенных в нижний регистр начальных знаков идентификатора пользователя. Для успешного подключения этот идентификатор нужно задать на UNIX-машине. Заметим, что длиннее 12 символов многие привычные в Windows идентификаторы, включая Administrator.
Отдельные клиентские MCA, такие как WebSphere MQ V5.3 Java или JMS MCA, не передают идентификатор пользователя агенту серверного подключения.
По этим причинам, как правило, мы советуем всем приложениям, которые подключаются по каналу с определенным названием, назначать общий контекст идентификационных данных, для чего служит имеющийся у объекта-канала серверного подключения атрибут "MCA-пользователь" ( MCAUSER – MCA user).
Примечание Используя MQSC в UNIX, значение атрибута MCAUSER важно заключать в апострофы. Причина этого – в чувствительности к регистру идентификаторов на UNIX-платформах. Тогда пример определения канала будет таким:DEFINE CHANNEL(PAYROLL.CLIENT) CHLTYPE(SVRCONN) MCAUSER('mqclient')
Для более надежного обеспечения того, что подключение к менеджеру могут производить только авторизованные приложения, подумайте, к примеру, о технологии сетевого экрана (firewall). Он позволит подключиться к портам машины, где работает менеджер, лишь определенным компьютерам.
Иной подход – защита канала серверного подключения при помощи SSL. Этот протокол может гарантировать то, что выполняющее подключение приложение имеет сертификат за подписью доверенного центра сертификации, срок действия которого не истек. Канал же серверного подключения можно настроить так, чтобы он принимал только соединения от объектов с определенными отличительными именами, указанными в предъявленном подключающимся приложением сертификате.
7.3.4. Настройка клиентского MCA для подключения к менеджеру
Приложение может задавать атрибуты клиентского MCA несколькими путями.
Например, атрибутами, которые понадобятся клиентскому MCA, являются название соединения, которым он будет пользоваться для подключения к менеджеру, и название канала, который он устанавливает.
Ряд применяемых приложением методов задания атрибутов характерен для конкретных API доступа к инфраструктуре очередей сообщений WebSphere MQ. Нередко эти атрибуты попросту называют настройками подключения.
Так, для задания настроек подключения клиентского MCA клиент, напрямую использующий MQI-интерфейс в коде на языке C, может воспользоваться передаваемой функции MQCONNX структурой MQCNO.
Программы на C и приложения на C++, которые подключаются к менеджеру очередей сообщений, могут для задания несложных настроек подключения агента использовать переменную окружения MQSERVER. Синтаксис переменной имеет вид:
CHANNEL.NAME/TCP/имя_хоста_или_IP-адрес(порт)
Приложения, написанные с использованием WebSphere MQ base Java API или Web Sphere MQ .NET API, могут задавать настройки подключения в свойствах класса MQEnvironment.
Приложения с использованием JMS API могут определять настройки подключения как параметры созданного в интерфейсе JMS Administration tool объекта MQConnection Factory.
7.3.5. Канальные объекты клиентских подключений
Реализуемые WebSphere MQ объекты-каналы клиентских подключений являются еще одним методом указания параметров подключения, включая такие более сложные атрибуты, как конфигурация SSL.
Чтобы задать канальные объекты клиентских подключений, используйте один из двух методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLNTCONN).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Client Connections конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Client-connection Channel.
Любой объект-канал клиентского подключения содержит как атрибут название менеджера (QMNAME – queue manager name). Клиентскому MCA он требуется для поиска подходящего канального объекта клиентского подключения, который может использоваться для подключения к менеджеру. Название менеджера, к которому надлежит подключиться, определяется приложением и может быть предварено "звездочкой" (*).
Пытаясь установить подключение, MCA клиента может задействовать множество определенных в составе менеджера объектов клиентских подключений. В итоге, если первичный менеджер окажется недоступен, приложение может подключиться ко вторичному (резервному) менеджеру.
Порядок определения названия менеджера очередей приложением зависит от применяемого API. Так, при работе через MQI-интерфейс название задается параметром QMgrName функции MQCONN или MQCONNX, а при использовании инструмента JMS Administration tool API для JMS – свойством QMANAGER объекта MQConnectionFactory.
Связь заданного приложением названия менеджера очередей сообщений с каналами клиентских подключений, которые используются клиентскими MCA для подключения к менеджеру, представлена в табл. 7.1.
| Выбранное приложением название менеджера очередей сообщений |
Описание порядка поиска соответствующих канальных объектов клиентских подключений |
|---|
| Пустое |
Соответствующими считаются объекты-каналы клиентских подключений с пустым названием менеджера. Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно формируется независимо от того, какое название менеджер имеет в действительности |
*название_менеджераПервый в выбранном приложением названии менеджера должен быть символ "звездочка" (*)
|
Соответствующими считаются только канальные объекты клиентских подключений с названием менеджера очередей сообщений "название_менеджера". Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно формируется независимо от того, какое название менеджер имеет в действительности. Этот механизм удобен для обеспечения резервного менеджера в том случае, если менеджер очередей с определенным названием недоступен для подключения |
название_менеджера |
Соответствующими считаются только канальные объекты клиентских подключений с названием менеджера очередей сообщений "название_менеджера". Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно сформируется лишь тогда, когда реальное название менеджера есть "название_менеджера" |
7.3.6. Таблица определений клиентских каналов (CCDT)
Описание каждого объекта-канала клиентского подключения добавляет новую запись в имеющийся у любого из менеджеров очередей сообщений файл – таблицу определений клиентских каналов (CCDT – client channel definition table).
Таблица CCDT не предназначена для чтения человеком, однако доступна для чтения множеством различных MCA клиентов в составе клиентских интерфейсов программирования (API).
Содержащий таблицу файл расположен следующим образом.
В WebSphere MQ для Windows:C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера\@ipcc\AMQCLCHL.TAB
В WebSphere MQ для UNIX:/var/mqm/qmgrs/название_менеджера/@ipcc/AMQCLCHL.TAB
В WebSphere MQ для iSeries:/QIBM/UserData/mqm/qmgrs/название_менеджера/ipcc
После того как набор канальных объектов клиентских подключений описан в составе менеджера – не обязательно того самого, к которому подключено приложение, – файл может быть скопирован в новое место для использования клиентским API.
К примеру, он может быть размещен в каталоге с организованным совместным сетевым доступом к нему всех машин, где выполняются приложения, подключенные к менеджеру.
Прежде чем приложение сможет установить подключение так, как было описано в табл. 7.1, API клиента нужно сконфигурировать, чтобы сообщить ему место расположения CCDT.
Сейчас использование CCDT поддерживают не все клиентские интерфейсы. Примеры интерфейсов, которые поддерживают таблицу CCDT, следующие:
Клиентские интерфейсы WebSphere MQ C API и WebSphere MQ C++ API.Расположение CCDT определяется переменными окружения MQCHLLIB и MQCHLTAB. MQCHLLIB содержит название каталога с таблицей CCDT, MQCHLTAB – название CCDT-файла.
Настройка Windows-клиента на той машине, где работает менеджер, в котором предварительно была создана таблица CCDT, имеет, например, вид:
MQCHLLIB=C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера\@ipcc MQCHLTAB=AMQCLCHL.TAB
Примечание Если переменные окружения MQCHLLIB и MQCHLTAB не установлены, по умолчанию местом поиска CCDT-файла являются:в среде Windows:C:\Program Files\IBM\WebSphere MQ\AMQCLCHL.TAB
в среде UNIX:/var/mqm/AMQCLCHL.TAB
Клиентский интерфейс WebSphere MQ V6.0 base Java API.Вторым параметром конструктора объекта MQQueueManager является объект – URL-ссылка.
Клиентский интерфейс WebSphere MQ V6.0 JMS API.URL-ссылка определяется в свойстве CCDTURL создаваемого при помощи инструмента JMS Administration tool объекта MQConnectionFactory.
7.4. Распределенные каналы сообщений
Распределенный канал сообщений – это канал, принимающий сообщения из конкретной транспортной очереди одного менеджера и передающий эти сообщения очередям другого заданного удаленного менеджера.
Распределенный канал сообщений должен быть вручную настроен для каждой описанной в составе менеджера транспортной очереди. Как сказано в разделе 6.2.1 "Разрешение названия очереди", менеджер размещает сообщение в транспортной очереди в результате разрешения названия очереди. По ходу разрешающей процедуры он добавляет в заголовок транспортной очереди сообщения достаточно информации для того, чтобы разрешение названия очереди произошло в тот момент, когда сообщение достигнет менеджера очередей назначения.
Примечание Издержки администрирования при описании распределенных каналов можно уменьшить, если использовать кластер менеджеров очередей сообщений.
7.4.1. Отправка сообщений
В состав любого распределенного канала сообщений входят два MCA, а значит, и два канальных объекта – по одному для каждого менеджера. В зависимости от типа описанного на менеджере объекта-канала сообщений каждый агент выполняет одну из следующих ролей.
MCA – отправитель.Открывает определенную атрибутами канального объекта транспортную очередь сообщений для монопольного извлечения. Сказанное означает, что никакие два канала не могут быть настроены так, чтобы забирать сообщения из одной транспортной очереди. MCA-отправитель извлекает сообщения из транспортной очереди и посылает их агенту-партнеру.
Примечание Это утверждение не касается кластерных каналов сообщений, которые коллективно пользуются единой транспортной очередью. Кластеры менеджеров очередей сообщений мы обсудим в лекции 8 "Кластеры менеджеров очередей".
MCA – получатель.Получает сообщения от MCA-отправителя. В процессе своей работы удаляет из каждого сообщения заголовок транспортной очереди и производит чтение содержимого. Открывает указанную в заголовке транспортной очереди очередь сообщений и помещает сообщение в эту очередь. Открытие очереди и размещение сообщения осуществляются с помощью стандартных вызовов MQI. Это означает, что разрешение названия очереди на менеджере аналогично тому, как если бы к нему подключилось непосредственно приложение, которое, руководствуясь деталями заголовка транспортной очереди, разместило бы сообщение в очереди самостоятельно. Если при разрешении названия на менеджере не удается установить допустимое место назначения сообщения, сообщение доставить нельзя. Об этом мы еще скажем в разделе 7.4.11 "Ошибки доставки сообщений".
Заголовок транспортной очереди создается при разрешении названия очереди на менеджере очередей сообщений, где выполняется MCA-отправитель, и служит для размещения сообщения в очереди под управлением того менеджера, где работает получатель. Заголовок содержит следующую информацию.
Название удаленной очереди.Название очереди назначения сообщения, полученное при выполнении на менеджере разрешающей процедуры. Пытаясь поместить сообщение в очередь удаленного менеджера, находящийся там агент указывает это название в структуре MQOD при открытии очереди.
Название удаленного менеджера.Название менеджера, управляющего очередью назначения сообщения. Также получается в ходе разрешающей процедуры и может не соответствовать названию того менеджера, которому доставляется сообщение, – такое возможно, например, в случае, если очередной менеджер-получатель не является местом назначения сообщения.
Дескриптор исходного сообщения.При добавлении заголовка транспортной очереди сообщение модифицируется. К началу тела прибавляется заголовок исходного сообщения, дескриптор же изменяется и описывает не данные сообщения, а заголовок транспортной очереди. Однако, когда сообщение поступает в очередь назначения, оно должно корректно отражать то, что было послано изначально, в том числе и дескриптор. Дескриптор исходного сообщения хранится в заголовке транспортной очереди и используется агентом при размещении сообщения с удаленным заголовком транспортной очереди на удаленном менеджере очередей сообщений.
Связь пары менеджеров очередей по каналу показана на рис 7.2.
(рис 7.2) Коммуникация двух менеджеров очередей сообщений с использованием агентов отправителя и получателя
7.4.2. Пакеты
Для надежного обеспечения однократной доставки сообщений и агент-отправитель, и агент-получатель должен иметь возможность гарантировать то, что сообщение не потеряется, не окажется отправлено дважды и будет успешно получено MCA-получателем.
С этой целью MCA-отправитель может использовать единицу работы, извлекая сообщения из очереди, а MCA-получатель – размещая их в очереди.
Примечание По умолчанию каналы сообщений не пользуются единицами работы для передачи непостоянных сообщений. Это означает, что сбои связи могут приводить к их потере. Такое стандартное поведение канала можно изменить, выбрав нормальную, а не высокую скорость передачи непостоянных сообщений (NPMSPEED – nonpersistent message speed) канальным объектом MCA-отправителя или MCA-получателя.
Чтобы обеспечить защиту от потери или двукратной доставки сообщений при сбоях коммуникации, эти две независимые единицы работы должны быть скоординированы обоими MCA. Для этого агенты должны "договориться" по сети о фиксации или откате обоими единицы работы, если связь оборвется.
Этот процесс требует дополнительного сетевого обмена, а потому обычно не производится для каждого передаваемого по каналу сообщения. Отдельные пересылаемые сообщения объединяются и образуют пакет (batch), в котором все сообщения либо фиксируются в приемных очередях, либо возвращаются в транспортную очередь как одно целое.
Предельное количество содержащихся в пакете сообщений называется размером пакета (batch size). Настроить это значение позволяют одноименные атрибуты ( BATCHSZ – batch size) канального объекта MCA-отправителя и MCA-получателя. Используемый размер пакета принимается равным меньшему из значений двух атрибутов.
Иногда для заполнения пакета в транспортной очереди бывает недостаточно сообщений. В этом случае в ожидании новых сообщений в транспортной очереди MCA-отправитель берет короткую паузу, фиксируя уже отосланные сообщения только по ее истечении. Количество миллисекунд ожидания до фиксации пакета сообщений MCA-отправителем определяется атрибутом пакетного интервала ( BATCHINT – batch interval). Его значением управляет канальный объект MCA-отправителя.
7.4.3. Неоднозначные каналы и порядковые номера сообщения
Если сетевой обмен был нарушен при подтверждении пакета двумя агентами MCA, такой канал может превратиться в неоднозначный (indoubt). Причина этого в том, что сообщение с запросом на подтверждение было отправлено, а ответ на него не получен. Отправившему запрос агенту неизвестно, действительно ли агент-партнер принял его запрос, а связь нарушилась уже во время ответа, или же сбой случился при отправке запроса.
Единица работы одного из каналов должна при этом оставаться в состоянии готовности (prepared) к фиксации или откату в зависимости от действий, предпринятых агентом-партнером. В целях автоматического разрешения неоднозначного состояния канала при его перезапуске оба агента поддерживают порядковые номера, связанные с количеством успешно переданных по каналу сообщений.
Неоднозначное состояние канала представлено значением YES атрибута INDOUBT его записи состояния.
Примечание Подробнее о неоднозначных каналах и ручных операциях, которые вы можете предпринять, если канал перешел в неоднозначное состояние и не способен автоматически его разрешить, читайте в руководстве WebSphere MQ Intercommunication, SC34-6587.
7.4.4. Интервалы разъединения
Оставлять канал связи открытым неопределенно долгое время может быть неразумно. Поэтому WebSphere MQ позволяет автоматически закрывать канал сообщений, если за указанный интервал по нему не передано ни единого сообщения.
Этот интервал времени задается в секундах, а для задания служит атрибут "интервал разъединения" ( DISCINT – disconnect interval) канального объекта MCA-отправителя. Для указания на то, что канал связи должен оставаться открытым сколь угодно долгое время, используется нулевое значение интервала.
7.4.5. Названия соединений
Для установления канала между агентами отправителя и получателя один из агентов MCA должен связаться с менеджером очередей – партнером, используя объект-слушатель того менеджера.
В зависимости от типа канального объекта с описанием MCA на каждом конце канала запуск последнего допустим с любой стороны подключения. Об этом мы еще скажем в разделе 7.4.10 "Допустимые пары объектов – распределенных каналов сообщений".
Атрибут "название соединения" ( CONNAME – connection name) объекта-канала определяет название TCP/IP-хоста или IP-адрес и порт слушателя партнерского менеджера очередей сообщений.
Названия соединений и слушатели обсуждались нами в разделе 5.3.8 "Сетевой доступ к менеджеру". Название соединения задается следующим образом:
Имя_хоста.или.IP-адрес(порт)
Если порт не указан, используется известный TCP/IP-порт WebSphere MQ с номером 1414.
Примечание При описании каналов через MQSC название соединения должно быть ограничено апострофами, например:DEFINE CHANNEL(TO.EXAMPLE.PAYROLL) CHLTYPE(SDR) +
XMITQ(EXAMPLE.PAYROLL) +
CONNAME('payroll.example.com(9001)')
7.4.6. Объекты receiver-каналов
Объект receiver-канала задается на менеджере для определения атрибутов MCA-получателя, которому другие менеджеры очередей могут посылать сообщения.
Объект receiver-канала нельзя использовать для инициирования канала.
Для описания объектов receiver-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(RCVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Receiver Channel.
7.4.7. Объекты requester-каналов
Объект requester-канала задается на менеджере для определения атрибутов MCA-получателя, которому другие менеджеры очередей могут посылать сообщения.
Объект requester-канала можно использовать для инициирования канала.
Для описания объектов requester-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(RQSTR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Requester Channel.
Обязательный атрибут – название соединения ( CONNAME ).
7.4.8. Объекты sender-каналов
Объект sender-канала задается на менеджере очередей сообщений для определения атрибутов MCA-отправителя, который из указанной транспортной очереди может посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один агент sender-канала или server-канала.
Объект sender-канала можно использовать для инициирования канала.
Для описания объектов sender-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(SDR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Sender Channel.
Обязательные атрибуты – название транспортной очереди ( XMITQ ) и название соединения ( CONNAME ).
7.4.9. Объекты server-каналов
Объект server-канала задается на менеджере очередей сообщений для определения атрибутов MCA-отправителя, который из указанной транспортной очереди может посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один агент sender-канала или server-канала.
Объект server-канала можно использовать для инициирования канала, если название соединения входит в определение объекта. Если название соединения задано, говорят, что объект server-канала определен полностью (fully qualified).
Для описания объектов server-каналов используйте один из двух методов.
Команду MQSC DEFINE CHANNEL CHLTYPE(SVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Server Channel.
Обязательный атрибут – название транспортной очереди ( XMITQ ).
Примечание Не смешивайте объекты server-каналов и описанные в разделе 7.3.2 канальные объекты серверных подключений.
7.4.10. Допустимые пары объектов – распределенных каналов сообщений
Агенты MCA, созданные из описанных канальных объектов, могут объединяться с образованием канала лишь в некоторых сочетаниях. Допустимые комбинации и порядок их применения мы рассмотрим в этом разделе лекции.
Каналы sender-receiver
Такой канал может инициироваться лишь со стороны отправителя.
Для подключения к одному объекту receiver-канала в составе менеджера можно использовать целый ряд объектов sender-каналов, описанных на различных менеджерах очередей сообщений.
Типичным является описание на менеджере единственного объекта – receiver-канала. Для связи с упомянутым менеджером все менеджеры в составе инфраструктуры располагают sender-каналом, имеющим то же имя, что и receiver-канал.
Каналы requester-server
Каналы такого рода могут инициироваться на стороне requester-канала или – опционально – на стороне server-канала, если в нем определено полностью название соединения.
Каналы requester-server не требуют, чтобы requester-канал, инициирующий соединение, находился в системе с конкретным именем соединения. Это позволяет описать множество одноименных requester-каналов в составе различных менеджеров, каждый из которых сможет запрашивать сообщения из единой транспортной очереди одного и того же удаленного менеджера. Впрочем, одновременно активным и извлекающим сообщения из транспортной очереди может являться только один канал, ведущий к requester-каналу.
Каналы requester-sender
Такой канал схож с каналом requester-server с полностью определенным объектом server-канала. Однако, после того как соединение было инициировано requester-каналом, связь разрывается и формируется снова sender-каналом с использованием хранящегося внутри него названия соединения.
Sender-каналу данное решение позволяет гарантировать, что он связан с requester-каналом под управлением конкретного менеджера.
Каналы server-receiver
Функционально эквивалентны паре sender-receiver. Соединение инициируется со стороны server-канала, а значит, server-канал должен иметь полностью определенное название соединения.
7.4.11. Ошибки доставки сообщений
Если MCA-получатель не может доставить сообщение в очередь, в отношении сообщения агент предпринимает ряд предсказуемых действий.
Доставка сообщения может дать сбой по следующим причинам.
Неудачное окончание разрешения названия очереди при попытке ее открытия. Как было сказано в разделе 7.4.1 "Отправка сообщений", названия очереди и менеджера очередей сообщений, которые служат для открытия очереди с целью размещения сообщения, содержатся в заголовке транспортной очереди. Процедуру разрешение названия и влияние на нее всех типов объектов-очередей мы обсудили в разделе 6.2.1 "Разрешение названия очереди".
Установленная при разрешении очередь, которая может являться локальной очередью менеджера очередей сообщений или транспортной очередью, представляющей следующий пункт назначения на маршруте к месту получения сообщения, уже содержит максимально допустимое количество сообщений.
Размещение сообщений в очереди блокировано.
Меры, предпринимаемые агентом, определяются атрибутами канального объекта агента и атрибутом "очередь недоставленных сообщений" ( DEADQ – dead letter queue) объекта-менеджера. Вкратце эти шаги таковы.
Поскольку в силу своей природы часть сбоев доставки – например, нахождение в очереди предельного количества сообщений – может не повторяться, MCA-получатель может попытаться разместить сообщение вновь. Количество повторных попыток размещения сообщения агентом определяется атрибутом "число попыток на сообщение" ( MRRTY – message retry) того объекта-канала, где описан MCA-получатель. Интервал между попытками определяется атрибутом "таймер попыток на сообщение" ( MRTMR – message retry timer) этого же канала.
Если атрибут "очередь недоставленных сообщений" ( DEADQ ) объекта-менеджера очередей задан, MCA-получатель попытается открыть очередь, имеющую указанное название. Если это ему удастся, к сообщению будет добавлен заголовок недоставленного сообщения ( MQDLH ), и оно будет размещено в этой очереди.Заголовок недоставленного сообщения содержит информацию об ошибке. В нее входят название очереди и менеджера очередей сообщений из заголовка транспортной очереди. Также в заголовок недоставленного сообщения входит и код причины, полученный при неудачной попытке открыть очередь для размещения сообщения. Такие коды причин мы обсуждали в разделе 6.2.1 "Коды завершения и причин".
Если для текущего менеджера очередь недоставленных сообщений не задана или не существует, действие зависит от факта, используются ли для передачи сообщений единицы работы. Как говорилось в разделе 7.4.2 "Пакеты", единицы работы задействуются при передаче постоянных сообщений; применительно же к непостоянным они используются лишь при задании нормальной (normal) скорости работы канала.
Если для доставки сообщений единицы работы не применяются, непостоянное сообщение аннулируется.
Если для доставки сообщений используются единицы работы, сообщение возвращается в транспортную очередь на стороне отправителя. Канал, как было сказано в разделе 7.2.1 "Понятие состояния канала", переходит в состояние RETRYING. При этом он пытается доставить сообщение снова – каждый раз при повторении перезапуска. Когда же заданное для канала количество повторных попыток будет исчерпано, он перейдет в состояние STOPPED, и перезапуск канала должен производиться вручную. Движение сообщений в канале будет прекращено, пока нельзя будет доставить сообщение, не будет указана очередь недоставленных сообщений для менеджера либо сообщение не будет вручную удалено из транспортной очереди.
Примечание Во избежание действий из шага 3 советуем вам описать очереди недоставленных сообщений для всех без исключения менеджеров.При создании любого менеджера формируется очередь SYSTEM.DEAD.LETTER. QUEUE. В дальнейшем менеджер можно настроить так, чтобы использовать ее как очередь недоставленных сообщений. Однако все очереди с префиксом SYSTEM. в WebSphere MQ Explorer полезно скрыть, а потому подобной настройки обычно рекомендуется избегать.
Убедитесь, что значение атрибута "предельная длина сообщения" очереди недоставленных сообщений достаточно велико и ни одно сообщение, попав в очередь, не будет усечено.
7.4.12. Работа с очередью недоставленных сообщений
После того как очередь недоставленных сообщений менеджера описана, задумаемся о направляемых в нее сообщениях. Чтобы гарантировать кратковременность нахождения в ней сообщений – а в это время они не могут обрабатываться приложениями системы, – нужны особые меры.
Выполнение действий над сообщениями, прибывшими в эту очередь, обычно называется обработкой очереди недоставленных сообщений.
Подходы к обработке данной очереди включают следующее.
Регулярный просмотр администратором.Прикрепляемый к сообщениям при постановке в эту очередь заголовок недоставленных сообщений имеет формат, трудно воспринимаемый человеком. По этой причине WebSphere MQ Explorer дает возможность вывода на экран отдельных полей, образующих заголовок, в удобочитаемом представлении. Для доступа к этой функции выполните следующие шаги:
выделите в навигаторе папку Queues менеджера очередей сообщений;
щелкните правой кнопкой мыши по очереди недоставленных сообщений на панели содержимого Queues ;
выберите в меню Browse Messages ;
щелкните правой кнопкой по сообщению из таблицы;
выберите в меню Properties ;
выберите раздел Dead-letter header.
Выполнение действия по триггеру, который срабатывает всегда, как только в очереди недоставленных сообщений появляются сообщения.Пример такого постоянного действия – выполнение несложного приложения, отсылающего электронное письмо администратору для того, чтобы тот смог сам просмотреть очередь. Подробнее о триггерах см. раздел 6.3 "Применение триггеров".
К разряду триггеров, которые можно использовать в данном случае, относятся:
триггеры типа FIRST с большим, определенным для менеджера триггерным интервалом. Они инициируют регулярное выполнение приложения, если в очереди недоставленных сообщений имеются сообщения;
триггеры типа EVERY. Они инициируют выполнение приложения всякий раз при поступлении в очередь нового сообщения.
Применение обработчика очереди недоставленных сообщений, входящего в WebSphere MQ.С учетом набора правил, настроенных при запуске обработчика, он может автоматически выполнять действия над сообщениями, прибывающими в очередь недоставленных сообщений. Для ознакомления с обработчиком очереди недоставленных сообщений из WebSphere MQ читайте руководство WebSphere MQ Intercommunication, SC34-6587.
Применение обработчика очереди недоставленных сообщений собственной разработки.Если правил из обработчика очереди недоставленных сообщений, входящего в WebSphere MQ, не хватает для выполнения особых требований клиента, допускается и создание специального приложения, которое будет обслуживать сообщения по мере их поступления в очередь.
7.4.13. Инициирование канала
Перезапуск каналов сообщений не производится WebSphere MQ автоматически, если каналы становятся неактивны по достижении интервала разъединения или при перезапуске менеджера.
Число каналов в составе менеджера может быть велико, и ручной запуск с использованием MQSC или WebSphere MQ Explorer в инфраструктуре взаимосвязанных менеджеров может оказаться неэффективным.
WebSphere MQ для платформ Windows и UNIX содержат процесс-инициатор каналов, автоматически запускающий их при поступлении сообщений в транспортные очереди.
Примечание Не смешивайте инициатор каналов в этом разделе книги с инициатором каналов WebSphere MQ для z/OS, описанным в разделе 5.3.10.Обязанности по запуску в WebSphere MQ для z/OS и WebSphere MQ для iSeries лежат на программах-слушателях каналов.
Инициатор каналов – это программа – триггерный монитор, которая считывает триггерные сообщения из очереди инициации каналов и запускает канал, указанный в данных каждого сообщения.
Инициатор каналов WebSphere MQ можно запустить по управляющей команде WebSphere MQ runmqchi. Впрочем, инициатор каналов по умолчанию предоставляется WebSphere MQ и автоматически запускается менеджером очередей сообщений.
Этот модуль инициатора каналов по умолчанию может быть заблокирован установкой параметра SCHINIT (start channel initiator) объекта-менеджера очередей в MANUAL.
Используемый по умолчанию инициатор каналов наблюдает за очередью неудачных попыток инициирования SYSTEM.CHANNEL.INITQ.
Настройка транспортной очереди с целью автоматического запуска канала-обработчика сообщений из этой очереди производится установкой следующих атрибутов.
Активируйте триггеры: TRIGGER.
Установите тип триггера "для первого сообщения": TRIGTYPE(FIRST).
Данные триггера – в значение названия канала: TRIGDATA('TO.remote.qmgr').
Очередь инициации – в SYSTEM.CHANNEL.INITQ: INITQ(SYSTEM.CHANNEL.INITQ).
7.5. Автоопределение каналов
Менеджер очередей сообщений можно настроить так, чтобы в ответ на запросы соединения от MCA канальные объекты создавались автоматически.
Чтобы разрешить автоопределение каналов менеджера очередей сообщений, установите атрибут "автоопределение каналов" ( CHAD – channel auto-definition) объекта-менеджера в значение ENABLED.
7.5.1. Автоопределение клиентских каналов
Если приложение пытается подключиться к менеджеру очередей сообщений, используя клиентский канал, но соответствующий объект-канал серверных подключений с требуемым названием в менеджере отсутствует, он создается автоматически.
После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты канального объекта серверных подключений основаны на атрибутах автоматически формируемого менеджером очередей сообщений канального объекта серверных подключений SYSTEM.AUTO.SVRCONN.
7.5.2. Автоопределение распределенных каналов сообщений
Если при попытке удаленного менеджера установить подключение, используя объект – sender-канала или полностью заданный объект – server-канала, соответствующий receiver-канал или requester-канал с требуемым названием на менеджере отсутствует, автоматически создается receiver-канал.
После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты объекта – receiver-канала основаны на атрибутах автоматически формируемого менеджером очередей сообщений объекта receiver-канала SYSTEM.AUTO.RCVR.
В этой лекции мы обсудим следующие вопросы:
Каналы
Запуск и останов каналов
Клиентские каналы
Распределенные каналы сообщений
Автоопределение каналов
7.1. Каналы
Все сетевые взаимодействия в WebSphere MQ производятся по каналам (channels). Как и понятие "очередь", слово "канал" регулярно встречается в терминологии WebSphere MQ и в разных контекстах может иметь различное толкование. Возможные его значения таковы.
Установленное сетевое соединение двух менеджеров очередей сообщений или клиентского приложения и менеджера.После установки WebSphere MQ сетевого соединения, по которому могут передаваться сообщения или команды MQI-интерфейса, оно обозначается как канал.
Канал, который соединяет два менеджера очередей и по которому могут передаваться сообщения, называется каналом сообщений (message channel).
Канал, который соединяет клиентское приложение и менеджер очередей сообщений и по которому могут передаваться вызовы MQI, называют клиентским (client channel), или MQI-каналом (MQI-channel).
Канальный объект.Канальные объекты – это объекты, описанные в составе менеджера очередей сообщений. Каждый объект-канал имеет свое название и тип (channel type). Атрибуты канального объекта определяют, как именно происходит коммуникация. От них, к примеру, может зависеть необходимость аутентификации по SSL-протоколу (Secure Sockets Layer) при установлении канала.
Одни типы канальных объектов предназначены для задания порядка установления каналов сообщений для своего менеджера. Другие – служат для описания порядка установления каналов сообщений, ведущих к другим менеджерам очередей сообщений в инфраструктуре.
Одни типы канальных объектов позволяют присоединить менеджер очередей к кластеру. Как только необходимые для подключения канальные объекты описаны, каналы сообщений, направленные к другим менеджерам очередей в кластере и обратно, будут автоматически сформированы.
Другие типы каналов служат для описания прямого подключения приложений к менеджеру очередей по сети.
Канальный агент (MCA).Любой канал WebSphere MQ – это сетевая связь двух канальных агентов (MCA – message channel agent).
Любое соединение, как установленное, так и в процессе попытки установления, ведущее от менеджера очередей и обратно, контролируется канальным агентом. Соединение, установленное подключившимся к менеджеру очередей приложением, хотя и не исходит из менеджера, также выполняется средствами MCA.
7.1.1. Введение в клиентские каналы
Если для подключения к менеджеру используется клиентский канал, при каждом функциональном вызове WebSphere MQ со стороны приложения для связи с удаленным менеджером очередей сообщений вызывается агент MCA. Его реализует используемый для подключения к менеджеру API-интерфейс клиента.
Клиентский API может являться частью базового клиента WebSphere MQ. Однако он может быть и клиентом JMS (Java Message Service), поставляемым с WebSphere Application Server, или другим клиентом, например поставляемым в составе Extended Message Service (XMS).
Хотя команды, передаваемые клиентским каналом менеджеру, являются командами MQI, к клиентскому MCA может иметься объектно-ориентированный, например WebSphere MQ C++ или Java API, или стандартизованный интерфейс, такой как JMS или XMS API. Функциональные вызовы перечисленных интерфейсов, которые отсылают или принимают сообщения в инфраструктуре WebSphere MQ, на самом деле в MCA выполняют команды MQI-интерфейса.
7.1.2. Канальные агенты (MCA)
Агент MCA устанавливает канал с агентом-партнером под управлением менеджера очередей сообщений, используя слушатель, предоставленный этим менеджером.
Название обоих агентов и атрибуты обычно определяют заданные в составе менеджера объекты-каналы. Однако те приложения, где применяется клиентский канал, могут определять название и атрибуты своих MCA-агентов самостоятельно.
Для обеспечения возможности получения менеджером очередей сообщений соединения и запуска MCA, если в составе менеджера отсутствует канальный объект с соответствующим названием, возможно автоопределение канала. Объект-канал с соответствующим названием и типом в составе менеджера задается автоматически и остается после разрыва соединения канала. Автоопределение каналов мы обсудим в разделе 7.5 "Автоопределение каналов".
Чтобы канал был создан, два MCA-агента должны договориться (negotiate), или связаться (bind) между собой. Ряд действий на этапе "переговоров" агентов приведен в следующем списке.
Агент, который решает, принимать ли соединение, должен удостовериться, что канальный объект известен менеджеру очередей сообщений с соответствующим названием и типом, и лишь затем разрешить подключение удаленного MCA. Для создания такого объекта может использоваться автоопределение канала, описанное в разделе 7.5 "Автоопределение каналов". Атрибуты такого объекта влияют на процедуру "переговоров".
Канальные объекты могут блокироваться. Если, по меньшей мере, один объект заблокирован, канал не сможет начать работу. Описание способа блокировки канала см. в разделе 7.2.1 "Понятие состояния канала".
Согласно настройке каждого из агентов возможно квитирование соединения по SSL-протоколу. Агент, который принимает соединение, либо каждый из MCA предоставляет партнеру сертификат, который в процессе квитирования тот должен удостоверить. При этом любой агент можно настроить так, чтобы он принимал соединения исключительно от сущности, имеющей в подтвержденном сертификате определенное отличительное имя (distinguished name).
Далее для партнерского MCA будет установлен контекст идентификационных данных, что важнее всего для клиентских каналов, где этот контекст служит для подтверждения подлинности каждого MQI-вызова. Контекстом может являться идентификатор пользователя, от чьего имени выполняется клиентское приложение (или агент-партнер), или принудительно выбран конкретный пользовательский идентификатор, назначенный менеджером очередей сообщений на основе атрибута канала.
Ряд атрибутов канала должен быть согласован обоими MCA, что даст возможность найти значения, приемлемые для каждого. Примером подобного атрибута служит размер пакета, описанный в разделе 7.4.2 "Пакеты". Обычно атрибуты такого рода являются числовыми и принимают меньшее из значений, предложенных каждым из MCA.
На рис 7.1 процесс установления канала двумя агентами MCA сведен воедино.
(рис 7.1) Установление канала, соединяющего два менеджера или приложение с менеджером
7.2. Запуск и останов каналов
Запуск канала означает запуск агента для подключения к MCA удаленного менеджера и установление канала. Остановом канала называют прекращение коммуникации двух агентов, которые установили канал.
Клиентские каналы запущены, как только приложение подключено к менеджеру, и остаются активными до его отключения.
Для запуска и останова соединяющих менеджеры каналов сообщений могут использоваться команды MQSC START CHANNEL и STOP CHANNEL. Дополнительно они служат для блокировки канальных объектов и ее снятия, а значит, определяют, могут с их помощью запускаться каналы или нет.
Аналогичные функции доступны в WebSphere MQ Explorer. Выберите в навигаторе папку Channels менеджера очередей сообщений, щелкните правой кнопкой мыши по объекту-каналу и укажите пункт меню Start или Stop.
Команда запуска объекта-канала сообщений, который осуществляет связь одного менеджера с другим, приводит к переходу канала в активное состояние. При этом он начинает передавать сообщения из транспортной очереди одного менеджера очередям сообщений другого.
Впрочем, каналы сообщений также могут запускаться автоматически – при появлении сообщения в транспортной очереди, – для чего служит инициатор каналов (channel initiator). Каналы сообщений в кластере менеджеров автоматически запускаются менеджером с помощью инициатора каналов, если это необходимо.
Команда останова канала имеет две функции.
Остановить все каналы, связанные с канальным объектом, и дать возможность их перезапуска клиентскому приложению, модулю "переговоров" каналов или кластеру менеджеров, когда это необходимо.В MQSC это действие выполняется при помощи атрибута MODE(INACTIVE) команды STOP CHANNEL. В WebSphere MQ Explorer выберите из выпадающего списка New state окна Stop Channel значение Inactive.
Блокировать канальный объект, препятствуя установлению использующих его каналов, пока канал не будет разблокирован снова и вручную запущен командой запуска.В MQSC это действие выполняется при помощи атрибута MODE(STOPPED) команды STOP CHANNEL. В WebSphere MQ Explorer выберите из выпадающего списка New state окна Stop Channel значение Stopped.
7.2.1. Понятие состояния канала
Менеджер очередей сообщений содержит записи состояния, связанные с канальными объектами, о существовании которых ему известно. Таковыми являются канальные объекты, заданные на этом менеджере вручную, описанные в ходе автоопределения автоматически либо известные благодаря кластеру менеджеров.
Для тех типов каналов, которые могут принимать подключения от приложений или от других менеджеров, может существовать несколько записей состояния, связанных с одним канальным объектом. Причина этого в том, что, пользуясь таким канальным объектом, менеджер в состоянии принять несколько подключений.
Для доступа к записям состояния предназначена команда MQSC DISPLAY CHSTATUS. Важнейшим атрибутом записи состояния является атрибут STATUS, представляющий состояние канала в целом.
Примечание В WebSphere MQ Explorer можно отобразить все записи состояния, которые соответствуют объекту – распределенному каналу сообщений или клиентскому каналу. Для этого выделите в навигаторе папку Channels, подчиненную менеджеру очередей сообщений, щелкните правой кнопкой мыши по интересующему каналу и выберите в меню Status -> Current status.
Если для канального объекта не существует ни одной записи состояния, канал, который связан с таким объектом, считается неактивным, или находящимся в состоянии INACTIVE.
Атрибут STATUS записи состояния может принимать следующие значения.
RUNNING: работающий канал – канал, в котором "переговоры" MCA-агентов успешно завершены и по которому можно передавать сообщения или команды MQI-интерфейса.
STOPPED: связанный с записью состояния канальный объект блокирован. Это означает, что установленный с помощью канального объекта канал не станет работать, пока канал не окажется разблокирован. Состояние STOPPED можно вводить, вручную остановив канал MQSC-командой STOP CHANNEL или через интерфейс WebSphere MQ Explorer. Разблокировать канальный объект можно, воспользовавшись командой START CHANNEL в MQSC или WebSphere MQ Explorer. Для канальных объектов, которые устанавливают канал, такое действие означает запуск канала. Запись о состоянии STOPPED сохраняется и после перезапуска менеджера.
RETRYING: для каналов, производящих установку соединения, это признак того, что попытка осуществить запуск канала закончилась неудачно. Через определенные промежутки канал автоматически пытается установить соединение снова. Подобное поведение определяется атрибутами короткого интервала между попытками (SHORTTMR – short retry interval), счетчика "коротких" попыток (SHORTRTY – short retry count), длинного интервала между попытками (LONGTMR) и счетчика "длинных" попыток (LONGRTY), заданными для объекта-канала. После того как будет предпринято указанное число повторных попыток, канал перейдет в состояние STOPPED и должен быть запущен вручную. Запись о состоянии RETRYING сохраняется и после перезапуска менеджера.
STOPPING, STARTING, BINDING, REQUESTING, INITIALIZING: промежуточные состояния, в которые каналы могут переходить в процессе установления и закрытия соединения.
PAUSED: состояние относится к каналам сообщений, повторно предпринимающим попытку доставить сообщение. Оно будет описано нами в разделе 7.4.11 "Ошибки доставки сообщений".
7.2.2. Названия каналов
Названия каналов могут содержать до 20 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов ".", "/", "_", "%".
Длина названия канала значительно меньше предельной длины названия очереди на всех платформах, кроме WebSphere MQ для z/OS, равной 48 знакам. Для упрощения администрирования название канала должно адекватно отражать его назначение.
Если длина названий всех менеджеров очередей сообщений в системе не превышает 17 символов, для всех каналов в системе может использоваться такая схема именования:
TO.Менеджер_назначения
Такое соглашение об именах способно работать с распределенными и кластерными каналами сообщений. Его гибкость определяется тем, что к одному менеджеру очередей сообщений, используя одно название канала, может подключиться целый ряд менеджеров, тогда как каждый канал конкретного менеджера подключается лишь к одному менеджеру очередей назначения.
7.3. Клиентские каналы
Благодаря клиентским каналам приложения, которые не работают на той же самой машине, что и менеджер, могут подключаться к нему и выполнять те же действия с ним, как будто они подключены к данному менеджеру локально.
Кроме того, клиентские каналы могут использоваться для подключения приложений, работающих на той же самой машине, что менеджер очередей сообщений, с целью воспользоваться стабильностью, которую обеспечивают такие каналы. Подключение к менеджеру очередей сообщений, используя клиентский канал, гарантирует наивысшую изоляцию приложения от менеджера, работа которого с наименьшей вероятностью пострадает в том случае, если приложение даст сбой и повредит те ресурсы, к которым имеет доступ.
7.3.1. Функционирование каналов
Если приложение соединяется с менеджером, используя механизм подключения из выбранного для разработки API, то оно запускает MCA-агент интерфейса API клиента, обозначенный в этой книге термином клиентского MCA (client MCA).
Упомянутый MCA обеспечивает связь с менеджером очередей сообщений, используя клиентский канал и предоставленный менеджером объект-слушатель. Для установления соединения MCA вызывает MQI-функции работы с каналом MQCONN и MQCONNX.
Каждый дальнейший вызов функции для работы с очередью сообщений, пришедший от приложения, которое использует данный менеджер, адресуется MCA. Агент же обращается к менеджеру очередей сообщений по клиентскому подключению через MQI-интерфейс.
На своей стороне менеджер запускает агент серверного подключения (server connection MCA). Используя локальное соединение с менеджером, он выполняет направленные MCA клиента вызовы MQI
Атрибуты MCA серверного подключения могут быть получены из описанного в составе менеджера объекта-канала серверного подключения, а могут – автоматически задаваться в ходе автоопределения канала – процесса, описанного в разделе 7.5 "Автоопределение каналов".
7.3.2. Канальные объекты серверных подключений
Канальный объект серверного подключения описывает название канала, которым для подключения к менеджеру может пользоваться клиент, и атрибуты агента, который управляет соединением.
Чтобы задать канальные объекты серверных подключений, используйте один из двух методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(SVRCONN).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Server-connection Channel.
Одним из важных аспектов использования канальных объектов серверных подключений является контекст идентификационных данных, который используется агентом серверного подключения при выполнении команд MQI-интерфейса.
7.3.3. Замечания о безопасности
По умолчанию контекст идентификационных данных – это идентификатор пользователя, от чьего имени на удаленной машине выполняется приложение. Однако с передачей идентификаторов пользователей между машинами под управлением разных операционных систем связан ряд следующих сложностей.
Слушатель менеджера очередей сообщений прослушивает TCP/IP-порт машины, где располагается менеджер. Ограничить обращение к порту только машинами конкретной сети или связанных с нею сетей, которым разрешено подключение к менеджеру, может оказаться непросто. Одно из этих приложений может работать от имени администратора mqm локальной машины, а в результате получит право на подключение к удаленной машине с привилегиями доступа этой учетной записи.
В то время как количество подключающихся к менеджеру очередей приложений может быть чересчур велико, сами приложения могут работать на разных машинах под разными учетными записями. При этом для успешного подключения приложений к менеджеру очередей сообщений каждое имя пользователя необходимо определить и поддерживать на машине, где работает менеджер.
WebSphere MQ для Windows поддерживает более длинные идентификаторы пользователей, чем WebSphere MQ для UNIX. Если приложение Windows по клиентскому подключению соединяется с менеджером, работающим под UNIX, контекстом идентификационных данных данного приложения, как правило, делаются 12 переведенных в нижний регистр начальных знаков идентификатора пользователя. Для успешного подключения этот идентификатор нужно задать на UNIX-машине. Заметим, что длиннее 12 символов многие привычные в Windows идентификаторы, включая Administrator.
Отдельные клиентские MCA, такие как WebSphere MQ V5.3 Java или JMS MCA, не передают идентификатор пользователя агенту серверного подключения.
По этим причинам, как правило, мы советуем всем приложениям, которые подключаются по каналу с определенным названием, назначать общий контекст идентификационных данных, для чего служит имеющийся у объекта-канала серверного подключения атрибут "MCA-пользователь" ( MCAUSER – MCA user).
Примечание Используя MQSC в UNIX, значение атрибута MCAUSER важно заключать в апострофы. Причина этого – в чувствительности к регистру идентификаторов на UNIX-платформах. Тогда пример определения канала будет таким:DEFINE CHANNEL(PAYROLL.CLIENT) CHLTYPE(SVRCONN) MCAUSER('mqclient')
Для более надежного обеспечения того, что подключение к менеджеру могут производить только авторизованные приложения, подумайте, к примеру, о технологии сетевого экрана (firewall). Он позволит подключиться к портам машины, где работает менеджер, лишь определенным компьютерам.
Иной подход – защита канала серверного подключения при помощи SSL. Этот протокол может гарантировать то, что выполняющее подключение приложение имеет сертификат за подписью доверенного центра сертификации, срок действия которого не истек. Канал же серверного подключения можно настроить так, чтобы он принимал только соединения от объектов с определенными отличительными именами, указанными в предъявленном подключающимся приложением сертификате.
7.3.4. Настройка клиентского MCA для подключения к менеджеру
Приложение может задавать атрибуты клиентского MCA несколькими путями.
Например, атрибутами, которые понадобятся клиентскому MCA, являются название соединения, которым он будет пользоваться для подключения к менеджеру, и название канала, который он устанавливает.
Ряд применяемых приложением методов задания атрибутов характерен для конкретных API доступа к инфраструктуре очередей сообщений WebSphere MQ. Нередко эти атрибуты попросту называют настройками подключения.
Так, для задания настроек подключения клиентского MCA клиент, напрямую использующий MQI-интерфейс в коде на языке C, может воспользоваться передаваемой функции MQCONNX структурой MQCNO.
Программы на C и приложения на C++, которые подключаются к менеджеру очередей сообщений, могут для задания несложных настроек подключения агента использовать переменную окружения MQSERVER. Синтаксис переменной имеет вид:
CHANNEL.NAME/TCP/имя_хоста_или_IP-адрес(порт)
Приложения, написанные с использованием WebSphere MQ base Java API или Web Sphere MQ .NET API, могут задавать настройки подключения в свойствах класса MQEnvironment.
Приложения с использованием JMS API могут определять настройки подключения как параметры созданного в интерфейсе JMS Administration tool объекта MQConnection Factory.
7.3.5. Канальные объекты клиентских подключений
Реализуемые WebSphere MQ объекты-каналы клиентских подключений являются еще одним методом указания параметров подключения, включая такие более сложные атрибуты, как конфигурация SSL.
Чтобы задать канальные объекты клиентских подключений, используйте один из двух методов.
MQSC-команду DEFINE CHANNEL CHLTYPE(CLNTCONN).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Client Connections конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Client-connection Channel.
Любой объект-канал клиентского подключения содержит как атрибут название менеджера (QMNAME – queue manager name). Клиентскому MCA он требуется для поиска подходящего канального объекта клиентского подключения, который может использоваться для подключения к менеджеру. Название менеджера, к которому надлежит подключиться, определяется приложением и может быть предварено "звездочкой" (*).
Пытаясь установить подключение, MCA клиента может задействовать множество определенных в составе менеджера объектов клиентских подключений. В итоге, если первичный менеджер окажется недоступен, приложение может подключиться ко вторичному (резервному) менеджеру.
Порядок определения названия менеджера очередей приложением зависит от применяемого API. Так, при работе через MQI-интерфейс название задается параметром QMgrName функции MQCONN или MQCONNX, а при использовании инструмента JMS Administration tool API для JMS – свойством QMANAGER объекта MQConnectionFactory.
Связь заданного приложением названия менеджера очередей сообщений с каналами клиентских подключений, которые используются клиентскими MCA для подключения к менеджеру, представлена в табл. 7.1.
| Выбранное приложением название менеджера очередей сообщений |
Описание порядка поиска соответствующих канальных объектов клиентских подключений |
|---|
| Пустое |
Соответствующими считаются объекты-каналы клиентских подключений с пустым названием менеджера. Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно формируется независимо от того, какое название менеджер имеет в действительности |
*название_менеджераПервый в выбранном приложением названии менеджера должен быть символ "звездочка" (*)
|
Соответствующими считаются только канальные объекты клиентских подключений с названием менеджера очередей сообщений "название_менеджера". Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно формируется независимо от того, какое название менеджер имеет в действительности. Этот механизм удобен для обеспечения резервного менеджера в том случае, если менеджер очередей с определенным названием недоступен для подключения |
название_менеджера |
Соответствующими считаются только канальные объекты клиентских подключений с названием менеджера очередей сообщений "название_менеджера". Если, воспользовавшись названием канала и атрибутами одного из канальных объектов такого рода, с менеджером удается связаться, соединение успешно сформируется лишь тогда, когда реальное название менеджера есть "название_менеджера" |
7.3.6. Таблица определений клиентских каналов (CCDT)
Описание каждого объекта-канала клиентского подключения добавляет новую запись в имеющийся у любого из менеджеров очередей сообщений файл – таблицу определений клиентских каналов (CCDT – client channel definition table).
Таблица CCDT не предназначена для чтения человеком, однако доступна для чтения множеством различных MCA клиентов в составе клиентских интерфейсов программирования (API).
Содержащий таблицу файл расположен следующим образом.
В WebSphere MQ для Windows:C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера\@ipcc\AMQCLCHL.TAB
В WebSphere MQ для UNIX:/var/mqm/qmgrs/название_менеджера/@ipcc/AMQCLCHL.TAB
В WebSphere MQ для iSeries:/QIBM/UserData/mqm/qmgrs/название_менеджера/ipcc
После того как набор канальных объектов клиентских подключений описан в составе менеджера – не обязательно того самого, к которому подключено приложение, – файл может быть скопирован в новое место для использования клиентским API.
К примеру, он может быть размещен в каталоге с организованным совместным сетевым доступом к нему всех машин, где выполняются приложения, подключенные к менеджеру.
Прежде чем приложение сможет установить подключение так, как было описано в табл. 7.1, API клиента нужно сконфигурировать, чтобы сообщить ему место расположения CCDT.
Сейчас использование CCDT поддерживают не все клиентские интерфейсы. Примеры интерфейсов, которые поддерживают таблицу CCDT, следующие:
Клиентские интерфейсы WebSphere MQ C API и WebSphere MQ C++ API.Расположение CCDT определяется переменными окружения MQCHLLIB и MQCHLTAB. MQCHLLIB содержит название каталога с таблицей CCDT, MQCHLTAB – название CCDT-файла.
Настройка Windows-клиента на той машине, где работает менеджер, в котором предварительно была создана таблица CCDT, имеет, например, вид:
MQCHLLIB=C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера\@ipcc MQCHLTAB=AMQCLCHL.TAB
Примечание Если переменные окружения MQCHLLIB и MQCHLTAB не установлены, по умолчанию местом поиска CCDT-файла являются:в среде Windows:C:\Program Files\IBM\WebSphere MQ\AMQCLCHL.TAB
в среде UNIX:/var/mqm/AMQCLCHL.TAB
Клиентский интерфейс WebSphere MQ V6.0 base Java API.Вторым параметром конструктора объекта MQQueueManager является объект – URL-ссылка.
Клиентский интерфейс WebSphere MQ V6.0 JMS API.URL-ссылка определяется в свойстве CCDTURL создаваемого при помощи инструмента JMS Administration tool объекта MQConnectionFactory.
7.4. Распределенные каналы сообщений
Распределенный канал сообщений – это канал, принимающий сообщения из конкретной транспортной очереди одного менеджера и передающий эти сообщения очередям другого заданного удаленного менеджера.
Распределенный канал сообщений должен быть вручную настроен для каждой описанной в составе менеджера транспортной очереди. Как сказано в разделе 6.2.1 "Разрешение названия очереди", менеджер размещает сообщение в транспортной очереди в результате разрешения названия очереди. По ходу разрешающей процедуры он добавляет в заголовок транспортной очереди сообщения достаточно информации для того, чтобы разрешение названия очереди произошло в тот момент, когда сообщение достигнет менеджера очередей назначения.
Примечание Издержки администрирования при описании распределенных каналов можно уменьшить, если использовать кластер менеджеров очередей сообщений.
7.4.1. Отправка сообщений
В состав любого распределенного канала сообщений входят два MCA, а значит, и два канальных объекта – по одному для каждого менеджера. В зависимости от типа описанного на менеджере объекта-канала сообщений каждый агент выполняет одну из следующих ролей.
MCA – отправитель.Открывает определенную атрибутами канального объекта транспортную очередь сообщений для монопольного извлечения. Сказанное означает, что никакие два канала не могут быть настроены так, чтобы забирать сообщения из одной транспортной очереди. MCA-отправитель извлекает сообщения из транспортной очереди и посылает их агенту-партнеру.
Примечание Это утверждение не касается кластерных каналов сообщений, которые коллективно пользуются единой транспортной очередью. Кластеры менеджеров очередей сообщений мы обсудим в лекции 8 "Кластеры менеджеров очередей".
MCA – получатель.Получает сообщения от MCA-отправителя. В процессе своей работы удаляет из каждого сообщения заголовок транспортной очереди и производит чтение содержимого. Открывает указанную в заголовке транспортной очереди очередь сообщений и помещает сообщение в эту очередь. Открытие очереди и размещение сообщения осуществляются с помощью стандартных вызовов MQI. Это означает, что разрешение названия очереди на менеджере аналогично тому, как если бы к нему подключилось непосредственно приложение, которое, руководствуясь деталями заголовка транспортной очереди, разместило бы сообщение в очереди самостоятельно. Если при разрешении названия на менеджере не удается установить допустимое место назначения сообщения, сообщение доставить нельзя. Об этом мы еще скажем в разделе 7.4.11 "Ошибки доставки сообщений".
Заголовок транспортной очереди создается при разрешении названия очереди на менеджере очередей сообщений, где выполняется MCA-отправитель, и служит для размещения сообщения в очереди под управлением того менеджера, где работает получатель. Заголовок содержит следующую информацию.
Название удаленной очереди.Название очереди назначения сообщения, полученное при выполнении на менеджере разрешающей процедуры. Пытаясь поместить сообщение в очередь удаленного менеджера, находящийся там агент указывает это название в структуре MQOD при открытии очереди.
Название удаленного менеджера.Название менеджера, управляющего очередью назначения сообщения. Также получается в ходе разрешающей процедуры и может не соответствовать названию того менеджера, которому доставляется сообщение, – такое возможно, например, в случае, если очередной менеджер-получатель не является местом назначения сообщения.
Дескриптор исходного сообщения.При добавлении заголовка транспортной очереди сообщение модифицируется. К началу тела прибавляется заголовок исходного сообщения, дескриптор же изменяется и описывает не данные сообщения, а заголовок транспортной очереди. Однако, когда сообщение поступает в очередь назначения, оно должно корректно отражать то, что было послано изначально, в том числе и дескриптор. Дескриптор исходного сообщения хранится в заголовке транспортной очереди и используется агентом при размещении сообщения с удаленным заголовком транспортной очереди на удаленном менеджере очередей сообщений.
Связь пары менеджеров очередей по каналу показана на рис 7.2.
(рис 7.2) Коммуникация двух менеджеров очередей сообщений с использованием агентов отправителя и получателя
7.4.2. Пакеты
Для надежного обеспечения однократной доставки сообщений и агент-отправитель, и агент-получатель должен иметь возможность гарантировать то, что сообщение не потеряется, не окажется отправлено дважды и будет успешно получено MCA-получателем.
С этой целью MCA-отправитель может использовать единицу работы, извлекая сообщения из очереди, а MCA-получатель – размещая их в очереди.
Примечание По умолчанию каналы сообщений не пользуются единицами работы для передачи непостоянных сообщений. Это означает, что сбои связи могут приводить к их потере. Такое стандартное поведение канала можно изменить, выбрав нормальную, а не высокую скорость передачи непостоянных сообщений (NPMSPEED – nonpersistent message speed) канальным объектом MCA-отправителя или MCA-получателя.
Чтобы обеспечить защиту от потери или двукратной доставки сообщений при сбоях коммуникации, эти две независимые единицы работы должны быть скоординированы обоими MCA. Для этого агенты должны "договориться" по сети о фиксации или откате обоими единицы работы, если связь оборвется.
Этот процесс требует дополнительного сетевого обмена, а потому обычно не производится для каждого передаваемого по каналу сообщения. Отдельные пересылаемые сообщения объединяются и образуют пакет (batch), в котором все сообщения либо фиксируются в приемных очередях, либо возвращаются в транспортную очередь как одно целое.
Предельное количество содержащихся в пакете сообщений называется размером пакета (batch size). Настроить это значение позволяют одноименные атрибуты ( BATCHSZ – batch size) канального объекта MCA-отправителя и MCA-получателя. Используемый размер пакета принимается равным меньшему из значений двух атрибутов.
Иногда для заполнения пакета в транспортной очереди бывает недостаточно сообщений. В этом случае в ожидании новых сообщений в транспортной очереди MCA-отправитель берет короткую паузу, фиксируя уже отосланные сообщения только по ее истечении. Количество миллисекунд ожидания до фиксации пакета сообщений MCA-отправителем определяется атрибутом пакетного интервала ( BATCHINT – batch interval). Его значением управляет канальный объект MCA-отправителя.
7.4.3. Неоднозначные каналы и порядковые номера сообщения
Если сетевой обмен был нарушен при подтверждении пакета двумя агентами MCA, такой канал может превратиться в неоднозначный (indoubt). Причина этого в том, что сообщение с запросом на подтверждение было отправлено, а ответ на него не получен. Отправившему запрос агенту неизвестно, действительно ли агент-партнер принял его запрос, а связь нарушилась уже во время ответа, или же сбой случился при отправке запроса.
Единица работы одного из каналов должна при этом оставаться в состоянии готовности (prepared) к фиксации или откату в зависимости от действий, предпринятых агентом-партнером. В целях автоматического разрешения неоднозначного состояния канала при его перезапуске оба агента поддерживают порядковые номера, связанные с количеством успешно переданных по каналу сообщений.
Неоднозначное состояние канала представлено значением YES атрибута INDOUBT его записи состояния.
Примечание Подробнее о неоднозначных каналах и ручных операциях, которые вы можете предпринять, если канал перешел в неоднозначное состояние и не способен автоматически его разрешить, читайте в руководстве WebSphere MQ Intercommunication, SC34-6587.
7.4.4. Интервалы разъединения
Оставлять канал связи открытым неопределенно долгое время может быть неразумно. Поэтому WebSphere MQ позволяет автоматически закрывать канал сообщений, если за указанный интервал по нему не передано ни единого сообщения.
Этот интервал времени задается в секундах, а для задания служит атрибут "интервал разъединения" ( DISCINT – disconnect interval) канального объекта MCA-отправителя. Для указания на то, что канал связи должен оставаться открытым сколь угодно долгое время, используется нулевое значение интервала.
7.4.5. Названия соединений
Для установления канала между агентами отправителя и получателя один из агентов MCA должен связаться с менеджером очередей – партнером, используя объект-слушатель того менеджера.
В зависимости от типа канального объекта с описанием MCA на каждом конце канала запуск последнего допустим с любой стороны подключения. Об этом мы еще скажем в разделе 7.4.10 "Допустимые пары объектов – распределенных каналов сообщений".
Атрибут "название соединения" ( CONNAME – connection name) объекта-канала определяет название TCP/IP-хоста или IP-адрес и порт слушателя партнерского менеджера очередей сообщений.
Названия соединений и слушатели обсуждались нами в разделе 5.3.8 "Сетевой доступ к менеджеру". Название соединения задается следующим образом:
Имя_хоста.или.IP-адрес(порт)
Если порт не указан, используется известный TCP/IP-порт WebSphere MQ с номером 1414.
Примечание При описании каналов через MQSC название соединения должно быть ограничено апострофами, например:DEFINE CHANNEL(TO.EXAMPLE.PAYROLL) CHLTYPE(SDR) +
XMITQ(EXAMPLE.PAYROLL) +
CONNAME('payroll.example.com(9001)')
7.4.6. Объекты receiver-каналов
Объект receiver-канала задается на менеджере для определения атрибутов MCA-получателя, которому другие менеджеры очередей могут посылать сообщения.
Объект receiver-канала нельзя использовать для инициирования канала.
Для описания объектов receiver-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(RCVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Receiver Channel.
7.4.7. Объекты requester-каналов
Объект requester-канала задается на менеджере для определения атрибутов MCA-получателя, которому другие менеджеры очередей могут посылать сообщения.
Объект requester-канала можно использовать для инициирования канала.
Для описания объектов requester-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(RQSTR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Requester Channel.
Обязательный атрибут – название соединения ( CONNAME ).
7.4.8. Объекты sender-каналов
Объект sender-канала задается на менеджере очередей сообщений для определения атрибутов MCA-отправителя, который из указанной транспортной очереди может посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один агент sender-канала или server-канала.
Объект sender-канала можно использовать для инициирования канала.
Для описания объектов sender-каналов воспользуйтесь одним из двух методов.
Командой MQSC DEFINE CHANNEL CHLTYPE(SDR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Sender Channel.
Обязательные атрибуты – название транспортной очереди ( XMITQ ) и название соединения ( CONNAME ).
7.4.9. Объекты server-каналов
Объект server-канала задается на менеджере очередей сообщений для определения атрибутов MCA-отправителя, который из указанной транспортной очереди может посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один агент sender-канала или server-канала.
Объект server-канала можно использовать для инициирования канала, если название соединения входит в определение объекта. Если название соединения задано, говорят, что объект server-канала определен полностью (fully qualified).
Для описания объектов server-каналов используйте один из двух методов.
Команду MQSC DEFINE CHANNEL CHLTYPE(SVR).
WebSphere MQ Explorer:щелкните правой кнопкой мыши по папке Channels конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
выберите в меню New -> Server Channel.
Обязательный атрибут – название транспортной очереди ( XMITQ ).
Примечание Не смешивайте объекты server-каналов и описанные в разделе 7.3.2 канальные объекты серверных подключений.
7.4.10. Допустимые пары объектов – распределенных каналов сообщений
Агенты MCA, созданные из описанных канальных объектов, могут объединяться с образованием канала лишь в некоторых сочетаниях. Допустимые комбинации и порядок их применения мы рассмотрим в этом разделе лекции.
Каналы sender-receiver
Такой канал может инициироваться лишь со стороны отправителя.
Для подключения к одному объекту receiver-канала в составе менеджера можно использовать целый ряд объектов sender-каналов, описанных на различных менеджерах очередей сообщений.
Типичным является описание на менеджере единственного объекта – receiver-канала. Для связи с упомянутым менеджером все менеджеры в составе инфраструктуры располагают sender-каналом, имеющим то же имя, что и receiver-канал.
Каналы requester-server
Каналы такого рода могут инициироваться на стороне requester-канала или – опционально – на стороне server-канала, если в нем определено полностью название соединения.
Каналы requester-server не требуют, чтобы requester-канал, инициирующий соединение, находился в системе с конкретным именем соединения. Это позволяет описать множество одноименных requester-каналов в составе различных менеджеров, каждый из которых сможет запрашивать сообщения из единой транспортной очереди одного и того же удаленного менеджера. Впрочем, одновременно активным и извлекающим сообщения из транспортной очереди может являться только один канал, ведущий к requester-каналу.
Каналы requester-sender
Такой канал схож с каналом requester-server с полностью определенным объектом server-канала. Однако, после того как соединение было инициировано requester-каналом, связь разрывается и формируется снова sender-каналом с использованием хранящегося внутри него названия соединения.
Sender-каналу данное решение позволяет гарантировать, что он связан с requester-каналом под управлением конкретного менеджера.
Каналы server-receiver
Функционально эквивалентны паре sender-receiver. Соединение инициируется со стороны server-канала, а значит, server-канал должен иметь полностью определенное название соединения.
7.4.11. Ошибки доставки сообщений
Если MCA-получатель не может доставить сообщение в очередь, в отношении сообщения агент предпринимает ряд предсказуемых действий.
Доставка сообщения может дать сбой по следующим причинам.
Неудачное окончание разрешения названия очереди при попытке ее открытия. Как было сказано в разделе 7.4.1 "Отправка сообщений", названия очереди и менеджера очередей сообщений, которые служат для открытия очереди с целью размещения сообщения, содержатся в заголовке транспортной очереди. Процедуру разрешение названия и влияние на нее всех типов объектов-очередей мы обсудили в разделе 6.2.1 "Разрешение названия очереди".
Установленная при разрешении очередь, которая может являться локальной очередью менеджера очередей сообщений или транспортной очередью, представляющей следующий пункт назначения на маршруте к месту получения сообщения, уже содержит максимально допустимое количество сообщений.
Размещение сообщений в очереди блокировано.
Меры, предпринимаемые агентом, определяются атрибутами канального объекта агента и атрибутом "очередь недоставленных сообщений" ( DEADQ – dead letter queue) объекта-менеджера. Вкратце эти шаги таковы.
Поскольку в силу своей природы часть сбоев доставки – например, нахождение в очереди предельного количества сообщений – может не повторяться, MCA-получатель может попытаться разместить сообщение вновь. Количество повторных попыток размещения сообщения агентом определяется атрибутом "число попыток на сообщение" ( MRRTY – message retry) того объекта-канала, где описан MCA-получатель. Интервал между попытками определяется атрибутом "таймер попыток на сообщение" ( MRTMR – message retry timer) этого же канала.
Если атрибут "очередь недоставленных сообщений" ( DEADQ ) объекта-менеджера очередей задан, MCA-получатель попытается открыть очередь, имеющую указанное название. Если это ему удастся, к сообщению будет добавлен заголовок недоставленного сообщения ( MQDLH ), и оно будет размещено в этой очереди.Заголовок недоставленного сообщения содержит информацию об ошибке. В нее входят название очереди и менеджера очередей сообщений из заголовка транспортной очереди. Также в заголовок недоставленного сообщения входит и код причины, полученный при неудачной попытке открыть очередь для размещения сообщения. Такие коды причин мы обсуждали в разделе 6.2.1 "Коды завершения и причин".
Если для текущего менеджера очередь недоставленных сообщений не задана или не существует, действие зависит от факта, используются ли для передачи сообщений единицы работы. Как говорилось в разделе 7.4.2 "Пакеты", единицы работы задействуются при передаче постоянных сообщений; применительно же к непостоянным они используются лишь при задании нормальной (normal) скорости работы канала.
Если для доставки сообщений единицы работы не применяются, непостоянное сообщение аннулируется.
Если для доставки сообщений используются единицы работы, сообщение возвращается в транспортную очередь на стороне отправителя. Канал, как было сказано в разделе 7.2.1 "Понятие состояния канала", переходит в состояние RETRYING. При этом он пытается доставить сообщение снова – каждый раз при повторении перезапуска. Когда же заданное для канала количество повторных попыток будет исчерпано, он перейдет в состояние STOPPED, и перезапуск канала должен производиться вручную. Движение сообщений в канале будет прекращено, пока нельзя будет доставить сообщение, не будет указана очередь недоставленных сообщений для менеджера либо сообщение не будет вручную удалено из транспортной очереди.
Примечание Во избежание действий из шага 3 советуем вам описать очереди недоставленных сообщений для всех без исключения менеджеров.При создании любого менеджера формируется очередь SYSTEM.DEAD.LETTER. QUEUE. В дальнейшем менеджер можно настроить так, чтобы использовать ее как очередь недоставленных сообщений. Однако все очереди с префиксом SYSTEM. в WebSphere MQ Explorer полезно скрыть, а потому подобной настройки обычно рекомендуется избегать.
Убедитесь, что значение атрибута "предельная длина сообщения" очереди недоставленных сообщений достаточно велико и ни одно сообщение, попав в очередь, не будет усечено.
7.4.12. Работа с очередью недоставленных сообщений
После того как очередь недоставленных сообщений менеджера описана, задумаемся о направляемых в нее сообщениях. Чтобы гарантировать кратковременность нахождения в ней сообщений – а в это время они не могут обрабатываться приложениями системы, – нужны особые меры.
Выполнение действий над сообщениями, прибывшими в эту очередь, обычно называется обработкой очереди недоставленных сообщений.
Подходы к обработке данной очереди включают следующее.
Регулярный просмотр администратором.Прикрепляемый к сообщениям при постановке в эту очередь заголовок недоставленных сообщений имеет формат, трудно воспринимаемый человеком. По этой причине WebSphere MQ Explorer дает возможность вывода на экран отдельных полей, образующих заголовок, в удобочитаемом представлении. Для доступа к этой функции выполните следующие шаги:
выделите в навигаторе папку Queues менеджера очередей сообщений;
щелкните правой кнопкой мыши по очереди недоставленных сообщений на панели содержимого Queues ;
выберите в меню Browse Messages ;
щелкните правой кнопкой по сообщению из таблицы;
выберите в меню Properties ;
выберите раздел Dead-letter header.
Выполнение действия по триггеру, который срабатывает всегда, как только в очереди недоставленных сообщений появляются сообщения.Пример такого постоянного действия – выполнение несложного приложения, отсылающего электронное письмо администратору для того, чтобы тот смог сам просмотреть очередь. Подробнее о триггерах см. раздел 6.3 "Применение триггеров".
К разряду триггеров, которые можно использовать в данном случае, относятся:
триггеры типа FIRST с большим, определенным для менеджера триггерным интервалом. Они инициируют регулярное выполнение приложения, если в очереди недоставленных сообщений имеются сообщения;
триггеры типа EVERY. Они инициируют выполнение приложения всякий раз при поступлении в очередь нового сообщения.
Применение обработчика очереди недоставленных сообщений, входящего в WebSphere MQ.С учетом набора правил, настроенных при запуске обработчика, он может автоматически выполнять действия над сообщениями, прибывающими в очередь недоставленных сообщений. Для ознакомления с обработчиком очереди недоставленных сообщений из WebSphere MQ читайте руководство WebSphere MQ Intercommunication, SC34-6587.
Применение обработчика очереди недоставленных сообщений собственной разработки.Если правил из обработчика очереди недоставленных сообщений, входящего в WebSphere MQ, не хватает для выполнения особых требований клиента, допускается и создание специального приложения, которое будет обслуживать сообщения по мере их поступления в очередь.
7.4.13. Инициирование канала
Перезапуск каналов сообщений не производится WebSphere MQ автоматически, если каналы становятся неактивны по достижении интервала разъединения или при перезапуске менеджера.
Число каналов в составе менеджера может быть велико, и ручной запуск с использованием MQSC или WebSphere MQ Explorer в инфраструктуре взаимосвязанных менеджеров может оказаться неэффективным.
WebSphere MQ для платформ Windows и UNIX содержат процесс-инициатор каналов, автоматически запускающий их при поступлении сообщений в транспортные очереди.
Примечание Не смешивайте инициатор каналов в этом разделе книги с инициатором каналов WebSphere MQ для z/OS, описанным в разделе 5.3.10.Обязанности по запуску в WebSphere MQ для z/OS и WebSphere MQ для iSeries лежат на программах-слушателях каналов.
Инициатор каналов – это программа – триггерный монитор, которая считывает триггерные сообщения из очереди инициации каналов и запускает канал, указанный в данных каждого сообщения.
Инициатор каналов WebSphere MQ можно запустить по управляющей команде WebSphere MQ runmqchi. Впрочем, инициатор каналов по умолчанию предоставляется WebSphere MQ и автоматически запускается менеджером очередей сообщений.
Этот модуль инициатора каналов по умолчанию может быть заблокирован установкой параметра SCHINIT (start channel initiator) объекта-менеджера очередей в MANUAL.
Используемый по умолчанию инициатор каналов наблюдает за очередью неудачных попыток инициирования SYSTEM.CHANNEL.INITQ.
Настройка транспортной очереди с целью автоматического запуска канала-обработчика сообщений из этой очереди производится установкой следующих атрибутов.
Активируйте триггеры: TRIGGER.
Установите тип триггера "для первого сообщения": TRIGTYPE(FIRST).
Данные триггера – в значение названия канала: TRIGDATA('TO.remote.qmgr').
Очередь инициации – в SYSTEM.CHANNEL.INITQ: INITQ(SYSTEM.CHANNEL.INITQ).
7.5. Автоопределение каналов
Менеджер очередей сообщений можно настроить так, чтобы в ответ на запросы соединения от MCA канальные объекты создавались автоматически.
Чтобы разрешить автоопределение каналов менеджера очередей сообщений, установите атрибут "автоопределение каналов" ( CHAD – channel auto-definition) объекта-менеджера в значение ENABLED.
7.5.1. Автоопределение клиентских каналов
Если приложение пытается подключиться к менеджеру очередей сообщений, используя клиентский канал, но соответствующий объект-канал серверных подключений с требуемым названием в менеджере отсутствует, он создается автоматически.
После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты канального объекта серверных подключений основаны на атрибутах автоматически формируемого менеджером очередей сообщений канального объекта серверных подключений SYSTEM.AUTO.SVRCONN.
7.5.2. Автоопределение распределенных каналов сообщений
Если при попытке удаленного менеджера установить подключение, используя объект – sender-канала или полностью заданный объект – server-канала, соответствующий receiver-канал или requester-канал с требуемым названием на менеджере отсутствует, автоматически создается receiver-канал.
После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты объекта – receiver-канала основаны на атрибутах автоматически формируемого менеджером очередей сообщений объекта receiver-канала SYSTEM.AUTO.RCVR.
