Мнение эксперта: Марк Тейлор о WebSphere MQ

Эта статья, подготовленная Марком Тейлором, разработчиком технической стратегии WebSphere, содержит ответы на основные вопросы пользователей, связанные с разработкой приложений для WebSphere MQ (ранее MQSeries) и взаимодействием с системами на платформах, отличных от z/OS.

Марк Тейлор, разработчик технической стратегии WebSphere MQ, IBM

Марк Тейлор (Mark Taylor) работает в IBM почти 20 лет в различных должностях, связанных с разработкой и обслуживанием клиентов. Он писал код для ранних версий MQSeries и участвовал в его переносе на различные операционные системы семейства Unix. Последние пять лет Марк работает в отделе технической стратегии, где сейчас отвечает за определение функций, включаемых в новые издания WebSphere MQ. Он также часто выступает на технических конференциях.



12.04.2010

В этом месяце мы попросили Марка Тейлора рассказать о разработке приложений для WebSphere MQ (ранее MQSeries) или взаимодействии с системами, размещенными на платформах, отличных от z/OS. WebSphere MQ позволяет приложениям обмениваться информацией между более чем 35 платформами IBM и других компаний, включая Linux и Windows® 2000. Марк Тейлор, как разработчик технической стратегии, отвечает за описание функций, которые добавляются в новые версии WebSphere MQ. Более подробную информацию вы найдете в разделе developerWorks WebSphere Business Integration.

Мы благодарим всех разработчиков WebSphere, приславших свои вопросы.

Вопрос: Как можно достичь прозрачного восстановления после отказа для MQSeries Java™ Client при кластерной установке MQSesies? Например, если менеджер очереди прекращает работу в середине операции получения или передачи, клиент должен иметь возможность обратиться к следующему доступному менеджеру очереди и продолжить процесс обработки прозрачным способом (прислано SR).

Ответ: Слово "кластер" имеет различные значения. В WebSphere MQ (WMQ) кластер предназначен для маршрутизации сообщений между менеджерами очередей. Приложение для передачи сообщения должно связаться с одним определенным менеджером очереди в пределах кластера. Связывание клиента с любым членом WMQ-кластера по выбору не предусмотрено. Другой смысл понятия "кластер" касается использования в качестве объекта, способного восстанавливаться после отказа. Этот подход реализуется, например, с использованием технологии HACMP. Это позволяет менеджерам очередей беспрепятственно передвигаться между машинами. Здесь нет места для подробного изложения, но оба эти типа кластеризации могут успешно работать совместно.

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

Тогда возникает вопрос, где вы устанавливаете соединение повторно?

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

Если вы действительно хотите подсоединиться к другому менеджеру очереди, клиентское приложение, написанное на C, может использовать в MQCONN шаблон в сочетании файлом с внешнего канала доступа (AMQCLCHL.TAB). Он выбирает из таблицы первый имеющийся в наличии менеджер очереди, удовлетворяющий вашему критерию выбора. Однако текущие версии Java- и JMS-классов не имеют доступа к этому файлу, поэтому для них список альтернативных соединений необходимо внести в программный код. Вы можете сделать это явно (к примеру, задавая в вашей программе адреса TCP/IP каждого менеджера очереди, пока соединение не установится), либо посредством итерирования по точкам входа в свойствах ConnectionFactory, доступных через JNDI.

Вопрос: MQ работает на платформе Unix. У меня есть NT-приложение, которое использует сервисы MQ для сообщений. Я хочу разработать простой сервис мониторинга MQ, который передавал бы мне глубину очереди и содержимое сообщений в очереди. Этот сервис мониторинга необходимо интегрировать в NT-приложение, чтобы пользователь мог видеть глубину очереди и сообщения. Приложение использует ORACLE и написано на языках C и Java. Что здесь можно сделать? Мы не можем позволить себе прибегнуть к сторонним сервисам (прислано SR из Deutsche Bank).

Ответ: Существует ряд API и технологий для определения глубины очереди. В зависимости от среды вашего приложения, вы можете использовать непосредственно MQINQ или посылать PCF сообщения командному серверу. Для неразрушающего чтения содержимого сообщений необходимо использовать метод MQGET с флагами MQGMO_BROWSE. Использование этих интерфейсов демонстрируется как в коде простого приложения, поставляемого с продуктом, а также в SupportPacs. В частности, обратите внимание на MS02 и MS0B; они помогут вам в конструировании PCF-сообщений. Смотрите полный список SupportPacs. Там же есть ссылки на несколько отдельных программ мониторинга.

Вопрос: Вы можете объяснить способ преобразования имен из JND-приложения WebSphere V5 к JMS-очереди WebSphere MQ? Считаете ли вы хорошей стратегией использование локального поставщика очередей на рабочих машинах в процессе разработки и развертывание до корпоративного пространства имен при внедрении? (прислано RW)

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

В реализации JMS в WMQ способ соединения приложения с менеджером очередей определяет Queue Connection Factory. Зачастую соединение происходит в режиме клиента через сеть TCP/IP. После того как соединение установлено, вы можете использовать объект Queue, чтобы открыть очередь в данном менеджере очередей. Имя очереди, заданное в JNDI-пространстве, совпадает с именем очереди, которое видит WMQ. Создание очереди в WMQ через команду runmqsc не делает ее автоматически доступной для JMS-приложений. Вам нужно поместить объект Queue с тем же именем в JNDI с помощью программы JMSAdmin.

WWebSphere Application Server V5.0 включает в себя ограниченный административный инструментарий, который объединяет в себе функции runmqsc ти JMSAdmin функциями для единственного заданного по умолчанию менеджера очередей, известного, как поставщик Embedded Messaging. Описанные очереди доступны только в этом менеджере очередей по умолчанию. Если вы хотите полной гибкости инструмента JMSAdmin, включая возможность соединения с различными менеджерами очередей, вам необходимо установить полную лицензионную копию WMQ V5.3 поверх встраиваемой версии.

Маршрут от JMS к JNDI создает один уровень изоляции и опосредования, что предоставляет возможность динамического изменения "реального" менеджера очередей, например, при переходе от разработки к производственной системе. Тем не менее, мне хотелось бы также рекомендовать конфигурировать все объектные имена, включая ссылку на JNDI-сервис, вне приложения (возможно, как свойства, на которое делается ссылка во время выполнения). Помните, что JNDI-ссылка может легко ссылаться на локальный файл на рабочей станции или на корпоративный сервер каталогов. Изменение конфигурируемых извне свойств предельно упрощает перемещение между разными средами. Если ваша организация уже определила договоренность об именах для других приложений, использующих WMQ, вы можете распространить ее и на пространство JMS.

Вопрос: Как мне узнать, какая версия WMQ установлена на каждой платформе?

Ответ: Вы можете использовать вывести список версий установленных продуктов соответствующими командами операционной системы. Например, lslpp для AIX, swlist для HP-UX, pkginfo для Solaris. Существует также команда mqver, в настоящее время недокументированная, которая доступна в версиях V5.2 и V5.3. Она показывает базовый уровень продукта, например, 530. Уровень CMVC содержит дату компиляции продукта. Он полезен для сервисных специалистов IBM, которые по нему могут определить номер CSD и примененные специализированные исправления. Мы намереваемся усовершенствовать эту команду, чтобы она точнее определяла номер CSD.

Вопрос: Когда можно будет использовать общие очереди на распределенных платформах?

Ответ: Мне не хотелось бы отвечать "никогда", но я думаю, что эта функция едва ли появится для платформ, отличных от z/OS. Общедоступные очереди, которые доступны различным менеджерам очередей одновременно, основываются на сервисах, предоставляемых, весьма специализированными устройствами, т.н. Coupling Facility. Это аппаратно-программный комплекс, функциональность которого далеко выходит за пределы простого распределения памяти между машинами. Например, существуют специализированные процессы, которые могут поддерживать модификацию в пределах определенного списка структур. Такие системы в настоящее время не поддерживаются другими платформами. Наши попытки найти технологии, которые позволили бы обновлять общедоступные очереди без использования Coupling Facility, пока не увенчались успехом из-за проблем с производительностью и восстановлением. Распределенные двухфазные транзакции просто недостаточно эффективны по сравнению с выделенными менеджерами очередей. На данный момент, если вам нужны параллельная масштабируемость и восстановление, которые обеспечивают такие очереди, то ваш выбор - z/OS.

Вопрос: Мое приложение теряет сообщения. Почему?

Ответ: WMQ очень аккуратно относится к сообщениям и не отбрасывает их, если ему не позволят это делать. Наиболее часто встречающаяся причина потери сообщения в том, что сообщение было определено как временное. Многие думают, что вы можете создать постоянную очередь, но атрибут DEFPSIST просто задает значение по умолчанию. Постоянство на самом деле является атрибутом сообщения, а не очереди. Программа приложения может либо устанавливать это значение явно, либо позволить взять его из атрибута очереди по умолчанию. Временные сообщения сбрасываются, когда менеджер очередей перезапускается, и также могут отбрасываться при обрыве канала. Когда вам кажется, что вы теряете сообщения, всегда проверяйте, не было ли оно быть отправлено как временное.

Вторая возможная причина "потери" сообщений в том, что менеджер очередей просто не поместил их в ожидаемую очередь. Сообщение не теряется, а просто попадает не туда. Просмотрите очереди "мертвых писем" Dead Letter Queue (DLQ) во всех менеджерах очередей, через которые сообщение могло быть направлено. Если возникла проблема с отправкой сообщения, оно, скорее всего, ушло в DLQ.

Последняя часто встречающаяся причина потери сообщений - аварийное завершение приложения клиента в процессе операции MQGET(WAIT). При перезагрузке ожидаемое сообщение оказывается удалено из очереди. Чтобы избежать этой проблемы, убедитесь, что вы используете транзакцию (MQGMO_SYNCPOINT) для вызова метода MQGET. Сообщение будет возвращено обратно в свою очередь, когда канал SVRCONN попытается и не сможет послать его клиентской программе.

Вопрос: Я не могу удалить сообщения из очереди, потому что они используются. Как я могу узнать, кто их использует? И как я могу прекратить их использование?

Ответ: Обратите внимание на команду DISPLAY QSTATUS, которая появилась в WMQ V5.3. Она отображает все процессы, которые имеют открытую очередь, как программы приложений, так и каналов. Программы каналов держат кэш дескрипторов недавно использовавшихся обращений к очередям, которые могут продолжать использовать очередь. Хотя канал однажды освобождает эти дескрипторы, информация DISPLAY QSTATUS показывает имя канала, так что вы можете завершить его принудительно, если это необходимо.

Вопрос: Существующее приложение ставит сообщение в очередь. Мне теперь нужна возможность послать копии этих сообщений во вторую очередь, но я не могу изменить приложение. Есть какой-либо способ сделать это?

Ответ: Если вы используете WMQ V5.3 на любой распределенной платформе, взгляните на API–интерфейс Exit. Он позволяет вам перехватывать каждый вызов MQI, сделанный приложением. Всякий раз, как приложение выполняет метод MQPUT, ваш выход выдает соответствующий метод MQPUT для тех же данных во вторую очередь. Другой вариант - изменить очередь, используемую приложением. Это легко сделать, если используется определение ALIAS или приложение читает свою выходную очередь из внешнего конфигурационного файла (временной очереди хранения). Затем написать новое приложение, которое получает сообщение и посылает одну его копию первоначальной выходной очереди, а вторую копию куда-либо еще. Вы также можете, конечно, использовать один из продуктов-брокеров WMQ, обеспечивающих максимальную гибкость.

Вопрос: Как я могу контролировать идентификатор пользователя, который используется для авторизации из JMS-приложения?

Ответ: Если приложение соединено с менеджером очереди в локальном режиме, идентификатор пользователя ассоциируется с выполняемым процессом. Если приложение связано с менеджером очередей как клиент через локальную сеть, то атрибут MCAUSER определения SVRCONN контролирует, какой идентификатор пользователя отвечает за соединение. Если значение MCAUSER пустое (значение по умолчанию), большинство систем вызывают выполнение JMS-приложения с полномочиями mqm, за исключением случаев, когда клиентская программа предоставляет собственный идентификатор пользователя.

Для очень старых С-клиентов, например, для Windows 95, идентификатор пользователя клиента задается переменной среды.

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

Для Java- и JMS-клиентов идентификатор пользователя должен выдаваться изнутри программы. Это может быть сделано либо определением значений в классе Environment, либо использованием версии метода JMS createQueueConnection, которая принимает идентификатор пользователя и пароль как параметры. Если ни один из этих механизмов не применяется, идентификатор пользователя по каналу не передается и берется значение по умолчанию из MCAUSER.

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

Для уверенности в идентификационных данных клиента вы должны либо использовать защищенные выходы канала, либо использовать SSL-аутентификацию. Если в методе createQueueConnection используется пароль, он становится доступен для защищенных выходов. Пример пары защищенных выходов, написанных на Java для клиента и на C для сервера, есть в SupportPac IC72.

Вопрос: Могу я использовать WMQ через Интернет?

Ответ: Большинство соединений через Интернет должны проходят через один или несколько брандмауэров, настроенные для изоляции машин и обеспечения безопасности. Хотя вы можете использовать WMQ напрямую через брандмауэр, открыв порт, с которым соединяется канал (1414 по умолчанию), существует несколько дополнительных возможностей, которые могут быть полезны администраторам.

Если вы хотите ограничить номер локального порта отправителя (это обычно не нужно, но иногда требуется), используйте атрибут LOCLADDR канала. Это позволяет инициализирующему каналу, такому как SENDER или CLNTCONN, указать, что исходящий сокет идет с определенного адреса TCP/IP, в пределах известного диапазона портов.

WMQ-каналы по умолчанию не имеют средств безопасности, применимых к ним самим. Если вы решили использовать соединение через Интернет, обратите внимание на применение средств SSL, имеющихся в версии V5.3, для аутентификации, кодирования и интеграции данных.

Для еще большей гибкости попробуйте SupportPac MS81 – сквозной Интернет-канал WMQ. Это полностью поддерживаемый пакет, который может действовать как прокси в демилитаризованной зоне между брандмауэрами, передавая потоки протоколов канала WMQ. Он может также упаковывать эти протоколы в HTTP, что еще больше упрощает преодоление брандмауэров.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=481846
ArticleTitle=Мнение эксперта: Марк Тейлор о WebSphere MQ
publish-date=04122010