...

Оглавление Примечания

by user

on
Category: Documents
108

views

Report

Comments

Transcript

Оглавление Примечания
Оглавление
Примечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
Авторское право . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX
Торговые марки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI
Команда, написавшая книгу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI
Как стать автором . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII
Отзывы и комментарии приветствуются . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII
Внесенные исправления . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIV
Ноябрь 2005 г. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIV
Новая информация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIV
Глава 1. Обзор . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Глава 2. Понятие очередей сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.
Базовые понятия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Промежуточное ПО. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Сообщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Очереди. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4. Межточечный обмен сообщениями. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.
2.1.5. Обмен сообщениями по принципу «публикации-подписки» . . . . . . . . . . . . . 7
Упрощение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Разработка с акцентом на бизнес-логике. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Сопровождение приложений и переносимость их кода. . . . . . . . . . . . . . . . 10
2.4.
2.3.
Расширяемость и скорость работы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Надежность служб и целостность данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Однократная доставка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Единицы работы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. Обработка ошибок. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.4. Среда обеспечения контроля качества. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Оглавление 2.5.
Защита . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1. Защита доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6.
2.5.2. Защита коммуникаций. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Высокая готовность системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1. Доступность служб. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.2. Доступность сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7.
2.6.3. Восстановление после сбоя. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Мониторинг и учет операций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1. Мониторинг производительности. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.2. Учет. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Глава 3. Средства поддержки очередей сообщений в WebSphere MQ . . . . . . . . . . . . . . 21
3.1.
Базовые понятия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1. Инфраструктура очередей сообщений WebSphere MQ. . . . . . . . . . . . . . . . . 22
3.1.2. Средства реализации инфраструктуры WebSphere MQ . . . . . . . . . . . . . . . . 22
3.2.
3.1.3. Пакеты дополнительных функций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Упрощение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Доступ приложений к инфраструктуре WebSphere MQ . . . . . . . . . . . . . . . . 24
3.2.2. Асинхронноевзаимодействие с использованием WebSphere MQ. . . . . . . . 24
3.2.3. Обобщенные пункты назначения WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . 25
3.2.4. Особые пункты назначения WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5. Предоставление услуг в инфраструктуре WebSphere MQ. . . . . . . . . . . . . . . 25
3.2.6. Очереди WebSphere MQ как интерфейс доступа к службам. . . . . . . . . . . . . 26
3.2.7. Стандартизованные API-интерфейсы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.8. WebSphere MQ и WebSphere Application Server. . . . . . . . . . . . . . . . . . . . . . . 27
3.2.9. Web-службы как интерфейс доступа к службам. . . . . . . . . . . . . . . . . . . . . . 28
3.3.
3.2.10. Упрощенная обработка сбоев в WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . 29
Расширяемость и скорость работы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1. Расширяемость менеджеров очередей WebSphere MQ. . . . . . . . . . . . . . . . . 30
3.3.2. Архитектура с одним менеджером очередей сообщений. . . . . . . . . . . . . . . 30
3.3.3. Центрально-лучевая архитектура WebSphere MQ . . . . . . . . . . . . . . . . . . . . . 31
3.4.
3.3.4. Кластерыменеджеров как возможность гибкого расширения . . . . . . . . . . 33
Надежность служб и целостность данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1. Постоянные и непостоянные сообщения. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2. Единицы работы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
VI Оглавление
3.5.
Безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.1. Object Authority Manager (OAM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.2. SSL-протокол и защита транспортного уровня стека (TLS). . . . . . . . . . . . . 37
3.6.
3.5.3. Защита коммуникаций по SSL-протоколу и технологии TLS. . . . . . . . . . . . 37
Высокая готовность системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.1. Ролькластеров менеджеров в работе служб высокой готовности. . . . . . . 38
3.6.2. Группы с разделением очередей на WebSphere MQ для z/OS. . . . . . . . . . . . 39
3.6.3. Кластеры высокой готовности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7.
3.6.4. Восстановление после сбоя. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Мониторинг и учет операций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.1. Мониторинг производительности. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.2. Учет. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.3
Трассировка маршрута сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Глава 4. Создание приложений для доступа к инфраструктуре WebSphere MQ . . . . . 43
4.1.
4.2.
Кроссплатформенная поддержка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Интерфейсыприкладного программирования (API) . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1. Интерфейс очередей сообщений (MQI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2. API-интерфейсы на базе объектной модели WebSphere MQ . . . . . . . . . . . . 45
4.2.3. Стандартизованные API-интерфейсы для WebSphere MQ . . . . . . . . . . . . . . 46
4.3.
4.2.4. Индивидуальные адаптеры. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Сообщения WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.1. Дескриптор сообщения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2. Преобразование данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3. Форматы сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.
4.3.4. Сборка сообщений из их фрагментов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Взаимодействиес инфраструктурой WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1. Клиентские продукты WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.
4.4.2. Основные возможности приложения WebSphere MQ. . . . . . . . . . . . . . . . . . 52
Транзакции и единицы работы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.1. Локальные единицы работы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.2. Точка синхронизации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.3. Фиксация и отмена. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.4. Незафиксированные сообщения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.5. Глобальные единицы работы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Оглавление
VII
4.5.6. Координация глобальных единиц работы . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.7. Двухфазовая фиксация. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.8. Спецификация XA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.9. Расширенный транзакционный клиент. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6.
4.5.10. Отказоустойчивость и обработка ошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Межточечный обмен сообщениями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.1. Извлечение сообщений из очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.2. Размещение служб на очередях сообщений. . . . . . . . . . . . . . . . . . . . . . . . . 60
4.6.3. Счетчики и очереди возврата . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6.4. Службы с управлением по событиям. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6.5. Обмен по принципу «отправил – забыл». . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6.6. Списки распространения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.7. Сегментация сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.8. Логическая группировка сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6.9. Отчеты. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6.10. Отчеты«подтверждение доставки» и «подтверждение прибытия». . . . . . . 64
4.6.11. Синхронный обмен по принципу «запрос – ответ». . . . . . . . . . . . . . . . . . . . 65
4.6.12. Частично синхронный обмен по принципу «запрос – ответ». . . . . . . . . . . . 65
4.6.13. Истечение срока существования сообщений. . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6.14. Реализация очереди ответов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7.
4.6.15. Обработка сообщений службой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Обмен по принципу публикации-подписки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.7.1. Брокер публикации-подписки WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . 70
4.7.2. Взаимодействиес брокером публикации-подписки WebSphere MQ. . . . . . 71
4.7.3. Потоки. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7.4. Регистрация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7.5. Темы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7.6. Публикации. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.7.7. Развитие функций публикации и подписки в WebSphere MQ. . . . . . . . . . . . 72
Глава 5. Менеджеры очередей: общее представление и настройка . . . . . . . . . . . . . . . . 73
5.1.
Информация об установке . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1.1. Последние доступные обновления. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.
VIII
5.1.2. Спецификация окружения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Интерфейсы администрирования WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Оглавление
5.2.1. WebSphere MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2. Модуль WebSphere MQ Explorer Healthcheck. . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.3. Управляющие команды WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.4. Команды языка управления WebSphere MQ для iSeries . . . . . . . . . . . . . . . . 81
5.2.5. Команды WebSphere MQ для z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.6. Команды WebSphere MQ Script (MQSC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.
5.2.7. Форматы программируемых команд (PCF) . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Менеджер очередей сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3.1. Наименование менеджеров очередей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3.2. Объекты WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.3. Группы с разделением очередей в WebSphere MQ для z/OS. . . . . . . . . . . . . 88
5.3.4. Структура и создание менеджера очередей. . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.5. Менеджер очередей по умолчанию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3.6. Объект-менеджер очередей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.7. Запуск и останов менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.8. Сетевой доступ к менеджеру очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.3.9. Слушатель WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.10. Инициатор каналов WebSphere MQ для z/OS. . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.11. Очередь недоставленных сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.12. Командный сервер. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.13. Журнализация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.14. Восстановление носителя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.15. Журналы ошибок. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.16. 64-разрядное оборудование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Глава 6. Технические основы организации очередей сообщений . . . . . . . . . . . . . . . . . 109
6.1.
Интерфейс очередей сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1.1. Дескриптор сообщения WebSphere MQ (MQMD). . . . . . . . . . . . . . . . . . . . . 110
6.1.2. Коды завершения и причины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.1.3. MQCONN и MQCONNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.1.4. MQOPEN и MQCLOSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.1.5. MQPUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.1.6. MQPUT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.1.7. MQGET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.1.8. MQBEGIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Оглавление IX
6.1.9. MQCMIT и MQBACK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.1.10. MQINQ и MQSET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.
6.1.11. MQDISC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.1. Разрешение названия очереди. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.2. Объекты локальных очередей и транспортные очереди. . . . . . . . . . . . . . . 121
6.2.3. Объекты псевдонимов очередей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.2.4. О
бъекты модельных очередей и динамическое создание локальных очередей сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.2.5. Объекты удаленных очередей. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.2.6. Атрибуты по умолчанию и контроль полномочий. . . . . . . . . . . . . . . . . . . . 131
6.3.
6.2.7. Состояние и онлайновый мониторинг очередей. . . . . . . . . . . . . . . . . . . . . 132
Применение триггеров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3.1. Порождение триггерных событий. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.3.2. Очереди инициации и триггерные сообщения. . . . . . . . . . . . . . . . . . . . . . . 135
6.3.3. Триггерный монитор. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Глава 7. Взаимодействие менеджеров очередей и клиентские подключения
в WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.1.
Каналы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.1.1. Введение в клиентские каналы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.2.
7.1.2. Канальные агенты (MCA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Запуск и останов каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.2.1. Понятие состояния канала. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.3.
7.2.2. Названия каналов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Клиентские каналы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.3.1. Функционирование каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.3.2. Канальные объекты серверных подключений. . . . . . . . . . . . . . . . . . . . . . . 144
7.3.3. Замечания о безопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.3.4. Настройка клиентского MCA для подключения к менеджеру. . . . . . . . . . . 145
7.3.5. Канальные объекты клиентских подключений . . . . . . . . . . . . . . . . . . . . . . 146
7.4.
7.3.6. Таблица определений клиентских каналов (CCDT) . . . . . . . . . . . . . . . . . . . 147
Распределенные каналы сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.4.1. Отправка сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.4.2. Пакеты. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.4.3. Неоднозначные каналы и порядковые номера сообщения. . . . . . . . . . . . . 151
Оглавление
7.4.4. Интервалы разъединения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.4.5. Названия соединений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.4.6. Объекты receiver-каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.4.7. Объекты requester-каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.4.8. Объекты sender-каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.4.9. Объекты server-каналов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.4.10. Допустимые пары объектов – распределенных каналов сообщений. . . . . 154
7.4.11. Ошибки доставки сообщений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.4.12. Работа с очередью недоставленных сообщений. . . . . . . . . . . . . . . . . . . . . 157
7.5.
7.4.13. Инициирование канала. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Автоопределение каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.5.1. Автоопределение клиентских каналов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.5.2. Автоопределение распределенных каналов сообщений. . . . . . . . . . . . . . . 159
Глава 8. Кластеры менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.1.
Обзор понятий кластеризации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8.1.1. Менеджерыочередей с полным и частичным репозиторием . . . . . . . . . . 163
8.1.2. Названия кластеров. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.1.3. Настройка менеджера очередей с полным репозиторием. . . . . . . . . . . . . 164
8.1.4. Кластерные каналы сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
8.1.5. Кластерные receiver-каналы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.1.6. Кластерные sender-каналы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
8.1.7. Совместный доступ к объектам-очередям в кластерах. . . . . . . . . . . . . . . . 168
8.1.8. Идентификатор менеджера очередей (QMID). . . . . . . . . . . . . . . . . . . . . . . 170
8.2.
8.1.9. Подписки и публикации в кластере . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Просмотр сведений из репозитория кластера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.2.1. Просмотр сведений из репозитория через MQSC. . . . . . . . . . . . . . . . . . . . 173
8.3.
8.2.2. Просмотрсведений из репозитория в WebSphere MQ Explorer . . . . . . . . . 175
Работа с менеджерами очередей в кластере . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.3.1. Приостановкаи возобновление работы менеджера очередей в кластере. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.3.2. Сброс членства менеджера очередей в кластере . . . . . . . . . . . . . . . . . . . . 180
8.3.3. Этапы подключения менеджера очередей к кластеру. . . . . . . . . . . . . . . . . 180
8.4.
8.3.4. Этапы удаления менеджера из кластера . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Балансировка нагрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.4.1. Работас привязкой при открытии и без фиксированной привязки . . . . . 186
Оглавление
XI
8.4.2. Алгоритм балансировки нагрузки. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.4.3. Порядковые номера мест назначения сообщений. . . . . . . . . . . . . . . . . . . . 188
8.4.4. Блокировка очереди на запись. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.4.5. Балансировканагрузки и локальное размещение очередей . . . . . . . . . . . 189
8.4.6. Ранг менеджеров и очередей сообщений . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.4.7. Приостановка менеджеров очередей в кластере. . . . . . . . . . . . . . . . . . . . . 190
8.4.8. Состояние канала. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
8.4.9. Приоритет менеджеров и очередей сообщений . . . . . . . . . . . . . . . . . . . . . 190
8.4.10. Ограничение кластерных подключений от менеджера. . . . . . . . . . . . . . . . 191
8.4.11. Весовая оценка менеджеров. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Глава 9. Обмен сообщениями с использованием WebSphere MQ:
практическое введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.1.
Обзор глав с практическими заданиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.1.1
9.2.
Администрирование менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . 194
9.1.2 Программы-примеры в WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Настройка окружения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.2.1. Установка WebSphere MQ V6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.2.2
Привилегии администратора WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . 195
9.2.3. Доступ к примерам WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.3.
9.2.4. О Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Обмен сообщениями с помощью локального менеджера очередей . . . . . . . . . . . 196
9.3.1. Создание менеджера очередей по умолчанию . . . . . . . . . . . . . . . . . . . . . . 196
9.3.2. Запуск менеджера очередей по умолчанию . . . . . . . . . . . . . . . . . . . . . . . . 198
9.3.3
Создание локальной очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
9.3.4. Отображение атрибутов новой очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
9.3.5. Модификация атрибутов объекта очереди . . . . . . . . . . . . . . . . . . . . . . . . . 203
9.3.6
Добавление тестовых сообщений в очередь . . . . . . . . . . . . . . . . . . . . . . . . 204
9.3.7. Просмотр сообщений, добавленных в очередь . . . . . . . . . . . . . . . . . . . . . 205
9.3.8. Определение и использование псевдонимов локальных очередей . . . . . 207
9.3.9. Завершение и перезапуск менеджера очередей . . . . . . . . . . . . . . . . . . . . . 209
9.3.10. Извлечение сообщений из очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
9.3.11. Удаление объекта очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.3.12. Создание псевдонима для менеджера очередей с использованием объекта удаленной очереди . . . . . . . . . . . . . . . . . . . . . 212
XII
Оглавление
9.3.13. Указание менеджера очередей при обращении к очереди. . . . . . . . . . . . . 213
9.4.
9.3.14. Удаление менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Создание служб обработки запросов и ответов на основе очереди . . . . . . . . . . . . 215
9.4.1. Создание и запуск менеджера очередей – основы службы . . . . . . . . . . . . 215
9.4.2. Создание очереди-основы службы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
9.4.3. Ручное объявление очереди ответов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
9.4.4. Добавление и анализ тестового запроса . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
9.4.5. Очистка очереди-основы службы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.4.6. Создание определения процесса для службы . . . . . . . . . . . . . . . . . . . . . . 219
9.4.7. Создание очереди инициации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.4.8. Активация триггера для очереди-основы службы . . . . . . . . . . . . . . . . . . . 221
9.4.9. Запуск триггерного монитора WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . 221
9.4.10. Отправка запроса службе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9.4.11.Создание объекта модельной очереди для динамической очереди ответов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
9.5.
9.4.12.Отправка Запроса с использованием временной динамической очереди ответов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Рассылка сообщений по подписке в WebSphere MQ с помощью JMS . . . . . . . . . . 226
9.5.1. Настройка среды JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
9.5.2. Создание и запуск менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.5.3. Запуск брокера на менеджере очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
9.5.4. Настройка менеджера очередей для работы с JMS . . . . . . . . . . . . . . . . . . 230
9.5.5. Настройка простого JMS-провайдера. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
9.5.6. Настройка JMS с помощью JMS Administration tool. . . . . . . . . . . . . . . . . . 231
9.5.7. Копирование примера JMS-приложения WebSphere MQ . . . . . . . . . . . . . . 232
9.5.8. Модификация примера JMS-приложения WebSphere MQ . . . . . . . . . . . . . 232
9.5.9. Компиляция приложения-примера. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
9.5.10. Запуск приложения-примера в режиме подписчика . . . . . . . . . . . . . . . . . 233
9.5.11. Запуск программы-примера в режиме издателя . . . . . . . . . . . . . . . . . . . . 234
Глава 10. Построение инфраструктуры WebSphere MQ:
практическое руководство . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.1. Настройка окружения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
10.2. Подключение к менеджеру очередей в режиме клиента . . . . . . . . . . . . . . . . . . . . . 236
10.2.1. Создание и запуск слушателя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
10.2.2. Создание объекта канала серверного подключения. . . . . . . . . . . . . . . . . . 238
Оглавление
XIII
10.2.3. Подключение с использованием переменной окружения MQSERVER . . . 239
10.2.4.Подключение с использованием объекта канала клиентского подключения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
10.2.5. Удаленное администрирование менеджера очередей. . . . . . . . . . . . . . . . . 243
10.2.6. Пример публикации-подписки для JMS, использующий клиентское подключение . . . . . . . . . . . . . . . . . . . . . . . . . . 246
10.3. Построение центрально-лучевой инфраструктуры . . . . . . . . . . . . . . . . . . . . . . . . . 247
10.3.1. Создание очереди недоставленных сообщений для центрального менеджера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
10.3.2. Создание объекта receiver-канала для центрального менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.3.3. Создание и запуск периферийного менеджера очередей со слушателем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.3.4. Создание транспортной очереди для периферийного
менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.3.5. Создание объекта sender-канала для периферийного
менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
10.3.6. Поверка канала с помощью команды ping WebSphere MQ. . . . . . . . . . . . . 251
10.3.7. Настройка и активация канала связи с центральным
менеджером очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
10.3.8. Отправка тестового сообщения по каналу центральному менеджеру очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
10.3.9. Создание объекта receiver-канала для периферийного менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
10.3.10.Создание транспортной очереди для центрального менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
10.3.11.Создание объекта sender-канала для центрального менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
10.3.12.Локальное определение удаленной очереди . . . . . . . . . . . . . . . . . . . . . . . . 256
10.3.13.Определение очереди ответов для периферийного менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
10.3.14. Запрос службы echo с периферийного менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
10.4. Создание кластеров менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
10.4.1. Создание менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
10.4.2. Назначение менеджеров очередей с полными репозиториями . . . . . . . . 259
10.4.3. Создание объектов кластерных receiver-каналов . . . . . . . . . . . . . . . . . . . . 260
XIV
Оглавление
10.4.4. Создание объектов кластерных sender-каналов . . . . . . . . . . . . . . . . . . . . . 261
10.4.5. Просмотр сведений о кластере. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
10.4.6. Предоставление общего доступа к очередям кластера. . . . . . . . . . . . . . . . 263
10.4.7. Активация балансировки нагрузки для локального экземпляра очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
10.4.8. Балансировка нагрузки по обработке сообщений очередями . . . . . . . . . . 265
10.4.9. Предоставление общего доступа к службе echo в кластере. . . . . . . . . . . 265
10.4.10. Предоставление общего доступа к очереди echo в кластере . . . . . . . . . 266
Глава 11 Защита инфраструктуры WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
11.1. Администрированиеновой копии WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . 268
11.2. Предоставление доступа к ресурсам менеджеров очередей . . . . . . . . . . . . . . . . . . 268
11.2.1. Object Authority Manager (OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
11.2.2. Полномочия для объектов в WebSphere MQ для z/OS . . . . . . . . . . . . . . . . 273
11.3. Установка контекста идентификационных данных клиентских приложений . . . . . 273
11.3.1. Процедура установки идентификационных данных в WebSphere MQ по умолчанию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
11.3.2. Идентификатор пользователя MCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
11.4. Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.4.1. Поддержка SSL в WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.4.2. CipherSpec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.4.3. Протокол TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
11.4.4. Обязательная и необязательная SSL-аутентификация клиентов . . . . . . . 276
11.4.5. Хранилище сертификатов менеджера очередей . . . . . . . . . . . . . . . . . . . . . 276
11.4.6. Администрирование хранилищ сертификатов WebSphere MQ . . . . . . . . . 277
11.4.7. Клиентские приложения WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
11.4.8. Доступ клиентских Java-приложений к WebSphere MQ . . . . . . . . . . . . . . . 278
11.4.9. SSL и WebSphere MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
11.4.10.Список отозванных сертификатов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
11.4.11.Выбор ЦС . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
11.4.12.Проверкасоставного имени с помощью атрибута SSL- «Peer» . . . . . . . . . 282
11.4.13.Совместимость со стандартом Federal Information Processing Standard (FIPS) . . . . . . . . . . . . . . . . . . . . . . . 283
11.5. Webspere MQ Internet Pass-Thru (IPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Оглавление
XV
Глава 12. Устранение неполадок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
12.1. Базовая информация, предоставляемая MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
12.1.1. Сообщения AMQXXXX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
12.1.2. Коды причины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
12.1.3. Журналы ошибок менеджеров очередей. . . . . . . . . . . . . . . . . . . . . . . . . . . 287
12.1.4. Системные журналы ошибок WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . 287
12.1.5. Расположение журналов ошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
12.1.6. Технология FFST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
12.1.7. Документация по WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
12.2. Устранение известных неполадок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
12.2.1. Сайт поддержки WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
12.2.2. Установка исправлений и обновлений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
12.2.3. «Молнии» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
12.2.4. Поиск APAR и Technote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
12.2.5. Дополнительные источники информации . . . . . . . . . . . . . . . . . . . . . . . . . . 290
12.2.6. Модуль Healthcheck для WebSphere MQ Explorer . . . . . . . . . . . . . . . . . . . . 291
12.3. Общие проблемы при построении инфраструктуры . . . . . . . . . . . . . . . . . . . . . . . . 291
12.3.1. Устранение неполадок распределенных каналов сообщений. . . . . . . . . . . 291
12.3.2. Устранение неполадок инициации каналов сообщений . . . . . . . . . . . . . . . 292
12.3.3. Устранение неполадок кластерных каналов сообщений . . . . . . . . . . . . . . 293
12.4. Общие проблемы с доступом к инфраструктуре . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
12.4.1. Устранение сбоев подключения к менеджеру очередей . . . . . . . . . . . . . . 295
12.4.2. Устранение неполадок отправки сообщений . . . . . . . . . . . . . . . . . . . . . . . . 296
12.4.3. Устранение неполадок извлечения сообщений . . . . . . . . . . . . . . . . . . . . . . 297
12.4.4. Устранение общих неполадок триггеров . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
12.4.5. Поиск сообщений, отправленных в инфраструктуру . . . . . . . . . . . . . . . . . 298
12.5. Сбор сведений для обращения в сервисную службу . . . . . . . . . . . . . . . . . . . . . . . . 300
12.5.1. Составление описания проблемы. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
12.5.2. Описание окружения. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
12.5.3. Описание использования WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . 301
12.5.4. Подготовка описания сбоя для отправки в IBM Service . . . . . . . . . . . . . . . 301
12.5.5. Воспроизведение неполадок. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
12.5.6. Трассировка WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
XVI
Оглавление
Приложение A. Новое в WebSphere MQ V6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
WebSphere MQ Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Команды PCF в WebSphere MQ для z/OS V6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64-разрядные менеджеры очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internet Protocol Version 6 (IPv6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Изменения в поддержке SSL в Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Усовершенствования SSL и TLS и сертификация FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Встроенный брокер публикации-подписки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSphere MQ как транспорт для Web-сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Усовершенствования групп общих очередей в z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Балансировка нагрузки в кластерах менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . .
Администрирование подключений к менеджеру очередей . . . . . . . . . . . . . . . . . . . . . . . . .
Унифицированный метод запуска и остановки слушателей . . . . . . . . . . . . . . . . . . . . . . . .
Запуск и остановка произвольных служб вместе с менеджерами очередей . . . . . . . . . .
Фильтрация информации о менеджерах очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Улучшенный мониторинг в реальном времени . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Учет использования менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Сбор статистики . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Трассировка инфраструктуры WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Улучшения ведения журналов на распределенных платформах . . . . . . . . . . . . . . . . . . . .
Динамическое конфигурирование менеджеров очередей в z/OS . . . . . . . . . . . . . . . . . . . .
Шунты журналов в WebSphere MQ для z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
306
306
306
307
307
307
308
308
308
309
309
309
310
310
311
311
311
312
312
313
313
Приложение B. Краткий справочник . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Управляющие команды WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Команды CL в WebSphere MQ для iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Команды Message Queue Interface (MQI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Командный интерфейс WebSphere MQ Script (MQSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Объект менеджера очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Объекты слушателей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Объекты служб . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Объекты списки имен . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Атрибуты объекта список имен . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Записи кластерных очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Записи кластерных менеджеров очередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Каналы и объекты каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Записи состояния каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Оглавление XVII
Примечания
Информация в этом руководстве охватывает продукцию и услуги, предлагаемые
в США.
Предложения IBM по услугам, товарам и их возможностям, описанным в руководстве,
могут не действовать в других странах. За информацией о текущем ассортименте до­
ступных продуктов и услуг обращайтесь в местные представительства IBM. Явные и
неявные упоминания услуг, продуктов и их возможностей не означают необходи­
мость их применения. Допускается их замена любыми функционально эквивалент­
ными продуктами и службами сторонних производителей, не нарушающими прав на
интеллектуальную собственность IBM, при этом ответственность за проверку совме­
стимости и продуктивности решений сторонних производителей принимает на себя
пользователь.
IBM может обладать патентами или патентными заявками на технологии, описанные
в настоящем руководстве, предоставление которых не означает наличия лицензии на
технологии. Письменные запросы лицензий следует направлять по адресу IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504­1785 USA.
Приведенный ниже абзац не относится к Соединенному Королевству и иным странам, законодательству которых противоречит данное положение: КОРПОРАЦИЯ
IBM ПРЕДОСТАВЛЯЕТ ДАННОЕ РУКОВОДСТВО «КАК ЕСТЬ» И НЕ ДАЕТ НИКАКИХ
ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ (НО НЕ ОГРАНИЧИВАЯСЬ)
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПАТЕНТНОЙ ЧИСТОТЫ, КОММЕРЧЕСКОЙ ПРИ­
ГОДНОСТИ И СООТВЕТСТВИЯ КОНКРЕТНОМУ НАЗНАЧЕНИЮ. В отдельных госу­
дарствах отказ от явных и подразумеваемых гарантий по ряду сделок запрещен, так
что указанное ограничение может вас не коснуться.
В руководстве возможны опечатки и технические неточности. Приводимые в нем
сведения регулярно обновляются, соответствующие изменения будут внесены в но­
вую редакцию руководства. Корпорация IBM оставляет за собой право в любое время
без уведомления модифицировать описанные в этом руководстве продукты и про­
граммные средства.
Любые ссылки на сайты сторонних компаний в этом руководстве носят исключи­
тельно информационный характер и не свидетельствуют об их поддержке корпора­
цией IBM; риск, связанный с применением ресурсов этих сайтов, принимает на себя
пользователь.
По своему усмотрению и без каких-­либо обязательств IBM может использовать и рас­
пространять любые предоставленные сведения.
За информацией о сторонних продуктах обращайтесь к производителям, их публи­
кациям и другим открытым источникам. IBM не тестировала эти продукты и не может
XVIII
Примечания
подтвердить точность оценок производительности, совместимости и прочих пара­
метров. Соответствующие вопросы следует направлять поставщикам этих продуктов.
Настоящее руководство содержит в качестве примеров данные и отчеты, используе­
мые в повседневной практике предприятий. Для наиболее полной иллюстрации
примеров в руководстве встречаются имена лиц, названия компаний, торговых ма­
рок, товаров. Все они вымышлены, и любые совпадения с именами и данными реаль­
но существующих компаний случайны.
Авторское право
Данное руководство содержит примеры исходного кода прикладных программ, ко­
торые иллюстрируют приемы программирования на различных платформах. Вы мо­
жете копировать, изменять и распространять их в любом виде без отчислений
в пользу IBM, руководствуясь целями разработки прикладных программ, включая
коммерческие, в соответствии с интерфейсом прикладного программирования плат­
формы, для которой предназначены эти программы. Примеры не подвергались все­
объемлющему тестированию, поэтому IBM не может явно или неявно гарантировать
надежность, удобство в обслуживании и работоспособность приведенных примеров.
Вам разрешено копировать, изменять и распространять программы-примеры, содер­
жащиеся в данном руководстве, в любом виде без отчислений в пользу IBM с целью
разработки, применения, в том числе коммерческого, и дистрибуции прикладных
программ, сообразуясь с интерфейсами прикладного программирования корпора­
ции IBM.
Торговые марки
Торговыми марками International Business Machines Corporation в Соединенных Шта­
тах и/или других странах являются:
AIX 5L™
IBM®
Redbooks™
AIX
iSeries™
SupportPac™
CICS®
MQSeries®
TXSeries®
DB2
OS/400
WebSphere®
®
®
developerWorks®
server®
HACMP
®
®
Parallel Sysplex®
z/OS®
RACF®
zSeries®
Redbooks (логотип)
™
Торговыми марками других компаний являются:
Java, Java Naming and Directory Interface, JDK, JVM, J2EE, Solaris и все торговые марки
на базе Java являются торговыми марками Sun Microsystems, Inc. в Соединенных Шта­
тах и/или других странах.
ActiveX, Microsoft, Windows и логотип Windows являются торговыми марками Micro­
soft Corporation в Соединенных Штатах и/или других странах.
UNIX является зарегистрированным товарным знаком The Open Group в Соединен­
ных Штатах и других странах.
Примечания
XIX
Linux является торговой маркой Линуса Торвальдса (Linus Torvalds) в Соединенных
Штатах и/или других странах.
Названия иных компаний, продуктов или услуг могут являться торговыми марками
или знаками обслуживания других компаний.
XX
Примечания
Предисловие
Цель данной книги из серии IBM® Redbook – расширить понимание продукта IBM
WebSphere® MQ клиентами и повысить ценность их инвестиций в него. Целостное ви­
дение WebSphere MQ поможет в построении надежных и масштабируемых решений,
основанных на гарантируемой WebSphere MQ однократной доставке сообщений.
Книга описывает основные понятия и преимущества технологии организации оче­
редей сообщений и является новой редакцией завоевавшего популярность издания
REDP-0021 (серия Redpaper), посвященного IBM WebSphere MQ версий 5.0 и 5.2.
Книга служит обзором архитектуры и введением в технические основы признанного
и надежного продукта WebSphere MQ.
Команда, написавшая книгу
Появление этой книги стало результатом сотрудничества команды специалистов со
всего мира, работающих в Центре Международной организации технической под­
держки (ITSO, International Technical Support Organization) в г. Сан-Хосе.
Сайда Дэвис (Saida Davies) – руководитель проектов ITSO с 15-летним стажем ра­
боты в сфере ИТ. Ей принадлежит несколько книг IBM Redbook™, посвященных раз­
нообразным сценариям бизнес-интеграции на распределенных платформах и плат­
форме IBM z/OS®. Сайда имеет опыт разработки архитектуры и проектирования ре­
шений WebSphere MQ, прекрасно знает операционную систему z/OS и владеет прак­
тическими навыками работы с операционными системами IBM и сторонних постав­
щиков. Как старший ИТ-специалист IBM Global Services, она работает с клиентами
корпорации и занимается разработкой служб для z/OS и WebSphere MQ на платфор­
мах z/OS и Microsoft® Windows®. В ее задачи входят разработка архитектуры, проек­
тирование, управление проектами и внедрение программного обеспечения на авто­
Предисловие
XXI
номных системах и в среде Parallel Sysplex®. Вклад Сайды в реализацию проектов
компании неоднократно отмечен наградой Bravo Award. Сайда имеет степень в об­
ласти информатики и владеет программированием для системы z/OS.
Питер Бродхерст (Peter Broadhurst) – инженер по программному обеспечению
IBM Hursley, Великобритания. В настоящее время работает инженером сопровожде­
ния в команде службы поддержки WebSphere MQ 3-го уровня (Level 3). Выполняя свои
обязанности, Питер приобрел прочные знания продукта WebSphere MQ и его функ­
ций и познакомился с основными характеристиками решений, реализуемых на этой
технологической базе клиентами корпорации. Решая возникающие у них проблемы,
он проникся актуальными для клиентов задачами понимания и развития принципов
WebSphere MQ и задач бизнеса, которые тот решает. За время своей карьеры Питер
работал и над тестированием WebSphere MQ V6.0, где получил представление о новой
функциональности очередной, шестой версии. Работа Питера в IBM началась после
того, как Университет Саутгемптона присудил ему степень бакалавра в области вы­
числительной техники (Bachelor of Engineering in Computer Engineering).
Команда авторов руководства благодарит тех, кто помог составить начальный план
книги:
Крейг Бот (Craig Both), руководитель команды тестирования WebSphere MQ FV,
инженер по программному обеспечению, IBM Software Group
Application and Integration Middleware Software, IBM Hursley, Великобритания
Гэри О’Коннор (Gary O’Connor), ИТ-специалист, разработчик
IBM Global Services, Application Management Services, IBM U.K.
Сушил Шарма (Sushil Sharma), служба поддержки WebSphere MQ Distributed L3 Service
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Пол Слейтер (Paul Slater), отдел WebSphere MQ Scenarios Testing, инженер по про­
граммному обеспечению
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Опе Сойаннво (Ope Soyannwo), инженер по программному обеспечению и консуль­
тант по .NET
iMeta Technologies, Великобритания
XXII
Предисловие
Джерри Л. Стивенс (Jerry L. Stevens), отдел технической стратегии и планирования
WebSphere MQ
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Команда авторов руководства благодарит своих рецензентов:
Саймон Блак (Simon Bluck), служба поддержки WebSphere MQ Level 3 Service
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Энди Эмметт (Andy Emmett), служба поддержки WebSphere MQ Level 3 Service
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Эмир Гарза (Emir Garza)
ИТ-специалист, консультант
IBM Software Group, Application and Integration Middleware Software
IBM Hursley, Великобритания
Как стать автором
Присоединяйтесь к нам во время продолжительных выездных программ от двух до
шести недель! Примите участие в разработке руководств IBM Redbook, посвященных
отдельным программным продуктам и решениям, получая при этом практический
опыт работы с передовыми технологиями. Вы будете работать с техническими спе­
циалистами корпорации IBM, деловыми партнерами и (или) покупателями.
Ваше участие будет способствовать распространению программных продуктов IBM
и удовлетворению запросов потребителей. Вы сможете наладить контакты в исследо­
вательских лабораториях IBM и повысить личную производительность и конкурен­
тоспособность.
Дополнительная информация о командировках и подаче заявок доступна по адресу:
ibm.com/redbooks/residencies.html.
Отзывы и комментарии приветствуются
Ваше мнение и комментарии важны для нас!
Мы хотим, чтобы наши материалы были максимально полезны. Отправьте ваши ком­
ментарии, касающиеся данного руководства или других технических руководств
(Redbooks), одним из следующих способов.
 С помощью нашего онлайнового форума Contact us (Свяжитесь с нами), посвя­
щенного Redbook, который находится в Интернете по адресу:
ibm.com/redbooks
 Отправьте ваши комментарии по электронной почте на адрес:
[email protected]
 Отправьте ваши комментарии в письменной форме по почте на адрес:
IBM Corporation, International Technical Support Organization
Предисловие XXIII
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Внесенные исправления
В этом разделе описаны внесенные в книгу исправления технического характера.
Настоящее издание также может включать незначительные неустановленные изме­
нения и правки редактора.
Исправления в руководстве SG24-7128-00
WebSphere MQ V6.0 Fundamentals
внесенные или обновленные 15 декабря 2005 г.
Ноябрь 2005 г.
Эта редакция отражает добавление, удаление или изменение следующей вновь опи­
санной информации.
Новая информация
Настоящее руководство IBM Redbook WebSphere MQ Fundamentals, SG24-7128 допол­
няет издание Redpaper MQSeries Primer, REDP-0021 следующей информацией:
 изменения в WebSphere MQ Version 6;
 усовершенствования в WebSphere MQ Version 6;
 основы WebSphere MQ Version 6.
XXIV
Предисловие
1
Обзор
Прочтя эту книгу, вы узнаете о таких новых элементах функциональности WebSphere
MQ Version 6.0, как WebSphere MQ Explorer, 64-разрядные менеджеры очередей
в Unix® и изменения в алгоритме балансировки нагрузки кластеров. Практические
разделы книги размещены после глав, дающих общее техническое представление
об аспектах реализации. По своему усмотрению практический материал книги мож­
но прорабатывать в сочетании с чтением глав технического характера. Это соз­даст
для вас рабочую обстановку, в которой вы сможете лучше понять изложенные идеи.
Задача WebSphere MQ – обеспечить возможность связи новых и существующих при­
ложений. Помимо этого, инфраструктура WebSphere MQ отделяет связь приложений
от отдельно взятых протоколов коммуникации и особенностей каждого из объ­­е­диненных сетью компьютеров.
Приложения, имеющие доступ к инфраструктуре WebSphere MQ, могут разрабаты­
ваться с участием целого спектра принципов и языков программирования и выпол­
няться в широком круге программных и аппаратных сред. WebSphere MQ может
исполь­зоваться для интеграции и расширения возможностей различных имеющихся
инфраструктур в рамках информационно-технологических (ИТ) систем организа­
ций и предприятий.
На протяжении книги мы не станем заострять внимание на том, как именно взаимо­
действовать с WebSphere MQ, используя тот или иной язык программирования.
Напро­тив, речь будет идти о базовых принципах WebSphere MQ, которые должны
быть поняты каждым, кто разрабатывает приложение, способное обращаться к инфра­
структуре WebSphere MQ.
Сила продукта WebSphere MQ – в гибкости, соединенной с надежностью, защищен­
ностью и возможностью масштабирования. Гибкость WebSphere MQ обеспечивает бо­
Обзор гатый выбор возможных альтернативных архитектур и подходов к реализации. При­
нятие взвешенного решения с учетом таких возможностей способно упростить как
разработку приложений, так и администрирование инфраструктуры WebSphere MQ.
В результате в книге не делается различий между администраторами и разработчика­
ми приложений WebSphere MQ. Такое более широкое видение является залогом
осознанного выбора архитектуры и реализации инфраструктуры и получающих до­
ступ к ней приложений.
В главе 2 «Понятие очередей сообщений» будут введены базовые понятия очередей
сообщений.
Далее, в главе 3 «Средства поддержки очередей сообщений в WebSphere MQ» мы про­
ведем обзор возможностей WebSphere MQ в каждой из областей, представленных
в главе 2.
Глава 4 «Создание приложений для доступа к инфраструктуре WebSphere MQ» посвя­
щена тому, как именно возможности WebSphere MQ могут использовать приложения,
предоставляющие доступ к системным службам.
В главе 5 «Менеджеры очередей: общее представление и настройка» мы опишем важ­
нейшие стороны организации и работы образующих инфраструктуру WebSphere MQ
менеджеров очередей.
В главе 6 «Технические основы организации очередей сообщений» речь пойдет о
специфических действиях, выполняемых приложением в отношении менед­жера
очередей, а также том, как менеджер конфигурируется для предоставления возмож­
ностей приложениям, которые к нему обращаются.
Гл а в а 7 «Взаимодействие менеджеров очередей и клиентские подключения
в Web Sphere MQ» описывает, как инфраструктура WebSphere MQ выходит за рамки
одной машины и распространяется по сети.
Затем в главе 8 «Кластеры менеджеров очередей» мы расскажем о том, как, объединяя
менеджеры очередей в кластеры, добиться упрощения администрирования и гибкос­
ти масштабирования системы.
Глава 9 «Обмен сообщениями с использованием WebSphere MQ: практическое введе­
ние» станет практическим вводным курсом по межточечному обмену сообщениями
и сообщениями публикации и подписки с использованием JMS с WebSphere MQ.
Глава 10 «Построение инфраструктуры WebSphere MQ: практическое руководство»
на практике раскроет вопросы организации инфраструктуры WebSphere MQ при по­
мощи центрально-лучевой архитектуры и гибких кластеров менеджеров очередей
сообщений.
Глава 11 «Защита инфраструктуры WebSphere MQ» знакомит с моделью безопасности
WebSphere MQ и тем, как ею можно воспользоваться для защиты инфраструктуры
WebSphere MQ.
Наконец, в последней, главе 12 «Устранение неполадок» представлены сведения, полез­
ные всем пользователям WebSphere MQ для понимания информации, полученной от
системы, и способов разрешения проблем, которые могут возникнуть в ходе работы.
Глава 1
2
Понятие очередей
сообщений
В этой главе книги мы опишем те сферы, в которых компании могут испытывать
затруд­нения в разработке ИТ-решений, представим технологию очередей сообще­
ний и вкратце обозначим ту роль, которую она способна играть в преодолении этих
трудностей.
Глава посвящена обсуждению следующих вопросов:







Базовые понятия
Упрощение
Расширяемость и скорость работы
Надежность служб и целостность данных
Защита
Высокая готовность системы
Мониторинг и учет операций
Понятие очередей сообщений
2.1. Базовые понятия
В ИТ-инфраструктуре компании может параллельно существовать множество техно­
логий. Зачастую в нее входят различные аппаратные платформы, языки программи­
рования, операционные системы и системы коммуникаций.
На базе этой инфраструктуры организуются службы, каждая из которых обеспечива­
ет возможность выполнения действия или получения информации. Службы могут
предоставляться для внутренних нужд компании или использования поставщиками
и клиентами предприятия.
Как одно целое, службы и предназначенная для их поддержки инфраструктура обра­
зуют систему. Для представления любой точки в такой системе, способной быть
местом размещения службы, могущей запрашивать службу или соединять себе подоб­
ные воедино, в книге используется общее понятие узел. Узлы могут являться отдель­
ными аппаратными серверами, а могут группами встречаться в программных компо­
нентах одного сервера.
Новые службы способны вводить в систему новые технологии. Однако им зачастую
необходимо взаимодействовать со службами, которые уже существуют, используя для
этого существующий набор технологий.
К тому же компания может испытывать желание технологически состыковать соб­
ственную систему с системами других предприятий или предоставлять внешние
интер­фейсы к своей системе существующим и потенциальным клиентам или бизнеспартнерам.
2.1.1. Промежуточное ПО
Программные приложения, разработанные компанией с целью запроса и предостав­
ления служб, требуют связи со службами, реализуемыми системой. Эти службы нахо­
дятся в разных ее узлах, а те могут быть созданы с использованием различных инфра­
структурных компонентов и технологий.
Технологии промежуточного ПО образуют абстрактный слой между инфраструктур­
ными компонентами и приложениями, стремящимися получить доступ к инфра­
структуре для реализации служб. В дальнейшем промежуточное ПО становится
частью инфраструктуры, играя в системе роль общего слоя, объединяющего узлы.
Слой промежуточного ПО способен упростить разработку и сопровождение прило­
жений, реализующих сами службы или запросы к ним, что позволяет сосредоточить
внимание на бизнес-логике служб, а не на сложностях доступа к имеющимся в систе­
ме службам.
Создание очередей сообщений – технология промежуточного ПО, заметно упрощаю­
щая коммуникации между узлами одной системы, а также между узлами связи разных
систем. Создание очередей сообщений дает службам возможность гибкого взаимо­
действия, не требующего детального знания целевой службы или наличия сведений
о ее текущей доступности. Надежной связи отдельных служб можно добиться незави­
симо от сложности инфраструктуры, объединяющей узлы конкретной системы.
Основу упомянутой технологии образуют два главных понятия: сообщение и очередь.
Глава 2
2.1.2. Сообщения
Входящему в систему узлу нередко требуется передать данные или запросить службу
другого узла в той же или связанной с ней системе. Эту порцию информации или
запрос можно считать примерами сообщений.
Сообщение может содержать простые данные в формате символов или чисел, слож­
ную двоичную информацию, запрос, команду или смесь всего перечисленного. Важ­
но, чтобы любой целевой узел, принимающий сообщение, «понял» его формат. Одна­
ко объединяющая узлы инфраструктура приема и передачи сообщений не требует
единого понимания. Она должна лишь гарантировать поддержание целостности
инфор­мации в сообщении и его правильную доставку по назначению.
Инфраструктура сообщений «понимает» различия между программными и аппарат­
ными составляющими, на которых работает тот или иной узел. Для обеспечения воз­
можности прочитать данные на разных программно-аппаратных платформах может
потребоваться перекодирование символьных и числовых данных. Инфраструктуру
сообщений можно настроить так, чтобы это перекодирование осуществлялось проз­
рачным образом и каждое сообщение осталось корректным при его получении.
Для передачи сообщения по назначению к нему может понадобиться добавить допол­
нительные данные, сопровождающие его при пересылке в инфраструктуре. Заметим,
что эти данные отделены от информации, содержащейся в сообщении, так же, как
конверт существует независимо от письма, которое в него вложено.
2.1.3. Очереди
Очередь – это контейнер для сообщений. Новые сообщения помещаются в конец
очереди, а размещенные в ней, как правило, извлекаются из начала. Движение сооб­
щений в пределах очереди показано на рис. 2.1 на стр. 5.
Рис. 2.1. Очередь и прохождение сообщений
Также для извлечения сообщений могут использоваться идентификаторы, которые
с ними связаны. Сообщениям можно назначить приоритет, чтобы сообщения с высо­
ким приоритетом извлекались из очереди быстрее сообщений с низким приорите­
том, или логически сгруппировать так, чтобы одно из них зависело от другого.
Понятие очередей сообщений
Однако очереди не призваны стать заменой баз данных. Они оптимизированы для
небольшого количества сообщений, проходящих их до своей доставки по назна­
чению.
Эта простая, но действенная идея лежит в основе надежной и расширяемой инфра­
структуры приема и передачи сообщений – инфраструктуры очередей сообщений.
Понятие очереди используется в инфраструктуре очередей сообщений, в том числе,
для решения следующих задач.
Буфер между отправителем и получателем сообщений.
Служба, которая получает, потребляет и обрабатывает сообщения, может быть
не готова обрабатывать каждое сообщение в момент его поступления, поскольку
может быть занята обработкой другого сообщения или недоступна по какой-то
иной причине. В то же время сообщения не могут поступать с одинаковой интен­
сивностью или не поступать в периоды занятости; спрос на работу службы может
временно превышать ее возможности по обслуживанию. При наличии очереди
между отправителем сообщений и получателем отправитель может посылать
сооб­щения, не зная, доступен ли получатель в настоящее время.
Подобный режим работы называется асинхронным взаимодействием, так как
источ­ник может продолжить свою работу, как только сообщение будет помещено
в очередь. Сравните его с синхронным взаимодействием, при котором он должен
ожидать готовности получателя и полного завершения работы над сообщением
для того, чтобы продолжить свою работу.
 Пакетная обработка.
Служба может быть не настроена на обработку и потребление каждого сообщения
при получении, а будет, напротив, ждать достижения некоего порога сообщений
в конкретной очереди, чтобы обработать их как единый пакет или выполнить
обра­ботку всех сообщений, полученных в определенный период времени. Это
позволит службе воспользоваться эффективностью масштаба обработки, а воз­
можно, и обработать данные в тот период, когда другие связанные системы
и службы не функционируют.
 Буферы между промежуточными узлами системы.
При движении от отправителей к получателям сообщениям может требоваться
пройти промежуточные узлы системы. Количество узлов, которые пройдет сооб­
щение, а также место расположения пункта назначения сообщения может быть
неизвестно стороне отправления или оказаться изменено. Сетевые соединения
между промежуточными узлами или сами промежуточные узлы иногда могут быть
недоступны. Поместив очередь как буфер между всеми узлами системы, можно
ставить сообщения на ожидание в любой точке, где они останутся до тех пор, пока
узел или сетевое соединение не станет снова доступным, после чего сообщение
автоматически перейдет к следующему узлу.
2.1.4. Межточечный обмен сообщениями
Многие сообщения предназначены для потребления лишь однажды. Точка внутри
системы, где сообщение будет использовано, может быть как известна, так и неизве­ст­
на для отправителя. Однако сам отправитель обеспечивает инфраструктуру сообще­
Глава 2
ний достаточной информацией для того, чтобы доставить сообщение только одному
потребителю.
В режиме межточечного обмена сообщение приходит один и только один раз
в единственное корректное место своего назначения.
Процесс межточечного обмена можно представить двумя общими категориями.
 Обмен по принципу «отправил – забыл».
Сообщение передается службе, выполняющей действие на базе этого сообщения.
При его обработке служба может сформировать новое сообщение, но источник
запроса не получает никаких явных свидетельств происходящего.
Иллюстрацией этого может быть сообщение с обновлением информации в базе
данных или сообщение с подробностями события, факт наступления которого
требует тех или иных действий, к примеру отправки сообщений системным адми­
нистраторам.
 Обмен по принципу «запрос – ответ».
Сообщение передается службе, выполняющей действие на базе этого сообщения
и посылающей ответ для его отправителя.
Пример подобной работы – запрос информации в базе данных и посылаемый как
реакция на него ответ или сообщение-запрос с подробным описанием действия,
которое требует выполнения и может иметь несколько результатов, – исход тако­
го события отсылается как ответ.
2.1.5. Обмен сообщениями по принципу публикации-подписки
В процессе межточечного обмена каждый узел, которому нужна информация, должен
знать те конкретные службы, которые могут ему ее предоставить. Аналогично и служ­
бы, передающие информацию, должны знать о тех конкретных узлах, которым пере­
дают свои данные, и времени, когда это сделать.
Предоставляемые инфраструктурой очередей сообщений в рамках модели межто­
чечного обмена функции «отправил – забыл» и «запрос – ответ» служат решением
при множестве обстоятельств. Однако в отношении данных, перечисленных ниже,
модель межточечного обмена имеет ограничения.
 Информация о состоянии.
Со временем какая-то информация может меняться, и обращающийся к ней узел
системы может быть вынужден отслеживать ее изменения. При этом узлу должна
быть предоставлена информация при запуске обработки, после чего его необхо­
димо уведомлять о любых происходящих с ней изменениях.
Информация такого рода называется состоянием. Примером состояния служит
текущая цена акций компании, имеющая значение в любой момент времени, но
также могущая в любой момент измениться; узлу же, возможно, требуется отсле­
живать рыночные котировки во времени.
Для поддержания актуальности данных об изменениях информации по принципу
«запрос – ответ» узел должен посылать службе периодические запросы текущего
состояния информации. Для этого он должен знать об узлах, где расположена
служба предоставления информации. Такой подход называют опросом.
Понятие очередей сообщений
Опрос службы – неэффективный способ получения уведомлений об изменениях
состояния. Большое число запросов может вернуть одно и то же значение, а посы­
лающий запрос узел не получает информации об изменениях до отправки следую­
щего запроса. Меньшие интервалы опроса могут повысить точность известной
узлу информации, но повышают и требования к ресурсам службы и инфраструк­
туре системы.
 Информация о событии.
Ряд действий должен производиться службой при наступлении того или иного
события.
Информация с описанием события, которое наступило, называется информацией
о событии. Например, при каждой продаже товара, находящегося на складе, служ­
ба управления складом может требовать обновления складской информации или
отправки дополнительного заказа товара поставщику.
Возможности межточечного обмена позволяют отправлять службам сообщения
о единичных событиях, когда они происходят. Однако каждый узел, который обна­
руживает события или является их источником, должен знать обо всех узлах, где
расположены службы, которым требуются такие события, и отправлять каждой
из этих служб сообщение по очереди.
Модель публикации и подписки снимает эти ограничения.
В ней сообщения от одного или нескольких отправителей может получать произ­
вольное число потребителей информации. При этом отправитель носит название
издателя, а потребитель обозначается как подписчик.
Обмен по принципу публикации-подписки включает понятие темы, на которую,
демон­стрируя интерес, может подписаться любое количество потребителей инфор­
мации. Такое положение дел аналогично тому, как если бы кто-то подписался лишь
на журналы по интересным для него темам. Каждая тема предоставляет информацию
о конкретном состоянии или событии.
Издатель может посылать сообщения с информацией по той или иной теме всем
подписчикам этой темы, не зная, сколько таких подписчиков и на каких конкретно
узлах они расположены. По этой причине обмен по принципу публикации-подписки
полностью разрывает связь между поставщиком и потребителем информации.
Нуждаясь в информации о состоянии, подписчик может запросить текущее состоя­
ние информации при запуске обработки, а подписавшись на тему интересующей
информации, он будет автоматически уведомляться об изменениях.
Нуждаясь в информации о событии, подписчик будет автоматически уведомляться
о происходящих событиях, если подпишется на тему событий, представляющих для
него интерес.
Для упрощения работы публикации и подписки необходим брокер, хранящий сведе­
ния о том, какие подписчики на какие темы подписаны и как им доставляются сооб­
щения. Используя брокер, издатель может публиковать сообщения для всех подпис­
чиков, не зная подробно, что они собой представляют.
По одной теме может иметься несколько издателей; подписчик по одной теме может
являться источником публикуемых сведений по другим.
Глава 2
Модель обмена по принципу публикации-подписки является действенным механиз­
мом, дающим возможность организации логического потока обновляемой информа­
ции от источников информации до всех ее потребителей. Гибкость такого решения
обусловлена тем, что число подписчиков может динамически расти или падать без
уведомления издателей.
2.2. Упрощение
Процесс передачи сообщения от источника к получателю может быть сложным
и включать в себя пересылку через многочисленные промежуточные узлы и линии
связи, различные по типу, скорости, качеству. Иногда в линиях связи наблюдается
сбой, и сообщение не может достичь места своего назначения до восстановления
соединения. К тому же во время генерации сообщения узел, которому оно отправля­
ется, или промежуточный узел может оказаться недоступен либо быть занят.
Важной особенностью инфраструктуры очередей сообщений является то, что ресур­
сы разработки приложений, необходимые для решения этих проблем, как и другие
ресурсы, описанные далее в книге, серьезно сокращены.
При пользовании инфраструктурой очередей сообщений для надежной отправки
сообщения получателю необходимы следующие шаги.
1. Передать инфраструктуре очередей сообщений информацию, необходимую для
указания корректного места назначения или мест назначений данного сооб­
щения.
2. Передать сообщение инфраструктуре очередей сообщений.
3. При успешном завершении шага 2 приложение способно определить, что сооб­
щение успешно достигло места своего назначения.
Примечание. Механизмы гарантированной доставки инфраструктуры очередей сообщений мы обсудим в разделе 2.4 «Надежность служб и целостность
данных».
2.2.1. Разработка с акцентом на бизнес-логике
Разработка бизнес-приложений, реализующих службы или запросы к ним, может
оказаться дорогостоящим процессом, требующим значительного объема ресурсов.
Инфраструктура очередей сообщений позволяет прикладным программистам боль­
ше времени уделить бизнес-логике реализации службы, а не проблемам коммуника­
ции и непростому обслуживанию возникающих сбоев.
В отсутствие безопасной, гибкой и надежной инфраструктуры очередей сообщений
прикладной программист вынужден заниматься дополнительной разработкой, решая
следующие проблемы.
 Удаленная служба может быть временно недоступна в момент, когда к ней нужно
подключиться локальному приложению.
Понятие очередей сообщений
 Канал связи локального приложения и удаленной службы может быть недоступен
или дать сбой после того, как передача уже частично завершена.
 Удаленная служба может работать на аппаратной платформе, отличной от плат­
формы локального приложения и имеющей существенные отличия в формате
символьных и числовых данных.
 С момента написания приложения маршрут доступа к удаленной службе может
быть изменен.
 В сети может иметься несколько экземпляров интересующей службы, и приложе­
ние должно выбрать, к какому из экземпляров оно планирует подключиться.
 Действие, выполняемое конкретной службой, может быть связано с манипуляция­
ми конфиденциальными данными, а значит, работа службы может инициировать­
ся лишь авторизованным приложением.
 Данные, пересылаемые удаленной службе по каналу коммуникации, могут иметь
закрытый характер и требовать защиты при передаче. В этом случае приложение
должно обеспечить шифрование данных.
 Сбой связи с конкретной службой может оказать отрицательное влияние на допус­
тимость тех операций, которые приложение уже выполнило.
 Текущие потребности приложений могут меняться со временем, обычно в сторо­
ну повышения.
2.2.2. Сопровождение приложений и переносимость их кода
Другое важное обстоятельство состоит в том, насколько просто поддерживать при­
ложения и взаимодействовать с ними после их первоначального написания. Разрабо­
тавшие приложение программист или команда специалистов могут быть недоступны
в то время, когда в продукт требуется внести изменения. Предъявляемые к приложе­
нию требования могут со временем расширяться, а доступ к существующим службам
может понадобиться другим узлам, находящимся вне системы или внутри нее. Новые
узлы могут содержать особые программные и аппаратные компоненты или оказаться
подключены по другим каналам коммуникации.
Снизив объем задач интеграции, требующих решения при создании приложения,
и заострив внимание при разработке на бизнес-логике, можно придать коду продукта
структуру, более простую в сопровождении будущими разработчиками, которым
пона­добится внести в продукт изменения.
Программное обеспечение, расположенное между приложениями и базовыми инфра­
структурными компонентами, с которыми приложения взаимодействуют, называется
промежуточным. Промежуточное ПО способно обеспечить функциональность,
нехарактерную для отдельного языка программирования, конкретной аппаратной
платформы или операционной системы. Своего рода промежуточное ПО представ­
ляет собой и реализующая асинхронное взаимодействие приложений технология
очередей сообщений.
Используя промежуточный слой, можно перенести код приложения на узлы с раз­
ными базовыми инфраструктурными компонентами или расширить его перечислен­
ными узлами. Усилия по разработке продукта и в первом, и во втором случае значи­
тельно сократятся.
10
Глава 2
Процесс модификации приложения для выполнения на узле с новыми базовыми
инфра­структурными компонентами именуется переносом, простота переноса прило­
жения на другие компоненты инфраструктуры носит название переносимости.
Доступ к существующим службам, не использующим промежуточный слой, зачастую
можно гибко расширить реализацией прокси, предоставляющего интерфейс между
промежуточным слоем и существующей службой. В перспективе новые приложения
будут обращаться к такой службе через промежуточный слой, используя прокси, а не
путем доступа напрямую.
2.3. Расширяемость и скорость работы
Планируя, проектируя, разрабатывая и предоставляя службу в ИТ-системе компании,
важно учитывать, отвечает ли служба предъявляемым требованиям и способна ли она
развиваться так, чтобы соответствовать им в дальнейшем.
Приведенный далее перечень описывает в целом употребление в этой книге набора
терминов, применяемых в отношении служб в ИТ-системах организаций.
 Производительность. Время от подачи запроса до завершения его обслуживания.
Порядок определения момента начала и окончания работы службы зависит от ха­
рактера функций, выполняемых самой службой.
 Нагрузка. Количество попыток запроса службы в данном временном интервале.
 Пропускная способность. Количество запросов на обслуживание, которое система
в целом может обработать в данном временном интервале.
 Расширяемость (масштабируемость). Простота повышения пропускной способ­
ности системы с целью обслуживания увеличившейся нагрузки и влияние этого
повышения на скорость ее работы (производительность).
Все перечисленные параметры важно рассматривать вместе, а не каждый из них
в отдельности.
 Служба, имеющая высокую скорость работы с каждым успешно принятым ей
запро­сом, но позволяющая параллельно обрабатывать лишь малое их число,
может быть не способна справиться с возникающими нагрузками.
 Служба, имеющая высокую пропускную способность благодаря одновременному
обслуживанию большого числа запросов, но низкую производительность в расче­
те на единичный запрос, может оказаться неприемлемо медленной.
Изначально предоставляемые службе ресурсы призваны гарантировать, что скорость
ее работы и пропускная способность приемлемы при нагрузках ожидаемого объема.
Оценивая исходные требования к ресурсам, необходимо учесть надежность и без­
опасность служб, поскольку технологии повышения безопасности и надежности
могут неблагоприятно сказаться на скорости их работы.
В то же время, анализируя начальную производительность и пропускную способ­
ность, важно оценить и расширяемость службы. Служба, которая хорошо масштаби­
руется, позволяет включать в систему дополнительные ресурсы для того, чтобы опе­
ративно повысить пропускную способность и справиться с увеличившейся нагрузкой
без негативного влияния на скорость своей работы. Если расширяемость службы
не учитывать изначально, рост пропускной способности может потребовать значи­
Понятие очередей сообщений
11
тельного объема модификаций службы либо отрицательно повлиять на производи­
тельность таковой.
Другой важный аспект – работа системы в целом в период, когда нагрузка на ту или
иную службу превысит пропускную способность. Зачастую это недолговременное
явление, возникающее при пиковых обращениях. Кроме того, оно может постепенно
или внезапно возникать с ростом спроса на конкретную службу, указывая на то, что
требуется расширить пропускную способность. Если этого не учесть, то отрицатель­
ные последствия пренебрежения таким шагом могут образовать следующий возмож­
ный «букет».
 Система будет не в состоянии обработать дополнительные запросы конкретной
службы.
 Скорость обслуживания отдельных запросов службы упадет до неприемлемого
значения.
 Снизится скорость работы прочих, реализуемых данной системой служб.
 Возникнет фатальный сбой, такой как достижение пределов аппаратных ресурсов.
Это вызовет недоступность отдельных служб на протяжении периода времени.
Часто такую проблему обозначают как простой, или выход из строя.
Масштабируемость и скорость работы инфраструктуры очередей сообщений вкупе
с умелым проектированием и грамотным планом могут придать системе реальную
расширяемость. При этом ресурсы могут выделяться и освобождаться по мере надоб­
ности с учетом требований к пропускной способности и производительности систе­
мы в условиях меняющейся нагрузки на информационную среду предприятия.
2.4. Надежность служб и целостность данных
Данные, передаваемые в инфраструктуре очередей сообщений, в общих чертах мож­
но разделить на две категории.
 Данные запросов. Промежуточные данные, пересылаемые в системе и полученные
на базе данных, надежно хранящихся в системе как таковой. Если запрос утерян,
это может быть неудобно для его отправителя, однако исходные данные остаются
в системе и запрос может быть повторен.
Примером сказанного является запрос текущего состояния заказа; если запрос
данных утерян либо на него не получен отклик, это не повлияет на текущее состоя­
ние заказа, и запрос можно повторить еще раз.
 Данные, критичные для ведения бизнеса. Данные, не хранящиеся в системе гделибо еще. При их утере в системе теряется важная информация или изменение
состояния.
Примером этого является сообщение об оплате заказа; если сообщение с под­
тверждением платежа будет утеряно, статус заказа может стать некорректным.
Возможно, клиент внес деньги в его оплату либо ему отправлена расписка в их
получении, но состояние заказа внутри системы не отражает ни того, ни другого.
Критичную для бизнеса информацию содержит большинство сообщений, передавае­
мых в инфраструктуре очередей. По этой причине важно, чтобы инфраструктура
предоставляла гарантии защиты подобных сообщений от их потери.
12
Глава 2
С обеспечением таких гарантий связан ряд обстоятельств, касающихся производи­
тельности, а потому сообщения с данными-ответами на запрос могут маркироваться
как таковые для повышения скорости их прохождения в инфраструктуре.
2.4.1. Однократная доставка
Помимо защиты сообщений с критичной для бизнеса информацией от потери в инфра­
структуре очередей важно, чтобы сообщения достигали заданного места своего на­
значения, а доставка происходила исключительно однократно.
Если сообщение было отправлено по допустимому в данной системе адресу, инфра­
структура очередей сообщений обязана гарантировать, что сообщение будет достав­
лено получателю. Однако пункт назначения или промежуточные узлы могут быть
недос­тупны на протяжении какого-то периода времени. В этом случае сообщения
остаются в системе в состоянии ожидания, пока не смогут продолжить свое движение
по назначению.
Поскольку отправитель запроса данных не может ожидать отклик сколь угодно дол­
гое время, то к информации, получаемой по запросу, могут предъявляться иные тре­
бования. В итоге сообщения в инфраструктуре могут помечаться как устаревшие,
если в произвольном узле системы они останутся дольше заданного временного пе­
риода.
Если сообщение достигает места назначения дважды, то результат этого может ока­
заться непредсказуемым. К примеру, двукратное получение сообщения с подтвержде­
нием платежа может создать видимость того, что клиент переплатил за услугу. Инфра­
структура очередей сообщений должна предоставлять гарантии того, что единичное
сообщение не может быть неожиданно доставлено по назначению дважды или ока­
заться в нескольких пунктах назначения одновременно.
Если сообщение нельзя доставить по назначению, работа системы должна быть четко
описана для того, чтобы найти и вручную маршрутизировать сообщение. Невозмож­
ность доставки может быть обусловлена изменениями в инфраструктуре и переносом
адреса назначения либо некорректной спецификацией назначения отправителем
сообщения. После поступления в инфраструктуру сообщения запрещено отклонять,
за исключением случаев их намеренной маркировки как устаревших или содержа­
щих только данные по запросу.
Понятие однократной доставки охватывает все эти соображения. Такую доставку
гаран­тирует WebSphere MQ.
2.4.2. Единицы работы
Далеко не всегда действия приложений можно воспринимать изолированно. Напри­
мер, служба может прочитать сообщение, обновить данные о клиенте, а в завершение
послать ответ. Каждое из трех действий самостоятельно, но при ошибке в любом
из них ни одно действие выполнено быть не должно.
О таких действиях говорят, что они входят в единицу работы. Единицы работы
включают отправку и получение сообщений, а также обновление информационных
баз данных. Инфраструктура очередей сообщений должна поддерживать завершение
Понятие очередей сообщений
13
или откат действий единицы работы в целом, дабы ни одно действие в ней не могло
выполниться без выполнения остальных. Также возможность инициировать откат
единицы работы в любой момент времени должно иметь само приложение.
2.4.3. Обработка ошибок
Сбои в ИТ-системе компании могут происходить без каких-либо предупреждений
и должны обрабатываться так, чтобы не приводить систему в противоречивое состоя­
ние. К примерам подобных сбоев относятся:





периодические сбои системы связи;
плановые и внеплановые простои прочих системных служб;
сбои, вызванные ограниченностью ресурсов и аппаратными неисправностями;
сбои ввиду программных ошибок;
сбои из-за модификации инфраструктуры или настроек.
При построении ИТ-системы компании такие сбои необходимо учитывать и обеспе­
чивать их согласованную и толерантную обработку. Элементы инфраструктуры оче­
редей сообщений упрощают данный процесс, реализуя отказоустойчивую инфра­
структуру работы служб и значительно снижая объем требуемой для выявления и
обра­ботки сбоев такого рода прикладной логики.
Дополнительно эти возможности способны помочь избежать сбоев, которые могут
привести к отказу всей системы, позволяя службам оставаться доступными даже при
появлении таковых.
Примечание. Подробнее отказоустойчивость и единые точки отказа мы
обсудим в разделе 2.6 «Повышенная готовность»
2.4.4. Среда обеспечения контроля качества
Особую роль при разработке и развертывании новой службы в ИТ-системе компании
играет ее тестирование. Раннее обнаружение проблемы может серьезно сократить
влияние ее возникновения в будущем и снизить объем ресурсов, необходимых для ее
устранения.
Рекомендуемая методика создания, тестирования и внедрения приложений предпо­
лагает наличие двух независимых сред.
 Производственная среда. Среда, в которой функционирует реальная система ком­
пании, где происходит предоставление реальных служб, используемых и доступ­
ных сотрудникам, партнерам организации или тем и другим.
 Контролирующая среда (среда обеспечения контроля качества). Среда для разра­
ботки и тестирования продукта должна предельно соответствовать производ­
ственной среде, включая аппаратуру, операционные системы, программные
средства инфраструктуры, конфигурацию и все службы. Любые плановые моди­
фикации производственной среды до осуществления в ней должны проводиться
и проверяться в контролирующей среде. В ней же необходимо имитировать и на­
грузки.
14
Глава 2
В простой системе обе среды могут пользоваться одной и той же программно-аппа­
ратной инфраструктурой. Однако полное разграничение этих сред может дать допол­
нительные преимущества и сократить возможность изменений в контролирую­щей
среде, отрицательно влияющих на доступность служб производственной среды
фирмы.
Характер и интенсивность загрузки служб, которые моделирует среда обеспечения
контроля качества, должны предельно соответствовать аналогам из производствен­
ной среды предприятия. Чем меньше наблюдаемые различия, тем вероятнее обнару­
жение возможных проблем в контролирующей среде до их появления в производ­
ственной.
Если проблема наблюдается и допускает воспроизведение в контролирующей среде,
в ней можно разработать и протестировать предлагаемое решение. Его создание
может оказаться разрушительной процедурой и требовать осуществления шагов, не­
рекомендуемых к выполнению в производственной среде без предварительного тес­
тирования. В контролирующей среде подобные изменения можно осуществить, опи­
сать и проверить, не влияя на производственную среду.
Элементом сопровождения программных компонентов системы является регулярная
профилактика. Выполняя профилактические работы в контролирующей среде
до повторения их в условиях производственной среды, вы значительно снизите
вероятность неожиданного влияния операций сопровождения на доступность про­
граммных служб.
2.5. Защита
Немаловажным в ИТ-системе компании является тщательное изучение проблем безо­
пасности и защиты. Доступ к службам и информации в рамках такой системы должен
быть под контролем, а целостность передаваемых по сетям общего пользования
закры­тых и чувствительных данных – должным образом обеспечена.
2.5.1. Защита доступа
Нередко важно гарантировать, что службы в ИТ-системе компании доступны только
авторизованным сторонам – людям и приложениям.
Применение службы без авторизации или по злому умыслу может вызвать поврежде­
ние данных, которые хранятся в системе, или сделать конфиденциальную информа­
цию доступной более широкой аудитории, чем это предполагалось правами доступа.
В целом защита доступа к службам включает решение двух следующих задач.
 Опознавание сущности, предпринимающей попытки обращения к службам.
 Запрет установленной или неустановленной сущности обращения к службам,
в работе с коими ей должно быть отказано.
Инфраструктура очередей сообщений должна включать функции надежного распо­
знавания сущности, пытающейся получить доступ к конкретной службе, а также пра­
вила выработки решений о том, располагает данная сущность правом обращения
к службе или же нет.
Понятие очередей сообщений
15
Это может оказаться особенно важным при наличии служб, открытых внешним
субъек­там, – поставщикам фирмы или ее клиентам. В данном случае инфраструктура
очередей должна иметь надежную и безопасную процедуру выдачи прав доступа
к службам для внешних контрагентов.
2.5.2. Защита коммуникаций
Входящие в систему узлы могут быть связаны различными каналами связи, предна­
значенными для общего пользования или не имеющими защиты. Во избежание внеш­
него вмешательства в посылку и получение данных такие каналы связи надлежит
защи­щать.
Технологии защиты каналов связи обеспечивают защиту от чтения или модификации
секретных данных третьими сторонами. Также они защищают и от попыток имита­
ции сущности, имеющей права доступа к службам внутри системы.
Внешнее вмешательство в систему по незащищенным каналам связи может вызвать
нарушение целостного характера данных либо привести к недоступности служб.
2.6. Высокая готовность системы
На службы, реализуемые ИТ-системой компании, можно положиться в повседневной
работе фирмы. Простои, при которых конкретная служба или их группа становится
недоступной, могут отразиться на деятельности компании, в результате чего ею будут
понесены убытки.
В широком смысле простои делятся на две категории.
 Плановые простои. Периоды недоступности одной или нескольких служб при
выполнении их планового обслуживания. Сюда относятся:
– профилактика программного обеспечения;
– изменение настроек инфраструктуры;
– резервное копирование или реорганизация данных.
 Внеплановые простои. Периоды недоступности одной или нескольких служб,
возникшие неожиданно. Они могут быть вызваны:
– программными или аппаратными сбоями;
– недостаточностью ресурсов;
– нарушением целостности информации.
Цель обеспечения высокой готовности служб – минимизация плановых и внеплано­
вых простоев инфраструктуры. Этого можно добиться несколькими путями, включая
следующие:
 Повышение надежности системы.
Надежность системы зависит от надежности всех ее компонентов, включая про­
граммные и аппаратные компоненты инфраструктуры, линии связи и приложе­
ния, реализующие функции служб. Заметный вклад в надежность системы в целом
вносит использование стабильной и надежной инфраструктуры очередей сооб­
щений с простыми интерфейсами для минимизации сложности ее служб.
16
Глава 2
 Снижение простоев, обусловленных обновлением компонентов.
Обновление и сопровождение компонентов, по возможности осуществляемое без
перевода служб в недоступное состояние, позволяет сократить плановые простои.
Первоначальное обновление контролирующей, а не производственной среды
снижает вероятность изменений в поведении рабочего окружения, влекущих
внеплановый останов.
 Гарантия эффективного восстановления системы при возникновении сбоя.
Если система допускает эффективное, то есть автоматическое, восстановление
после сбоя без потери целостности информации, последствия и продолжитель­
ность такого внепланового простоя будут гораздо меньше.
 Минимизация влияния на службы единичного сбоя.
Если в компоненте системы наблюдается сбой, он может повлиять на систему
и службы, которые ею предоставляются. В контексте очередей сообщений это
воздействие можно разбить на следующие подгруппы:
– доступность служб;
– доступность сообщений.
2.6.1. Доступность служб
Если в компоненте системы произойдет сбой, он повлияет на все зависимые от него
компоненты. Те, в свою очередь, могут повлиять на другие, в конечном же итоге затро­
нутыми могут оказаться одна или несколько служб системы.
Если в системе есть лишь один экземпляр службы либо все экземпляры конкретной
службы зависят от конкретного компонента, то возникает единая точка отказа внутри
системы.
Организуя в системе множество экземпляров службы, способных действовать неза­
висимо, можно обеспечить доступность службы для новых запросов даже после отка­
за нескольких экземпляров.
В контексте очередей сообщений это требует, чтобы новые сообщения, которые
поме­щаются в очереди на отказавших узлах или проходящие через них, направля­
лись на другие узлы системы.
2.6.2. Доступность сообщений
Прежде чем достичь пункта своего назначения, сообщение может пройти в системе
вереницу узлов, а оказавшись на месте, оставаться там какое-то время, прежде чем
служба начнет его обработку. Впрочем, и самой службе между потреблением сообще­
ния и успешным окончанием всех действий над ним также необходимо определен­
ное время.
Если компонент системы дал сбой, узлы, в которых размещены очереди и службы,
могут, как следствие, тоже утратить функциональность. Это может произойти мгно­
венно, не оставляя инфраструктуре и приложениям времени на реакцию, как, напри­
мер, в случае отказа аппаратуры. Пока узел продолжает быть недоступным, все сооб­
щения в очередях в этом узле тоже продолжают быть недоступными. Такие сообще­
ния называют «застрявшими» (stranded messages).
Понятие очередей сообщений
17
Если подобное сообщение содержит критичные для бизнеса данные, становится
важным его надежно восстановить. Восстановление «застрявших» сообщений должно
поддерживать целостность хранимой в них информации.
Корректно должна быть разрешена и ситуация с каждой выполнявшейся в момент
сбоя единицей работы. Так, служба могла начать обрабатывать сообщение, но не ус­
петь закончить его обслуживание.
Восстановление сообщений с критичными для бизнеса данными может осущест­
вляться в жестких временных рамках, возврат к работе затронутых неисправимой
ошибкой ресурсов – требовать времени и ручного вмешательства. В итоге для восста­
новления доступности сообщений на незатронутых сбоем ресурсах может потребо­
ваться произвести ряд ручных или автоматических операций.
2.6.3. Восстановление после сбоя
Отдельные катастрофические повреждения могут затронуть все ресурсы какого-либо
узла, а возможно, и группы связанных друг с другом и находящихся на единой физи­
ческой площадке узлов. Возврат к работе служб после подобных сбоев или восста­
новление данных на поврежденных узлах требует тщательного планирования
и предварительной подготовки.
Компания может планомерно готовиться к такого рода проблемам, периодически
снимая резервные копии данных в узлах системы, содержащих критичную для веде­
ния бизнеса информацию. Используя стратегии резервирования, восстановить дан­
ные в полностью актуальном их состоянии на поврежденном узле (узлах) возможно
далеко не всегда. Однако соблюдение таких стратегий может существенно сократить
количество данных, утраченных при разрушительном останове.
2.7. Мониторинг и учет операций
Сведения о работе и использовании системы имеют важное практическое значение.
Они могут стать показателем качества функционирования системы, индикатором
производительности и пропускной способности при разных нагрузках, а также дать
возможность отслеживать работу отдельных сущностей.
2.7.1. Мониторинг производительности
Мониторинг производительности в контексте инфраструктуры очередей сообще­
ний включает замер количества и продолжительности тех действий, которые осу­
ществляются при обращении служб к очередям сообщений или при движении сооб­
щений сквозь очереди и промежуточные узлы. Результаты замеров могут служить для
оценки производительности и пропускной способности служб, а также инфраструк­
туры, которая их поддерживает.
Такие данные могут оказаться полезны при наделении служб ресурсами или приня­
тии решения о наращивании ресурсов для расширения пропускной способности
службы. Кроме того, мониторинг производительности может принести пользу при
выявлении любых внезапных или постепенных изменений в характере нагрузки
системы с целью предупреждения проблем до их реального появления.
18
Глава 2
2.7.2. Учет
Учет в контексте очередей сообщений включает накопление информации об исполь­
зовании отдельных очередей конкретными сущностями, которыми могут быть при­
ложение, реализующее службу на основе данной очереди, внешний или внутренний
пользователь.
Собранная при учете статистика позволяет установить и провести анализ характера
использования системы и, к примеру, удостовериться, что качество обслуживания
конкретной сущности соответствует ожиданиям. Другое применение таких дан­
ных – организация функции выставления счетов на оплату с учетом использования
конкретной службы конкретной сущностью.
Понятие очередей сообщений
19
3
Средства поддержки очередей
сообщений в WebSphere MQ
Эта глава описывает формирование очередей сообщений в системе IBM WebSphere
MQ, обзор соответствующих возможностей которой мы приведем для каждой проб­
лемной области, описанной в главе 2 «Понятие очередей сообщений».
В этой же главе книги мы обсудим следующие вопросы:







Базовые понятия
Упрощение
Расширяемость и скорость работы
Надежность служб и целостность данных
Безопасность
Высокая готовность системы
Мониторинг и учет операций
Средства поддержки очередей сообщений в WebSphere MQ
21
3.1. Базовые понятия
IBM WebSphere MQ – признанная и испытанная платформа промежуточного ПО для
поддержки очередей сообщений. За более чем 10 лет разработки продукт WebSphere
MQ стал гибким и надежным решением, готовым справиться со всем набором задач,
описанных в предшествующей главе.
Основанная на технологии WebSphere MQ инфраструктура очередей сообщений по­
может в реализации доступной, надежной, масштабируемой, безопасной и удобной
в сопровождении среды транспорта сообщений с гарантией однократной доставки.
3.1.1. Инфраструктура очередей сообщений WebSphere MQ
Узел инфраструктуры очередей сообщений WebSphere MQ называется менеджером
очередей (queue manager). Один физический сервер может содержать множество
таких менеджеров, способных функционировать на целом спектре различных соче­
таний аппаратуры и операционных систем.
Каждый менеджер очередей содержит средства надежного обслуживания очередей
сооб­щений. На всех платформах без исключения менеджеры наделены функциями
поддержки очередей сообщений с использованием модели межточечного обмена,
в том числе по принципам «отправил – забыл» и «запрос – ответ», описанным в главе 2.
Менеджеры очередей WebSphere MQ Version 6.0, кроме WebSphere MQ для z/OS, также
содержат брокеры публикации-подписки для обмена сообщениями по соответствую­
щей модели.
Менеджеры управляют очередями в инфраструктуре очередей, а также поддерживают
все сообщения в этих очередях, ожидающие обработки или маршрутизации. Менед­
жеры очередей устойчивы к сбоям и поддерживают целостность критичных для биз­
неса данных, пересылаемых через инфраструктуру.
Связь менеджеров в инфраструктуре обеспечивают каналы (channels). Сообщения
перемещаются по этим каналам автоматически и движутся от исходного отправителя
к конечному потребителю с учетом настройки менеджеров очередей в составе инфра­
структуры.
В настройку менеджеров можно вносить множество изменений, которые будут про­
зрачны для приложений, реализующих сами службы или запросы к ним.
3.1.2. Средства реализации инфраструктуры WebSphere MQ
WebSphere MQ V6.0 содержит WebSphere MQ Explorer, являющийся графическим интер­
фейсом (GUI) конфигурирования и контроля менеджеров очередей в инфраструк­
туре WebSphere MQ с настольной рабочей станции. Также он позволяет администри­
ровать менеджеры очередей на платформе z/OS.
Для целей администрирования на всех платформах без исключения в WebSphere MQ
входит сценарный (scripting) MQSC-интерфейс. Для iSeries™ и z/OS в продукте име­
ются панельные интерфейсы администрирования.
22
Глава 3
В состав каждого менеджера WebSphere MQ входят объекты (objects). Они определя­
ют настройки очередей своего менеджера, а также характер взаимодействия самого
менеджера, приложений и других менеджеров в инфраструктуре WebSphere MQ.
Объекты могут использоваться для настройки специальных маршрутов, соединяю­
щих отдельные менеджеры очередей в составе инфраструктуры. Также с их помощью
менеджер можно подключить к кластеру менеджеров очередей (queue manager cluster), в котором каналы между последними по мере надобности создаются автомати­
чески.
Кластеры менеджеров очередей снижают объем работы по администрированию
системы, необходимой при построении или модификации инфраструктуры Web­
Sphere MQ. Менеджеры очередей могут подключаться к кластерам и покидать их без
дополнительного конфигурирования менеджеров в составе инфраструктуры.
Наконец, кластеры менеджеров очередей реализуют много дополнительных функ­
ций, которые расширяют возможности связи менеджеров, описанные администрато­
рами вручную, и могут использоваться для улучшения расширяемости и повышения
готовности служб, которые предоставляет система.
3.1.3. Пакеты дополнительных функций
Ряд дополнительных функций и руководств, не включенных в базовый выпуск Web­
Sphere MQ, поставляется как пакеты поддержки WebSphere MQ SupportPac™.
Функциональная направленность SupportPac различна и включает в том числе следу­
ющее:





отчеты о производительности WebSphere MQ;
документацию и руководства по тем или иным функциям и возможностям;
примеры приложений, взаимодействующих с WebSphere MQ;
сценарии для упрощения администрирования WebSphere MQ;
интерфейсы к WebSphere MQ для дополнительных языков программирования.
Каждый пакет имеет уникальное обозначение и отнесен в определенную категорию.
Категория указывает происхождение SupportPac и уровень поддержки этого Support­
Pac корпорацией IBM.
Перечень всех доступных пакетов серии SupportPac и дополнительные подробности
о системе и категориях SupportPac см. на Web-сайте по адресу:
http://www.ibm.com/software/integration/support/supportpacs
3.2. Упрощение
WebSphere MQ обеспечивает упрощенное взаимодействие приложений, созданных
для разных аппаратных платформ и разных операционных систем, реализованных
на разных языках программирования или работающих в различных программных
и аппаратных средах.
WebSphere MQ позволяет организациям выбирать самые подходящие инфраструк­
турные компоненты для размещения служб или доступа к службам в своих системах.
Средства поддержки очередей сообщений в WebSphere MQ
23
Новые приложения могут взаимодействовать с набором существующих служб, не зная
сути организации имеющихся компонентов инфраструктуры очередей, реализую­
щих эти службы. Ранее разработанные и лишенные интерфейса к инфраструктуре
очередей службы могут быть адаптированы к новым условиям путем создания прокси
(proxies) для стыковки существующих интерфейсов с теми, к которым обращается
инфраструктура очередей сообщений WebSphere MQ.
Для работы с инфраструктурой очередей WebSphere MQ предоставляет широкий
круг интерфейсов прикладного программирования (API), выбор одного из которых
может быть продиктован методологией языка программирования и той средой, в ко­
торой осуществляется разработка.
Асинхронная природа отправки и получения сообщений в WebSphere MQ способна
упростить логику приложений и обеспечить структурированную обработку сбоев,
если они возникнут.
3.2.1. Доступ приложений к инфраструктуре WebSphere MQ
Установив связь даже с одним менеджером очередей в инфраструктуре WebSphere
MQ, приложение способно «общаться» с подключенными к другим менеджерам оче­
редей приложениями в той же инфраструктуре. Менеджер очередей, с которым свя­
зано приложение, может располагаться на машине отличной от той, где оно уста­
новлено.
Это условие не зависит от сочетаний аппаратуры и операционных систем машин, где
работает приложение и менеджер очередей, к которому произошло подключение.
3.2.2. Асинхронное взаимодействие
с использованием WebSphere MQ
Два приложения, нуждающихся в связи между собой и выполняемых на одной или
на разных машинах, изначально могут быть созданы для непосредственной синх­
ронной взаимосвязи.
В этом случае оба приложения ведут обмен информацией, ожидая доступности при­
ложения-партнера, а затем производя пересылку. Если приложение-партнер недо­с­тупно по какой-либо причине, включая занятость в ходе взаимодействия с прочими
приложениями, передача информации невозможна.
Все сбои взаимосвязи приложений, которые могут происходить как на одной, так и
на разных, соединенных сетью машинах, должны урегулироваться приложениями
самостоятельно. Это требует протокола передачи и подтверждения получения инфор­
мации, а также протокола отправки последующих ответов.
Включение в цепь связи двух приложений очереди WebSphere MQ позволяет сделать
такую взаимосвязь асинхронной. Каждое приложение помещает информацию для
партнера в очередь в виде сообщения WebSphere MQ, а приложение-партнер обраба­
тывает ее в период своей готовности. В дальнейшем, если необходимо, приложениепартнер может послать ответ на сообщение отправителю.
Если два приложения работают на разных машинах, то предоставленная WebSphere
MQ гарантия однократной доставки обеспечивает прием каждого сообщения, при­
24
Глава 3
чем один раз. Нередко этим устраняется требование ответа со стороны службы. Если
при обработке сообщения произойдет сбой, служба сможет осуществить необходи­
мую операцию, будь то ответ стороне отправителя, уведомление администратора
или другого приложения путем отправки отчета.
Приложения, занятые обработкой поступающих сообщений, трактуются как постав­
щики служб. Служба может производить любые виды работ, к примеру обновление
информации в базе данных или отправку электронных писем администратору.
3.2.3. Обобщенные пункты назначения WebSphere MQ
Пункты назначения в инфраструктуре обозначаются названиями очередей, откуда
приложения извлекают сообщения на обработку. В пределах менеджера эти названия
уникальны, однако разные менеджеры в инфраструктуре могут иметь очереди с иден­
тичными именами.
Такое название служит для опознания конкретной службы или обобщенного опреде­
ления, назначенного службе инфраструктурой.
3.2.4. Особые пункты назначения WebSphere MQ
Конкретное приложение, хотя и необязательно, может иметь свой собственный уни­
кальный пункт назначения в инфраструктуре, составленный из названия очереди,
назначенной приложению, и менеджера, к которому то подключено.
Этот пункт назначения может быть постоянным, то есть позволяющим отправлять
сообщения приложению даже в неактивный период, а может – временным, существую­
щим лишь в течение времени жизни самого приложения.
Такие пункты могут строиться динамически, давая возможность неограниченному
количеству приложений подключаться к одному менеджеру очередей и иметь соб­
ственный пункт назначения в инфраструктуре.
Эти уникальные пункты позволяют пересылать отклики инициатору запроса по прин­
ципу межточечного обмена, а также маршрутизировать публикации подписанным
на них приложениям по модели публикации-подписки.
3.2.5. Предоставление услуг в инфраструктуре WebSphere MQ
Приложение, предоставляющее услугу, ждет поступления сообщений в очередь, наз­
ванную в инфраструктуре именем самого приложения.
Далее приложение обрабатывает каждое входящее сообщение, учитывая его содер­
жимое и бизнес-логику службы. Последняя может подразумевать обновление или
запрос информации в базе данных, принятие решений о требуемых на следующем
этапе ручных или автоматических операциях, а также их выполнение, включая от­
правку сообщений другим службам системы.
Сообщения из одной очереди могут обрабатываться множеством приложений-пос­
тавщиков, но по запросу от приложения ему может быть предоставлен исключитель­
ный доступ ко всем сообщениям конкретной очереди.
Средства поддержки очередей сообщений в WebSphere MQ
25
3.2.6. Очереди WebSphere MQ как интерфейс доступа к службам
Для доступа к службе инфраструктуры очередей сообщений WebSphere MQ приложе­
ние требует нижеперечисленной информации.
 Данные о размещении службы. В WebSphere MQ это название очереди в модели
межточечного обмена или темы в модели публикации-подписки.
 Способ подключения к инфраструктуре. В WebSphere MQ это имя и параметры
подключения к менеджеру очереди инфраструктуры. Менеджер может находиться
на той же машине, что приложение, или располагаться на удаленной машине
с подключением к сети.
 Детали интерфейса конкретной службы. Указывают, реализован ли интерфейс
по принципу «отправил – забыл», «запрос – ответ» или по модели публикацииподписки. Содержат структуру данных тех сообщений, которые передаются между
приложениями, стремящимися получить доступ к службе и предоставляющи­ми ее.
 Механизм отправки и получения сообщений. Прикладной интерфейс програм­
мирования (API), реализующий функции, совместимые с используемой инфра­
структурой. WebSphere MQ содержит целый спектр разнообразных API, способных
использоваться из разных языков программирования и с различных платформ.
Другие вопросы, такие как способ маршрутизации сообщений до пункта их назначе­
ния, решает инфраструктура WebSphere MQ, выполняющая свою работу прозрачно
для приложения.
К разряду решаемых инфраструктурой вопросов относится и обработка сбоев на лю­
бых промежуточных узлах маршрута доставки, а также выбор вариантов обхода по­вреж­
денных узлов сети и выдача запросов балансировки нагрузки доступным ресурсам ин­
фраструктуры.
Подобный доступ к службам гибок и удобен в сопровождении. Собственную инфра­
структуру и службы, а также внешний доступ к последним могут поддерживать отдель­
ные департаменты фирм и компании в целом.
Для этого приведенную информацию они передают в другие подразделения или
фирмы (например, бизнес-партнерам, клиентам, поставщикам). Еще один доступный
им способ – создание собственных приложений для обращения к службам с исполь­
зованием инфраструктуры очередей и публикация видимого извне интерфейса
к разработанным приложениям, к примеру для обеспечения возможности внешнего
доступа к службе через Web-браузер.
Инфраструктура может претерпевать изменения, такие как межмашинный перенос
приложений, расширение памяти, модификации при обслуживании, а также рест­
руктуризацию и объединение инфраструктур, не влияющие на работу или доступ­
ность служб, предоставленных интерфейсом.
3.2.7. Стандартизованные API-интерфейсы
Использование стандартизованного API для обращения к службам через инфраструк­
туру очередей может сделать данный процесс еще более гибким. В этой книге поня­
26
Глава 3
тие стандартизованного API служит для обозначения интерфейсов, не являющихся
специфичной составной частью таких конкретных продуктов, как WebSphere MQ.
Примерами стандартизованных интерфейсов, которые могут использоваться для об­
ращения к службам, предоставляемым инфраструктурой WebSphere MQ, являются:
 Java™ Message Service (JMS)
 IBM Message Service Client (XMS)
Подробнее мы рассмотрим их в разделе 4.2.3 «Стандартизованные API-интерфейсы
для WebSphere MQ».
Использование стандартизованных интерфейсов для обращения к службам позволя­
ет логике приложения не зависеть от технологий очередей, а это дает возможность
меняться технологиям в инфраструктуре как таковой.
Например, брокер, реализующий функции публикации-подписки в инфраструктуре
WebSphere MQ, может быть обновлен с брокера публикации-подписки WebSphere
MQ до WebSphere Business Integration Message Broker или WebSphere Business Integra­
tion Event Broker.
WebSphere Business Integration Message Broker и WebSphere Business Integration Event
Broker – это независимые системы-брокеры, которые в процессе своей работы за­
действуют базовую функциональность обмена сообщениями WebSphere MQ и пред­
лагают дополнительные возможности, максимально использующие модель сообще­
ний публикации-подписки.
Широкому распространению этих API могут помочь многочисленные продукты. Так,
API-интерфейс JMS – промышленный стандарт на API-интерфейсы обмена сообще­
ниями в спецификации Java 2 Platform Enterprise Edition (J2EE™).
Модификация стандартизованного API с целью поддержки в нем конкретных очере­
дей сообщений обычно не производится приложением самостоятельно. Как правило,
такие данные содержатся в каталоге (directory), доступном локально или в сети,
а приложение получает необходимую информацию по обслуживанию очередей
из этого каталога.
В случае с WebSphere MQ данные каталога содержат параметры подключения к ме­
неджеру и названия очередей.
Информация в каталоге может меняться и отражать такие изменения в интерфейсе
службы, как подключение к другому менеджеру. После проведения изменений в инф­
раструктуре корректировка приложения не требуется.
3.2.8. WebSphere MQ и WebSphere Application Server
Такие J2EE-совместимые серверы приложений, как IBM WebSphere Application Server,
предоставляют структуру (framework) для разработки и размещения приложений.
В свою очередь, приложения на J2EE-сервере могут обращаться к целому ряду функ­
ций через интерфейсы API, заданные в спецификации J2EE.
Одним из множества стандартизованных API-интерфейсов в спецификации J2EE
явля­ется интерфейс JMS, который описывает API межточечного обмена и приемапере­дачи сообщений по принципу публикации-подписки. Для обеспечения широко­
Средства поддержки очередей сообщений в WebSphere MQ
27
го спектра иных возможностей, в которых также могут нуждаться прикладные про­
дукты, служат прочие интерфейсы. Так, приложение может получить внешний запрос
по интерфейсу, доступному через сеть Интернет и Web-браузер, а может самостоя­
тельно послать запрос и обновить информацию в базе данных.
Технологии, реализующие функциональность J2EE, могут быть встроены в сервер
приложений J2EE, а могут быть выполнены как независимые продукты, настроенные
на работу с сервером приложений J2EE как поставщики (provider) этих функций.
В поставку WebSphere Application Server Version 5 входит встроенный поставщик
JMS-функций на базе WebSphere MQ.
В поставку WebSphere Application Server Version 6 входит встроенный поставщик
JMS-функций WebSphere Platform Messaging. WebSphere Platform Messaging – это неза­
висимая от WebSphere MQ технология межточечного обмена и организации очере­
дей сообщений по принципу публикации-подписки.
WebSphere MQ может быть настроен как JMS-поставщик для WebSphere Application
Server V6.0. Инфраструктуры WebSphere Platform Messaging могут быть связаны с
инфра­структурами WebSphere MQ.
3.2.9. Web-службы как интерфейс доступа к службам
Самостоятельно стандартизованные API не решают проблему описания интерфейса
доступа к службе. Приложение по-прежнему должно знать формат передаваемых
службе сообщений и данных, необходимых ей для выполнения операций.
Решение могут обеспечить Web-службы. Их главная идея – в определении общих
стандартов описания и обмена информацией приложений, выдающих запросы
к службам, и непосредственно служб.
Для описания Web-служб используется универсальный язык – Web Services Description
Language (WSDL). WSDL-описание каждой Web-службы может содержать данные
о том, каков порядок обращения к службе, какая информация требуется, каков воз­
вращаемый результат, и способно дать общее представление о службе, к примеру
описание действий, которые она выполняет.
WSDL-описание Web-службы может быть сгенерировано по коду реализации бизнеслогики самой службы. Такой подход называется «снизу – вверх».
Допускается и обратное: предварительно созданное WSDL-описание может служить
основой при создании кода реализации службы. Такой подход называется «сверху –
вниз».
В обоих случаях WSDL-описание службы может являться общим для приложения,
реа­лизующего Web-службу, и всех обращающихся к ней приложений. Тем самым
формируется общий регламент взаимодействия перечисленных приложений.
WSDL-описание каждой входящей в состав системы Web-службы может храниться
в общедоступном реестре (registry). Это дает возможность приложениям (разработ­
чикам) запрашивать в реестре WSDL-описания служб, к которым они желают полу­
чить доступ, в том числе уточняя порядок взаимодействия.
28
Глава 3
Посредником в подобных взаимодействиях является функциональный слой, именуе­
мый Simple Object Access Protocol (SOAP). Он описывает общий формат данных Webслужбы и приложения, которое обращается к такой службе. Для обеспечения гаран­
тии передачи только корректно заданной информации данные могут проверяться
на соответствие WSDL-описанию.
Протокол SOAP описывает, как занятые в обмене данные определяются приложения­
ми. Однако как таковой он не дает механизма взаимодействия приложений внутри
сети. Для связи независимых приложений необходим транспортный слой.
Использование как среды транспорта инфраструктуры очередей сообщений Web­
Sphere MQ может соединить преимущества Web-служб при описании взаимодействий
с асинхронной природой, надежностью и присущей WebSphere MQ гарантией одно­
кратной доставки.
Подробнее о Web-службах, включая правила пользования WebSphere MQ как транс­
портом для Web-служб, читайте в следующих руководствах:
 WebSphere MQ Solutions in a Microsoft .NET Environment, SG24-7012
 WebSphere MQ Transport для SOAP, SC34-6651
3.2.10. Упрощенная обработка сбоев в WebSphere MQ
Используя любой из интерфейсов доступа к WebSphere MQ, приложение может выиг­
рать от применения механизма обработки ошибок, упрощенного в сравнении с синх­
ронным взаимодействием со службой по сети связи.
Так, после размещения сообщения в инфраструктуре очередей WebSphere MQ гаран­
тирует его доставку по назначению, причем один раз.
Предоставляемая WebSphere MQ гарантия однократной доставки снимает с приложе­
ния ответственность за обработку сбоев коммуникации.
Независимо от конечного пункта назначения сообщения приложение сначала ставит
сообщение в очередь, управляемую тем менеджером, с которым оно само связано.
Этой очередью может являться как конечный пункт назначения, так и промежуточная
очередь для отправки другому менеджеру очередей в составе инфраструктуры.
Приложению как таковому достаточно лишь знать название очереди. Порядок
дос­тавки сообщения по назначению и возможность отправки любых ответов менед­
жеру очередей, к которому подключено приложение, определяют настройки инфра­
структуры WebSphere MQ.
Кластеры менеджеров очередей способны упростить такую настройку, предоставляя
менеджерам очередей автоматически обновляемые данные о других менеджерах
в системе и их доступности. Используя кластеры менеджеров, можно связать с одним
сообщением несколько возможных адресов назначения, представляющих различные
ресурсы системы, способные обработать данное сообщение. Это действие также вы­
полняется прозрачно для приложения, которому достаточно знать только название
очереди.
Средства поддержки очередей сообщений в WebSphere MQ
29
3.3. Расширяемость и скорость работы
WebSphere MQ является расширяемой эффективной реализацией очередей сообще­
ний, основанной на применении функций, предоставляемых каждой операционной
системой и нацеленных на повышение производительности за счет использования
потенциала современных многопроцессорных серверов.
3.3.1. Расширяемость менеджеров очередей WebSphere MQ
Каждый менеджер очередей одновременно выполняет большое число задач, пользу­
ясь множеством имеющихся в составе физических или эмулируемых аппаратурой
виртуальных процессоров. Координацию решения этих задач осуществляет
WebSphere MQ, гарантирующий целостность данных.
Количество параллельных активных подключений к одному менеджеру может дости­
гать десятков, сотен, а иногда – тысяч. Такая совокупность соединений может одно­
временно обрабатывать сообщения из одних и тех же очередей, которые реализуются
одним менеджером. WebSphere MQ предполагает гибкость в реализации обращаю­
щихся к менеджерам очередей приложений и допускает увеличение их пропускной
способности и скорости их работы.
Приложения, которые обращаются к инфраструктуре WebSphere MQ, могут разраба­
тываться и размещаться на серверах приложений WebSphere Application Server, что
позволит им пользоваться возможностями расширения WebSphere Application Server
как такового.
Приложения могут непосредственно строиться на функциях многопоточности и
многозадачности операционных систем и решать ряд задач параллельно в разных
потоках одного приложения, а могут выполняться как несколько экземпляров одного
приложения, подключенных к одному менеджеру очередей сообщений.
3.3.2. Архитектура с одним менеджером очередей сообщений
Асинхронность приема и отправления сообщений в WebSphere MQ помогает плавно
наращивать возможности приложений даже тогда, когда в предоставлении службы
задействована одна-единственная машина.
Поскольку буфером между приложением, выдавшим запрос к службе, и приложением,
реализующим таковую, является очередь, служба способна адаптироваться к пере­
менной нагрузке и справиться с ее возможным возникновением.
Приложение-инициатор запроса к службе может располагаться на той же машине,
что и приложение, которое эту службу предоставляет. Находящийся на той же маши­
не менеджер содержит очереди, позволяющие добиться эффективного асинхронного
взаимодействия приложений. Сказанное иллюстрирует левая половина рис. 3.1.
Также подключенным к менеджеру очередей приложениям WebSphere MQ дает воз­
можность располагаться на удаленных машинах и выступать в роли его клиентов
(clients). В результате единственный менеджер может обеспечивать обращение
к службе не одной, а нескольких машин сразу. Число клиентов в WebSphere MQ не
30
Глава 3
ограничено. Впрочем, на деле его лимит определяет пропускная способность данной
единичной машины.
Такова простейшая форма инфраструктуры WebSphere MQ: единственный менеджер
очередей сообщений реализует службу, необходимую подключенным к нему прило­
жениям. Эта схема показана на правой части рис. 3.1.
Applications
accessing
the service
Single queue
manager
Applications
providing
the service
Single queue
manager
Applications
providing
the service
.
.
.
Рис. 3.1. Примеры архитектуры с одним менеджером очередей WebSphere MQ
3.3.3. Центрально-лучевая архитектура WebSphere MQ
Подключение приложения к менеджеру очередей WebSphere MQ как клиента имеет
ограничения. Приложение и менеджер разделяет сетевое соединение, которое влияет
на производительность их работы, в первую очередь на больших расстояниях. Также
для работоспособности приложения тому требуется доступное подключение по сети.
И хотя этим подключением к приложению управляет WebSphere MQ, взаимодействие
по сети приложения и менеджера не является асинхронным.
Такой подход с единственным менеджером обладает возможностью расширения
и позволяет использовать целый ряд менеджеров очередей, не внося изменения
в приложения.
Приложения, которые обращаются к службе, могут иметь менеджер очереди на той
же машине, что обеспечит им быстрое соединение с инфраструктурой и даст вос­
Средства поддержки очередей сообщений в WebSphere MQ
31
пользоваться преимуществами асинхронного взаимодействия со службой, распола­
гающейся на другом менеджере.
Еще одним вариантом служит подключение обращающихся к работе служб приложе­
ний к менеджеру в роли клиентов по быстрому сетевому соединению; скажем, так
можно подключить все приложения, вызывающие службу в офисе филиала. Благода­
ря наличию этого менеджера связь со службами на другом основном (hub) менеджере
очередей становится асинхронной. При этом в реализации приложений как таковых
может иметься внешний интерфейс к службе (к примеру, дающий возможность
исполь­зовать ее через сеть Интернет и Web-браузер).
Те менеджеры очередей, которые предоставляют доступ к службам hub-менеджера,
носят название spoke-менеджеров (spokes) центрально-лучевой («hub and spoke»)
архи­тектуры WebSphere MQ.
Приложения, занятые обеспечением работы служб, могут находиться на мейнфрейме
или на сервере. Данная машина содержит hub-менеджер с очередью, из которой эти
приложения извлекают сообщения на обработку. Здесь могут находиться и другие
необходимые приложениям ресурсы, такие как база данных. В зависимости от при­
нятого подхода к реализации приложений, предоставляющих службу, запросы из од­
ной очереди может обрабатывать несколько экземпляров приложений такого рода.
Архитектуру дополняет выполняемое вручную задание маршрутов от spoke- до hubменеджеров очередей, реализующих отдельные службы. Многочисленные службы
в составе инфраструктуры могут контролироваться целым набором разных hubменеджеров, а может и единственный основной менеджер поддерживать совокуп­
ность очередей.
Примером центрально-лучевой архитектуры служит рис. 3.2.
.
.
.
кан
ал
Рис. 3.2. Пример центрально-лучевой архитектуры WebSphere MQ
32
Глава 3
3.3.4. Кластеры менеджеров как возможность
гибкого расширения
Более гибким подходом является объединение менеджеров очередей в кластер (queue
manager cluster). Кластеры менеджеров дают возможность множеству экземпляров одной-единственной службы располагаться на нескольких менеджерах очередей.
Приложения, осуществляющие вызов конкретной службы, могут соединяться с лю­
бым из менеджеров очередей в кластере. При выдаче приложениями запросов
к службе менеджер очереди, к которому подключены приложения, автоматически
балансирует нагрузку, распределяя запросы по всем доступным менеджерам очере­
дей, имеющим экземпляр данной службы.
Это позволяет существовать в кластере менеджеров очередей целому пулу машин,
каждая из которых содержит менеджер очереди и приложения, необходимые для
обра­щения к службе. Особую пользу это приносит в распределенной среде, расшире­
ние емкости которой позволяет решить проблему с текущей нагрузкой силами
не­с­кольких серверов, а не единственного мейнфрейма или сервера высокой произ­
водительности.
Менеджеры очередей могут динамически входить в состав и покидать кластер, чтобы
справиться с меняющейся нагрузкой на конкретную службу, предоставляемую систе­
мой. При этом необходимо осуществить настройку лишь того менеджера очередей,
который подключается к кластеру или покидает его состав, но не тех менеджеров,
которые уже располагаются в кластере.
Менеджеры очередей, к которым во время запроса служб подключаются приложения,
тоже могут динамически присоединяться к кластеру и выходить из него. К примеру,
в инфраструктуре могут существовать шлюзы доступа по Web-интерфейсу, который
также должен справляться с меняющейся нагрузкой. Для обращения к общим служ­
бам, реализованным по всему предприятию, менеджер очередей может располагаться
в офисе каждого удаленного филиала организации.
Пример инфраструктуры WebSphere MQ на базе кластера менеджеров показан
на рис. 3.3.
Средства поддержки очередей сообщений в WebSphere MQ
33
Рис. 3.3. Пример архитектуры WebSphere MQ на базе кластера менеджеров
3.4. Надежность служб и целостность данных
Надежностью, доказанной более чем десятилетием разработки, менеджеры очередей
WebSphere MQ, совместно входящие в состав одноименной инфраструктуры, зарабо­
тали прекрасную репутацию. Они действительно могут работать в течение длитель­
ного периода времени, наконец, к ним так же долго могут быть подключены прило­
жения.
Связь менеджеров очередей по коммуникационным каналам устойчива к сбоям сете­
вого характера, так как WebSphere MQ предоставляет гарантию точного осуществле­
ния однократной доставки.
3.4.1. Постоянные и непостоянные сообщения
Определенные взаимодействия приложений внутри системы затрагивают лишь дан­
ные из запросов, потеря которых может доставить ряд неудобств, однако не отразит­
ся на целостности хранимых в системе данных. В подобных случаях производитель­
ность можно считать важнее, чем целостность информации.
Так, доступ к приложению, направившему запрос о состоянии заказа через графиче­
ский интерфейс, может производиться из разных точек сети или по Интернету.
34
Глава 3
Пользователь, обратившись к данным такого рода, пожалуй, будет готов ждать
информацию по запросу лишь ограниченный интервал времени. Если информация
недоступна, сообщение-запрос или сообщение-ответ с полученной информацией
может уже не требоваться. Потеря сообщения при таких обстоятельствах не столь
существенна, как неспособность эффективно обработать данное сообщение.
Вместе с тем сообщения с критичными для бизнеса данными, такими как подтверж­
дение оплаты сделанного заказа, должны надежно обслуживаться системой. Если на
какой-либо машине в инфраструктуре произойдет сбой или пункт назначения ока­
жется недоступен при плановой профилактике отдельных станций инфраструктуры,
сообщения должны дождаться того момента, когда их можно будет доставить.
Для отражения характера находящихся внутри данных сообщения, передаваемые
в инфраструктуре WebSphere MQ, помечаются как относящиеся к одной из двух кате­
горий.
 Непостоянные (nonpersistent) сообщения. По соображениям производительности
WebSphere MQ оптимизирует действия, выполняемые над непостоянными сооб­
щениями. Непостоянные сообщения могут теряться, если сетевое соединение
менед­жеров очередей дает сбой, менеджер очереди подвергается перезапуску
в профилактических целях или внезапно возникает ошибка, из-за которой менед­
жер очереди нештатно прекращает свою работу.
Так как потеря данных некоторых запросов может причинить неудобства, а сами
данные может потребоваться запросить вновь, менеджер очереди можно настро­
ить так, чтобы допускать меньше оптимизирующих действий над некоторыми
непостоянными сообщениями. В число подобных настроек входит отказоустой­
чивая передача непостоянных сообщений по коммуникационным каналам и
сохра­нение этих сообщений в очередях на протяжении плановых перезапусков
менеджеров. Однако вне зависимости от настроек менеджера очередей однократ­
ная доставка непостоянных сообщений не гарантируется. Сообщения, несущие
критичную для бизнеса информацию, всегда должны помечаться как постоянные.
 Постоянные (persistent) сообщения. Как постоянные маркируются сообщения
с жизненно важными для бизнеса данными. Однократная доставка постоянных
сообщений гарантируется WebSphere MQ, который не отклоняет постоянные
сооб­щения из-за сетевых сбоев, ошибок доставки или плановых перезапусков
менед­жера. Каждый менеджер очереди ведет отказоустойчивый журнал (log) всех
действий, осуществляемых над постоянными сообщениями. Его ведение защища­
ет от внезапных неплановых остановов, влекущих потерю постоянных сообще­
ний. Незавершенные операции над постоянными сообщениями аннулируются,
в том числе для поддержания целостности всех единиц работы, описанной в раз­
деле 3.4.2.
Примечание. При любых обстоятельствах держите данные журнала менеджеров очередей сообщений в надежном хранилище информации. Если находящиеся
в хранилище данные будут утеряны или повреждены, скажем, из-за ошибок на жестком диске, WebSphere MQ не сможет восстановить сообщения.
Средства поддержки очередей сообщений в WebSphere MQ
35
Постоянные сообщения могут позволить упростить конструкцию приложений за
счет использования действующей в WebSphere MQ гарантии однократной доставки.
Сообщение, передаваемое для выполнения операции, будет обязательно доставлено
для обработки по назначению. Приложение, которое в действительности выполняет
действие над сообщением, не обязательно должно быть доступно в момент посылки
сообщения с требованием о его выполнении.
3.4.2. Единицы работы
Многие выполняемые приложением действия нельзя рассматривать изолированно.
В процессе функционирования приложению может потребоваться произвести
отправ­ку или получение множества сообщений. И только в том случае, если одни
сооб­щения успешно отправлены или получены, могут отправляться или приниматься
другие.
Приложение, занятое обработкой сообщений, может осуществлять действия, связан­
ные не только с инфраструктурой WebSphere MQ, но и с другими ресурсами. К при­
меру, в зависимости от содержимого каждого сообщения оно может обновлять
инфор­мацию в базе данных. Действия же по извлечению сообщения, отправке по­
следующего ответа и обновлению информации в базе данных должны фиксироваться
в системе только тогда, когда без сбоев завершено все ранее перечисленное.
Такие действия принято считать относящимися к одной единице работы (unit of
work). Единицы работы, выполняемые приложением с доступом к инфраструктуре
WebSphere MQ, могут включать в себя отправку и получение сообщений, а также
обнов­ления базы данных. Чтобы гарантированно фиксировать единицу работы лишь
в случае успешного выполнения всех ее действий, WebSphere MQ может координиро­
вать все изменяемые ресурсы.
Также WebSphere MQ может участвовать в единицах работы, координируемых други­
ми продуктами. Например, действия в инфраструктуре WebSphere MQ могут вклю­
чаться в единицы работы, которые координирует WebSphere Application Server.
3.5. Безопасность
WebSphere MQ содержит функции обеспечения безопасности доступа, установления
подлинности, а также защиты и целостности процесса коммуникации.
3.5.1. Object Authority Manager (OAM)
Все действия, производимые приложением с подключением к менеджеру, аутентифи­
цируются менеджером очередей при помощи компонента, который носит название
менеджера полномочий объектов OAM (Object Authority Manager).
Настройка менеджера очередей требует описать те объекты WebSphere MQ, которые
входят в соответствующий менеджер. Для выполнения любого действия, такого как
подключение к менеджеру, отправка или извлечение сообщения из очереди, прило­
жение вынуждено обращаться к объектам WebSphere MQ.
36
Глава 3
При этом при каждой попытке приложения произвести какое бы то ни было дей­
ствие над объектом WebSphere MQ менеджер OAM гарантирует, что субъект безопас­
ности, от чьего имени приложение подключено к менеджеру, имеет право на тот тип
доступа, который оно запрашивает по отношению к объекту, над которым осущест­
вляется действие.
3.5.2. SSL-протокол и защита транспортного уровня стека (TLS)
Приложения, подключаемые к WebSphere MQ, не требуют размещения на той же
машине, что и менеджер очередей, с которым соединяются для обращения к инфра­
структуре. Как клиенты данного менеджера приложения могут подключаться и
по сети.
Такое расширение правил доступа дает немалую гибкость, но снижает степень гаран­
тии того, что менеджер очереди верно определяет подлинность всех подключаемых
к нему приложений.
Отраслевыми технологическими стандартами обеспечения подлинности являются
протокол SSL (Secure Sockets Layer) и защита транспортного уровня стека (TLS – Trans­
port Layer Security). И тот и другой имеют аналогичные функции и строятся на схожих
принципах установления подлинности. Как содержащий ряд дополнительных воз­
можностей обеспечения безопасности, TLS часто считают преемником SSL. Web­
Sphere MQ V6.0 реализует как функции TLS, так и функции SSL, введенные в WebSphere
MQ V5.3. Для всех процессов коммуникации по сети в инфраструктуре WebSphere MQ
можно использовать либо защиту транспортного уровня стека, либо SSL-протокол.
Пользуясь этими технологиями, WebSphere MQ может верифицировать подлинность
как подключающихся к менеджеру очередей приложений, так и других менеджеров
в инфраструктуре, с которыми производится обмен сообщениями.
3.5.3. Защита коммуникаций по SSL-протоколу и технологии TLS
Помимо возможности верификации подлинности, а значит, и проведения аутенти­
фикации сущностей OAM-компонентом менеджера очередей SSL-протокол и техно­
логия TLS на уровне отраслевого стандарта обеспечивают безопасность коммуника­
ций.
Любое сетевое соединение в инфраструктуре WebSphere MQ, подлинность сторон
которого верифицирована по SSL-протоколу или технологии TLS, может проходить
шифрование при помощи целого ряда различных алгоритмов, используемых в стан­
дарте SSL-протокола и защиты транспортного уровня TLS. Подобное шифрование
гарантирует защиту коммуникаций.
Также SSL-протокол и технология TLS могут верифицировать целостность данных,
пересылаемых по сетевому соединению. Тем самым реализуется защита от модифи­
кации данных по злому умыслу и повреждения данных сетевой линией связи.
Средства поддержки очередей сообщений в WebSphere MQ
37
3.6. Высокая готовность системы
Надежность WebSphere MQ делает этот продукт отличным решением для создания
инфраструктуры очередей сообщений для служб высокой готовности.
В процессе использования WebSphere MQ должен сочетаться с контролирующей
средой, близко напоминающей производственную среду и применяемой для разра­
ботки и проверки действия приложений, а также тестирования изменений в инфра­
структуре и приложениях до внесения этих изменений в производственную среду.
Вложения в создание контролирующей среды позволяют проверять качество входя­
щих в систему служб с целью гарантировать их наиболее полное соответствие харак­
теру использования системы. Тестирование минимизирует вероятность того, что
сбои программного или логического характера снизят доступность служб, которые
предоставляет система.
Для служб, высокая готовность которых имеет критическое значение, необходимо
предусмотреть порядок действий на период плановых и неплановых остановов.
К причинам простоя служб относятся аппаратные сбои, а также профилактические
работы и обновление приложений и компонентов инфраструктуры.
Подробнее обо всех темах, затронутых в этой главе, читайте в руководстве Understanding high availability with WebSphere MQ по адресу:
http://www.ibm.com/developerworks/websphere/library/techarticles/0505_hiscock/0505_
hiscock.html
3.6.1. Роль кластеров менеджеров в работе служб
высокой готовности
Объединение менеджеров очередей в кластер, речь о котором шла в разделе 3.3.4
«Кластеры менеджеров как возможность гибкого расширения», позволяет динами­
чески устанавливать и разворачивать множество независимых экземпляров конкрет­
ной службы.
Менеджеры очередей в составе кластера менеджеров автоматически маршрутизиру­
ют сообщения всем доступным экземплярам интересующей службы. Если менеджер
очереди помечен как недоступный, к примеру из-за профилактических действий
в инфраструктуре WebSphere MQ или над приложениями и другими ресурсами, необ­
ходимыми службе, то экземпляр службы под управлением данного менеджера больше
не получает новые сообщения.
Аналогично, если менеджер очереди внезапно становится недоступен, к примеру изза коснувшегося его сбоя сети связи или аппаратуры, запросы автоматически пере­
правляются другим, оставшимся доступными экземплярам. Кластеры менеджеров
позволяют инфраструктуре автоматически менять маршруты и обходить сбои.
WebSphere MQ V6.0 вводит дополнительные возможности работы кластеров менед­
жеров, способные обеспечить еще больший контроль над тем, как автоматически
маршрутизируются запросы. Менеджеры очередей на серверах с большей пропуск­
ной способностью могут маршрутизировать большее число сообщений, чем на сер­
верах с более низкими показателями. Наконец, они могут выполнять функцию резер­
38
Глава 3
ва для выполнения служб и получать сообщения только в том случае, когда первичные
менеджеры очередей недоступны.
3.6.2. Группы с разделением очередей на WebSphere MQ для z/OS
IBM WebSphere MQ для z/OS использует возможность объединения систем под z/OS
в так называемый сисплекс (sysplex). Менеджеры очередей в одном сисплексе могут
являться членами группы с разделением очередей (queue sharing group) и вместе полу­
чать доступ к сообщениям в одних и тех же общих очередях.
Тем самым может быть решена проблема доступности сообщений, возникающая
в том случае, когда менеджер становится недоступен, а его очереди непусты. Класте­
ры менеджеров автоматически переправляют новые запросы в обход сбойного
менед­жера, однако сообщения в очередях не могут быть прочтены, пока менеджер
не станет доступен снова.
Если менеджер очереди является членом группы с разделением очередей, то обра­
титься к сообщениям в очереди могут и другие менеджеры очередей в группе, остаю­
щиеся доступными и позволяющие предотвратить недоступность интересующих
сооб­щений.
3.6.3. Кластеры высокой готовности
Другим решением проблемы доступности сообщений при сбое аппаратуры или в пе­
риод плановой профилактики, к примеру обновления компонентов программных
средств, являются кластеры высокой готовности.
Они предполагают наличие первичного и вторичного аппаратного сервера, каждый
из которых содержит все программные компоненты, необходимые для предоставле­
ния службы. По запросу, сформированному вручную, или при сбое любого из компо­
нентов первичного сервера, реализующих службу, система аварийно переключается
(failover) с первичного сервера на вторичный.
Надежное хранилище информации, которое для хранения данных используют все
программные компоненты первичного сервера, также переключается на вторичный.
Это дает возможность аналогичным компонентам вторичного сервера получить до­
ступ к данным точно в том состоянии, которое они имели на момент сбоя.
Примечание. Кластеры высокой готовности являются не функциональной
возможностью продукта WebSphere MQ, а более широкой концепцией, реализованной в целом ряде продуктов, в том числе у многих производителей операционных систем. Не смешивайте кластеры высокой готовности и кластеры менеджеров очередей, представляющие собой функционал WebSphere MQ.
Одним из множества примеров продуктов с поддержкой кластеров высокой
готовности является IBM HACMP™, реализующий кластеризацию серверов
под управлением IBM AIX® 5L™.
В контексте WebSphere MQ это означает, что установка WebSphere MQ производится
на каждый из серверов, и оба сервера содержат менеджер очереди, настроенный на
Средства поддержки очередей сообщений в WebSphere MQ
39
хранение данных в надежном хранилище информации, переключаемом между этими
серверами.
И хотя оба менеджера не могут функционировать параллельно и обращаться к оди­
наковым данным, программные средства поддержки кластера высокой готовности
переключают надежное хранилище информации с одного сервера на другой при
обнаружении сбоя.
Немаловажно и то, что эта функциональность реализуется независимо от WebSphere
MQ. Причиной этого является то, что ресурсы, которые нужно переключить с одного
сервера на другой, не ограничены лишь WebSphere MQ. После аварийного переклю­
чения доступными должны быть все программные компоненты, необходимые для
реализации службы, включая сами приложения и всевозможные базы данных, серве­
ры приложений и прочие программные средства инфраструктуры. Все эти программ­
ные компоненты должны иметь доступ к точно таким же данным, какие были на мо­
мент сбоя.
Для обеспечения прозрачности перехода с точки зрения работы службы как таковой
переключению подлежит и подтверждение подлинности сервера в сети.
Будучи поставляемым как независимый компонент, программное обеспечение для
поддержки кластеров высокой готовности способно самостоятельно установить
доступность всех программных компонентов, которые должны находиться под его
управлением, и осуществить межмашинное переключение всех найденных компо­
нентов.
Решение для кластеров высокой готовности является сочетанием программных инст­
рументов кластеризации, способных осуществлять координацию всех ресурсов,
и надежного хранилища информации, способного переключаться между первичны­
ми и вторичными серверами. Для использования хранилища с возможным межма­
шинным переключением после сбоя все необходимые программные компоненты,
включая нестандартные приложения, должны быть полностью установлены на каж­
дом из серверов.
Поддержка WebSphere MQ кластеров высокой готовности не ограничена теми или
иными решениями. Компания может выбрать решение, отвечающее ее потребностям,
соответствующее операционным системам и оборудованию.
3.6.4. Восстановление после сбоя
Восстановление после аварийного останова, вызвавшего значительные потери дан­
ных или массовую недоступность рабочих станций, требует проведения тщательного
анализа и планирования. По сути, такие события предсказать невозможно.
Для создания резервной копии менеджера очередей на момент времени может быть
создан полный «мгновенный снимок» всей его информации.
Методы восстановления после сбоя обычно не гарантируют, что после аварии будет
доступна самая актуальная информация. Как правило, резервное копирование дан­
ные не производится синхронно с их фактической записью ввиду наличия связанных
с этим издержек производительности.
40
Глава 3
WebSphere MQ V6.0 предоставляет ряд средств, предполагающих наличие удаленной
копии менеджера на территориально удаленной площадке, созданной на базе «мгно­
венного снимка» менеджера. Действия над данными в самом менеджере, которые
заре­гистрированы менеджером в журнале, могут сегментами передаваться на удален­
ную площадку по мере завершения менеджером очередного сегмента. Перенос может
осуществляться вручную или с использованием продуктов сторонних поставщиков.
На удаленной копии менеджера эти действия можно повторить заново и сделать
отра­жение состояния исходного менеджера очередей более актуальным. Последнее
может дать возможность ускорить восстановление доступности самых последних
по времени резервирования перемещенных на удаленную площадку данных после
аварийного останова. Впрочем, асинхронность резервирования на больших расстоя­
ниях вряд ли обеспечит доступность точно таких же данных, какие имелись на мо­
мент сбоя.
3.7. Мониторинг и учет операций
WebSphere MQ V6.0 содержит ряд новых функций, позволяющих собирать данные
о производительности системы и совершаемых операциях.
Этот раздел главы содержит самый общий обзор предоставляемых системой возмож­
ностей. Подробнее о функциях мониторинга и учета, их назначении и использова­
нии см. руководство Monitoring WebSphere MQ, SC34-6593.
3.7.1. Мониторинг производительности
WebSphere MQ V6.0 способен в реальном масштабе времени предоставлять данные
производительности о потоке сообщений в очередях под управлением менеджеров
и потоке сообщений в каналах между менеджерами очередей.
Помимо этого, он позволяет строить периодические итоговые отчеты со статистикой
загрузки очередей менеджера или каналов, соединяющих менеджеры в составе
инфра­структуры.
3.7.2. Учет
WebSphere MQ V6.0 может формировать отчеты о нагрузке на менеджер очереди для
каждого подключенного к нему приложения. Эти отчеты строятся при отключении
приложения или – для долго выполняемых приложений – через регулярные интервалы.
Отчеты предназначены для получения информации, достаточной для выявления
приложения или сущности, которая вызывает соответствующую нагрузку. Информа­
ция касается действий, осуществляемых приложением, и необходима в целях анали­
за его скорости или определения суммы счета к оплате с учетом выполнявшихся
операций.
Средства поддержки очередей сообщений в WebSphere MQ
41
3.7.3 Трассировка маршрута сообщений
WebSphere MQ V6.0 содержит функции установления маршрута, которым движутся
сообщения в инфраструктуре WebSphere MQ и в связанных с указанным продуктом
системах.
42
Глава 3
4
Создание приложений
для доступа к инфраструктуре
WebSphere MQ
Эта глава описывает возможности создания приложений с использованием тех функ­
ций, которые инфраструктура WebSphere MQ предоставляет в целях реализации
служб и обращения к службам. В ней мы введем принятые в WebSphere MQ фунда­
ментальные понятия межточечного обмена и обмена сообщениями по принципу
публикации-подписки, а также опишем доступные интерфейсы прикладного про­
граммирования (API).
Глава посвящена следующим вопросам:







Кроссплатформенная поддержка
Интерфейсы прикладного программирования (API)
Сообщения WebSphere MQ
Взаимодействие с инфраструктурой WebSphere MQ
Транзакции и единицы работы
Межточечный обмен сообщениями
Обмен по принципу публикации-подписки
Создание приложений для доступа к инфраструктуре WebSphere MQ
43
4.1. Кроссплатформенная поддержка
Образующие инфраструктуру WebSphere MQ менеджеры очередей и приложения,
стремящиеся получить доступ к инфраструктуре, могут располагаться на целом спект­
ре различных типов аппаратуры и операционных систем. Комбинация той или иной
разновидности оборудования и конкретной операционной системы обозначается
как платформа.
Информацию о платформах, которые поддерживают менеджеры очередей в продук­
ции IBM, см. на Web-странице по адресу:
http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html
Для каждой платформы, которая поддерживает работу WebSphere MQ, эта страница
содержит особую спецификацию окружения (SOE – statement of environment) с под­
робным описанием уровней поддержки каждого программного компонента, с кото­
рым может взаимодействовать WebSphere MQ, а также необходимые для WebSphere
MQ сведения о сопровождении компонентов. На ряде платформ версия WebSphere
MQ, которую поддерживает платформа, может не являться последней.
Дополнительные платформы, которые не включены в список и не пользуются под­
держкой корпорации IBM, могут поддерживать компании из числа партнеров IBM
(IBM Business Partner).
Менеджер очередей не обязательно должен находиться на том же сервере, что и под­
ключенные приложения. Если менеджер размещен на другом сервере, для подключе­
ния приложения к менеджеру очередей WebSphere MQ необходима клиентская
составляющая продукта. Силами IBM и компаний со статусом IBM Business Partner
клиентские продукты WebSphere MQ могут поддерживаться на большем числе плат­
форм, чем менеджеры очередей сообщений.
4.2. Интерфейсы прикладного
программирования (API)
Для подключения приложений к менеджерам очередей и взаимодействия с инфра­
структурой WebSphere MQ, частью которой и является менеджер, необходим интер­
фейс прикладного программирования (API – application programming interface).
4.2.1. Интерфейс очередей сообщений (MQI)
Основным API-интерфейсом WebSphere MQ является интерфейс очередей сообще­
ний (MQI – message queue interface).
MQI – это процедурный API, а будучи таковым, он подходит для приложений, создан­
ных на процедурных языках программирования. Процедурным API называется ин­
терфейс, в котором контекст и данные, необходимые любой функции, передаются ей
в момент вызова. Приложение должно контролировать весь контекст и обеспечивать
наличие мест хранения всех элементов данных самостоятельно.
Кроме того, MQI описывает все структуры, константы и базовые типы данных, необ­
ходимые в целях взаимодействия с WebSphere MQ. При разработке приложений
44
Глава 4
с использованием MQI необходимо явно манипулировать этими типами и структу­
рами.
Непосредственное использование MQI возможно из приложений, реализованных
на следующих языках программирования:
 C
 COBOL
Другие описанные в этом разделе API основаны на гибкости MQI и предоставляют
ряд интерфейсов, позволяющих пользоваться преимуществами современных мето­
дов и языков программирования.
4.2.2. API-интерфейсы на базе объектной модели WebSphere MQ
В объектно-ориентированных языках программирования действия, состояния, дан­
ные могут быть связаны с логическими объектами, над которыми эти действия совер­
шаются. Выбор такого подхода при создании приложения позволяет структуре само­
го приложения быть логически ближе к его функциональному назначению.
WebSphere MQ предоставляет набор объектно-ориентированных интерфейсов API
для нескольких объектно-ориентированных языков программирования. И хотя сам
процесс программирования с использованием этих API в случае с тем или иным
языком разнится, все интерфейсы выполнены по единому замыслу, именуемому
объектной моделью WebSphere MQ.
Интерфейсы служат оболочкой функциональности и структур данных, предостав­
ленных MQI, реализуя их в виде классов, по которым могут строиться экземпляры
объектов. Каждый класс содержит методы, способные работать с экземплярами клас­
са, что позволяет приложению больше сосредоточиться на своей бизнес-логике, уде­
ляя меньше внимания манипулированию и отслеживанию контекста, сопровождению
структур данных или выделению и освобождению памяти.
WebSphere MQ предоставляет следующий набор объектно-ориентированных APIинтерфейсов.
 WebSphere MQ C++.
WebSphere MQ C++ служит API-интерфейсом для C++, соответствующим объект­
ной модели WebSphere MQ. При создании приложений, обращающихся к Web­
Sphere MQ на языке C++, программист может пользоваться как объектно-ориен­
тированным API, так и прямым доступом к операционной системе и аппаратным
возможностям, прибегая, где это необходимо, к функциям языка C. Подробнее
об API-интерфейсе для C++ читайте в руководстве WebSphere MQ Using C++, SC346592.
 WebSphere MQ base Java API.
WebSphere MQ base Java API является API-интерфейсом к базовому диалекту языка
Java, соответствующим объектной модели WebSphere MQ. При создании Java-при­
ложений для доступа к WebSphere MQ программист может использовать преиму­
щества переноса приложения между платформами, который обеспечивает язык
Java. Функциональность платформы Java может упростить и другие аспекты напи­
Создание приложений для доступа к инфраструктуре WebSphere MQ
45
сания приложений. Подробнее о Java API читайте в руководстве WebSphere MQ
Using Java, SC34-6591.
Примечание. Альтернативный интерфейс для языка Java описан в раз-
деле 4.2.3 «Стандартизованные API-интерфейсы для WebSphere MQ».
 Классы WebSphere MQ для .NET:
Классы WebSphere MQ для .NET играют роль отвечающего объектной модели
WebSphere MQ API-интерфейса для окружения .NET. При помощи классов Web­
Sphere MQ для .NET приложения Microsoft Windows могут разрабатываться
на множестве языков программирования. Подробнее о .NET и классах WebSphere
MQ читайте в руководстве WebSphere MQ Using .Net, GC34-6605.
Примечание. Альтернативный интерфейс для окружения .NET описан
в разделе 4.2.3 «Стандартизованные API-интерфейсы для WebSphere MQ».  COM-интерфейс WebSphere MQ.
COM-интерфейс WebSphere MQ содержит ряд компонентов Microsoft ActiveX®,
именуемых WebSphere MQ Automation Classes for ActiveX (MQAX). Компоненты
MQAX соответствуют требованиям, традиционно предъявляемым к ActiveX-ком­
понентам, и объектной модели WebSphere MQ. Подробнее о модели компонент­
ных объектов (COM – Component Object Model) и MQAX читайте в руководстве
WebSphere MQ for Windows V6.0, Using the Component Object Model Interface,
SC34-6594.
4.2.3. Стандартизованные API-интерфейсы для WebSphere MQ
Как было сказано в разделе 3.2.7 «Стандартизованные API-интерфейсы», стандартизо­
ванные API для обращения к WebSphere MQ могут придать дополнительную гибкость
приложениям, в которых они используются.
Примечание. Благодаря более простым и стандартизованным концепциям
отправки и получения сообщений и скрытию деталей реализации стандартизованные API могут упрощать логику приложений. Для реализации функций стандартизованного API слой между ним и инфраструктурой WebSphere MQ использует
необходимую функциональность WebSphere MQ.
Доступ ко всему спектру функций инфраструктуры WebSphere MQ может требовать применения собственного API-интерфейса WebSphere MQ.
46
Глава 4
Примерами стандартизованных API-интерфейсов, которые могут использоваться для
доступа к инфраструктуре очередей сообщений WebSphere MQ, являются.
 Java Message Service (JMS):
JMS – часть стандарта Java 2 Platform Enterprise Edition (J2EE), которая инкапсули­
рует как модель межточечного обмена, так и модель обмена сообщениями по прин­
ципу публикации-подписки. По сути, приложения, созданные на Java с JMS-интер­
фейсом, могут не зависеть от брокера, предоставляющего возможности публика­
ции и подписки в WebSphere MQ. Это дает свою гибкость и позволяет обновлять
брокер публикации-подписки WebSphere MQ без дорогостоящей переработки
соз­данных приложений.
При доступе к функциям обмена сообщениями по принципу публикации-подпис­
ки от приложений, использующих JMS API, не требуется формировать и запускать
команды публикации и подписки WebSphere MQ.
JMS – отраслевой стандарт обмена сообщениями в рамках спецификации J2EE.
J2EE стандартизирует интерфейсы к целому ряду общих элементов функциональ­
ности, одним из которых является прием и передача сообщений по JMS.
WebSphere MQ содержит все средства и инструменты, необходимые для того, что­
бы приложение для обмена сообщениями через JMS-интерфейс могло получить
доступ к инфраструктуре WebSphere MQ. Таким образом, WebSphere MQ становит­
ся поставщиком (provider) JMS для данного приложения.
Примечание. Сообщения, размещенные в инфраструктуре WebSphere MQ
посредством JMS API, по умолчанию содержат ряд связанных метаданных. С их
помощью через JMS API сообщения могут получать удаленные приложения. Для обеспечения возможности взаимодействия с приложениями через другие API
доступа к инфраструктуре WebSphere MQ метаданные могут быть заблокиро­
ваны.
Приложения, которые обращаются к инфраструктуре WebSphere MQ через JMSинтерфейс, могут располагаться на сервере WebSphere Application Server. Это поз­
воляет им пользоваться полным набором функций стандарта J2EE, а также воз­
можностями развертывания и масштабирования, присущими WebSphere Applica­
tion Server.
Встроенная JMS-служба, поставляемая с WebSphere Application Server V5, основана
на WebSphere MQ V5.3. WebSphere Application Server V6 содержит новый компо­
нент-поставщик службы обмена сообщениями по технологии JMS – WebSphere
Platform Messaging. Поставщиком JMS для WebSphere Application Server V6 после
соответствующей настройки может стать WebSphere MQ. Инфраструктура Web­
Sphere Platform Messaging может соединяться с инфраструктурой WebSphere MQ.
Реализуя новое приложение на языке Java и выполняя межточечный обмен либо
обмен по принципу публикации-подписки, продумайте возможность взаимодейст­
вия с WebSphere MQ при помощи JMS.
Язык Java, JMS, спецификации J2EE и WebSphere Application Server являются важ­
ными темами, представляющими самостоятельный интерес.
Создание приложений для доступа к инфраструктуре WebSphere MQ
47
 IBM Message Service Client (XMS).
XMS – интерфейс обмена сообщениями для языков C, C++ и .NET-окружения. Под­
ход XMS-интерфейса к приему и отправлению сообщений очень близок к подходу
JMS API, а значит, и к преимуществам промышленной стандартизации, характер­
ным для JMS.
XMS инкапсулирует как модель межточечного обмена, так и модель обмена сооб­
щениями по принципу публикации-подписки. Приложения, разработанные на C,
C++ или в окружении .NET с XMS-интерфейсом, могут не зависеть от брокера,
предоставляющего возможности публикации и подписки в WebSphere MQ. Это
дает свою гибкость и позволяет обновлять брокер публикации-подписки Web­
Sphere MQ без дорогостоящей переработки созданных приложений.
При доступе к функциям обмена сообщениями по принципу публикации-подпис­
ки от приложений, использующих XMS API, не требуется формировать и запускать
команды публикации и подписки WebSphere MQ.
Сообщения, размещенные в инфраструктуре WebSphere MQ приложениями, в ко­
торых используется XMS API, могут извлекаться из нее приложениями, в которых
для взаимодействия с инфраструктурой WebSphere MQ используется API-интер­
фейс JMS.
На сегодняшний день средства для упрощения разработки приложений с приме­
нением XMS-интерфейса и обеспечения возможности отправки и получения
сообщений подобными приложениями в инфраструктуре очередей сообщений
WebSphere MQ находятся в пакете SupportPac IA94. Подробнее об этом см. по ад­
ресу:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24007092&loc=en_
US&cs=utf-8&lang=en
Примечание. В настоящее время SupportPac IA94 относится к категории 2
(Category 2), то есть его поддержка по каналам обслуживания продукции IBM
недоступна. Подробности приведены на Web-сайте.
Реализуя новое приложение на C, C++ или в окружении .NET и выполняя межто­
чечный обмен либо обмен по принципу публикации-подписки, продумайте воз­
можность взаимодействия с WebSphere MQ при помощи XMS.
4.2.4. Индивидуальные адаптеры
Если WebSphere MQ не имеет интерфейса для конкретного языка программирования
или программного компонента инфраструктуры, который необходим приложению,
для него может быть создан индивидуальный адаптер (custom adapter).
Индивидуальные адаптеры обеспечивают возможность взаимодействия одного из
API, упомянутых ранее, например MQI, и языка программирования или программно­
го компонента инфраструктуры, в рамках или при помощи которого разработано
приложение.
48
Глава 4
Индивидуальный адаптер – пример прокси-модуля, который задействует существую­
щий интерфейс и расширяет его в целях работы с инфраструктурой очередей сооб­
щений WebSphere MQ.
Примером подобного адаптера является реализованная в пакете SupportPac MA89
поддержка языка Perl для MQSeries®. Этот индивидуальный адаптер служит интерфей­
сом между WebSphere MQ и языком Perl. Подробнее о SupportPac MA89 см. по адресу:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24000208&loc=en_US&cs=
utf-8&lang=en
Примечание. SupportPac MA89 имеет 4-ю категорию сервиса (Category 4).
Его поставку осуществляет не IBM, а сторонний производитель. Подробности
приведены на Web-сайте.
4.3. Сообщения WebSphere MQ
Сообщения, пересылаемые в инфраструктуре WebSphere MQ, могут содержать данные
различных форматов, выбранных с учетом конкретных требований приложений,
обращающихся к инфраструктуре.
Для выполнения обработки каждого отдельного сообщения необходимы данные о
самом сообщении, которые не являются частью передаваемой сообщением инфор­
мации и касаются, к примеру, того, требует ли сообщение ответа от приложения, ко­
торое его обработает.
4.3.1. Дескриптор сообщения
Каждое сообщение в инфраструктуре WebSphere MQ имеет связанный с ним дескриптор (message descriptor).
Дескриптор содержит метаданные сообщения. Они описывают сообщение, но не
являются частью данных, которые в нем находятся.
Ряд метаданных формируется приложением-отправителем сообщения, ряд – генери­
руется и автоматически обновляется WebSphere MQ по мере движения сообщения
по инфраструктуре очередей. Приложению-получателю сообщения доступны все его
метаданные.
Примерами метаданных, которые мы обсудим в этой главе, являются:




уникальный, или индивидуальный, идентификатор сообщения;
тип сообщения, определяющий потребность в формировании ответа;
детали отправки ответа на данное сообщение;
срок жизни (expiry interval), определяющий, имеет ли сообщение конечный
период существования;
 информация о том, как, когда, кем было создано сообщение;
 информация о представлении данных в теле данного сообщения.
Создание приложений для доступа к инфраструктуре WebSphere MQ
49
4.3.2. Преобразование данных
Отдельные машины, где размещаются менеджеры очередей инфраструктуры Web­
Sphere MQ, могут представлять символьные и числовые данные неодинаковым обра­
зом. Для представления конкретного символа и числа могут служить различные зна­
чения байтов.
Каждый менеджер очередей, работающий на конкретной машине, «понимает» при­
нятый на ней способ представления символов или чисел. Это значит, что он способен
осуществить конвертацию данных для перевода их из иных представлений в то
представление, которое будет доступно приложениям, работающим на конкретном
компьютере.
WebSphere MQ можно настроить для выполнения такого преобразования двумя спо­
собами.
 При прохождении сообщением инфраструктуры WebSphere MQ конвертация
данных может производиться всякий раз по достижении сообщением очередного
менеджера в канале. Этот подход может оказаться неэффективным, поскольку,
прежде чем достичь места своего назначения, сообщение может пройти целую
череду менеджеров.
 При получении сообщения о потребности в конвертации данных может объявить
приложение. В результате данные переводятся в локальное представление той ма­
шины, на которой выполняется приложение, которое, впрочем, может запросить
конкретный вариант перевода. Этот способ преобразования данных является
реко­мендуемым к применению.
4.3.3. Форматы сообщений
Для того чтобы менеджер был в состоянии преобразовать данные сообщения, он
должен быть информирован о том, какие данные в нем содержатся. Эта задача реша­
ется приложением-отправителем, которое указывает формат в дескрипторе сообще­
ния. Если формат сообщения не указан, WebSphere MQ трактует тело сообщения как
двоичное, и перевод данных становится невозможен.
Формат сообщения определяет один тип данных.
Часто сообщения содержат данные только в символьном представлении, так как оно
может служить для записи и цифр, и букв. К примеру, для обеспечения единой струк­
туры передаваемых сообщений приложения-отправители и приложения-получатели
могут пользоваться языком XML (Extensible Markup Language). XML-сообщения пред­
ставляют все содержащиеся в них данные в виде символов, так что WebSphere MQ
может произвести конвертацию данных всего подобного сообщения.
Также WebSphere MQ допускает гибкую структуризацию сообщений, которые могут
содержать комбинацию двоичных, символьных и числовых данных, а также ряд
допол­нительных метаданных, прозрачно интерпретируемых WebSphere MQ для опи­
сания структуры передаваемой информации.
50
Глава 4
4.3.4. Сборка сообщений из их фрагментов
Особую гибкость в работу инфраструктуры вносит сборка сообщения из фрагментов,
способ осуществления которой понятен заложенным в менеджерах очередей алго­
ритмам преобразования информации. Каждый фрагмент сообщения имеет свою
длину; сумма длин всех фрагментов соответствует всей длине сообщения.
Формат каждого из фрагментов и сведения об исходном способе представления ука­
заны в предшествующем фрагменте. Первый фрагмент определяется полями в де­
скрипторе сообщения. Дескриптор сообщений, содержащих лишь символьную или
двоичную информацию, детально описывает сообщение целиком.
Вкратце типы фрагментов сведены в приведенный далее перечень:
 Фрагмент, который WebSphere MQ может рассматривать как содержащий единый
тип данных. Данные, которые WebSphere MQ может воспринимать в качестве
одно­типных, – это:
– двоичные данные, которые WebSphere MQ не конвертирует;
– символьные данные, конвертацию которых WebSphere MQ может произвести.
 Структура WebSphere MQ: структуры такого рода могут содержать данные многих
различных типов, а ряд структур – и дополнительные метаданные сообщения.
Структуры могут автоматически добавляться и удаляться из сообщений самим
WebSphere MQ при прохождении инфраструктуры.
Если после структуры допустим другой фрагмент сообщения, структура содержит
достаточный объем данных с описанием деталей следующего фрагмента. Эти
данные образуют подмножество сведений из дескриптора сообщения.
Примеры структур данного рода следующие.
– Заголовок транспортной очереди и очереди недоставленных сообщений: Авто­
матически добавляются к сообщению менеджером очередей в ситуациях, опи­
санных далее в этой книге. Обычно приложения не добавляют к сообщениям
сами эти структуры, однако знать о возможности добавления к сообщению
данных структур полезно при просмотре сообщений в очереди менеджера
очередей.
– Первый и второй заголовки правил и форматирования. Могут использоваться
приложениями для описания содержимого сообщений с данными множества
разных типов, например, с комбинацией символьных и числовых данных.
Сборка ряда фрагментов одного сообщения с использованием этих структур
может оказаться полезной для проведения дифференцированной конвертации
данных из различных фрагментов.
Примечание. Сообщения, помещенные в инфраструктуру WebSphere MQ
стандартизованными API, такими как JMS (Java Message Service), нередко
содержат автоматически пристыкованные к ним заголовки правил и форматирования, в которых содержатся метаданные, необходимые стандартизованным
интерфейсам.
Создание приложений для доступа к инфраструктуре WebSphere MQ
51
 Команда WebSphere MQ. Отдельные сообщения адресуются компонентам Web­
Sphere MQ, заставляя их выполнять определенные действия. Примерами упомяну­
тых компонентов являются брокер публикации-подписки, а также командный
сервер WebSphere MQ, обсуждаемые далее в этой книге. Структуру сообщений,
которые содержат эти команды, WebSphere MQ определяет самостоятельно.
Примечание. Использование стандартизованных интерфейсов, например JMS,
для приема и передачи сообщений по принципу публикации-подписки может
сделать необязательными формирование и передачу команд брокеру публикацииподписки в составе WebSphere MQ.
4.4. Взаимодействие с инфраструктурой
WebSphere MQ
Для обращения к инфраструктуре WebSphere MQ приложения подключаются к ме­
неджеру очередей, используя для этого любой API-интерфейс, обсуждавшийся выше.
При этом они могут соединиться с менеджером, работающим на той машине, где
выполняются сами. Это самый эффективный способ подключения к менеджеру, кото­
рый именуется связыванием (binding).
Кроме того, используя клиентское (client) подключение по сети, приложения могут
соединяться с менеджером на удаленной машине. Работа соединения как клиента
накладывает свой отпечаток на его скорость, а удаленный менеджер очередей должен
быть доступен для успешного подключения. Вместе с тем установку сервера на маши­
ну, где расположен клиент, производить не потребуется.
4.4.1. Клиентские продукты WebSphere MQ
На машине, где установлены приложения, которые подключаются к инфраструктуре
WebSphere MQ как клиенты менеджера очередей, требуется лишь небольшой объем
программных средств WebSphere MQ.
Примечание. Некоторые клиентские продукты WebSphere MQ доступны как
пакеты поддержки SupportPac, некоторые поставляются на дистрибутивном
носителе для установки WebSphere MQ.
Лицензии на сервер WebSphere MQ для машин, имеющих исключительно клиентскую инсталляцию WebSphere MQ, на сегодняшний день не требуются.
4.4.2. Основные возможности приложения WebSphere MQ
Приведенный далее перечень вкратце описывает основные возможности, которые
предоставляются приложениям, подключенным к инфраструктуре WebSphere MQ
через отдельный менеджер.
52
Глава 4
 Приложение может извлекать сообщения из очередей под управлением данного
менеджера для обработки и реализации службы с интерфейсом к очереди, выпол­
ненным по принципу «запрос – ответ» или «отправил – забыл».
 С учетом характеристик очереди менеджера очередей, к которому произошло
подключение, приложение может получить в инфраструктуре уникальный объект.
Он предъявляется другим приложениям, давая им возможность посылать сообще­
ния данному. При межточечном обмене в WebSphere MQ он называется очередью
ответа (reply-to queue); другое его название – очередь отклика (response queue).
В случае, если это необходимо, уникальный объект может существовать и после
завершения приложения. Несколько приложений могут коллективно использо­
вать одну очередь, извлекая лишь предназначенные для них сообщения и пользу­
ясь для этого корреляционным идентификатором (correlation identifier). Возмож­
ности получения уникального объекта мы обсудим в разделе 4.6.14 «Реализация
очереди ответов».
 Приложение может посылать сообщения очередям в любую точку инфраструкту­
ры. Для этого менеджер очередей, к которому подключено приложение, достаточ­
но настроить так, чтобы он знал о наличии места назначения сообщения.
При асинхронной взаимосвязи с прочими приложениями, подключенными
к одно­му менеджеру, очередь назначения может находиться под управлением того
же самого менеджера.
Инфраструктуру WebSphere MQ можно настроить так, чтобы маршрутизация сооб­
щений учитывала лишь названия очередей. Это рекомендуется делать при отправ­
ке сообщений службам, что оставляет возможность перенастроить инфраструкту­
ру без ущерба для интерфейса к службам-получателям сообщений.
Приложение может задать конкретную очередь назначения в инфраструктуре,
указав имя очереди и ее менеджера. Это полезно при генерации ответов или отче­
тов, высылаемых как ответ на запрос к службе со стороны приложения.
И в первом, и во втором случае менеджер очередей, к которому подключено при­
ложение, должен знать, как направить сообщение в очередь назначения. Решение
на этот счет в процессе разрешения названия очереди (queue name resolution)
принимает каждый менеджер на пути к месту назначения сообщения, а значит, он
должен знать лишь следующий шаг маршрута доставки по назначению.
Информацию о маршрутах к очередям и менеджерам, которую хранят все менед­
жеры очередей сообщений, можно сконфигурировать при помощи определенных
на данном менеджере объектов очередей (queue objects) WebSphere MQ. Кластеры
менеджеров дают возможность автоматически узнавать об альтернативных марш­
рутах к очередям и менеджерам в составе инфраструктуры, а также производить
балансировку нагрузки между несколькими очередями кластера с одним именем.
Дальнейшее обсуждение разрешения названий очередей и процедуры техничес­
кой настройки менеджеров, управляющих разрешением, см. в разделе 6.2.1 «Раз­
решение названия очереди».
 Приложение может получить доступ к функциям публикации и подписки, предо­
ставляемым инфраструктурой для публикации сообщений и подписки на опреде­
ленные темы.
Создание приложений для доступа к инфраструктуре WebSphere MQ
53
При непосредственном использовании публикации и подписки в WebSphere MQ
реализованный в инфраструктуре брокер публикации-подписки принимает
команды по интерфейсу «запрос – ответ». Интерфейс позволяет зарегистрировать
приложение в роли подписчика по некоторой теме, публиковать по ней сообще­
ния или посылать брокеру команды прочего содержания.
Аналогично приему ответов в интерфейсе «запрос – ответ» сообщения по
подписке ставятся в очередь, управляемую тем менеджером, к которому подклю­
чено приложение.
Подробнее о публикации и подписке в WebSphere MQ и расширении возмож­
ностей публикации и подписки в инфраструктуре WebSphere MQ см. раздел 4.7
«Обмен по принципу публикации-подписки».
Примечание. Используя стандартизованные API так, как описано в разделе
4.2.3 «Стандартизованные API-интерфейсы для WebSphere MQ», интерфейс
публикации-подписки WebSphere MQ можно значительно упростить.
4.5. Транзакции и единицы работы
Единицы работы дают возможность группировать множество действий, выполняе­
мых приложением, с тем чтобы каждая отдельная операция в составе единицы рабо­
ты успешно фиксировалась в системе только в том случае, если все действия в данной
единице работы успешно завершены.
Базовым элементом, позволяющим регистрировать или отменять действия в рамках
единицы работы как единую группу, служит транзакция. Нередко термины «транзак­
ция» и «единица работы» используют как синонимы.
Транзакции WebSphere MQ позволяют фиксировать или аннулировать ряд действий
над сообщениями в составе единицы работы. Над сообщениями в WebSphere MQ
можно произвести две базовые операции.
 Сообщение можно поставить в очередь. Это – первое действие приложения по
отправке сообщения через инфраструктуру очередей, также каждый раз выполня­
емое каналом при размещении сообщения в транспортной очереди или очереди
пункта назначения сообщения.
Это действие называется постановкой сообщения в очередь или операцией put.
 Сообщение можно извлечь из очереди. Этим занимается приложение или канал
сообщений, переправляющий сообщение из транспортной очереди по каналу
коммуникации.
Это действие называется извлечением (изъятием) сообщения из очереди или опе­
рацией get.
4.5.1. Локальные единицы работы
По умолчанию единица работы может содержать только put- и get-операции. Web­
Sphere MQ автоматически начинает единицу работы и также формирует транзакцию.
Говорят, что единица работы локальна для WebSphere MQ.
54
Глава 4
Транзакция, управляющая локальной единицей работы, координируется WebSphere
MQ, поскольку WebSphere MQ владеет транзакцией, управляющей единицей работы.
4.5.2. Точка синхронизации
Локальные единицы работы автоматически создаются при первом выполнении при­
ложением операций put или get. Условием этого является требование к WebSphere MQ
осуществить данное действие под управлением точки синхронизации (syncpoint).
Выражение «под управлением точки синхронизации» означает, что операция put или
get должна входить в текущую единицу работы. Все дальнейшие операции, которые
выполняются под управлением точки синхронизации и могут относиться к различ­
ным очередям, продолжат оставаться частью этой единицы работы, пока она не будет
завершена.
4.5.3. Фиксация и отмена
Локальная единица работы может стать завершенной в трех ситуациях.
 Приложение фиксирует (commit) единицу работы. Значит, каждое действие этой
единицы работы должно быть зарегистрировано. Об успешной или о неудачной
фиксации единицы работы приложение будет проинформировано системой.
 Приложение отменяет (back out) единицу работы. Значит, все действия данной
единицы работы аннулируются, каждое сообщение возвращается в очередь,
из которой было извлечено в этой единице работы операцией get, и удаляется
из очереди, в которую было помещено в этой единице работы операцией put.
 Приложение отключается от WebSphere MQ. Если отключение имело контролиру­
емый характер, локальная единица работы фиксируется WebSphere MQ от имени
приложения, и приложение получает уведомление, если фиксация закончилась
неудачно. Однако если приложение завершает свою работу без управляемого
отклю­чения от WebSphere MQ, то, обнаружив подобное завершение, WebSphere
MQ откатит все текущие единицы работы данного приложения.
4.5.4. Незафиксированные сообщения
Если сообщения помещаются в очередь в пределах единицы работы (под управлением
точки синхронизации), то они недоступны к изъятию для других приложений, а также
для приложения, разместившего эти сообщения в очереди, пока данная единица работы
не окажется зафиксирована. При аннулировании единицы работы все сообщения, раз­
мещенные в очередях за время данной единицы работы, никогда не станут дос­тупны к
изъятию для других приложений.
Если сообщения извлекаются из очереди в пределах единицы работы (под управле­
нием точки синхронизации), они становятся недоступны для других приложений
сразу после выполнения get. Поэтому два приложения не могут извлечь из очереди
одно и то же сообщение. Однако сообщения, изъятые из очереди за время единицы
работы, реально не удаляются из очереди, пока данная единица работы не окажется
зафиксирована. При аннулировании единицы работы все сообщения, изъятые за ее
время из очереди, снова становятся доступными к изъятию для любых приложений.
Создание приложений для доступа к инфраструктуре WebSphere MQ
55
В результате, если то же самое приложение повторно попытается произвести извле­
чение (get) в следующей единице работы, оно вполне может извлечь то же самое со­
общение.
Сообщения, которые были помещены в очередь или изъяты из нее в пределах едини­
цы работы, которая еще не зафиксирована и не отменена, называют незафиксированными (uncommitted).
Одновременно в каждом из подключений приложения к менеджеру может осущест­
вляться лишь одна единица работы. Однако в разных потоках приложение может
поддерживать несколько подключений. Поток – это средство, предоставляемое опе­
рационной системой или виртуальной машиной Java (JVM™ – Java Virtual Machine)
для обеспечения возможности выполнять множество действий в одном приложении
параллельно.
4.5.5. Глобальные единицы работы
Одним из самых значимых качеств единицы работы является ее способность содер­
жать действия, выполняемые не только с WebSphere MQ, но и с другими ресурсами.
Самым распространенным примером ресурса такого рода является база данных.
Типичным набором действий, которые может произвести служба внутри системы,
является:
1) изъять из очереди сообщение-запрос;
2) по его данным осуществить запросы к базе данных и ее обновления;
3) отослать сообщения другим службам внутри системы для дополнительного об­
служивания запроса;
4) отослать ответ приложению, направившему запрос.
Если реализующее службу приложение неожиданно закрывается, скажем после шага 2
в предшествующем примере, то целостность системы может зависеть от того, будут
ли аннулированы все действия данной единицы работы. Если они содержатся в гло­
бальной единице работы, то сбой на любом шаге может быть устранен посредством
ее отката. Исходное сообщение-запрос будет возвращено в очередь для обслужива­
ния, как будто оно оттуда не извлекалось.
Единицы работы, включающие действия в WebSphere MQ и действия над другими ре­
сурсами, называют глобальными.
4.5.6. Координация глобальных единиц работы
Транзакция, управляющая глобальной единицей работы, координируется менеджером транзакций (transaction manager), который должен иметь возможность общать­
ся со всеми участниками данной единицы работы. Участники глобальной единицы
работы носят название менеджеров ресурсов (resource manager). В предшествующем
примере к занятым в глобальной единице работы менеджерам ресурсов относились
WebSphere MQ и база данных.
56
Глава 4
WebSphere MQ может выступать в роли менеджера транзакций, который координи­
рует глобальные единицы работы, включающие в качестве менеджеров ресурсов
системы баз данных.
В момент начала глобальной единицы работы приложение обязано проинформиро­
вать менеджер транзакций об этой единице работы. Для старта глобальной единицы
работы проинформирован в том числе должен быть и WebSphere MQ. Причиной
этого является то, что менеджер транзакций не знает, когда именно приложение
выпол­нило первое действие глобальной единицы работы. Например, первым дейс­
твием глобальной единицы работы, координируемой WebSphere MQ, может быть
обнов­ление базы данных.
WebSphere MQ также может выступать в роли менеджера ресурсов глобальной едини­
цы работы, координируемой внешним менеджером транзакций. Примерами внеш­них
менеджеров транзакций являются IBM CICS®, TXSeries® и WebSphere Application Server.
Информацию о настройке WebSphere MQ как менеджера транзакций или менеджера
ресурсов в глобальных единицах работы читайте в главе 9 «Configuring WebSphere
MQ» руководства WebSphere MQ System Administration Guide, SC34-6584.
Примечание. IBM поддерживает работу WebSphere MQ как менеджера
транзакций только с определенным набором менеджеров ресурсов, а работу
WebSphere MQ как менеджера ресурсов – только с определенным набором
менеджеров транзакций. Подробнее об этом читайте по адресу:
http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html
4.5.7. Двухфазная фиксация
Действия всех участников глобальной единицы работы должны быть скоординиро­
ваны для того, чтобы любой менеджер в любой момент времени мог сообщить о воз­
никновении сбоя. Важнейший вид подобной координации известен как двухфазная
фиксация (two-phase commit).
Двухфазная фиксация состоит из двух следующих шагов.
1. Подготовка. Все менеджеры ресурсов, занятые в глобальной единице работы,
полу­чают запрос от менеджера транзакций и должны гарантировать, что они мо­
гут фиксировать эту единицу работы. После того, как менеджер ресурсов успешно
завершил фазу подготовки к фиксации единицы работы, он больше не может
потребовать ее аннулировать. С этого времени право отменить данную единицу
работы принадлежит лишь менеджеру транзакций. Менеджер же ресурсов должен
сохранять информацию о подготовленной к фиксации единице работы неопре­
деленно долгое время, а именно до получения извещения от менеджера транзак­
ций с требованием фиксации или отмены данной единицы работы.
2. Фиксация. Если фаза подготовки к фиксации успешно завершена каждым из ме­
неджеров ресурсов, то менеджер транзакций данной единицы работы информи­
рует все менеджеры ресурсов о необходимости ее зафиксировать.
Создание приложений для доступа к инфраструктуре WebSphere MQ
57
4.5.8. Спецификация XA
Спецификация XA опубликована организацией Open Group и описывает взаимодейст­
вия между менеджером транзакций и менеджером ресурсов. Ей отвечает и WebSphere
MQ. Узнать подробнее о спецификации XA или загрузить ее текст можно на Webстранице по адресу:
http://www.opengroup.org/bookstore/catalog/c193.htm
4.5.9. Расширенный транзакционный клиент
WebSphere MQ позволяет подключающимся к менеджеру очередей приложениям ра­
ботать с ним удаленно, соединяясь по сети в роли его клиентов.
Однако во время координации глобальной единицы работы все менеджеры ресурсов,
управляемые менеджером транзакций, должны присутствовать на той же машине, где
расположен менеджер транзакций как таковой.
По этой причине приложение, которое для подключения к менеджеру очередей
использует стандартную программу-клиент, не может в глобальные единицы работы
включать действия WebSphere MQ.
WebSphere MQ содержит продукт, именуемый расширенным транзакционным клиен­
том. Он позволяет приложениям, которые подключаются к удаленному менеджеру оче­
редей сообщений, включать действия WebSphere MQ в глобальные единицы работы.
Примечание. Данный продукт поставляется на условиях, отличных от принятых
для клиентской инсталляции WebSphere MQ. Подробнее об этом читайте по адресу:
http://www.ibm.com/software/integration/wmq/transclient.html
В этих условиях WebSphere MQ не может выступать в качестве менеджера транзакций
глобальной единицы работы, поскольку координировать глобальные единицы рабо­
ты в WebSphere MQ может лишь менеджер очередей сообщений. Однако WebSphere
MQ может являться менеджером ресурсов глобальной единицы работы. При этом
приложение может, например, участвовать в глобальных единицах работы, коорди­
нируемых WebSphere Application Server.
4.5.10. Отказоустойчивость и обработка ошибок
Выполняя действия WebSphere MQ в рамках единицы работы (под управлением точки
синхронизации) и фиксируя эти действия лишь в случае успешного завершения своих
связанных операций, приложение может стать устойчивым к возникающим сбоям.
Примечание. Ряд выполняемых приложением операций, скажем обновление
файлов в файловой системе или отправка электронных писем администратору,
не может быть помещен в рамки единицы работы. Поэтому разработчику приложений необходимо учитывать, что при внезапном завершении приложения
WebSphere MQ не сможет аннулировать эти действия.
58
Глава 4
Если реализующее службу приложение испытывает проблемы при обработке сооб­
щения, оно может произвести откат текущей единицы работы и вернуть сообщение в
очередь. После этого сообщение снова становится доступным для обработки тем же
или иным приложением, ожидающим сообщений из этой же очереди.
Если приложению требуется поместить в очередь или извлечь из нее несколько со­
общений и эти действия являются частью конкретных действий по обработке, то на­
хождение этих независимых действий в рамках единицы работы означает, что каж­
дое отдельное действие будет успешно совершено, только если вся единица работы
будет зафиксирована успешно. Если в любой момент обработки приложение столк­
нется с проблемой, оно может проинформировать WebSphere MQ, потребовав отме­
нить текущую единицу работы.
Если при обработке сообщения приложение неожиданно дает сбой, а единицу работы
этого приложения координирует WebSphere MQ, то, обнаружив сбой приложения, Web­
Sphere MQ автоматически отменит единицу работы и вернет сообщение в очередь.
Примечание. WebSphere MQ может регистрировать сбой только всего
процесса, но не потоков внутри него. Поэтому, если один поток неожиданно
прерывается, текущая единица работы внутри него не завершается WebSphere
MQ до окончания всего процесса.
Примером такого рода процесса является виртуальная машина языка Java (JVM)
на сервере приложений J2EE. Если сервер выявит сбой в выполняемом приложении и закроет его, при том что приложение работало как Java-поток на виртуальной машине, WebSphere MQ не обнаружит завершения потока до окончания
работы JVM в целом. Впрочем, серверы приложений J2EE имеют поддержку
менеджмента транзакций и могут быть в состоянии урегулировать подобную
ситуацию. WebSphere MQ можно настроить как менеджер ресурсов для единиц
работы отдельных серверов приложений J2EE, включая WebSphere Application
Server, как было сказано в разделе 4.5.5 «Глобальные единицы работы».
4.6. Межточечный обмен сообщениями
Базовые возможности межточечного обмена, включая предоставляемую WebSphere
MQ гарантию однократной доставки постоянных сообщений, обеспечивают надеж­
ную и производительную работу межточечного приема и отправления сообщений,
пересылаемых между приложениями, имеющими доступ к инфраструктуре Web­
Sphere MQ.
В этом разделе мы подробно опишем возможности межточечного обмена по дей­
ствующим в инфраструктуре WebSphere MQ принципам «отправил – забыл» и
«запрос – ответ». Здесь же на уровне реализации мы рассмотрим организацию служб
и доступ к ним приложений.
4.6.1. Извлечение сообщений из очереди
Приложения извлекают сообщения из очередей под управлением менеджеров, к ко­
торым они подключены.
Создание приложений для доступа к инфраструктуре WebSphere MQ
59
Извлекая сообщения, приложение может потребовать исключительных прав доступа
ко всем прибывающим в конкретную очередь сообщениям; и напротив, несколько
приложений могут ожидать появления сообщений в одной общей очереди.
При извлечении сообщений приложения могут просматривать (browse) сообщения
в очереди, не извлекая их и не делая недоступными для других приложений.
Также приложения могут извлекать (get) сообщения из очереди, стирая их из нее
и делая их недоступными для других приложений. WebSphere MQ гарантирует, что
никакие два приложения не могут успешно изъять из очереди одно конкретное сооб­
щение.
Приложения могут ждать появления в очереди доступных им сообщений как некий
период времени, так и неопределенно долгое время, просматривая и извлекая до­
ступные сообщения по мере их появления.
Приложения могут уточнить, что готовы извлекать только те сообщения, которые
имеют определенные признаки или отвечают параметрам соответствия (match
options). Обычно как таким признаком пользуются корреляционным идентификато­
ром, который может быть задействован для связи сообщения в общей очереди не­
скольких приложений только с одним из них.
4.6.2. Размещение служб на основе очередей сообщений
Приложение может предоставлять очередь как интерфейс к реализуемой службе
и извлекать вновь поступающие в очередь сообщения для индивидуальной их обра­
ботки.
Запросы к службе, размещенной на основе очереди, может посылать произвольное
количест­во приложений, которые подключены к инфраструктуре очередей и не вла­
деют данными о доступности службы при отправлении сообщений. Очередь буфери­
зирует сообщения в порядке их постановки, в котором затем эти сообщения могут
быть обра­ботаны. Такой порядок работы именуют FIFO (first-in first-out – «первый
вошел, первый вышел»).
Каждому сообщению может быть назначен приоритет, и сообщения с более высоким
приоритетом извлекаются WebSphere MQ раньше, чем сообщения с более низким.
Приоритеты могут использоваться для обеспечения необходимого качества обслу­
живания разнообразных приложений, посылающих запрос к службе.
Сообщений из одной очереди может ожидать несколько экземпляров приложения
службы, поскольку для ряда служб эффективнее обрабатывать несколько запросов
одновременно. Такие приложения могут располагаться на той же машине, что и ме­
неджер очередей, или подключаться к нему как клиенты с удаленных машин. Введе­
ние большего количества экземпляров приложений, реализующих службу, может
позволить увеличить пропускную способность и производительность службы.
При пользовании лишь названием службы, но не конкретного менеджера в ходе
отправки сообщения службе настройку инфраструктуры можно менять, не влияя
на приложения, посылающие запросы к службе. К примеру, инфраструктуру можно
изменить так, чтобы установить ряд кластеров менеджеров и обеспечить наличие
60
Глава 4
множества экземпляров конкретной службы на базе очередей с одним и тем же
названием под управлением разных менеджеров, а значит, на различных машинах.
Менеджеры очередей, к которым подключены приложения, стремящиеся получить
доступ к конкретной службе, выполняют балансировку нагрузки, распределяя запро­
сы по всем доступным экземплярам интересующей службы.
Завершив обслуживать сообщение, служба может формировать ответы на запрос
обратившегося приложения или строить отчет, зависящий от результатов обслужива­
ния. Речь об этом пойдет в разделе 4.6.15 «Обработка сообщений службой».
4.6.3. Счетчики и очереди возврата
Сбои при обработке сообщений требуют согласованных контрмер. Одним из вари­
антов дальнейших действий является перенос сообщения в другую очередь для спе­
циального рассмотрения, возможно с добавлением к сообщению метаданных, отра­
жающих характер ошибки.
WebSphere MQ позволяет очередям, откуда извлекаются сообщения, задавать очереди
возврата (backout queue). Приложение может проверить правильность названия
такой очереди и пользоваться ею как местом назначения сообщений, обработка
которых вызвала сбой.
Ряд сбоев может не возникать повторно, и дополнительной попытки произвести
обработку может оказаться достаточно. Если приложение получает сообщение в ходе
единицы работы, которую в дальнейшем откатывает, или выдает ошибку при обра­
ботке, WebSphere MQ увеличивает счетчик возвратов (backout count) в дескрипторе
данного сообщения.
При извлечении сообщения приложение может проверить, чему равен счетчик его
возвратов, а это позволит определить, должно ли сообщение быть обслужено или
направлено в очередь возврата.
Дополнительно в очереди может быть задан порог возврата, определяющий, сколько
раз должны предприниматься попытки обработать конкретное сообщение.
Примечание. WebSphere MQ не переносит сообщения в очереди возврата
автоматически.
4.6.4. Службы с управлением по событиям
Используя WebSphere MQ, приложение-поставщик службы может ожидать появления
в очереди сообщений сколь угодно долгое время, не создавая лишней нагрузки на
элементы инфраструктуры.
Это дает возможность управлять службами посредством событий, происходящих
в системе или являющихся результатом внешних взаимодействий системы и челове­
ка. Такие службы могут оперативно и эффективно реагировать на внешние действия
и обрабатывать события, как только те происходят, не посылая периодических
запросов с целью проверить, не случилось ли чего нового.
Создание приложений для доступа к инфраструктуре WebSphere MQ
61
Приложению-поставщику может быть нежелательно долгое время оставаться в сос­то­я­
нии неактивности, ожидая появления сообщений, например в силу наличия ресур­сов,
используемых приложением при простое.
Для обеспечения автоматического запуска приложений при появлении в очереди до­
ступных им сообщений WebSphere MQ реализует механизм "триггеринга" (triggering).
Далее приложение может обработать все сообщения в очереди, после чего закрыться,
или обработать все сообщения, доступные на данный момент, и непродолжительное
время подождать новых.
Также WebSphere MQ поддерживает срабатывание триггеров при поступлении в оче­
редь определенного количества либо при появлении каждого отдельного сообщения.
Это позволяет производить пакетную обработку сообщений и обеспечивать работу
простых приложений, созданных с целью обслуживать по сообщению при каждом из
своих запусков.
4.6.5. Обмен по принципу «отправил – забыл»
Для того чтобы после отправки сообщения приложение могло продолжить свою
работу, достаточно поместить сообщение в очередь, управляемую тем менеджером
очередей, к которому подключено приложение. Это позволяет быстро начать даль­
нейшее выполнение приложения после отправки им сообщения, что особенно спра­
ведливо при пользовании соединением с менеджером очередей через связывание,
а не посредством сетевого подключения приложения как клиента.
Для разрешения названия очереди служит хранящееся в составе менеджера очередей,
к которому подключено приложение, представление инфраструктуры WebSphere
MQ, позволяющее определить, возможна ли отправка данного сообщения. Если да,
сообщение ставится в очередь. Если при этом выясняется, что очередь назначения
имеет локальное размещение, сообщение доставляется напрямую. В противном слу­
чае оно помещается в промежуточную транспортную очередь (transmission queue),
откуда оно будет передано другому менеджеру очередей в составе инфраструктуры.
Ставя сообщение в транспортную очередь, менеджер очередей добавляет в него но­
вую информацию, позволяющую по достижении сообщением другого менеджера
вторично произвести разрешение названия очереди. Новый менеджер может размес­
тить сообщение у себя или осуществить те же действия для передачи сообщения сле­
дующему по маршруту движения в пункт назначения менеджеру в составе инфра­
структуры.
Примечание. Подробнее о принципах построения инфраструктуры WebSphere
MQ, настройке знаний менеджера очередей с использованием объектов
WebSphere MQ, влиянии кластеров менеджеров на эту настройку и сущности
передачи сообщений по каналам коммуникации вы узнаете из следующих глав
книги.
Такая асинхронная природа обмена имеет то преимущество, что позволяет прило­
жениям продолжать действовать в соответствии с бизнес-логикой, пока WebSphere
62
Глава 4
MQ решает коммуникационные задачи доставки каждого сообщения в свою очередь
наз­на­чения.
Если приложение подключено непосредственно к службе, для чего, скажем, исполь­
зуется протокол прямой связи, их работа делается синхронной. Приложение вынуж­
дено ожидать момента, когда служба будет доступна и готова принимать информа­
цию, подключиться к ней, передать данные, получить подтверждение факта доставки
по назначению и лишь затем продолжить свою работу.
При отправке сообщения приложение может указать то, насколько «постоянным»
оно является. Если эта информация не указана, менеджер очередей выставляет нуж­
ное значение по умолчанию на базе настроек объектов-очередей, используемых при
разрешении названия очереди WebSphere MQ.
Сообщение, которое, не требуя ответа, содержит запрос действия от приложенияпоставщика службы, помечается в WebSphere MQ как дейтаграмма (datagram). При­
ложения могут использовать службы, посылая дейтаграммы очередям, реализующим
интерфейсы к подобным службам.
4.6.6. Списки распространения
Приложение может отправить одно и то же сообщение по нескольким адресам, ис­
пользуя единственную операцию WebSphere MQ, связанную со списком распростра­
нения (distribution list). Если ряд перечисленных в списке распространения мест на­
значения менеджер очередей может достичь посредством передачи сообщения по
одному каналу по адресу одного менеджера промежуточной или целевой очереди,
сообщение будет отправлено лишь один раз.
Примечание. Эта возможность недоступна в WebSphere MQ для z/OS.
Подробности см. в руководстве WebSphere MQ Application Programming Guide,
SC34-6595.
4.6.7. Сегментация сообщений
Максимальная длина отдельного сообщения в инфраструктуре WebSphere MQ состав­
ляет 100 Мб. Однако по умолчанию очереди не принимают сообщений длиннее 4 Мб.
Сообщения длиной свыше 100 Мб или 4 Мб – при том что очередь, через которую
сообщение проходит, двигаясь по маршруту к пункту своего назначения, не настрое­
на на прием сообщений большей длины – могут дробиться на фрагменты меньшие
по размеру.
Сегментация при отправке и повторная сборка при получении сообщений может
осуществляться приложением самостоятельно, а может – автоматически менеджером
очередей сообщений.
Создание приложений для доступа к инфраструктуре WebSphere MQ
63
Примечание. Эта возможность недоступна в WebSphere MQ для z/OS.
Подробности см. в руководстве WebSphere MQ Application Programming Guide,
SC34-6595.
4.6.8. Логическая группировка сообщений
В определенных условиях WebSphere MQ не может обеспечить наличие и поддержа­
ние порядка, в котором сообщения ставятся в очередь на обслуживание, или того,
какие именно сообщения извлекаются из очереди конкретными приложениями. Как
правило, сообщения доставляются в порядке отправки, однако на такой ход событий
могут повлиять сбои при передаче сообщения по каналу коммуникации, наличие не­
скольких приложений, извлекающих сообщения из одной очереди, а также единицы
работы.
Приложение может помечать сообщения как относящиеся к одной логической груп­
пе. Внутри нее сообщения нумеруются, что позволяет доставлять их в порядке их от­
правления. Менеджер очередей может автоматически доставлять сообщения группы
в порядке отправки их приложением. По мере необходимости отдельные сообщения
в группе могут проходить сегментацию, однако WebSphere MQ не требует наличия
между содержимым указанных сообщений какой бы то ни было взаимосвязи.
4.6.9. Отчеты
Целью отправки некоторых сообщений является оповещение о событии, скажем,
в порядке отклика на непредвиденную проблему при обработке сообщения дейта­
граммы. В WebSphere MQ такие сообщения помечаются как отчеты (report), в дес­
крипторе которых есть поле feedback с указанием причины их формирования.
Если, получив дейтаграмму, служба совершает ошибку при обслуживании запроса, то
существует ряд действий, которые она может произвести. Одно из них – выдать сооб­
щение-отчет и отослать его отправителю дейтаграммы либо передать это сообщение
другой очереди на специальную обработку.
Приложение может явно запросить в службе сообщение-отчет только в случае сбоя
или успешного завершения. WebSphere MQ передает этот запрос службе в поле дес­
криптора сообщений, служба же может быть реализована так, что в соответствующих
условиях вернет отчет отправителю.
4.6.10. Отчеты «подтверждение доставки»
и «подтверждение прибытия»
Также менеджер очередей WebSphere MQ может автоматически строить отчеты в сле­
дующих ситуациях.
 Подтверждение прибытия (COA – confirm on arrival).
Сообщение прибывает в очередь назначения, которой управляет менеджер це­
левой очереди.
 Подтверждение доставки (COD – confirm on delivery).
64
Глава 4
Сообщение извлекается из целевой очереди программными средствами приложе­
ния.
Эти отчеты приходят по назначению, указанному приложением, отсылающим
сооб­щение, для чего служит тот же механизм, что при обмене по принципу
«запрос – ответ».
4.6.11. Синхронный обмен по принципу «запрос – ответ»
Действия, связанные с отправкой сообщения-запроса и ожиданием ответа, в Web­
Sphere MQ асинхронны и независимы. Тем не менее, если того требует приложение,
их можно свести в одну синхронную операцию.
Действие по отправке запроса совершенно аналогично отправлению дейтаграммы,
однако для получения ответа от приложения потребуется предоставление опреде­
ленной дополнительной информации.
Приложение указывает ту очередь ответов (reply-to queue), в которой ждет появле­
ния реакции на запрос. Эта очередь может принадлежать одному, а может – совмест­
но использующим ее нескольким приложениям. К обсуждению этого мы вернемся
в разделе 4.6.14 «Реализация очереди ответов». Название очереди ответов размещает­
ся в дескрипторе сообщения-запроса.
Также в дескрипторе сообщения может присутствовать название менеджера очереди
ответов. Впрочем, обычно это поле автоматически заполняет WebSphere MQ. В этом
случае оно принимает значение имени менеджера очередей, к которому подключено
приложение.
Сообщение с запросом действия службы и требованием вернуть ответ по адресу при­
ложения-отправителя в WebSphere MQ помечается как запрос (request).
Сообщение с ответом службы на сообщение-запрос приложения-отправителя в Web­
Sphere MQ помечается как ответ (reply).
4.6.12. Частично синхронный обмен по принципу «запрос – ответ»
Разделение формирования запроса и ожидания ответа на пару асинхронных незави­
симых операций способно сделать приложение-инициатор запроса более гибким.
Так, оно может не проверять наличие ответа сразу же по отправлении сообщения.
Взамен оно может выполнять прочие процедуры, не зависящие от получения ответа,
и проверить его приход спустя какое-то время, что позволит сократить время про­
стоя приложения в ожидании обработки запроса службой. Также это может позво­
лить отсрочить обработку ответа на запрос до поступления требования от пользова­
теля или появления надобности, вызванной ходом дальнейшего выполнения прило­
жения.
Отдельные синхронно выполняемые приложениями запросы могут относиться к тем
данным, которые уже надежно хранятся внутри системы. Работая с такими запроса­
ми, приложение может не захотеть неопределенно долгое время ожидать отклика
службы, установив тайм-аут фиксированной длины. Реализация функций тайм-аута
и отклонения запроса до получения ответа возможна благодаря асинхронности при­
ема и отправления сообщений в WebSphere MQ.
Создание приложений для доступа к инфраструктуре WebSphere MQ
65
Примечание. На протяжении времени между отправкой сообщения-запроса
службе и получением сообщения-ответа приложение не может определить
состояние запроса. По окончании тайм-аута текущее состояние запроса не
должно повлиять на дальнейшую обработку, поскольку та еще может быть
успешно завершена или уже закончилась.
Для осуществления тайм-аута приложение может заявить о готовности ждать сооб­
щений в очереди ответов в течение некоего периода ожидания (wait interval). По его
истечении WebSphere MQ уведомляет приложение об отсутствии сообщений, доступ­
ных для обработки в очереди ответов, и приложение продолжает свою работу.
В случае, если это необходимо, приложение может неоднократно возвращаться
к ожиданию сообщений в очереди ответа, выполняя свою работу до и после каждой
попытки. Также приложение может периодически проверять наличие поступающих
в очередь сообщений, передав WebSphere MQ сведения о том, что совершенно не же­
лает тратить время на ожидание при отсутствии сообщений, и вынуждая WebSphere
MQ запрашивать (poll) появление ответа.
4.6.13. Истечение срока существования сообщений
Если приложение работает по тайм-ауту, оно должно указать срок существования
(expiry time) сообщения в дескрипторе отправляемого запроса. Описанное значение
в десятых долях секунды устанавливает приложение-инициатор запроса, WebSphere
MQ сокра­щает его для отражения времени, проведенного сообщением в инфраструк­
туре. Сюда относится время, проведенное в очереди по адресу назначения до приема
сооб­щения службой на обработку, и время во всех транзитных очередях. Когда же
срок существования истекает, сообщение уже не смогут принимать приложения, и
оно станет пригодным для удаления инфраструктурой.
Обычно в дескриптор сообщения-ответа служба копирует текущее время существо­
вания запроса. Однако с учетом конкретной реализации время существования ответа
может приниматься равным заранее установленному значению или не выставляться
для сообщений-ответов вовсе.
Приложение может запросить отчет об истечении срока существования сообщения
(expiry report), который показывает, когда устаревшее сообщение удалилось инфра­
структурой.
Примечание. При обнулении срока существования сообщений WebSphere MQ
не производит их немедленного удаления из очереди. Устаревшие сообщения
продолжают влиять на глубину очереди до попытки их извлечения приложением.
До этого не строится и отчет об истечении срока существования.
В WebSphere MQ V6.0 возможна периодическая проверка всех контролируемых
менеджером очередей, призванная автоматически удалять устаревшие сообщения. Проверка такого рода действует в системе по умолчанию. 66
Глава 4
4.6.14. Реализация очереди ответов
Реализуемая приложением, инициирующим запрос, очередь ответов находится под
управлением менеджера очередей, с которым связано приложение-инициатор.
В большой системе запросы службе может посылать множество приложений, под­
ключенных к одному менеджеру. В подобных случаях WebSphere MQ с успехом мас­
штабируется и предлагает приложению-инициатору на выбор несколько вариантов
задания очереди ответов в сообщении-запросе.
 Использование единой очереди ответов для всех запросов, адресованных службе.
В дескрипторе каждого сообщения в WebSphere MQ содержится идентификатор
(message identifier), который генерируется WebSphere MQ и может быть уникаль­
ным в пределах инфраструктуры.
Также в дескрипторе сообщения есть поле корреляционного идентификатора,
которым приложения могут пользоваться для связи своих запросов с ответами.
При отсылке ответа на сообщение-запрос служба копирует идентификатор сооб­
щения-запроса в корреляционный идентификатор ответа. Это позволяет обеспе­
чить уникальность идентификатора ответа и сохранить связь между ответом и
исходным запро­сом. Приложение, запросившее службу, может ожидать сообще­
ния с тем же корреляционным идентификатором, что и идентификатор запроса,
который был им отправлен.
Данный подход упрощает администрирование и сокращает нагрузку на менеджер
очередей ввиду потребности лишь в одной очереди ответов, задание которой де­
лается вручную. Подход, описанный выше, может использоваться и для постоян­
ных (persistent) сообщений.
Если приложение завершается, не получив ответа на выданный им запрос, а ответ
имеет неограниченное время существования, то вам придется удалить или обра­
ботать сообщение самостоятельно.
Это может вызвать рост очереди, но если сообщения содержат критичные для
бизнеса данные, над оказавшимися в подобном состоянии сообщениями, возмож­
но, требуется произвести определенные действия. К примеру, чтобы восстановить
работу после возникновения сбоя, приложение, выдавшее запрос, может вести
учет отправленных им запросов.
Примечание. Система WebSphere MQ оптимизирована для приложений,
ожидающих сообщений с конкретным корреляционным идентификатором, и от создания приложений, ожидающих сообщений с конкретным идентификатором сообщения, рекомендуется воздержаться. При росте очереди и появлении в ней множества сообщений эффективность приложений второго рода снижается.
 Использование временной динамической очереди.
С целью организации для приложения уникального объекта в пределах инфра­
структуры WebSphere MQ дает возможность создать очередь динамически. Временная динамическая очередь (temporary dynamic queue) существует ровно то
время, пока к ней обращается конкретное приложение. WebSphere MQ автомати­
чески удаляет временные динамические очереди из менеджера, как только прило­
Создание приложений для доступа к инфраструктуре WebSphere MQ
67
жение заявляет, что связанная с очередью обработка завершена, или приложение,
выдавшее запрос, закрывается.
Этот подход приемлем только для результатов запросов данных, содержащихся
в непостоянных (nonpersistent) сообщениях. Во временной динамической очере­
ди не могут содержаться постоянные сообщения с критичной для бизнеса инфор­
мацией, поскольку они автоматически удаляются из менеджера очередей Web­
Sphere MQ при завершении приложения, даже если оно вызвано сбоем и в очереди
есть сообщения.
Используя этот подход, приложение может ожидать появления во временной ди­
намической очереди ответов любых сообщений, не требуя прихода сообщений
с конкретным корреляционным идентификатором. Это гарантирует строгую изо­
ляцию независимых приложений, использующих возможности данной службы,
а значит, снижает и вероятность того, что наугад взятое приложение повредит от­
веты, адресованные другим приложениям, из-за ошибок логического характера.
Системные ресурсы для поддержания каждой временной динамически создавае­
мой и удаляемой очереди довольно невелики.
 Использование постоянной динамической очереди.
Постоянная динамическая очередь (permanent dynamic queue) организуется при
тех же условиях, что и временная, и может использоваться аналогично. Однако
WebSphere MQ не удаляет ее из менеджера автоматически, в том числе при закры­
тии приложения, отправившего запрос. Вместо этого приложение обязано само­
стоятельно удалить очередь из менеджера очередей после завершения обработки.
Этот подход наделен теми же преимуществами, что и работа с временными дина­
мическими очередями, но годится и для использования тогда, когда в составе
сооб­щения-ответа содержится критичная для бизнеса информация.
Если, как в случае с единой очередью ответов, приложение закрывается, не полу­
чив ответа на выданный им запрос, сообщение-ответ и постоянная динамическая
очередь сообщений продолжают существование, пока для обработки сообщения
и удаления очереди не будут приняты определенные меры.
4.6.15. Обработка сообщений службой
Действия службы по согласованной обработке сообщений и генерации ответов и от­
четов на дейтаграммы и сообщения-запросы вкратце иллюстрирует следующий спи­
сок шагов.
1. Начать глобальную единицу работы, если таковые используются.
2. Извлечь сообщение из очереди. При этом может понадобиться учесть сегментацию
сообщения или порядок в логической группе. Если потребность в этом имеется,
уведомить WebSphere MQ о необходимости извлечь сообщение целиком или извле­
кать сообщения в составе группы с учетом порядка следования. Дополнительно вы­
яснить, нужно ли конвертировать данные, – если да, потребовать от менеджера оче­
редей осуществления перевода. При пользовании единицей работы указать, что
данное действие производилось под управлением точки синхронизации.
3. Проверить тип, формат сообщения и запрошенные варианты отчета в его дес­
крипторе. Если они не отвечают функциональности службы, принять необходи­
68
Глава 4
мые меры. К ним может относиться проверка указания очереди возврата и пере­
нос сообщения в эту очередь.
4. Если при обработке сообщений используются единицы работы и очереди возвра­
та, то по возможности проверить счетчик числа возвратов. Если его значение
превышает порог возврата для очереди, то поместить сообщение в очередь воз­
врата.
5. Согласно бизнес-логике службы произвести работу над сообщением, предоставив
запрошенные услуги. Сюда может входить взаимодействие с иными продуктами,
такими как базы данных, и передача сообщений для других служб, которые реали­
зует система.
6. По итогам обработки данного сообщения установить результат, определив, была
ли обработка успешно завершена.
7. Если с учетом типа полученного сообщения и результата его обслуживания необ­
ходим отчет или ответ, сформировать таковой. Набор традиционных шагов здесь
выглядит так.
a. Получить данные для ответа.
b. Создать дескриптор ответа или отчета либо использовать дескриптор исход­
ного сообщения.
c. Убедиться в том, что в дескрипторе должным образом установлены все поля,
относящиеся к содержимому сообщения, включая его формат и способ пред­
ставления данных. Задание их как значений по умолчанию вынуждает Web­
Sphere MQ выбирать те значения, которые соответствуют локальному пред­
ставлению.
d. Установить тип сообщения как ответ или отчет.
e. Из дескриптора исходного сообщения скопировать идентификатор сообще­
ния в корреляционный идентификатор дескриптора ответа или отчета.
f. Очистить идентификатор сообщения в дескрипторе ответа или отчета, побу­
див WebSphere MQ сформировать новый идентификатор сообщения для отве­
та.
g. Использовать время существования, указанное в дескрипторе исходного сооб­
щения, или установить его равным предопределенной величине.
h. При генерации сообщения-отчета выбрать соответствующий код обратной
связи в его дескрипторе.
i. Убедиться, что признак постоянности, а также приоритет ответа или отчета те
же, что и в исходном сообщении.
j. Отправить ответ или отчет, используя названия очереди ответов и управляю­
щего ей менеджера, взятые из исходного сообщения. При пользовании едини­
цей работы указать, что данное действие производилось под управлением
точки синхронизации.
Создание приложений для доступа к инфраструктуре WebSphere MQ
69
Примечание. Эти действия могут включаться в единицу работы. Именно так
мы и советуем поступать при передаче постоянных сообщений с критичной для ведения бизнеса информацией.
8. Фиксировать единицу работы.
4.7. Обмен по принципу публикации-подписки
Обмен сообщениями по принципу публикации-подписки требует применения бро­
кера публикации-подписки, который ведет учет подписки на конкретные темы
и обеспечивает возможность публикации тематических сообщений.
4.7.1. Брокер публикации-подписки WebSphere MQ
WebSphere MQ содержит встроенный брокер, для выполнения функций публикации
и подписки, использующий базовые возможности WebSphere MQ.
Примечание. Брокер публикации-подписки был встроен в WebSphere MQ в пакете Fix Pack 8 для WebSphere MQ Version 5.3 и входит в состав WebSphere
MQ Version 6.0. Ранее он поставлялся в пакете SupportPac MA0C.
Брокер публикации-подписки WebSphere MQ использует инфраструктуру очередей
сообщений WebSphere MQ для приема и обработки команд, учета подписки, хране­
ния текущей статусной информации, а также как механизм доставки при отправке
публикаций подписчикам. Гарантию однократной доставки брокер наследует от сис­
темы.
Примечание. Здесь мы даем лишь краткое описание возможностей брокера
публикации-подписки WebSphere MQ.
Подробнее о публикации и подписке в WebSphere MQ читайте в следующих
руководствах:
 WebSphere MQ Publish/Subscribe User’s Guide, SC34-6606
 WebSphere Business Integration Pub/Sub Solutions, SG24-6088
 MQSeries Publish/Subscribe Applications, SG24-6282
Каждый менеджер очередей может управлять максимум одним брокером, имеющим
то же название в инфраструктуре, что и менеджер очередей, на котором он располо­
жен. Брокеры могут объединяться в сеть брокеров (broker network), давая возмож­
ность приложениям, связанным с одним менеджером, получать публикации в адрес
брокера под управлением другого менеджера.
70
Глава 4
4.7.2. Взаимодействие с брокером публикации-подписки
WebSphere MQ
Брокер публикации-подписки WebSphere MQ имеет набор команд, которые можно
посылать брокеру по интерфейсу «запрос – ответ». Команды выполняют такие функ­
ции, как регистрация приложения как подписчика и публикация сообщения на опре­
деленную тему.
Интерфейс брокера «запрос – ответ» для каждого менеджера очередей использует
очередь, именуемую очередью управления брокером (broker control queue).
Такие стандартизованные API, как Java Message Service (JMS), могут упростить интерфейс
с брокером, сделав необязательными явное формирование и передачу ему команд.
4.7.3. Потоки
Всю массу тематической информации брокер может разбивать на потоки (streams).
Публикация по теме в одном потоке не рассылается подписчикам этой темы, заре­
гистрированным на другие потоки. Подписка и другая необходимая информация
хранится в отдельной очереди WebSphere MQ для каждого из потоков.
4.7.4. Регистрация
Прежде чем получить возможность принимать публикации, каждый подписчик дол­
жен быть зарегистрирован брокером. Регистрация требует наличия у подписчика
очереди, где могут располагаться приходящие от брокера публикации.
Очередь может являться собственной очередью подписчика или использоваться
несколькими подписчиками совместно. Если очередь для подписки делится между
несколькими подписчиками, при регистрации подписчик должен предоставить
корреляционный идентификатор сообщения. Он служит в целях опознавания права
соб­ственности на сообщения в очереди. Аналогичные проблемы существуют при
выборе очереди подписчика, о чем мы говорили в разделе 4.6.14 «Реализация очере­
ди ответов».
Источнику публикаций не требуется регистрации брокером до начала публикации
сооб­щений. Однако он все же может зарегистрироваться в целях настройки некоторых
аспектов поведения по умолчанию, касающихся осуществляемых публикаций и уве­
домления брокера о темах, по которым производится публикация. Публикация вправе
содержать любые произвольные данные, которые могут входить в тело сообщения
WebSphere MQ и описаны в разделе 4.1 «Кроссплатформенная поддержка».
4.7.5. Темы
Темы определяются брокером по символьным строкам, называемым строкой темы
(topic string). Эти строки есть в каждой из публикаций любого источника публикации.
При регистрации брокером подписчик также задает строку темы. В дальнейшем его
строка темы будет сравниваться с темой каждой из публикаций. Если две строки сов­
падают, публикация ставится в очередь, заданную подписчиком при его регистрации.
Посимвольное совпадение строк совершенно необязательно, – в теме, которую при
Создание приложений для доступа к инфраструктуре WebSphere MQ
71
регистрации указывает подписчик, могут находиться символы обобщения, позволя­
ющие оформить подписку на диапазон тем.
Регистрация не прекращается и в том случае, когда приложение-подписчик не вы­
полняется. Это значит, что публикации будут накапливаться в очереди подписчика,
пока тот является неактивным.
4.7.6. Публикации
В WebSphere MQ публикации бывают двух видов.
 Несохраняемые публикации (non-retained publications).
По умолчанию брокер WebSphere MQ удаляет публикации после их постановки
в очередь всех соответствующих зарегистрированных подписчиков.
 Сохраняемые публикации (retained publications).
Источник публикации может потребовать, чтобы одна конкретная или все публи­
кации от его имени сохранялись. Каждый раз при обработке публикации броке­
ром она будет доставляться в очереди всех соответствующих зарегистрированных
подписчиков, а ее копия будет сохранена брокером. По каждой отдельной теме
брокер хранит лишь копию последней по времени публикации.
Одним из частных примеров пользования сохраняемыми публикациями является
хранение данных о состоянии. При публикации их в таком виде подписчик, начиная
свою работу, может запросить текущее состояние по некоторой теме. В итоге, чтобы
определить актуальное состояние, ему не нужно ждать публикации по своей теме.
4.7.7. Развитие функций публикации и подписки в WebSphere MQ
Брокер публикации-подписки WebSphere MQ реализует базовые возможности, необ­
ходимые для пользования моделью обмена сообщениями по принципу публикацииподписки. Однако источник и поставщик информации могут быть разделены еще
больше, что лишь сильнее упрощает создание и внедрение бизнес-служб.
Полноценное раскрытие потенциала модели публикации-подписки может позволить
внедрить такую инфраструктуру сообщений, в которой разнообразные приложения
смогут обмениваться информацией в разной форме, а поток данных контролируется,
маршрутизируется и трансформируется при помощи бизнес-правил, а не закрытой
логики.
IBM WebSphere Business Integration Message Broker и WebSphere Business Integration
Event Broker – это отдельные брокеры, основанные на базовых функциях работы
с сообщениями WebSphere MQ и максимально использующие возможности модели
публикации-подписки.
Совет. Использование стандартизованных интерфейсов для обращения к службам публикации- подписки может обеспечить гибкость при переходе с базовых возможностей обмена сообщениями публикации и подписки WebSphere
MQ на решение на базе WebSphere Business Integration Message Broker или
WebSphere Business Integration Event Broker без дорогостоящей модификации
приложений.
72
Глава 4
5
Менеджеры очередей:
общее представление
и настройка
В этой главе мы обсудим предназначенные для создания и настройки менеджеров
очередей сообщений WebSphere MQ интерфейсы администрирования, а также вкрат­
це опишем работу менеджеров и реализуемые ими функции обеспечения целостно­
сти передаваемых данных.
Глава посвящена обсуждению следующих вопросов:
 Информация об установке
 Интерфейсы администрирования WebSphere MQ
 Менеджеры очередей сообщений
Менеджеры очередей: общее представление и настройка
73
5.1. Информация об установке
Информацию об установке WebSphere MQ на платформах Microsoft Windows, UNIX
и IBM Eserver® iSeries содержат книги WebSphere MQ Quick Beginnings. В них также
приведены этапы проверки правильности вашей инсталляции WebSphere MQ. В зави­
симости от имеющейся платформы читайте следующие руководства WebSphere
MQ V6.0 Quick Beginnings:
 WebSphere MQ для Windows V6.0 Quick Beginnings, GC34-6476
 WebSphere MQ для Linux V6.0 Quick Beginnings, GC34-6480
 WebSphere MQ для AIX V6.0 Quick Beginnings, GC34-6478
 WebSphere MQ для Solaris V6.0 Quick Beginnings, GC34-6477
 WebSphere MQ для HP-UX V6.0 Quick Beginnings, GC34-6479
 WebSphere MQ для iSeries V6.0 Quick Beginnings, GC34-6481
Инструкции по установке на платформе z/OS, а также введение в специфику приме­
нения WebSphere MQ на этой платформе изложены в руководстве WebSphere MQ
для z/OS V6.0 Concepts and Planning Guide, GC34-6582.
5.1.1. Последние доступные обновления
По завершении инсталляции рекомендуем установить последние обновления
WebSphere MQ. Подробнее об этом см. в разделе 12.2.1 «Сайт поддержки WebSphere
MQ».
Примечание. Сведения, относящиеся к используемой вами платформе,
может содержать специальный информационный раздел файла readme,
поставляе­мого с последними обновлениями WebSphere MQ.
5.1.2. Спецификация окружения
Подробные сведения о поддерживаемых версиях операционных систем, компилято­
ров и иных компонентов программных средств, взаимодействующих с WebSphere
MQ, включая необходимые обновления, доступны в спецификации окружения
(SOE – statement of environment) соответствующей платформы, на которой работает
WebSphere MQ.
Спецификации окружения доступны на Web-странице по адресу:
http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html
74
Глава 5
5.2. Интерфейсы администрирования WebSphere MQ
Целям администрирования WebSphere MQ служит множество интерфейсов. Введени­
ем в практику их использования является данный раздел главы.
5.2.1. WebSphere MQ Explorer
Входящим в WebSphere MQ графическим интерфейсом (GUI) администрирования
менеджеров очередей и содержащихся в них объектов, а также конфигурирования
WebSphere MQ, установленного на той же машине, что и GUI, является WebSphere MQ
Explorer.
WebSphere MQ Explorer – одно из нововведений WebSphere MQ V6.0. В поставку пре­
дыдущих версий WebSphere MQ для Windows входит графический интерфейс на базе
Microsoft Management Console (MMC). В его составе – ряд модулей оснастки (snap-in)
MMC: WebSphere MQ Explorer и WebSphere MQ Services.
GUI-среда WebSphere MQ Explorer схожа с интерфейсом MMC-модулей оснастки
адми­нистрирования менеджеров очередей сообщений и настройки WebSphere MQ
предшествующих релизов. При этом функциональность WebSphere MQ Explorer
гораздо шире возможностей ранних версий. Благодаря же преимуществам построе­
ния WebSphere MQ Explorer на базе технологии Eclipse, о чем мы еще скажем в разделе
«WebSphere MQ Explorer и проект Eclipse», его функциональность продолжает разви­
ваться и дальше.
Запуск WebSphere MQ Explorer
На момент написания этих строк WebSphere MQ Explorer был пригоден для установ­
ки на следующих продуктах WebSphere MQ:
 WebSphere MQ для Windows
 WebSphere MQ для Linux® (x86)
По окончании установки WebSphere MQ со всеми необходимыми компонентами
WebSphere MQ Explorer можно запустить, воспользовавшись одним из нижеперечис­
ленных способов.
 Произведя запуск управляющей команды WebSphere MQ strmqcfg.
 Щелкнув по значку WebSphere MQ Explorer. Последний метод доступен только
при работе с WebSphere MQ для Windows. Значок WebSphere MQ Explorer нахо­
дится в программной группе IBM WebSphere MQ, доступной из меню Windows
Start.
Работа с WebSphere MQ и локальными менеджерами очередей
Рис. 5.1 содержит пример экрана WebSphere MQ Explorer с тремя описанными на той
же машине, что и Explorer, менеджерами очередей сообщений: example.payroll, exam­
ple.stock_control и example.online_shopping. Элементы управления интерфейсом, ко­
торые мы обсудим в этом разделе, на рисунке выделены особо.
В оригинале книга опубликована в ноябре 2005 г. – Примеч. пер.
Менеджеры очередей: общее представление и настройка
75
Рис. 5.1. Структура окна WebSphere MQ Explorer
Структура окна WebSphere MQ Explorer представлена двумя базовыми панелями.
 Панель навигации (навигатор). Содержит древовидное представление ресурсов
WebSphere MQ, которые допускают администрирование с использованием Web­
Sphere MQ Explorer. Ресурсы, показанные в этой панели, разделены на подчинен­
ные корневому узлу IBM WebSphere MQ папки. Чтобы развернуть элемент дерева
и увидеть все его содержимое, нажмите расположенный рядом знак «+», чтобы
свернуть ранее развернутый элемент – знак «–». Для вывода на экран страницы
содержимого элемента выделите его в дереве навигации.
 Панель содержимого. Выбор элемента в дереве навигации отображает в данной
панели табличное представление всех соответствующих ему объектов либо
инфор­мацию с описанием, помимо которого здесь же могут быть приведены
действия (actions).
Примечание. Для получения сводной справочной информации о текущих
сведениях в панели содержимого WebSphere MQ Explorer нажмите клавишу F1.
Для перехода в полнофункциональную справочную систему выберите Help →
Help Contents.
В целях администрирования менеджеров очередей сообщений, установленных на
данной машине и удаленно подключенных к WebSphere MQ Explorer, используется
папка Queue Managers. Каждому менеджеру, с которым существует соединение, в пап­
76
Глава 5
ке Queue Managers соответствует элемент списка, также содержащий ряд папок, выби­
раемых для доступа к объектам менеджера очередей и настройки последних.
Часть папок менеджера очередей сообщений содержит папка Advanced. Вы можете
отказаться от ее применения и выводить входящие в нее папки непосредственно
в структуре Queue Managers. Для этого щелкните по папке Advanced и следуйте указа­
ниям на панели содержимого инструмента.
Щелчок по подчиненной папке менеджера очередей сообщений открывает на пане­
ли содержимого таблицу объектов этого типа, описанных в контексте данного менед­
жера. Столбцы таблицы отображают атрибуты всех представленных в ней объектов,
для чего служит собственный вид значка для каждого из упомянутых типов. Если
атри­бут не соответствует конкретному элементу таблицы, ячейка помечается серым.
Системные объекты могут быть скрыты, однако показаны на рис. 5.2.
Рис. 5.2. WebSphereMQ Explorer. Показано содержимое очередей менеджера и ряд системных объектов
Представленный на рис. 5.2 выпадающий список Filter может использоваться для вы­
вода только объектов, соответствующих заданным в таблице критериям, скажем
только очередей, в которых находится более 10 сообщений. Для настройки помимо
стандартных фильтров для отбора объектов нестандартной фильтрации, а также для
добавления таких фильтров к перечню постоянно доступных служит вызываемое
из выпадающего списка окно Manage Filters.
Этот же список Filter (см. рис. 5.2) может применяться для изменения порядка следо­
вания показанных в таблице атрибутов столбцов или для добавления (удаления)
столбцов, отображающих конкретные атрибуты. Стандартная схема размещения
Менеджеры очередей: общее представление и настройка
77
столбцов дана в системе по умолчанию. Чтобы настроить собственную схему столб­
цов и поместить ее в список постоянно доступных, используйте вызываемое из спис­
ка Filter окно Manage Schemes.
Большинство функций WebSphere MQ Explorer активизируется щелчком правой
кнопкой мыши по элементу в дереве навигации или строке таблицы и выбором не­
обходимого действия из меню.
Так, чтобы отобразить свойства менеджера очередей сообщений, щелкните правой
кнопкой по менеджеру и выберите пункт Properties. Рис. 5.3 содержит пример окна
свойств установленного на локальной машине менеджера очередей.
Рис. 5.3. Окно свойств менеджера очередей сообщений
Это окно имеет то же расположение элементов, что и другие аналогичные окна
свойств в WebSphere MQ Explorer. Дерево в левой части может использоваться для
доступа к подкатегориям, в которые сведены все доступные свойства.
Папка Queue Manager Clusters может использоваться для доступа к информации, свя­
занной с кластерами менеджеров очередей. Каждый элемент папки соответствует
кластеру, полным репозиторием для которого является один из менеджеров очередей
из папки Queue Managers. Эту папку мы обсудим в разделе 8.2.2 «Просмотр сведений
из репозитория» в WebSphere MQ Explorer».
Замечания об обновленных менеджерах
Менеджеры очередей сообщений, созданные изначально в WebSphere MQ V5.3 или
более ранней версии WebSphere MQ и запущенные после установки WebSphere MQ
V6.0, носят название обновленных (migrated).
78
Глава 5
Процесс обновления (migration) обновляет данные менеджеров, включая все объекты
WebSphere MQ, а также журналы каждого менеджера, до состояния данных и журна­
лов WebSphere MQ V6.0. Существующая конфигурация менеджера очередей при
обнов­лении сохраняется.
До появления WebSphere MQ V6.0 менеджеры очередей сообщений автоматически
не запускали командный сервер, используемый WebSphere MQ Explorer в процессе
адми­нистрирования всех без исключения менеджеров, в том числе менеджеров, ло­
кальных по отношению к машине, где выполняется WebSphere MQ Explorer.
Также в целях администрирования WebSphere MQ Explorer требует, чтобы на менед­
жерах очередей сообщений были описаны конкретные системные объекты Web­
Sphere MQ, не создаваемые на протяжении обновления.
Для выполнения администрирования обновленных менеджеров очередей сообще­
ний произведите следующие шаги.
1. Остановите менеджер, если он выполняется.
2. Для построения введенных в WebSphere MQ V6.0 системных объектов очереди
выполните команду:
strmqm -c Queue_Manager_Name
3. Для изменения менеджера так, чтобы при запуске он автоматически загружал
командный сервер, выполните команду:
– Windows:
echo ALTER QMGR SCMDSERV(QMGR) | runmqsc Queue_Manager_Name
– UNIX:
echo «ALTER QMGR SCMDSERV(QMGR)» | runmqsc Queue_Manager_Name
4. Запустите менеджер очередей снова или во избежание перезапуска выполните
команду:
strmqcsv Queue_Manager_Name
Введение в администрирование удаленных менеджеров очередей
WebSphere MQ Explorer способен подключаться к удаленным менеджерам очередей
и администрировать их в папке Queue Managers.
При этом не требуется, чтобы удаленные менеджеры очередей работали на той же плат­
форме, что и WebSphere MQ Explorer, или имели одинаковую с ним версию WebSphere MQ.
Новой возможностью WebSphere MQ Explorer является удаленное администрирова­
ние менеджеров очередей WebSphere MQ для z/OS. Для этого удаленный менеджер
WebSphere MQ для z/OS должен работать под управлением WebSphere MQ V6.0.
Чтобы установить соединение с удаленными менеджерами очередей, WebSphere MQ
Explorer организует клиентское подключение, используя описанный в разделе «Син­
таксис MQSC» интерфейс в формате программируемых команд (PCF).
На практике удаленное администрирование, включая шаги, которые позволят сделать
доступным для него менеджер очередей, мы покажем в разделе 10.2 «Подключение
к менеджеру очередей в режиме клиента».
Менеджеры очередей: общее представление и настройка
79
Примечание. WebSphere MQ Explorer способен подключаться к удаленным
менеджерам очередей сообщений по клиентским соединениям, защищенным
по SSL-протоколу (Secure Sockets Layer). Для этого он пользуется функциями
SSL-подключений WebSphere MQ Java API. Подробности работы подобных
соединений выходят за рамки книги.
Настройки WebSphere MQ Explorer
Для конфигурирования настроек WebSphere MQ Explorer выберите пункт меню
Window → Preferences. На экране появится окно Preferences, содержащее несколько
разделов настроек среды Eclipse, в которой работает WebSphere MQ Explorer.
Чтобы изменить свойства WebSphere MQ, выберите из списка в левой части окна
категорию WebSphere MQ Explorer, как показано на рис. 5.4.
Рис. 5.4. Окно WebSphere MQ Explorer Preferences
WebSphere MQ Explorer и проект Eclipse
WebSphere MQ Explorer создан в виде набора подключаемых модулей (plug-ins) плат­
формы Eclipse, являющейся частью проекта с тем же названием. Платформа Eclipse
служит универсальной инструментальной платформой, реализующей базовые воз­
можности для создания интегрированных сред разработки (IDE), интерфейсов адми­
нистрирования и других приложений.
80
Глава 5
Каждое из перечисленных приложений может существовать в рамках общей среды
(workbench) Eclipse, которая обеспечивает их единое представление. Впрочем, вид
каждого приложения может меняться при помощи перспективы (perspective).
В целях удобства администрирования WebSphere MQ в состав WebSphere MQ Explorer
включена перспектива WebSphere MQ Explorer, меняющая представление среды при
запуске WebSphere MQ Explorer или ее ручном выборе.
Каждое приложение платформы Eclipse организовано как совокупность подключае­
мых модулей, построенных на базе функциональности модулей, имеющихся для
этой платформы. Сами образующие приложение модули могут предоставлять набор
функций для приложений, построенных как модули, подключаемые к данному при­
ложению. Любая область или элемент приложения, возможности которых может
расширять другое приложение – подключаемый модуль, называется точкой расширения приложения (extension point).
WebSphere MQ содержит ряд таких точек, допускающих гибкий рост функциональ­
ных возможностей WebSphere MQ Explorer благодаря новым подключаемым моду­
лям, которые войдут в WebSphere MQ или будут реализованы сторонними разработ­
чиками.
Примечание. По умолчанию WebSphere MQ Explorer запускается автономно,
что не дает возможности обращаться к среде Eclipse в целом. Для получения
полного доступа к таковой выберите Window → Preferences. Затем отметьте
опцию in an Eclipse Workbench. Для вступления настройки в силу WebSphere MQ
Explorer нужно запустить заново.
5.2.2. Модуль WebSphere MQ Explorer Healthcheck
Примером такого модуля, обогащающего WebSphere MQ Explorer дополнительными
возможностями обнаружения неисправностей и созданного на базе точек расшире­
ния приложения, является WebSphere MQ Explorer Healthcheck.
Модуль WebSphere MQ Explorer Healthcheck входит в состав пакета SupportPac MH01.
Подробнее о нем читайте на Web-странице по адресу:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24010096
5.2.3. Управляющие команды WebSphere MQ
WebSphere MQ для платформ UNIX и Windows содержит набор команд для выполне­
ния операций над совокупностью менеджеров очередей сообщений и непосредствен­
но WebSphere MQ. Команды выполняются в интерфейсе командной строки конкрет­
ной операционной системы. Если нет указания на иное, путь к этим командам вклю­
чается в путь поиска команд операционной системы при установке WebSphere MQ.
5.2.4. Команды языка управления WebSphere MQ для iSeries
Команды языка управления (CL – control language) IBM OS/400® в составе WebSphere
MQ для iSeries служат для выполнения операций над совокупностью менеджеров оче­
Менеджеры очередей: общее представление и настройка
81
редей и непосредственно WebSphere MQ. Для обращения к главному интерфейсу ко­
манд языка управления в составе WebSphere MQ используйте CL-команду WRKMQM.
5.2.5. Команды WebSphere MQ для z/OS
WebSphere MQ для z/OS содержит набор команд, которые могут выполняться над
подсистемой менеджера очередей из консоли z/OS или ее аналога, к примеру System
Display and Search Facility (SDSF).
О подсистеме менеджера очередей в WebSphere MQ для z/OS речь пойдет в разделе
5.3.4 «Структура и создание менеджера очередей».
5.2.6. Команды WebSphere MQ Script (MQSC)
Конфигурирование системы при помощи WebSphere MQ Explorer может иметь отри­
цательные последствия для рабочего окружения. Учет вносимых в менеджер измене­
ний отсутствует, и согласованная запись модификаций, производимых через графи­
ческий интерфейс, может оказаться непростым делом.
Использование для выполнения команд настройки менеджеров очередей сценарного
интерфейса позволяет осуществлять действия по управлению изменениями, наце­
ленные на регистрацию и учет выполненных команд. Документируя команды сцена­
рия для создания и настройки менеджера очередей и внеся в них минимальные изме­
нения, можно сформировать дубликат менеджера, к примеру для масштабирования
системы с переносом на другую машину.
Сценарии могут служить для выполнения распространенных команд администриро­
вания системы, а результат работы таких сценариев – передаваться на обработку для
выявления успешности завершения и выдачи соответствующей диагностической ин­
формации.
С целью предоставления таких возможностей в WebSphere MQ встроен сценарный
интерфейс WebSphere MQ Script (MQSC) к менеджеру очередей сообщений. В сочета­
нии с описанными в разделе 5.2.3 управляющими командами WebSphere MQ все
действия над менеджером очередей сообщений могут оформляться в виде сценариев
на таких внешних по отношению к системе языках записи командных сценариев, как
Perl и оболочка Korn UNIX-системы.
Выполнение команд MQSC
Команды MQSC выполняются над менеджером очередей так, как описано ниже.
 WebSphere MQ для Windows, WebSphere MQ для UNIX.
Интерфейсом для выполнения над менеджером очередей MQSC-команд служит
входящая в WebSphere MQ управляющая программа runmqsc. Программа прини­
мает команды на стандартный ввод командного интерфейса, из которого и про­
исходит их выполнение. Для запуска интерактивной MQSC-сессии управления
менеджером очередей сообщений используйте формат вызова:
runmqsc название_менеджера
Стандартным вводом текстовых диалоговых интерфейсов служит клавиатура. – Примеч. пер.
82
Глава 5
Если набор команд MQSC сохранен в файл, то содержимое файла можно передать
команде runmqsc через стандартный ввод:
runmqsc название_менеджера < имя_файла
Команда runmqsc может использоваться для выполнения MQSC-команд управле­
ния удаленным менеджером очередей сообщений. Об этом читайте в главе 6 «Ad­
ministering remote WebSphere MQ objects» руководства WebSphere MQ System Administration Guide, SC34-6584.
 WebSphere MQ для iSeries.
Команды MQSC могут выполняться в интерактивном режиме, для чего служит
CL-команда RUNMSQC.
Также они могут быть записаны как сценарий, который представляет собой фи­
зический файл-источник. Для его выполнения предназначена CL-команда
STRMQMMQSC.
Примечание. Дополнительно WebSphere MQ для iSeries содержит CL-команды, которые могут служить для выполнения MQSC-команд через
панельный диалоговый интерфейс. Для доступа к этим CL-командам WebSphere
MQ воспользуйтесь CL-командой WRKMQM.
 WebSphere MQ для z/OS.
Здесь команды MQSC служат для управления подсистемой конкретного менедже­
ра очередей сообщений.
Примечание. WebSphere MQ для z/OS содержит панели управления и операции, которые могут использоваться для интерактивного выполнения
функций MQSC-команд. Для доступа к ним служат Time Sharing Option (TSO) и Interactive System Productivity Facility (ISPF).
Синтаксис MQSC
Синтаксис MQSC очень прост. Общий формат команды имеет вид:
COMMAND OBJTYPE('Название_Объекта) ATTR1(ЗНАЧЕНИЕ) ATTR2('значение') ATTR3
где OBJTYPE – тип объекта, COMMAND – один из ряда допустимых для данного типа объек­
тов командных ключевых слов, ATTR1, ATTR2, ATTR3 – названия допустимых для него
атрибутов.
Отдельные комбинации командных ключевых слов и типов объектов, такие как
ALTER QMGR, не требуют указания имен объектов. Отдельные атрибуты не требуют
приведения их значений. Немало команд и типов имеют сокращенные варианты;
к примеру, ALT может заменить ALTER.
Для некоторых командных ключевых слов требуется задание как типа, так и подтипа,
например:
DEFINE CHANNEL('my.channel') CHLTYPE(RCVR)
Менеджеры очередей: общее представление и настройка
83
Каждая комбинация ключевого слова и типа принимает свой набор атрибутов. Ряд
атрибутов является обязательным. Для указания пустого значения атрибута исполь­
зуйте пробел в круглых скобках: ATTR( ). Ряд атрибутов допускает множественность
значений. В этом случае они разделяются запятыми. Например, так:
ALTER NAMELIST('my.namelist') NAMES(NAME1,'name2')
Если в команде приведена допустимая комбинация ключевого слова и типа, но атри­
буты команды не соответствуют указанной комбинации или пропущены, но должны
быть, команда не выполняется, а на экран выводится краткая информация о правилах
записи выбранной комбинации.
Примечание. Названия объектов и значения атрибутов, не заключенные в знаки одинарных кавычек, автоматически преобразуются в верхний регистр.
Поэтому если вам требуется ввести в команду названия объектов или значения
атрибутов в нижнем регистре символов, то вы должны использовать знаки
одинарных кавычек.
Значения атрибутов, содержащие специальные символы, например скобки,
должны записываться в одинарных кавычках.
MQSC не различает регистр ключевых слов, таких как COMMAND, OBJTYPE,
ATTR1, ATTR2, ATTR3, в вышеуказанном примере общего формата команды.
В число наиболее употребительных командных ключевых слов входят следующие:
 DEFINE или DEF
Создать новый объект с конкретным типом, названием и значениями перечис­
ленных атрибутов. Для принудительной замены существующего объекта с таким
же типом и именем DEFINE может сопровождаться атрибутом REPLACE. Для указа­
ния названия другого объекта с таким же типом, значениями атрибутов которого
нужно заполнить все атрибуты объекта, не указанные в команде, служит атрибут
LIKE.
 ALTER или ALT
Модифицировать имеющийся объект с конкретным типом и конкретным назва­
нием, придав его атрибутам указанные значения.
 DELETE
Удалить имеющийся объект с конкретным типом и конкретным названием.
 DISPLAY или DIS
Отобразить названные атрибуты имеющихся объектов с конкретным типом и конк­
ретным названием. Для вывода на экран всех атрибутов каждого из объектов можно
воспользоваться специальным именем ALL. Если не задан ни один атрибут, для каж­
дого из объектов выводится набор атрибутов по умолчанию.
В конце названий и значений типов объектов можно указать «звездочку» (*). Это вынуж­
дает команду отобразить атрибуты всех тех объектов, названия или типы которых
начи­наются со значения, указанного до символа маски. Например, следующая коман­
да отображает все атрибуты очередей, названия которых начинаются на example:
DISPLAY QUEUE('example*') ALL
84
Глава 5
В WebSphere MQ V6.0 возможна дополнительная фильтрация информации, выдавае­
мой командой DISPLAY, для чего пользуются ключевым словом WHERE. В круглых
скобках после него следуют три значения: название атрибута, оператор и значение
фильтра. Для каждого из объектов заданный атрибут сверяется со значением фильтра
при помощи оператора, и атрибуты упомянутого объекта выводятся лишь тогда, ког­
да такое сравнение было успешно завершено. Например, следующей командой будут
показаны глубина (CURDEPTH) и описание (DESCR) очередей, содержащих более
10 сообщений:
DISPLAY QUEUE(*) DESCR CURDEPTH WHERE(CURDEPTH,GT,10)
 START
Произвести запуск существующего объекта с конкретным типом и конкретным
названием, к примеру, слушателя или канала.
 STOP
Остановить имеющийся объект с конкретным типом и конкретным названием,
например слушатель или канал сообщений.
Команда MQSC может занимать несколько строк, для переноса между которыми пос­
ле пробела в конце строки пишут знак «плюс» (+). Например, так:
DEFINE CHANNEL(TO.PAYROLL) +
CHLTYPE(SDR) +
CONNAME(‘another.machine.com(1414)’) +
XMITQ(PAYROLL)
Также в сценарий MQSC могут включаться строки, содержащие комментарий. Первым
знаком такой строки служит знак «звездочка» (*).
Полное описание синтаксиса команд MQSC и деталей работы каждой такой команды
вкупе с описанием атрибутов, пригодных для использования в командах, см. в руко­
водстве WebSphere MQ Script (MQSC) Command Reference, SC34-6597, доступном
на Web-странице по адресу:
http://www.ibm.com/software/integration/wmq/library/
5.2.7. Форматы программируемых команд (PCF)
Форматы программируемых команд (PCF) служат интерфейсом программирования
для менеджеров очередей сообщений. Для каждой команды MQSC имеется соответ­
ствующая команда в формате программируемых команд, которая может использо­
ваться для управления данным менеджером. Соответствующие параметры PCF име­
ются для каждого MQSC-атрибута.
Команды в формате программируемых команд обслуживает командный сервер (command server) менеджера очередей сообщений. Он выполняет заданное каждой из
PCF-команд действие и формирует сообщение-ответ с результатом ее работы.
Реализация интерфейса к командному серверу отвечает стандартной модели по прин­
ципу «запрос – ответ», что означает, что сервер обрабатывает запросы из очереди
и отсылает ответы, помещая их в очереди ответа, указанные приложениями-инициа­
Менеджеры очередей: общее представление и настройка
85
торами запросов. Очередь, из которой командный сервер извлекает запросы на обра­
ботку, называется SYSTEM.ADMIN.COMMAND.QUEUE.
Подробности формирования и отправки отдельных сообщений с командами PCF
и о­б­работки ответов на подобные сообщения выходят за рамки книги. Читайте
об этом в руководстве WebSphere MQ Programmable Command Formats and Administration
Interface, SC34-6598 на Web-странице по адресу:
http://www.ibm.com/software/integration/wmq/library/
Упростить применение PCF-интерфейса к менеджерам очередей из приложений
на языке Java может пакет SupportPac MS0B. Подробнее читайте о нем по адресу:
http://www.ibm.com/support/docview.wss?rs=171&uid=swg24000668&loc=en_US&cs=utf8&lang=en
Созданный в WebSphere MQ V6.0 на платформе Windows, UNIX или iSeries менеджер
очередей сообщений при своем старте автоматически запускает командный сервер.
Такое поведение менеджера может быть заблокировано сменой значения атрибута
SCMDSERV на MANUAL в объекте менеджера очередей в MQSC или установкой равным
Manual свойства Command server control в окне Properties менеджера очередей в Web­
Sphere MQ Explorer.
Менеджеры очередей сообщений, созданные на этих платформах до появления Web­
Sphere MQ V6.0, включая обновленные до нее, не запускают командный сервер авто­
матически. Для них запуск командного сервера осуществляется так.
 WebSphere MQ для Windows, WebSphere MQ для UNIX:
strmqcsv название_менеджера
 WebSphere MQ для iSeries:
STRMQMCSVR MQMNAME(‘название_менеджера’)
 В WebSphere MQ для z/OS обработка PCF-команд сервером возможна только
в версии WebSphere MQ для z/OS V6.0.
Для запуска командного сервера в WebSphere MQ для z/OS используется команда:
START CMDSERV MQSC
5.3. Менеджер очередей сообщений
Менеджеры очередей сообщений являются основным элементом инфраструктуры
WebSphere MQ. Каждое приложение, получающее доступ к инфраструктуре, для обра­
щения к ней должно быть подключено к менеджеру. Приложения могут получать
сооб­щения из очередей под управлением только тех менеджеров, к которым они
подключены.
Примечание. Благодаря группам с разделением очередей WebSphere MQ для z/OS допускает, чтобы одной общей очередью управлял целый ряд менеджеров. Подробнее об этом см. в разделе 5.3.3 «Группы с разделением очередей в WebSphere MQ для z/OS».
86
Глава 5
Менеджер очередей сообщений служит для приложения точкой входа в инфраструк­
туру. Подключившись к своему менеджеру, оно может отправлять с помощью него
сообщения очередям под управлением других менеджеров очередей сообщений в
инфра­структуре очередей.
Для обеспечения движения сообщений от одного менеджера к другому каждый менед­
жер в инфраструктуре должен иметь сетевое соединение с теми из менеджеров, кото­
рым он может маршрутизировать сообщения. По мере своего продвижения от при­
ложения-отправителя в итоговую очередь назначения сообщение может проходить
целый ряд менеджеров.
На машине, где установлен сервер WebSphere MQ, может располагаться несколько
менеджеров очередей сообщений. Количество менеджеров, размещенных на кон­к­
ретной машине одновременно, ограничено только ее ресурсами.
5.3.1. Наименование менеджеров очередей
Все менеджеры имеют свое название. Оно должно быть уникальным в инфраструкту­
ре, что позволяет каждой очереди в ее пределах быть уникальным местом назначения
сообщений. Название менеджера используется при установлении соединения и ука­
зании местоположения очереди в составе инфраструктуры.
Контроль за уникальностью названий менеджеров очередей сообщений WebSphere
MQ осуществляет только в отношении менеджеров, работающих на одной и той же
машине.
Немаловажен и выбор подходящего названия менеджера, которое может отражать
характер его использования, название и местоположение машины.
При назначении имен менеджерам очередей сообщений советуем не забывать
о росте инфраструктуры, в том числе появлении дополнительных менеджеров на тех
же самых машинах, или слиянии нескольких инфраструктур WebSphere MQ в буду­
щем.
После того как менеджер очередей создан, переименовать его невозможно. Для сме­
ны имени менеджера он должен быть удален и создан повторно. Это касается и всех
его элементов конфигурации.
В WebSphere MQ для z/OS название менеджера может быть не длиннее четырех сим­
волов и содержать только буквы алфавита в верхнем регистре, цифры и символы
из набора $ # @.
На остальных платформах название менеджера очередей сообщений может дости­
гать в длину 48 символов и содержать строчные и прописные буквы латинского
алфавита, цифры и следующий набор символов: . / _ %. Название менеджера чувствительно к буквенному регистру, а значит, QMGR1 обозначает другой менеджер, нежели
Qmgr1.
WebSphere MQ полностью поддерживает как названия из букв смешанного регистра,
так и названия, отличные только регистром букв. Однако, во избежание проблем
в применении приложений, подключаемых к менеджерам очередей сообщений или
пересылающих сообщения очередям, относитесь к использованию регистра симво­
лов с осторожностью.
Менеджеры очередей: общее представление и настройка
87
5.3.2. Объекты WebSphere MQ
В пределах менеджера очередей сообщений осуществляются задание и настройка
объектов (objects) WebSphere MQ. Объекты являются теми индивидуальными элемен­
тами, которые совместно образуют сам менеджер и связанную с последним конфигу­
рацию. Каждый объект имеет свой тип, название и несколько атрибутов (attributes),
которые дают возможность его настроить.
Значительная часть этой главы будет посвящена типам объектов, которые могут вхо­
дить в состав менеджера очередей сообщений, их описанию и настройке, а также
функциональности объектов каждого типа. Примерами объектов, которые мы под­
робнее рассмотрим в этой главе, являются:
 сам менеджер очередей сообщений;
 очереди под управлением менеджера.
Определенный набор объектов определяется при создании менеджера автоматиче­
ски. Объекты, имя которых начинается с SYSTEM, что позволяет отличить их от объ­
ектов, которые созданы администратором WebSphere MQ, обычно носят название
системных (system objects).
Имеется немало разнообразных системных объектов, которые мы по отдельности
обсудим в соответствующих разделах этой главы. Заметим, что ни один системный
объект не подлежит удалению администратором. По характеру применения эти объ­
екты можно разделить следующим образом:
 Объекты для внутреннего использования.
Ряд системных объектов требуется для выполнения определенных функций Web­
Sphere MQ. Эти объекты не должны изменяться администратором.
 Объекты для обеспечения стандартной функциональности.
Несколько системных объектов выступают в роли объектов по умолчанию для
выполнения конкретных функций. Обычно для подмены функциональности этих
объектов администраторам рекомендуется создавать собственные объекты, отве­
чающие их собственным соглашениям об именах.
 Системные объекты по умолчанию.
Для каждого из типов объектов существует системный объект с именем вида
SYSTEM.DEFAULT.OBJECT.TYPE
Каждый вновь созданный объект этого типа по умолчанию наследует атрибуты
однотипного с ним системного объекта по умолчанию. Изменение свойств сис­
темного объекта по умолчанию приводит к изменению атрибутов новых объектов
того же типа, однако не изменяет атрибуты объектов, которые уже существуют.
Кроме того, объект может быть создан на базе атрибутов любого другого объекта
того же типа, определенного ранее. В этом случае говорят, что новый объект
похож (like) на имеющийся в системе.
5.3.3. Группы с разделением очередей в WebSphere MQ для z/OS
WebSphere MQ для z/OS работает на аппаратной платформе мейнфреймов IBM
Eserver zSeries® под управлением операционной системы z/OS. В этой книге экземп­
88
Глава 5
ляр z/OS, способный функционировать в логическом разделе (LPAR), мы чаще всего
будем называть образом (z/OS image).
WebSphere MQ для z/OS базируется на функциях платформы z/OS и имеет дополни­
тельные, недоступные на прочих платформах возможности, наиболее значимой из
которых являются группы с разделением очередей (QSG).
Множество являющихся членами QSG менеджеров очередей сообщений имеют дос­
туп к содержащимся в QSG общим очередям (shared queues). Любая общая очередь
QSG доступна всем образующим группу менеджерам, подобно тому как если бы она
управлялась менеджером локально.
Сказанное означает, что одно приложение, подключенное к менеджеру очередей
сооб­щений, может поместить сообщение в общую очередь, а другое приложение,
связанное с другим менеджером очередей сообщений в той же QSG-группе, может
оттуда его извлечь.
При отказе от применения общих очередей сообщений его пришлось бы передавать
в очередь под управлением второго менеджера, пересылая по распределенному или
кластерному каналу до того, как второе приложение смогло его получить.
Другое значимое преимущество QSG заключается в том, что при возникновении сбоя
в одном из менеджеров в составе подобной группы другие менеджеры этой же QSG
смогут продолжить обрабатывать данные из общих для данной группы очередей.
В основу QSG-групп заложены функции, реализуемые объединением нескольких об­
разов z/OS в сисплекс (sysplex). Все менеджеры очередей сообщений – члены QSGгруппы должны располагаться в пределах образов z/OS одного сисплекса.
Сисплекс включает в себя устройство сопряжения (CF – coupling facility), которое
дает возможность ряду образов z/OS в сисплексе иметь совместные данные. Web­
Sphere MQ для z/OS использует устройство сопряжения совместно с функциональ­
ностью системы баз данных IBM DB2®.
В силу этого обстоятельства каждый входящий в QSG менеджер очередей сообщений
должен иметь доступ и к DB2. Экземпляры БД DB2, к которым обращаются менедже­
ры очередей в QSG, должны располагаться в одной и той же группе с разделением
данных (data-sharing group). Группа с разделением данных – это одна из возможнос­
тей DB2, дающая возможность множеству экземпляров баз данных совместно поль­
зоваться хранилищем информации.
WebSphere MQ для z/OS использует устройство сопряжения и DB2 для обеспечения
коллективного доступа к описанию очереди и сообщениям в ней всех менеджеров
очередей сообщений, являющихся членами QSG. После описания очереди для одного
менеджера в QSG-группе доступ к этой разделяемой очереди получает каждый менед­
жер QSG.
Каждая QSG-группа имеет свое название. Правила именования QSG совершенно ана­
логичны описанным выше правилам для имен менеджеров очередей в WebSphere MQ
для z/OS.
Менеджеры очередей: общее представление и настройка
89
Примечание. WebSphere MQ для z/OS Version 6.0 имеет ряд функциональных
усовершенствований, связанных с разделяемыми очередями и QSG. Вкратце
сущность их такова.
 Предельная длина сообщения, которое может вместить разделяемая очередь
сообщений, увеличена с 63 Кб до 100 Мб. При размещении в разделяемой очереди сообщения с длиной более 63 Кб в CF помещается «заполнитель» (4 Кб),
а данные хранятся средствами DB2.
 При пользовании QSG-группой и сбое административной структуры активные
в QSG менеджеры очередей сообщений больше не завершают работу. Вместо
аварийного завершения их работа будет приостановлена, структура автоматически помещена на новое место и построена заново, после чего работа возобновится.
5.3.4. Структура и создание менеджера очередей
Детали функционирования, а также настройки менеджера очередей сообщений зави­
сят от конкретной платформы, где выполняется WebSphere MQ.
Подробное изложение нюансов работы менеджера выходит за рамки книги. Однако
в этом разделе мы приведем обзор ряда платформ WebSphere MQ Version 6.0. При
обсуж­дении каждой платформы мы подчеркнем самое основное.
WebSphere MQ для Windows
В WebSphere MQ для Windows менеджер очередей сообщений работает как совокуп­
ность процессов в операционной системе.
В этой книге предполагается, что инсталляция WebSphere MQ для Windows V6.0 про­
ведена в каталоге установки по умолчанию. Если при развертывании системы вы вы­
брали другой каталог, то замените им встречающийся во всех примерах каталог
C:\Program Files\IBM\WebSphere MQ.
Каждый менеджер очередей владеет и поддерживает определенный набор файлов
в файловой системе машины.
 Каталог данных менеджера очередей сообщений.
Каталог данных менеджера очередей сообщений содержит определения объектов,
данные сообщений, а также прочие данные менеджера. По умолчанию путь к это­
му каталогу имеет вид:
C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера
 Файлы журнала менеджера.
Файлы, содержащие журнал менеджера очередей сообщений. Журнализацию мы
обсудим в разделе 5.3.13 «Журнализация». По умолчанию путь к этим файлам име­
ет вид:
C:\Program Files\IBM\WebSphere MQ\log\название_менеджера
Входящее в указанные пути название_менеджера может частично не совпадать с ре­
альным названием менеджера очередей сообщений. Подробнее о построении входя­
90
Глава 5
щего в состав пути имени каталога из названия менеджера читайте в руководстве
WebSphere MQ System Administration Guide, SC34-6584. Основное различие между ними
состоит в том, что неалфавитные символы в названии менеджера заменяются в име­
ни каталога: символ «.» меняется на «!», символ «/» на «&».
Базовая информация о настройках менеджера очередей сообщений хранится в реест­
ре Windows. Она включает информацию о подходе к журнализации менеджера и на­
стройках протокола коммуникации. Вносимые в эту информацию изменения
не видны менеджерам, работающим в текущий момент, пока они не остановлены
и не запущены снова.
Настройки менеджера в реестре Windows можно изменять с помощью WebSphere
MQ Explorer. Для доступа к конфигурации менеджера щелкните правой кнопкой
мыши по его значку в навигаторе и выберите пункт меню Properties.
Содержащуюся в реестре Windows информацию о настройке менеджера очередей
сообщений также можно модифицировать командой WebSphere MQ amqmdain reg.
Примечание. Прямое изменение информации в реестре системы Windows
требует исключительной подготовки. Поэтому в процессе конфигурирования
WebSphere MQ мы настоятельно рекомендуем не прибегать к этому способу
редактирования.
Всю информацию о параметрах конфигурации WebSphere MQ, хранимых в реестре
Windows, можно найти в части 4 «Configuring WebSphere MQ» руководства WebSphere
MQ System Administration Guide, SC34-6584.
Менеджер очередей сообщений в WebSphere MQ для Windows может быть создан
следующими путями.
 При помощи WebSphere MQ Explorer.
Настроить менеджеры WebSphere MQ можно, воспользовавшись входящим в Web­
Sphere MQ Explorer мастером Create Queue Manager. Для обращения к мастеру
щелкните правой кнопкой мыши по папке Queue Managers и выберите пункт
меню New → Queue Manager.
 При помощи управляющей команды WebSphere MQ crtmqm.
Команда WebSphere MQ crtmqm описана в части 6 «WebSphere MQ control
commands» руководства WebSphere MQ System Administration Guide, SC34-6584.
Примечание. Для создания менеджера пользователь, который решает эту
задачу, должен являться членом группы с именем mqm. При установке WebSphere
MQ эта группа создается автоматически.
При создании менеджера вы можете задавать параметры, определяющие начальные
значения важных атрибутов конфигурации в реестре системы Windows. Часть на­
строек конфигурации, касающихся процессов журнализации, после создания менед­
жера не подлежит изменению. Подробнее об этом см. раздел 5.3.13 «Журнализация».
Менеджеры очередей: общее представление и настройка
91
Параметры, заданные при создании менеджера, имеют значения по умолчанию. Пос­
ледние вместе с другой не относящейся к конкретному менеджеру информацией
о настройках WebSphere MQ хранятся в реестре Windows.
Настройки WebSphere MQ можно менять при помощи WebSphere MQ Explorer. Для
доступа к конфигурации WebSphere MQ щелкните правой кнопкой мыши по значку
WebSphere MQ в навигаторе и выберите пункт меню Properties.
Также конфигурацию WebSphere MQ можно менять, используя управляющую команду
WebSphere MQ amqmdain reg.
WebSphere MQ для UNIX
В WebSphere MQ для платформ UNIX менеджер очередей сообщений работает как
совокупность процессов в операционной системе.
Каждый менеджер очередей владеет и поддерживает определенный набор файлов
в файловой системе машины.
 Каталог данных менеджера очередей сообщений.
Каталог данных менеджера очередей сообщений содержит определения объектов,
данные сообщений, а также прочие данные менеджера. По умолчанию путь к это­
му каталогу имеет вид:
/var/mqm/qmgrs/название_менеджера
 Файлы журнала менеджера:
Файлы, содержащие журнал менеджера очередей сообщений. Журнализацию мы
обсудим в разделе 5.3.13 «Журнализация». По умолчанию путь к этим файлам име­
ет вид:
/var/mqm/log/название_менеджера
Примечание. По соображениям производительности файловые системы /var/
mqm/qmgrs и /var/mqm/log рекомендуется монтировать на разные физические
файловые системы.
Входящее в указанные пути название_менеджера может частично не совпадать
с реальным названием менеджера очередей сообщений. Подробнее о построении
входящего в состав пути имени каталога из названия менеджера читайте в разделе
«Understanding WebSphere MQ file names» руководства WebSphere MQ System Administration Guide, SC34-6584. Основное различие между ними состоит в том, что
неалфавитные символы в названии менеджера заменяются в имени каталога: сим­
вол «.» меняется на «!», символ «/» на «&».
Базовая информация о настройках менеджера очередей сообщений хранится
в файле, расположение в файловой системе которого приведено для каталога
с данными менеджера очередей по умолчанию: /var/mqm/qmgrs/название_
менеджера/qm.ini.
В нем содержится информация об организации журнализации менеджера и на­
стройках протоколов коммуникации. Вносимые в эту информацию изменения не
92
Глава 5
видны менеджерам, работающим в текущий момент, пока они не остановлены
и не запущены снова.
На всех UNIX-платформах этот файл может напрямую быть изменен при помощи
текстового редактора, например vi или emacs.
На тех UNIX-платформах, которые поддерживают такую возможность, настройки
конфигурации в этом файле могут модифицироваться при помощи WebSphere
MQ Explorer. Для доступа к конфигурации менеджера щелкните правой кнопкой
мыши по его значку в навигаторе и выберите пункт меню Properties.
Менеджер очередей сообщений в WebSphere MQ для UNIX создается управляющей
командой WebSphere MQ crtmqm, которая описана в части 6 «WebSphere MQ control
commands» руководства WebSphere MQ System Administration Guide, SC34-6584.
На тех UNIX-платформах, которые поддерживают такую возможность, менеджер
очередей сообщений можно создать, воспользовавшись входящим в WebSphere
MQ Explorer мастером Create Queue Manager. Для обращения к мастеру щелкните
правой кнопкой мыши по папке Queue Managers в навигаторе и выберите пункт
меню New → Queue Manager.
Примечание. Для создания менеджера пользователь, который решает эту
задачу, должен являться членом группы с именем mqm. При установке WebSphere
MQ эта группа создается автоматически.
При создании менеджера вы можете задавать параметры, определяющие начальные
значения важных атрибутов конфигурации в файле qm.ini. Часть настроек конфи­
гурации, касающихся процессов журнализации, после создания менеджера не под­
лежит изменению. Подробнее об этом см. раздел 5.3.13 «Журнализация» .
Параметры, заданные при создании менеджера, имеют значения по умолчанию.
Последние вместе с другой не относящейся к конкретному менеджеру информа­
цией о настройках WebSphere MQ хранятся в файле /var/mqm/mqs.ini.
На всех UNIX-платформах этот файл может напрямую быть изменен при помощи
текстового редактора, например, vi или emacs.
На тех UNIX-платформах, которые поддерживают такую возможность, настройки
конфигурации WebSphere MQ могут модифицироваться при помощи WebSphere
MQ Explorer. Для доступа к конфигурации менеджера щелкните правой кнопкой
мыши по его значку в навигаторе и выберите пункт меню Properties.
Примечание. Редактируя файл mqs.ini, будьте особенно осторожны, если
одновременно с этим на машине работают менеджеры очередей сообщений или
подключенные к ним приложения.
В этих условиях файл нельзя изменять путем создания дубликата с дальнейшим
переименованием копии для замены существующего mqs.ini. Если именно эти
шаги вам нужно произвести, то перезапись mqs.ini должна быть предварена
обязательным остановом всех менеджеров очередей сообщений и подключенных
к ним приложений, которые работают на машине.
Менеджеры очередей: общее представление и настройка
93
WebSphere MQ для iSeries
В WebSphere MQ для iSeries менеджер очередей сообщений работает как совокуп­
ность пакетных заданий (batch jobs). По умолчанию они выполняются в подсистеме
QMQM, созданной при установке WebSphere MQ для iSeries. Подробнее о запуске
пакет­ных заданий WebSphere MQ читайте в руководстве WebSphere MQ для iSeries V6.0
System Administration Guide, SC34-6586.
Примечание. В дальнейшем в книге не будет упоминаний пакетных заданий
iSeries. Обычно для обозначения таковых будет использоваться термин процесс
(process).
Прежде чем попытаться выполнить ту или иную CL-команду WebSphere MQ, убеди­
тесь в том, что подсистема QMQM работает. Для ее запуска воспользуйтесь следующей
командой:
STRSBS QMQM/QMQM
Каждый менеджер очередей владеет и поддерживает работу ряда используемых в его
работе ресурсов.
 Библиотека менеджера очередей сообщений.
Каждый менеджер имеет библиотеку. Она содержит разделы (journals), образую­
щие журнал (log). Название библиотеки определяется названием менеджера.
 Каталог данных менеджера очередей сообщений.
Каталог данных менеджера очередей сообщений в интегрированной файловой
системе (IFS) содержит определения объектов, данные сообщений, а также прочие
данные менеджера. По умолчанию путь к этому каталогу имеет вид:
/QIBM/UserData/mqm/qmgrs/название_менеджера
Название библиотеки, а также входящее в IFS-путь название_менеджера может час­
тично не совпадать с реальным названием менеджера очередей сообщений. Подроб­
нее о построении названия библиотеки и IFS-имени каталога из названия менеджера
читайте в руководстве WebSphere MQ для iSeries V6.0 System Administration Guide,
SC34-6586.
Базовая информация о настройках менеджера очередей сообщений хранится в фай­
ле, расположение в файловой системе которого приведено для каталога с данными
менеджера очередей сообщений по умолчанию: /QIBM/UserData/mqm/название_
менеджера/qm.ini.
В нем содержится информация об организации журнализации менеджера и настрой­
ках протоколов коммуникации. Вносимые в эту информацию изменения не видны
менеджерам, работающим в текущий момент, пока они не остановлены и не запуще­
ны снова.
Файл qm.ini может быть напрямую модифицирован в CL-редакторе EDTF.
Менеджер очередей сообщений в WebSphere MQ для iSeries создается CL-командой
WebSphere MQ для iSeries CRTMQM. Подробнее об этом читайте в руководстве WebSphere MQ для iSeries V6.0 System Administration Guide, SC34-6586.
94
Глава 5
Примечание. Для создания менеджера пользователь, который решает эту
задачу, должен являться членом группы QMQMADM. При установке WebSphere
MQ эта группа создается автоматически.
Параметрами этой команды определяются начальные значения хранящихся в файле
qm.ini важных атрибутов конфигурации. Часть настроек, касающихся процессов
журнализации, после создания менеджера не подлежит изменению. Подробнее об
этом см. раздел 5.3.13 «Журнализация».
Не относящаяся к конкретному менеджеру информация о настройках WebSphere MQ
хранится в IFS в файле /QIBM/UserData/mqm/mqs.ini.
Файл может быть напрямую модифицирован в CL-редакторе EDTF.
WebSphere MQ для z/OS
Информацию о работе менеджеров очередей сообщений в WebSphere MQ для z/OS
читайте в руководстве WebSphere MQ для z/OS V6.0 Concepts and Planning Guide,
GC34-6582.
5.3.5. Менеджер очередей по умолчанию
Один из менеджеров, работающих на данной машине, можно сконфигурировать как
менеджер очередей сообщений по умолчанию.
При подключении к инфраструктуре без указания названия менеджера приложение,
которое работает на той же машине, что и один из менеджеров, будет подключено
к менеджеру, который настроен по умолчанию.
Если менеджер очередей не задан в тексте команды, то ряд команд WebSphere MQ
также выбирают менеджер очередей сообщений по умолчанию.
WebSphere MQ для Windows, iSeries, UNIX
В WebSphere MQ для платформ Windows, iSeries, UNIX менеджер очередей сообщений
по умолчанию определяется опцией в процессе его создания.
Задание этой опции приводит к тому, что имя данного менеджера заносится в пара­
метр Default queue manager в настройках WebSphere MQ. Позднее его значение можно
модифицировать заменой упомянутого параметра. Редактирование настроек Web­
Sphere MQ на базе Windows, UNIX, а также iSeries мы обсудим в разделе 5.3.4 «Структу­
ра и создание менеджера очередей».
WebSphere MQ для z/OS
Порядок определения менеджера очередей сообщений по умолчанию зависит от ок­
ружения, откуда подключается приложение. Подробнее об этом читайте в разделе
«Writing a WebSphere MQ application» руководства WebSphere MQ Application Programming Guide, SC34-6595.
Менеджеры очередей: общее представление и настройка
95
5.3.6. Объект-менеджер очередей
Информацию о настройке менеджера очередей сообщений, которую можно менять
во время его работы, содержит соответствующий объект. Администрируют объектменеджер очередей так же, как и другие объекты менеджера очередей сообщений.
При пользовании WebSphere MQ Explorer атрибуты объекта-менеджера очередей
нахо­дятся в одном окне Properties с атрибутами конфигурации менеджера очередей.
5.3.7. Запуск и останов менеджера очередей
Правила запуска и останова менеджера очередей сообщений специфичны для всех
платформ WebSphere MQ. В этом разделе мы опишем шаги, необходимые для этого
на каждой платформе.
Примечание. С появлением WebSphere MQ V6.0 в названия и структуру
процессов, реализующих менеджер, внесены немалые изменения. Это относится
ко всем платформам системы, кроме WebSphere MQ для z/OS. Подробности
сделанных изменений выходят за рамки книги. Однако их появление может
повлиять на ранее созданные сценарии завершения или очистки менеджера
очередей сообщений, а также контроля активности менеджера очередей на машине. Подробнее о процессах, являющихся частью менеджера очередей сообщений
WebSphere MQ V6.0, читайте в следующих руководствах.
 Windows и UNIX:
WebSphere MQ System Administration Guide, SC34-6584, – приложение D
«Stopping and removing queue managers manually»
 iSeries:
WebSphere MQ для iSeries V6.0 System Administration Guide, SC34-6586, раздел
«Work management»
WebSphere MQ для Windows, UNIX, iSeries
Для запуска и прекращения работы менеджеров очередей сообщений пользователь,
который решает эти задачи, должен являться членом группы с именем mqm. При уста­
новке WebSphere MQ эта группа создается автоматически.
Чтобы запустить менеджер, используйте один из следующих приемов.
 Запуск при помощи WebSphere MQ Explorer.
Щелкните правой кнопкой мыши по значку менеджера очередей в навигаторе
и выберите пункт Start.
Примечание. Чтобы настроить менеджер очередей сообщений на автозапуск
одновременно с машиной, используйте WebSphere MQ Explorer для Windows. В нем щелкните правой кнопкой мыши по значку менеджера очередей в навигаторе и выберите пункт Properties. После чего измените значение поля Startup с Manual на Automatic.
96
Глава 5
 Запуск по команде WebSphere MQ strmqm:
Команда strmqm доступна в WebSphere MQ на платформах UNIX и Windows
и описана в части 6 «WebSphere MQ control commands» руководства WebSphere MQ
System Administration Guide, SC34-6584.
Примечание. При пользовании управляющей командой WebSphere MQ
strmqm на базе платформы Windows менеджер запускается от имени текущего
пользователя системы. В результате его работа будет завершена, как только
текущий пользователь выйдет из своего сеанса работы. По этой причине подумайте об отказе от команды strmqm в пользу команды amqmdain qmgr start.
 Запуск по команде WebSphere MQ amqmdain qmgr start
Управляющая команда amqmdain qmgr start доступна только в WebSphere MQ для
Windows. Запускаемый с ее помощью менеджер очередей сообщений продолжает
свою работу и после того, как выполнивший команду пользователь покидает
систему. Команда amqmdain qmgr start описана в части 6 «WebSphere MQ control
commands» руководства WebSphere MQ System Administration Guide, SC34-6584.
 Запуск по CL-команде STRMQM
CL-команда STRMQM доступна в WebSphere MQ для iSeries и описана в руководстве
WebSphere MQ для iSeries V6.0 System Administration Guide, SC34-6586.
При завершении работы менеджера важно не забывать о возможном наличии актив­
ных подключений к нему со стороны приложений. По этим соображениям WebSphere
MQ поддерживает три метода завершения менеджеров.
Используйте их в следующем порядке приоритета. Если какой-то метод не может
оста­новить менеджер за требуемый интервал времени, переходите к следующему из
способов. Очередную команду вы можете запускать, пока работает менее «радикаль­
ная» предыдущая.
1. Плавный останов (quiesced shutdown).
Плавный останов – принятый по умолчанию метод завершения менеджера.
До своего останова менеджер ожидает штатного отключения всех ранее подклю­
чившихся приложений. Приложения могут продолжать использовать менеджер,
пока не отключатся от него. В процессе его использования они могут потребовать
уведомить их о том, что менеджер начинает останов, что даст возможность опре­
делить начало завершения работы и разорвать подключение.
2. Немедленный останов (immediate shutdown).
Всем действиям, выполняемым с менеджером очередей в текущий момент, предо­
ставляется возможность успешного завершения до окончания его работы. При
этом новые операции с менеджером вызывают ошибку.
3. Принудительный останов (preemptive shutdown).
Работа менеджера сразу же прекращается. Используйте этот метод только в том
случае, если ни первый, ни второй метод не принесли результатов. Принудитель­
ный останов может иметь непредсказуемые последствия для подключенных
к менед­жеру очередей приложений.
Менеджеры очередей: общее представление и настройка
97
Если ни один из трех методов не позволил остановить менеджер, обратитесь к доку­
ментации.
 К разделу «Stopping a queue manager manually» руководства WebSphere MQ System
Administration Guide, SC34-6584
 К разделу «Quiescing WebSphere MQ для iSeries» руководства WebSphere MQ для
iSeries V6.0 System Administration Guide, SC34-6586
Все методы останова следуют одинаковой процедуре. Для завершения работы
менед­жера выберите один из следующих приемов.
 При помощи WebSphere MQ Explorer.
Щелкните правой кнопкой мыши по значку менеджера очередей в навигаторе
и выберите пункт Stop.
 По команде WebSphere MQ endmqm.
Команда endmqm доступна в WebSphere MQ на платформах UNIX и Windows
и описана в части 6 «WebSphere MQ control commands» руководства WebSphere MQ
System Administration Guide, SC34-6584.
Примечание. По команде endmqm может быть остановлен в том числе
менеджер, запущенный командой amqmdain qmgr start.
 По команде WebSphere MQ amqmdain qmgr end.
Управляющая команда amqmdain qmgr end доступна только в WebSphere MQ для
Windows и описана в части 6 «WebSphere MQ control commands» руководства WebSphere MQ System Administration Guide, SC34-6584.
 По CL-команде ENDMQM.
CL-команда ENDMQM доступна в WebSphere MQ для iSeries и описана в руковод­
стве WebSphere MQ for iSeries V6.0 System Administration Guide, SC34-6586.
WebSphere MQ для z/OS
Связанная с каждым из менеджеров очередей сообщений WebSphere MQ подсистема
z/OS запускается во время начальной загрузки программ (IPL – initial program load).
Для запуска менеджера можно прибегнуть к подаваемой для его подсистемы команде
START QMGR.
В целях автоматического перезапуска менеджера при сбое может использоваться
z/OS Automatic Restart Manager (ARM). Работа ARM описана в разделе «Using the z/OS
Automatic Restart Manager (ARM)» руководства WebSphere MQ для z/OS V6.0 System
Administration Guide, SC34-6585.
При завершении работы менеджера важно не забывать о возможном наличии
актив­ных подключений к нему со стороны приложений. По этим соображениям
WebSphere MQ поддерживает целый ряд методов завершения менеджеров.
 Команда STOP QMGR MODE(QUIESCE).
Этот метод завершения менеджера принят по умолчанию. До своего останова
менед­жер ожидает штатного отключения всех ранее подключившихся приложе­
ний. Приложения могут продолжать использовать менеджер, пока не отключатся
98
Глава 5
от него. В процессе его использования они могут потребовать уведомить их о том,
что менеджер начинает свой останов, что даст возможность определить начало
завершения работы и разорвать подключение. Во избежание автоматического
пере­запуска менеджера регистрация его в ARM аннулируется.
 Команда STOP QMGR MODE(FORCE).
Работа менеджера прекращается принудительно. Используйте этот метод, если
плавный останов не позволил вам завершить менеджер за требуемый интервал
времени или же к нему нет ни одного активного подключения от приложений.
Во избежание автоматического перезапуска менеджера регистрация его в ARM
аннулируется.
 Команда STOP QMGR MODE(RESTART).
Работа менеджера прекращается так же, как при использовании команды STOP
QMGR MODE(FORCE). Однако регистрация его в ARM сохраняется. В результате,
если настройки ARM предполагают автоматический перезапуск менеджера очере­
дей сообщений, он будет запущен вновь.
5.3.8. Сетевой доступ к менеджеру очередей
Входящим в инфраструктуру менеджерам очередей и клиентам нужно установить
связь с любым из менеджеров очередей по сети. Для этого они используют базовый
протокол связи. Для целей коммуникации в WebSphere MQ могут использоваться
протоколы, которые перечислены ниже.




Transmission Control Protocol/Internet Protocol (TCP/IP)
SNA LU 6.2 (только Windows и z/OS)
NetBIOS (только Windows)
SPX (только Windows)
В этой книге мы обсудим лишь TCP/IP-протокол. Подробности других протоколов
см. в руководстве WebSphere MQ System Administration Guide, SC34-6584.
Для установления соединения по TCP/IP-протоколу менеджер очередей сообщений
должен прослушивать подключение по определенному порту.
Как имя соединения выступает IP-адрес или имя хоста машины, объединенное с номе­
ром порта, который активно прослушивает менеджер очередей сообщений. Имя сое­
динения служит идентификатором менеджера в TCP/IP-сети, которым для установле­
ния связи могут пользоваться другие менеджеры или клиенты.
Менеджер очередей сообщений может выбирать любой номер порта, который
не прослушивает другой менеджер WebSphere MQ или иное программное обеспече­
ние на машине.
Известным номером порта WebSphere MQ является 1414. Если на машине работает
единственный менеджер очередей сообщений, обычно он прослушивает TCP/IPпорт с этим номером. Если имя соединения не содержит номера порта, WebSphere
MQ предполагает, что на машине с данным IP-адресом или именем хоста имеется
менеджер очередей сообщений, который прослушивает именно этот порт.
Менеджеры очередей: общее представление и настройка
99
5.3.9. Слушатель WebSphere MQ
На всех платформах WebSphere MQ, за исключением WebSphere MQ для z/OS, прослу­
шиванием TCP/IP занят процесс-«слушатель» (listener) WebSphere MQ.
Он прослушивает подключения к своему порту, после чего для обработки соединения
создает канальный агент (MCA – message channel agent), который действует независи­
мо от того, идет ли речь о распределенном, кластерном канале сообщений или кли­
ентском соединении. Каналы сообщений и MCA мы обсудим в разделе 7.1.2 «Понятие
состояния канала».
Агент MCA, созданный слушателем WebSphere MQ, не выполняется в своем собствен­
ном процессе внутри системы. Напротив, он формируется слушателем в пределах
пула процессов. Число процессов в упомянутом пуле автоматически регулируется
WebSphere MQ в зависимости от количества активных MCA каждого менеджера.
В целом этот подход называют формированием канального пула (channel pooling).
Его применение означает, что каждый из MCA требует меньше ресурсов, чем при
рабо­те внутри собственного процесса. В зависимости от схемы самой системы и
наблю­даемых в ней нагрузок менеджер очередей сообщений может иметь тысячи
активных одновременных подключений.
Примечание. До выпуска WebSphere MQ V5.3 формирование канального
пула для платформ UNIX отсутствовало. Вместо него использовался процессслушатель операционной системы inetd. WebSphere MQ Version 5.3 и WebSphere
MQ Version 6.0 по-прежнему поддерживают использование входящего в ОС
слушателя inetd. Однако он не дает возможности использовать преимущества
предоставляемых WebSphere MQ функций формирования канального пула,
поскольку каждый из MCA работает в рамках своего собственного процесса.
Для формирования слушателей используется MQSC-команда DEFINE LISTENER, для
запуска – MQSC-команда START LISTENER.
В WebSphere MQ Explorer слушатели могут создаваться и запускаться автоматически
при создании менеджера. Если это вам не подходит, то для создания слушателей
щелкните правой кнопкой мыши по находящейся в навигаторе папке Listeners
менеджера очередей сообщений и выберите пункт меню New → Listener.
Для запуска слушателей в WebSphere MQ Explorer выберите в навигаторе папку Listeners
менеджера очередей сообщений. На вновь открывшейся странице содержимого
Listeners щелкните правой кнопкой мыши по слушателю и выберите пункт меню
Start.
WebSphere MQ для Windows также поддерживает слушатели LU 6.2, NetBIOS и SPX.
Слушатель можно настроить на автозапуск одновременно с менеджером. По этой
причине рекомендуем вам отказаться от запуска слушателей вручную, сконфигури­
ровав каждый менеджер так, чтобы заданный для него слушатель автоматически
запус­кался с ним вместе.
100
Глава 5
Примечание. До выпуска WebSphere MQ Version 6.0 слушатель WebSphere
MQ не был объектом менеджера очередей сообщений. Для справки в WebSphere
MQ V5.3 доступны следующие приемы запуска слушателей сетевых подключений.
 В WebSphere MQ V5.3 для UNIX-платформ слушатель должен запускаться
из командной оболочки вручную при помощи управляющей команды WebSphere MQ runmqlsr.
 В WebSphere MQ для iSeries V5.3 для запуска слушателя используется CL-команда STRMQMLSR.
 В WebSphere MQ для Windows V5.3 слушатель может автоматически
запускаться совместно с менеджером при помощи управляющей команды WebSphere MQ amqmdain crtlsr или модуля оснастки WebSphere MQ Services.
5.3.10. Инициатор каналов WebSphere MQ для z/OS
В WebSphere MQ для z/OS TCP/IP-сеть прослушивает инициатор каналов (channel
initiator).
Инициатор каналов WebSphere MQ для z/OS, также известный как инструмент
пересылки (mover), действует в адресном пространстве менеджера очередей
сообщений. Он служит для размещения всех относящихся к менеджеру канальных
агентов (MCA) независимо от того, управляют ли эти агенты распределенным,
кластерным каналом сообщений или клиентским соединением. Каналы сообщений
и MCA мы обсудим в разделе 7.1.2 «Понятие состояния канала».
Для запуска инициатора служит команда START CHINIT, выполняемая в подсистеме
менеджера очередей сообщений.
В пределах инициатора допустим запуск нескольких TCP/IP-слушателей, каждый
из которых прослушивает конкретный TCP/IP-порт. Для запуска слушателя используется
выполняемая в подсистеме менеджера очередей сообщений команда START LISTENER.
WebSphere MQ для z/OS также поддерживает слушатели LU 6.2.
5.3.11. Очередь недоставленных сообщений
WebSphere MQ предоставляет гарантию доставки сообщений, а потому, если сообще­
ние не может быть доставлено в очередь назначения или в транспортную очередь
на мар­шруте его движения, система предпринимает определенные меры.
При этом сообщение помещается в очередь недоставленных сообщений (dead letter
queue) последнего менеджера, который оно попыталось пройти на пути к месту
своего назначения.
При создании менеджера очередь недоставленных сообщений не создается Web­
Sphere MQ автоматически. Однако ее требуется создать, а менеджер очередей
сообщений – настроить на ее применение.
К причинам, по которым сообщение может быть не доставлено, относятся следующие:
у менеджера нет очереди с приведенным названием; менеджер не знает о том, какому
Менеджеры очередей: общее представление и настройка
101
очередному менеджеру переслать сообщение на маршруте; в очереди уже находится
предельно допустимое для нее количество сообщений.
Примечание. Если менеджер не настроен на применение очереди недоставленных сообщений, а сообщение от другого менеджера ему доставить нельзя, то
передача всех сообщений по каналу, соединяющему два этих менеджера, блокируется. Работа канала сообщений сможет возобновиться только после настройки
менеджера-приемника путем задания для него очереди недоставленных сообщений или обеспечения возможности успешной доставки сообщения определением
целевой очереди. В противном случае конкретное сообщение, которое не удается
доставить, может быть вручную удалено из очереди, однако это потребует, чтобы
оно было опознано и извлечено приложением.
По этой причине настройте очереди недоставленных сообщений для всех без
исключения менеджеров очередей сообщений в инфраструктуре.
Очереди недоставленных сообщений и их настройка станут темой нашего обсужде­
ния в разделе 7.4.11 «Ошибки доставки сообщений».
5.3.12. Командный сервер
WebSphere MQ позволяет администрировать менеджеры очередей удаленно. Для
упро­щения такой работы на менеджере очередей сообщений может работать команд­
ный сервер. Он выполняет посылаемые менеджеру команды. Речь о них шла в раз­деле 5.2.7 «Форматы программируемых команд (PCF)».
5.3.13. Журнализация
Журнализация – одна из основных внутренних функций менеджера. Его журнал – это
запись осуществленных менеджером очередей действий в порядке их выполнения.
Как журнальные записи (log records) регистрируются все действия над постоянными
сообщениями, изменения конфигурации объектов менеджера и другие действия
внутреннего характера.
Способ ведения журнала менеджером гарантирует, что заносимые в него действия не
завершаются до тех пор, пока запись о выполнении не будет помещена в журнал
в надежном хранилище информации.
Данные из журнала отделены от данных самого менеджера. Последние содержат
только текущее состояние всех объектов и сообщений в очередях. Подходы к записи
данных менеджером очередей сообщений могут предполагать их буферизацию
в памяти или запись в надежное хранилище информации с использованием
оптимизированных возможностей операционной системы.
Поэтому не исключается возможность того, что, если менеджер будет неожиданно
остановлен, к примеру ввиду внезапного сбоя в машине, на которой он выполняется,
данные менеджера утратят целостность и логичность.
В этом случае для повторного достижения корректного текущего состояния объектов
при перезапуске менеджер пользуется журналом. Для этого он повторяет те действия,
102
Глава 5
которые описаны записями в журнале и произошли с момента рассогласования
журнала и данных самого менеджера.
Менеджер регулярно сверяет целостность данных журнала и своих собственных.
Этот процесс осуществляется во время контрольных точек (checkpoint), проис­
ходящих автоматически во время работы менеджера и по ее завершении.
Если менеджер очередей завершен штатно, контрольная точка означает, что
повторения потребует минимальное число записей, а запуск менеджера пройдет
оптимально. Если менеджер закроется аварийно, то повторения при его запуске
может потребовать большее число записей из журнала.
Если элемент данных менеджера очередей сообщений, к примеру информация
в сооб­щении, тем или иным образом искажен, то связанный с элементом объект,
например очередь, снабжается признаком «поврежденный» (damaged). При наличии
у объекта признака повреждений доступ приложений к нему блокируется. Если таким
объектом является объект-очередь, сообщения в ней становятся недоступны.
5.3.14. Восстановление носителя
Поврежденный объект можно восстановить по ведущимся менеджером журналам.
Этот процесс носит название восстановления носителя (media recovery). Для обес­
печения возможности восстановления носителя менеджер очередей сообщений
в WebSphere MQ для платформ Windows и UNIX нужно настроить так, чтобы
использовалась линейная (linear logging), а не циклическая журнализация (circular
logging). В WebSphere MQ для iSeries журнализацию всегда можно считать линейной.
Проблемы журнализации и восстановления носителей в WebSphere MQ для z/OS
достаточно специфичны и не являются предметом рассмотрения в этой книге. Для
изучения этих вопросов читайте руководство WebSphere MQ для z/OS V6.0 Concepts
and Planning Guide, GC34-6582.
Суть же циклической и линейной журнализации такова.
 Циклическая журнализация.
Менеджер очередей сообщений управляет размером журнала автоматически, не
требуя усилий администратора. Однако при этом он гарантирует только то, что
обладает достаточной информацией для поддержания целостности критических
для бизнеса данных, включая постоянные сообщения, и перезапуска менеджера.
В то же время восстановление носителя невозможно, так как объем данных о
каждом объекте менеджера в журнале для этого недостаточен.
 Линейная журнализация.
Менеджер ведет непрерывный журнал с момента формирования, никак не управ­
ляя его размером. В итоге журнал содержит всю информацию, необходимую для
воссоздания объектов. Однако для архивации или удаления журналов, в которых
отпала необходимость, необходима работа администратора, иначе ресурсы хра­
нилища информации, доступные для размещения журнала, в конце концов пере­
полнятся.
Менеджеры очередей: общее представление и настройка
103
Менеджер очередей сообщений уведомляет администратора о наиболее старых
записях из журнала, требуемых для своего перезапуска. Также он сообщает адми­
нистратору о самых старых записях, необходимых в целях восстановления носи­
теля объектов этого менеджера.
Примечание. WebSphere MQ V6.0 позволяет администратору увидеть, какие
наиболее старые записи в составе журнала необходимы для восстановления
носителя той или иной очереди.
Администратор может удалять из журнала любые записи, возраст которых
превышает возраст старейшей записи, необходимой для перезапуска менеджера
очередей сообщений без ущерба для его деятельности. В то же время для
упрощения восстановления его объектов администратор вправе сохранять
(возможно, в сжатом виде и на резервном носителе) в том числе старые записи
о работе менеджера очередей сообщений.
Образ (media image) конкретной выборки или всей совокупности объектов ме­
неджера может быть занесен в журнал системным администратором. При этом
в журнале образуется весь набор записей, требуемых для восстановления носите­
ля для объекта. В итоге размер журнала, необходимого в целях восстановления
носителя, может стать меньше. Без занесения в журнал образа процесс восстанов­
ления носителя может потребовать наличия записей, сопоставимых по возрасту
с моментом формирования исходного объекта восстановления, и включать
повторение действий, описанных большим числом записей в составе журнала.
С журнализацией менеджера, под управлением которого находятся критичные
для предприятия службы, рекомендуем вам ознакомиться поподробнее. Получен­
ный багаж знаний поможет выбрать механизм журнализации менеджера, сплани­
ровать администрирование линейных журналов и понять то, как на процессы
журнализации влияют единицы работы. За справкой по этому кругу вопросов
обра­щайтесь к следующим руководствам.
 Windows и UNIX:
WebSphere MQ System Administration Guide, SC34-6584, раздел «Recovery and problem
determination»
 iSeries:
WebSphere MQ для iSeries V6.0 System Administration Guide, SC34-6586, раздел «Back­
up, recovery and restart»
5.3.15. Журналы ошибок
Происходящие с менеджером WebSphere MQ на платформах Windows, UNIX и iSeries
значимые события заносятся в журналы ошибок этого менеджера вместе с
отражающей момент их наступления временной меткой. Их детальное описание
менеджером очередей сообщений схоже с описаниями событий в журналах
операционной системы. Поэтому журналы ошибок должны периодически
контролироваться администратором той машины, где установлен WebSphere MQ.
104
Глава 5
Примерами разновидностей информации, входящей в журнал ошибок менеджера
очередей сообщений, являются:
 информация о запуске и останове данного менеджера;
 информация о входящих и исходящих подключениях данного менеджера, вклю­
чая распределенные и кластерные каналы сообщений и соединения с клиентами.
Сюда же относятся сведения о сбоях;
 информация о попытках нарушения защиты, то есть о стремлении приложений
получить доступ к объектам, обращаться к которым этим приложениям запрещено;
 непредвиденные события, происходящие с менеджером.
Журналы ошибок менеджера содержатся в ряде пригодных для человеческого вос­
приятия файлов, которые можно открыть в программе просмотра текстов. Для каж­
дого менеджера объем такого набора файлов фиксирован и составляет по умолчанию
256 Кб. При заполнении одного файла менеджер переходит к другому, но не больше
трех раз. Имена файлов журнала ошибок следующие:
 AMQERR01.LOG
 AMQERR02.LOG
 AMQERR03.LOG
Примечание. Размер каждого из журналов ошибок WebSphere MQ V6.0
можно сконфигурировать, воспользовавшись параметром ErrorLogSize в
настройках определенного менеджера. Также WebSphere MQ V6.0 дает
возможность ограничить частоту журнализации самых распространенных
событий, включая установление соединений. Подробнее об этом см. в разделе
«Configuring WebSphere MQ» руководства WebSphere MQ System Administration
Guide, SC34-6584.
Иногда события, происходящие на машине с WebSphere MQ, нельзя связать с кон­к­
ретным менеджером очередей сообщений. К числу этих событий относятся в том
числе неудачные попытки клиентского приложения установить соединение с менед­
жером. События такого рода регистрируются в нескольких журналах ошибок
WebSphere MQ, которые носят название системных и по формату полностью совпа­
дают с журналами ошибок менеджеров очередей сообщений.
Кроме того, в редких случаях WebSphere MQ может связать событие с менеджером,
но оказаться не в состоянии зарегистрировать событие в ведущемся для этого менед­
жера журнале. Тогда запись о событии сохраняется в другом наборе журналов – сис­
темных журналах ошибок менеджеров очередей сообщений, – или вместо нее стро­
ится FFST-отчет (FFST – First-Failure Support Technology). Более подробную информа­
цию читайте в разделе 12.1.6 «Технология FFST».
Журналы ошибок имеют следующее месторасположение.
 Windows:
– журналы ошибок менеджеров:
C:\Program Files\IBM\WebSphere MQ\Qmgrs\название_менеджера\errors
Менеджеры очередей: общее представление и настройка
105
– системные журналы ошибок WebSphere MQ:
C:\Program Files\IBM\WebSphere MQ\errors
– системные журналы ошибок WebSphere MQ при установке только клиентской
части:
C:\Program Files\IBM\WebSphere MQ Client\errors
– системные журналы ошибок менеджеров:
C:\Program Files\IBM\WebSphere MQ\@SYSTEM\errors
 UNIX:
– журналы ошибок менеджеров:
/var/mqm/qmgrs/название_менеджера/errors
– системные журналы ошибок WebSphere MQ:
/var/mqm/errors
– системные журналы ошибок менеджеров:
/var/mqm/qmgrs/@SYSTEM/errors
 iSeries:
– журналы ошибок менеджеров:
/QIBM/UserData/mqm/название_менеджера/errors
– системные журналы ошибок WebSphere MQ:
/QIBM/UserData/mqm/errors
– системные журналы ошибок менеджеров:
/QIBM/UserData/mqm/&SYSTEM/errors
5.3.16. 64-разрядное оборудование
64-разрядное оборудование дает возможность адресовать значительно больше
ресурсов памяти для конкретного приложения, чем 32-разрядные вычислительные
системы. Однако, для того чтобы эти дополнительные ресурсы памяти стали доступны
для приложений, 64-разрядную адресацию должна поддерживать и операционная
система компьютера.
До выпуска WebSphere MQ V6.0 менеджеры очередей сообщений для платформ UNIX
не пользовались реализованной на этих платформах адресацией дополнительной
памяти.
Приложения, подключенные к менеджерам очередей сообщений на UNIX-платфор­
мах, могли использовать 64-разрядную адресацию этих 64-битных платформ лишь с
по­мощью 64-разрядных клиентов из SupportPac, что снижало производительность
приложений, которые работают по сети.
WebSphere MQ V6.0 содержит 64-разрядные менеджеры очередей сообщений для ря­
да UNIX-платформ. Такие менеджеры по-прежнему готовы принимать подключения
32-разрядных приложений посредством связывания или клиентских соединений,
однако теперь могут принимать и подключения к ним 64-разрядных приложений
при помощи связывания.
106
Глава 5
Приложениям, реализующим службы, это дает возможность использовать функции
64-битной адресации памяти операционной системой и оборудованием при под­
ключении их к менеджерам очередей сообщений WebSphere MQ Version 6.0.
Возможностями 64-битной адресации на UNIX-платформах пользуются и менеджеры
очередей сообщений, которые при своем масштабировании могут выходить за пре­
делы, обусловленные 32-разрядной адресацией памяти.
Примечание. На одинаковом оборудовании 64-разрядные менеджеры
WebSphere MQ V6.0 не всегда более производительны, чем 32-разрядные менеджеры WebSphere MQ V5.3. Однако в отдельных случаях скорость работы
WebSphere MQ V5.3 ограничивает 32-разрядная адресация, что требует внимательно отнестись к повышению производительности.
На платформах с 64-битной адресацией памяти внутренние структуры WebSphere
MQ иногда требуют больше ресурсов памяти. В результате максимальная емкость
некоторых 64-разрядных менеджеров WebSphere MQ V6.0 может быть меньше,
чем 32-разрядных менеджеров WebSphere MQ V5.3 на этом же оборудовании.
Впрочем, на более мощном сервере с бо'льшим объемом памяти 64-битный
менеджер очередей сообщений WebSphere MQ V6.0 способен к более ощутимому
масштабированию. Причиной тому является то, что частью этих ресурсов памяти
32-разрядные менеджеры просто не в состоянии воспользоваться.
Подробнее о 64-разрядных платформах, которые в настоящее время поддерживает
WebSphere MQ, см. на Web-странице по адресу:
http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html
Менеджеры очередей: общее представление и настройка
107
6
Технические основы
организации очередей
сообщений
Эта глава книги подробно описывает базовые возможности WebSphere MQ по орга­
низации очередей сообщений. В ней будут приведены сведения о формируемых в
составе менеджера объектах и их использовании. Мы опишем сообщения WebSphere
MQ и то, как отправлять и принимать их, используя интерфейс очередей сообщений
(MQI).
Отдельные детали организации MQI-интерфейса не связаны ни с одним из таких
объектно-ориентированных или стандартизованных интерфейсов прикладного
программирования (API), как Java Message Service (JMS), непосредственно. Однако эти
API основаны на базовых возможностях MQI-интерфейса. Поэтому понимание объ­
ектов, сообщений WebSphere MQ и MQI не становится бесполезным даже при обра­
щении к инфраструктуре через стандартизованные API.
В этой главе мы обсудим следующие вопросы:
 Интерфейс очередей сообщений
 Очереди
 Применение триггеров
Технические основы организации очередей сообщений
109
6.1. Интерфейс очередей сообщений
Интерфейс очередей сообщений (MQI – Message Queue Interface) служит процедур­
ным интерфейсом отправки и получения сообщений через WebSphere MQ. Поэтому
напрямую он может использоваться только из процедурных языков программирова­
ния, например C. В то же время немало приложений из числа созданных для обраще­
ния к инфраструктуре очередей сообщений WebSphere MQ используют объектноориентированный язык, такой как C++ или Java. Впрочем, извлечь выгоду из исполь­
зования стандартизованных интерфейсов отправки и получения сообщений
WebSphere MQ, включая Java Message Service (JMS) или Extended Message Service (XMS),
могут и приложения, написанные на процедурных и объектно-ориентированных
языках одновременно.
Как бы то ни было, все эти API используют MQI как основу реализации, либо вызывая
функции модулей, написанных на языке C, либо посылая по клиентскому подключе­
нию менеджеру очередей сообщений команды MQI-интерфейса. Поэтому знание
самого MQI может оказаться чрезвычайно полезным при написании приложений,
использующих API, и при анализе потока сообщений в инфраструктуре.
MQI-интерфейс содержит 13 функций, а также структуры и типы данных. Они реали­
зуют доступ к функциям менеджера, связанным с отправкой и получением сообще­
ний по принципу межточечного обмена, заданием структуры сообщений WebSphere
MQ и обеспечением возможности запроса и изменения атрибутов важнейших типов
объектов.
6.1.1. Дескриптор сообщения WebSphere MQ (MQMD)
Дескриптор сообщения WebSphere MQ (MQMD) связан с каждым из сообщений,
находящихся в очереди под управлением менеджера. Это – структура, содержащая
ряд полей с описанием сообщения. Размещая сообщение в очереди, приложение
передает менеджеру его дескриптор отдельно от его тела. При чтении из очереди
приложение получает от менеджера очередей MQMD и тело сообщения отдельно.
Следующий список содержит перечень часто используемых полей дескриптора
сообщения.
 Тип сообщения (MsgType).
В WebSphere MQ сообщения могут помечаться как относящиеся к типам, перечис­
ленным ниже.
– Дейтаграмма (datagram) – не требует обязательного ответа, но может требо­
вать формирования отчета.
– Запрос (request) – требует обязательного ответа.
– Ответ (reply) – выдается как отклик на сообщение-запрос.
– Отчет (report) – строится при обработке сообщения.
 Отчет (Report) и обратная связь (Feedback).
Поле «отчет» выступает признаком требования отчета, формируемого при обра­
ботке сообщения менеджером очередей сообщений или приложением-получате­
лем. Например, приложению может требоваться отчет менеджера-приемника об
110
Глава 6
успешной доставке сообщения или от приложения-получателя – о его успешном
обслуживании. При формировании отчета приложением или менеджером в поле
обратной связи помещается код с указанием причины для его построения.
 Очередь ответов (ReplyToQ).
Приложение, выдающее сообщение-запрос или определяющее варианты постро­
ения отчета, задает в этом поле название очереди ответов. Приложение, формиру­
ющее ответ на этот запрос или отчет как отклик на дейтаграмму, помещает его в
ту очередь, которая имеет такое название.
 Менеджер очереди ответов (ReplyToQMgr).
Содержит имя менеджера очередей, управляющего очередью ответов. WebSphere
MQ автоматически помещает в это поле название того менеджера, в который
сообщение помещается изначально. Приложение должно модифицировать это
поле только в том случае, если его ответы или отчеты необходимо пересылать в
очередь на другом менеджере.
 Идентификатор сообщения (MsgId).
Может быть определен приложением или сгенерирован менеджером. Выдается
приложению-отправителю менеджером очередей сообщений и может использо­
ваться при последующей обработке.
Созданный менеджером очередей сообщений идентификатор является неповто­
ряющимся во всей инфраструктуре WebSphere MQ. Однако это зависит от всех без
исключения менеджеров в ее составе, имеющих уникальные в пределах первых
12 символов имена.
 Корреляционный идентификатор (CorrelId).
Это поле может использоваться приложениями для связи двух сообщений или
связи сообщения и приложения. Чаще всего служит для сопоставления ответа с
запросом при обмене сообщениями по принципу «запрос – ответ». Приложение,
которое обрабатывает запрос, копирует его идентификатор сообщения в поле
корреляционного идентификатора формируемого ответа. Если же в одну очередь
приходят ответы сразу на несколько сообщений-запросов или ответы на запросы
нескольких приложений, то приложение сможет прочитать ответ, обратившись
лишь к сообщениям с нужным корреляционным идентификатором.
 Признак постоянного сообщения (Persistence).
Это поле определяет, относится ли сообщение к категории постоянных, речь
о которых велась в разделе 3.4.1 «Постоянные и непостоянные сообщения». Буду­
чи не заданным приложением-отправителем явно, оно наследует значение при­
знака постоянных сообщений той очереди, в которой размещено.
 Приоритет (Priority).
Сообщениям может назначаться приоритет от 0 до 9. При этом WebSphere MQ
можно настроить так, чтобы сообщения с большим приоритетом передавались
приложениям раньше тех сообщений, чей приоритет ниже.
 Идентификатор набора кодовых символов (CCSID – CodedCharSetId).
CCSID задает набор символов, который отображает определенные символы в те
или иные байты или наборы байтов. Для данных, именуемых строковыми и пред­
ставляющих текст, WebSphere MQ может производить конверсию из одного набо­
Технические основы организации очередей сообщений
111
ра символов в другой так, что одни и те же символы будут представлены одними и
теми же данными в сообщении. Мы говорили об этом в разделе 4.3.2 «Преобразо­
вание данных». По умолчанию поле имеет значение CCSID менеджера, которому
передано конкретное сообщение; последнее же чаще всего равно CCSID соответс­
твующего компьютера.
 Кодировка (Encoding).
От платформы к платформе порядок байтов в числовых данных меняется.
WebSphere MQ использует поле «кодировка» для указания того, как эти данные
представляют числовые значения. Как в случае CCSID, над числовыми данными в
WebSphere MQ допустимо преобразование информации. По умолчанию поле
«кодировка» имеет значение типа кодировки машины, где сформировано сообще­
ние.
 Формат (Format).
Поле «формат» определяет тип данных, передаваемых в сообщении. Оно может
задавать тип данных сообщения в целом: строковый, числовой, двоичный. Кроме
того, оно может определять тип структуры WebSphere MQ, которая, в свою оче­
редь, может всего лишь являться первой в числе структур, образующих цепь
структур сообщения. Каждая из структур этого рода способна включать в себя
различные типы данных. По умолчанию поле «формат» соответствует двоичному
типу, преобразования которого в WebSphere MQ запрещены.
 Время (PutTime) и дата (PutData) размещения в очереди.
В этих полях дескриптора сообщения менеджер сохраняет время и дату, пред­
ставляющие момент прибытия сообщения в очередь, где оно пребывает в настоя­
щее время.
 Срок жизни (Expiry).
Сообщениям может назначаться период существования, помещаемый в это поле
и измеряемый в десятых долях секунды. Если сообщение остается в инфраструк­
туре очередей WebSphere MQ дольше этого времени, оно становится устаревшим,
недоступным для приложений и пригодным для удаления менеджером очередей
сообщений. Устаревшие сообщения удаляются исключительно при попытке
извлечения или просмотра их приложением. WebSphere MQ V6.0 содержит в сво­
ем составе задание контроля срока существования (expiry task), которое перио­
дически просматривает все сообщения всех без исключения очередей и принуди­
тельно удаляет устаревшие сообщения.
MQMD содержит сведения о приложении, поместившем сообщение в очередь, и
идентификаторе пользователя, от чьего имени это приложение выполнялось.
Также в MQMD входит информация, относящаяся к сообщениям, входящим в группы,
или сегменты. О сообщениях такого рода мы говорили в разделе 4.6.7 «Сегментация
сообщений».
6.1.2. Коды завершения и причины
Вызов любой из функций MQI-интерфейса завершается возвратом кода завершения
(CompCode) и причины (Reason):
112
Глава 6
 Код завершения.
Может иметь одно из трех следующих значений:
– MQCC_OK: обращение к функции успешно завершено.
– MQCC_WARNING : функция выполнена частично. Подробности отражены в коде
причины.
– MQCC_FAILED: вызов функции неудачен.
 Код причины.
По завершении вызова любой функции она может вернуть один из многих кодов
причины; какие-то из них представляют признаки сбоя, какие-то – частичное
выполнение. Подробнее см. раздел “Reason” описания полей (Fields) конкретных
вызываемых функций в руководстве WebSphere MQ Application Programming
Reference, SC34-6596.
Код причины – целочисленное значение. Для получения символьного представ­
ления десятичного или шестнадцатеричного числового значения или числового
значения из символьного представления используйте команду WebSphere MQ
mqrc. В следующем примере для кода причины MQRC_NO_MSG_AVAILABLE будет
выдана одинаковая информация:
mqrc MQRC_NO_MSG_AVAILABLE
mqrc 2033
mqrc 0x7F1
mqrc 0x000007f1
Подробности см. в разделе 12.1.2 «Коды причины».
6.1.3. MQCONN и MQCONNX
Для отправки сообщений через инфраструктуру очередей каждое приложение или
поток должно установить соединение с менеджером. Им может являться локальный
менеджер, размещенный на той же машине, что и приложение, или же удаленный
менеджер на другой машине сети.
Программный выбор способа подключения приложения – связывание с локальным
менеджером или клиентское соединение с удаленным – в MQI невозможен. В про­
граммах на языке C, использующих MQI напрямую, выбор производится подключе­
нием к приложению библиотек связывания или клиентских соединений. При поль­
зовании другими API метод выбора подключения к менеджеру зависит от самого API
и обсуждается в документации WebSphere MQ к данному интерфейсу.
В MQI-интерфейс входят две функции подключения к менеджеру очередей сообще­
ний: MQCONN и MQCONNX. Единственное различие между ними заключается в том,
что вызову функции MQCONNX можно передать дополнительные параметры, объ­
единенные в структуру параметров подключения (MQCNO).
При вызове любой из двух функций установления соединения ей требуется название
того менеджера, к которому должно быть подключено приложение. Если это назва­
ние не указано, а приложение использует подключение путем связывания, предпола­
гается применение менеджера очередей сообщений по умолчанию, как это описано
в разделе 5.3.5 «Менеджер по умолчанию».
Технические основы организации очередей сообщений
113
Приложение может установить соединение с менеджером только в том случае, если
оно на это уполномочено. В основе авторизации приложений лежит контекст иден­
тификационных данных (identity context). Для приложений, выполняющих связыва­
ние, этим контекстом служит идентификатор пользователя операционной системы,
от чьего имени выполняется приложение. Он же может выступать в роли контекста
идентификационных данных для клиентских соединений; кроме того, в последнем
случае менеджер очередей может быть сконфигурирован так, чтобы предоставлять
клиенту конкретный идентификатор пользователя, существующий на удаленной
машине, где работает менеджер.
В случае успешного подключения приложению выдается описатель (handle) соеди­
нения (Hconn), который им должен передаваться всем будущим вызовам MQI.
6.1.4. MQOPEN и MQCLOSE
Функция MQI MQOPEN служит для обращения к заданному объекту в составе менед­
жера, с которым приложение установило соединение. Для каждого из объектов
(например, очереди) доступ к которому необходим приложению, должен произво­
диться отдельный вызов. Любой вызов функции MQOPEN должен сопровождаться
соответствующим вызовом MQCLOSE.
Приложение передает MQOPEN дескриптор объекта (MQOD). Он описывает объект,
который планирует открыть приложение, и содержит его название. При работе с
очередями также может задаваться название менеджера очередей сообщений. Это
позволяет приложению переслать конкретное сообщение конкретному менеджеру в
системе, информацией о котором располагает локальный менеджер. Подробнее об
этом см. раздел 6.2.1 «Разрешение названия очереди».
Также приложение передает этой функции параметры, определяющие род действий,
которые нужно осуществить над объектом.
Основываясь на информации из дескриптора и контексте идентификационных дан­
ных приложения, менеджер выясняет, уполномочено ли данное приложение на
выполнение запрошенного им действия над данным объектом. Если полномочия
есть, приложению возвращается описатель объекта ( Hobj ), который при работе с
этим объектом должен передаваться им будущим вызовам MQI.
Не все типы объектов доступны через MQI-интерфейс. Как правило, MQI служит для
открытия объектов-очередей для размещения в них и изъятия сообщений. Типы
объектов-очередей под управлением менеджеров и способы обращения к очередям
удаленного менеджера мы обсудим в разделе 6.2 «Очереди».
При вызове MQOPEN приложение может запросить следующие возможные действия:
 Запись (Output). Размещение в очереди сообщений функцией MQPUT. Доступно
только для объектов-очередей.
 Просмотр (Browse). Считывание из очереди сообщений функцией MQGET, при
котором те сохраняют свою доступность для других приложений. Доступно толь­
ко для объектов-очередей под управлением того менеджера, к которому подклю­
чено приложение.
114
Глава 6
 Извлечение (Input). Считывание из очереди сообщений функцией MQGET, после
которого сообщения не сохраняют свою доступность для других приложений.
Может быть монопольным, что означает возможность открытия очереди для счи­
тывания лишь одним приложением одновременно. Доступно только для объек­
тов-очередей под управлением того менеджера, к которому подключено прило­
жение.
 Запрос (Inquire). Возврат значений атрибутов объекта функцией MQINQ.
 Установка (Set). Задание значений атрибутов объекта функцией MQSET.
6.1.5. MQPUT
MQI-функция MQPUT служит для размещения сообщений в очередях, открытых для
записи.
Вызов функции MQPUT завершается постановкой сообщения в очередь того менед­
жера, к которому подключено приложение. Впрочем, объект, открытый функцией
MQOPEN, может представлять очередь назначения под управлением другого, удален­
ного менеджера. В этом случае очередью, в которой будет размещено сообщение,
станет транспортная очередь (transmission queue) локального менеджера.
Доставка сообщения менеджеру, которому оно предназначено, как и любому другому
менеджеру на маршруте его движения, осуществляется по каналам. Каналы передачи
сообщений мы обсудим в разделе 7.4 «Распределенные каналы сообщений».
При вызове функции MQPUT ей передается структура дескриптора сообщения (MQMD).
Во время работы функции менеджер заполняет дескриптор данными, возвращая их
приложению в той же самой структуре.
Примечание. Если одна и та же структура MQMD служит для выполнения
нескольких вызовов MQPUT, поля, которые сформировал менеджер, между
вызовами должны быть обнулены. Очистки, в частности, требует идентификатор
сообщения; иначе он будет полностью совпадать у всех сообщений, размещенных
с помощью этой структуры MQMD.
Для указания того, как именно выполняется обращение к MQPUT, ей также передается
структура параметров размещения сообщения (MQPMO ), в которой приложению воз­
вращается определенная информация.
Обычно MQPMO служит для указания на то, что обращение к MQPUT должно произойти
под управлением точки синхронизации. Это значит, что вся работа по размещению
сообщения войдет в текущую единицу работы, а сообщение будет недоступно осталь­
ным приложениям для считывания и передачи менеджеру-получателю сообщения,
пока не будет произведен вызов функции MQCMIT.
6.1.6. MQPUT1
MQI-функция MQPUT1 вызывает MQOPEN, за ней – MQPUT и завершает свою работу
вызовом MQCLOSE. Приложение же должно передать ей достаточно информации
для выполнения всех трех действий.
Технические основы организации очередей сообщений
115
MQPUT1 – удобный и эффективный механизм вызова при постановке в очередь еди­
ничного сообщения. Нередко он служит для размещения в очереди сообщения-отве­
та или отчета.
6.1.7. MQGET
MQI-функция MQGET предназначена для считывания сообщений из очередей,
открытых для просмотра или для извлечения.
На вход функции MQGET передается структура дескриптора сообщения (MQMD). В ней
менеджер очередей возвращает дескриптор успешно считанного сообщения.
Для указания того, как именно выполняется обращение к MQGET, ей также передается
структура параметров извлечения сообщения (MQGMO), в которой приложению возвра­
щается определенная информация.
Структура MQGMO определяет, должен ли вызов функции MQGET просмотреть сооб­
щения, оставив таковые доступными для других приложений, или извлечь с удалением их из очереди.
Приложение могут не интересовать все сообщения очереди. Например, ему могут
быть интересны только отчеты или ответы на дейтаграммы или запросы, выданные
им самим. Для упрощения своей задачи приложение может указать на тот факт, что
ему интересны лишь сообщения с конкретным корреляционным идентификатором,
поместив этот идентификатор в структуру MQMD, передаваемую функции MQGET. При
этом оно может управлять тем, производится ли сопоставление с корреляционным
идентификатором из структуры MQMD, используя для этого параметры сопоставления
(match options) в структуре MQGMO. Такое считывание сообщения носит название извлечения по корреляционному идентификатору.
Используя этот же механизм, приложение может прибегнуть к извлечению по идентификаторам сообщений. Однако при работе с очередями, которые содержат мно­
жество сообщений, такое поведение менее эффективно, чем извлечение по корреля­
ционному идентификатору, и при обычных условиях, как правило, не используется.
Одна из целей извлечения по идентификаторам сообщений – решение таких задач
администрирования системы, как извлечение с удалением или просмотр конкретно­
го сообщения.
Структура MQGMO определяет, должно ли приложение ждать появления в очереди отве­
чающих его критериям сообщений, извлекая их по прибытии в течение установлен­
ного периода. При этом приложение может отказаться от ожидания, ждать неопреде­
ленно долгое время или до истечения заданного в миллисекундах периода ожидания.
Ожидать прибытия сообщений в одну общую очередь могут сразу несколько прило­
жений. В этом случае порядок извлечения сообщений из очереди не определен.
Вызывая функцию MQGET, приложение передает ей буфер и указывает его размер.
Если сообщение слишком велико для размещения в буфере, приложение может
использовать MQGMO , чтобы определить, как должен поступить менеджер: вернуть
сообщение частично или сигнализировать об ошибке при вызове MQGET.
MQGMO определяет, должна ли функция MQGET выполняться под управлением точки
синхронизации. Последнее означает, что вся работа по извлечению сообщения вой­
116
Глава 6
дет в текущую единицу работы. Сообщение останется в очереди, но будет недоступно
остальным приложениям для извлечения, пока не будет произведен вызов функции
MQCMIT.
Примечание. При написании приложений, которые извлекают постоянные
сообщения с критичными для бизнеса данными по клиентским соединениям, рекомендуем вызывать функцию MQGET под управлением точки синхронизации,
вслед за которой использовать вызов MQCMIT. Это защитит сообщение от потери
при сбое в линии связи между приложением и менеджером, который может
произойти во время передачи менеджером сообщения приложению по клиентскому подключению.
6.1.8. MQBEGIN
MQI-функция MQBEGIN применяется только в том случае, если менеджер очередей
сообщений настроен так, чтобы координировать глобальные единицы работы, вклю­
чающие операции в системе баз данных. При вызове функции MQBEGIN приложени­
ем в системе начинается новая единица работы, включающая обновления базы дан­
ных, корректно сконфигурированной для участия в координируемых WebSphere MQ
единицах работы, и вызовы MQPUT/MQGET, производимые под управлением точки
синхронизации.
Если координация единицы работы с участием WebSphere MQ осуществляется внеш­
ним менеджером транзакций, то для начала единицы работы приложению нужно
обратиться к этому менеджеру.
Глобальные единицы работы мы обсуждали в разделе 4.5.5 «Глобальные единицы
работы».
6.1.9. MQCMIT и MQBACK
MQI-функция MQCMIT предназначена для фиксации текущей единицы работы.
Локальная единица работы, включающая только операции WebSphere MQ, содержит
все вызовы функций MQPUT и MQGET под управлением точки синхронизации, про­
изведенные с момента подключения приложения или последнего вызова MQCMIT
или MQBACK. Глобальная единица работы, которая координируется WebSphere MQ и
где содержатся операции в системе баз данных и WebSphere MQ, содержит все вызо­
вы MQPUT и MQGET под управлением точки синхронизации с момента последнего
обращения к MQBEGIN, MQCMIT или MQBACK.
MQI-функция MQBACK предназначена для отмены текущей единицы работы, кото­
рую образуют те же самые операции, что в случае с функцией MQCMIT. Отмена еди­
ницы работы аннулирует все операции, или производит откат. Изъятые с удалением
сообщения возвращаются в очередь, а размещенные – удаляются из нее, так и не став
доступными для других приложений.
Технические основы организации очередей сообщений
117
6.1.10. MQINQ и MQSET
MQI-функция MQINQ служит для получения значений заданных атрибутов объектов,
открытых в целях их запроса.
На вход функции MQINQ передается совокупность селекторов (selectors). Она содер­
жит названия всех атрибутов, запрос значений которых осуществляется.
Для размещения значений, возвращаемых функцией, ей также передается ряд буфе­
ров, подразделяемых на буферы для хранения символьных (строковых) атрибутов,
например описаний, и буферы для хранения числовых (целочисленных) атрибутов,
таких как глубина очереди.
MQI-функция MQSET служит для установки значений заданных атрибутов объектов,
открытых для их задания.
Входные параметры MQSET – набор селекторов и буферы с новыми значениями
атрибутов.
6.1.11. MQDISC
Вызов функции MQDISC должен сопровождать каждый вызов MQCONN и MQCONNX
со стороны приложения. Если приложение не смогло произвести обращение к
MQDISC перед своим закрытием или было аварийно завершено, WebSphere MQ очи­
щает соединение, обнаружив, что приложение больше не выполняется.
Если WebSphere MQ координирует локальные или глобальные единицы работы, при
выполнении MQDISC менеджер предпринимает попытку вызова MQCMIT. Если вызов
функции MQCMIT завершается неудачно, приложение уведомляется об этом кодом
возврата функции MQDISC. Если перед своим закрытием приложение не выполнит
MQDISC, менеджер очередей произведет вызов функции MQBACK, обнаружив, что
приложение больше не выполняется.
6.2. Очереди
Понятие «очередь» (queue) встречается в терминологии WebSphere MQ довольно час­
то. Однако в разных контекстах оно имеет неодинаковые значения.
 Объект-очередь.
Объекты-очереди – объекты, определенные в составе менеджера очередей сооб­
щений. При выполнении над менеджером функции MQOPEN могут определяться
своим названием. Для описания и настройки служат MQSC или WebSphere MQ
Explorer.
Объекты-очереди бывают нескольких типов. Они могут представлять саму оче­
редь, содержащую сообщения, или метод поиска пункта назначения другой оче­
реди в инфраструктуре WebSphere MQ.
Объекты-очереди всех типов могут отображаться MQSC, имея общий тип QUEUE.
Подробнее каждый тип очереди мы рассмотрим ниже в этом разделе.
118
Глава 6
 Очередь сообщений.
Реально представлять очередь, которая входит в менеджер и может содержать сооб­
щения, способен лишь один тип объекта – объект «локальная очередь» (local queue).
Особый случай локальной очереди – транспортная очередь, которая служит про­
межуточной очередью, объединяющей менеджеры.
В составе менеджеров локальные очереди могут быть определены явно.
Кроме того, они могут быть определены динамически – на базе объектов модельных очередей (model queue) посредством вызова MQOPEN с названием модельной
очереди в роли параметра. Обычно определенные динамически локальные очере­
ди носят название динамических (dynamic queues). Они удаляются при вызове
MQCLOSE. Временные динамические очереди могут автоматически удаляться
менеджером очередей сообщений и при отключении приложения.
 Известный локальному менеджеру кластерный экземпляр очереди.
В большинстве случаев их называют кластерными очередями сообщений (cluster
queues). Кластерная очередь – не настоящий объект-очередь под управлением
локального менеджера, а локальное – по отношению к менеджеру – представление
экземпляра объекта-очереди, существующего в любой точке кластера. Фактический
объект-очередь может находиться под управлением локального менеджера, а может
располагаться и на другом менеджере очередей в кластере. В составе менеджера
с одним и тем же названием может существовать множество кластерных очередей
сообщений. Подробнее кластеры менеджеров очередей и кластерные очереди
сообщений мы обсудим в главе 8 «Кластеры менеджеров очередей».
Примечание. Все описанные ниже в этом разделе объекты-очереди имеют в
кластере менеджеров специальное назначение и служат, в том числе, для того,
чтобы соединить между собой кластеры менеджеров очередей сообщений или
подключить кластер к инфраструктуре, где кластеры не используются.
Заметим, что применение кластеров при создании новой инфраструктуры
WebSphere MQ может устранить множество требований, которые предъявляются к
этим типам объектов, а значит, упростить их администрирование. Подробнее о
кластерах менеджеров очередей сообщений читайте в главе 8 «Кластеры менеджеров очередей». 6.2.1. Разрешение названия очереди
При отправке сообщения из приложения местом назначения сообщения может
являться очередь под управлением того же самого менеджера, к которому подключе­
но приложение. Однако им может быть и другой менеджер очередей сообщений в
инфраструктуре WebSphere MQ. Менеджер, к которому подключено приложение,
должен знать, как направлять сообщения этому удаленному менеджеру. Больше того,
в его составе должна быть очередь временного хранения сообщений, передаваемых
к месту своего назначения, – транспортная очередь.
Между тем менеджером, к которому подключено приложение, и местом назначения
сообщения может находиться несколько промежуточных менеджеров. Каждый
Технические основы организации очередей сообщений
119
менеджер на маршруте движения сообщения выбирает очередную целевую точку
маршрута независимо от других. При этом он руководствуется своим собственным
знанием инфраструктуры. Оно заключено в определенных на этом менеджере объ­
ектах WebSphere MQ и может быть дополнено знаниями, полученными от других
менеджеров, входящих в этот же кластер.
Процесс определения очередного пункта доставки сообщения на маршруте по пре­
доставленным приложением сведениям о месте назначения сообщения называется
разрешением названия очереди (queue name resolution). Он производится менедже­
ром очередей сообщений при каждом получении сообщения от приложения или
другого менеджера.
Разрешение названия очереди выполняется и при каждом вызове MQOPEN для
открытия очереди перед размещением сообщений. При этом, используя данные из
структуры MQOD , переданной при вызове MQOPEN, – название объекта и название
менеджера очередей объекта, – менеджер очередей сообщений пытается восстано­
вить название нужной целевой очереди и менеджера для данного сообщения.
После разрешения названия очереди приложение может помещать в нее сообщения для
отправки по установленному месту их назначения, используя вызовы MQPUT. В итоге
при размещении сообщения менеджер совершает одно из перечисленных действий.
 Если при разрешении названия оказалось, что очередь назначения локальна по
отношению к данному менеджеру, то сообщение размещается непосредственно
в ней.
 Если при разрешении названия оказалось, что место назначения сообщения свя­
зано с другим – известным текущему – менеджером, то сообщение размещается
в транспортной очереди для отправки этому известному менеджеру. Данный шаг
требует включения в сообщение дополнительной информации, дабы при дости­
жении им удаленного менеджера название очереди могло быть снова разрешено.
Эту информацию называют заголовком транспортной очереди. О том, что про­
исходит с сообщением после размещения в транспортной очереди, читайте
в разделе 7.4.1 «Отправка сообщений».
Графическая схема разрешения названия приведена на рис. 6.1. Все типы объектовочередей, показанные на нем значками в прямоугольнике «Разрешение названия
очереди», будут описаны нами в этой главе. Обратите внимание, что значки на рис.
6.1 полностью соответствуют тем, что служат для представления объектов каждого
типа в WebSphere MQ Explorer.
Объекты различных типов по-разному влияют на разрешение названия очереди.
Иллюстрацией этого станут приведенные в следующих разделах аналогичные рисун­
ки для объектов всех типов. На них будут продемонстрированы условия, в которых
место назначения сообщения определяется тем, как именно объект конкретного
типа описан в составе менеджера, к которому подключено приложение.
Примечание. Влияние вхождения менеджера в кластер на разрешение
названия очереди мы обсудим в разделе 8.1.7 «Совместный доступ к объектамочередям в кластерах».
120
Глава 6
Рис. 6.1. Разрешение названия очереди
6.2.2. Объекты локальных очередей и транспортные очереди
Объекты локальных очередей – единственный тип объектов-очередей, представляю­
щих реальную очередь, содержащую сообщения. Объекты локальных очередей могут
описываться вручную, – о чем мы расскажем в этом разделе, или быть созданы дина­
мически – в соответствии с процедурой из раздела 6.2.4 «Объекты модельных очере­
дей и динамическое создание локальных очередей сообщений».
Коль скоро содержать сообщения могут только объекты локальных очередей, их
применение многогранно. В этой книге объекты локальных очередей – это чаще
всего локальные очереди системы, поскольку именно ими в ней и представлена
реальная очередь сообщений.
Простым примером применения локальной очереди является организация асин­
хронной коммуникации нескольких приложений на одной и той же машине. Исполь­
зуя одну локальную очередь, они могут размещать в ней сообщения и извлекать их
оттуда.
Все остальные типы объектов-очередей могут рассматриваться как способы построе­
ния локальной очереди, разрешения названий и месторасположения локальных оче­
редей либо маршрутизации сообщений между локальными очередями системы.
Технические основы организации очередей сообщений
121
Рис. 6.2 показывает, как приложение размещает сообщение в локальной очереди.
Здесь разрешение названия очереди буквально переводит указанное название объекта в название локальной очереди при помощи описанного объекта локальной оче­
реди системы.
Информация о получателе (заданная в MQOPEN):
Queue_Name
Название объекта:
Название менеджера очередей объекта: Пусто или название локального менеджера
Сообщение
Разрешение названия очереди
в присутствии объекта локальной очереди
Объект – локальная очередь Queue_Name
Место назначения
локально
Сообщение
Менеджер
очередей сообщений
Очереди,
определенные локально
Очередь Queue_Name
Рис. 6.2. Разрешение названия очереди в присутствии объекта локальной очереди
Транспортные очереди
Атрибут USAGE объекта локальной очереди системы может использоваться, чтобы
пометить локальную очередь как транспортную очередь. Для этого атрибут USAGE
локальной очереди сообщений принимают равным XMITQ.
Если локальная очередь помечается как транспортная, приложения должны отказать­
ся от попыток размещать в ней сообщения напрямую.
Передача сообщений из транспортной очереди удаленному менеджеру производится
по каналу сообщений. Каналы сообщений мы обсудим в разделе 7.4.1 «Отправка
сообщений».
Определение транспортной очереди обеспечивает менеджер очередей информаци­
ей, как именно направлять сообщения менеджеру целевой очереди. Все сообщения с
тем же названием менеджера очередей объекта, что и название транспортной оче­
реди, помещаются в эту очередь, так что названия транспортной очереди и удален­
122
Глава 6
ного менеджера должны – в общем случае – совпадать. Впрочем, если название
менеджера не соответствует названию транспортной очереди, описанные в разделе
6.2.5 «Объекты удаленных очередей» объекты удаленных очередей позволяют задать
маршрут явно.
Примечание. Для передачи сообщений, являющихся ответом или отчетом,
используется поле ReplyToQMgr дескриптора исходной дейтаграммы или запроса.
Если менеджер очередей не знает, как направлять сообщения менеджеру очереди ответов, отправить ответ окажется невозможно.
Чтобы менеджер очередей получил сведения о порядке маршрутизации, опишите
одноименную менеджеру очереди ответов транспортную очередь. Рис. 6.3 показывает, как приложение отправляет сообщение и указывает название
менеджера очередей объекта. С ним совпадает название транспортной очереди, а
значит, именно в ней сообщение и будет размещено.
Рис. 6.3. Разрешение названия очереди в присутствии транспортной очереди
Ручное задание локальных объектов
Принадлежащий локальной очереди атрибут «тип определения» (DEFTYPE – definition
type) дает возможность разделить все локальные очереди на те, которые описывались
Технические основы организации очередей сообщений
123
вручную, и те, что динамически сформированы из объектов модельных очередей.
Атрибут «тип определения» (DEFTYPE) вручную созданных локальных очередей имеет
значение PREDEFINED.
Примечание. Атрибут «тип определения» (DEFTYPE) не проводит различий
между локальными очередями, которые автоматически созданы WebSphere MQ
при организации менеджера, и очередями, которые создал администратор.
Создать локальные очереди вручную можно, используя один из перечисленных
методов.
 При помощи MQSC-команды DEFINE QLOCAL.
 При помощи WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Queues конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Local Queue;
c) следуйте указаниям мастера New Local Queue.
6.2.3. Объекты псевдонимов очередей
Объекты псевдонимов очередей являются представлениями других целевых объектов
очередей, имеющих другие названия. Обращение к псевдониму очереди аналогично
доступу к целевой очереди, чьим псевдонимом она является. Ссылки на псевдоним оче­
реди переправляются целевой очереди, заданной как элемент описания псевдонима.
Атрибут «целевая (базовая) очередь» псевдонима (TARGQ – target queue, base queue)
содержит имя целевого объекта-очереди.
Этот целевой объект-очередь должен иметь один из следующих типов.
 Локальная очередь, заданная на том же менеджере очередей сообщений, что
и псевдоним очереди.
 Удаленная очередь, заданная на том же менеджере очередей сообщений, что
и псевдоним очереди.
 Экземпляр очереди, общий для того кластера менеджеров очередей сообщений,
в который входит текущий менеджер. Обсуждению кластеров посвящена глава 8
«Кластеры менеджеров очередей».
Примечание. WebSphere MQ не требует, чтобы названию указанной при
описании или модификации псевдонима целевой очереди соответствовал существующий объект-очередь. Если целевой объект-очередь некорректен, попытки
вызова MQOPEN или маршрутизации сообщений через этот псевдоним закончатся
неудачно.
Рис. 6.4 показывает, как приложение размещает сообщение в локальной очереди
через псевдоним очереди. Запрошенное приложением название объекта при разре­
шении указывает на целевой объект – локальную очередь, как это и вытекает из
определения псевдонима.
124
Глава 6
Рис. 6.4. Р
азрешение названия очереди в присутствии объекта псевдонима очереди со ссылкой на локальную очередь
Описать псевдоним очереди можно, используя один из двух методов.
 При помощи MQSC-команды DEFINE QALIAS.
 При помощи WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Queues конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Alias Queue;
c) следуйте указаниям мастера New Alias Queue.
6.2.4. Объекты модельных очередей и динамическое создание
локальных очередей сообщений
Объекты модельных очередей содержат атрибуты объектов – локальных очередей,
которые могут создаваться приложением динамически. Очереди, которые построены
динамически, являются экземплярами локальных очередей и могут содержать сооб­
щения. В этой книге динамически созданный экземпляр локальной очереди сообще­
ний обычно назван динамической очередью.
Задача динамической очереди – стать временным объектом для приложения в инф­
раструктуре очередей сообщений WebSphere MQ. Самым распространенным приме­
ром ее использования является организация собственной очереди ответов для при­
Технические основы организации очередей сообщений
125
ложения при обмене сообщениями по принципу «запрос – ответ». Об этом шла речь
в разделе 4.6.14 «Реализация очереди ответов».
Приложение может динамически создать локальную очередь, просто указав имя объ­
екта модельной очереди как название объекта в структуре MQOD , передаваемой
MQOPEN. Название созданной локальной очереди сообщений не связано с названием
объекта модельной очереди.
Название динамической очереди выбирается приложением, вызвавшим MQOPEN.
Для этого в MQOD входит поле «название динамической очереди» (DynamicQName).
В конце поля названия в составе MQOD можно указать символ маски. Он вынуждает
менеджер очередей самостоятельно создать остальную часть ее имени. Это имя уни­
кально в пределах менеджера. Для обеспечения уникальности всех 48 символов
названия объекта-очереди размещать маску после 33-го символа в поле названия
динамической очереди нельзя.
По умолчанию поле названия динамической очереди в MQOD принимает следующие
значения.
 В WebSphere MQ для z/OS:
CSQ.*
 В WebSphere MQ для всех прочих платформ:
AMQ.*
После того как динамическая очередь создана, обращаться к ней можно так же, как и
к локальной очереди, которая формировалась вручную. Приложения должны посы­
лать такой очереди сообщения, используя ее динамически созданное название, а не
название объекта модельной очереди.
Существует два разных типа динамических локальных очередей. Атрибут «тип опре­
деления» (DEFTYPE) объекта модельной очереди указывает, какого типа динамическая
очередь создается, если открыть упомянутый модельный объект. Тип динамической
очереди влияет на то, как ею можно будет воспользоваться и когда менеджер очере­
дей ее удалит. Существующие типы задания перечислены ниже.
 Динамический временный (TEMPDYN).
Временная динамическая локальная очередь может содержать только непостоян­
ные сообщения. Причина этого в том, что менеджер очередей сообщений может
автоматически ее удалить. При этом не сохранится ни одно сообщение, которое в
ней окажется. Временная динамическая локальная очередь удаляется менеджером
при следующих условиях:
– если приложение выполняет функцию MQCLOSE с описателем объекта (Hobj),
полученного как результат вызова MQOPEN, создавшего эту очередь;
– если приложение отключается от менеджера вызовом MQDISC;
– после обнаружения менеджером закрытия приложения, если то завершилось
без выполнения MQDISC;
– при перезапуске менеджера.
 Динамический постоянный (PERMDYN).
Постоянная динамическая локальная очередь может содержать как постоянные,
так и непостоянные сообщения. Такие очереди не удаляются менеджером очере­
126
Глава 6
дей сообщений автоматически. Вручную постоянную динамическую локальную
очередь можно удалить следующим образом:
– вызовом MQCLOSE с опцией удаления (MQCO_DELETE) из приложения, не обяза­
тельно создавшего очередь изначально вызовом MQOPEN. Успешно вызов
функции MQCLOSE завершится лишь при пустой очереди;
– вызовом MQCLOSE с опцией удаления и очистки (MQCO_DELETE_PURGE) из прило­
жения, не обязательно создавшего очередь изначально вызовом MQOPEN.
Вызов функции MQCLOSE будет успешным даже при непустой очереди. Одна­
ко он завершится с ошибкой, если в составе очереди имеются сообщения, раз­
мещенные в ней или извлеченные из нее в рамках единицы работы, которая
еще не зафиксирована, но и не аннулирована, – такие сообщения относят к
незафиксированным;
– удалением объекта-очереди из интерфейса администрирования, такого как
WebSphere MQ Explorer или MQSC.
Для описания объектов модельных очередей используйте один из следующих методов:
 Выполните MQSC-команду DEFINE QMODEL.
 В WebSphere MQ Explorer:
a) Щелкните правой кнопкой мыши по папке Queues конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) Выберите в меню New → Model Queue;
c) Следуйте указаниям мастера New Model Queue.
6.2.5. Объекты удаленных очередей
Объекты удаленных очередей служат для описания маршрутов к другим менеджерам
очередей сообщений в инфраструктуре WebSphere MQ. В описание входит отображение
названий менеджеров на транспортные очереди и названий очередей – на имена других
различных очередей под управлением удаленных менеджеров очередей сообщений.
Для объектов удаленных очередей есть три способа применения.
 Как локальное определение удаленной очереди сообщений.
С его помощью приложение может открыть удаленный объект-очередь для того,
чтобы помещать в эту очередь сообщения, явно не указывая название удаленного
менеджера очередей, то есть аналогично тому, как оно помещает их в локальную
очередь. В этом случае удаленным объектом-очередью можно воспользоваться
затем, чтобы разместить очередь в составе удаленного менеджера, не внося изме­
нений в приложение, созданное для работы с очередью локальной. Чтобы сфор­
мировать локальное определение удаленной очереди сообщений, создайте объект
типа «удаленная очередь» с атрибутами, которые перечислены ниже.
– Название объекта «удаленная очередь».
Название очереди, в которую подключенные к менеджеру очередей приложе­
ния помещают свои сообщения.
– Удаленное имя (RNAME).
Название очереди, которой управляет целевой менеджер. Может полностью
совпадать с названием объекта «удаленная очередь». Данное название очереди
используется при разрешении названия очереди на удаленной машине.
Технические основы организации очередей сообщений
127
– Название удаленного менеджера очередей сообщений (RQMNAME).
Название, которое имеет целевой менеджер, не обязательно являющийся оче­
редным менеджером маршрута. Данное название менеджера используется при
разрешении названия очереди на удаленной машине.
– Транспортная очередь (XMITQ).
Содержит название транспортной очереди, которая передает сообщения оче­
редному менеджеру маршрута к месту их назначения. Если удаленный менед­
жер очередей имеет то же название, что и транспортная очередь, атрибут
может не заполняться.
Рис. 6.5 показывает, как приложение посылает сообщение, пользуясь локальным опи­
санием очереди на удаленной машине. Название объекта, которое указано приложе­
нием, – это название объекта «удаленная очередь». При разрешении названия очере­
ди сообщение будет размещено в заданной в описании удаленной очереди сообще­
ний транспортной очереди. К сообщению при передаче будет прикреплен заголовок
транспортной очереди с атрибутами, взятыми из описания объекта «удаленная оче­
редь». Ими станут удаленное имя и название удаленного менеджера очередей сообщений. Когда сообщение достигнет места своего назначения, информация из заголовка
транспортной очереди послужит для разрешения названия очереди
в составе удаленного менеджера.
Рис. 6.5. Разрешениеназвания очереди в присутствии локального определения удаленной очереди сообщений
128
Глава 6
 Как псевдоним менеджера очередей сообщений.
Служит для того, чтобы менеджер получил сведения о маршруте, ведущем к менед­
жеру целевой очереди. Применяется, если название менеджера целевой очереди
отлично от названия используемой для направления сообщений этому менеджеру
транспортной очереди. Также псевдонимы такого рода могут использоваться в
целях отображения одного названия менеджера очередей на другое. Частным
случаем этого является отображение на пустое название, которое обозначает
локальный менеджер очередей или выступает как признак необходимости балан­
сировки нагрузки при работе с кластером менеджеров.
– Название объекта «удаленная очередь».
Название менеджера очередей сообщений, для которого формируется псевдо­
ним. В тех случаях, когда указанное название менеджера очередей объекта
совпадает с названием объекта «удаленная очередь», он служит для разрешения
названия.
– Удаленное имя (RNAME).
Применительно к псевдониму атрибут должен быть незаполнен.
– Название удаленного менеджера очередей сообщений (RQMNAME).
Название менеджера целевой очереди, не обязательно очередного менеджера
маршрута. После направления сообщения очередному менеджеру маршрута с
использованием указанной транспортной очереди данное название менедже­
ра используется при разрешении названия. Может оставаться пустым для ука­
зания необходимости в разрешении названия очереди аналогично тому, как
если бы название менеджера не было указано вовсе.
– Транспортная очередь (XMITQ).
Содержит название транспортной очереди, которая передает сообщения оче­
редному менеджеру маршрута к месту их назначения. Если удаленный менед­
жер очередей имеет то же название, что и транспортная очередь, атрибут
может не заполняться. Также он может не заполняться при описании псевдо­
нима для локального менеджера.
Рис. 6.6 показывает, как приложение посылает сообщение, используя псевдоним
менеджера очередей сообщений. Название менеджера очередей объекта, которое
указано приложением, преобразуется в другое название менеджера, для доставки
которому сообщение будет размещено в транспортной очереди.
Технические основы организации очередей сообщений
129
Рис. 6.6. Разрешениеназвания очереди в присутствии псевдонима менеджера очередей сообщений
 Как псевдоним очереди ответов.
Псевдоним очереди ответов служит для настройки маршрутов, которыми ответы
перемещаются к менеджеру по компонентам инфраструктуры. Влияет на название
менеджера очереди ответов в дескрипторе сообщения при размещении сообще­
ния приложением, но не на разрешение названия очереди при открытии таковой.
Применение псевдонимов очереди ответов выходит за рамки книги. Подробнее
об этом см. руководство WebSphere MQ Intercommunication, SC34-6587.
Для описания объектов удаленных очередей используйте один из следующих прие­
мов.
 MQSC-команду DEFINE QREMOTE.
 В WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Queues конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Remote Queue;
c) следуйте указаниям мастера New Remote Queue.
130
Глава 6
6.2.6. Атрибуты по умолчанию и контроль полномочий
При открытии очереди WebSphere MQ производит проверку прав, определяя, упол­
номочена ли сущность выполнять действия, которые запросила. К обсуждению этой
темы мы вернемся в разделе 11.2 «Предоставление доступа к ресурсам менеджеров
очередей».
Также WebSphere MQ задает ряд значений по умолчанию для сообщений, которые
впоследствии будут посланы открывшим очередь приложением. В дальнейшем при­
ложение вправе заменить эти значения на свои собственные.
Такой контроль полномочий и значения по умолчанию основаны на атрибутах и
разрешениях единственного объекта WebSphere MQ. Его можно считать первым сре­
ди объектов WebSphere MQ, к которым производится доступ при разрешении опре­
деленного приложением названия очереди.
Объект, который используется при отправлении сообщений, зависит от сочетания
названий объекта и менеджера очередей объекта. Возможные комбинации показаны
в табл. 6.1. В их число входят и сочетания для кластеров менеджеров очередей сооб­
щений. Речь о таких кластерах пойдет в главе 8 «Кластеры менеджеров очередей».
Табл. 6.1. О
бъект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий
Название объекта
Название менеджера Объект WebSphere MQ для установки значений
очередей объекта
по умолчанию и проверки наличия полномочий
Название объекта –
локальной, модельной,
удаленной очереди или
их псевдонима, опреде­
ленное на локальном
менеджере очередей
сообщений
Пусто или назва­
ние локального
менеджера
Любое
Название удален­ Транспортная очередь
ного менеджера,
при разрешении
которого может
быть установле­
но название
транспортной
очереди
Название очереди, сов­
местно используемой
тем кластером менедже­
ров очередей сообще­
ний, в который входит
текущий менеджер
Пусто
Объект WebSphere MQ, имеющий задан­
ное название
Проверка наличия полномочий произ­
водится в отношении объекта
SYSTEM.CLUSTER.TRANSMIT.QUEUE
Источником значений по умолчанию
является определение объекта-очереди
под управлением удаленного менедже­
ра. Значения по умолчанию можно уви­
деть, отобразив атрибуты записи клас­
терной очереди, к примеру воспользо­
вавшись командой DISPLAY QCLUSTER
из состава MQSC
Технические основы организации очередей сообщений
131
Постоянство по умолчанию
Одним из часто используемых атрибутов объектов-очередей является атрибут посто­
янства по умолчанию (DEFPSIST – default persistence). Установить, будет ли сообщение
постоянным, приложение может при его размещении, задав параметр вызова MQPUT.
Выбрав иной подход, приложение может оставить определение постоянства сообще­
ний на откуп атрибуту соответствующей очереди.
Предположим, менеджер управляет локальной очередью local.psist с атрибутом
DEFPSIST(YES). Пусть им же управляется псевдоним очереди alias.nonpsist с параметра­
ми DEFPSIST(NO) и TARGQ(‘local.psist’) . Сообщение, размещенное в очереди после
открытия local.psist, окажется постоянным. Сообщение, размещенное после откры­
тия alias.nonpsist, будет непостоянным. Между тем оба сообщения будут помещены в
одну очередь.
Примечание. Приведенная ситуация лишь пример, не являющийся рекомендуемой практикой. Наибольшую эффективность WebSphere MQ демонстри­рует
при условии, что в очереди содержатся исключительно постоянные или непо­
стоянные сообщения.
6.2.7. Состояние и онлайновый мониторинг очередей
Локальные очереди – важнейший контролируемый менеджером ресурс, поскольку
именно в них находятся все сообщения, которые он содержит.
Наблюдая за действиями обращающихся к менеджеру очередей приложений или
выявляя проблемы, связанные с работой последних, администратор подчас испыты­
вает потребность в сведениях о том, как происходит доступ приложений к конкрет­
ным очередям. Информация о потоке сообщений через определенную очередь также
может оказаться полезной в обнаружении и разрешении проблем или при контроле
производительности в ходе распределения ресурсов.
Удовлетворяя эту потребность, WebSphere MQ предоставляет данные мониторинга
о состоянии каждой располагающейся на менеджере локальной очереди сообщений.
В совокупности эти сведения, значительно расширенные в WebSphere MQ V6.0, таковы.
 Количество находящихся в очереди сообщений.
 Количество приложений, открывших очередь для просмотра или извлечения
сообщений.
 Дата и время последнего извлечения приложением сообщения из очереди.
 Количество приложений, открывших очередь для размещения сообщений.
 Дата и время последнего размещения приложением сообщения в очереди.
 Количество находящихся в очереди незафиксированных сообщений. Таковыми
считаются сообщения, которые были помещены в очередь или извлечены из нее в
рамках незавершенной единицы работы.
 Сведения о каждом соединении с менеджером открывшего очередь приложения,
включая:
– название приложения, которое установило соединение;
– идентификатор процесса приложения;
132
Глава 6
– контекст идентификационных данных, в котором выполняется приложение;
– действия, для выполнения которых приложение открыло очередь: просмотр
сообщений, извлечение, размещение или запрос;
– если соединение с менеджером является удаленным и происходит по клиент­
скому подключению, то информация об указанном подключении;
– признак активности; выполняет ли приложение работу с менеджером;
 Информация о производительности использующих очередь приложений. В нее
в том числе, входят:
– кратко- и долгосрочная оценка среднего времени, которое сообщение прово­
дит до извлечения из очереди. дается в микросекундах, поскольку срок пребы­
вания сообщения в очереди может быть очень мал;
– наибольший срок пребывания в очереди еще не покинувшего ее сообщения в
секундах. в очередях с быстрым потоком сообщений большое значение может
указывать на проблему с обработкой одного из поставленных в очередь сооб­
щений.
Примечание. Полученная в ходе контроля очередей информация о производительности является новшеством WebSphere MQ V6.0 и называется информацией
онлайнового мониторинга (online monitoring). Используя атрибут MONQ объектаменеджера очередей сообщений, вы можете наблюдать за всеми очередями,
которыми менеджер управляет; используя же атрибут MONQ очереди – за требуемым набором локальных очередей. Подробности см. в руководстве Monitoring
WebSphere MQ, SC34-6593. Или нажмите клавишу F1 и выберите раздел Online
Monitoring страницы свойств, предварительно выделив менеджер очередей
сообщений в WebSphere MQ Explorer.
Чтобы просмотреть информацию о состоянии очередей, используйте один из двух
методов.
 MQSC-команду DISPLAY QSTATUS.
 WebSphere MQ Explorer. Обычно этот способ просмотра самый удобный:
a) щелкните по папке Queues конкретного менеджера очередей сообщений
в навигаторе WebSphere MQ Explorer;
b) щелкните правой кнопкой мыши по интересующей вас локальной очереди
таблицы, представленной на панели содержимого Queues;
c) выберите пункт меню Status.
6.3. Применение триггеров
Поступающие в очереди сообщения представляют происходящие в системе события.
В большинстве случаев эти сообщения требуют обработки.
Для автоматического запуска обработки менеджером очередей сообщений в
WebSphere MQ предусмотрен механизм «триггеринга» (triggering). По характеру
обработки ею может являться открытие канала передачи сообщений из транспорт­
ной очереди удаленному менеджеру или инициирование работы экземпляра прило­
Технические основы организации очередей сообщений
133
жения для того, чтобы произвести действие над одним или несколькими сообщения­
ми (пакетом).
С учетом назначения очереди приходящее в нее сообщение может представлять или
не представлять событие, которое требует обработки. Саму очередь можно настроить
на порождение триггерных событий (trigger events), соответствующих тому, для
каких целей она используется.
6.3.1. Порождение триггерных событий
На порождение триггерных событий очередь можно настроить различным образом.
 Для каждого сообщения.
Триггерное сообщение будет порождено для каждого поступающего в очередь
сообщения. Для выбора такого режима триггеринга в локальной очереди сообще­
ний задайте следующие параметры:
– активируйте триггеры: TRIGGER;
– установите тип триггера «для каждого сообщения»: TRIGTYPE(EVERY).
 Для первого сообщения.
Триггерное событие порождает первое сообщение, поступающее в очередь после
того, как она опустеет. Обычно триггерное событие возникает, если для извлече­
ния сообщений очередь открывается каким бы то ни было приложением. Однако
если через указанный триггерный интервал приходит сообщение, а ни одно при­
ложение не открыло очередь на извлечение, то возникнет новое триггерное
событие. Для выбора такого режима работы триггеринга в локальной очереди
сообщений задайте следующие параметры:
– активируйте триггеры: TRIGGER;
– установите тип триггера «для первого сообщения»: TRIGTYPE(FIRST);
– установите являющийся атрибутом объекта-менеджера очередей сообщений
триггерный интервал, равный необходимому вам значению в миллисекундах:
TRIGINT(5000).
 Для заданной глубины.
Триггерное событие порождает то сообщение, при поступлении которого общее
количество сообщений, находящихся в очереди, становится выше определенного
порогового значения. Триггерное событие не возникает, если есть приложение,
открывшее эту очередь для извлечения сообщений. Чтобы настроить этот меха­
низм триггеринга, задайте следующие атрибуты локальной очереди:
– активируйте триггеры: TRIGGER;
– установите тип триггера «для заданной глубины»: TRIGTYPE(DEPTH);
– установите требуемый порог глубины очереди: TRIGDPTH(10).
134
Глава 6
Примечание. Для того чтобы триггерное событие произошло, должна быть
выполнена совокупность условий. Если триггерное событие не возникает, как
запланировано, рекомендуем поочередно проверить выполнение всех условий,
что даст возможность установить причину вашей проблемы. Полностью условия
перечислены в разделе «Starting WebSphere MQ applications using triggers»
руководства WebSphere MQ Application Programming Guide, SC34-6595. 6.3.2. Очереди инициации и триггерные сообщения
Когда в системе происходит триггерное событие, в очередь ининциации (initiation
queue) помещается сообщение. Это сообщение называется триггерным сообщением
(trigger message). Название очереди, в которой будет размещено триггерное сообще­
ние, содержится в атрибуте «очередь инициации» (INITQ) объекта – локальной очере­
ди сообщений.
Как очередь инициации может быть обозначена любая из локальных очередей. Для
того чтобы назначить ей эту роль, особой настройки локальной очереди не нужно.
Единственное условие – такая очередь сообщений не может являться транспортной
очередью.
Любое триггерное сообщение содержит сведения о том действии, которое должно
быть выполнено в ответ на триггерное событие, и включает следующую информацию.
 Название очереди.
Название той очереди, откуда событие было порождено.
 Подробные данные о запускаемом приложении.
Подробности запуска приложений зависят от конкретной платформы. Для описа­
ния таковых в WebSphere MQ имеются объекты типа PROCESS. Их атрибуты содер­
жат достаточно информации для запуска конкретного приложения в операцион­
ной системе. Если в атрибуте PROCESS очереди, которая породила событие, содер­
жится название существующего объекта PROCESS, то все его атрибуты будут разме­
щены в триггерном сообщении.
 Данные триггера.
Специальные данные из атрибута «данные триггера» (TRIGDATA) очереди, породив­
шей событие.
6.3.3. Триггерный монитор
Приложения, ожидающие поступления сообщений в помеченную как очередь ини­
циации локальную очередь сообщений, называют триггерными мониторами (trigger
monitor).
Триггерные мониторы в WebSphere MQ
В составе WebSphere MQ есть триггерные мониторы для каждой платформы. Их функ­
ция – поддержка базовых возможностей выполнения приложений согласно опреде­
Технические основы организации очередей сообщений
135
лению PROCESS при каждом возникновении триггерного события. Его детальное опи­
сание передается приложению при запуске.
Подробнее о триггерных мониторах в WebSphere MQ читайте раздел “Writing Web
Sphere MQ applications” руководства WebSphere MQ Application Programming Guide,
SC34-6595.
Инициатор распределенных каналов WebSphere MQ
Инициатор распределенных каналов WebSphere MQ – это процесс WebSphere MQ, по
умолчанию автоматически запускаемый менеджером очередей сообщений. Это осо­
бый триггерный монитор, открывающий каналы сообщений с названиями, которые
содержатся в атрибутах TRIGDATA транспортных очередей, настроенных на примене­
ние триггеров. Подробности см. в разделе 7.4.13 «Инициирование канала».
Примечание. Не смешивайте инициатор каналов в этом разделе с инициатором каналов в WebSphere MQ для z/OS из раздела 5.3.10 «Инициатор каналов
WebSphere MQ для z/OS».
Открытие каналов сообщений в WebSphere MQ для z/OS и WebSphere MQ для
iSeries реализуют программы-слушатели каналов.
136
Глава 6
7
Взаимодействие менеджеров
очередей и клиентские подключения в WebSphere MQ
Эта глава описывает взаимодействие менеджеров очередей сообщений между собой
и с приложениями, в том числе удаленно подключенными как клиенты, а также связь
менеджеров по каналам сообщений.
В этой главе мы обсудим следующие вопросы:





Каналы
Запуск и останов каналов
Клиентские каналы
Распределенные каналы сообщений
Автоопределение каналов
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
137
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-интерфейс клиента.
138
Глава 7
Клиентский 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-вызова. Контекстом может являться
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
139
идентификатор пользователя, от чьего имени выполняется клиентское приложе­
ние (или агент-партнер), или принудительно выбран конкретный пользователь­
ский идентификатор, назначенный менеджером очередей сообщений на основе
атрибута канала.
 Ряд атрибутов канала должен быть согласован обоими MCA, что даст возможность
найти значения, приемлемые для каждого. Примером подобного атрибута служит
размер пакета, описанный в разделе 7.4.2 «Пакеты». Обычно атрибуты такого рода
являются числовыми и принимают меньшее из значений, предложенных каждым
из MCA.
На рис. 7.1 процесс установления канала двумя агентами MCA сведен воедино.
ы менеджера).
Рис. 7.1. Установлениеканала, соединяющего два менеджера или приложение с менеджером
7.2. Запуск и останов каналов
Запуск канала означает запуск агента для подключения к MCA удаленного менеджера
и установление канала. Остановом канала называют прекращение коммуникации
двух агентов, которые установили канал.
Клиентские каналы запущены, как только приложение подключено к менеджеру,
и остаются активными до его отключения.
Для запуска и останова соединяющих менеджеры каналов сообщений могут исполь­
зоваться команды MQSC START CHANNEL и STOP CHANNEL. Дополнительно они служат для
блокировки канальных объектов и ее снятия, а значит, определяют, могут с их помо­
щью запускаться каналы или нет.
140
Глава 7
Аналогичные функции доступны в 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
141
Примечание. В 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 знакам. Для упрощения
администрирования название канала должно адекватно отражать его назначение.
142
Глава 7
Если длина названий всех менеджеров очередей сообщений в системе не превыша­
ет 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
«Автоопределение каналов».
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
143
7.3.2. Канальные объекты серверных подключений
Канальный объект серверного подключения описывает название канала, которым
для подключения к менеджеру может пользоваться клиент, и атрибуты агента, кото­
рый управляет соединением.
Чтобы задать канальные объекты серверных подключений, используйте один из двух
методов.
 MQSC-команду DEFINE CHANNEL CHLTYPE(SVRCONN).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню 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,
не передают идентификатор пользователя агенту серверного подключения.
144
Глава 7
По этим причинам, как правило, мы советуем всем приложениям, которые под­
ключаются по каналу с определенным названием, назначать общий контекст иденти­
фикационных данных, для чего служит имеющийся у объекта-канала серверного
подключения атрибут «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.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
145
7.3.5. Канальные объекты клиентских подключений
Реализуемые WebSphere MQ объекты-каналы клиентских подключений являются еще
одним методом указания параметров подключения, включая такие более сложные
атрибуты, как конфигурация SSL.
Чтобы задать канальные объекты клиентских подключений, используйте один из
двух методов.
 MQSC-команду DEFINE CHANNEL CHLTYPE(CLNTCONN).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Client Connections конкретного
менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню 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.1. Обзорпорядка выбора канальных объектов клиентских подключений MCA клиента
Выбранное приложением
название менеджера очередей
сообщений
Описание порядка поиска соответствующих канальных объектов
клиентских подключений
Пустое
Соответствующими считаются объекты-каналы клиентских
подключений с пустым названием менеджера. Если, воспользовавшись
названием канала и атрибутами одного из канальных объектов такого
рода, с менеджером удается связаться, соединение успешно
формируется независимо от того, какое название менеджер имеет
в действительности
146
Глава 7
Окончание табл 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.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
147
Сейчас использование 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 «Раз­
решение названия очереди», менеджер размещает сообщение в транспорт­ной очере­
ди в результате разрешения названия очереди. По ходу разрешающей процедуры он
добавляет в заголовок транспортной очереди сообщения достаточно информации
для того, чтобы разрешение названия очереди произошло в тот момент, когда сооб­
щение достигнет менеджера очередей назначения.
Примечание. Издержки администрирования при описании распределенных
каналов можно уменьшить, если использовать кластер менеджеров очередей
сообщений.
148
Глава 7
7.4.1. Отправка сообщений
В состав любого распределенного канала сообщений входят два MCA, а значит, и два
канальных объекта – по одному для каждого менеджера. В зависимости от типа опи­
санного на менеджере объекта-канала сообщений каждый агент выполняет одну из
следующих ролей.
 MCA – отправитель.
Открывает определенную атрибутами канального объекта транспортную очередь
сообщений для монопольного извлечения. Сказанное означает, что никакие два
канала не могут быть настроены так, чтобы забирать сообщения из одной транс­
портной очереди. MCA-отправитель извлекает сообщения из транспортной оче­
реди и посылает их агенту-партнеру.
Примечание. Это утверждение не касается кластерных каналов сообщений,
которые коллективно пользуются единой транспортной очередью. Кластеры
менеджеров очередей сообщений мы обсудим в главе 8 «Кластеры менеджеров
очередей».
 MCA – получатель.
Получает сообщения от MCA-отправителя. В процессе своей работы удаляет
из каждого сообщения заголовок транспортной очереди и производит чтение
содержимого. Открывает указанную в заголовке транспортной очереди очередь
сообщений и помещает сообщение в эту очередь. Открытие очереди и размеще­
ние сообщения осуществляются с помощью стандартных вызовов MQI. Это
означает, что разрешение названия очереди на менеджере аналогично тому, как
если бы к нему подключилось непосредственно приложение, которое, руководс­
твуясь деталями заголовка транспортной очереди, разместило бы сообщение в
очереди самостоятельно. Если при разрешении названия на менеджере не удает­
ся установить допустимое место назначения сообщения, сообщение доставить
нельзя. Об этом мы еще скажем в разделе 7.4.11 «Ошибки доставки сообщений».
Заголовок транспортной очереди создается при разрешении названия очереди
на менеджере очередей сообщений, где выполняется MCA-отправитель, и служит для
размещения сообщения в очереди под управлением того менеджера, где работает
получатель. Заголовок содержит следующую информацию.
 Название удаленной очереди.
Название очереди назначения сообщения, полученное при выполнении на менед­
жере разрешающей процедуры. Пытаясь поместить сообщение в очередь удален­
ного менеджера, находящийся там агент указывает это название в структуре MQOD
при открытии очереди.
 Название удаленного менеджера.
Название менеджера, управляющего очередью назначения сообщения. Также
получается в ходе разрешающей процедуры и может не соответствовать названию
того менеджера, которому доставляется сообщение, – такое возможно, например,
в случае, если очередной менеджер-получатель не является местом назначения
сообщения.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
149
 Дескриптор исходного сообщения.
При добавлении заголовка транспортной очереди сообщение модифицируется.
К началу тела прибавляется заголовок исходного сообщения, дескриптор же
изменяется и описывает не данные сообщения, а заголовок транспортной очере­
ди. Однако, когда сообщение поступает в очередь назначения, оно должно кор­
ректно отражать то, что было послано изначально, в том числе и дескриптор.
Дескриптор исходного сообщения хранится в заголовке транспортной очереди и
используется агентом при размещении сообщения с удаленным заголовком
транспортной очереди на удаленном менеджере очередей сообщений.
Связь пары менеджеров очередей по каналу показана на рис. 7.2.
Рис. 7.2. Коммуникациядвух менеджеров очередей сообщений с использованием агентов отправителя и получателя
7.4.2. Пакеты
Для надежного обеспечения однократной доставки сообщений и агент-отправитель,
и агент-получатель должен иметь возможность гарантировать то, что сообщение не
потеряется, не окажется отправлено дважды и будет успешно получено MCA-получа­
телем.
150
Глава 7
С этой целью 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) к фиксации или откату в зависимости от действий, предпринятых
агентом-партнером. В целях автоматического разрешения неоднозначного состоя­
ния канала при его перезапуске оба агента поддерживают порядковые номера, свя­
занные с количеством успешно переданных по каналу сообщений.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
151
Неоднозначное состояние канала представлено значением 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)')
152
Глава 7
7.4.6. Объекты receiver-каналов
Объект receiver-канала задается на менеджере для определения атрибутов MCA-полу­
чателя, которому другие менеджеры очередей могут посылать сообщения.
Объект receiver-канала нельзя использовать для инициирования канала.
Для описания объектов receiver-каналов воспользуйтесь одним из двух методов.
 Командой MQSC DEFINE CHANNEL CHLTYPE(RCVR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Receiver Channel.
7.4.7. Объекты requester-каналов
Объект requester-канала задается на менеджере для определения атрибутов MCAполучателя, которому другие менеджеры очередей могут посылать сообщения.
Объект requester-канала можно использовать для инициирования канала.
Для описания объектов requester-каналов воспользуйтесь одним из двух методов.
 Командой MQSC DEFINE CHANNEL CHLTYPE(RQSTR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Requester Channel.
Обязательный атрибут – название соединения (CONNAME).
7.4.8. Объекты sender-каналов
Объект sender-канала задается на менеджере очередей сообщений для определения
атрибутов MCA-отправителя, который из указанной транспортной очереди может
посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один
агент sender-канала или server-канала.
Объект sender-канала можно использовать для инициирования канала.
Для описания объектов sender-каналов воспользуйтесь одним из двух методов.
 Командой MQSC DEFINE CHANNEL CHLTYPE(SDR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Sender Channel.
Обязательные атрибуты – название транспортной очереди (XMITQ) и название соеди­
нения (CONNAME).
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
153
7.4.9. Объекты server-каналов
Объект server-канала задается на менеджере очередей сообщений для определения
атрибутов MCA-отправителя, который из указанной транспортной очереди может
посылать сообщения другим менеджерам.
Одновременно активным для одной транспортной очереди может быть только один
агент sender-канала или server-канала.
Объект server-канала можно использовать для инициирования канала, если название
соединения входит в определение объекта. Если название соединения задано, гово­
рят, что объект server-канала определен полностью (fully qualified).
Для описания объектов server-каналов используйте один из двух методов.
 Команду MQSC DEFINE CHANNEL CHLTYPE(SVR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Server Channel.
Обязательный атрибут – название транспортной очереди (XMITQ).
Примечание. Не смешивайте объекты server-каналов и описанные в разде­-
ле 7.3.2 канальные объекты серверных подключений.
7.4.10. Допустимые пары объектов – распределенных
каналов сообщений
Агенты MCA, созданные из описанных канальных объектов, могут объединяться
с образованием канала лишь в некоторых сочетаниях. Допустимые комбинации
и порядок их применения мы рассмотрим в этом разделе главы.
Каналы sender-receiver
Такой канал может инициироваться лишь со стороны отправителя.
Для подключения к одному объекту receiver-канала в составе менеджера можно
использовать целый ряд объектов sender-каналов, описанных на различных менед­
жерах очередей сообщений.
Типичным является описание на менеджере единственного объекта – receiver-канала.
Для связи с упомянутым менеджером все менеджеры в составе инфраструктуры рас­
полагают sender-каналом, имеющим то же имя, что и receiver-канал.
Каналы requester-server
Каналы такого рода могут инициироваться на стороне requester-канала или – опцио­
нально – на стороне server-канала, если в нем определено полностью название
соединения.
154
Глава 7
Каналы 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)
объекта-менеджера. Вкратце эти шаги таковы.
1. Поскольку в силу своей природы часть сбоев доставки – например, нахождение
в очереди предельного количества сообщений – может не повторяться, MCAполучатель может попытаться разместить сообщение вновь. Количество повтор­
ных попыток размещения сообщения агентом определяется атрибутом «число
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
155
попыток на сообщение» (MRRTY – message retry) того объекта-канала, где описан
MCA-получатель. Интервал между попытками определяется атрибутом «таймер
попыток на сообщение» (MRTMR – message retry timer) этого же канала.
2. Если атрибут «очередь недоставленных сообщений» (DEADQ ) объекта-менеджера
очередей задан, MCA-получатель попытается открыть очередь, имеющую указан­
ное название. Если это ему удастся, к сообщению будет добавлен заголовок недо­
ставленного сообщения (MQDLH), и оно будет размещено в этой очереди.
Заголовок недоставленного сообщения содержит информацию об ошибке. В нее
входят название очереди и менеджера очередей сообщений из заголовка транс­
портной очереди. Также в заголовок недоставленного сообщения входит и код
причины, полученный при неудачной попытке открыть очередь для размещения
сообщения. Такие коды причин мы обсуждали в разделе 6.1.2 «Коды завершения
и причин».
3. Если для текущего менеджера очередь недоставленных сообщений не задана или
не существует, действие зависит от факта, используются ли для передачи сообще­
ний единицы работы. Как говорилось в разделе 7.4.2 «Пакеты», единицы работы
задействуются при передаче постоянных сообщений; применительно же к непос­
тоянным они используются лишь при задании нормальной (normal) скорости
работы канала.
Если для доставки сообщений единицы работы не применяются, непостоянное
сообщение аннулируется.
Если для доставки сообщений используются единицы работы, сообщение возвра­
щается в транспортную очередь на стороне отправителя. Канал, как было сказано
в разделе 7.2.1 «Понятие состояния канала», переходит в состояние RETRYING. При
этом он пытается доставить сообщение снова – каждый раз при повторении
перезапуска. Когда же заданное для канала количество повторных попыток будет
исчерпано, он перейдет в состояние STOPPED, и перезапуск канала должен произво­
диться вручную. Движение сообщений в канале будет прекращено, пока нельзя
будет доставить сообщение, не будет указана очередь недоставленных сообщений
для менеджера либо сообщение не будет вручную удалено из транспортной оче­
реди.
Примечание. Во избежание действий из шага 3 советуем вам описать
очереди недоставленных сообщений для всех без исключения менеджеров.
При создании любого менеджера формируется очередь SYSTEM.DEAD.LETTER.
QUEUE. В дальнейшем менеджер можно настроить так, чтобы использовать ее
как очередь недоставленных сообщений. Однако все очереди с префиксом
SYSTEM. в WebSphere MQ Explorer полезно скрыть, а потому подобной настройки
обычно рекомендуется избегать.
Убедитесь, что значение атрибута «предельная длина сообщения» очереди
недоставленных сообщений достаточно велико и ни одно сообщение, попав в очередь, не будет усечено.
156
Глава 7
7.4.12. Работа с очередью недоставленных сообщений
После того как очередь недоставленных сообщений менеджера описана, задумаемся
о направляемых в нее сообщениях. Чтобы гарантировать кратковременность нахож­
дения в ней сообщений – а в это время они не могут обрабатываться приложениями
системы, – нужны особые меры.
Выполнение действий над сообщениями, прибывшими в эту очередь, обычно назы­
вается обработкой очереди недоставленных сообщений.
Подходы к обработке данной очереди включают следующее.
 Регулярный просмотр администратором.
Прикрепляемый к сообщениям при постановке в эту очередь заголовок недостав­
ленных сообщений имеет формат, трудно воспринимаемый человеком. По этой
причине WebSphere MQ Explorer дает возможность вывода на экран отдельных
полей, образующих заголовок, в удобочитаемом представлении. Для доступа
к этой функции выполните следующие шаги:
a) выделите в навигаторе папку Queues менеджера очередей сообщений;
b) щелкните правой кнопкой мыши по очереди недоставленных сообщений
на панели содержимого Queues;
c) выберите в меню Browse Messages;
d) щелкните правой кнопкой по сообщению из таблицы;
e) выберите в меню Properties;
f) выберите раздел Dead-letter header.
 Выполнение действия по триггеру, который срабатывает всегда, как только в оче­
реди недоставленных сообщений появляются сообщения.
Пример такого постоянного действия – выполнение несложного приложения,
отсылающего электронное письмо администратору для того, чтобы тот смог сам
просмотреть очередь. Подробнее о триггерах см. раздел 6.3 «Применение тригге­
ров».
К разряду триггеров, которые можно использовать в данном случае, относятся:
– триггеры типа FIRST с большим, определенным для менеджера триггерным
интервалом. Они инициируют регулярное выполнение приложения, если в
очереди недоставленных сообщений имеются сообщения;
– триггеры типа EVERY . Они инициируют выполнение приложения всякий раз
при поступлении в очередь нового сообщения.
 Применение обработчика очереди недоставленных сообщений, входящего
в WebSphere MQ.
С учетом набора правил, настроенных при запуске обработчика, он может авто­
матически выполнять действия над сообщениями, прибывающими в очередь
недоставленных сообщений. Для ознакомления с обработчиком очереди недо­
ставленных сообщений из WebSphere MQ читайте руководство WebSphere MQ
Intercommunication, SC34-6587.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
157
 Применение обработчика очереди недоставленных сообщений собственной раз­
работки.
Если правил из обработчика очереди недоставленных сообщений, входящего
в 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 канальные объекты создавались автоматически.
158
Глава 7
Чтобы разрешить автоопределение каналов менеджера очередей сообщений, устано­
вите атрибут «автоопределение каналов» (CHAD – channel auto-definition) объектаменеджера в значение ENABLED.
7.5.1. Автоопределение клиентских каналов
Если приложение пытается подключиться к менеджеру очередей сообщений, исполь­
зуя клиентский канал, но соответствующий объект-канал серверных подключений с
требуемым названием в менеджере отсутствует, он создается автоматически.
После автоопределения канала объект-канал функционирует так, как будто создавал­
ся вручную. Атрибуты канального объекта серверных подключений основаны на
атрибутах автоматически формируемого менеджером очередей сообщений каналь­
ного объекта серверных подключений SYSTEM.AUTO.SVRCONN.
7.5.2. Автоопределение распределенных каналов сообщений
Если при попытке удаленного менеджера установить подключение, используя объ­
ект – sender-канала или полностью заданный объект – server-канала, соответствую­
щий receiver-канал или requester-канал с требуемым названием на менеджере отсутс­
твует, автоматически создается receiver-канал.
После автоопределения канала объект-канал функционирует так, как будто создавал­
ся вручную. Атрибуты объекта – receiver-канала основаны на атрибутах автоматиче­
ски формируемого менеджером очередей сообщений объекта receiver-канала SYSTEM.
AUTO.RCVR.
Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ
159
8
Кластеры менеджеров
очередей
Эта глава дает начальное представление о кластерах менеджеров очередей и показы­
вает, как, пользуясь ими, вы можете сократить объем работы по администрированию
инфраструктуры WebSphere MQ и получить дополнительные возможности, позволя­
ющие повысить готовность служб и сбалансировать нагрузку между несколькими
экземплярами службы в составе кластера.
В этой главе мы обсудим следующие вопросы:




Обзор понятий кластеризации
Просмотр сведений о репозиториях кластеров
Работа с менеджерами очередей в кластере
Балансировка нагрузки
Кластеры менеджеров очередей
161
8.1. Обзор понятий кластеризации
Все менеджеры очередей в кластере располагают сведениями о том, какими ресурса­
ми наделен кластер, причем ресурсы в его составе не требуют явного локального
описания. Добавлять в кластер новые ресурсы, например менеджеры и очереди,
которыми они управляют, вы можете динамически, автоматически делая их доступ­
ными для пользования всем менеджерам очередей сообщений, которые входят
в кластер.
Это дает возможность добавлять в кластер или удалять из него дополнительные
ресурсы аппаратуры с учетом меняющейся нагрузки на инфраструктуру очередей
сообщений WebSphere MQ.
Менеджер очередей может являться членом нескольких кластеров, что позволяет
подразделять компоненты инфраструктуры WebSphere MQ по характеру служб или
организовывать группы. Менеджеры могут выступать в роли связующего звена между
кластерами, а также между кластером и имеющейся инфраструктурой WebSphere MQ
на основе распределенных каналов сообщений.
Примечание. В процессе реализации новой инфраструктуры как базу для ее
построения рекомендуется использовать кластер.
Для получения присущих кластерам преимуществ в виде дополнительной баланси­
ровки нагрузки и высокой готовности существующая инфраструктура может расши­
ряться через создание связей между нею самой и расширенной инфраструктурой
на базе кластера.
Изложенное в данной главе представление о кластерах кому-то покажется изначаль­
но сложным для понимания. Однако эти идеи приведут нас к такой инфраструктуре
менеджеров очередей сообщений, администрировать которую значительно проще,
чем построенную с использованием распределенных каналов, что и показывают
практические примеры из раздела 10.4 «Создание кластеров менеджеров очередей».
Увеличиваясь в масштабе, такая инфраструктура может охватить тысячи менед­
жеров.
Примечание. Вплоть до конца главы понятием «кластер» (cluster ) мы будем
пользоваться, называя так кластеры менеджеров очередей сообщений. Не путайте его с кластерами высокой готовности – понятием, характерным не только для WebSphere MQ, о котором мы говорили в разделе 3.6 «Высокая
готовность системы».
162
Глава 8
8.1.1. Менеджеры очередей с полным
и частичным репозиторием
Любой менеджер очередей сообщений содержит репозиторий (repository) с данными
о кластерах, в которых он состоит.
Каждый менеджер внутри кластера можно настроить так, чтобы он содержал частичный или полный репозиторий. Суть полных и частичных репозиториев такова.
 Полный репозиторий.
Содержит данные обо всех совместных ресурсах кластера. В их число входят все
менеджеры и все объекты очередей в кластере, которые используются совместно.
Для каждого кластера в составе инфраструктуры обычно настроено ровно два
менеджера очередей сообщений, имеющих полный репозиторий.
Менеджер, содержащий полный репозиторий с представлением кластера, называ­
ется менеджером очередей с полным репозиторием (full repository queue manager).
 Частичный репозиторий.
Содержит информацию о менеджерах очередей с полным репозиторием класте­
ра. В частичный репозиторий входят сведения лишь о тех объектах очередей и
менеджерах с частичным репозиторием, которые необходимы самому менеджеру.
Если подключенное к нему приложение попытается открыть очередь, название
которой неизвестно для менеджера, то при попытке поиска указанного ресурса
будут опрошены менеджеры очередей с полным репозиторием всех кластеров,
где данный менеджер состоит.
Менеджер, содержащий частичный репозиторий своего кластера, называется
менеджером очередей с частичным репозиторием (partial repository queue manager).
Для вхождения в кластер менеджер очередей должен «знать» его полный репозито­
рий. Поэтому каждый кластер обязан содержать два или более менеджера, в которых
такой репозиторий будет храниться. Именно эти два менеджера очередей с полным
репозиторием изначально и образуют кластер, организуя соединение между собой.
Иметь в составе кластера более двух полных репозиториев, как правило, не рекомен­
дуется потому, что полный репозиторий содержит всю информацию о каждом
из ресурсов, входящих в кластер, а значит, должен регулярно обмениваться сведения­
ми с другими полными репозиториями. Увеличение же их числа повысит нагрузку
на инфраструктуру из-за того, что обмен станет более интенсивным.
8.1.2. Названия кластеров
Любой кластер имеет свое название. Имена кластеров могут содержать до 48 знаков
и состоять из букв верхнего, нижнего регистра и цифр, а также символов «.», «/», «_», «%».
Полезными могут оказаться короткие имена кластеров, длина которых позволит
включать их в описание всех кластерных канальных объектов.
Кластеры менеджеров очередей
163
8.1.3. Настройка менеджера очередей с полным репозиторием
Примечание. Этот шаг рекомендуется выполнить до того, как менеджер
очередей будет подключен к кластеру с использованием описанных в этом
разделе объектов кластерных sender- и receiver-каналов сообщений.
Для задания кластеров, полный репозиторий с информацией о которых содержит
текущий менеджер, служат атрибуты объекта-менеджера «репозиторий» ( REPOS –
repository) и «список названий репозиториев» (REPOSNL – repository namelist).
Атрибут REPOS позволяет определить имя только одного кластера.
Атрибут REPOSNL позволяет определить имена нескольких кластеров. Задайте в этом
атрибуте название описанного на менеджере объекта – списка имен. Определите
объект-список так, чтобы он содержал перечень названий интересующих кластеров.
Примечание. Поддержание полного репозитория кластера может оказаться
причиной заметной вычислительной работы на менеджере, вызванной тем, что
кластер может содержать множество менеджеров или очередей под управлением
таковых. По этой причине мы советуем отказаться от размещения на менеджерах
очередей с полным репозиторием служб, представляемых кластером.
Если эта машина все-таки выделена для размещения служб, рекомендуем
определить на ней ряд других менеджеров. Для размещения менеджеров с полным репозиторием крупных кластеров может оказаться разумным выделить
отдельное оборудование.
Также рекомендуем не размещать оба менеджера с полным репозиторием на одной и той же машине. Поскольку менеджеры очередей с частичным репозиторием кластера могут по-прежнему получать о нем информацию, если одна
машина даст сбой или окажется недоступной, разделив менеджеры, вы избежите
возникновения в кластере единой точки отказа.
8.1.4. Кластерные каналы сообщений
Вся информация в кластере передается по кластерным каналам сообщений (cluster
message channels). Это справедливо и для тех случаев, когда приложение отправляет
сообщение во входящую в кластер очередь и когда менеджер запрашивает в полном
репозитории информацию о ресурсах в составе кластера.
Кластерные и распределенные каналы сообщений очень напоминают друг друга.
И те и другие передают сообщения из транспортной очереди на одном менеджере
в очередь, управляемую другим менеджером из кластера. Однако важное различие
между ними состоит в том, что все сообщения, отправляемые через кластерные кана­
лы, посылаются из одной общей транспортной очереди. Название этой автоматиче­
ски задаваемой на любом менеджере во время создания очереди:
SYSTEM.CLUSTER.TRANSMIT.QUEUE
164
Глава 8
Все сообщения, адресуемые менеджерам очередей в кластере, будут размещены
в этой очереди сообщений автоматически.
WebSphere MQ автоматически создает и запускает кластерные каналы сообщений,
когда в них возникает необходимость. Это означает, что после того, как менеджер
подключается к кластеру, дальнейшее администрирование каналов вручную уже
не требуется.
Кластерные каналы сообщений используют агенты каналов сообщений (MCA)
отправления и получения и обладают теми же возможностями, что и любой распре­
деленный канал. К примеру, они имеют интервалы разъединения, поддерживают
пакетную обработку и записи состояния канала, могут пользоваться аутентификаци­
ей SSL. Описание распределенных каналов и передачи сообщений между MCA-отпра­
вителем и MCA-получателем см. в разделе 7.4 «Распределенные каналы сообщений».
Начальный шаг подключения менеджера очередей к кластеру должен производиться
вручную. При вхождении в кластер менеджер задает атрибуты, которые любой другой
менеджер очередей в кластере должен будет использовать для того, чтобы установить
с ним соединение.
С этой целью в WebSphere MQ введены объекты – кластерные каналы. Они могут
определяться в составе менеджера для инициирования процесса подключения его
к кластеру.
8.1.5. Кластерные receiver-каналы
Объекты – кластерные receiver-каналы описывают атрибуты, которыми, определяя
кластерные sender-каналы сообщений, адресованных текущему менеджеру, должны
пользоваться все входящие в один или несколько кластеров менеджеры очередей
сообщений.
Чтобы сообщить менеджерам очередей с полным репозиторием о менеджере, в со­
ставе которого описан кластерный receiver-канал, он публикуется внутри кластера.
Это означает отправку сведений о нем в один из полных репозиториев кластера,
который передаст их остальным менеджерам очередей с полным репозиторием.
Полные репозитории, в свою очередь, опубликуют это определение на менеджерах
с частичным репозиторием в этом кластере, как только те запросят ресурсы, которы­
ми этот менеджер управляет.
Объекты – кластерные receiver-каналы описывают название и атрибуты, которыми
во время установления направленного к данному менеджеру канала от других менед­
жеров пользуются как MCA-отправитель, так и MCA-получатель.
Так, в кластерном receiver-канале задан интервал разъединения кластерных каналов
сообщений. Им пользуется каждый MCA-отправитель, производящий подключение
к менеджеру.
Поскольку ряд атрибутов, к примеру конфигурация SSL, должен совпадать у агентов
отправления и получения, администрирование может существенно упроститься.
Работая с кластером, достаточно настроить лишь атрибуты одного менеджера, кото­
рый подключается к кластеру, а не обоих – на каждом из концов подключения.
Кластеры менеджеров очередей
165
Чтобы вручную задать объекты – кластерные receiver-каналы, используйте один
из следующих методов.
 MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSRCVR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Cluster-receiver Channel.
Обязательный атрибут – название соединения (CONNAME ) с объектом – кластерным
receiver-каналом. Значением атрибута должно являться название хоста или IP-адрес
и порт, где выполняется слушатель того менеджера очередей сообщений, в составе
которого описан этот объект. Именно этим названием соединения будут пользо­
ваться другие менеджеры очередей в кластере, устанавливая связь с данным менедже­
ром очередей сообщений.
Для задания кластеров, к которым применимо описание канала, служат атрибуты
объекта – кластерного receiver-канала «кластер» (CLUSTER – cluster) и «список названий
кластеров» (CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом
атрибуте название описанного на менеджере очередей объекта – списка имен. Опре­
делите объект-список так, чтобы он содержал перечень интересующих кластеров.
Выход из кластера осуществляется самим менеджером очередей сообщений и проис­
ходит, если атрибут CLUSTER или CLUSNL receiver-канала, через который менеджер был
подключен к кластеру, изменяется и больше не указывает на кластер или если назва­
ние кластера удаляется из объекта списка имен, название которого задано в атрибуте
CLUSNL того же кластерного receiver-канала.
Примечание. Используя список названий кластеров (CLUSNL), менеджер
очередей сообщений может опубликовать кластерный receiver-канал сразу в
нескольких кластерах, что позволяет каналам, направленным к этому менеджеру
в каждом из них, иметь одинаковое название. Канальные объекты такого типа
обычно именуют следующим образом:
TO.названиеменеджера
Другой подход заключается в публикации менеджером отдельных объектов –
кластерных receiver-каналов в каждом кластере, для чего служит атрибут каждого
из объектов-каналов CLUSTER. Канальные объекты такого типа обычно именуют
следующим образом:
TO.названиекластера.названиеменеджера
Второе соглашение об именах сокращает то количество символов, которое
допустимо для обозначения менеджера очередей сообщений в 20-символьном
названии канала.
166
Глава 8
8.1.6. Кластерные sender-каналы
Понятие «кластерный sender-канал» нередко служит для описания различных объек­
тов.
 Описанного вручную объекта – кластерного sender-канала, или CLUSSDR. Использу­
ется при подключении к кластеру для связи с его полным репозиторием.
 Кластерного sender-канала, описанного автоматически, – CLUSSDRA – или автоматического кластерного sender-канала с явным определением (auto explicit cluster
sender). Автоматически формируются менеджерами очередей сообщений с уче­
том определений кластерных receiver-каналов, опубликованных множеством вхо­
дящих в кластер менеджеров для установления связи с ними.
 Автоматически описанного кластерного sender-канала, заменяющего кластерный
sender-канал, описанный вручную, – CLUSSDRB, – или автоматического кластерного sender-канала (auto cluster sender). Автоматически формируется менеджером
очередей сообщений с учетом определения кластерного receiver-канала, опубли­
кованного менеджером очередей с полным репозиторием, для которого объект –
кластерный sender-канал был изначально описан при вхождении в кластер.
Вручную, или явно, определенный объект – кластерный sender-канал выполняет лишь
одну функцию – начальное установление связи с одним из полных репозиториев
во время подключения к кластеру.
Название объекта – кластерного sender-канала, описанного вручную, должно соот­
ветствовать названию объекта – кластерного receiver-канала, описанного в составе
менеджера очередей с полным репозиторием и опубликованного этим же менедже­
ром при вхождении в кластер.
Аналогично для успешного подключения ряд атрибутов описанного вручную клас­
терного sender-канала, к примеру конфигурация SSL, должны быть гарантированно
корректны.
Чтобы вручную задать объект – кластерный sender-канал, используйте один из следу­
ющих методов.
 MQSC-команду DEFINE CHANNEL CHLTYPE(CLUSSDR).
 WebSphere MQ Explorer:
a) щелкните правой кнопкой мыши по папке Channels конкретного менеджера
очередей сообщений в навигаторе WebSphere MQ Explorer;
b) выберите в меню New → Cluster-sender Channel.
Обязательным атрибутом является название соединения (CONNAME) объекта – кластер­
ного канала. Значением атрибута должно служить название хоста или IP-адрес и порт,
где выполняется слушатель менеджера очередей с полным репозиторием кластера.
При этом не имеет значения, какой именно полный репозиторий выбран. Тем
не менее название канала должно соответствовать имени описанного в этом репози­
тории объекта – кластерного receiver-канала.
Для задания кластеров, в которых описание канала может использоваться для связи
с полным репозиторием, служат атрибуты объекта – кластерного sender-канала
«кластер» (CLUSTER – cluster) и «список названий кластеров» (CLUSNL – cluster namelist).
Кластеры менеджеров очередей
167
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом
атрибуте название описанного на менеджере очередей объекта – списка имен. Опре­
делите объект-список так, чтобы он содержал перечень интересующих кластеров.
При описании объекта – кластерного sender-канала через него в полном репозито­
рии публикуются любые объекты – кластерные receiver-каналы, что вызывает начало
автоматического процесса установления членства менеджера в указанных кластерах.
Результатом осуществления такого процесса для каждого кластера является то, что
определение кластерного receiver-канала сохраняется во всех полных репозиториях
кластера. В них также заносятся и определения любых объектов-очередей, коллек­
тивный доступ к которым обеспечивает подключающийся к кластеру менеджер оче­
редей сообщений. В свою очередь, менеджер получает представление обо всех пол­
ных репозиториях кластера.
По окончании описанного процесса явно определенный кластерный sender-канал
более не используется. В дальнейшем менеджер очередей пользуется определениями
кластерных receiver-каналов, совместный доступ к которым имеют все менеджеры
очередей кластера. Это позволяет установить каналы ко всем менеджерам очередей
сообщений с полным и частичным репозиторием. Аналогично и эти менеджеры
очередей могут установить каналы к данному менеджеру, используя обобществлен­
ное в кластере определение кластерного receiver-канала.
Примечание. Если в кластере существует более двух менеджеров очередей
с полным репозиторием, кластерные sender-каналы должны быть заданы явно
по схеме «из каждого полного репозитория – в каждый». Причина этого в том, что
полные репозитории кластера получают информацию только от тех других полных
репозиториев, с которыми они связаны явно определенным кластерным senderканалом.
Менеджерам очередей с частичным репозиторием достаточно одного явного
кластерного sender-канала независимо от числа имеющихся в составе кластера
менеджеров очередей с полным репозиторием. Описание на менеджере очередей
с частичным репозиторием более одного явного кластерного sender-канала
не дает никаких преимуществ.
8.1.7. Совместный доступ к объектам-очередям в кластерах
Менеджеры очередей с полным и частичным репозиторием в кластере могут пользо­
ваться объектами-очередями кластера коллективно.
Это дает возможность автоматически распространять сведения об объектах-очередях
по всем менеджерам очередей в кластере. Например, приложение, подключенное
к одному менеджеру, может разместить сообщение в локальной очереди другого,
причем сама очередь может совместно использоваться всем кластером без указания
названия этого удаленного менеджера.
168
Глава 8
Совместный доступ допускают следующие типы объектов-очередей.
 Объекты локальных очередей:
Чаще всего совместный доступ в кластерах организуется именно к ним. Обоб­
ществление локальных очередей позволяет приложению, подключенному к лю­
бому менеджеру очередей в кластере, поместить сообщение в очередь, которая
используется этим менеджером совместно с другим, указав только название оче­
реди во время ее открытия.
Примечание. Осуществить в кластере совместный доступ к динамически
сформированным локальным очередям посредством коллективного пользования
определением модельной очереди, на базе которой они построены, невозможно.
Однако, если приложение размещает сообщение в очереди с произвольным
названием с указанием конкретного менеджера, который является членом
кластера, сообщение доставляется этому менеджеру. Сказанное означает, что
приложение может послать ответ в динамически организованную очередь для
ответов, используя название очереди ответов и ее менеджера, указанные в де­­-
с­крипторе сообщения-запроса. Название менеджера очереди ответов автоматически подставляется тем менеджером очередей сообщений, к которому было
подключено приложение-инициатор запроса.
В итоге приложения могут производить обмен сообщениями по принципу «запрос – ответ» со службой на основе разделяемой очереди в составе кластера
аналогично тому, как если бы эта очередь находилась под управлением менеджера, к которому подключено приложение.
 Объекты очередей-псевдонимов.
Наличие в кластере очереди-псевдонима с совместным доступом позволяет
менеджеру очередей сообщений обобществить в нем имеющийся в составе
менеджера объект-очередь под другим именем. Локальное по отношению к менед­
жеру название очереди определяется атрибутом «целевая (базовая) очередь»
(TARGQ/base queue), названием же объекта очереди-псевдонима служит название,
под которым очередь доступа в составе кластера.
 Объекты удаленных очередей.
Совместный доступ к различным типам входящих в кластер объектов удаленных
очередей, описанных в разделе 6.2.5 «Объекты удаленных очередей», дает различ­
ные результаты. Типичные примеры их использования следующие.
– Локальное определение удаленной очереди.
Предоставляет входящим в кластер менеджерам возможность совместно
использовать очередь сообщений, находящуюся вне кластера, то есть в составе
менеджера, который не является его членом. Названием объекта удаленной
очереди является название, под которым организован совместный доступ
к ней внутри кластера. Название целевой очереди в составе менеджера очере­
дей назначения определяется атрибутом «удаленное имя» (RNAME ), название
управляющего ею менеджера – атрибутом «название удаленного менеджера
очередей сообщений» (RQMNAME ). Название транспортной очереди менеджера,
на котором описана удаленная очередь, может быть задано атрибутом «транс­
Кластеры менеджеров очередей
169
портная очередь» (XMITQ ) или по умолчанию принято равным названию уда­
ленного менеджера.
– Псевдоним менеджера очередей сообщений.
В данном случае атрибут RNAME объекта удаленной очереди остается пустым.
При этом возможны две ситуации.
• Внутри кластера менеджер очередей может выбрать альтернативное имя.
Им станет название обобществленного в кластере объекта удаленной оче­
реди; реальное же название менеджера будет указано в атрибуте «название
удаленного менеджера очередей сообщений» (RQMNAME).
• Название менеджера вне кластера может быть известно внутри него, а
транспортная очередь к этому менеджеру – задаваться в составе менеджера
очередей сообщений, предоставляющего совместный доступ к определе­
нию объекта удаленной очереди. Название, под которым менеджер очере­
дей сообщений должен быть известен в составе кластера, – это название
обобществленного в нем объекта удаленной очереди. Название менеджера
очередей вне кластера определяется атрибутом RQMNAME. Название транспорт­
ной очереди менеджера внутри кластера, если оно отлично от названия
менеджера очередей за пределами такового, задается атрибутом XMITQ.
Примечание. Еще один полезный способ применения объектов удаленных
очередей в кластере – описание в составе менеджера очередей псевдонима
с пустым значением атрибута «удаленное имя» (RNAME) без разделения объекта
удаленной очереди в кластере.
Такая схема ведет к балансировке нагрузки, создаваемой сообщениями, поступающими этому менеджеру очередей извне кластера и содержащими конкретное
название менеджера очередей сообщений.
Совместно пользоваться объектами-очередями с одним названием и одного или раз­
ных типов в одном кластере могут, располагая этими типами объектов-очередей,
сразу несколько менеджеров. Об этом мы еще скажем в разделе 8.4 «Балансировка
нагрузки».
Для задания кластеров, в которых к объекту организован совместный доступ, служат
атрибуты объектов-очередей «кластер» (CLUSTER – cluster) и «список названий класте­
ров» (CLUSNL – cluster namelist).
Атрибут CLUSTER позволяет определить имя только одного кластера.
Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом
атрибуте название описанного на менеджере очередей объекта – списка имен. Опре­
делите объект-список так, чтобы он содержал перечень интересующих кластеров.
8.1.8. Идентификатор менеджера очередей (QMID)
При создании каждого менеджера очередей сообщений для него строится иденти­
фикатор менеджера QMID (queue manager identifier), значение которого определяют
время создания и название менеджера. В этих условиях вероятность того, что два
170
Глава 8
менеджера получат одинаковые QMID, очень невелика, даже если они будут названы
одинаково.
Уникальность QMID позволяет различать менеджеры очередей в кластере, неповто­
ряемость их названий для этого не используется. Два менеджера очередей сообщений
с одинаковыми названиями вряд ли будут включены в кластер умышленно, и делать
это определенно не стоит. Однако почему-либо менеджер может быть пересоздан,
например после сбоя аппаратуры. При этом старый менеджер с тем же названием
мог не пройти успешное отключение от кластера до присоединения к нему нового.
Столкнувшись с подобными ситуациями, кластеру важно иметь возможность разли­
чать первый и второй менеджер.
Если это произошло и в кластере оказалось несколько менеджеров с одинаковыми
названиями, то, приступая к разрешению ситуации, изучите документацию по коман­
де MQSC RESET CLUSTER ACTION(FORCEREMOVE).
Примечание. Описанные в ней действия предпринимайте только после
прочтения соответствующих разделов в WebSphere MQ Queue Manager Clusters,
SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.1.9. Подписки и публикации в кластере
В этом разделе мы коротко расскажем о том, как полные и частичные репозитории
кластера поддерживают актуальную информацию, что послужит основой для пони­
мания сведений, получаемых при просмотре той информации о кластере, которая
в них содержится.
Все полные репозитории кластера общаются между собой, и это позволяет им обес­
печить поддержание полной и одинаковой информации обо всех менеджерах и объ­
ектах-очередях в кластере.
Как только к кластеру подключается менеджер с частичным репозиторием, он публикует информацию о себе, включая предоставленную объектом – кластерным recei­
ver-каналом, и адресует ее двум полным репозиториям внутри кластера.
Организуя совместный доступ к объекту очереди внутри кластера, менеджер с час­
тичным репозиторием аналогично публикует сведения об объекте двум полным
репозиториям кластера.
Частичный репозиторий повторяет эти публикации каждые 27 дней, что позволяет
полным репозиториям убедиться, что менеджер внутри кластера остается активным,
а информация – актуальной. Также полным репозиториям адресуются любые пуб­
ликации с изменениями этих совместно используемых в кластере менеджеров
объектов.
Если публикация не повторяется в течение 30 дней, ее срок действия истекает, и на
запрос сведений от частичных репозиториев полные репозитории перестают выда­
вать ее как ответ. Однако на случай временной недоступности менеджера по некото­
рой причине репозитории сохраняют ее в течение еще 60 дней. Если по окончании
Кластеры менеджеров очередей
171
периода, длящегося в общей сложности 90 дней, менеджер не повторил публикацию
информации, полный репозиторий больше не считает его частью своего кластера.
Когда же частичный репозиторий повторно установит связь с полным, он станет
известен кластеру снова.
Частичный репозиторий поддерживает сведения лишь о тех менеджерах и объектах
очередей кластера, которые ему интересны, в частности:
 обо всех менеджерах с полным репозиторием, успешно подключившихся к клас­
теру;
 об объектах-очередях, входящих в кластер и одноименных объектам, обобщест­
вленным менеджером очередей внутри кластера;
 об объектах-очередях, входящих в кластер под именами, по адресу которых под­
ключенные к менеджеру очередей приложения посылают сообщения;
 о менеджерах с частичными репозиториями, под управлением которых находятся
известные этому менеджеру объекты очередей.
Для получения информации менеджер с частичным репозиторием производит
подписку на сведения от менеджеров с полным репозиторием. В ответ он получает
все известные полному репозиторию публикации о соответствующих объектах или
уведомление о том, что нужная информация недоступна.
Подписки формируются частичным репозиторием в момент организации коллек­
тивного доступа к новому объекту в составе кластера, а также при разрешении назва­
ний очередей, когда подключенные к менеджеру очередей приложения пытаются
открыть их для размещения сообщений.
Если менеджеру с частичным репозиторием неизвестны названия объектов или
менеджеров объектов-очередей, указанные при открытии таковых для размещения
сообщений, подписки на информацию от полных репозиториев генерируются для
всех кластеров, в которые входит данный частичный репозиторий.
Примечание. Открывая неизвестную в частичном репозитории очередь
сообщений, менеджер может до 10 секунд ждать отклика менеджера очередей
с полным репозиторием. Если ожидание безрезультатно, то приложение, которое
пытается поместить сообщение в очередь, будет не в состоянии это сделать.
По этой причине возможность в любой момент времени установить связь хотя бы
с одним из полных репозиториев кластера чрезвычайно важна.
Подписки имеют ограниченный 30-дневный период существования, на протяжении
которого частичный репозиторий автоматически получает от менеджеров с полным
репозиторием обновления по подписке. По истечении 27 дней подписку требуется
продлить. Однако менеджер продлевает ее только в том случае, если обращался к пуб­
ликациям по подписке с того момента, как продлевал ее в прошлый раз. Иначе он не
препятствует тому, чтобы срок подписки истек. Впрочем, если приложение в очеред­
ной раз попытается открыть объект очереди, подписку можно инициировать вновь.
В период существования подписки информация, относящаяся к ней в частичном репо­
зитории, актуальна, поскольку полный репозиторий автоматически передает ему
обновления, когда они происходят. Частичному репозиторию это дает возможность
172
Глава 8
общаться с управляющими объектами очередей менеджерами напрямую, не связываясь
с полным репозиторием. А значит, приложения, подключенные к частичному репози­
торию, могут открывать очереди и размещать сообщения наиболее эффективно.
Репозиторий менеджера поддерживается входящим в менеджер очередей соответ­
ствующий компонент, называемый менеджером репозитория. Он управляет подпис­
ками и отсылает публикации полным репозиториям внутри кластера.
Данный механизм обеспечивает баланс между числом подписок, которые должен
поддерживать полный репозиторий, и «знаниями» частичных репозиториев, позво­
ляющими приложениям эффективно обращаться к объектам-очередям.
8.2. Просмотр сведений из репозитория кластера
Как мы уже говорили, записи состояния кластерных каналов сообщений хранятся
в каждом менеджере подобно записям состояния распределенных каналов. Кластер­
ные каналы сообщений также можно запускать, останавливать, активизировать
и блокировать, используя команды START CHANNEL и STOP CHANNEL в MQSC.
Однако, воспользовавшись MQSC и WebSphere MQ Explorer, о кластерах можно узнать
подробнее, если познакомиться с текущим содержимым частичного или полного
репозиториев менеджера очередей сообщений.
8.2.1. Просмотр сведений из репозитория через MQSC
В составе MQSC есть две команды доступа к этим сведениям.
 DISPLAY QCLUSTER.
Команда выводит информацию обо всех совместно используемых кластерами
экземплярах объектов-очередей, о которых известно менеджеру. Например,
запуск следующей команды в полном репозитории кластера отображает всю
известную информацию обо всех разделяемых в нем объектах-очередях:
DISPLAY QCLUSTER(*) CLUSTER('Cluster.Name') ALL
Каждый разделяемый внутри кластера экземпляр объекта очереди называют кластерной очередью (cluster queue). Заметим, что, как показано в разделе 8.4 «Балан­
сировка нагрузки», для упрощения балансировки нагрузки в пределах кластера
обобществленными среди ряда менеджеров очередей сообщений могут считаться
несколько кластерных очередей с одним именем. Каждая запись о такой очереди
содержит сведения о типе объекта очереди, менеджере, управляющем ею в класте­
ре, а также о том, могут ли приложения помещать в нее сообщения или очередь
заблокирована на запись.
Примечание. Эта же команда MQSC, поданная в частичном репозитории,
может не вернуть полный список общих кластерных очередей кластера, что
связано с обстоятельствами, рассмотренными нами в разделе 8.1.9 «Подписки
и публикации в кластере».
Кластеры менеджеров очередей
173
 DISPLAY CLUSQMGR.
Команда выводит информацию об известных менеджеру очередей сообщений
менеджерах очередей в кластере. Так, запуск следующей команды в полном репо­
зитории кластера покажет всю известную информацию обо всех менеджерах
очередей кластера:
DISPLAY CLUSQMGR(*) CLUSTER('Cluster.Name') ALL
Каждую выводимую при этом на экран запись называют записью кластерного
менеджера очередей (cluster queue manager), или CLUSQMGR -записью. Одна из них
содержит данные о локальном менеджере очередей сообщений, работая с кото­
рым вы запустили команду. Информация в этой записи содержит в себе название
и подробное описание относящегося к данному менеджеру кластерного канала
сообщений. Им может оказаться объект – кластерный receiver-канал локального
менеджера или любой из типов кластерных sender-каналов из раздела 8.1.6 «Клас­
терные sender-каналы». Тип кластерного канала сообщений представлен атрибу­
том «тип описания» (DEFTYPE – definition type) записи кластерного менеджера оче­
редей и содержит информацию о состоянии кластерных sender-каналов данного
менеджера, ведущих к остальным менеджерам очередей внутри кластера.
Примечание. Для получения информации о каналах, направленных к данному менеджеру очередей сообщений и установленных с помощью обобществленного в кластере определения кластерного receiver-канала используйте команду
DISPLAY CHSTATUS. Направленные к менеджеру активные кластерные каналы
могут иметь несколько менеджеров в кластере одновременно, причем название
кластерного receiver-канала окажется одинаковым. Запись кластерного менеджера очередей может представлять каналы к менеджеру как неактивные в тот
момент, когда на самом деле они реально работают.
Запись кластерного менеджера очередей также содержит подробные сведения
о менеджере очередей сообщений, в том числе его QMID, и информацию о том,
является ли он полным репозиторием кластера. В записи о полном репозитории
атрибут «тип менеджера очередей» (QMTYPE – queue manager type) принимает зна­
чение REPOS, в записи о частичном – значение NORMAL.
Примечание. Эта же команда MQSC, поданная в частичном репозитории,
может не вернуть полного списка менеджеров очередей в кластере, но должна
показать все полные репозитории в нем. Такое поведение команды связано
с обстоятельствами, рассмотренными в разделе 8.1.9 «Подписки и публикации
в кластере».
Если при подключении к кластеру не удается запустить заданный вручную кластер­
ный sender-канал, ведущий в полный репозиторий, название в записи кластерного
менеджера очередей примет следующий вид:
SYSTEM.TEMPQMGR.hostname(port)
174
Глава 8
Здесь hostname(port) – название соединения в описании канала. Подобный формат
обусловлен тем, что имя менеджера очередей сообщений невозможно установить,
пока канал к нему не будет успешно пущен.
8.2.2. Просмотр сведений из репозитория
в WebSphere MQ Explorer
Для представления информации из репозитория кластера в WebSphere MQ Explorer
имеется папка Queue Manager Clusters в навигаторе инструмента.
Как только WebSphere MQ Explorer подключается к менеджеру из папки Queue Manag­
ers с полным репозиторием кластера, обозначения кластеров появляются в папке
Queue Manager Clusters автоматически. Менеджеры, представляющие собой полные
репозитории кластера, могут находиться на той же машине, что WebSphere MQ
Explorer, или быть подключенными к нему удаленно.
Примечание. WebSphere MQ Explorer не показывает информацию о кластерах, для которых подключенные из папки Queue Managers менеджеры очередей
являются частичными репозиториями.
Причина этого в том, что менеджеры с частичным репозиторием не содержат
достаточно сведений о кластере для того, чтобы надежно установить информацию обо всех менеджерах очередей в нем, как было сказано в разделе 8.1.9
«Подписки и публикации в кластере».
Под каждым из значков кластера в навигаторе будут отображаться две папки.
 Full Repositories.
Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, кото­
рые входят в кластер и содержат его полные репозитории. Значок каждого менед­
жера очередей с полным репозиторием кластера расположен уровнем ниже.
 Partial Repositories.
Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, кото­
рые входят в кластер и содержат его частичные репозитории. Значок каждого
менеджера очередей с частичным репозиторием кластера расположен уровнем
ниже.
Папка Queue Manager Clusters в WebSphere MQ Explorer показана на рис. 8.1. Взятый
как пример кластер содержит четыре менеджера, локально работающих на машине с
WebSphere MQ Explorer. Два менеджера содержат полный и два – частичный репози­
торий.
Кластеры менеджеров очередей
175
Рис. 8.1. Папка Queue Manager Clusters в WebSphere MQ Explorer
Если к WebSphere MQ Explorer подключено несколько менеджеров очередей с пол­
ными репозиториями одного кластера, WebSphere MQ Explorer выбирает один из них,
чтобы сформировать содержимое папок кластера – Full Repositories и Partial Reposito­
ries. Используемый для этого менеджер называют источником кластерной информации.
Все полные репозитории менеджеров содержат идентичную информацию, о чем
упоминалось в разделе 8.1.9 «Подписки и публикации в кластере». Тем не менее, если
менеджер отключается от сети, или ведущие к нему кластерные каналы блокируются,
в его полном репозитории может оказаться не вся необходимая информация о
менеджерах очередей кластера. В этих условиях источником кластерной информа­
ции может стать другой менеджер, также содержащий полный репозиторий и под­
ключенный из папки Queue Managers. Для его выбора выделите значок кластера в
навигаторе и щелкните по кнопке Select на странице содержимого Cluster.
Просмотр репозитория единичного менеджера
После запроса источника кластерной информации для получения сведений о менед­
жерах очередей – членах кластера на экран может быть выведена информация
из частичного или полного репозитория каждого входящего в кластер менеджера.
Если в папках Full Repositories или Partial Repositories определенного кластера выбрать
конкретный менеджер, откроется страница содержимого с информацией, которую
данный менеджер содержит в своем репозитории.
176
Глава 8
Информация на этой странице будет запрашиваться у менеджера, который вы
выбрали, а не в источнике кластерной информации.
Если в папке Queue Managers удаленный менеджер не показан, хранящуюся в его
репозитории информацию о кластере вы все же можете просмотреть. Значок менед­
жера будет изначально вам недоступен, а представленные таблицы не будут содер­
жать данных. Для установления через кластер соединения с этим менеджером и вы­
вода информации на экран щелкните правой кнопкой по недоступному значку
менеджера в папке Partial Repositories или Full Repositories кластера в навигаторе
и выберите Connect To Queue Manager.
Примечание. Подключение к менеджеру для вывода данных репозитория, не
показанному в используемой папке Queue Managers, происходит не напрямую,
а посредством отправки и получения сообщений от него через кластер.
Соединение, которым пользуется WebSphere MQ Explorer, адресовано выбранному для текущего кластера источнику кластерной информации.
Чтобы это подключение было успешным, менеджер очередей сообщений, для которого нужно произвести вывод кластерной информации, должен иметь работающий командный сервер. Кроме того, должна быть возможна связь с этим менеджером очередей через кластер, реализующий двухсторонний обмен с выбранным
как источник кластерной информации менеджером очередей с полным репозиторием. Если целевой менеджер не запущен, не работает его командный сервер,
возникает ошибка авторизации или дает сбой соединение через кластер, выводимая на экран ошибка обычно имеет вид:
Command server not responding within timeout period. (AMQ4032)
Отображаемая после успешного подключения к менеджеру информация на странице
содержимого репозитория делится на три вкладки.
 Cluster Queues.
Содержит сведения обо всех совместно используемых кластерами экземплярах объ­
ектов-очередей, о которых известно менеджеру. Информация идентична той, которая
выводится на экран при запуске для данного менеджера команды MQSC DISPLAY
QCLUSTER.
Каждый разделяемый внутри кластера экземпляр объекта очереди называют кластерной очередью (cluster queue). Заметим, что, как показано в разделе 8.4 «Баланси­
ровка нагрузки», для упрощения балансировки нагрузки в пределах кластера обоб­
ществленными среди ряда менеджеров очередей сообщений могут считаться
несколько кластерных очередей с одним именем. Каждая запись о такой очереди
содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере,
а также о том, могут ли приложения помещать в нее сообщения или очередь заблоки­
рована на запись.
Количество совместно используемых в кластере объектов-очередей, информация
о которых хранится в репозитории менеджера, графически представлено над таб­
лицей.
Кластеры менеджеров очередей
177
Каждой кластерной очереди в таблице отведено по строке. Столбцы таблицы пока­
зывают атрибуты записи данных о такой очереди. Дважды щелкнув по самой записи,
вы увидите атрибуты записи в окне свойств.
Примечание. Менять значения атрибутов объекта, представленного записью
о кластерной очереди, из окна свойств нельзя. Это справедливо и для тех
случаев, когда менеджер подключен к WebSphere MQ Explorer из папки Queue
Managers.
Чтобы изменить атрибуты, обязательно подключите менеджер очередей сообщений к WebSphere MQ из папки Queue Managers. Затем выберите в навигаторе
папку Queues конкретного менеджера и дважды щелкните по разделяемому
в кластере объекту очереди в таблице.
 Cluster-sender channels.
Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR,
выполненной для всех удаленных менеджеров очередей кластера. Это записи обо
всех известных данному менеджеру очередей сообщений менеджерах очередей в
кластере, для связи с которыми он использует кластерный sender-канал. Типы
таких каналов мы обсуждали в разделе 8.1.6 «Кластерные sender-каналы».
Для каждого менеджера очередей в кластере, известного текущему менеджеру,
в таблице отводится по строке. Каждой строкой таблицы представлен направлен­
ный к менеджеру, работающий или способный работать кластерный sender-канал.
Это – запись кластерного менеджера очередей. Она содержит детальные сведения
о состоянии канала и менеджере очередей сообщений, в том числе его QMID
и информацию о том, является ли он полным репозиторием кластера. Столбцы
таблицы обеспечивают подробное представление, доступ к которому в окне
свойств осуществляется двойным щелчком по строке. Дальнейшие сведения
о запи­сях кластерных менеджеров очередей, которые содержит данная вкладка,
см. в разделе 8.2.1 «Просмотр сведений из репозитория через MQSC».
Примечание. Менять значения атрибутов любых канальных объектов,
к которым относятся записи кластерных менеджеров очередей, из окна свойств
нельзя. Это справедливо и для тех случаев, когда менеджер подключен
к WebSphere MQ Explorer из папки Queue Managers.
Обсуждаемые здесь записи, хотя и показывают кластерные sender-каналы, как
правило, представляют автоматически заданные каналы, созданные на основе
кластерных receiver-каналов, которые описаны менеджером очередей сообщений
при подключении к кластеру. Подробнее об этом см. в разделе 8.1.5 «Кластерные
receiver-каналы». Вручную объекты – кластерные sender-каналы создаются только
при подключении к кластеру для связи с полным репозиторием такового.
Подробности см. в разделе 8.1.6 «Кластерные sender-каналы».
178
Глава 8
 Cluster-receiver channels.
Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR,
выполненной для локального менеджера. Обычно это всего одна запись. Она
содержит ту информацию, которая была опубликована менеджером очередей
сообщений при подключении к кластеру и является описанием кластерного
receiver-канала. Подробности читайте в разделе 8.1.5 «Кластерные receiver-каналы».
Обычно эта таблица содержит одну строку, которая свидетельствует о публикации
данным менеджером единственного объекта – кластерного receiver-канала. Это запись кластерного менеджера очередей. Она содержит детальные сведения
о состоянии канала и менеджере очередей сообщений, в том числе его QMID
и информацию о том, является ли он полным репозиторием кластера. Столбцы
таблицы обеспечивают подробное представление, доступ к которому в окне
свойств осуществляется двойным щелчком по строке. Дальнейшие сведения
о записях кластерных менеджеров очередей, которые содержит данная вкладка,
см. в разделе 8.2.1 «Просмотр сведений из репозитория через MQSC».
Примечание. Менять значения атрибутов канального объекта, к которому
относится запись кластерного менеджера очередей, из окна свойств нельзя. Это
справедливо и для тех случаев, когда менеджер подключен к WebSphere MQ
Explorer из папки Queue Managers.
Применение кластерных receiver-каналов при подключении к кластеру мы обсуждали в разделе 8.1.5 «Кластерные receiver-каналы».
8.3. Работа с менеджерами очередей в кластере
Этот раздел главы посвящен описанию общих действий, выполняемых в ходе адми­
нистрирования или создания кластера менеджеров очередей сообщений. Процедура
администрирования относительно несложна, однако чтобы остальные менеджеры
очередей в кластере не содержали ложную информацию о данном менеджере очере­
дей сообщений, а подключение к нему в кластере возможно установить, должна пра­
вильно выполняться.
8.3.1. Приостановка и возобновление работы
менеджера очередей в кластере
Приостановка работы менеджера очередей в кластере отлична от его удаления.
В результате приостановки доставка сообщений очередям, совместный доступ
к которым в кластере организует текущий менеджер, становится практически невоз­
можной. Она существенно сокращает вероятность того, что контролирующий работу
остальных менеджеров алгоритм балансировки нагрузки выберет доставку сообще­
ний очередям текущего менеджера. Вопросы балансировки нагрузки мы обсудим
в разделе 8.4 «Балансировка нагрузки».
Приостановка работы менеджера очередей не мешает тому, чтобы специально пред­
назначенные ему сообщения поступали к нему из кластера.
После выполнения приостановки работу менеджера можно снова возобновить.
Кластеры менеджеров очередей
179
Чтобы произвести приостановку или возобновление работы менеджера очередей
в кластере, используйте один из следующих методов.
 Для целей приостановки или возобновления работы менеджера очередей в одном
кластере – команды MQSC SUSPEND QMGR CLUSTER или RESUME QMGR CLUSTER.
 Для целей приостановки или возобновления работы менеджера очередей
в нескольких кластерах – команды MQSC SUSPEND QMGR CLUSNL или RESUME QMGR CLUSNL.
 WebSphere MQ Explorer:
a) для выполнения приостановки менеджера с частичным репозиторием полный
репозиторий кластера должен быть подключен из папки Queue Managers нави­
гатора;
b) откройте в навигаторе папку Queue Manager Clusters;
c) разверните дерево навигатора под значком с тем же названием, что и кластер;
d) в зависимости от того, полный или частичный репозиторий кластера содер­
жит текущий менеджер, разверните в навигаторе папку Full Repositories или
Partial Repositories;
e) щелкните в навигаторе правой кнопкой по значку, одноименному менеджеру.
• Если работу менеджера в кластере необходимо остановить, выберите в ме­
ню Suspend Cluster Membership.
• Если работу менеджера в кластере необходимо возобновить, выберите
в меню Resume Cluster Membership. Заметим, что этот пункт доступен толь­
ко в том случае, если менеджер в кластере был ранее приостановлен.
8.3.2. Сброс членства менеджера очередей в кластере
Для удаления из кластера всей информации о менеджере и обеспечения возможнос­
ти нового запуска менеджера очередей в нем без выхода и повторного подключения
воспользуйтесь командой MQSC RESET CLUSTER.
Это действие также доступно из WebSphere MQ Explorer, где нужно щелкнуть правой
кнопкой мыши по значку менеджера очередей интересующего вас кластера.
Примечание. Предпринимайте это действие только после прочтения соответствующих разделов руководства WebSphere MQ Queue Manager Clusters,
SC34-6589. Особую аккуратность следует проявить, если ваша работа затрагивает менеджеры очередей с полным репозиторием кластера.
8.3.3. Этапы подключения менеджера очередей к кластеру
Опишем в этом разделе ручные операции добавления менеджера в существующий
кластер или формирования нового. Для кластеров, не использующих списки имен
в определениях каналов или атрибутах репозиториев менеджеров, перечисленные
здесь действия также можно осуществить при помощи мастеров WebSphere MQ
Explorer.
180
Глава 8
С применением мастеров WebSphere MQ Explorer
В мастерах WebSphere MQ Explorer создание кластера и добавление менеджера оче­
редей в существующих – это разные операции. И в первом и во втором случае менед­
жеры очередей должны быть предварительно созданы и запущены, а также подклю­
чены к WebSphere MQ в папке Queue Managers.
Для доступа к мастеру создания кластера Create Cluster:
1. Убедитесь, что оба изначально образующих кластер менеджера очередей с пол­
ным репозиторием существуют и подключены из папки Queue Managers.
2. Щелкните правой кнопкой по расположенной в дереве навигатора папке Queue
Manager Clusters.
3. Выберите в меню New → Queue manager cluster.
Для доступа к мастеру добавления в кластер Add to cluster:
1. Убедитесь, что полный репозиторий кластера подключен к WebSphere MQ Explorer
из папки Queue Managers.
2. Убедитесь, что из этой папки подключен и вводимый в состав кластера менеджер.
3. В представленной в навигаторе папке Queue Manager Clusters щелкните правой
кнопкой по тому кластеру, к которому подключается менеджер.
4. Выберите в меню Add Queue Manager To Cluster.
Операции, выполняемые вручную
Чтобы вручную добавить менеджер в существующий кластер или сформировать
новый, произведите следующую работу.
1. Убедитесь в том, что для менеджера описан слушатель на конкретный сетевой
порт, а имя хоста или IP-адрес машины, где размещается менеджер, известны
и доступны всем остальным менеджерам очередей в кластере.
Примечание. Не используйте имя хоста, равное localhost, и IP-адрес
127.0.0.1, так как они действуют только на локальной машине.
2. Убедитесь в том, что известно название подключения к полному репозиторию
кластера, включая имя хоста или IP-адрес машины с менеджером и порт, на кото­
рый настроен слушатель. Если эти шаги касаются одного из пары исходных
менеджеров очередей с полным репозиторием, то речь идет о названии соедине­
ния с другим менеджером очередей сообщений, который содержит – или может
содержать – полный репозиторий кластера.
Примечание. Если текущим менеджером планируется заменить прежний
полный репозиторий, рекомендуем выбрать название соединения того полного
репозитория кластера, который в нем остается.
Кластеры менеджеров очередей
181
3. Если текущий менеджер должен содержать полный репозиторий одного кластера,
установите атрибут REPOS объекта-менеджера очередей сообщений равным назва­
нию такового.
Если менеджер очередей должен содержать полные репозитории нескольких
кластеров, определите объект – список имен с занесенными в атрибут NAMES назва­
ниями всех кластеров. Укажите название объекта – списка имен в атрибуте REPOSNL
объекта – менеджера очередей сообщений.
4. Определите объект – кластерный receiver-канал, описав в нем порядок обращения
к текущему менеджеру остальных менеджеров очередей внутри кластера.
– В атрибуте CONNAME задайте название соединения для связи с тем менеджером,
который подключается к кластеру.
– Если кластерный receiver-канал планируется использовать для подключения
только к одному кластеру, заполните его названием атрибут CLUSTER.
– Если один объект – кластерный receiver-канал, напротив, будет использоваться
для подключения менеджера к целой серии кластеров, определите объект ­–
список имен с названиями последних, перечислив их в атрибуте списка назва­
ний NAMES. Укажите имя объекта – списка имен в атрибуте CLUSNL объекта – клас­
терного receiver-канала.
– Задайте любые дополнительные атрибуты, такие как интервал разъединения,
размер пакета или конфигурация SSL, которыми должны пользоваться менед­
жеры очередей внутри кластера, отправляя сообщения вводимому в его состав
менеджеру.
5. Определите объект – кластерный sender-канал, чтобы описать подключение к су­
ществующему полному репозиторию кластера, или выберите другой описанный
менеджер очередей с полным репозиторием.
– В атрибуте CONNAME задайте название соединения для связи с тем менеджером,
где расположен полный репозиторий кластера.
– Если на удаленном менеджере с полным репозиторием расположен полный
репозиторий только одного кластера – того, к которому текущий менеджер
подключается, или для каждого из тех кластеров, полными репозиториями
которых он управляет, менеджер имеет собственные объекты – кластерные
receiver-каналы, заполните атрибут CLUSTER названием кластера.
– Если в составе менеджера очередей с полным репозиторием, напротив, описан
общий объект – кластерный receiver-канал для нескольких кластеров, к кото­
рым текущий менеджер должен быть подключен, определите объект – список
имен с названиями последних, перечислив их как значение атрибута списка
названий NAMES . Укажите имя объекта – списка имен в атрибуте CLUSNL объек­
та – кластерного sender-канала.
– Задайте любые дополнительные атрибуты, к примеру конфигурацию SSL,
которые необходимы определению кластерного receiver-канала на менеджере
очередей с полным репозиторием.
182
Глава 8
Примечание. Если подключающийся к кластеру менеджер является менеджером с полным репозиторием, а число прочих имеющихся в составе кластера
полных репозиториев больше, чем единица, явно определите кластерные senderканалы ко всем остальным менеджерам очередей сообщений с полным репозиторием кластера.
6. Наконец, менеджер очередей сообщений становится членом кластера и, пользуясь
атрибутами «кластер» (CLUSTER) и «список названий кластеров» (CLUSNL) объектов,
может организовывать общий доступ к объектам-очередям в кластере. При этом
существующие объекты-очереди могут меняться, а новые – определяться впервые.
Примечание. До успешного окончания процесса подключения к кластеру
в экранной выдаче команд DISPLAY CLUSQMGR и папке Clusters в WebSphere MQ
Explorer вы увидите элементы вида:
SYSTEM.TEMPQMGR.hostname(port)
Обратите на них внимание, если менеджер с полным репозиторием, явный
кластерный sender-канал к которому вы описали, функционирует, имеет работающий на верном сетевом порту слушатель и уже введен в состав кластера. Если
вы видите подобные элементы, тщательно проверьте атрибуты описанных
кластерных канальных объектов и убедитесь, что слушатели настроены на
правильные порты на каждом из менеджеров. Общие сведения об устранении
проблем мы приведем в разделе 12.3.3 «Общие проблемы при построении
инфраструктуры».
8.3.4. Этапы удаления менеджера из кластера
Теперь опишем ручные операции удаления менеджера из кластера. Для кластеров, не
использующих списки имен в определениях каналов или атрибутах репозиториев
менеджеров, перечисленные здесь действия также можно осуществить при помощи
мастеров WebSphere MQ Explorer.
С применением мастеров WebSphere MQ Explorer
Для доступа к мастеру Remove Queue Manager from Cluster в составе WebSphere MQ
Explorer используйте следующие шаги.
1. Под значком кластера на панели навигации в папке Queue Manager Clusters найди­
те соответствующий менеджеру значок. Его местом расположения окажется папка
Full Repositories или Partial Repositories.
2. Щелкните правой кнопкой мыши по найденному значку и выберите в меню
Remove Queue Manager From Cluster.
Операции, выполняемые вручную
Чтобы вручную удалить менеджер из кластера менеджеров, произведите следующую
работу.
Кластеры менеджеров очередей
183
1. Если удаляемый менеджер содержит полный репозиторий, убедитесь, что еще два
полных репозитория остаются в составе кластера.
Примечание. Если это не так, подключите к кластеру новый менеджер
очередей с полным репозиторием прежде, чем перейдете к удалению сущест­
вующего.
2. Если удаляемый менеджер содержит полный репозиторий, сообщите всем менед­
жерам очередей внутри кластера, что тот больше не управляет его полным репо­
зиторием. Для этого:
– если в составе менеджера хранится репозиторий только одного кластера,
очистите атрибут REPOS или REPOSNL объекта – менеджера очередей сообщений,
выбрав для удаления значения тот атрибут, в котором оно содержится;
Примечание. В командах MQSC пустое значение должно записываться в одинарных кавычках:
ALTER QMGR REPOS(' ')
– если в составе менеджера хранится репозиторий нескольких кластеров, а он
должен быть удален только из одного, модифицируйте заданный в атрибуте
менеджера REPOSNL объект ­– список так, чтобы исключить данный кластер из
перечня.
3. Произведите приостановку менеджера очередей, как описано в разделе 8.3.1
«Приостановка и возобновление работы менеджера очередей в кластере».
4. Сообщите менеджерам из кластера, что данный менеджер покидает его состав.
Для этого:
– если послуживший для подключения кластерный receiver-канал использовался
для подключения только к одному кластеру, очистите атрибут CLUSTER или CLUSNL
объекта – кластерного receiver-канала, выбрав для удаления значения тот атри­
бут, в котором оно содержится;
Примечание. В командах MQSC пустое значение должно записываться в одинарных кавычках:
ALTER CHANNEL('TO.QmgrName’) CHLTYPE(CLUSRCVR) CLUSTER(‘ ‘)
– если послуживший для подключения кластерный receiver-канал использовался
для подключения к нескольким кластерам, а должен быть удален только
из одного, модифицируйте заданный в атрибуте CLUSNL объекта – кластерного
receiver-канала объект-список так, чтобы исключить данный кластер из пе­
речня.
184
Глава 8
5. Выполните команду останова канала объекта – кластерного receiver-канала, кото­
рый применялся при подключении менеджера очередей к кластеру. К примеру,
в MQSC используйте следующую команду:
STOP CHANNEL('TO.QmgrName’)
Примечание. По окончании этого шага любое сообщение, отосланное
менеджеру очередей через кластер, останется в кластерной транспортной
очереди менеджера-источника. Поэтому, прежде чем запустить указанную
команду, дождитесь прекращения поступления менеджеру новых сообщений.
Менеджеры из кластера уже «знают» о его удалении, а значит, алгоритмы
балансировки нагрузки перестанут присылать новые сообщения в его адрес.
6. Если на протяжении этих этапов атрибут «кластер» или «список названий класте­
ров» был очищен, а потребности в кластерном receiver-канале для повторного
подключения менеджера очередей к кластеру не возникнет, объект – кластерный
receiver-канал может быть удален.
7. Если послуживший для подключения кластерный sender-канал использовался для
подключения менеджера очередей только к одному кластеру, на этом шаге он
может быть остановлен и удален. В противном случае для удаления ссылки на
кластер из определения кластерного sender-канала или списка имен, в которых
она содержится, следуйте процедуре, описанной для кластерного receiver-канала.
8. Выполните команду обновления кластера, из которого удаляется менеджер. Тем
самым вы гарантируете очистку информации о кластере из репозитория этого
менеджера очередей.
Примечание. Если покидающий кластер менеджер содержит полный репозиторий, возможно существование ведущих к этому менеджеру, явно описанных
частичными репозиториями кластерных sender-каналов сообщений. В этом случае
опишите на менеджерах частичных репозиториев новые объекты – кластерные
каналы, направленные к оставшемуся полному репозиторию кластера, и удалите
старый объект – кластерный sender-канал. Иначе такие менеджеры не смогут,
если потребуется, покинуть кластер и снова войти в него в будущем. В числе
прочих действий выполните команду REFRESH CLUSTER с параметром REPOS(YES).
8.4. Балансировка нагрузки
Мощнейшей из возможностей кластеров является балансировка нагрузки. Она дает
возможность разместить службу в составе нескольких менеджеров очередей внутри
кластера, распределяя запросы от обращающихся к ней приложений по экземплярам
службы, – прозрачно для работы программ.
Производительность размещенных в кластере служб может эффективно наращи­
ваться расширением ресурсов инфраструктуры. Новые запросы от приложений, под­
ключившихся к менеджерам в составе кластера для того, чтобы воспользоваться
Кластеры менеджеров очередей
185
предложенными им службами, автоматически адресуются новым машинам, где
выполняются эти службы и менеджеры.
Автоматически обнаруживая, что менеджер очередей недоступен, балансировка
нагрузки может обеспечить и высокую готовность реализуемых служб, новые запро­
сы которых распределяются по оставшимся доступными менеджерам очередей внут­
ри кластера.
Чтобы воспользоваться преимуществами балансировки нагрузки, особой настройки
кластера не потребуется. Чтобы добавить в кластер экземпляр службы, подключите
новый менеджер очередей, после чего откройте совместный доступ к очереди, пред­
ставляющей службу, распознаваемую по имени очереди. Все менеджеры очередей
внутри кластера, которые обращались – или в будущем обратятся – к названию этой
очереди из кластера, автоматически получили или получат уведомление о вновь
созданном экземпляре. С момента уведомления об экземпляре менеджеры могут
посылать ему сообщения.
Выбор определенного экземпляра, которому будет адресовано сообщение, осуществ­
ляется менеджером, обычно с частичным репозиторием, к которому подключено
приложение-отправитель.
При первом же обращении к очереди с определенным названием приложением,
подключенным к менеджеру очередей он оформляет на полном репозитории под­
писку на информацию об имеющихся в составе кластера экземплярах интересующей
очереди. В дальнейшем менеджер автоматически информируется об изменении
экземпляров, их удалении или их добавлении.
Чтобы получить преимущества от балансировки нагрузки, приложение не должно
задавать название конкретного менеджера при открытии очереди функцией MQOPEN.
Примечание. Если при открытии очереди название менеджера указано, то
в целях балансировки нагрузки можно воспользоваться описанными в разделе
8.1.7 «Совместный доступ к объектам-очередям в кластерах» объектами-очередями сообщений. Так часто и поступают с сообщениями, приходящими от менеджеров очередей извне кластера, когда агент-получатель открывает очередь, пользуясь названием менеджера, заданным в заголовке транспортной очереди.
8.4.1. Работа с привязкой при открытии
и без фиксированной привязки
В процессе своего выполнения приложение может отослать множество сообщений,
адресованных одной службе, реализованной внутри кластера и распознаваемой по
названию очереди.
Нередко каждое сообщение может направляться различным экземплярам упомяну­
той службы, и это не окажет отрицательного воздействия на работу программы,
инициировавшей запрос. Если служба-получатель сообщений действует по модели
«запрос – ответ», каждое посланное отправителем сообщение содержит явное указа­
ние на то, кому конкретно служба должна ответить, и контекста в ее работе не требу­
ется. Такой порядок функционирования очень эффективен с позиции балансировки
186
Глава 8
нагрузки и может повышать устойчивость приложения к недоступности отдельного
экземпляра интересующей службы.
Однако ведущийся двумя приложениями обмен может иметь характер диалога по
схеме «запрос – ответ – запрос и т. д.», которая основана на контексте, сформирован­
ном предыдущими сообщениями. Взаимосвязь между ними называют сродством
сообщений (message affinity). При наличии такового приложению может понадобить­
ся привязка (bind) к конкретному экземпляру службы в составе кластера. Для обеспе­
чения привязки приложение может явно указать одну из двух опций менеджера при
открытии очереди.
 Привязка при открытии.
Все сообщения, отсылаемые при помощи описателя, полученного от функции MQOPEN,
и до момента вызова MQCLOSE , направляются одному и тому же входящему в кластер
экземпляру очереди сообщений. Балансировка нагрузки выполняется лишь однаж­
ды – при открытии очереди со стороны приложения.
 Без фиксированной привязки.
Балансировка нагрузки производится каждый раз, когда, используя описатель объек­
та, приложение размещает сообщение в очереди.
Поведение по умолчанию определяется атрибутом «привязка по умолчанию»
(DEFBIND – default bind) экземпляра очереди сообщений, входящего в состав кластера
и выбранного при вызове MQOPEN . Этот атрибут задается в объекте очереди, разде­
ляемом внутри кластера и расположенном на менеджере, который создал этот объект
и обеспечил совместный доступ к нему из кластера.
Примечание. Существующим приложениям, в которых применяется функция
MQPUT1 или вызовы MQOPEN и MQCLOSE для размещения каждого сообщения,
не удастся воспользоваться преимуществами привязки при открытии. Такие
приложения необходимо модифицировать для многократного размещения
сообщений с применением одного описателя или – что еще лучше – устранения
сродства сообщений.
8.4.2. Алгоритм балансировки нагрузки
Каждый раз, когда менеджер выбирает место назначения сообщений в кластере по наз­
ванию очередей, вызывается встроенный в него алгоритм балансировки нагрузки.
Упрощенно – при настройках по умолчанию и успешном установлении канала к
каждому менеджеру очередей внутри кластера – балансировку нагрузки можно рас­
сматривать как круговое распределение сообщений. В результате если приложение
без привязки разместило 1000 сообщений, а на 10 кластерных менеджерах размеще­
но 10 одноименных очередей, то приложениям на этих очередях под управлением
каждого из 10 менеджеров поступит около 100 сообщений.
Впрочем, эта оценка не точна и зависит от многих факторов. В этом разделе мы
только в общих чертах опишем, как работает алгоритм балансировки нагрузки и как
можно его настроить, используя возможности WebSphere MQ V6.0. Подробности
Кластеры менеджеров очередей
187
процесса выработки решения алгоритмом при каждом вызове такового читайте в ру­
ководстве WebSphere MQ Queue Manager Clusters, SC34-6589.
8.4.3. Порядковые номера мест назначения сообщений
Для выполнения кругового алгоритма балансировки менеджер очередей сообщений
локально хранит порядковый номер места назначения сообщения для каждого извест­
ного ему кластерного менеджера очередей.
Примечание. Присвоение номеров ведется на уровне кластерных каналов
сообщений, однако в большинстве ситуаций каждый подобный известный менеджеру канал соответствует одному менеджеру очередей в кластере.
Алгоритм балансировки нагрузки отдает предпочтение такому подходящему менед­
жеру очередей назначения, порядковый номер которого наименьший.
Порядковый номер места назначения возрастает всякий раз, когда этому менеджеру
поступает сообщение через кластер. Увеличение номеров не зависит от конкретной
очереди, а значит, сообщения, приходящие экземпляру очереди с одним названием,
влияют на балансировку нагрузки, создаваемой сообщениями из этого кластера,
адресованными экземплярам очередей с другими названиями, но под управлением
того же самого менеджера. Сюда относится и передача команд другим менеджерам
для поддержания актуальности данных в репозиториях кластера, и указание конкрет­
ного менеджера очередей сообщений при отправке таковых приложениями.
В условиях настройки по умолчанию увеличение номера одинаково при передаче
каждого сообщения. Поэтому в описанном выше элементарном примере сообщения
распределяются равномерно.
Однако существует ряд других обстоятельств, влияющих на работу алгоритма баланси­
ровки нагрузки. Обсуждению таких факторов мы и посвятим окончание этой главы.
Расположим влияющие на алгоритм факторы в том порядке, в котором их анализи­
рует алгоритм. Порядковый номер места назначения сообщения окажется в этом
случае лишь последним, поскольку он обеспечивает балансировку только для подхо­
дящих мест назначения – «кандидатов».
Примечание. Контроль порядковых номеров во время его работы ведется
менеджером очередей сообщений WebSphere MQ V6.0. Задача менеджера –
учитывать происходящие изменения, к примеру возобновление работы менеджеров очередей внутри кластера. Сброс порядковых номеров всех каналов без исключения можно принудительно провести, перезапустив менеджер.
8.4.4. Блокировка очереди на запись
Если обобществленная в кластере очередь блокирована на запись, информация
об этом публикуется и передается всем заинтересованным в ней менеджерам очере­
дей кластера.
188
Глава 8
Попытки отослать сообщение блокированным на запись экземплярам очередей
предпринимаются лишь тогда, когда все прочие экземпляры очередей в кластере
недоступны.
Примечание. Если сообщения явно передаются данному менеджеру, а никаких прочих доступных экземпляров очередей с соответствующим названием
в кластере не находится, сообщения доставляются этому менеджеру. Их обработкой занимается MCA-получатель, о чем рассказано в разделе 7.4.1 «Отправка
сообщений».
8.4.5. Балансировка нагрузки и локальное
размещение очередей
Если подключенное к менеджеру очередей приложение размещает сообщение, указав
имя объекта – локальной очереди в составе своего менеджера, по умолчанию всегда
используется локальный экземпляр очереди, если он не является заблокированным
на запись.
В WebSphere MQ V6.0 поведение по умолчанию можно изменить для того, чтобы,
задействовав балансировку нагрузки, обращаться с локальной и удаленными очере­
дями кластера одинаково.
Поведение по умолчанию для всех очередей менеджера можно изменить, пользуясь
атрибутом «очередь с кластерной балансировкой нагрузки» (CLWLUSEQ – cluster work­
load use queue) объекта – менеджера очередей сообщений.
На уровне очереди принятое для всего менеджера поведение по умолчанию можно
изменить, пользуясь атрибутом «очередь с кластерной балансировкой нагрузки»
(CLWLUSEQ – cluster workload use queue) конкретной локальной очереди сообщений.
8.4.6. Ранг менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджеры очередей в кластере могут ранжироваться заданием
или изменением атрибута «ранг кластерной балансировки нагрузки» (CLWLRANK – clus­
ter workload rank) кластерного receiver-канала, который был использован менедже­
ром для подключения к кластеру.
Пока в кластере существуют экземпляры очередей с соответствующим названием и
разрешенной записью, экземпляры очередей на менеджерах с бо' льшим рангом при
выборе всегда имеют приоритет над экземплярами на менеджерах с меньшим рангом.
Отдельные экземпляры очередей также могут ранжироваться при помощи атрибута
«ранг кластерной балансировки нагрузки» (CLWLRANK – cluster workload rank) объектаочереди, обобществленного внутри кластера. Алгоритмом балансировки ранг
от­дельных очередей принимается во внимание после анализа ранга менеджеров.
Ранжирование способно принудительно выбрать итоговое место назначения в клас­
тере. Оно полезно в процессе объединения нескольких кластеров и описания соеди­
няющих их маршрутов. Ранжирование полезно для описания порядка маршрутиза­
Кластеры менеджеров очередей
189
ции сообщений между объединенными кластерами и выбора оптимального места
назначения сообщений.
8.4.7. Приостановка менеджеров очередей в кластере
Если входящий в кластер менеджер приостановлен, как это описано в разделе 8.3.1
«Приостановка и возобновление работы менеджера очередей в кластере», то алго­
ритм балансировки нагрузки выбирает другие менеджеры, предпочитая их данному.
Приступая к плановому обслуживанию определенного менеджера, полезно обеспе­
чить отсутствие адресуемых ему сообщений от приложений, которые не должны
присылать их до тех пор, пока он снова не станет для них доступен.
Впрочем, если других доступных экземпляров очереди с соответствующим названи­
ем нет, сообщения будут по-прежнему поступать на приостановленный менеджер.
8.4.8. Состояние канала
Предпочтение перед другими при выборе имеют экземпляры очередей менеджеров,
каналы к которым уже запущены или стали естественно неактивны.
Если такие экземпляры не обнаружены, выбираются экземпляры под управлением
тех менеджеров, каналы к которым находятся в процессе установления.
Если найти их не удается, выбираются менеджеры очередей сообщений, каналы к ко­
торым ранее дали сбой и находятся в процессе повторного подключения. Того
момента, когда канал будет перезапущен, сообщения ожидают в кластерной транс­
портной очереди.
Если экземпляры очередей находятся только в составе менеджеров, каналы к кото­
рым требуют перезапуска ручным способом, включая остановленные каналы, сооб­
щения должны отсылаться подобным менеджерам и оставаться в транспортной оче­
реди, пока ручной запуск каналов не будет произведен.
Такое поведение позволяет автоматически обходить сбои отдельных кластерных
менеджеров.
8.4.9. Приоритет менеджеров и очередей сообщений
В WebSphere MQ V6.0 менеджерам очередей внутри кластера может назначаться прио­
ритет, для чего задается или меняется атрибут «приоритет кластерной балансировки
нагрузки» (CLWLPRTY – cluster workload priority) кластерного receiver-канала, который
был использован менеджером для подключения к кластеру.
Экземплярам очередей под управлением менеджера с бо' льшим приоритетом при
выборе обычно отдается предпочтение над экземплярами очередей менеджера
с меньшим приоритетом.
Однако в тех случаях, когда менеджер, имеющий больший приоритет, почему-либо
считается недоступным, выбираются экземпляры очередей менеджера, приоритет
которого меньше. Так нужные менеджеры могут оказаться приостановлены, или
каналы к ним могут дать сбой.
190
Глава 8
Приоритет отдельных экземпляров очередей может устанавливать атрибут «приори­
тет кластерной балансировки нагрузки» (CLWLPRTY – cluster workload priority) объектаочереди, обобществленного внутри кластера. Алгоритмом балансировки приоритет
отдельных очередей принимается во внимание после приоритета менеджеров.
Приоритеты позволяют размещать службы на вторичных – или резервных – ресур­
сах кластера. Такие ресурсы могут находиться на географически удаленных площад­
ках, а значит, медленнее работать. При этом они могут выполнять функцию первич­
ных ресурсов для других служб системы, так что отправка запросов им при нормаль­
ной работе ухудшит производительность данных первичных служб. Однако, если
на тех ресурсах, где обычно размещена служба, произойдет сбой, резервные ресурсы
дадут возможность обеспечить ее доступность.
8.4.10. Ограничение кластерных подключений от менеджера
Если к службе системы обращается множество приложений, а в целях управления
нагрузкой организован ряд ее экземпляров, распределение нагрузки всех приложе­
ний по всем существующим экземплярам может оказаться неэффективным. Оно
может привести к ситуации, когда количество активных каналов на каждом управля­
ющем службой менеджере очередей сообщений будет достаточно велико.
WebSphere MQ V6.0 позволяет ограничить число участвующих в балансировке
нагрузки экземпляров на одном менеджере. В итоге прочие экземпляры останутся не
затронуты балансировкой по порядковым номерам.
Предельное значение определяется максимальным числом каналов, которые можно
установить от одного менеджера в кластере к другим. Непосредственно для настрой­
ки служит атрибут «количество недавно использованных каналов менеджера клас­
терной балансировки нагрузки» (CWMRUC – cluster workload manager recently used chan­
nel) объекта – менеджера очередей сообщений.
Установив предел для всех менеджеров, которые обращаются к службе, вы сможете
сократить и количество одновременно установленных каналов, ведущих к менедже­
ру, где она выполняется.
8.4.11. Весовая оценка менеджеров
Одни машины, где работают службы, могут быть мощнее других, а стало быть, в со­
стоянии обслужить больше запросов, чем остальные компьютеры с той же системной
службой.
В WebSphere MQ V6.0 менеджерам очередей в кластере могут назначаться веса от 1 до
99, для чего задается или изменяется атрибут «вес кластерной балансировки нагруз­
ки» ( CLWLWGHT – cluster workload weight) кластерного receiver-канала, который был
использован менеджером для подключения к кластеру.
Алгоритм кластерной балансировки нагрузки посылает больше сообщений тем
менеджерам, чей вес выше. Количество получаемых ими сообщений пропорциональ­
но их весу.
Для получения этого результата алгоритм увеличивает порядковые номера мест
назначения всех менеджеров на значение, привязанное к их весу. Чем выше вес менед­
Кластеры менеджеров очередей
191
жера, тем меньше прибавляет алгоритм к номеру, отправляя каждое сообщение. Вели­
чина приращения есть частное от деления 1000 на вес определенного менеджера.
К примеру, пусть нам доступны два менеджера очередей сообщений с весами 60 и 20,
а номера мест назначения одинаковы. Между очередями с одним названием под
управлением этих менеджеров распределим четыре сообщения. Три из них будут
адресованы менеджеру, вес которого 60, и лишь одно – менеджеру, вес которого 20.
Причина этого в том, что оба номера назначения станут больше на 50:
 (1000 / 60) × 3 = 50;
 (1000 / 20) × 1 = 50.
192
Глава 8
9
Обмен сообщениями
с использованием WebSphere
MQ: практическое введение
Эта глава посвящена созданию, запуску и администрированию локальных менедже­
ров очередей WebSphere MQ. Изучив ее, вы освоите работу с WebSphere MQ Explorer
и применение управляющих команд WebSphere MQ. Вы также найдете здесь пошаго­
вые инструкции для решения общих задач конфигурирования менеджеров очередей
с использованием WebSphere MQ Explorer и сценариев MQSC. Межточечный обмен
сообщениями (по принципу «точка-точка», point-to-point), как и рассылка сообще­
ний по подписке (publish/subscribe messaging), осуществляется с использованием ло­
кальной инфраструктуры WebSphere MQ, построение которой – ваша задача. Эта ин­
фраструктура включает менеджер очередей, в котором работает служба, поддер­
живающая интерфейс запросов-ответов. Эта служба запускается при добавлении
сооб­щений в очередь.
В этой главе обсуждаются следующие темы:





Обзор глав с практическими заданиями
Настройка окружения
Обмен сообщениями с использованием локального менеджера очередей
Создание службы обработки запросов и ответов на основе очереди
Рассылка сообщений по подписке в WebSphere MQ с использованием JMS
Обмен сообщениями с использованием WebSphere MQ: практическое введение 193
9.1. Обзор глав с практическими заданиями
Эта книга содержит практическое введение в очереди сообщений WebSphere MQ, ко­
торое разбито на две главы.
 В этой главе вы научитесь создавать и администрировать менеджеры очередей,
обеспечивающие доступ к службам обработки сообщений. Эти службы доступны
посредством менеджеров очередей и поддерживают различные модели обмена
сообщениями: межточечный обмен либо рассылку сообщений по подписке.
 В главе 10 вы научитесь связывать менеджеры очередей с использованием
TCP/IP-сетей как в центрально-лучевую (hub-and-spoke) инфраструктуру, так и
в кластеры с целью предоставления доступа к этим службам.
При изучении материалов введения вы будете пользоваться административными
интерфейсами и примерами приложений из состава WebSphere MQ.
9.1.1. Администрирование менеджеров очередей
Многие административные задачи решаются с использованием WebSphere MQ
Explorer либо интерфейса сценариев MQSC. Ниже приводятся пошаговые инструкции
для обоих случаев.
Если у вас нет опыта работы с WebSphere MQ, рекомендуем воспользоваться Web­
Sphere MQ Explorer. По мере накопления знаний можно приступать к освоению
MQSC – так вы научитесь создавать сценарии для решения описанных в этой главе
задач. Так, процедуры контроля изменений могут требовать сценариев MQSC для
внесения любых изменений в производственной среде.
Примечание. Здесь и далее используются имена в нижнем регистре как
оптимальные для администрирования с применением WebSphere MQ Explorer.
Следите, чтобы в командах MQSC значения атрибутов и имена объектов, содержащие
символы в нижнем регистре, были заключены в одинарные кавычки. Регулярное
применение кавычек – общая рекомендация при работе с MQSC, позволяющая избе­
жать путаницы.
9.1.2. Программы-примеры в WebSphere MQ
С WebSphere MQ поставляется множество программ-примеров, как в виде исходного
кода, так и в прекомпилированном, готовом к применению виде. В этой книге приво­
дятся примеры на языке программирования С, использующие интерфейс очередей
сообщений (MQI) для демонстрации межточечного обмена сообщениями. Имеются
также аналогичные примеры на других языках программирования.
Примеры на языке Java, использующие JMS – стандартный интерфейс прикладного
программирования (API), – иллюстрируют обмен сообщениями по механизму пуб­
ликации-подписки. По большому счету то же верно для клиентов IBM Message Service
(XMS).
194
Глава 9
Обмен сообщениями по подписке также может быть реализован при помощи соот­
ветствующих команд WebSphere MQ, адресованных брокеру публикации-подписки
WebSphere MQ. Это возможно с использованием любого из API для межточечного
обмена сообщениями, поддерживаемого WebSphere MQ.
Прежде чем приступать к созданию решений на основе WebSphere MQ, прикладным
программистам рекомендуется изучить прилагаемые примеры исходного кода на С
либо других языках программирования. Эти примеры послужат хорошей отправной
точкой при разработке и тестировании таких решений.
9.2. Настройка окружения
В этой главе предполагается, что вы работаете на сервере под управлением ОС
Windows или Linux с WebSphere MQ V6.0. Впрочем, все задачи (за исключением свя­
занных с WebSphere MQ Explorer) могут быть выполнены удаленно на UNIX-сервере
с WebSphere MQ V6.0.
Примечание. Если вы работаете с WebSphere MQ на Linux-сервере, следуйте
отдельным инструкциям, приведенным ниже.
9.2.1. Установка WebSphere MQ V6.0
Подробнее об установке сервера WebSphere MQ см. в руководстве WebSphere MQ V6.0
Quick Beginnings для соответствующей платформы:
 WebSphere MQ для Windows V6.0 Quick Beginnings, GC34-6476
 WebSphere MQ для Linux V6.0 Quick Beginnings, GC34-6480
Установите все необходимые и дополнительные компоненты, сделайте необходимые
настройки.
9.2.2. Привилегии администратора WebSphere MQ
Учетная запись, под которой вы входите в систему, должна иметь привилегии адми­
нистратора WebSphere MQ.
 В Windows: ваша учетная запись должна быть членом одной из следующих групп:
– Administrators,
– mqm.
 В UNIX: ваша учетная запись должна быть членом группы
– mqm.
9.2.3. Доступ к примерам WebSphere MQ
Каталог с примерами WebSphere MQ должен быть в пути поиска, заданном соответст­
вующей переменной окружения в ОС. При установке WebSphere MQ в Windows это
делается автоматически.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
195
Примеры WebSphere MQ устанавливаются в следующий каталог.
 В Windows: C:\Program Files\IBM\WebSphere MQ\Tools\c\Samples\Bin
 В UNIX (кроме IBM AIX 5L): /opt/mqm/samp/bin – добавьте этот путь к пути поиска
текущего терминального сеанса, например так:
PATH=$PATH:/opt/mqm/samp/bin
export PATH
 В IBM AIX 5L: /usr/mqm/samp/bin – добавьте этот путь к пути поиска текущего
терминального сеанса, например так:
PATH=$PATH:/usr/mqm/samp/bin
export PATH
9.2.4. Замечания о Java
Действия, описанные в разделе 9.5, требуют установки пакета Java Development Kit
(JDK), расположенного в каталоге prereqs на установочном носителе WebSphere MQ
V6.0. Если установить JDK невозможно, упражнения, посвященные обмену сообще­
ниями по подписке, следует пропустить.
9.3. Обмен сообщениями с помощью
локального менеджера очередей
В этом разделе вы познакомитесь с графическим интерфейсом, а также с интерфей­
сом командной строки, применяемым для создания, запуска, завершения и удаления
менеджеров очередей. Кроме того, вы научитесь добавлять и извлекать из очереди
тестовые сообщения, а также просматривать содержимое очередей с использованием
WebSphere MQ Explorer и программ-примеров WebSphere MQ.
Ниже предполагается, что вы знакомы с интерфейсами и примерами из этого раз­
дела.
9.3.1. Создание менеджера очередей по умолчанию
Ниже показано, как создать на компьютере менеджер очередей и назначить его
менеджером очередей по умолчанию.
Это делается при помощи мастера WebSphere MQ Explorer Create Queue Manager либо
команды crtmqm WebSphere MQ.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queue Managers в навигаторе и выберите New\
Queue Manager – откроется страница Enter Basic Values (Step 1) мастера Create
Queue Manager.
2. Введите host1/qm1 в поле Queue manager name.
3. Установите параметр Make this the default queue manager.
196
Глава 9
4. Для остальных параметров примите значения по умолчанию и щелкните Next,
не щелкая кнопку Finish, – откроется страница Enter log values (Step 2).
5. Оставьте на этой странице значения по умолчанию и щелкните Next, не щелкая
Finish, – откроется страница Enter configuration options (Step 3).
6. Снимите флажок Start queue manager.
Примечание. Флажок Start queue manager позволяет автоматически выполнить действия, описанные в разделе 9.3.2.
Параметр Auto start менеджера очередей поддерживается только в Windows и
позволяет автоматически запустить менеджер очередей при перезагрузке
компьютера. 7. Для остальных полей оставьте значения по умолчанию и щелкните Next, не щелкая
Finish, – откроется страница Enter listener options (Step 4).
Примечание. Если на вашем компьютере уже есть менеджер очередей с
компонентом-слушателем WebSphere MQ, привязанным к стандартному TCP/IPпорту, на этой странице может появиться сообщение «The port is already used by
another WMQ Listener».
8. Снимите флажок Create listener configured for TCP/IP.
Примечание. Этот флажок позволяет автоматически выполнить действия,
описанные в разделе 10.2.1.
9. Для остальных полей оставьте значения по умолчанию и щелкните Next, не щелкая
Finish, – откроется страница Enter explorer options (Step 5).
10.Оставьте значения по умолчанию на этой странице и щелкните Finish.
11.Откроется окно Creating Queue Manager «host1/qm1» с сообщением о состоянии.
Примечание. Если щелкнуть Show details в этом окне, можно просматривать
команды WebSphere MQ, исполняя которые WebSphere MQ Explorer создает
менеджер очередей. При этом после завершения установки (выводом сообщения
Finished в главном окне) окно состояния следует закрыть вручную.
12.Завершив это упражнение, убедитесь, что в окне навигатора в папке Queue Manag­
ers отображается менеджер очередей в виде значка, соответствующего останов­
ленному локальному менеджеру очередей.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
197
Применение управляющих команд WebSphere MQ
Выполните следующую команду, чтобы создать менеджер очередей в конфигурации
по умолчанию и сделать его менеджером очередей по умолчанию на данном ком­
пьютере:
crtmqm -q host1/qm1
Примечание. В отсутствие параметра -q созданный менеджер не станет
менеджером очередей по умолчанию на данном компьютере.
Эта команда генерирует следующий вывод:
WebSphere MQ queue manager created.
Creating or replacing default objects for host1/qm1.
Default objects statistics : 43 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
Следующая команда позволяет проверить, создан ли менеджер очередей:
dspmq
Эта команда генерирует следующий вывод:
QMNAME(host1/qm1) STATUS(Ended immediately)
9.3.2. Запуск менеджера очередей по умолчанию
Ниже показано, как запустить созданный ранее менеджер очередей. Это делается
с помощью WebSphere MQ Explorer либо управляющих команд amqmdain/strmqm
WebSphere MQ.
В управляющих командах WebSphere MQ не обязательно указывать имя менеджера
очередей, поскольку эти команды адресованы менеджеру очередей по умолчанию.
Применение WebSphere MQ Explorer
Щелкните правой кнопкой менеджер очередей host1/qm1 в окне навигатора и выбе­
рите Start – откроется окно, похожее на то, что отображалось во время создания
менеджера очередей.
Завершив это упражнение, убедитесь, что в окне навигатора в папке Queue Managers
отображается менеджер очередей в виде значка, соответствующего работающему
локальному менеджеру очередей.
Применение управляющих команд WebSphere MQ
Команды для UNIX и Windows отличаются следующим:
 Windows:
amqmdain qmgr start
198
Глава 9
Примечание. Эта команда позволяет запустить менеджер очередей так,
чтобы при выходе из системы и входе в нее он не останавливался. В UNIX
аналогичная команда работает, но при выходе из системы запущенный ей
менеджер очередей завершается.
В WebSphere MQ для Windows V5.3 используйте следующую команду:
amqmdain start host1/qm1
 UNIX:
strmqm
Эта команда генерирует следующий вывод:
WebSphere MQ queue manager ‘host1/qm1’ starting.
5 log records accessed on queue manager ‘host1/qm1’ during the log replay
phase.
Log replay for queue manager ‘host1/qm1’ complete.
Transaction manager state recovered for queue manager ‘host1/qm1’.
WebSphere MQ queue manager ‘host1/qm1’ started.
Примечание. Следующий вывод свидетельствует о том, что данный менеджер очередей не является менеджером очередей по умолчанию на этом компьютере:
AMQ8118: WebSphere MQ queue manager does not exist.
Чтобы проверить это либо сделать текущий менеджер очередей менеджером по умолчанию, выполните следующие действия.
 Применение WebSphere MQ Explorer (в Windows):
a) щелкните правой кнопкой IBM WebSphere MQ в окне навигатора и выберите
Properties;
b) проверьте и при необходимости отредактируйте поле Default queue manager
name. В нем должно быть следующее значение:
host1/qm1
c) щелкните OK.
 применение файла mqs.ini в UNIX:
a) откройте файл mqs.ini в текстовом редакторе, таком как vi или emacs. Файл mqs.ini находится в каталоге
/var/mqm/mqs.ini
b) найдите строку
DefaultQueueManager:
c) если эта строка не существует, добавьте ее в конце файла;
d) затем добавьте следующую строку:
Name=host1/qm1
Обмен сообщениями с использованием WebSphere MQ: практическое введение
199
9.3.3. Создание локальной очереди
В этом разделе рассказывается, как определить новый объект локальной очереди
в менеджере очередей. Объект локальной очереди представляет очередь, обслуживае­
мую менеджером очередей, в которую можно добавлять сообщения, а также получать
сообщения из нее.
Это делается с использованием WebSphere MQ Explorer либо команды MQSC DEFINE,
поддерживаемой командой runmqsc. Команда runmqsc служит для отправки команд
MQSC менеджеру очередей.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Раскройте значок менеджера очередей host1/qm1 в навигаторе – откроется папка
Queues менеджера.
2. Щелкните правой кнопкой папку Queues и выберите New\Local Queue – откроется
страница «Enter a name» (с значком в виде красного креста) мастера Create Local
Queue.
3. Введите queue1 в поле Name.
4. Щелкните Next, не щелкая Finish, – откроется страница Change the properties of
the new Local Queue, на которой можно задать исходные атрибуты объекта ло­
кальной очереди.
5. Введите в поле Description следующее:
Redbook example queue1: Newly defined
6. Щелкните Finish – на некоторое время откроется индикатор хода выполнения,
затем окно результатов с сообщением:
The object was created successfully. (AMQ4148)
Применение команд MQSC
Выполните следующие действия.
1. Запустите интерактивный сеанс MQSC для менеджера очередей по умолчанию
следующей командой:
runmqsc
2. После запуска интерактивный сеанс MQSC ожидает ввода, отображая мигающий
курсор, и генерирует следующий вывод:
5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
Starting MQSC for quew host1/qm1.
Теперь сеанс готов к приему ввода, дополнительное сообщение о запуске сеанса
не отображается.
200
Глава 9
Примечание. Если менеджер очередей не запустился или не назначен
менеджером по умолчанию, генерируется следующий вывод и отображается
обычное приглашение ОС:
5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED.
AMQ8146: WebSphere MQ queue manager not available.
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
3. Выполните следующую команду, чтобы создать очередь:
DEFINE QLOCAL('queue1') + DESCR('Redbook example queue1: Newly defined')
Примечание. Для использования символов в нижнем регистре в именах и описаниях важно использовать одинарные кавычки (см. пример выше).
Заметьте, что символ «+» завершает первую строку и перед ним после скобки
стоит пробел. Это позволяет создавать многострочные команды MQSC.
Команда генерирует следующий вывод:
AMQ8006: WebSphere MQ queue created.
Примечание. Если предпринять несколько попыток создания очереди, то
попытки, следующие за успешным созданием, окончатся неудачей и выводом
следующего сообщения:
AMQ8150: WebSphere MQ object already exists.
В этом случае добавьте к команде атрибут REPLACE, например так:
DEFINE QLOCAL('queue1') REPLACE + DESCR(‘Redbook example queue1:
Newly defined’)
4. Выйдите из интерактивного сеанса MQSC, выполнив команду
END
Вы вернетесь в командную строку ОС, и будет сгенерирован вывод со сводкой ко­
манд, выполненных во время сеанса, например:
END
2 : END One MQSC command read. No commands have a syntax error. All valid MQSC
commands were processed.
9.3.4. Отображение атрибутов новой очереди
Атрибут описания (DESCR) хранится в определении объекта. Все остальные атрибуты
имеют значения по умолчанию. Например, для атрибута, определяющего постоянс­
тво сообщений по умолчанию (DEFPSIST), задано значение NO (непостоянные). Зна­
Обмен сообщениями с использованием WebSphere MQ: практическое введение
201
чение неизменяемого атрибута CURDEPTH, определяющего текущую длину очереди,
показывает, что длина новой очереди равна нулю.
Просмотр значения атрибутов возможен с помощью WebSphere MQ Explorer (сред­
ствами схемы WebSphere MQ Explorer) либо команды runmqsc, поддерживающей
использование символов обощения и значений атрибутов в командах MQSC DISPLAY.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выделите папку Queues в менеджере очередей host1/qm1, расположенном в папке
Queue Managers навигатора.
2. В таблице отображается строка с описанием очереди queue1. В столбцах таблицы
выводятся значения атрибутов очереди. Прокрутите таблицу вправо для просмот­
ра значений атрибутов Description, Persistence и Current queue depth.
3. Можно изменять порядок столбцов по умолчанию, а также сохранять настроен­
ный вид таблицы с помощью схем WebSphere MQ. Внизу таблицы отображается
следующий текст:
Scheme: Standard for Queues – Distributed
Это свидетельствует об использовании схемы столбцов по умолчанию, а также
о том, что этот менеджер очередей не относитcя к числу менджеров очередей
WebSphere MQ для z/OS. Обычно термин distributed (распределенный) обозначает
любые платформы, кроме мейнфреймов.
Справа от текста находится стрелка. Щелкните ее – откроется меню со списком
готовых схем, которые можно применить к таблице, а также команд для редакти­
рования схем и управления ими.
Щелкните Manage Schemes – откроется окно, в котором можно создать собствен­
ные или отредактировать существующие схемы для таблиц, отображающих сведе­
ния об очередях в WebSphere MQ Explorer.
Например, можно переместить столбцы Description, Persistence и Current queue
depth в начало таблицы.
Применение команды MQSC
Выполните следующие действия.
1. Запустите интерактивный сеанс MQSC для менеджера очередей по умолчанию
следующей командой:
runmqsc
2. Следующей командой MQSC выведите список объектов локальных очередей:
DISPLAY QLOCAL(*)
Вывод этой команды содержит сводку всех локальных очередей; в этом примере
отображаются сведения об очереди queue1:
AMQ8409: Display Queue details. QUEUE(queue1) TYPE(QLOCAL)
202
Глава 9
3. Исполните следующую команду MQSC для просмотра всех атрибутов этой оче­реди:
DISPLAY QLOCAL(‘queue1’) ALL
Команда выводит значения множества атрибутов.
Примечание. Для использования символов в нижнем регистре в именах
объектов важно использовать одинарные кавычки (см. пример выше). В противном случае вы получите сообщение об ошибке:
AMQ8147: WebSphere MQ object QUEUE1 not found.
4. Чтобы просматривать только такие атрибуты, как постоянство по умолчанию,
описание и текущая длина очереди, выполните следующую команду MQSC:
DISPLAY QLOCAL('queue1') DEFPSIST DESCR CURDEPTH
Эта команда генерирует следующий вывод:
AMQ8409: Display Queue details. QUEUE(queue1) TYPE(QLOCAL) CURDEPTH(0)
DEFPSIST(NO) DESCR(Redbook example queue1: Newly defined)
5. Выполните следующую команду, чтобы выйти из интерактивного сеанса MQSC:
END
Примечание. Команда MQSC DISPLAY QUEUE позволяет выводить атрибуты
любого объекта очереди независимо от его типа. Например, следующая команда
отображает все объекты очередей, определенные в менеджере очередей:
DISPLAY QUEUE(*)
9.3.5. Модификация атрибутов объекта очереди
Ниже рассказано, как изменить атрибуты существующего объекта очереди с помо­
щью WebSphere MQ Explorer и команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выделите папку Queues менеджера очередей host1/qm1, расположенную в папке
Queue Managers навигатора.
2. Щелкните правой кнопкой строку queue1 в таблице и выберите команду
Properties либо щелкните дважды эту строку – откроется окно свойств объекта
локальной очереди.
3. Введите в поле Description следующий текст:
Redbook example queue1: Altered description
4. Щелкните OK – на короткое время откроется окно с индикатором хода операции.
5. Обратите внимание на изменение атрибута-описания объекта локальной очереди
в таблице очередей.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
203
Применение команд MQSC
Выполните следующие действия.
1. Запустите интерактивный сеанс MQSC для менеджера очередей по умолчанию
командой
runmqsc
2. Выполните следующую команду MQSC, чтобы изменить атрибут с описанием
очереди:
ALTER QLOCAL('queue1') + DESCR('Redbook example queue1: Altered description')
Примечание. Для использования символов в нижнем регистре в именах
объектов важно использовать одинарные кавычки (см. пример выше). В противном случае вы получите сообщение об ошибке:
AMQ8147: WebSphere MQ object QUEUE1 not found.
3. Чтобы вывести обновленный атрибут очереди, выполните следующую команду:
DISPLAY QLOCAL(‘queue1’) DESCR
4. Выполните следующую команду, чтобы выйти из интерактивного сеанса MQSC:
END
9.3.6. Добавление тестовых сообщений в очередь
Ниже рассказывается, как поместить в ранее созданную очередь сообщения с произ­
вольным текстом при помощи WebSphere MQ Explorer и программы-примера amqsput
для WebSphere MQ, работающей с менеджером очередей по умолчанию на данном
компьютере.
Видно, что после добавления сообщений в очередь значение ее атрибута «текущая
длина» (CURDEPTH) изменяется и отражает число добавленных сообщений. О про­
смотре этого атрибута см. в разделе 9.3.4.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выделите папку Queues менеджера очередей host1/qm1, расположенную в папке
Queue Managers в окне навигатора.
2. Щелкните правой кнопкой строку queue1 в таблице и выберите команду Put Test
Message – откроется одноименное окно.
3. Введите в поле Message data текст сообщения.
4. Щелкните Put message – поле Message data опустеет. Так можно ввести несколько
тестовых сообщений; после ввода каждого сообщения щелкайте Put message.
5. Щелкните Close, чтобы закрыть окно.
204
Глава 9
Применение программы-примера для WebSphere MQ
Примечание. Путь к каталогу с примерами программ для WebSphere MQ
должен быть добавлен к пути поиска в переменных окружения ОС.
Выполните следующие действия.
1. Выполните следующую команду:
amqsput queue1
Генерируется следующий вывод, после чего команда ожидает ввода пользователя:
Sample AMQSPUT0 start
target queue is queue1
2. Введите сообщение и нажмите клавишу Enter. Так можно ввести несколько тесто­
вых сообщений; после ввода каждого сообщения нажимайте Enter.
3. Чтобы выйти, нажмите Enter, не вводя текста.
Примечание. Если вы получаете сообщение об ошибке 2059 или 2058 (см. листинг ниже), проверьте, настроен ли менеджер очередей как менеджер по умолчанию (см. раздел 9.3.2) и работает ли он (командой dspmq):
Sample AMQSPUT0 start
MQCONN ended with reason code 2059
Получив сообщение, подобное следующему, проверьте имена указанной в команде очереди (включая регистр символов) и созданного объекта, о про­
смотре имен см. в разделе 9.3.4.
Sample
target
MQOPEN
unable
Sample
AMQSPUT0 start
queue is QUEUE1
ended with reason code 2085
to open queue for output
AMQSPUT0 end
Для толкования кодов возврата служит команда mqrc, принимающая код как
параметр. Ниже показаны примеры вывода mqrc для кодов 2058, 2059 и 2085:
2058 0x0000080a MQRC_Q_MGR_NAME_ERROR
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
2085 0x00000825 MQRC_UNKNOWN_OBJECT_NAME
Другие коды возврата MQCONN, MQOPEN и MQPUT также можно расшифровать
с помощью mqrc. Подробнее о кодах возврата см. в разделе «API completion and
reason codes» руководства WebSphere MQ Messages, GC34-6601.
9.3.7. Просмотр сообщений, добавленных в очередь
Здесь рассказывается, как осуществляется просмотр сообщений, находящихся в дан­
ный момент в очереди WebSphere MQ, без их удаления. Для просмотра доступно как
содержимое сообщений, так и сведения о них, хранимые в дескрипторах сообщений.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
205
Сообщения, добавляемые в очередь, являются непостоянными (nonpersistent messages). В поле reply-to queue manager сообщений автоматически записывается строка
host1/qm1 менеджером, в чью очередь добавлены эти сообщения.
Сообщения, генерация которых описана в разделе 9.3.6, представляли собой дейта­
граммы, то есть сообщения, не требующие ответа.
В силу этой причины значение reply-to queue не определялось WebSphere MQ Explorer
или программой-примером amqsput при добавлении сообщения.
Сейчас мы воспользуемся интерфейсом WebSphere MQ Explorer либо программойпримером amqsbcg для WebSphere MQ.
Примечание. Эти методы весьма удобны при разработке, тестировании и мониторинге очередей рабочих систем, поскольку такой метод просмотра никак
не влияет на содержащиеся в очереди сообщения.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой очередь в таблице менеджера очередей и выберите
Browse Messages – откроется окно с индикатором хода операции, а затем окно
Message browser.
2. Каждая строка в таблице, отображаемой в окне Message browser, представляет
одно из сообщений в очереди. В столбцах этой таблицы отображается информа­
ция о сообщении, которая находится в дескрипторе сообщения, а также содержи­
мое или данные сообщения. Настраивая схему таблицы, можно изменять порядок
столбцов, чтобы, например, переместить столбцы Persistence, Message type,
Message data, Reply-to queue и Reply-to Queue Manager в начало таблицы.
3. Некоторые типы сообщений лучше просматривать в виде двоичных данных, а не
текста. Для этого дважды щелкните строку таблицы, представляющую сообще­
ние, – откроется окно свойств сообщения. Щелкните секцию Data в этом окне.
Применение программ-примеров для WebSphere MQ
Выполните следующие действия:
1. Выполните следующую команду для просмотра сообщений в очереди менеджера
по умолчанию; вывод команды будет перенаправлен в файл queue1.txt:
amqsbcg queue1 > queue1.txt
2. Откройте queue1.txt в любом текстовом редакторе. Для каждого из сообщений
в файле содержатся сведения из дескриптора и содержимое в двоичном и тексто­
вом (справа) представлении.
Читать сведения из такого файла сложнее, чем в WebSphere MQ Explorer. Разберем
значение наиболее интересных полей вывода команды amqsbcg.
206
Глава 9
MsgType : 8
Тип 8 соответствует дейтаграммам. Запросы имеют тип 1, ответы – 2, отчеты – 4.
Persistence : 0
Значение «0» свидетельствует о том, что сообщение является непостоянным, а значе­
ние «1», напротив, говорит о том, что это сообщение является постоянным.
ReplyToQ : ‘ ‘
В этом поле отображается 48-значное имя очереди ответов (reply-to queue). Если
в имени меньше 48 символов, недостающие символы заменяются пробелами, распо­
ложенными справа. Такие данные называются дополненными пробелами (blankpadded), они часто используются в структурах WebSphere MQ. В этом примере данное
поле в дескрипторе сообщений пусто.
ReplyToQMgr : ‘host1/qm1 ‘
Это поле содержит 48-значное дополненное пробелами имя менеджера очереди
ответов (reply-to queue manager), оно автоматически заполняется менеджером очере­
дей при размещении сообщения.
**** Message ****
length – 20 bytes
00000000: 5265 6462 6F6F 6B20 7465 7374 206D 6573 00000010: 7361 6765 ‘Redbook test mes’
‘sage ‘
Здесь отображается содержимое сообщения в двоичном и (справа) в текстовом пред­
ставлении. Это существенно облегчает просмотр содержимого некоторых типов
сообщений, особенно объемных, которые проще просматривать в двоичном пред­
ставлении. Впрочем, содержимое простых тестовых сообщений из наших примеров
как раз удобнее просматривать в текстовом представлении.
9.3.8. Определение и использование псевдонимов
локальных очередей
Ниже рассказывается, как создать объект псевдонима очереди, ссылающийся на суще­
ствующую очередь, но имеющий другое имя.
Атрибуты объекта псевдонима очереди определяют параметры по умолчанию, с кото­
рыми сообщения добавляются в очередь, на которую ссылается псевдоним (его целе­
вую очередь). Так, ниже показано, что если настроить для псевдонима свойство
persistent, то сообщения, добавленные через этот псевдоним, будут постоянными.
Примечание. В данном примере для наглядности в одну и ту же очередь
добавляются сообщения двух типов: постоянные и непостоянные. Однако в
WebSphere MQ более эффективны очереди с сообщениями одного типа, поэтому
смешивать постоянные и непостоянные сообщения в одной очереди не рекомендуется.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
207
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues в host1/qm1 и выберите New\Alias
Queue – откроется страница «Enter a name» мастера New Alias Queue, помеченная
красным крестиком.
2. Введите queue1.persistent в поле Name.
3. Щелкните Next, не щелкая Finish, – откроется окно настройки свойств нового
псевдонима. В нем можно задать атрибуты объекта псевдонима очереди.
4. Введите queue1 в поле Base queue.
Примечание. В результате этого действия будет задан атрибут «целевая
очередь» (target queue, TARGQ) объекта псевдонима очереди.
5. Введите в поле Description следующее значение:
Redbook example alias to queue1: For persistent messages
6. Установите значение Persistent для поля Persistence.
7. Щелкните Finish, затем в окне сообщения AMQ4148 об успешном создании объек­
та щелкните OK.
8. Щелкните правой кнопкой новую строку в таблице Queues (queue1.persistent),
выберите Put Test Message и добавьте в очередь несколько сообщений.
9. Обратите внимание, что значение атрибута «текущая длина» очереди queue1 уве­
личилось. Просмотрите сообщения в очереди queue1, как описано в разделе 9.3.7.
Сообщения, добавленные в очередь через этот псевдоним, имеют атрибут Persis­
tent (постоянные), тогда как ранее добавленные сообщения имеют атрибут Not
Persistent (непостоянные).
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC (с использованием runmqsc):
DEFINE QALIAS('queue1.persistent') TARGQ('queue1') DEFPSIST(YES) +
DESCR('Redbook example alias to queue1: For persistent messages')
2. Проверьте атрибуты объекта псевдонима очереди при помощи следующей коман­
ды MQSC:
DISPLAY QALIAS('queue1.persistent') TARGQ DEFPSIST DESCR
Примечание. Помните, что имя queue1 должно быть в нижнем регистре,
поэтому при определении объекта псевдонима очереди важно заключать аргумент TARGQ в одинарные кавычки.
208
Глава 9
3. Выйдите из runmqsc командой END, затем добавьте к очереди несколько тестовых
сообщений через псевдоним с помощью программы-примера для WebSphere MQ
(передача пустой строки вызывает завершение программы):
amqsput queue1.persistent
4. Просмотрите сообщения в очереди, как описано в разделе 9.3.7. Обратите внима­
ние, что новые сообщения являются постоянными, а прежние (добавленные на­
прямую, без псевдонима) – нет.
9.3.9. Завершение и перезапуск менеджера очередей
Ниже рассказывается, как остановить менеджер очередей с помощью WebSphere MQ
Explorer или команды endmqm. Далее вы перезапустите менеджер очередей и про­
смотрите сообщения в очереди. Сообщения, являющиеся непостоянными, исчезнут,
а постоянные – останутся в очереди.
При этом будет выполнена т. н. «плавная» остановка менеджера очередей, во время
которой он уведомляет об остановке все подключенные к нему приложения, но не
прекращает принимать от них запросы.
Примечание. Также возможна немедленная остановка менеджера очередей,
при которой он завершает только текущие операции, но не выполняет больше
никаких действий. Этот метод используется, если работа менеджера очередей не завершается слишком долго. Немедленное завершение работы менеджера
очередей возможно и во время его «плавной» остановки.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой значок менеджера очередей в папке Queue Managers
и выберите команду Stop – откроется окно End Queue Manager.
2. В этом окне оставьте переключатель в положении Controlled.
Примечание. Управляемое завершение (controlled end) менеджера очередей в WebSphere MQ Explorer аналогично завершению командой endmqm и выпол­
няет «плавную» остановку с выводом окна состояния до окончания остановки
менеджера очередей.
3. Дождитесь завершения остановки (см. окно состояния).
Заметьте, что теперь для менеджера очередей отображается значок остановленно­
го локального менеджера очередей.
4. Перезапустите менеджер очередей, щелкнув его правой кнопкой и выбрав коман­
ду Start. Дождитесь завершения запуска (см. окно состояния).
5. Изучите содержимое очереди queue1. Обратите внимание, что в ней остались лишь
постоянные сообщения, добавленные ранее при помощи псевдонима очереди.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
209
Применение управляющих команд WebSphere MQ
Выполните следующие действия.
1. Следующая команда завершает менеджер очередей, вызывая его «плавную» оста­
новку:
endmqm -w host1/qm1
Примечание. Команда endmqm требует указывать имя менеджера очередей,
даже если она адресована менеджеру очередей по умолчанию. Это позволяет
избежать случайной остановки менеджера очередей по умолчанию.
Другой синтаксис команды endmqm имеет следующий вид:
endmqm имя_менеджера_очередей
При вызове без дополнительных параметров эта команда инициирует «плавную»
остановку и сразу возвращает управление. Команда dspmq позволяет увидеть, ког­
да остановится менеджер очередей.
Следующая команда немедленно останавливает менеджер очередей:
endmqm -i имя_менеджера_очередей
2. Для перезапуска менеджера очередей используется команда amqmdain qmgr start
(в Windows) либо strmqm (в UNIX), см. раздел 9.3.2.
3. Просмотрите сообщения в очереди queue1, как описано в разделе 9.3.7. Заметьте,
что в очереди остались только постоянные сообщения.
Примечание. Можно настроить отдельную локальную очередь так, чтобы при
перезапуске менеджера очередей не потерять непостоянные сообщения. Для
этого необходимо воспользоваться значением High атрибута класс NPM
(NPMCLASS), который задают в секции Storage окна свойств очереди. Можно
выполнить эти действия сейчас над очередью queue1.
Однако такие настройки не эквивалентны использованию постоянных сообщений.
WebSphere MQ не регистрирует в журнале операции над непостоянными сообщениями и не восстанавливает их после сбоев менеджера очередей. Следовательно,
сообщения в очередях класса High все равно могут быть поте­ряны. Поэтому
данные, критичные для бизнеса, непременно должны быть помечены как постоянные.
9.3.10. Извлечение сообщений из очереди
Ниже рассказывается, как извлечь сообщения из очереди WebSphere MQ, при этом
извлекаемые сообщения удаляются из очереди. Любое сообщение может быть успеш­
но извлечено из очереди только одним приложением. Разберем это с использовани­
ем программ-примеров для WebSphere MQ.
210
Глава 9
Выполните следующие действия:
1. Если в очереди queue1 не осталось сообщений, добавьте в нее несколько тестовых
сообщений (напрямую либо через псевдоним).
2. Следующая команда извлекает все сообщения из очереди менеджера очередей
по умолчанию:
amqsget queue1
Для каждого из сообщений в очереди эта команда выводит на экран строку, перед
завершением программа ожидает добавления новых сообщений в течение 10 се­
кунд. Если за это время в очередь будут добавлены новые сообщения, программа
немедленно выводит их на экран и ожидает следующие 10 секунд.
Вывод программы-примера выглядит так:
Sample AMQSGET0 start
message <Redbook test message 1>
message <Redbook test message 2>
message <Redbook test message 3>
no more messages
Sample AMQSGET0 end
3. Обратите внимание, что после завершения этой программы в очереди не останет­
ся сообщений. В этом можно убедиться путем просмотра содержимого очереди.
9.3.11. Удаление объекта очереди
Ниже рассказывается, как удалить объект очереди на примере ранее созданного объ­
екта псевдонима. Это делается при помощи WebSphere MQ Explorer либо команды
MQSC DELETE.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой объект псевдонима очереди, queue1.persistent, в таб­
лице менеджера очередей и выберите Delete – система запросит подтверждение.
2. Пометьте флажком имя удаляемого объекта и щелкните Yes.
3. После того как окно состояния закроется, система вновь запросит подтверждение.
Щелкните OK.
4. Обратите внимание на отсутствие удаленного объекта в таблице менеджера оче­
редей.
Применение команд MQSC.
Выполните следующие действия.
1. Выполните следующую команду MQSC (из-под runmqsc):
DELETE QALIAS(‘queue1.persistent’)
Генерируется следующий вывод:
AMQ8007: WebSphere MQ queue deleted.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
211
2. Заметьте, что объект удаленной очереди больше не отображается следующими
командами MQSC:
DISPLAY QUEUE(*)
DISPLAY QALIAS(*)
9.3.12. Создание псевдонима для менеджера очередей
с использованием объекта удаленной очереди
Псевдоним менеджера очередей лишь один из примеров объектов удаленных очере­
дей, создаваемых при помощи WebSphere MQ Explorer или команды MQSC DEFINE
QREMOTE.
Примечание. Псевдоним менеджера очередей – это объект удаленной
очереди, у которого атрибут «имя удаленной очереди» пуст (не имеет значения).
Подробнее его использование освещается в разделе 10.3.12.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues менеджера host1/qm1 и выберите New\
Remote Queue – откроется страница «Enter a name» мастера New Remote Queue,
помеченная красным крестиком.
2. Введите host1/qm1.alias в поле Name.
3. Щелкните Next, не щелкая Finish, – откроется страница Change the properties of
the new Alias Queue, на которой можно задать атрибуты псевдонима очереди.
4. Введите host1/qm1 в поле Remote Queue Manager.
5. В поле Description введите следующее значение:
Redbook example queue manager alias to host1/qm1
6. Щелкните Finish, затем щелкните OK в окне сообщения AMQ4148 (об успешном
создании объекта).
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC (из-под runmqsc):
DEFINE QREMOTE('host1/qm1.alias') RNAME('') RQMNAME('host1/qm1') +
DESCR('Redbook example queue manager alias to host1/qm1')
2. Проверьте атрибуты объекта удаленной очереди, представляющего псевдоним
менеджера очередей, с помощью команды MQSC следующего вида:
DISPLAY QREMOTE('host1/qm1.alias') RNAME RQMNAME DESCR
212
Глава 9
Примечание. Помните: имя host1/qm1 должно вводиться в нижнем регистре,
поэтому важно заключить аргумент RQMNAME в одинарные кавычки при объявлении объекта псевдонима очереди.
9.3.13. Указание менеджера очередей при обращении к очереди
Ниже рассказывается, как указать нужный менеджер очередей, чтобы открыть оче­
редь и поместить в нее сообщения. Для этого применяются программы-примеры
WebSphere MQ. Следующий пример иллюстрирует гибкость различных типов объек­
тов очередей при управлении разрешением имен очередей.
Программы-примеры для WebSphere MQ поддерживают широкий спектр функций
и параметров, в этом примере мы рассмотрим дополнительные функции програм­
мы-примера amqsput.
Примечание. Использованная в этом примере команда удобна для проверки
маршрутов к удаленным менеджерам очередей. Для этого через локальный
менеджер очередей отправляют тестовые сообщения на имя удаленного менеджера очередей.
Применение программ-примеров WebSphere MQ
Выполните следующие действия.
1. Запустите программу-пример для WebSphere MQ следующим образом и добавьте
в очередь несколько сообщений:
amqsput queue1 host1/qm1 8208 0 host1/qm1.alias
Программу-пример здесь вызывают со следующими параметрами:
– queue1 – имя очереди;
– host1/qm1 – имя менеджера очередей, к которому подключаются для отправки
сообщений;
– 8208 – десятичный код параметров запроса, который должен быть передан
при вызове MQOPEN (для данного примера это не важно). Такой вызов застав­
ляет открыть очередь сообщений для записи с целью добавления в нее сооб­
щений и приводит к неудаче последующие попытки добавить сообщения, если
менеджер очередей находится в процессе «плавной остановки»);
– 0 – код, определяющий вызов MQCLOSE без параметров (не важно для данного
примера);
– host1/qm1.alias – имя объекта менеджера очередей, заданное при вызове
MQOPEN (дополнительный параметр, используемый в этом примере). Оно
соответствует ранее объявленному псевдониму менеджера очередей, а не ме­
неджеру очередей, к которому приложение подключено напрямую. Механизм
разрешения имен очередей преобразует эту ссылку в имя локального менед­
жера очередей (host1/qm1) через псевдоним менеджера очередей.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
213
Примечание. Если уничтожить объект удаленной очереди, представляющий
псевдоним менеджера очередей, неверно задать имя менеджера очередей (оно чувствительно к регистру) либо значение атрибута удаленной очереди или допустить ошибку при вызове команды amqsput, вызов MQOPEN завершится с кодом 2087 MQRC_UNKNOWN_REMOTE_Q_MGR.
2. Просмотрите содержимое queue1. Вы увидите, что сообщения доставлены в оче­
редь queue1, обслуживаемую менеджером host1/qm1, включая сообщения, пере­
данные через псевдоним host1/qm1.alias.
9.3.14. Удаление менеджера очередей
Ниже демонстрируется удаление менеджера очередей. Менеджер очередей удаляется
вместе со всеми его очередями и сообщениями, восстановление их средствами Web­
Sphere MQ невозможно. Эта операция осуществляется при помощи WebSphere MQ
Explorer либо управляющей команды dltmqm.
Примечание. Команда dltmqm WebSphere MQ не запрашивает подтверждение перед удалением менеджеров очередей, отменить ее также невозможно.
Поэтому пользуйтесь данной командой с осторожностью.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Если менеджер очередей host1/qm1 работает, щелкните его правой кнопкой
и выберите Stop, чтобы остановить этот менеджер очередей.
2. Выберите метод остановки и щелкните OK – откроется окно состояния. Когда оно
закроется, щелкните правой кнопкой менеджер очередей host1/qm1 в дереве
навигатора и выберите Delete.
3. Проверьте имя удаляемого менеджера очередей в окне запроса подтверждения.
Если все в порядке, щелкните Yes, чтобы удалить менеджер, в противном случае
щелкните No для возврата в WebSphere MQ Explorer. При выборе удаления откро­
ется окно состояния.
4. По завершении операции окно состояния закроется – менеджер очередей будет
удален, он также исчезнет из дерева объектов навигатора.
Применение управляющих команд WebSphere MQ
Выполните следующие действия.
1. Остановите менеджер очередей (см. раздел 9.3.9), например такой командой:
endmqm -w host1/qm1
2. После остановки менеджер очередей можно удалить следующей командой:
dltmqm host1/qm1
214
Глава 9
Примечание. Подобно команде endmqm, команда dltmqm требует указывать
имя менеджера очередей, даже при удалении менеджера очередей по умолчанию.
9.4. Создание служб обработки запросов
и ответов на основе очереди
Ниже рассказывается о размещении служб на базе менеджера очередей, обеспечива­
ющем интерфейс запрос-ответ для очереди. Среди прочего освещаются настройка
триггеров для автоматического запуска службы при добавлении сообщения в очередь
с использованием программ-примеров из WebSphere MQ.
9.4.1. Создание и запуск менеджера очередей – основы службы
Ниже показано, как создать менеджер очередей host1/echo.hub, который выступит
в роли основы для службы, которая возвращает в составе ответа текст, пришедший
в составе запроса.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queue Managers и выберите New\Queue
Manager.
2. Введите host1/echo.hub в поле Queue manager name.
3. Снимите флажок Make this queue manager the default queue manager.
4. Щелкните Next.
5. Щелкните Next, чтобы принять параметры ведения журнала, заданные по умолча­
нию.
6. Пометьте флажок Start queue manager – это необходимо для автоматического
запуска менеджера очередей.
7. Щелкните Next.
8. Снимите флажок Create listener configured for TCP/IP.
9. Щелкните Finish.
Применение управляющих команд WebSphere MQ
Выполните следующие действия.
1. Создайте менеджер очередей, не делая его менеджером очередей по умолчанию,
при помощи следующей команды:
crtmqm host1/echo.hub
2. Запустите менеджер очередей следующей командой:
– в Windows:
amqmdain qmgr start host1/echo.hub
Обмен сообщениями с использованием WebSphere MQ: практическое введение
215
– в UNIX:
strmqm host1/echo.hub
9.4.2. Создание очереди-основы службы
Ниже рассказывается о создании объекта локальной очереди, который в дальнейшем
станет основой службы, запускающейся для обработки поступающих запросов. Это
делается с использованием WebSphere MQ Explorer либо команд MQSC. Атрибуты
этой очереди имеют значения по умолчанию и запросы, поступающие в эту очередь,
являются непостоянными.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues менеджера очередей host1/echo.hub
и выберите команду New\Local Queue.
2. Введите echo в поле Name.
3. Щелкните Next.
4. В поле Description введите следующее значение:
Queue hosting the echo service
5. Щелкните Finish.
Применение команд MQSC
Выполните следующую команду MQSC, адресованную менеджеру host1/echo.hub:
DEFINE QLOCAL('echo') +
DESCR('Queue hosting the echo service')
9.4.3. Ручное объявление очереди ответов
Ниже рассказывается, как вручную создать объект локальной очереди, которую
запрашивающее приложение будет использовать для получения ответов. Это делается
с использованием WebSphere MQ Explorer либо команд MQSC. Атрибуты очереди
ответов имеют значения по умолчанию.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues менеджера host1/echo.hub и выберите
New\Local Queue.
2. Введите echo.replies.manual в поле Name.
3. Щелкните Next.
4. Введите в поле Description следующее значение:
Manually defined reply-to queue for echo service
5. Щелкните Finish.
216
Глава 9
Применение команд MQSC
Примечание. Поскольку host1/echo.hub не является менеджером очередей по умолчанию, для запуска интерактивного сеанса MQSC применяется следующая команда:
runmqsc host1/echo.hub
Помните: для завершения интерактивного сеанса MQSC используется команда END.
Выполните следующую команду MQSC для менеджера host1/echo.hub:
DEFINE QLOCAL('echo.replies.manual') + DESCR('Manually defined reply-to queue
for echo service')
9.4.4. Добавление и анализ тестового запроса
Ниже рассказывается, как добавить тестовое сообщение с запросом. Также вы узнаете,
как изучить это сообщение, чтобы понять его отличие от сообщения-дейтаграммы.
Для этого вы воспользуетесь программами-примерами WebSphere MQ. О просмотре
очередей см. в разделе 9.3.7.
Выполните следующие действия:
1. Выполните команду amqsreq, вызывающую одноименную программу–пример
WebSphere MQ:
amqsreq echo host1/echo.hub echo.replies.manual
Примечание. Эту команду вызывают со следующими параметрами:
 echo – имя очереди-основы службы, предоставляющей интерфейс запрос-ответ; в настоящее время активных служб, обрабатывающих сообщения в этой очереди, нет;
 host1/echo.hub – имя менеджера очередей, к которому подключается запрашивающее приложение;
 echo.replies.manual – имя очереди ответов, которое запрашивающее приложение указывает в дескрипторах сообщений с запросами; запрашивающее приложение ожидает поступления ответов в эту очередь.
Первоначально эта команда генерирует следующий вывод:
Sample AMQSREQ0 start
server queue is echo
replies to echo.replies.manual
Обмен сообщениями с использованием WebSphere MQ: практическое введение
217
Примечание. Следите за регистром имен очередей в MQSC и WebSphere MQ
Explorer, а также параметров этой команды. При возврате неожиданного кода
завершения воспользуйтесь командой mqrc, чтобы получить его понятное
описание в текстовой форме.
2. Добавьте несколько сообщений через эту команду. После ввода каждого из сооб­
щений нажимайте Enter. Чтобы прекратить отправку сообщений, нажмите Enter,
не вводя ничего, – после этого программа в течение 10 секунд будет ожидать по­
ступления ответов. На этот раз ответы не приходят, поскольку служба еще не
настроена.
3. Изучите сообщения, добавленные в эхо-очередь (очередь с ответами), обращая
внимание на:
– тип сообщения (MsgType): это запрос (код 1);
– имя эхо-очереди (echo.replies.manual);
– менеджер очередей, обслуживающий эхо-очередь (host1/echo.hub);
– при использовании WebSphere MQ Explorer выберите секцию Identifiers в окне
свойств сообщения. Обратите внимание на то, что идентификатор сообщения
(MsgId) представлен уникальным значением, сгенерированным WebSphere
MQ;
– также заметьте, что поле корреляционного идентификатора (CorrelId) пусто.
9.4.5. Очистка очереди-основы службы
Ниже рассказывается, как очистить очередь – основу службы. Это необходимо, чтобы
сообщения, ранее добавленные в очередь, не помешали генерации (с использовани­
ем правил срабатывания, triggering rules) триггерных сообщений WebSphere MQ в от­
вет на поступление последующих сообщений. Если при выполнении последующих
упражнений у вас возникнут проблемы, возможно, описанные ниже действия помо­
гут устранить их.
Примечание. Эти действия не обязательны; помните также, что в реальной
среде очистка очереди запросов может привести к потере важных данных.
Это упражнение можно выполнить с использованием WebSphere MQ Explorer или
команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выберите папку Queues менеджера host1/echo.hub.
2. Щелкните правой кнопкой в таблице строку очереди echo и выберите Clear Messages.
218
Глава 9
3. В окне Clear queue оставьте флажок Queue will be cleared with the CLEAR command
и щелкните Clear.
4. Заметьте, что теперь значение атрибута «текущая длина очереди» равно нулю.
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера host1/echo.hub:
CLEAR QLOCAL(‘echo’)
9.4.6. Создание определения процесса для службы
Ниже демонстрируется организация службы обработки запросов и ответов, работаю­
щей на базе очереди echo, с применением программы-примера amqsech. Эта про­
грамма предназначена для запуска с помощью триггеров WebSphere MQ.
Далее рассказывается, как создать определение процесса, необходимого для запуска
amqsech – приложения-примера WebSphere MQ, представляющего требуемую службу.
Это делается с использованием WebSphere MQ Explorer или команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Process Definitions в менеджере host1/echo.hub
и выберите New\Process Definition.
Примечание. Эта папка находится в папке Advanced менеджера очередей (см. окно навигатора).
2. Введите amqsech в поле Name.
3. Щелкните Next.
4. Введите следующий текст в поле Description:
The amqsech WebSphere MQ sample program
5. Выберите подходящее значение параметра Application type:
– в Windows: Windows NT;
– в UNIX: Unix.
6. Введите путь к приложению:
– в Windows:
C:\Program Files\IBM\WebSphere MQ\Tools\c\samples\bin\amqsech.exe
– В UNIX (кроме AIX 5L):
C:\Program Files\IBM\WebSphere MQ\Tools\c\samples\bin\amqsech.exe
/opt/mqm/samp/bin/amqsech
– В AIX 5L:
/usr/mqm/samp/bin/amqsech
7. Щелкните Finish.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
219
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC для менеджера host1/echo.hub:
– в Windows:
DEFINE PROCESS(‘amqsech’) + DESCR(‘The amqsech WebSphere MQ sample program’) +
APPLTYPE(WINDOWSNT) +
APPLICID(‘C:\Program Files\IBM\WebSphere MQ\Tools\c\samples\bin\amqsech.exe’)
– в UNIX (кроме AIX 5L):
DEFINE PROCESS('amqsech') + DESCR('The amqsech WebSphere MQ sample program') +
APPLTYPE(UNIX) APPLICID('/opt/mqm/samp/bin/amqsech')
– в AIX 5L:
DEFINE PROCESS(‘amqsech’) + DESCR(‘The amqsech WebSphere MQ sample program’) +
APPLTYPE(UNIX) APPLICID(‘/usr/mqm/samp/bin/amqsech’)
2. Выполните следующую команду MQSC для просмотра атрибутов объекта опреде­
ления процесса:
DISPLAY PROCESS(‘amqsech’)
Примечание. Следите за регистром атрибутов и имени процесса в объекте
определения. На платформах UNIX путь также чувствителен к регистру.
9.4.7. Создание очереди инициации
Ниже рассказывается, как создать локальную очередь с атрибутами по умолчанию,
которая впоследствии станет очередью инициации, принимающей триггерные сооб­
щения для очереди echo. Это делается при помощи WebSphere MQ Explorer либо
команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues в менеджере host1/echo.hub и выберите
New\Local Queue.
2. Введите echo.initq в поле Name.
3. Щелкните Next.
4. Введите в поле Description следующий текст:
Initiation queue for triggering the echo service
5. Щелкните Finish.
220
Глава 9
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера host1/echo.hub:
DEFINE QLOCAL('echo.initq') + DESCR('Initiation queue for triggering the echo
service')
9.4.8. Активация триггера для очереди-основы службы
Ниже описывается активация триггера для очереди echo. В данном примере исполь­
зуется триггер типа first, генерирующий триггерное сообщение при поступлении в
очередь первого сообщения.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выберите папку Queues менеджера host1/echo.hub.
2. Щелкните правой кнопкой в таблице строку очереди echo и выберите Properties.
3. Перейдите в секцию Triggering.
4. В поле Trigger control установите значение On.
5. Назначьте параметру Trigger type значение First.
6. Введите echo.initq в поле Initiation queue.
7. Введите amqsech в поле Process name.
8. Щелкните OK.
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC в отношении менеджера host1/echo.hub:
ALTER QLOCAL('echo') + TRIGGER TRIGTYPE(FIRST) INITQ('echo.initq') +
PROCESS('amqsech')
2. Проверьте атрибуты объекта очереди следующей командой MQSC:
DISPLAY QLOCAL('echo') TRIGGER TRIGTYPE INITQ PROCESS
Примечание. Убедитесь, что выбран верный регистр для атрибутов.
9.4.9. Запуск триггерного монитора WebSphere MQ
Ниже рассказывается, как запустить триггерный монитор WebSphere MQ, отслежива­
ющий поступление триггерных сообщений в ранее созданную очередь инициации
echo.initq.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
221
Выполните следующие действия.
1. Откройте окно командной строки либо запустите новый терминальный сеанс
(запустив триггерный монитор, не останавливайте его – он еще потребуется при
изучении этой главы; если монитор по каким-то причинам остановится, переза­
пустите его, как описано ниже. Чтобы остановить монитор, активируйте окно
командной строки или сеанс, в котором он работает, и нажмите Ctrl+C).
2. Выполните следующую команду, чтобы запустить триггерный монитор WebSphere
MQ для менеджера очередей host1/echo.hub и очереди инициации echo.initq:
runmqtrm -m host1/echo.hub -q echo.initq
После запуска эта команда генерирует следующий вывод:
5724-H72 (C) Copyright IBM Corp. 1994, 2004. ALL RIGHTS RESERVED. WebSphere MQ
trigger monitor started.
Waiting for a trigger message
9.4.10. Отправка запроса службе
Ниже рассказывается, как отправить в очередь echo сообщение с запросом вызываю­
щего генерацию триггерного сообщения и его добавление в очередь инициации,
заданную атрибутами очереди echo.
Триггерное сообщение обрабатывается триггерным монитором WebSphere MQ,
который запускает в ответ на такие сообщения программу amqsech с использовани­
ем объекта определения процесса, заданного в параметрах очереди echo.
Триггерный монитор WebSphere MQ передает программе amqsech все сведения
из триггерного сообщения, необходимые для определения очереди для обработки
сообщений.
Программа amqsech генерирует ответы в виде копий исходных сообщений и направ­
ляет их очереди ответов, заданной в дескрипторах сообщений запросов.
Выполните следующие действия.
1. Выполните следующую команду:
amqsreq echo host1/echo.hub echo.replies.manual
2. Введите текст одного сообщения и нажмите Enter (пока не вводите пустую строку
после сообщения).
3. Изучите вывод триггерного монитора, включая дополнительную информацию,
которую он отображает. Монитор сообщает о том, что в очереди инициации было
сгенерировано триггерное сообщение, обработанное затем триггерным монито­
ром, который запустил в ответ программу amqsech. Спустя примерно 10 секунд
(после завершения программы amqsech, не дождавшейся следующего сообщения)
генерируется дополнительный вывод примерно такого вида:
C:\PROGRA~1\IBM\WEBSPH~1\Tools\c\samples\bin\amqsech.exe «TMC 2echo amqsech
C:\Program Files\IBM\WebSphere MQ\Tools\c\samples\bin\amqsech.exe
host1/echo.hub
«
222
Глава 9
Sample AMQSECHA start
Example request message
MQGET ended with reason code 2033
Sample AMQSECHA end
End of application trigger.
4. Этот вывод свидетельствует о том, что программа amqsech, запущенная триггер­
ным монитором WebSphere MQ, обработала сообщение и отправила ответ в оче­
редь echo.replies.manual, заданную в команде, которой вызывается amqsreq.
Изучите сообщение, полученное очередью echo.replies.manual. Если для этого
используется программа amqsbcg, запустите ее в новом окне командной строки,
чтобы не прерывать работу amqsreq.
Обратите внимание на следующие сведения в составе ответа:
– тип сообщения (MsgType) – ответ (reply, код 2);
– параметры, такие как идентификатор сообщения (MsgId) и корреляционный
идентификатор (CorrelId), определены (имеют значения), поскольку amqsech
копирует идентификатор сообщения из дескриптора сообщения-запроса
в поле корреляционного идентификатора дескриптора сообщения-ответа. Это
позволяет запрашивающему приложению сопоставлять полученные ответы
отправленным запросам. Уникальный идентификатор для сообщения-ответа
генерируется WebSphere MQ.
5. Вернитесь в окно командной строки, в котором был отправлен запрос, с помощью
amqsreq. Нажмите Enter, не вводя ничего. Спустя примерно 10 секунд программа
amqsreq завершится, генерируя следующий вывод:
Sample AMQSREQ0 start
server queue is echo
replies to echo.replies.manual
Example test message
response <Example test message>
no more replies
Sample AMQSREQ0 end
Примечание. Если вы столкнулись с трудностями, проверьте атрибуты всех
объявленных ранее объектов, а также регистр имен объектов, параметры команд
(включая параметры триггерного монитора WebSphere MQ).
9.4.11. Создание объекта модельной очереди
для динамической очереди ответов
Ниже освещается определение объекта модельной очереди для создания временных
динамических очередей ответов. Динамическое создание очередей ответов выполня­
Обмен сообщениями с использованием WebSphere MQ: практическое введение
223
ет программа amqsreq при запросе службы echo. Для этого упражнения мы восполь­
зуемся WebSphere MQ Explorer или командами MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues в менеджере host1/echo.hub и выберите
New\Model Queue.
2. Введите echo.replies.tempdyn в поле Name.
3. Щелкните Next.
4. Введите следующий текст в поле Description:
Temporary dynamic reply-to queues for echo service
5. Перейдите в секцию Extended.
6. Заметьте, что в поле Definition Type задано значение Temporary Dynamic.
7. Щелкните Finish.
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC в отношении менеджера host1/echo.hub:
DEFINE QMODEL('echo.replies.tempdyn') + DESCR('Temporary dynamic reply-to
queues for echo service')
2. Выполните следующую команду MQSC, чтобы проверить свойства созданного
объекта:
DISPLAY QMODEL(‘echo.replies.tempdyn’) DESCR DEFTYPE
Обратите внимание на тип определения (атрибут DEFTYPE): он является времен­
ным и динамическим (TEMPDYN).
9.4.12. Отправка запроса с использованием временной
динамической очереди ответов
Ниже рассказывается, как запросить службу (см. раздел 9.4.10). При этом в командной
строке вызова amqsreq в качестве приемника ответов задана модельная очередь echo.
replies.tempdyn.
Когда программа amqsreq открывает модельную очередь, менеджер очередей авто­
матически создает временную динамическую очередь на основе атрибутов объекта
модельной очереди echo.replies.tempdyn. По завершении программы amqsreq менед­
жер очередей автоматически удаляет этот объект. Если программа завершена
досрочно, например нажатием Ctrl+C во время обработки, удаление будет выполнено
через несколько секунд после остановки amqsreq.
Выполните следующие действия.
1. Запустите amqsreq следующей командой:
amqsreq echo host1/echo.hub echo.replies.tempdyn
224
Глава 9
Программа генерирует следующий вывод:
Sample AMQSREQ0 start
server queue is echo
replies to AMQ.42DD88DE02C70120
где AMQ.42DD88DE02C70120 – имя динамической очереди.
2. Изучите свойства временной динамической очереди следующим образом.
– С помощью WebSphere MQ Explorer:
i. Выберите папку Queues менеджера очередей host1/echo.hub.
ii. Включите в WebSphere MQ Explorer отображение временных очередей
(см. рис. 9.1).
Рис. 9.1. Отображение временных очередей в WebSphere MQ Explorer
iii. Обратите внимание на идентичность описания динамической очереди
и объекта модельной очереди, на основе которого она создана.
Примечание. Временные динамические очереди, имена которых начинаются с AMQ.MQEXPLORER, созданы WebSphere MQ Explorer на основе модельной очереди
SYSTEM.MQEXPLORER.REPLY.MODEL. WebSphere MQ Explorer использует интерфейс
запросов и ответов, поддерживаемый командными серверами менеджеров
очередей.
– С помощью команд MQSC.
i. Выполните следующую команду MQSC в отношении менеджера host1/echo.
hub:
DISPLAY QL('AMQ.*') DEFTYPE DESCR
ii. Заметьте, что значение атрибута «описание» (DESCR) динамической очере­
ди идентично описанию объекта модельной очереди, на основе которого
была создана эта очередь.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
225
3. Заметьте, что с приложением amqsreq работают так же, как с очередью, объявлен­
ной вручную.
4. Обратите внимание, что после завершения приложения amqsreq временная дина­
мическая очередь удаляется автоматически.
Примечание. Приложение-пример amqsreq не поддерживает постоянные
динамические очереди, поскольку оно не позволяет указать параметры, необходимые для удаления очереди после того, как она будет закрыта. Однако можно
поэкспериментировать с модельными очередями, объявленными как постоянные
динамические очереди (тип определения – PERMDYN), и программой amqsreq.
Временные очереди этого типа необходимо удалять вручную с помощью
WebSphere MQ Explorer или команд MQSC.
9.5. Рассылка сообщений по подписке
в WebSphere MQ с помощью JMS
В этом разделе демонстрируется применение брокера публикации-подписки
(publish/subscribe broker) WebSphere MQ с примерами кода для WebSphere MQ JMS
(Java Message Service).
Примечание. Для изучения этого раздела необходимо установить пакет Java
Development Kit (JDK). JDK 1.4.2 находится в каталоге Prereqs на установочном
носителе WebSphere MQ V6.0.
Каталог с исполняемыми файлами java и javac из JDK необходимо добавить к пути ОС.
Пример кода для WebSphere MQ JMS потребуется слегка изменить, а затем
скомпилировать. Однако знать язык программирования Java для этого не обязательно.
9.5.1. Настройка среды JMS
Создайте на компьютере, на котором предполагается работать с примерами кода,
каталог – в нем будут размещены все файлы и каталоги, необходимые для выполне­
ния описанных ниже действий. Все команды и терминальные сеансы должны рабо­
тать с этим каталогом.
Исполняющая среда Java Runtime Environment (JVM), в которой работают Java-при­
ложения, ищет скомпилированные компоненты Java-приложений в каталоге class
path, заданном соответствующей переменной окружения.
При установке WebSphere MQ в Windows путь к компонентам, необходимым для ис­
полнения приложений WebSphere MQ JMS, автоматически добавляется к переменной
пути к классам Java, а на платформах UNIX это придется сделать вручную с помощью
текущей оболочки.
226
Глава 9
Далее предполагается, что независимо от платформы рабочий каталог добавлен
в путь к классам Java.
Для этого выполните следующие действия (в каждом окне командной строки или
терминальном окне, где будут выполняться описанные ниже упражнения).
 В Windows:
a. Перейдите в рабочий каталог, например:
C:
cd \wmq_redbook\jmspubsub
b. Выполните следующую команду, чтобы добавить путь к текущему каталогу
в путь к классам Java:
set CLASSPATH=%CLASSPATH%;.
 В UNIX:
a. Перейдите в рабочий каталог, например так:
cd ~/wmq_redbook/jmspubsub
b. Выполните следующую команду (с синтаксисом, принятым на вашей UNIXплатформе; не забудьте пробел между знаками «.» и «/»):
• В UNIX (кроме AIX 5L):
. /opt/mqm/java/bin/setjmsenv
• В AIX 5L:
. /usr/mqm/java/bin/setjmsenv
c. Выполните следующую команду, чтобы добавить текущий каталог (а также
дополнительный пакет Jar, не добавленный setjmsenv) в путь к классам Java.
• В UNIX (кроме AIX 5L):
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/jms.jar:.
export CLASSPATH
• В AIX 5L:
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/jms.jar:.
export CLASSPATH
Обмен сообщениями с использованием WebSphere MQ: практическое введение
227
Примечание. Если при выполнении описанных ниже упражнений вы столкнулись с ошибками, например:
Exception in thread «main» java.lang.NoClassDefFoundError
попробуйте устранить их, выполнив следующие действия. Настройте переменные
окружения CLASSPATH вручную, например так.
 В UNIX (кроме AIX 5L):
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/com.ibm.mq.jar
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/com.ibm.mqjms.jar
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/connector.jar
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/jms.jar CLASSPATH=$CLASSPATH:/
opt/mqm/java/lib/jndi.jar CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/jta.
jar CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/providerutil.jar
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/fscontext.jar
CLASSPATH=$CLASSPATH:/opt/mqm/java/lib/ldap.jar CLASSPATH=$CLASSPATH:.
export CLASSPATH
 В AIX 5L:
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/com.ibm.mq.jar
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/com.ibm.mqjms.jar
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/connector.jar
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/jms.jar CLASSPATH=$CLASSPATH:/
usr/mqm/java/lib/jndi.jar CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/jta.
jar CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/providerutil.jar
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/fscontext.jar
CLASSPATH=$CLASSPATH:/usr/mqm/java/lib/ldap.jar CLASSPATH=$CLASSPATH:.
export CLASSPATH
9.5.2. Создание и запуск менеджера очередей
Прежде всего необходимо создать и запустить менеджер очередей host1/jmspubsub,
обеспечивающий доступ к брокеру публикации-подписки.
Это делается с помощью управляющих команд WebSphere MQ или WebSphere MQ
Explorer (см. раздел 9.4.1).
9.5.3. Запуск брокера на менеджере очередей
WebSphere MQ V6.0 поддерживает объект службы, который создается в менеджере
очередей и позволяет запустить брокер публикации-подписки на этом менеджере.
Брокер публикации-подписки WebSphere MQ не запускается по умолчанию. Однако
его можно настроить для запуска вместе с менеджером очередей. Это делается с по­
мощью WebSphere MQ Explorer и команд MQSC.
228
Глава 9
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выберите папку Services менеджера очередей host1/jmspubsub.
2. Щелкните значок, включающий отображение системных объектов, если это еще
не сделано (см. рис. 9.2).
3. Щелкните правой кнопкой службу SYSTEM.BROKER и выберите команду
Properties.
4. Установите для поля Service значение Queue manager, чтобы брокер публикацииподписки запускался вместе с менеджером очередей.
5. Щелкните OK.
6. Щелкните правой кнопкой службу SYSTEM.BROKER и выберите Start, чтобы
запустить брокер.
Рис. 9.2. Отображение системных объектов в WebSphere MQ Explorer
Применение команд MQSC
Выполните следующие действия.
1. Чтобы настроить брокер публикации-подписки WebSphere MQ для запуска вместе
с менеджером очередей, выполните следующую команду MQSC в отношении
менеджера host1/jmspubsub:
ALTER SERVICE('SYSTEM.BROKER') CONTROL(QMGR)
2. Чтобы запустить брокер публикации-подписки, выполните следующую команду
MQSC в отношении менеджера host1/jmspubsub:
START SERVICE('SYSTEM.BROKER')
Обмен сообщениями с использованием WebSphere MQ: практическое введение
229
9.5.4. Настройка менеджера очередей для работы с JMS
WebSphere MQ требует некоторой настройки менеджера очередей, чтобы последний
смог работать с JMS-приложениями и использовать возможности брокера публика­
ции-подписки.
Для этого поставляется специальный сценарий MQSC. Выполните его над менедже­
ром очередей host1/jmspubsub, как показано ниже.
 В Windows (команда вводится как одна строка):
runmqsc host1/jmspubsub < «C:\Program Files\IBM\WebSphere MQ \Java\bin\MQJMS_
PSQ.mqsc»
 В UNIX (кроме AIX 5L):
runmqsc host1/jmspubsub < /opt/mqm/java/bin/MQJMS_PSQ.mqsc
 В AIX 5L:
runmqsc host1/jmspubsub < /usr/mqm/java/bin/MQJMS_PSQ.mqsc
9.5.5. Настройка простого JMS-провайдера
JMS – стандартный интерфейс, который поддерживается не только WebSphere MQ.
Поэтому операции, специфичные для WebSphere MQ, необходимо сопоставить
с операциями, описанными в стандарте JMS.
Приложения могут оперативно получать сведения о таких сопоставлениях, запраши­
вая из каталога информацию о том, как предоставляется доступ к JMS. Этот ката­
лог – не обязательно каталог файловой системы, он может быть распределенной
системой. Часто в производственной среде такой каталог находится на сетевом сер­
вере LDAP (Lightweight Directory Access Protocol). Такая конфигурация позволяет опе­
ративно вносить изменения. Приложения, использующие JMS, запрашивают сведения
о доступе к JMS из каталога через интерфейс под названием JNDI (Java Naming and
Directory Interface™).
В приведенном ниже простом примере для хранения подобной информации в фай­
ловой системе создается каталог, далее подготавливается его содержимое при помо­
щи средств WebSphere MQ JMS Administration tool.
Для работы с WebSphere MQ JMS Administration tool необходимо сделать следующее.
1. В рабочем каталоге, созданном для этого примера, создайте следующий каталог
(но не переходите в него):
jms.provider
2. Создайте в рабочем каталоге файл JMSAdmin.config следующего содержания:
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory PROVIDER_
URL=file:jms.provider SECURITY_AUTHENTICATION=none
Этот файл служит для настройки инструмента JMS Administration tool с целью подго­
товки содержимого созданного ранее каталога файловой системы.
230
Глава 9
9.5.6. Настройка JMS с помощью JMS Administration tool
Инструмент WebSphere MQ JMS Administration tool создает объекты в каталоге,
доступном через интерфейс JNDI. По завершении настройки этот каталог станет
доступным приложениям, которые работают c WebSphere MQ и JMS через JNDI. Эти
приложения смогут настраивать доступ к JMS, предоставляемый им WebSphere MQ.
Синтаксис команд WebSphere MQ JMS Administration tool аналогичен таковому у ко­
манд MQSC, только имена объектов и атрибутов в нижнем регистре не обязательно
заключать в одинарные кавычки.
Подробнее о WebSphere MQ JMS Administration tool и соответствующих объектах
см. WebSphere MQ V6.0 Using Java, SC34-6591.
Ниже рассказывается, как создать объект Topic Connection Factory, определяющий
способ подключения JMS-приложения к провайдеру функций обмена сообщений
по принципу публикации-подписки (publish/subscribe), а также объект Topic, опреде­
ляющий «тему», в которой приложения смогут публиковать свои сообщения и подпи­
сываться на получение сообщений этой темы.
Выполните следующие действия.
1. Запустите инструмент WebSphere MQ JMS Administration tool:
– в Windows:
«C:\Program Files\IBM\WebSphere MQ\Java\Bin\JMSAdmin.bat»
– в UNIX (кроме AIX 5L):
/opt/mqm/java/bin/JMSAdmin
– в AIX 5L:
/usr/mqm/java/bin/JMSAdmin
После запуска программа генерирует следующий вывод:
5724-H72, 5655-L82, 5724-L26 (c) Copyright IBM Corp. 2002,2005. All Rights
Reserved. Starting Websphere MQ classes for Java(tm) Message Service
Administration
InitCtx>
2. Создайте объект Topic Connection Factory (TCF) для подключения к брокеру пуб­
ликации-подписки, работающему в менеджере очередей host1/jmspubsub.
Для этого выполните следующую команду:
DEFINE TCF(PubSub.TCF) QMANAGER(host1/jmspubsub) TRANSPORT(BIND)
3. Создайте объект Topic для темы MQJMS/Samples/PubSub, выполнив следующую
команду:
DEFINE T(PubSub.T) TOPIC(MQJMS/Samples/PubSub)
4. Остановите WebSphere MQ JMS Administration tool следующей командой:
END
Обмен сообщениями с использованием WebSphere MQ: практическое введение
231
9.5.7. Копирование примера JMS-приложения WebSphere MQ
Приложение-пример, иллюстрирующее функции публикации и подписки на сооб­
щения в WebSphere MQ JMS, находится в каталоге.
1. В Windows:
C:\Program Files\IBM\WebSphere MQ\Tools\Java\jms\JMSPubSub.java
2. В UNIX (кроме AIX 5L):
/opt/mqm/samp/java/jms/JMSPubSub.java
3. В AIX 5L:
/usr/mqm/samp/java/jms/JMSPubSub.java
Скопируйте этот файл в рабочий каталог, созданный для этого примера.
9.5.8. Модификация примера JMS-приложения WebSphere MQ
Ниже показано, как изменить пример JMS-приложения, чтобы он смог работать с соз­
данным ранее каталогом через JNDI, а также с объектами, созданными в этом катало­
ге при помощи WebSphere MQ JMS Administration tool.
Также необходимо привести имена объектов в соответствие базовым правилам име­
нования, принятым в данной системе, а не правилам LDAP (последние в данной книге
не рассматриваются).
Выполните следующие действия.
1. Откройте файл JMSPubSub.java в текстовом редакторе.
2. Найдите в коде следующие строки (в примере для WebSphere MQ V6.0 они начи­
наются со строки 88):
String CTX_FACTORY = «com.sun.jndi.ldap.LdapCtxFactory»; String INIT_URL =
«ldap://polaris/cn=PubSub,o=ibm_us,c=us»;
3. Отредактируйте следующие строки согласно параметрам конфигурации
WebSphere MQ JMS Administration tool:
String CTX_FACTORY = «com.sun.jndi.fscontext.RefFSContextFactory»; String
INIT_URL = «file:jms.provider»;
4. Найдите в коде следующую строку (в примере для WebSphere MQ V6.0 – строка
98):
TopicConnectionFactory tcf = (TopicConnectionFactory)ctx.lookup( «cn=PubSub.
TCF» );
5. Отредактируйте эту строку, подставив имя объекта Topic Connection Factory,
созданного ранее при помощи WebSphere MQ JMS Administration tool:
TopicConnectionFactory tcf = (TopicConnectionFactory)ctx.lookup( «PubSub.TCF» );
6. Найдите в коде следующую строку (в примере для WebSphere MQ V6.0 – строка
112):
Topic t = (Topic)ctx.lookup( «cn=PubSub.T» );
232
Глава 9
7. Отредактируйте эту строку, подставив имя объекта Topic, созданного ранее при
помощи WebSphere MQ JMS Administration tool:
Topic t = (Topic)ctx.lookup( «PubSub.T» );
8. Сохраните файл.
9.5.9. Компиляция приложения-примера
Компиляция примера JMS-приложения для WebSphere MQ, демонстрирующего пуб­
ликацию и подписку, выполняется следующей командой:
javac JMSPubSub.java
В результате ее исполнения в рабочем каталоге создается файл JMSPubSub.class.
9.5.10. Запуск приложения-примера в режиме подписчика
Скомпилированный пример JMS-приложения может работать как в режиме издателя
сообщения, так и в режиме подписчика. Допускается запуск сразу нескольких экземп­
ляров программ-издателей и подписчиков.
Чтобы запустить программу-пример в режиме подписчика, выполните следующие
действия.
1. Откройте окно командной строки или терминальный сеанс, где будет запущен
экземпляр программы, который станет подписчиком сообщений. Сделайте
настройки, описанные в разделе 9.5.1.
2. Выполните следующую команду, чтобы запустить программу-пример в режиме
подписчика:
– в Windows:
java JMSPubSub -sub
– в UNIX (кроме AIX 5L):
java -D»java.library.path=/opt/mqm/java/lib» JMSPubSub -sub
– в AIX 5L:
java -D»java.library.path=/usr/mqm/java/lib» JMSPubSub -sub
После запуска программа генерирует следующий вывод:
[R]eceiveBlock, Receive[N]oWait, Receive[5]Secs, [Q]uit?
3. Чтобы заставить экземпляр-подписчик ожидать публикации следующего сообще­
ния по данной теме, нажмите R, затем Enter.
Примечание. Эти клавиши необходимо нажимать после получения каждого
сообщения.
Обмен сообщениями с использованием WebSphere MQ: практическое введение
233
9.5.11. Запуск программы-примера в режиме издателя
Скомпилированный пример JMS-приложения может работать как в режиме издателя
сообщения, так и в режиме подписчика. Допускается запуск сразу нескольких экземп­
ляров программ-издателей и подписчиков.
Чтобы запустить программу-пример в режиме издателя, выполните следующие дейст­
вия:
1. Откройте окно командной строки или терминальный сеанс, где будет запущен
экземпляр программы, который станет издателем сообщений. Сделайте настрой­
ки, описанные в разделе 9.5.1.
2. Выполните следующую команду, чтобы запустить программу-пример в режиме
издателя:
– в Windows:
java JMSPubSub -pub
– в UNIX (кроме AIX 5L):
java -D»java.library.path=/opt/mqm/java/lib» JMSPubSub -pub
– в AIX 5L:
java -D»java.library.path=/usr/mqm/java/lib» JMSPubSub -pub
После запуска программа генерирует следующий вывод:
[P]ublish message, [Q]uit?
3. Чтобы опубликовать сообщение, нажмите P, затем Enter.
4. Введите текст публикуемого сообщения и нажмите Enter.
Сообщение будет опубликовано и станет доступным всем ожидающим подписчи­
кам. Получив такое сообщение, подписчик генерирует вывод следующего вида:
JMS Message class: jms_text JMSType: null
JMSDeliveryMode: 2
JMSExpiration: 0 JMSPriority: 4
JMSMessageID: ID:414d5120686f7374312f6a6d73707562d1dcdd4220001e08
JMSTimestamp: 1121839520615
JMSCorrelationID:ID:414d5120686f7374312f6a6d73707562d1dcdd4220006f05
JMSDestination: topic://MQJMS/Samples/PubSub JMSReplyTo: null JMSRedelivered:
false
JMS_IBM_PutDate:20050720
JMSXAppID:host1/jmspubsub
JMS_IBM_Format:MQSTR
JMS_IBM_PutApplType:26
JMS_IBM_MsgType:8 JMSXUserID:pbroad
JMS_IBM_PutTime:06052061
JMSXDeliveryCount:1
Redbook test message
234
Глава 9
10
Построение инфраструктуры
WebSphere MQ: практическое
руководство
Изучая эту главу, вы дополните локальную инфраструктуру, созданную при изучении
предыдущей главы. Вы научитесь создавать клиентские подключения к менеджерам
очередей и выполнять удаленное администрирование при помощи WebSphere MQ
Explorer. Вы также освоите построение центрально-лучевой инфраструктуры, созда­
ние кластеров менеджеров очередей; вы увидите, как это облегчает администрирова­
ние и предоставляет дополнительные возможности по балансировке нагрузки. Цент­
рально-лучевая инфраструктура и кластеры менеджеров очередей – связанные поня­
тия, они сообща используют различные службы.
В этой главе обсуждаются следующие темы:




Настройка окружения
Подключение к менеджеру очередей в режиме клиента
Построение центрально-лучевой инфраструктуры
Создание кластеров менеджеров очередей
Построение инфраструктуры WebSphere MQ: практическое руководство 235
10.1. Настройка окружения
Для выполнения упражнений из этой главы необходимо то же окружение, что было
настроено для изучения главы 9.
Единственное дополнение – TCP/IP-сеть, соединяющая компьютеры, на которых
рабо­тают приложения и менеджеры очередей.
В этой главе предполагается, что в сети может быть несколько компьютеров с разны­
ми хост-именами и IP-адресами. Впрочем, любое из приведенных ниже упражнений
можно выполнить и на изолированной рабочей станции под управлением Windows
или Linux, то есть наличие сетевого подключения не обязательно.
Примечание. При использовании компьютера, не подключенного к сети, все
хост-имена в этой главе следует заменить идентификатором локального компьютера:
localhost
Примеры хост-имен, используемых в этой главе:
host1.example.com
host2.example.com
Кроме того, в этой главе указаны уникальные номера портов, которые прослушивают менеджеры очередей. Это означает, что данные номера портов можно
использовать как на одном компьютере, так и на разных.
10.2. Подключение к менеджеру очередей
в режиме клиента
В этом разделе рассказывается, как приложения подключаются к удаленным менед­
жерам очередей, получая доступ к тем же функциям, что и приложения, подключен­
ные к локальным менеджерам очередей.
Ниже демонстрируется получение доступа к менеджеру очередей и его администри­
рование на примере менеджера host1/echo.hub, созданного в разделе 9.4. Эти инст­
рукции позволят получить доступ к службе, функционирующей в этом менеджере
очередей, через клиентское подключение.
Альтернативный вариант – создание и запуск нового менеджера очередей. В этом
случае следует заменить host1/echo.hub именем созданного вами менеджера оче­
редей.
Примечание. Вышеописанные действия могут быть выполнены на одном
компьютере. В этом случае просто подставьте вместо host1.example.com хост-имя
или IP-адрес своего компьютера.
Если ваш компьютер не имеет IP­-адреса либо его адрес часто меняется, можно
использовать универсальное хост-имя локального компьютера – localhost.
236
Глава 10
10.2.1. Создание и запуск слушателя
Ниже рассказывается, как создать и запустить для менеджера очередей слушатель
(listener), предоставляющий возможность идентификации в сети. В WebSphere MQ 6.0
слушатели являются объектами WebSphere MQ, объявленными в менеджере очередей.
Эти действия можно выполнить при помощи WebSphere MQ Explorer или команд
MQSC.
Примечание. Предполагается, что вы работаете с менеджером очередей
WebSphere MQ V6.0, в прежних версиях слушатели создавались и запускались
независимо от менеджеров очередей.
Слушатель отслеживает некоторый порт в TCP/IP-сети. Порт – фундаментальное
поня­тие TCP/IP-сетей. Существует множество портов, которые могут прослушиваться
сетевыми службами, работающими на компьютере. Предполагается, что выбранные
для следующих примеров порты не прослушиваются другими службами. В противном
случае выберите другой порт и замените им соответствующие номера портов в при­
веденных ниже примерах.
Если в системе работает единственный менеджер очередей, он обычно прослушивает
порт 1414 – стандартный порт WebSphere MQ. В приведенных ниже инструкциях
используется произвольный диапазон портов, который вряд ли будет занят другими
менеджерами очередей и сетевыми службами.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Listeners в менеджере очередей и выберите
New\TCP Listener.
Примечание. Папка Listeners находится внутри папки Advanced менеджера
очередей (см. дерево папок в окне навигатора).
Если флажок Create listener configured for TCP/IP на странице Enter listener
options (Step 4) мастера Create Queue Manager был помечен, объект-слушатель
LISTENER.TCP был создан автоматически.
В этом случае щелкните правой кнопкой объект-слушатель в таблице и выберите
Stop. После остановки слушателя щелкните его правой кнопкой, выберите
команду Delete и подтвердите удаление.
2. Введите LISTENER.TCP в поле name.
3. Щелкните Next.
4. Введите в поле Description следующий текст:
TCP/IP Listener for queue manager
5. Введите 9001 в поле Port.
Построение инфраструктуры WebSphere MQ: практическое руководство
237
6. Установите для поля Control значение Queue Manager, чтобы слушатель автомати­
чески запускался и останавливался вместе с менеджером очередей.
7. Щелкните Finish.
8. Щелкните правой кнопкой строку LISTENER.TCP в таблице и выберите Start – слу­
шатель будет запущен.
9. Убедитесь, что в столбце Listener status содержится значение Running. В против­
ном случае щелкните кнопку Refresh в правом верхнем углу экрана и снова про­
верьте состояние слушателя.
Примечание. Если в столбце состояния по-прежнему находится значение
Stopped, скорее всего, в системе работает другой менеджер очередей, прослушивающий выбранный порт. Проверьте наличие объекта-слушателя LISTENER.TCP в каждом из менеджеров очередей, работающих на компьютере.
Менеджеры очередей, работающие на одном компьютере, должны прослушивать
разные TCP/IP-порты.
Применение команд MQSC
Выполните следующие действия.
1. Создайте объект-слушатель, который автоматически запускается и останавливает­
ся вместе с менеджером очередей. Для этого выполните следующую команду
MQSC в отношении менеджера очередей host1/echo.hub:
DEFINE LISTENER('LISTENER.TCP’) + TRPTYPE(TCP) PORT(9001) CONTROL(QMGR) +
DESCR(‘TCP/IP Listener for queue manager’)
2. Запустите слушатель, выполнив следующую команду MQSC:
START LISTENER('LISTENER.TCP')
Примечание. Если вы используете WebSphere MQ Explorer, отмечайте
флажок Create listener configured for TCP/IP на странице Enter listener options
(Step 4) мастера Create Queue Manager, чтобы при необходимости автоматически
создавать объекты-слушатели вместе с менеджерами очередей.
Проверьте, свободен ли выбранный порт, перед щелчком Finish. Порт, к которому
привязан объект-слушатель, можно изменить и после создания менеджера
очередей. После смены порта непременно перезапустите слушатель.
10.2.2. Создание объекта канала серверного подключения
Объект канала серверного подключения определяет имя и атрибуты канала для кли­
ентских подключений к менеджеру очередей.
Один из ключевых атрибутов, которые можно настроить для объекта канала сервер­
ного подключения, – идентификатор локального пользователя, под которым удален­
238
Глава 10
ные приложения подключаются через канал, представленный данным объектом
(обычно это идентификатор пользователя MCA, MCAUSER).
Это удобно, поскольку приложения, обращающиеся к менеджеру очередей с удален­
ных машин, могут работать под различными пользовательскими учетными записями
(например, если один из них работает на компьютере под управлением UNIX, а дру­
гой – на Windows-компьютере). При выполнении приведенных ниже упражнений
можно использовать имя, под которым вы входите в систему. Это позволит приложе­
ниям, работающим на любом компьютере, обращаться к компьютеру, на котором ра­
ботает менеджер очередей, с привилегиями администратора WebSphere MQ.
Ниже рассказывается, как создать объект канала серверного подключения с именем
all.clients, который будет использоваться в примерах этого раздела для подключения
приложений к менеджеру очередей. Это делается с использованием WebSphere MQ
Explorer или команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Channels в менеджере host1/echo.hub и выбери­
те New\Server-connection Channel.
2. Введите all.clients в поле Name.
3. Щелкните Next.
4. При желании перейдите в секцию MCA и укажите имя пользователя в поле MCA
user ID.
5. Щелкните Finish.
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера очередей host1/echo.
hub:
DEFINE CHANNEL('all.clients') CHLTYPE(SVRCONN) MCAUSER(‘имя_пользователя')
10.2.3. Подключение с использованием переменной
окружения MQSERVER
Клиентский канальный агент (message channel agent, MCA), доступный при работе
с MQI напрямую (например, из приложений, написанных на С), может быть настроен
при помощи переменных окружения. Базовые атрибуты, включая имя канала и под­
ключения, настраиваются при помощи переменной MQSERVER.
Приложения, использующие базовый клиентский MCA , и те, что работают с менед­
жером очередей напрямую, создают с применением разных наборов библиотек
WebSphere MQ. Библиотеки, применяемые в первом случае, обычно называются клиентскими библиотеками WebSphere MQ.
С WebSphere MQ поставляются версии базовых программ-примеров, таких как
amqsput, amqsget, amqsbcg, amqsreq и amqsech, скомпилированных с использовани­
Построение инфраструктуры WebSphere MQ: практическое руководство
239
ем клиентских библиотек WebSphere MQ. Для вызова этих версий добавьте латинскую
букву «c» к имени нужного приложения, например: amqsputc, amqsgetc, amqsbcgc,
amqsreqc или amqsechc.
Примечание. Клиентские MCA, предназначенные для использования с другими API, такими как Java, JMS, .NET и XMS, настраиваются по-другому.
Подробнее об этом см. в руководстве WebSphere MQ по тому API, с которым вы
работаете.
При подключении к менеджеру очередей в режиме клиента задают имя менеджера
(обычно оно совпадает с именем менеджера, к которому требуется подключиться).
Если вместо имени ввести звездочку (*), можно подключиться к произвольному менед­
жеру очередей.
Чтобы добавить или извлечь сообщения из очереди, подключившись к менеджеру
очередей как клиент, с использованием переменной окружения MQSERVER и про­
грамм-примеров WebSphere MQ, выполните следующие действия.
1. Определите в локальном менеджере очередей очередь с произвольным именем
(в данном примере – queue1).
2. Присвойте переменной окружения MQSERVER следующее значение:
– в Windows:
set MQSERVER=all.clients/TCP/host1.example.com(9001)
– в UNIX:
MQSERVER=all.clients/TCP/’host1.example.com(9001)’ export MQSERVER
3. Добавьте сообщения в очередь с помощью команды amqsputc:
amqsputc queue1 host1/echo.hub
4. Для просмотра сообщений в очереди воспользуйтесь командой amqsbcgc:
amqsbcgc queue1 host1/echo.hub > queue1.txt
5. Извлеките сообщения из очереди командой amqsgetc:
amqsgetc queue1 host1/echo.hub
6. Для запроса эхо-службы, запускаемой с помощью триггера для очереди host1/
echo.hub, выполните следующую команду:
amqsreqc echo host1/echo.hub echo.replies.manual
Примечание. При возникновении ошибок с кодами 2058 или 2059 проверьте
системные журналы ошибок WebSphere MQ и менеджера очередей (см. раздел
5.3.15).
240
Глава 10
10.2.4. Подключение с использованием объекта
канала клиентского подключения
Объекты каналов клиентского подключения в WebSphere MQ предназначены для
исчер­пывающей настройки атрибутов клиентских MCA.
При определении объекта канала клиентского подключения создается запись в файле,
называемом «таблица определений клиентских каналов» (client channel definition
table, CCDT), данного менеджера очередей. Он используется клиентами для получения
сведений о доступных менеджерах очередей. Этот файл может быть создан любым
менеджером очередей, а не только тем, к которому подключается приложение. Далее
этот файл может быть скопирован на удаленные машины либо опубликован в сети.
Ниже рассказывается, как сконфигурировать базовые программы-примеры Web­
Sphere MQ с использованием параметров, заданных в CCDT, при подключении
к менед­жерам очередей.
Выполните следующие действия.
1. Создайте для менеджера очередей host1/echo.hub два канала серверного подклю­
чения (см. раздел 10.2.2) с именами client.channel1 и client.channel2. Альтернатив­
ный вариант – определение отдельных каналов у различных менеджеров очере­
дей, слушатели которых привязаны к разным портам одного или различных ком­
пьютеров.
2. Создайте два объекта канала клиентского подключения (оба для менеджера оче­
редей host1/echo.hub), их имена должны соответствовать именам ранее создан­
ных объектов каналов серверных подключений.
– В WebSphere MQ Explorer.
i. Щелкните правой кнопкой папку Client Connections для менеджера host1/
echo.hub и выберите New\Client-connection Channel.
ii. Введите client.channel1 в поле Name.
iii. Щелкните Next.
iv. Введите echo.hub в поле Queue manager name (здесь преднамеренно вводит­
ся имя, отличное от реального имени менеджера очередей).
v. Введите host1.example.com(9001) в поле Connection name.
vi. Щелкните Finish.
vii. Повторите шаги i–vi, чтобы создать второй объект канала клиентского
подключения с именем client.channel2. Атрибуту, задающему имя менеджера
очередей, должно быть присвоено значение echo.hub . Имя подключения
может быть тем же, если оба объекта канала серверного подключения свя­
заны с одним менеджером очередей (в противном случае используйте имя,
заданное для подключения ко второму менеджеру очередей).
– С помощью команд MQSC. Исполните следующие команды MQSC в отношении
менеджера очередей host1/echo.hub:
Построение инфраструктуры WebSphere MQ: практическое руководство
241
DEFINE CHL('client.channel1') CHLTYPE(CLNTCONN) + QMNAME('echo.hub')
CONNAME('host1.example.com(9001)’)
DEFINE CHL(‘client.channel2’) CHLTYPE(CLNTCONN) + QMNAME(‘echo.hub’)
CONNAME(‘host1.example.com(9001)’)
Атрибут «имя подключения» (CONNAME) во втором определении может содер­
жать имя подключения к другому менеджеру очередей, представленного объектом
канала серверного подключения client.channel2.
3. Ниже предполагается, что клиентское приложение работает на той же машине,
что и менеджер очередей host1/echo.hub. В противном случае скопируйте CCDT
на эту машину и отредактируйте переменные окружения, прописав в них локаль­
ные пути по отношению к клиентским приложениям.
Чтобы указать клиентскому MCA, используемому программами-примерами Web­
Sphere MQ, расположение CCDT, определите следующие переменные окружения.
– В Windows:
set MQSERVER=
set «MQCHLLIB=C:\Program Files\IBM\WebSphere MQ\Qmgrs\host1&echo!hub\@ipcc»
set MQCHLTAB=AMQCLCHL.TAB
– В UNIX:
unset MQSERVER
MQCHLLIB=’/var/mqm/qmgrs/host1&echo!hub/@ipcc’
MQCHLTAB=AMQCLCHL.TAB
export MQCHLLIB
export MQCHLTAB
4. Запустите программу-пример amqsputc для менеджера очередей host1/echo.hub:
amqsputc queue1 *echo.hub
Примечание. Символ «звездочка» (*) указывает, что приложению не требуется подключение к определенному менеджеру очередей. При этом используются
любые записи CCDT, у которых атрибут «имя менеджера очередей» равен «echo.hub».
5. Оставьте программу amqsputc подключенной к менеджеру очередей в ожидании
ввода.
6. Отобразите имя используемого канала (если используется два менеджера очере­
дей, выполните эти действия для каждого менеджера).
– С помощью WebSphere MQ Explorer.
Выберите папку Channels (в менеджере очередей host1/echo.hub). Обратите вни­
мание, что объекты каналов серверных подключений client.channel1 и client.
channel2 находятся в состоянии running («работает»).
242
Глава 10
Примечание. Чтобы получить дополнительные сведения о подключении,
щелкните правой кнопкой менеджер очередей host1/echo.hub в окне навигатора,
выберите Application Connections, а затем щелкните нужное подключение.
– С помощью MQSC.
Выполните следующую команду MQSC; заметьте, что для одного из объектов кана­
ла серверного подключения поле STATUS имеет значение RUNNING:
DIS CHSTATUS('client.*')
7. Передайте пустую строку программе amqsputc, чтобы завершить ее.
8. Отключите канал серверного подключения.
– В WebSphere MQ Explorer
Выберите папку Channels (для host1/echo.hub). Щелкните правой кнопкой канал
и выберите Stop; убедитесь, что в поле New State указано значение Stopped.
– С помощью команд MQSC.
Выполните следующую команду в отношении менеджера очередей host1/echo.
hub, указав имя работающего канала:
STOP CHANNEL('client.channel1') STATUS(STOPPED)
9. Снова запустите программу amqsputc. Обратите внимание, что она работает, хотя
ранее использованный канал теперь недоступен, поскольку используется вторая
запись CCDT (которая может соответствовать другому менеджеру очередей, как
сказано выше).
10.2.5. Удаленное администрирование менеджера очередей
Ниже рассказывается о применении WebSphere MQ Explorer для удаленного адми­
нистрирования менеджеров очередей с использованием клиентских подключений.
В этом примере предполагается, что менеджер очередей работает на одном компью­
тере с WebSphere MQ Explorer. Однако WebSphere MQ Explorer также поддерживает
администрирование менеджеров очередей на нескольких удаленных компьютерах,
в том числе на разных платформах. Кроме того, WebSphere MQ Explorer также позво­
ляет администрировать менеджеры очередей в WebSphere MQ для z/OS V6.0.
Построение инфраструктуры WebSphere MQ: практическое руководство
243
Примечание. Для удаленного администрирования менеджеров очередей
с помощью WebSphere MQ Explorer требуется:
 объект-слушатель, привязанный к известному порту;
 объект канала серверного подключения с известным именем;
 работающий командный сервер;
 модельная очередь SYSTEM.MQEXPLORER.REPLY.MODEL.
В Windows и UNIX менеджеры очередей, созданные при помощи WebSphere MQ
V6.0, по умолчанию имеют работающий командный сервер и нужную модельную
очередь. Однако менеджеры очередей в WebSphere MQ версии 5.3 и ниже
требуют ручной настройки этих компонентов; то же верно для менеджеров,
созданных в WebSphere MQ V5.3 и обновленных до WebSphere MQ V6.0. Чтобы
вручную подготовить нужные компоненты, выполните следующие действия.
1. Выполните следующую команду WebSphere MQ, чтобы вручную запустить командный сервер для менеджера очередей:
strmqcsv имя_менеджера_очередей
2. Определите нужную модельную очередь следующей командой MQSC:
DEFINE QMODEL('SYSTEM.MQEXPLORER.REPLY.MODEL') DEFTYPE(TEMPDYN)
Далее выполните следующие действия.
1. Щелкните правой кнопкой папку Queue Managers в WebSphere MQ Explorer и выбе­
рите Show/Hide Queue Managers (см. рис. 10.1).
Рис. 10.1. Окно Show/Hide Queue Managers в WebSphere MQ Explorer
244
Глава 10
2. В окне Show/Hide Queue Managers щелкните Add – запустится мастер Add Queue
Manager, позволяющий настроить способ подключения WebSphere MQ Explorer
к менеджеру очередей. В этом примере подключение будет выполнено, как описа­
но в разделе 10.2.3.
3. На первой странице мастера введите имя менеджера очередей в поле Queue
manager name, например host1/echo.hub.
4. Установите параметр Connect directly.
5. Щелкните Next.
6. Введите хост-имя или IP-адрес компьютера, на котором работает менеджер оче­
редей host1/echo.hub. В этом примере используется хост-имя host1.example.com, для
локального компьютера можно использовать имя localhost.
7. Укажите порт, к которому привязан слушатель заданного менеджера очередей,
например 9001.
8. Укажите имя объекта канала серверного подключения, объявленного для менед­
жера очередей (в этом примере – all.clients).
9. Щелкните Finish.
Ниже на рис. 10.2 показан пример вводимой информации.
Рис. 10.2. Запуск мастера Add Queue Manager для прямого подключения к менеджеру очередей
В результате выбранный менеджер очередей будет добавлен к таблице Shown Queue
Managers в окне Show/Hide Queue Managers.
10.Щелкните Close в окне Show/Hide Queue Managers.
Построение инфраструктуры WebSphere MQ: практическое руководство
245
11.Заметьте, что теперь этот менеджер очередей доступен в папке Queue Managers,
подобно локальным менеджерам очередей. Имя подключения, добавленное к име­
ни этого менеджера очередей, свидетельствует о том, что он является удален­ным, а его значок отличается от значков локальных менеджеров очередей
(см. рис. 10.3).
Рис. 10.3. Удаленное администрирование менеджера очередей в WebSphere MQ Explorer
10.2.6. Пример публикации-подписки для JMS,
использующий клиентское подключение
Чтобы настроить пример, иллюстрирующий публикацию-подписку в JMS (см. 9.5)
для использования клиентского подключения к менеджеру очередей, достаточно
изме­нить объекты в каталоге так, чтобы к ним можно было обращаться через JNDI.
Ни исходный текст, ни способ вызова примера модификации не требует.
Ниже описано, как настроить объекты в каталоге для доступа через JNDI, чтобы про­
грамма-пример для JMS смогла подключаться к менеджеру очередей как клиент.
Выполните следующие действия.
1. Настройте текущее окно командной строки или терминальный сеанс, как описано
в разделе 9.5.1.
2. Настройте слушатель для менеджера очередей host1/jmspubsub , привязав его
к порту 9010 (см. раздел 10.2.1).
3. Объявите объект канала серверного подключения с именем jms.clients для менед­
жера host1/jmspubsub.
4. Запустите утилиту WebSphere MQ JMS Administration tool (см. раздел 9.5.6).
5. Объявите в TCF клиентское подключение для удаленного менеджера очередей
(ранее TCF использовался для подключения к локальному менеджеру очередей).
Для этого выполните следующую команду в WebSphere MQ JMS Administration tool
(вводите команду как одну строку):
ALTER TCF(PubSub.TCF) HOSTNAME(host1.example.com) PORT(9010)
TRANSPORT(CLIENT) CHANNEL(jms.clients)
246
Глава 10
6. Завершите WebSphere MQ JMS Administration tool с помощью команды END.
7. Запустите программу-пример (не изменяя код и не компилируя ее заново) как из­
датель (см. 9.5.11), затем как подписчик (см. 9.5.10).
10.3. Построение центрально-лучевой инфраструктуры
В этом разделе рассказывается, как сделать менеджер очередей host1/echo.hub цент­
ральным элементом такой инфраструктуры, как создать периферийные менеджеры
очередей («лучи») и вручную настроить взаимодействие между менеджерами, пред­
ставляющими «центр» и «лучи» инфраструктуры.
В результате все периферийные менеджеры очередей получат доступ к службе echo,
работающей в менеджере host1/echo.hub.
10.3.1. Создание очереди недоставленных сообщений
для центрального менеджера
Ниже рассказывается, как создать очередь недоставленных, сообщений (dead letter
queue) для менеджера очередей host1/echo.hub, чтобы не потерять неверно адресо­
ванные непостоянные сообщения. Без этой предосторожности найти сообщения,
циркулирующие в инфраструктуре, с использованием каналов бывает очень сложно.
Д а н н а я з а д а ч а р е ш а е т с я с и с п о л ь з о в а н и е м We b S p h e r e M Q E x p l o r e r и л и
команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues для менеджера очередей host1/echo.hub
и выберите New\Local Queue.
2. Введите dead.letters в поле Name.
3. Щелкните Finish.
4. Щелкните правой кнопкой значок менеджера очередей host1/echo.hub и выбери­
те Properties.
5. Перейдите в секцию Extended окна свойств.
6. Введите dead.letters в поле Dead letter queue.
7. Щелкните OK.
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC в отношении менеджера очередей host1/
echo.hub, чтобы создать объект локальной очереди:
DEFINE QLOCAL(‘dead.letters’)
Построение инфраструктуры WebSphere MQ: практическое руководство
247
2. Выполните следующую команду MQSC в отношении менеджера очередей host1/
echo.hub, чтобы настроить его объект для использования ранее созданной очереди
недоставленных сообщений:
ALTER QMGR DEADQ('dead.letters')
Примечание. Проследите, чтобы значение атрибута DEADQ в точности
соответствовало имени только что созданного объекта локальной очереди.
10.3.2. Создание объекта receiver-канала для центрального
менеджера очередей
Ниже рассказывается, как объявить для центрального менеджера очередей объект
канала, обеспечивающий связь с периферийными менеджерами очередей централь­
но-лучевой инфраструктуры (в этом примере используется единственный объект
receiver-канала). Ниже описано, как настроить связь между центральным и каждым
из периферийных менеджеров очередей.
Это делается с использованием WebSphere MQ Explorer или команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Channels менеджера очередей host1/echo.hub
и выберите New\Receiver Channel.
2. Введите to.host1/echo.hub в поле Name.
3. Щелкните Finish.
Применение команд MQSC
1. Выполните следующую команду MQSC в отношении менеджера очередей host1/
echo.hub:
DEFINE CHANNEL('to.host1/echo.hub') CHLTYPE(RCVR)
2. Проверьте атрибуты канала, выполнив следующую команду MQSC:
DISPLAY CHANNEL('to.host1/echo.hub')
10.3.3. Создание и запуск периферийного менеджера очередей
со слушателем
Рекомендуется выполнить приведенные ниже инструкции хотя бы один раз, чтобы
освоить создание периферийных менеджеров очередей. В дальнейшем при необхо­
димости можно создавать дополнительные периферийные менеджеры, повторяя эти
действия с использованием других менеджеров и имен подключений.
Сначала создайте и запустите новый менеджер очередей (предполагается, что имя
менеджера очередей, созданного первым, будет host2/spoke).
248
Глава 10
Для новых менеджеров можно увеличить число в имени host2 либо заменять его
именами компьютеров (если вы используете несколько разных компьютеров).
Чтобы различать компьютеры, на которых работают центральный и периферийные
менеджеры очередей, ниже используется хост-имя namehost2.example.com.
Его следует заменить хост-именем либо IP-адресом реального компьютера. Как
и в предыдущих примерах, все менеджеры очередей могут работать на одном компь­
ютере. В этом случае замените host2.example.com IP-адресом либо хост-именем
локального компьютера либо на localhost.
Для каждого из менеджеров очередей необходимо определить слушатель. Если пред­
полагается использовать на одном компьютере несколько менеджеров очередей,
реко­мендуется назначать им номера портов, связанные с их именами. Так, слушатель
первого из периферийных менеджеров очередей следует привязать к порту 9002.
Для каждого следующего менеджера увеличивайте номер порта на единицу во избе­
жание путаницы.
Примечание. Слушателям менеджеров очередей, работающих на разных
компьютерах, можно назначать одинаковые порты. Для менеджеров, работающих
на одном и том же компьютере, необходимо использовать разные порты.
Также рекомендуется создать для каждого из периферийных менеджеров очередь
недоставленных сообщений (см. 10.3.1; имя «host1/echo.hub» следует заменить име­
нами периферийных менеджеров очередей).
10.3.4. Создание транспортной очереди для периферийного
менеджера очередей
Транспортная очередь (transmission queue) играет роль временного хранилища сооб­
щений, предназначенных для передачи другому менеджеру очередей в составе инф­
раструктуры. Однако сама по себе транспортная очередь не передает сообщения
другому менеджеру. Это просто объект локальной очереди, назначенный для исполь­
зования в этой роли.
Для работы с транспортными очередями применяют WebSphere MQ Explorer
и команды MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Queues менеджера очередей host2/spoke и вы­
берите New\Local Queue.
2. Введите host1/echo.hub в поле Name.
3. Щелкните Next.
4. Выберите значение Transmission в поле Usage.
Построение инфраструктуры WebSphere MQ: практическое руководство
249
5. В поле Description введите следующий текст:
Transmission queue for messages to host1/echo.hub
6. Щелкните Finish.
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера очередей host2/
spoke:
DEFINE QLOCAL('host1/echo.hub') USAGE(XMITQ) + DESCR('Transmission queue for
messages to host1/echo.hub')
Примечание. Следите за правильностью регистра имени менеджера очередей; кроме того, имя должно заключаться в одинарные кавычки.
10.3.5. Создание объекта sender-канала для периферийного
менеджера очередей
Объект sender-канала позволяет установить связь между двумя менеджерами очере­
дей в инфраструктуре. Имя объекта sender-канала должно соответствовать имени
объекта удаленного канала совместимого типа, объявленного в менеджере очередей,
являющемся получателем сообщений. Объект канала получателя уже объявлен в цент­
ральном менеджере очередей; все периферийные менеджеры очередей используют
этот объект для подключения к центральному менеджеру очередей.
Канал принимает сообщения от транспортной очереди менеджера и передает их
удаленному менеджеру очередей. Создать канал можно с использованием WebSphere
MQ Explorer или команд MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Щелкните правой кнопкой папку Channels в менеджере очередей host2/spoke
и выберите New\Sender Channel.
2. Введите to.host1/echo.hub в поле Name.
3. Щелкните Next.
4. Объект sender-канала используется для создания каналов связи с центральным
менеджером, поэтому полю Connection name присваивают следующее значение:
host1.example.com(9001)
5. Введите host1/echo.hub в поле Transmission queue.
6. Щелкните Finish.
250
Глава 10
Применение команд MQSC
Выполните следующие действия.
1. Выполните следующую команду MQSC в отношении менеджера очередей host2/
spoke:
DEFINE CHANNEL('to.host1/echo.hub') CHLTYPE(SDR) +
CONNAME('host1.example.com(9001)’) XMITQ(‘host1/echo.hub’)
2. Проверьте атрибуты канала при помощи следующей команды MQSC:
DISPLAY CHANNEL('to.host1/echo.hub')
10.3.6. Проверка канала с помощью команды ping WebSphere MQ
Ниже рассказывается, как с помощью команды WebSphere MQ ping проверить связь
через канал. Однако, при этой проверке сообщения через канал не передаются. Для
этой цели используются WebSphere MQ Explorer или команды MQSC.
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выберите папку Channels менеджера очередей host2/spoke.
2. Щелкните правой кнопкой элемент to.host1/echo.hub и выберите команду Ping.
3. Откроется окно с результатами.
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера очередей host2/
spoke:
PING CHANNEL('to.host1/echo.hub')
Примечание. Если команда ping вернет ошибку, проверьте следующее:
в объекте sender-канала указано верное хост-имя или IP-адрес, а также номер
порта для менеджера очередей host1/echo.hub;
имя объекта sender-канала соответствует имени объекта receiver-канала, объявленного в host1/echo.hub, вплоть до регистра символов;
у менеджера очередей host1/echo.hub имеется активный слушатель.
10.3.7. Настройка и активация канала связи с центральным
менеджером очередей
Ниже рассказывается, как автоматически стартовать канал связи между перифе­
рийным и центральным менеджерами очередей с помощью инициатора каналов
WebSphere MQ при поступлении сообщения в транспортную очередь. Это делается
с использованием WebSphere MQ Explorer и команд MQSC.
Построение инфраструктуры WebSphere MQ: практическое руководство
251
Применение WebSphere MQ Explorer
Выполните следующие действия.
1. Выберите папку Queues в менеджере очередей host2/spoke.
2. Щелкните правой кнопкой очередь host1/echo.hub и выберите Properties.
3. Перейдите в секцию Triggering окна свойств очереди.
4. В поле Trigger control установите значение On.
5. В поле Trigger type введите First.
6. Введите to.host1/echo.hub в поле Trigger data.
7. Введите SYSTEM.CHANNEL.INITQ в поле, которое содержит имя очереди инициации.
8. Щелкните OK.
Применение команд MQSC
Выполните следующую команду MQSC в отношении менеджера очередей host2/
spoke:
ALTER QLOCAL('host1/echo.hub') TRIGGER TRIGTYPE(FIRST) + TRIGDATA('to.host1/
echo.hub') INITQ('SYSTEM.CHANNEL.INITQ')
Примечание. Для успешной активации к