Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ

7.3. Клиентские каналы

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

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

7.3.1. Функционирование каналов

Если приложение соединяется с менеджером, используя механизм подключения из выбранного для разработки API, то оно запускает MCA-агент интерфейса API клиента, обозначенный в этой книге термином клиентского MCA (client MCA).

Упомянутый MCA обеспечивает связь с менеджером очередей сообщений, используя клиентский канал и предоставленный менеджером объект-слушатель. Для установления соединения MCA вызывает MQI-функции работы с каналом MQCONN и MQCONNX.

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

На своей стороне менеджер запускает агент серверного подключения (server connection MCA). Используя локальное соединение с менеджером, он выполняет направленные MCA клиента вызовы MQI

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

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).

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.