Оглавление �

Оглавление

Примечания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .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 .1 .5 . Обменсообщениямипопринципу«публикации-подписки» . . . . . . . . . . . . . 7

2 .2 . Упрощение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 .2 .1 . Разработкасакцентомнабизнес-логике . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 .2 .2 . Сопровождениеприложенийипереносимостьихкода . . . . . . . . . . . . . . . . 10

2 .3 . Расширяемостьискоростьработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 .4 . Надежностьслужбицелостностьданных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 .4 .1 . Однократнаядоставка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 .4 .2 . Единицыработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 .4 .3 . Обработкаошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 .4 .4 . Средаобеспеченияконтролякачества . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

�I Оглавление

2 .5 . Защита . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 .5 .1 . Защитадоступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 .5 .2 . Защитакоммуникаций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 .6 . Высокаяготовностьсистемы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 .6 .1 . Доступностьслужб . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 .6 .2 . Доступностьсообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 .6 .3 . Восстановлениепослесбоя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 .7 . Мониторингиучетопераций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 .7 .1 . Мониторингпроизводительности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 .7 .2 . Учет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Глава 3 . Средства поддержки очередей сообщений в WebSphere MQ . . . . . . . . . . . . . 21

3 .1 . Базовыепонятия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 .1 .1 . ИнфраструктураочередейсообщенийWebSphereMQ . . . . . . . . . . . . . . . . . 22

3 .1 .2 . СредствареализацииинфраструктурыWebSphereMQ . . . . . . . . . . . . . . . . 22

3 .1 .3 . Пакетыдополнительныхфункций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 .2 . Упрощение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 .2 .1 . ДоступприложенийкинфраструктуреWebSphereMQ . . . . . . . . . . . . . . . . 24

3 .2 .2 . АсинхронноевзаимодействиесиспользованиемWebSphereMQ . . . . . . . . 24

3 .2 .3 . ОбобщенныепунктыназначенияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . 25

3 .2 .4 . ОсобыепунктыназначенияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 .2 .5 . ПредоставлениеуслугвинфраструктуреWebSphereMQ . . . . . . . . . . . . . . . 25

3 .2 .6 . ОчередиWebSphereMQкакинтерфейсдоступакслужбам . . . . . . . . . . . . . 26

3 .2 .7 . СтандартизованныеAPI-интерфейсы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 .2 .8 . WebSphereMQиWebSphereApplicationServer . . . . . . . . . . . . . . . . . . . . . . . 27

3 .2 .9 . Web-службыкакинтерфейсдоступакслужбам . . . . . . . . . . . . . . . . . . . . . . 28

3 .2 .10 . УпрощеннаяобработкасбоеввWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . 29

3 .3 . Расширяемостьискоростьработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 .3 .1 . РасширяемостьменеджеровочередейWebSphereMQ . . . . . . . . . . . . . . . . . 30

3 .3 .2 . Архитектурасоднимменеджеромочередейсообщений . . . . . . . . . . . . . . . 30

3 .3 .3 . Центрально-лучеваяархитектураWebSphereMQ . . . . . . . . . . . . . . . . . . . . . 31

3 .3 .4 . Кластерыменеджеровкаквозможностьгибкогорасширения . . . . . . . . . . 33

3 .4 . Надежностьслужбицелостностьданных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 .4 .1 . Постоянныеинепостоянныесообщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 .4 .2 . Единицыработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Оглавление �II

3 .5 . Безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 .5 .1 . ObjectAuthorityManager(OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 .5 .2 . SSL-протоколизащитатранспортногоуровнястека(TLS) . . . . . . . . . . . . . 37

3 .5 .3 . ЗащитакоммуникацийпоSSL-протоколуитехнологииTLS . . . . . . . . . . . . 37

3 .6 . Высокаяготовностьсистемы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 .6 .1 . Ролькластеровменеджероввработеслужбвысокойготовности . . . . . . . 38

3 .6 .2 . ГруппысразделениемочередейнаWebSphereMQдляz/OS . . . . . . . . . . . . 39

3 .6 .3 . Кластерывысокойготовности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 .6 .4 . Восстановлениепослесбоя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 .7 . Мониторингиучетопераций . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 .7 .1 . Мониторингпроизводительности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 .7 .2 . Учет . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 .7 .3 Трассировкамаршрутасообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Глава 4 . Создание приложений для доступа к инфраструктуре WebSphere MQ . . . . . 43

4 .1 . Кроссплатформеннаяподдержка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 .2 . Интерфейсыприкладногопрограммирования(API) . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 .2 .1 . Интерфейсочередейсообщений(MQI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 .2 .2 . API-интерфейсынабазеобъектноймоделиWebSphereMQ . . . . . . . . . . . . 45

4 .2 .3 . СтандартизованныеAPI-интерфейсыдляWebSphereMQ . . . . . . . . . . . . . . 46

4 .2 .4 . Индивидуальныеадаптеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 .3 . СообщенияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 .3 .1 . Дескрипторсообщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 .3 .2 . Преобразованиеданных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 .3 .3 . Форматысообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 .3 .4 . Сборкасообщенийизихфрагментов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 .4 . ВзаимодействиесинфраструктуройWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 .4 .1 . КлиентскиепродуктыWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 .4 .2 . ОсновныевозможностиприложенияWebSphereMQ . . . . . . . . . . . . . . . . . . 52

4 .5 . Транзакциииединицыработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 .5 .1 . Локальныеединицыработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 .5 .2 . Точкасинхронизации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 .5 .3 . Фиксацияиотмена . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 .5 .4 . Незафиксированныесообщения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 .5 .5 . Глобальныеединицыработы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

�III Оглавление

4 .5 .6 . Координацияглобальныхединицработы . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 .5 .7 . Двухфазоваяфиксация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4 .5 .8 . СпецификацияXA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4 .5 .9 . Расширенныйтранзакционныйклиент . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 .5 .10 . Отказоустойчивостьиобработкаошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 .6 . Межточечныйобменсообщениями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 .6 .15 . Обработкасообщенийслужбой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 .7 . Обменпопринципупубликации-подписки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4 .7 .1 . Брокерпубликации-подпискиWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . 70

4 .7 .2 . Взаимодействиесброкеромпубликации-подпискиWebSphereMQ . . . . . . 71

4 .7 .3 . Потоки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 .7 .4 . Регистрация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 .7 .5 . Темы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 .7 .6 . Публикации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 .7 .7 . РазвитиефункцийпубликациииподпискивWebSphereMQ . . . . . . . . . . . . 72

Глава 5 . Менеджеры очередей: общее представление и настройка . . . . . . . . . . . . . . . 73

5 .1 . Информацияобустановке . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 .1 .1 . Последниедоступныеобновления . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 .1 .2 . Спецификацияокружения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 .2 . ИнтерфейсыадминистрированияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 .2 .1 . WebSphereMQExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 .2 .2 . МодульWebSphereMQExplorerHealthcheck . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 .2 .3 . УправляющиекомандыWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 .2 .4 . КомандыязыкауправленияWebSphereMQдляiSeries . . . . . . . . . . . . . . . . 81

5 .2 .5 . КомандыWebSphereMQдляz/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5 .2 .6 . КомандыWebSphereMQScript(MQSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5 .2 .7 . Форматыпрограммируемыхкоманд(PCF) . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5 .3 . Менеджерочередейсообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5 .3 .1 . Наименованиеменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5 .3 .2 . ОбъектыWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5 .3 .3 . ГруппысразделениемочередейвWebSphereMQдля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 . СлушательWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5 .3 .10 . ИнициаторканаловWebSphereMQдля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 . ДескрипторсообщенияWebSphereMQ(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 .1 .11 . MQDISC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6 .2 . Очереди . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 .2 .7 . Состояниеионлайновыймониторингочередей . . . . . . . . . . . . . . . . . . . . . 132

6 .3 . Применениетриггеров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 .1 .2 . Канальныеагенты(MCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7 .2 . Запускиостановканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7 .2 .1 . Понятиесостоянияканала . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7 .2 .2 . Названияканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

7 .3 . Клиентскиеканалы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7 .3 .1 . Функционированиеканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

7 .3 .2 . Канальныеобъектысерверныхподключений . . . . . . . . . . . . . . . . . . . . . . . 144

7 .3 .3 . Замечанияобезопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

7 .3 .4 . НастройкаклиентскогоMCAдляподключениякменеджеру . . . . . . . . . . . 145

7 .3 .5 . Канальныеобъектыклиентскихподключений . . . . . . . . . . . . . . . . . . . . . . 146

7 .3 .6 . Таблицаопределенийклиентскихканалов(CCDT) . . . . . . . . . . . . . . . . . . . 147

7 .4 . Распределенныеканалысообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7 .4 .1 . Отправкасообщений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

7 .4 .2 . Пакеты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

7 .4 .3 . Неоднозначныеканалыипорядковыеномерасообщения . . . . . . . . . . . . . 151

X Оглавление

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 .4 .13 . Инициированиеканала . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

7 .5 . Автоопределениеканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 .1 .9 . Подпискиипубликациивкластере . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

8 .2 . Просмотрсведенийизрепозиториякластера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

8 .2 .1 . ПросмотрсведенийизрепозиториячерезMQSC . . . . . . . . . . . . . . . . . . . . 173

8 .2 .2 . ПросмотрсведенийизрепозиториявWebSphereMQExplorer . . . . . . . . . 175

8 .3 . Работасменеджерамиочередейвкластере . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

8 .3 .1 . Приостановкаивозобновлениеработыменеджераочередейвкластере . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179

8 .3 .2 . Сбросчленстваменеджераочередейвкластере . . . . . . . . . . . . . . . . . . . . 180

8 .3 .3 . Этапыподключенияменеджераочередейккластеру . . . . . . . . . . . . . . . . . 180

8 .3 .4 . Этапыудаленияменеджераизкластера . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

8 .4 . Балансировканагрузки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Администрированиеменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . 194

9 .1 .2 Программы-примерывWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

9 .2 . Настройкаокружения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

9 .2 .1 . УстановкаWebSphereMQV6 .0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

9 .2 .2 ПривилегииадминистратораWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . 195

9 .2 .3 . ДоступкпримерамWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

9 .2 .4 . ОJava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

9 .3 . Обменсообщениямиспомощьюлокальногоменеджераочередей . . . . . . . . . . . 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 .3 .14 . Удалениеменеджераочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

9 .4 . Созданиеслужбобработкизапросовиответовнаосновеочереди . . . . . . . . . . . 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 . ЗапусктриггерногомонитораWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . 221

9 .4 .10 . Отправказапросаслужбе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

9 .4 .11 .Созданиеобъектамодельнойочередидлядинамическойочередиответов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

9 .4 .12 .ОтправкаЗапросасиспользованиемвременнойдинамическойочередиответов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 .5 . РассылкасообщенийпоподпискевWebSphereMQспомощью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спомощьюJMSAdministrationtool . . . . . . . . . . . . . . . . . . 231

9 .5 .7 . КопированиепримераJMS-приложенияWebSphereMQ . . . . . . . . . . . . . . 232

9 .5 .8 . МодификацияпримераJMS-приложенияWebSphereMQ . . . . . . . . . . . . . 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 . ПоверкаканаласпомощьюкомандыpingWebSphereMQ . . . . . . . . . . . . . 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

XI� Оглавление

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 . АдминистрированиеновойкопииWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . 268

11 .2 . Предоставлениедоступакресурсамменеджеровочередей . . . . . . . . . . . . . . . . . 268

11 .2 .1 . ObjectAuthorityManager(OAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

11 .2 .2 . ПолномочиядляобъектоввWebSphereMQдляz/OS . . . . . . . . . . . . . . . . 273

11 .3 . Установкаконтекстаидентификационныхданныхклиентскихприложений . . . . 273

11 .3 .1 . Процедураустановкиидентификационныхданных вWebSphereMQпоумолчанию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

11 .3 .2 . ИдентификаторпользователяMCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

11 .4 . SecureSocketsLayer(SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

11 .4 .1 . ПоддержкаSSLвWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

11 .4 .2 . CipherSpec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

11 .4 .3 . ПротоколTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

11 .4 .4 . ОбязательнаяинеобязательнаяSSL-аутентификацияклиентов . . . . . . . 276

11 .4 .5 . Хранилищесертификатовменеджераочередей . . . . . . . . . . . . . . . . . . . . 276

11 .4 .6 . АдминистрированиехранилищсертификатовWebSphereMQ . . . . . . . . . 277

11 .4 .7 . КлиентскиеприложенияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

11 .4 .8 . ДоступклиентскихJava-приложенийкWebSphereMQ . . . . . . . . . . . . . . . 278

11 .4 .9 . SSLиWebSphereMQExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

11 .4 .10 .Списокотозванныхсертификатов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

11 .4 .11 .ВыборЦС . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

11 .4 .12 .ПроверкасоставногоимениспомощьюатрибутаSSL-«Peer» . . . . . . . . 282

11 .4 .13 .Совместимостьсостандартом FederalInformationProcessingStandard(FIPS) . . . . . . . . . . . . . . . . . . . . . . . 283

11 .5 . WebspereMQInternetPass-Thru(IPT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Оглавление X�

Глава 12 . Устранение неполадок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

12 .1 . Базоваяинформация,предоставляемаяMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

12 .1 .1 . СообщенияAMQXXXX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

12 .1 .2 . Кодыпричины . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

12 .1 .3 . Журналыошибокменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

12 .1 .4 . СистемныежурналыошибокWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . 287

12 .1 .5 . Расположениежурналовошибок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

12 .1 .6 . ТехнологияFFST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

12 .1 .7 . ДокументацияпоWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

12 .2 . Устранениеизвестныхнеполадок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

12 .2 .1 . СайтподдержкиWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

12 .2 .2 . Установкаисправленийиобновлений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

12 .2 .3 . «Молнии» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

12 .2 .4 . ПоискAPARиTechnote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

12 .2 .5 . Дополнительныеисточникиинформации . . . . . . . . . . . . . . . . . . . . . . . . . . 290

12 .2 .6 . МодульHealthcheckдляWebSphereMQExplorer . . . . . . . . . . . . . . . . . . . . 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 . ОписаниеиспользованияWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . 301

12 .5 .4 . ПодготовкаописаниясбоядляотправкивIBMService . . . . . . . . . . . . . . . 301

12 .5 .5 . Воспроизведениенеполадок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

12 .5 .6 . ТрассировкаWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

X�I Оглавление

Приложение A . Новое в WebSphere MQ �6 .0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

WebSphereMQExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

КомандыPCFвWebSphereMQдляz/OSV6 .0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

64-разрядныеменеджерыочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

InternetProtocolVersion6(IPv6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

ИзменениявподдержкеSSLвWindows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

УсовершенствованияSSLиTLSисертификацияFIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Встроенныйброкерпубликации-подписки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

WebSphereMQкактранспортдляWeb-сервисов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Усовершенствованиягруппобщихочередейвz/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Балансировканагрузкивкластерахменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . 309

Администрированиеподключенийкменеджеруочередей . . . . . . . . . . . . . . . . . . . . . . . . 309

Унифицированныйметодзапускаиостановкислушателей . . . . . . . . . . . . . . . . . . . . . . . 309

Запускиостановкапроизвольныхслужбвместесменеджерамиочередей . . . . . . . . . . 310

Фильтрацияинформацииоменеджерахочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Улучшенныймониторингвреальномвремени . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Учетиспользованияменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Сборстатистики . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

ТрассировкаинфраструктурыWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Улучшенияведенияжурналовнараспределенныхплатформах . . . . . . . . . . . . . . . . . . . . 312

Динамическоеконфигурированиеменеджеровочередейвz/OS . . . . . . . . . . . . . . . . . . . 313

ШунтыжурналоввWebSphereMQдляz/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Приложение B . Краткий справочник . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

УправляющиекомандыWebSphereMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

КомандыCLвWebSphereMQдляiSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

КомандыMessageQueueInterface(MQI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

КомандныйинтерфейсWebSphereMQScript(MQSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Объектменеджераочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Объектыслушателей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Объектыслужб . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Объектыспискиимен . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Атрибутыобъектасписокимен . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Записикластерныхочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Записикластерныхменеджеровочередей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Каналыиобъектыканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Записисостоянияканалов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Оглавление X�II

Примечания

Информация в этом руководстве охватывает продукцию и услуги, предлагаемые в США.

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

IBM может обладать патентами или патентными заявками на технологии, описанные в настоящем руководстве, предоставление которых не означает наличия лицензии на технологии. Письменные запросы лицензий следует направлять по адресу IBM Direc-tor of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504­1785 USA.

Приведенный ниже абзац не относится к Соединенному Королевству и иным стра-нам, законодательству которых противоречит данное положение: КОРПОРАЦИЯ IBM ПРЕДОСТАВЛЯЕТ ДАННОЕ РУКОВОДСТВО «КАК ЕСТЬ» И НЕ ДАЕТ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ (НО НЕ ОГРАНИЧИВАЯСЬ) ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПАТЕНТНОЙ ЧИСТОТЫ, КОММЕРЧЕСКОЙ ПРИ­ГОДНОСТИ И СООТВЕТСТВИЯ КОНКРЕТНОМУ НАЗНАЧЕНИЮ. В отдельных госу­дарствах отказ от явных и подразумеваемых гарантий по ряду сделок запрещен, так что указанное ограничение может вас не коснуться.

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

Любые ссылки на сайты сторонних компаний в этом руководстве носят исключи­тельно информационный характер и не свидетельствуют об их поддержке корпора­цией IBM; риск, связанный с применением ресурсов этих сайтов, принимает на себя пользователь.

По своему усмотрению и без каких­либо обязательств IBM может использовать и рас­пространять любые предоставленные сведения.

За информацией о сторонних продуктах обращайтесь к производителям, их публи­кациям и другим открытым источникам. IBM не тестировала эти продукты и не может

X�III Примечания

подтвердить точность оценок производительности, совместимости и прочих пара­метров. Соответствующие вопросы следует направлять поставщикам этих продуктов.

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

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

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

Торговые маркиТорговыми марками International Business Machines Corporation в Соединенных Шта­тах и/или других странах являются:

AIX 5L™ IBM® Redbooks™

AIX® iSeries™ SupportPac™

CICS® MQSeries® TXSeries®

DB2® OS/400® WebSphere®

developerWorks® Parallel Sysplex® z/OS®

server® RACF® zSeries®

HACMP®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

Отправьте ваши комментарии по электронной почте на адрес:

redbook@us..ibm.com

Отправьте ваши комментарии в письменной форме по почте на адрес:

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.

XXI� Предисловие

Обзор 1

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 обеспечивает бо­

2 Глава1

гатый выбор возможных альтернативных архитектур и подходов к реализации. При­нятие взвешенного решения с учетом таких возможностей способно упростить как разработку приложений, так и администрирование инфраструктуры 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 для понимания информации, полученной от системы, и способов разрешения проблем, которые могут возникнуть в ходе работы.

Понятиеочередейсообщений 3

2

Понятие очередей сообщений

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

Глава посвящена обсуждению следующих вопросов:

Базовые понятия

Упрощение

Расширяемость и скорость работы

Надежность служб и целостность данных

Защита

Высокая готовность системы

Мониторинг и учет операций

4 Глава2

2 .1 . Базовые понятияВ ИТ­инфраструктуре компании может параллельно существовать множество техно­логий. Зачастую в нее входят различные аппаратные платформы, языки программи­рования, операционные системы и системы коммуникаций.

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

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

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

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

2 .1 .1 . Промежуточное ПОПрограммные приложения, разработанные компанией с целью запроса и предостав­ления служб, требуют связи со службами, реализуемыми системой. Эти службы нахо­дятся в разных ее узлах, а те могут быть созданы с использованием различных инфра­структурных компонентов и технологий.

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

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

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

Основу упомянутой технологии образуют два главных понятия: сообщение и очередь.

Понятиеочередейсообщений 5

2 .1 .2 . СообщенияВходящему в систему узлу нередко требуется передать данные или запросить службу другого узла в той же или связанной с ней системе. Эту порцию информации или запрос можно считать примерами сообщений.

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

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

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

2 .1 .3 . ОчередиОчередь – это контейнер для сообщений. Новые сообщения помещаются в конец очереди, а размещенные в ней, как правило, извлекаются из начала. Движение сооб­щений в пределах очереди показано на рис. 2.1 на стр. 5.

Рис . 2 .1 . Очередьипрохождениесообщений

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

6 Глава2

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

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

Буфер между отправителем и получателем сообщений.

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

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

Пакетная обработка.

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

Буферы между промежуточными узлами системы.

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

2 .1 .4 . Межточечный обмен сообщениямиМногие сообщения предназначены для потребления лишь однажды. Точка внутри системы, где сообщение будет использовано, может быть как известна, так и неизвест­на для отправителя. Однако сам отправитель обеспечивает инфраструктуру сообще­

Понятиеочередейсообщений 7

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

В режиме межточечного обмена сообщение приходит один и только один раз в единственное корректное место своего назначения.

Процесс межточечного обмена можно представить двумя общими категориями.

Обмен по принципу «отправил – забыл».

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

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

Обмен по принципу «запрос – ответ».

Сообщение передается службе, выполняющей действие на базе этого сообщения и посылающей ответ для его отправителя.

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

2 .1 .5 . Обмен сообщениями по принципу публикации-подпискиВ процессе межточечного обмена каждый узел, которому нужна информация, должен знать те конкретные службы, которые могут ему ее предоставить. Аналогично и служ­бы, передающие информацию, должны знать о тех конкретных узлах, которым пере­дают свои данные, и времени, когда это сделать.

Предоставляемые инфраструктурой очередей сообщений в рамках модели межто­чечного обмена функции «отправил – забыл» и «запрос – ответ» служат решением при множестве обстоятельств. Однако в отношении данных, перечисленных ниже, модель межточечного обмена имеет ограничения.

Информация о состоянии.

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

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

Для поддержания актуальности данных об изменениях информации по принципу «запрос – ответ» узел должен посылать службе периодические запросы текущего состояния информации. Для этого он должен знать об узлах, где расположена служба предоставления информации. Такой подход называют опросом.

8 Глава2

Опрос службы – неэффективный способ получения уведомлений об изменениях состояния. Большое число запросов может вернуть одно и то же значение, а посы­лающий запрос узел не получает информации об изменениях до отправки следую­щего запроса. Меньшие интервалы опроса могут повысить точность известной узлу информации, но повышают и требования к ресурсам службы и инфраструк­туре системы.

Информация о событии.

Ряд действий должен производиться службой при наступлении того или иного события.

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

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

Модель публикации и подписки снимает эти ограничения.

В ней сообщения от одного или нескольких отправителей может получать произ­вольное число потребителей информации. При этом отправитель носит название издателя, а потребитель обозначается как подписчик.

Обмен по принципу публикации­подписки включает понятие темы, на которую, демонстрируя интерес, может подписаться любое количество потребителей инфор­мации. Такое положение дел аналогично тому, как если бы кто­то подписался лишь на журналы по интересным для него темам. Каждая тема предоставляет информацию о конкретном состоянии или событии.

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

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

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

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

По одной теме может иметься несколько издателей; подписчик по одной теме может являться источником публикуемых сведений по другим.

Понятиеочередейсообщений 9

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

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

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

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

1. Передать инфраструктуре очередей сообщений информацию, необходимую для указания корректного места назначения или мест назначений данного сооб­щения.

2. Передать сообщение инфраструктуре очередей сообщений.

3. При успешном завершении шага 2 приложение способно определить, что сооб­щение успешно достигло места своего назначения.

Примечание. Механизмыгарантированнойдоставкиинфраструктурыочере-дейсообщениймыобсудимвразделе2.4«Надежностьслужбицелостностьданных».

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

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

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

10 Глава2

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

Удаленная служба может работать на аппаратной платформе, отличной от плат­формы локального приложения и имеющей существенные отличия в формате символьных и числовых данных.

С момента написания приложения маршрут доступа к удаленной службе может быть изменен.

В сети может иметься несколько экземпляров интересующей службы, и приложе­ние должно выбрать, к какому из экземпляров оно планирует подключиться.

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

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

Сбой связи с конкретной службой может оказать отрицательное влияние на допус­тимость тех операций, которые приложение уже выполнило.

Текущие потребности приложений могут меняться со временем, обычно в сторо­ну повышения.

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

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

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

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

Понятиеочередейсообщений 11

Процесс модификации приложения для выполнения на узле с новыми базовыми инфраструктурными компонентами именуется переносом, простота переноса прило­жения на другие компоненты инфраструктуры носит название переносимости.

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

2 .3 . Расширяемость и скорость работыПланируя, проектируя, разрабатывая и предоставляя службу в ИТ­системе компании, важно учитывать, отвечает ли служба предъявляемым требованиям и способна ли она развиваться так, чтобы соответствовать им в дальнейшем.

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

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

Нагрузка. Количество попыток запроса службы в данном временном интервале.

Пропускная способность. Количество запросов на обслуживание, которое система в целом может обработать в данном временном интервале.

Расширяемость (масштабируемость). Простота повышения пропускной способ­ности системы с целью обслуживания увеличившейся нагрузки и влияние этого повышения на скорость ее работы (производительность).

Все перечисленные параметры важно рассматривать вместе, а не каждый из них в отдельности.

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

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

Изначально предоставляемые службе ресурсы призваны гарантировать, что скорость ее работы и пропускная способность приемлемы при нагрузках ожидаемого объема. Оценивая исходные требования к ресурсам, необходимо учесть надежность и без­опасность служб, поскольку технологии повышения безопасности и надежности могут неблагоприятно сказаться на скорости их работы.

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

12 Глава2

тельного объема модификаций службы либо отрицательно повлиять на производи­тельность таковой.

Другой важный аспект – работа системы в целом в период, когда нагрузка на ту или иную службу превысит пропускную способность. Зачастую это недолговременное явление, возникающее при пиковых обращениях. Кроме того, оно может постепенно или внезапно возникать с ростом спроса на конкретную службу, указывая на то, что требуется расширить пропускную способность. Если этого не учесть, то отрицатель­ные последствия пренебрежения таким шагом могут образовать следующий возмож­ный «букет».

Система будет не в состоянии обработать дополнительные запросы конкретной службы.

Скорость обслуживания отдельных запросов службы упадет до неприемлемого значения.

Снизится скорость работы прочих, реализуемых данной системой служб.

Возникнет фатальный сбой, такой как достижение пределов аппаратных ресурсов. Это вызовет недоступность отдельных служб на протяжении периода времени. Часто такую проблему обозначают как простой, или выход из строя.

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

2 .4 . Надежность служб и целостность данныхДанные, передаваемые в инфраструктуре очередей сообщений, в общих чертах мож­но разделить на две категории.

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

Примером сказанного является запрос текущего состояния заказа; если запрос данных утерян либо на него не получен отклик, это не повлияет на текущее состоя­ние заказа, и запрос можно повторить еще раз.

Данные, критичные для ведения бизнеса. Данные, не хранящиеся в системе где­либо еще. При их утере в системе теряется важная информация или изменение состояния.

Примером этого является сообщение об оплате заказа; если сообщение с под­тверждением платежа будет утеряно, статус заказа может стать некорректным. Возможно, клиент внес деньги в его оплату либо ему отправлена расписка в их получении, но состояние заказа внутри системы не отражает ни того, ни другого.

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

Понятиеочередейсообщений 13

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

2 .4 .1 . Однократная доставкаПомимо защиты сообщений с критичной для бизнеса информацией от потери в инфра­структуре очередей важно, чтобы сообщения достигали заданного места своего на­значения, а доставка происходила исключительно однократно.

Если сообщение было отправлено по допустимому в данной системе адресу, инфра­структура очередей сообщений обязана гарантировать, что сообщение будет достав­лено получателю. Однако пункт назначения или промежуточные узлы могут быть недоступны на протяжении какого­то периода времени. В этом случае сообщения остаются в системе в состоянии ожидания, пока не смогут продолжить свое движение по назначению.

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

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

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

Понятие однократной доставки охватывает все эти соображения. Такую доставку гарантирует WebSphere MQ.

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

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

14 Глава2

или откат действий единицы работы в целом, дабы ни одно действие в ней не могло выполниться без выполнения остальных. Также возможность инициировать откат единицы работы в любой момент времени должно иметь само приложение.

2 .4 .3 . Обработка ошибокСбои в ИТ­системе компании могут происходить без каких­либо предупреждений и должны обрабатываться так, чтобы не приводить систему в противоречивое состоя­ние. К примерам подобных сбоев относятся:

периодические сбои системы связи;

плановые и внеплановые простои прочих системных служб;

сбои, вызванные ограниченностью ресурсов и аппаратными неисправностями;

сбои ввиду программных ошибок;

сбои из­за модификации инфраструктуры или настроек.

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

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

Примечание. Подробнееотказоустойчивостьиединыеточкиотказамыобсудимвразделе2.6«Повышеннаяготовность»

2 .4 .4 . Среда обеспечения контроля качестваОсобую роль при разработке и развертывании новой службы в ИТ­системе компании играет ее тестирование. Раннее обнаружение проблемы может серьезно сократить влияние ее возникновения в будущем и снизить объем ресурсов, необходимых для ее устранения.

Рекомендуемая методика создания, тестирования и внедрения приложений предпо­лагает наличие двух независимых сред.

Производственная среда. Среда, в которой функционирует реальная система ком­пании, где происходит предоставление реальных служб, используемых и доступ­ных сотрудникам, партнерам организации или тем и другим.

Контролирующая среда (среда обеспечения контроля качества). Среда для разра­ботки и тестирования продукта должна предельно соответствовать производ­ственной среде, включая аппаратуру, операционные системы, программные средства инфраструктуры, конфигурацию и все службы. Любые плановые моди­фикации производственной среды до осуществления в ней должны проводиться и проверяться в контролирующей среде. В ней же необходимо имитировать и на­грузки.

Понятиеочередейсообщений 15

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

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

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

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

2 .5 . ЗащитаНемаловажным в ИТ­системе компании является тщательное изучение проблем безо­пасности и защиты. Доступ к службам и информации в рамках такой системы должен быть под контролем, а целостность передаваемых по сетям общего пользования закрытых и чувствительных данных – должным образом обеспечена.

2 .5 .1 . Защита доступаНередко важно гарантировать, что службы в ИТ­системе компании доступны только авторизованным сторонам – людям и приложениям.

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

В целом защита доступа к службам включает решение двух следующих задач.

Опознавание сущности, предпринимающей попытки обращения к службам.

Запрет установленной или неустановленной сущности обращения к службам, в работе с коими ей должно быть отказано.

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

16 Глава2

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

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

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

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

2 .6 . Высокая готовность системыНа службы, реализуемые ИТ­системой компании, можно положиться в повседневной работе фирмы. Простои, при которых конкретная служба или их группа становится недоступной, могут отразиться на деятельности компании, в результате чего ею будут понесены убытки.

В широком смысле простои делятся на две категории.

Плановые простои. Периоды недоступности одной или нескольких служб при выполнении их планового обслуживания. Сюда относятся:

– профилактика программного обеспечения;

– изменение настроек инфраструктуры;

– резервное копирование или реорганизация данных.

Внеплановые простои. Периоды недоступности одной или нескольких служб, возникшие неожиданно. Они могут быть вызваны:

– программными или аппаратными сбоями;

– недостаточностью ресурсов;

– нарушением целостности информации.

Цель обеспечения высокой готовности служб – минимизация плановых и внеплано­вых простоев инфраструктуры. Этого можно добиться несколькими путями, включая следующие:

Повышение надежности системы.

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

Понятиеочередейсообщений 17

Снижение простоев, обусловленных обновлением компонентов.

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

Гарантия эффективного восстановления системы при возникновении сбоя.

Если система допускает эффективное, то есть автоматическое, восстановление после сбоя без потери целостности информации, последствия и продолжитель­ность такого внепланового простоя будут гораздо меньше.

Минимизация влияния на службы единичного сбоя.

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

– доступность служб;

– доступность сообщений.

2 .6 .1 . Доступность службЕсли в компоненте системы произойдет сбой, он повлияет на все зависимые от него компоненты. Те, в свою очередь, могут повлиять на другие, в конечном же итоге затро­нутыми могут оказаться одна или несколько служб системы.

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

Организуя в системе множество экземпляров службы, способных действовать неза­висимо, можно обеспечить доступность службы для новых запросов даже после отка­за нескольких экземпляров.

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

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

Если компонент системы дал сбой, узлы, в которых размещены очереди и службы, могут, как следствие, тоже утратить функциональность. Это может произойти мгно­венно, не оставляя инфраструктуре и приложениям времени на реакцию, как, напри­мер, в случае отказа аппаратуры. Пока узел продолжает быть недоступным, все сооб­щения в очередях в этом узле тоже продолжают быть недоступными. Такие сообще­ния называют «застрявшими» (stranded messages).

18 Глава2

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

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

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

2 .6 .3 . Восстановление после сбояОтдельные катастрофические повреждения могут затронуть все ресурсы какого­либо узла, а возможно, и группы связанных друг с другом и находящихся на единой физи­ческой площадке узлов. Возврат к работе служб после подобных сбоев или восста­новление данных на поврежденных узлах требует тщательного планирования и предварительной подготовки.

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

2 .7 . Мониторинг и учет операцийСведения о работе и использовании системы имеют важное практическое значение. Они могут стать показателем качества функционирования системы, индикатором производительности и пропускной способности при разных нагрузках, а также дать возможность отслеживать работу отдельных сущностей.

2 .7 .1 . Мониторинг производительностиМониторинг производительности в контексте инфраструктуры очередей сообще­ний включает замер количества и продолжительности тех действий, которые осу­ществляются при обращении служб к очередям сообщений или при движении сооб­щений сквозь очереди и промежуточные узлы. Результаты замеров могут служить для оценки производительности и пропускной способности служб, а также инфраструк­туры, которая их поддерживает.

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

Понятиеочередейсообщений 19

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

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

СредстваподдержкиочередейсообщенийвWebSphereMQ 21

3

Средства поддержки очередей сообщений в WebSphere MQ

Эта глава описывает формирование очередей сообщений в системе IBM WebSphere MQ, обзор соответствующих возможностей которой мы приведем для каждой проб­лемной области, описанной в главе 2 «Понятие очередей сообщений».

В этой же главе книги мы обсудим следующие вопросы:

Базовые понятия

Упрощение

Расширяемость и скорость работы

Надежность служб и целостность данных

Безопасность

Высокая готовность системы

Мониторинг и учет операций

22 Глава3

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 MQWebSphere MQ V6.0 содержит WebSphere MQ Explorer, являющийся графическим интер­фейсом (GUI) конфигурирования и контроля менеджеров очередей в инфраструк­туре WebSphere MQ с настольной рабочей станции. Также он позволяет администри­ровать менеджеры очередей на платформе z/OS.

Для целей администрирования на всех платформах без исключения в WebSphere MQ входит сценарный (scripting) MQSC­интерфейс. Для iSeries™ и z/OS в продукте име­ются панельные интерфейсы администрирования.

СредстваподдержкиочередейсообщенийвWebSphereMQ 23

В состав каждого менеджера WebSphere MQ входят объекты (objects). Они определя­ют настройки очередей своего менеджера, а также характер взаимодействия самого менеджера, приложений и других менеджеров в инфраструктуре WebSphere MQ.

Объекты могут использоваться для настройки специальных маршрутов, соединяю­щих отдельные менеджеры очередей в составе инфраструктуры. Также с их помощью менеджер можно подключить к кластеру менеджеров очередей (queue manager clus-ter), в котором каналы между последними по мере надобности создаются автомати­чески.

Кластеры менеджеров очередей снижают объем работы по администрированию системы, необходимой при построении или модификации инфраструктуры 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 позволяет организациям выбирать самые подходящие инфраструк­турные компоненты для размещения служб или доступа к службам в своих системах.

24 Глава3

Новые приложения могут взаимодействовать с набором существующих служб, не зная сути организации имеющихся компонентов инфраструктуры очередей, реализую­щих эти службы. Ранее разработанные и лишенные интерфейса к инфраструктуре очередей службы могут быть адаптированы к новым условиям путем создания прокси (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 гарантия однократной доставки обеспечивает прием каждого сообщения, при­

СредстваподдержкиочередейсообщенийвWebSphereMQ 25

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

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

3 .2 .3 . Обобщенные пункты назначения WebSphere MQПункты назначения в инфраструктуре обозначаются названиями очередей, откуда приложения извлекают сообщения на обработку. В пределах менеджера эти названия уникальны, однако разные менеджеры в инфраструктуре могут иметь очереди с иден­тичными именами.

Такое название служит для опознания конкретной службы или обобщенного опреде­ления, назначенного службе инфраструктурой.

3 .2 .4 . Особые пункты назначения WebSphere MQКонкретное приложение, хотя и необязательно, может иметь свой собственный уни­кальный пункт назначения в инфраструктуре, составленный из названия очереди, назначенной приложению, и менеджера, к которому то подключено.

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

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

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

3 .2 .5 . Предоставление услуг в инфраструктуре WebSphere MQПриложение, предоставляющее услугу, ждет поступления сообщений в очередь, наз­ванную в инфраструктуре именем самого приложения.

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

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

26 Глава3

3 .2 .6 . Очереди WebSphere MQ как интерфейс доступа к службамДля доступа к службе инфраструктуры очередей сообщений WebSphere MQ приложе­ние требует нижеперечисленной информации.

Данные о размещении службы. В WebSphere MQ это название очереди в модели межточечного обмена или темы в модели публикации­подписки.

Способ подключения к инфраструктуре. В WebSphere MQ это имя и параметры подключения к менеджеру очереди инфраструктуры. Менеджер может находиться на той же машине, что приложение, или располагаться на удаленной машине с подключением к сети.

Детали интерфейса конкретной службы. Указывают, реализован ли интерфейс по принципу «отправил – забыл», «запрос – ответ» или по модели публикации­подписки. Содержат структуру данных тех сообщений, которые передаются между приложениями, стремящимися получить доступ к службе и предоставляющи­ ми ее.

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

Другие вопросы, такие как способ маршрутизации сообщений до пункта их назначе­ния, решает инфраструктура WebSphere MQ, выполняющая свою работу прозрачно для приложения.

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

Подобный доступ к службам гибок и удобен в сопровождении. Собственную инфра­структуру и службы, а также внешний доступ к последним могут поддерживать отдель­ные департаменты фирм и компании в целом.

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

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

3 .2 .7 . Стандартизованные API-интерфейсыИспользование стандартизованного API для обращения к службам через инфраструк­туру очередей может сделать данный процесс еще более гибким. В этой книге поня­

СредстваподдержкиочередейсообщенийвWebSphereMQ 27

тие стандартизованного 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 межточечного обмена и приема­передачи сообщений по принципу публикации­подписки. Для обеспечения широко­

28 Глава3

го спектра иных возможностей, в которых также могут нуждаться прикладные про­дукты, служат прочие интерфейсы. Так, приложение может получить внешний запрос по интерфейсу, доступному через сеть Интернет и 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­описания служб, к которым они желают полу­чить доступ, в том числе уточняя порядок взаимодействия.

СредстваподдержкиочередейсообщенийвWebSphereMQ 29

Посредником в подобных взаимодействиях является функциональный слой, именуе­мый 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.

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

30 Глава3

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 не

СредстваподдержкиочередейсообщенийвWebSphereMQ 31

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

Такова простейшая форма инфраструктуры WebSphere MQ: единственный менеджер очередей сообщений реализует службу, необходимую подключенным к нему прило­жениям. Эта схема показана на правой части рис. 3.1.

...

Applicationsproviding

the serviceSingle queue

manager

Applicationsproviding

the serviceSingle queue

manager

Applicationsaccessingthe service

...

Рис . 3 .1 . ПримерыархитектурысоднимменеджеромочередейWebSphereMQ

3 .3 .3 . Центрально-лучевая архитектура WebSphere MQПодключение приложения к менеджеру очередей WebSphere MQ как клиента имеет ограничения. Приложение и менеджер разделяет сетевое соединение, которое влияет на производительность их работы, в первую очередь на больших расстояниях. Также для работоспособности приложения тому требуется доступное подключение по сети. И хотя этим подключением к приложению управляет WebSphere MQ, взаимодействие по сети приложения и менеджера не является асинхронным.

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

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

32 Глава3

пользоваться преимуществами асинхронного взаимодействия со службой, распола­гающейся на другом менеджере.

Еще одним вариантом служит подключение обращающихся к работе служб приложе­ний к менеджеру в роли клиентов по быстрому сетевому соединению; скажем, так можно подключить все приложения, вызывающие службу в офисе филиала. Благода­ря наличию этого менеджера связь со службами на другом основном (hub) менеджере очередей становится асинхронной. При этом в реализации приложений как таковых может иметься внешний интерфейс к службе (к примеру, дающий возможность использовать ее через сеть Интернет и Web­браузер).

Те менеджеры очередей, которые предоставляют доступ к службам hub­менеджера, носят название spoke-менеджеров (spokes) центрально­лучевой («hub and spoke») архитектуры WebSphere MQ.

Приложения, занятые обеспечением работы служб, могут находиться на мейнфрейме или на сервере. Данная машина содержит hub-менеджер с очередью, из которой эти приложения извлекают сообщения на обработку. Здесь могут находиться и другие необходимые приложениям ресурсы, такие как база данных. В зависимости от при­нятого подхода к реализации приложений, предоставляющих службу, запросы из од­ной очереди может обрабатывать несколько экземпляров приложений такого рода.

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

Примером центрально­лучевой архитектуры служит рис. 3.2.

...

канал

Рис . 3 .2 . Примерцентрально-лучевойархитектурыWebSphereMQ

СредстваподдержкиочередейсообщенийвWebSphereMQ 33

3 .3 .4 . Кластеры менеджеров как возможность гибкого расширения

Более гибким подходом является объединение менеджеров очередей в кластер (queue manager cluster). Кластеры менеджеров дают возможность множеству экземпляров од-ной-единственной службы располагаться на нескольких менеджерах очередей.

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

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

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

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

Пример инфраструктуры WebSphere MQ на базе кластера менеджеров показан на рис. 3.3.

34 Глава3

Рис . 3 .3 . ПримерархитектурыWebSphereMQнабазекластераменеджеров

3 .4 . Надежность служб и целостность данныхНадежностью, доказанной более чем десятилетием разработки, менеджеры очередей WebSphere MQ, совместно входящие в состав одноименной инфраструктуры, зарабо­тали прекрасную репутацию. Они действительно могут работать в течение длитель­ного периода времени, наконец, к ним так же долго могут быть подключены прило­жения.

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

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

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

СредстваподдержкиочередейсообщенийвWebSphereMQ 35

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

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

Для отражения характера находящихся внутри данных сообщения, передаваемые в инфраструктуре WebSphere MQ, помечаются как относящиеся к одной из двух кате­горий.

Непостоянные (nonpersistent) сообщения. По соображениям производительности WebSphere MQ оптимизирует действия, выполняемые над непостоянными сооб­щениями. Непостоянные сообщения могут теряться, если сетевое соединение менеджеров очередей дает сбой, менеджер очереди подвергается перезапуску в профилактических целях или внезапно возникает ошибка, из­за которой менед­жер очереди нештатно прекращает свою работу.

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

Постоянные (persistent) сообщения. Как постоянные маркируются сообщения с жизненно важными для бизнеса данными. Однократная доставка постоянных сообщений гарантируется WebSphere MQ, который не отклоняет постоянные сообщения из­за сетевых сбоев, ошибок доставки или плановых перезапусков менеджера. Каждый менеджер очереди ведет отказоустойчивый журнал (log) всех действий, осуществляемых над постоянными сообщениями. Его ведение защища­ет от внезапных неплановых остановов, влекущих потерю постоянных сообще­ний. Незавершенные операции над постоянными сообщениями аннулируются, в том числе для поддержания целостности всех единиц работы, описанной в раз­деле 3.4.2.

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

36 Глава3

Постоянные сообщения могут позволить упростить конструкцию приложений за счет использования действующей в 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.

СредстваподдержкиочередейсообщенийвWebSphereMQ 37

При этом при каждой попытке приложения произвести какое бы то ни было дей­ствие над объектом 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 могут верифицировать целостность данных, пересылаемых по сетевому соединению. Тем самым реализуется защита от модифи­кации данных по злому умыслу и повреждения данных сетевой линией связи.

38 Глава3

3 .6 . Высокая готовность системыНадежность WebSphere MQ делает этот продукт отличным решением для создания инфраструктуры очередей сообщений для служб высокой готовности.

В процессе использования WebSphere MQ должен сочетаться с контролирующей средой, близко напоминающей производственную среду и применяемой для разра­ботки и проверки действия приложений, а также тестирования изменений в инфра­структуре и приложениях до внесения этих изменений в производственную среду.

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

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

Подробнее обо всех темах, затронутых в этой главе, читайте в руководстве Under-standing 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 вводит дополнительные возможности работы кластеров менед­жеров, способные обеспечить еще больший контроль над тем, как автоматически маршрутизируются запросы. Менеджеры очередей на серверах с большей пропуск­ной способностью могут маршрутизировать большее число сообщений, чем на сер­верах с более низкими показателями. Наконец, они могут выполнять функцию резер­

СредстваподдержкиочередейсообщенийвWebSphereMQ 39

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

3 .6 .2 . Группы с разделением очередей на WebSphere MQ для z/OSIBM WebSphere MQ для z/OS использует возможность объединения систем под z/OS в так называемый сисплекс (sysplex). Менеджеры очередей в одном сисплексе могут являться членами группы с разделением очередей (queue sharing group) и вместе полу­чать доступ к сообщениям в одних и тех же общих очередях.

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

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

3 .6 .3 . Кластеры высокой готовностиДругим решением проблемы доступности сообщений при сбое аппаратуры или в пе­риод плановой профилактики, к примеру обновления компонентов программных средств, являются кластеры высокой готовности.

Они предполагают наличие первичного и вторичного аппаратного сервера, каждый из которых содержит все программные компоненты, необходимые для предоставле­ния службы. По запросу, сформированному вручную, или при сбое любого из компо­нентов первичного сервера, реализующих службу, система аварийно переключается (failover) с первичного сервера на вторичный.

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

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

ОднимизмножествапримеровпродуктовсподдержкойкластероввысокойготовностиявляетсяIBMHACMP™,реализующийкластеризациюсерверовподуправлениемIBMAIX®5L™.

В контексте WebSphere MQ это означает, что установка WebSphere MQ производится на каждый из серверов, и оба сервера содержат менеджер очереди, настроенный на

40 Глава3

хранение данных в надежном хранилище информации, переключаемом между этими серверами.

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

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

Для обеспечения прозрачности перехода с точки зрения работы службы как таковой переключению подлежит и подтверждение подлинности сервера в сети.

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

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

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

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

Для создания резервной копии менеджера очередей на момент времени может быть создан полный «мгновенный снимок» всей его информации.

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

СредстваподдержкиочередейсообщенийвWebSphereMQ 41

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 может формировать отчеты о нагрузке на менеджер очереди для каждого подключенного к нему приложения. Эти отчеты строятся при отключении приложения или – для долго выполняемых приложений – через регулярные интервалы.

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

42 Глава3

3 .7 .3 Трассировка маршрута сообщенийWebSphere MQ V6.0 содержит функции установления маршрута, которым движутся сообщения в инфраструктуре WebSphere MQ и в связанных с указанным продуктом системах.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 43

4

Создание приложений для доступа к инфраструктуре WebSphere MQ

Эта глава описывает возможности создания приложений с использованием тех функ­ций, которые инфраструктура WebSphere MQ предоставляет в целях реализации служб и обращения к службам. В ней мы введем принятые в WebSphere MQ фунда­ментальные понятия межточечного обмена и обмена сообщениями по принципу публикации­подписки, а также опишем доступные интерфейсы прикладного про­граммирования (API).

Глава посвящена следующим вопросам:

Кроссплатформенная поддержка

Интерфейсы прикладного программирования (API)

Сообщения WebSphere MQ

Взаимодействие с инфраструктурой WebSphere MQ

Транзакции и единицы работы

Межточечный обмен сообщениями

Обмен по принципу публикации­подписки

44 Глава4

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. При разработке приложений

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 45

с использованием 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++, SC34­6592.

WebSphere MQ base Java API.

WebSphere MQ base Java API является API­интерфейсом к базовому диалекту языка Java, соответствующим объектной модели WebSphere MQ. При создании Java­при­ложений для доступа к WebSphere MQ программист может использовать преиму­щества переноса приложения между платформами, который обеспечивает язык Java. Функциональность платформы Java может упростить и другие аспекты напи­

46 Глава4

сания приложений. Подробнее о Java API читайте в руководстве WebSphere MQ Using Java, SC34­6591.

Примечание. АльтернативныйинтерфейсдляязыкаJavaописанвраз-деле4.2.3«СтандартизованныеAPI-интерфейсыдляWebSphereMQ».

Классы 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-интерфейсыдляWebSphereMQ».

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слоймеждунимиинфраструктуройWebSphereMQиспользуетнеобходимуюфункциональностьWebSphereMQ.

ДоступковсемуспектруфункцийинфраструктурыWebSphereMQможеттребо-ватьприменениясобственногоAPI-интерфейсаWebSphereMQ.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 47

Примерами стандартизованных 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 для данного приложения.

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

Приложения, которые обращаются к инфраструктуре 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 являются важ­ными темами, представляющими самостоятельный интерес.

48 Глава4

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=swg24­007092&loc=en_US&cs=utf-8&lang=en

Примечание. ВнастоящеевремяSupportPacIA94относитсяккатегории2(Category2),тоестьегоподдержкапоканаламобслуживанияпродукцииIBMнедоступна.ПодробностиприведенынаWeb-сайте.

Реализуя новое приложение на C, C++ или в окружении .NET и выполняя межто­чечный обмен либо обмен по принципу публикации­подписки, продумайте воз­можность взаимодействия с WebSphere MQ при помощи XMS.

4 .2 .4 . Индивидуальные адаптерыЕсли WebSphere MQ не имеет интерфейса для конкретного языка программирования или программного компонента инфраструктуры, который необходим приложению, для него может быть создан индивидуальный адаптер (custom adapter).

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

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 49

Индивидуальный адаптер – пример прокси­модуля, который задействует существую­щий интерфейс и расширяет его в целях работы с инфраструктурой очередей сооб­щений WebSphere MQ.

Примером подобного адаптера является реализованная в пакете SupportPac MA89 поддержка языка Perl для MQSeries®. Этот индивидуальный адаптер служит интерфей­сом между WebSphere MQ и языком Perl. Подробнее о SupportPac MA89 см. по адресу:

http://www.ibm.com/support/docview.wss?rs=171&uid=swg24­000208&loc=en_US&cs= utf-8&lang=en

Примечание. SupportPacMA89имеет4-юкатегориюсервиса(Category4).ЕгопоставкуосуществляетнеIBM,астороннийпроизводитель.ПодробностиприведенынаWeb-сайте.

4 .3 . Сообщения WebSphere MQСообщения, пересылаемые в инфраструктуре WebSphere MQ, могут содержать данные различных форматов, выбранных с учетом конкретных требований приложений, обращающихся к инфраструктуре.

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

4 .3 .1 . Дескриптор сообщенияКаждое сообщение в инфраструктуре WebSphere MQ имеет связанный с ним дескрип-тор (message descriptor).

Дескриптор содержит метаданные сообщения. Они описывают сообщение, но не являются частью данных, которые в нем находятся.

Ряд метаданных формируется приложением­отправителем сообщения, ряд – генери­руется и автоматически обновляется WebSphere MQ по мере движения сообщения по инфраструктуре очередей. Приложению­получателю сообщения доступны все его метаданные.

Примерами метаданных, которые мы обсудим в этой главе, являются:

уникальный, или индивидуальный, идентификатор сообщения;

тип сообщения, определяющий потребность в формировании ответа;

детали отправки ответа на данное сообщение;

срок жизни (expiry interval), определяющий, имеет ли сообщение конечный период существования;

информация о том, как, когда, кем было создано сообщение;

информация о представлении данных в теле данного сообщения.

50 Глава4

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 для опи­сания структуры передаваемой информации.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 51

4 .3 .4 . Сборка сообщений из их фрагментовОсобую гибкость в работу инфраструктуры вносит сборка сообщения из фрагментов, способ осуществления которой понятен заложенным в менеджерах очередей алго­ритмам преобразования информации. Каждый фрагмент сообщения имеет свою длину; сумма длин всех фрагментов соответствует всей длине сообщения.

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

Вкратце типы фрагментов сведены в приведенный далее перечень:

Фрагмент, который WebSphere MQ может рассматривать как содержащий единый тип данных. Данные, которые WebSphere MQ может воспринимать в качестве однотипных, – это:

– двоичные данные, которые WebSphere MQ не конвертирует;

– символьные данные, конвертацию которых WebSphere MQ может произвести.

Структура WebSphere MQ: структуры такого рода могут содержать данные многих различных типов, а ряд структур – и дополнительные метаданные сообщения. Структуры могут автоматически добавляться и удаляться из сообщений самим WebSphere MQ при прохождении инфраструктуры.

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

Примеры структур данного рода следующие.

– Заголовок транспортной очереди и очереди недоставленных сообщений: Авто­матически добавляются к сообщению менеджером очередей в ситуациях, опи­санных далее в этой книге. Обычно приложения не добавляют к сообщениям сами эти структуры, однако знать о возможности добавления к сообщению данных структур полезно при просмотре сообщений в очереди менеджера очередей.

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

Примечание. Сообщения,помещенныевинфраструктуруWebSphereMQстандартизованнымиAPI,такимикакJMS(JavaMessageService),нередкосодержатавтоматическипристыкованныекнимзаголовкиправилиформатиро-вания,вкоторыхсодержатсяметаданные,необходимыестандартизованныминтерфейсам.

52 Глава4

Команда WebSphere MQ. Отдельные сообщения адресуются компонентам Web­Sphere MQ, заставляя их выполнять определенные действия. Примерами упомяну­тых компонентов являются брокер публикации­подписки, а также командный сервер WebSphere MQ, обсуждаемые далее в этой книге. Структуру сообщений, которые содержат эти команды, WebSphere MQ определяет самостоятельно.

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

4 .4 . Взаимодействие с инфраструктурой WebSphere MQ

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

При этом они могут соединиться с менеджером, работающим на той машине, где выполняются сами. Это самый эффективный способ подключения к менеджеру, кото­рый именуется связыванием (binding).

Кроме того, используя клиентское (client) подключение по сети, приложения могут соединяться с менеджером на удаленной машине. Работа соединения как клиента накладывает свой отпечаток на его скорость, а удаленный менеджер очередей должен быть доступен для успешного подключения. Вместе с тем установку сервера на маши­ну, где расположен клиент, производить не потребуется.

4 .4 .1 . Клиентские продукты WebSphere MQНа машине, где установлены приложения, которые подключаются к инфраструктуре WebSphere MQ как клиенты менеджера очередей, требуется лишь небольшой объем программных средств WebSphere MQ.

Примечание. НекоторыеклиентскиепродуктыWebSphereMQдоступныкакпакетыподдержкиSupportPac,некоторыепоставляютсянадистрибутивномносителедляустановкиWebSphereMQ.

ЛицензиинасерверWebSphereMQдлямашин,имеющихисключительноклиент-скуюинсталляциюWebSphereMQ,насегодняшнийденьнетребуются.

4 .4 .2 . Основные возможности приложения WebSphere MQПриведенный далее перечень вкратце описывает основные возможности, которые предоставляются приложениям, подключенным к инфраструктуре WebSphere MQ через отдельный менеджер.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 53

Приложение может извлекать сообщения из очередей под управлением данного менеджера для обработки и реализации службы с интерфейсом к очереди, выпол­ненным по принципу «запрос – ответ» или «отправил – забыл».

С учетом характеристик очереди менеджера очередей, к которому произошло подключение, приложение может получить в инфраструктуре уникальный объект. Он предъявляется другим приложениям, давая им возможность посылать сообще­ния данному. При межточечном обмене в WebSphere MQ он называется очередью ответа (reply-to queue); другое его название – очередь отклика (response queue). В случае, если это необходимо, уникальный объект может существовать и после завершения приложения. Несколько приложений могут коллективно использо­вать одну очередь, извлекая лишь предназначенные для них сообщения и пользу­ясь для этого корреляционным идентификатором (correlation identifier). Возмож­ности получения уникального объекта мы обсудим в разделе 4.6.14 «Реализация очереди ответов».

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

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

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

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

И в первом, и во втором случае менеджер очередей, к которому подключено при­ложение, должен знать, как направить сообщение в очередь назначения. Решение на этот счет в процессе разрешения названия очереди (queue name resolution) принимает каждый менеджер на пути к месту назначения сообщения, а значит, он должен знать лишь следующий шаг маршрута доставки по назначению.

Информацию о маршрутах к очередям и менеджерам, которую хранят все менед­жеры очередей сообщений, можно сконфигурировать при помощи определенных на данном менеджере объектов очередей (queue objects) WebSphere MQ. Кластеры менеджеров дают возможность автоматически узнавать об альтернативных марш­рутах к очередям и менеджерам в составе инфраструктуры, а также производить балансировку нагрузки между несколькими очередями кластера с одним именем.

Дальнейшее обсуждение разрешения названий очередей и процедуры техничес­кой настройки менеджеров, управляющих разрешением, см. в разделе 6.2.1 «Раз­решение названия очереди».

Приложение может получить доступ к функциям публикации и подписки, предо­ставляемым инфраструктурой для публикации сообщений и подписки на опреде­ленные темы.

54 Глава4

При непосредственном использовании публикации и подписки в WebSphere MQ реализованный в инфраструктуре брокер публикации­подписки принимает команды по интерфейсу «запрос – ответ». Интерфейс позволяет зарегистрировать приложение в роли подписчика по некоторой теме, публиковать по ней сообще­ния или посылать брокеру команды прочего содержания.

Аналогично приему ответов в интерфейсе «запрос – ответ» сообщения по подписке ставятся в очередь, управляемую тем менеджером, к которому подклю­чено приложение.

Подробнее о публикации и подписке в WebSphere MQ и расширении возмож­ностей публикации и подписки в инфраструктуре WebSphere MQ см. раздел 4.7 «Обмен по принципу публикации­подписки».

Примечание. ИспользуястандартизованныеAPIтак,какописановразделе4.2.3«СтандартизованныеAPI-интерфейсыдляWebSphereMQ»,интерфейспубликации-подпискиWebSphereMQможнозначительноупростить.

4 .5 . Транзакции и единицы работыЕдиницы работы дают возможность группировать множество действий, выполняе­мых приложением, с тем чтобы каждая отдельная операция в составе единицы рабо­ты успешно фиксировалась в системе только в том случае, если все действия в данной единице работы успешно завершены.

Базовым элементом, позволяющим регистрировать или отменять действия в рамках единицы работы как единую группу, служит транзакция. Нередко термины «транзак­ция» и «единица работы» используют как синонимы.

Транзакции WebSphere MQ позволяют фиксировать или аннулировать ряд действий над сообщениями в составе единицы работы. Над сообщениями в WebSphere MQ можно произвести две базовые операции.

Сообщение можно поставить в очередь. Это – первое действие приложения по отправке сообщения через инфраструктуру очередей, также каждый раз выполня­емое каналом при размещении сообщения в транспортной очереди или очереди пункта назначения сообщения.

Это действие называется постановкой сообщения в очередь или операцией put.

Сообщение можно извлечь из очереди. Этим занимается приложение или канал сообщений, переправляющий сообщение из транспортной очереди по каналу коммуникации.

Это действие называется извлечением (изъятием) сообщения из очереди или опе­рацией get.

4 .5 .1 . Локальные единицы работыПо умолчанию единица работы может содержать только put­ и get­операции. Web­Sphere MQ автоматически начинает единицу работы и также формирует транзакцию. Говорят, что единица работы локальна для WebSphere MQ.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 55

Транзакция, управляющая локальной единицей работы, координируется 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. Поэтому два приложения не могут извлечь из очереди одно и то же сообщение. Однако сообщения, изъятые из очереди за время единицы работы, реально не удаляются из очереди, пока данная единица работы не окажется зафиксирована. При аннулировании единицы работы все сообщения, изъятые за ее время из очереди, снова становятся доступными к изъятию для любых приложений.

56 Глава4

В результате, если то же самое приложение повторно попытается произвести извле­чение (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 и база данных.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 57

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поддерживаетработуWebSphereMQкакменеджератранзакцийтолькосопределеннымнаборомменеджеровресурсов,аработуWebSphereMQкакменеджераресурсов–толькосопределеннымнаборомменеджеровтранзакций.Подробнееобэтомчитайтепоадресу:

http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html

4 .5 .7 . Двухфазная фиксацияДействия всех участников глобальной единицы работы должны быть скоординиро­ваны для того, чтобы любой менеджер в любой момент времени мог сообщить о воз­никновении сбоя. Важнейший вид подобной координации известен как двухфазная фиксация (two-phase commit).

Двухфазная фиксация состоит из двух следующих шагов.

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

2. Фиксация. Если фаза подготовки к фиксации успешно завершена каждым из ме­неджеров ресурсов, то менеджер транзакций данной единицы работы информи­рует все менеджеры ресурсов о необходимости ее зафиксировать.

58 Глава4

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 в глобальные единицы работы.

Примечание. Данныйпродуктпоставляетсянаусловиях,отличныхотпринятыхдляклиентскойинсталляцииWebSphereMQ.Подробнееобэтомчитайтепоадресу:

http://www.ibm.com/software/integration/wmq/transclient.html

В этих условиях WebSphere MQ не может выступать в качестве менеджера транзакций глобальной единицы работы, поскольку координировать глобальные единицы рабо­ты в WebSphere MQ может лишь менеджер очередей сообщений. Однако WebSphere MQ может являться менеджером ресурсов глобальной единицы работы. При этом приложение может, например, участвовать в глобальных единицах работы, коорди­нируемых WebSphere Application Server.

4 .5 .10 . Отказоустойчивость и обработка ошибокВыполняя действия WebSphere MQ в рамках единицы работы (под управлением точки синхронизации) и фиксируя эти действия лишь в случае успешного завершения своих связанных операций, приложение может стать устойчивым к возникающим сбоям.

Примечание. Рядвыполняемыхприложениемопераций,скажемобновлениефайловвфайловойсистемеилиотправкаэлектронныхписемадминистратору,неможетбытьпомещенврамкиединицыработы.Поэтомуразработчикуприло-женийнеобходимоучитывать,чтопривнезапномзавершенииприложенияWebSphereMQнесможетаннулироватьэтидействия.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 59

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

Если приложению требуется поместить в очередь или извлечь из нее несколько со­общений и эти действия являются частью конкретных действий по обработке, то на­хождение этих независимых действий в рамках единицы работы означает, что каж­дое отдельное действие будет успешно совершено, только если вся единица работы будет зафиксирована успешно. Если в любой момент обработки приложение столк­нется с проблемой, оно может проинформировать WebSphere MQ, потребовав отме­нить текущую единицу работы.

Если при обработке сообщения приложение неожиданно дает сбой, а единицу работы этого приложения координирует WebSphere MQ, то, обнаружив сбой приложения, Web­Sphere MQ автоматически отменит единицу работы и вернет сообщение в очередь.

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

ПримеромтакогородапроцессаявляетсявиртуальнаямашинаязыкаJava(JVM)насервереприложенийJ2EE.Еслисервервыявитсбойввыполняемомприложе-нииизакроетего,притомчтоприложениеработалокакJava-потокнавиртуаль-ноймашине,WebSphereMQнеобнаружитзавершенияпотокадоокончанияработыJVMвцелом.Впрочем,серверыприложенийJ2EEимеютподдержкуменеджментатранзакцийимогутбытьвсостоянииурегулироватьподобнуюситуацию.WebSphereMQможнонастроитькакменеджерресурсовдляединицработыотдельныхсерверовприложенийJ2EE,включаяWebSphereApplicationServer,какбылосказановразделе4.5.5«Глобальныеединицыработы».

4 .6 . Межточечный обмен сообщениямиБазовые возможности межточечного обмена, включая предоставляемую WebSphere MQ гарантию однократной доставки постоянных сообщений, обеспечивают надеж­ную и производительную работу межточечного приема и отправления сообщений, пересылаемых между приложениями, имеющими доступ к инфраструктуре Web­Sphere MQ.

В этом разделе мы подробно опишем возможности межточечного обмена по дей­ствующим в инфраструктуре WebSphere MQ принципам «отправил – забыл» и «запрос – ответ». Здесь же на уровне реализации мы рассмотрим организацию служб и доступ к ним приложений.

4 .6 .1 . Извлечение сообщений из очередиПриложения извлекают сообщения из очередей под управлением менеджеров, к ко­торым они подключены.

60 Глава4

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

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

Также приложения могут извлекать (get) сообщения из очереди, стирая их из нее и делая их недоступными для других приложений. WebSphere MQ гарантирует, что никакие два приложения не могут успешно изъять из очереди одно конкретное сооб­щение.

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

Приложения могут уточнить, что готовы извлекать только те сообщения, которые имеют определенные признаки или отвечают параметрам соответствия (match options). Обычно как таким признаком пользуются корреляционным идентификато­ром, который может быть задействован для связи сообщения в общей очереди не­скольких приложений только с одним из них.

4 .6 .2 . Размещение служб на основе очередей сообщенийПриложение может предоставлять очередь как интерфейс к реализуемой службе и извлекать вновь поступающие в очередь сообщения для индивидуальной их обра­ботки.

Запросы к службе, размещенной на основе очереди, может посылать произвольное количество приложений, которые подключены к инфраструктуре очередей и не вла­деют данными о доступности службы при отправлении сообщений. Очередь буфери­зирует сообщения в порядке их постановки, в котором затем эти сообщения могут быть обработаны. Такой порядок работы именуют FIFO (first­in first­out – «первый вошел, первый вышел»).

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

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

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

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 61

множества экземпляров конкретной службы на базе очередей с одним и тем же названием под управлением разных менеджеров, а значит, на различных машинах.

Менеджеры очередей, к которым подключены приложения, стремящиеся получить доступ к конкретной службе, выполняют балансировку нагрузки, распределяя запро­сы по всем доступным экземплярам интересующей службы.

Завершив обслуживать сообщение, служба может формировать ответы на запрос обратившегося приложения или строить отчет, зависящий от результатов обслужива­ния. Речь об этом пойдет в разделе 4.6.15 «Обработка сообщений службой».

4 .6 .3 . Счетчики и очереди возвратаСбои при обработке сообщений требуют согласованных контрмер. Одним из вари­антов дальнейших действий является перенос сообщения в другую очередь для спе­циального рассмотрения, возможно с добавлением к сообщению метаданных, отра­жающих характер ошибки.

WebSphere MQ позволяет очередям, откуда извлекаются сообщения, задавать очереди возврата (backout queue). Приложение может проверить правильность названия такой очереди и пользоваться ею как местом назначения сообщений, обработка которых вызвала сбой.

Ряд сбоев может не возникать повторно, и дополнительной попытки произвести обработку может оказаться достаточно. Если приложение получает сообщение в ходе единицы работы, которую в дальнейшем откатывает, или выдает ошибку при обра­ботке, WebSphere MQ увеличивает счетчик возвратов (backout count) в дескрипторе данного сообщения.

При извлечении сообщения приложение может проверить, чему равен счетчик его возвратов, а это позволит определить, должно ли сообщение быть обслужено или направлено в очередь возврата.

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

Примечание. WebSphereMQнепереноситсообщениявочередивозвратаавтоматически.

4 .6 .4 . Службы с управлением по событиямИспользуя WebSphere MQ, приложение­поставщик службы может ожидать появления в очереди сообщений сколь угодно долгое время, не создавая лишней нагрузки на элементы инфраструктуры.

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

62 Глава4

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

Для обеспечения автоматического запуска приложений при появлении в очереди до­ступных им сообщений WebSphere MQ реализует механизм "триггеринга" (triggering). Далее приложение может обработать все сообщения в очереди, после чего закрыться, или обработать все сообщения, доступные на данный момент, и непродолжительное время подождать новых.

Также WebSphere MQ поддерживает срабатывание триггеров при поступлении в оче­редь определенного количества либо при появлении каждого отдельного сообщения. Это позволяет производить пакетную обработку сообщений и обеспечивать работу простых приложений, созданных с целью обслуживать по сообщению при каждом из своих запусков.

4 .6 .5 . Обмен по принципу «отправил – забыл»Для того чтобы после отправки сообщения приложение могло продолжить свою работу, достаточно поместить сообщение в очередь, управляемую тем менеджером очередей, к которому подключено приложение. Это позволяет быстро начать даль­нейшее выполнение приложения после отправки им сообщения, что особенно спра­ведливо при пользовании соединением с менеджером очередей через связывание, а не посредством сетевого подключения приложения как клиента.

Для разрешения названия очереди служит хранящееся в составе менеджера очередей, к которому подключено приложение, представление инфраструктуры WebSphere MQ, позволяющее определить, возможна ли отправка данного сообщения. Если да, сообщение ставится в очередь. Если при этом выясняется, что очередь назначения имеет локальное размещение, сообщение доставляется напрямую. В противном слу­чае оно помещается в промежуточную транспортную очередь (transmission queue), откуда оно будет передано другому менеджеру очередей в составе инфраструктуры.

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

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

Такая асинхронная природа обмена имеет то преимущество, что позволяет прило­жениям продолжать действовать в соответствии с бизнес­логикой, пока WebSphere

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 63

MQ решает коммуникационные задачи доставки каждого сообщения в свою очередь назначения.

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

При отправке сообщения приложение может указать то, насколько «постоянным» оно является. Если эта информация не указана, менеджер очередей выставляет нуж­ное значение по умолчанию на базе настроек объектов­очередей, используемых при разрешении названия очереди WebSphere MQ.

Сообщение, которое, не требуя ответа, содержит запрос действия от приложения­поставщика службы, помечается в WebSphere MQ как дейтаграмма (datagram). При­ложения могут использовать службы, посылая дейтаграммы очередям, реализующим интерфейсы к подобным службам.

4 .6 .6 . Списки распространенияПриложение может отправить одно и то же сообщение по нескольким адресам, ис­пользуя единственную операцию WebSphere MQ, связанную со списком распростра­нения (distribution list). Если ряд перечисленных в списке распространения мест на­значения менеджер очередей может достичь посредством передачи сообщения по одному каналу по адресу одного менеджера промежуточной или целевой очереди, сообщение будет отправлено лишь один раз.

Примечание. ЭтавозможностьнедоступнавWebSphereMQдляz/OS.Подробностисм.вруководствеWebSphereMQApplicationProgrammingGuide,SC34-6595.

4 .6 .7 . Сегментация сообщенийМаксимальная длина отдельного сообщения в инфраструктуре WebSphere MQ состав­ляет 100 Мб. Однако по умолчанию очереди не принимают сообщений длиннее 4 Мб.

Сообщения длиной свыше 100 Мб или 4 Мб – при том что очередь, через которую сообщение проходит, двигаясь по маршруту к пункту своего назначения, не настрое­на на прием сообщений большей длины – могут дробиться на фрагменты меньшие по размеру.

Сегментация при отправке и повторная сборка при получении сообщений может осуществляться приложением самостоятельно, а может – автоматически менеджером очередей сообщений.

64 Глава4

Примечание. ЭтавозможностьнедоступнавWebSphereMQдляz/OS.Подробностисм.вруководствеWebSphereMQApplicationProgrammingGuide,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).

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 65

Сообщение извлекается из целевой очереди программными средствами приложе­ния.

Эти отчеты приходят по назначению, указанному приложением, отсылающим сообщение, для чего служит тот же механизм, что при обмене по принципу «запрос – ответ».

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.

66 Глава4

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

Для осуществления тайм­аута приложение может заявить о готовности ждать сооб­щений в очереди ответов в течение некоего периода ожидания (wait interval). По его истечении WebSphere MQ уведомляет приложение об отсутствии сообщений, доступ­ных для обработки в очереди ответов, и приложение продолжает свою работу.

В случае, если это необходимо, приложение может неоднократно возвращаться к ожиданию сообщений в очереди ответа, выполняя свою работу до и после каждой попытки. Также приложение может периодически проверять наличие поступающих в очередь сообщений, передав WebSphere MQ сведения о том, что совершенно не же­лает тратить время на ожидание при отсутствии сообщений, и вынуждая WebSphere MQ запрашивать (poll) появление ответа.

4 .6 .13 . Истечение срока существования сообщенийЕсли приложение работает по тайм­ауту, оно должно указать срок существования (expiry time) сообщения в дескрипторе отправляемого запроса. Описанное значение в десятых долях секунды устанавливает приложение­инициатор запроса, WebSphere MQ сокращает его для отражения времени, проведенного сообщением в инфраструк­туре. Сюда относится время, проведенное в очереди по адресу назначения до приема сообщения службой на обработку, и время во всех транзитных очередях. Когда же срок существования истекает, сообщение уже не смогут принимать приложения, и оно станет пригодным для удаления инфраструктурой.

Обычно в дескриптор сообщения­ответа служба копирует текущее время существо­вания запроса. Однако с учетом конкретной реализации время существования ответа может приниматься равным заранее установленному значению или не выставляться для сообщений­ответов вовсе.

Приложение может запросить отчет об истечении срока существования сообщения (expiry report), который показывает, когда устаревшее сообщение удалилось инфра­структурой.

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

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

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 67

4 .6 .14 . Реализация очереди ответовРеализуемая приложением, инициирующим запрос, очередь ответов находится под управлением менеджера очередей, с которым связано приложение­инициатор.

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

Использование единой очереди ответов для всех запросов, адресованных службе.

В дескрипторе каждого сообщения в WebSphere MQ содержится идентификатор (message identifier), который генерируется WebSphere MQ и может быть уникаль­ным в пределах инфраструктуры.

Также в дескрипторе сообщения есть поле корреляционного идентификатора, которым приложения могут пользоваться для связи своих запросов с ответами.

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

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

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

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

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

Использование временной динамической очереди.

С целью организации для приложения уникального объекта в пределах инфра­структуры WebSphere MQ дает возможность создать очередь динамически. Вре-менная динамическая очередь (temporary dynamic queue) существует ровно то время, пока к ней обращается конкретное приложение. WebSphere MQ автомати­чески удаляет временные динамические очереди из менеджера, как только прило­

68 Глава4

жение заявляет, что связанная с очередью обработка завершена, или приложение, выдавшее запрос, закрывается.

Этот подход приемлем только для результатов запросов данных, содержащихся в непостоянных (nonpersistent) сообщениях. Во временной динамической очере­ди не могут содержаться постоянные сообщения с критичной для бизнеса инфор­мацией, поскольку они автоматически удаляются из менеджера очередей Web­Sphere MQ при завершении приложения, даже если оно вызвано сбоем и в очереди есть сообщения.

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

Системные ресурсы для поддержания каждой временной динамически создавае­мой и удаляемой очереди довольно невелики.

Использование постоянной динамической очереди.

Постоянная динамическая очередь (permanent dynamic queue) организуется при тех же условиях, что и временная, и может использоваться аналогично. Однако WebSphere MQ не удаляет ее из менеджера автоматически, в том числе при закры­тии приложения, отправившего запрос. Вместо этого приложение обязано само­стоятельно удалить очередь из менеджера очередей после завершения обработки.

Этот подход наделен теми же преимуществами, что и работа с временными дина­мическими очередями, но годится и для использования тогда, когда в составе сообщения­ответа содержится критичная для бизнеса информация.

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

4 .6 .15 . Обработка сообщений службойДействия службы по согласованной обработке сообщений и генерации ответов и от­четов на дейтаграммы и сообщения­запросы вкратце иллюстрирует следующий спи­сок шагов.

1. Начать глобальную единицу работы, если таковые используются.

2. Извлечь сообщение из очереди. При этом может понадобиться учесть сегментацию сообщения или порядок в логической группе. Если потребность в этом имеется, уведомить WebSphere MQ о необходимости извлечь сообщение целиком или извле­кать сообщения в составе группы с учетом порядка следования. Дополнительно вы­яснить, нужно ли конвертировать данные, – если да, потребовать от менеджера оче­редей осуществления перевода. При пользовании единицей работы указать, что данное действие производилось под управлением точки синхронизации.

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

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 69

мые меры. К ним может относиться проверка указания очереди возврата и пере­нос сообщения в эту очередь.

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

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

6. По итогам обработки данного сообщения установить результат, определив, была ли обработка успешно завершена.

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

a. Получить данные для ответа.

b. Создать дескриптор ответа или отчета либо использовать дескриптор исход­ного сообщения.

c. Убедиться в том, что в дескрипторе должным образом установлены все поля, относящиеся к содержимому сообщения, включая его формат и способ пред­ставления данных. Задание их как значений по умолчанию вынуждает Web­Sphere MQ выбирать те значения, которые соответствуют локальному пред­ставлению.

d. Установить тип сообщения как ответ или отчет.

e. Из дескриптора исходного сообщения скопировать идентификатор сообще­ния в корреляционный идентификатор дескриптора ответа или отчета.

f. Очистить идентификатор сообщения в дескрипторе ответа или отчета, побу­див WebSphere MQ сформировать новый идентификатор сообщения для отве­та.

g. Использовать время существования, указанное в дескрипторе исходного сооб­щения, или установить его равным предопределенной величине.

h. При генерации сообщения­отчета выбрать соответствующий код обратной связи в его дескрипторе.

i. Убедиться, что признак постоянности, а также приоритет ответа или отчета те же, что и в исходном сообщении.

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

70 Глава4

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

8. Фиксировать единицу работы.

4 .7 . Обмен по принципу публикации-подпискиОбмен сообщениями по принципу публикации­подписки требует применения бро­кера публикации­подписки, который ведет учет подписки на конкретные темы и обеспечивает возможность публикации тематических сообщений.

4 .7 .1 . Брокер публикации-подписки WebSphere MQWebSphere MQ содержит встроенный брокер, для выполнения функций публикации и подписки, использующий базовые возможности WebSphere MQ.

Примечание. Брокерпубликации-подпискибылвстроенвWebSphereMQвпакетеFixPack8дляWebSphereMQVersion5.3ивходитвсоставWebSphereMQVersion6.0.РанееонпоставлялсявпакетеSupportPacMA0C.

Брокер публикации­подписки WebSphere MQ использует инфраструктуру очередей сообщений WebSphere MQ для приема и обработки команд, учета подписки, хране­ния текущей статусной информации, а также как механизм доставки при отправке публикаций подписчикам. Гарантию однократной доставки брокер наследует от сис­темы.

Примечание. Здесьмыдаемлишькраткоеописаниевозможностейброкерапубликации-подпискиWebSphereMQ.

ПодробнееопубликациииподпискевWebSphereMQчитайтевследующихруководствах:

WebSphereMQPublish/SubscribeUser’sGuide,SC34-6606

WebSphereBusinessIntegrationPub/SubSolutions,SG24-6088

MQSeriesPublish/SubscribeApplications,SG24-6282

Каждый менеджер очередей может управлять максимум одним брокером, имеющим то же название в инфраструктуре, что и менеджер очередей, на котором он располо­жен. Брокеры могут объединяться в сеть брокеров (broker network), давая возмож­ность приложениям, связанным с одним менеджером, получать публикации в адрес брокера под управлением другого менеджера.

СозданиеприложенийдлядоступакинфраструктуреWebSphereMQ 71

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). Эти строки есть в каждой из публикаций любого источника публикации.

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

72 Глава4

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

Регистрация не прекращается и в том случае, когда приложение­подписчик не вы­полняется. Это значит, что публикации будут накапливаться в очереди подписчика, пока тот является неактивным.

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 и максимально использующие возможности модели публикации­подписки.

Совет. Использованиестандартизованныхинтерфейсовдляобращениякслужбампубликации-подпискиможетобеспечитьгибкостьприпереходесбазовыхвозможностейобменасообщениямипубликациииподпискиWebSphereMQнарешениенабазеWebSphereBusinessIntegrationMessageBrokerилиWebSphereBusinessIntegrationEventBrokerбездорогостоящеймодификацииприложений.

Менеджерыочередей:общеепредставлениеинастройка 73

5

Менеджеры очередей: общее представление и настройка

В этой главе мы обсудим предназначенные для создания и настройки менеджеров очередей сообщений WebSphere MQ интерфейсы администрирования, а также вкрат­це опишем работу менеджеров и реализуемые ими функции обеспечения целостно­сти передаваемых данных.

Глава посвящена обсуждению следующих вопросов:

Информация об установке

Интерфейсы администрирования WebSphere MQ

Менеджеры очередей сообщений

74 Глава5

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,поставляемогоспоследнимиобновлениямиWebSphereMQ.

5 .1 .2 . Спецификация окруженияПодробные сведения о поддерживаемых версиях операционных систем, компилято­ров и иных компонентов программных средств, взаимодействующих с WebSphere MQ, включая необходимые обновления, доступны в спецификации окружения (SOE – statement of environment) соответствующей платформы, на которой работает WebSphere MQ.

Спецификации окружения доступны на Web­странице по адресу:

http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html

Менеджерыочередей:общеепредставлениеинастройка 75

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 г. – Примеч. пер.

76 Глава5

Рис . 5 .1 . СтруктураокнаWebSphereMQExplorer

Структура окна WebSphere MQ Explorer представлена двумя базовыми панелями.

Панель навигации (навигатор). Содержит древовидное представление ресурсов WebSphere MQ, которые допускают администрирование с использованием Web­Sphere MQ Explorer. Ресурсы, показанные в этой панели, разделены на подчинен­ные корневому узлу IBM WebSphere MQ папки. Чтобы развернуть элемент дерева и увидеть все его содержимое, нажмите расположенный рядом знак «+», чтобы свернуть ранее развернутый элемент – знак «–». Для вывода на экран страницы содержимого элемента выделите его в дереве навигации.

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

Примечание.  ДляполучениясводнойсправочнойинформацииотекущихсведенияхвпанелисодержимогоWebSphereMQExplorerнажмитеклавишуF1.ДляпереходавполнофункциональнуюсправочнуюсистемувыберитеHelp → Help Contents.

В целях администрирования менеджеров очередей сообщений, установленных на данной машине и удаленно подключенных к WebSphere MQ Explorer, используется папка Queue Managers. Каждому менеджеру, с которым существует соединение, в пап­

Менеджерыочередей:общеепредставлениеинастройка 77

ке Queue Managers соответствует элемент списка, также содержащий ряд папок, выби­раемых для доступа к объектам менеджера очередей и настройки последних.

Часть папок менеджера очередей сообщений содержит папка Advanced. Вы можете отказаться от ее применения и выводить входящие в нее папки непосредственно в структуре Queue Managers. Для этого щелкните по папке Advanced и следуйте указа­ниям на панели содержимого инструмента.

Щелчок по подчиненной папке менеджера очередей сообщений открывает на пане­ли содержимого таблицу объектов этого типа, описанных в контексте данного менед­жера. Столбцы таблицы отображают атрибуты всех представленных в ней объектов, для чего служит собственный вид значка для каждого из упомянутых типов. Если атрибут не соответствует конкретному элементу таблицы, ячейка помечается серым. Системные объекты могут быть скрыты, однако показаны на рис. 5.2.

Рис . 5 .2 . WebSphereMQExplorer .Показаносодержимоеочередейменеджераирядсистемныхобъектов

Представленный на рис. 5.2 выпадающий список Filter может использоваться для вы­вода только объектов, соответствующих заданным в таблице критериям, скажем только очередей, в которых находится более 10 сообщений. Для настройки помимо стандартных фильтров для отбора объектов нестандартной фильтрации, а также для добавления таких фильтров к перечню постоянно доступных служит вызываемое из выпадающего списка окно Manage Filters.

Этот же список Filter (см. рис. 5.2) может применяться для изменения порядка следо­вания показанных в таблице атрибутов столбцов или для добавления (удаления) столбцов, отображающих конкретные атрибуты. Стандартная схема размещения

78 Глава5

столбцов дана в системе по умолчанию. Чтобы настроить собственную схему столб­цов и поместить ее в список постоянно доступных, используйте вызываемое из спис­ка 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).

Менеджерыочередей:общеепредставлениеинастройка 79

Процесс обновления (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 «Подключение к менеджеру очередей в режиме клиента».

80 Глава5

Примечание. WebSphereMQExplorerспособенподключатьсякудаленнымменеджерамочередейсообщенийпоклиентскимсоединениям,защищеннымпоSSL-протоколу(SecureSocketsLayer).ДляэтогоонпользуетсяфункциямиSSL-подключенийWebSphereMQJavaAPI.Подробностиработыподобныхсоединенийвыходятзарамкикниги.

Настройки WebSphere MQ Explorer

Для конфигурирования настроек WebSphere MQ Explorer выберите пункт меню Window → Preferences. На экране появится окно Preferences, содержащее несколько разделов настроек среды Eclipse, в которой работает WebSphere MQ Explorer.

Чтобы изменить свойства WebSphere MQ, выберите из списка в левой части окна категорию WebSphere MQ Explorer, как показано на рис. 5.4.

Рис . 5 .4 . ОкноWebSphereMQExplorerPreferences

WebSphere MQ Explorer и проект Eclipse

WebSphere MQ Explorer создан в виде набора подключаемых модулей (plug-ins) плат­формы Eclipse, являющейся частью проекта с тем же названием. Платформа Eclipse служит универсальной инструментальной платформой, реализующей базовые воз­можности для создания интегрированных сред разработки (IDE), интерфейсов адми­нистрирования и других приложений.

Менеджерыочередей:общеепредставлениеинастройка 81

Каждое из перечисленных приложений может существовать в рамках общей среды (workbench) Eclipse, которая обеспечивает их единое представление. Впрочем, вид каждого приложения может меняться при помощи перспективы (perspective).

В целях удобства администрирования WebSphere MQ в состав WebSphere MQ Explorer включена перспектива WebSphere MQ Explorer, меняющая представление среды при запуске WebSphere MQ Explorer или ее ручном выборе.

Каждое приложение платформы Eclipse организовано как совокупность подключае­мых модулей, построенных на базе функциональности модулей, имеющихся для этой платформы. Сами образующие приложение модули могут предоставлять набор функций для приложений, построенных как модули, подключаемые к данному при­ложению. Любая область или элемент приложения, возможности которых может расширять другое приложение – подключаемый модуль, называется точкой расши-рения приложения (extension point).

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

Примечание. ПоумолчаниюWebSphereMQExplorerзапускаетсяавтономно,чтонедаетвозможностиобращатьсяксредеEclipseвцелом.ДляполученияполногодоступактаковойвыберитеWindow → Preferences.Затемотметьтеопциюin an Eclipse Workbench.ДлявступлениянастройкивсилуWebSphereMQExplorerнужнозапуститьзаново.

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=swg24­010096

5 .2 .3 . Управляющие команды WebSphere MQWebSphere MQ для платформ UNIX и Windows содержит набор команд для выполне­ния операций над совокупностью менеджеров очередей сообщений и непосредствен­но WebSphere MQ. Команды выполняются в интерфейсе командной строки конкрет­ной операционной системы. Если нет указания на иное, путь к этим командам вклю­чается в путь поиска команд операционной системы при установке WebSphere MQ.

5 .2 .4 . Команды языка управления WebSphere MQ для iSeriesКоманды языка управления (CL – control language) IBM OS/400® в составе WebSphere MQ для iSeries служат для выполнения операций над совокупностью менеджеров оче­

82 Глава5

редей и непосредственно WebSphere MQ. Для обращения к главному интерфейсу ко­манд языка управления в составе WebSphere MQ используйте CL­команду WRKMQM.

5 .2 .5 . Команды WebSphere MQ для z/OSWebSphere 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 название_менеджера

� Стандартным вводом текстовых диалоговых интерфейсов служит клавиатура. – Примеч. пер.

Менеджерыочередей:общеепредставлениеинастройка 83

Если набор команд MQSC сохранен в файл, то содержимое файла можно передать команде runmqsc через стандартный ввод:

runmqsc название_менеджера < имя_файла

Команда runmqsc может использоваться для выполнения MQSC­команд управле­ния удаленным менеджером очередей сообщений. Об этом читайте в главе 6 «Ad­ministering remote WebSphere MQ objects» руководства WebSphere MQ System Admin-istration Guide, SC34­6584.

WebSphere MQ для iSeries.

Команды MQSC могут выполняться в интерактивном режиме, для чего служит CL­команда RUNMSQC.

Также они могут быть записаны как сценарий, который представляет собой фи­зический файл­источник. Для его выполнения предназначена CL­команда STRMQMMQSC.

Примечание. ДополнительноWebSphereMQдляiSeriesсодержитCL-команды,которыемогутслужитьдлявыполненияMQSC-командчерезпанельныйдиалоговыйинтерфейс.ДлядоступакэтимCL-командамWebSphereMQвоспользуйтесьCL-командойWRKMQM.

WebSphere MQ для z/OS.

Здесь команды MQSC служат для управления подсистемой конкретного менедже­ра очередей сообщений.

Примечание. WebSphereMQдляz/OSсодержитпанелиуправленияиоперации,которыемогутиспользоватьсядляинтерактивноговыполненияфункцийMQSC-команд.ДлядоступакнимслужатTimeSharingOption(TSO)иInteractiveSystemProductivityFacility(ISPF).

Синтаксис MQSC

Синтаксис MQSC очень прост. Общий формат команды имеет вид:

COMMAND OBJTYPE('Название_Объекта) ATTR1(ЗНАЧЕНИЕ) ATTR2('значение') ATTR3

где OBJTYPE – тип объекта, COMMAND – один из ряда допустимых для данного типа объек­тов командных ключевых слов, ATTR1, ATTR2, ATTR3 – названия допустимых для него атрибутов.

Отдельные комбинации командных ключевых слов и типов объектов, такие как ALTER QMGR, не требуют указания имен объектов. Отдельные атрибуты не требуют приведения их значений. Немало команд и типов имеют сокращенные варианты; к примеру, ALT может заменить ALTER.

Для некоторых командных ключевых слов требуется задание как типа, так и подтипа, например:

DEFINE CHANNEL('my.channel') CHLTYPE(RCVR)

84 Глава5

Каждая комбинация ключевого слова и типа принимает свой набор атрибутов. Ряд атрибутов является обязательным. Для указания пустого значения атрибута исполь­зуйте пробел в круглых скобках: 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

Менеджерыочередей:общеепредставлениеинастройка 85

В 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­атрибута.

Команды в формате программируемых команд обслуживает командный сервер (com-mand server) менеджера очередей сообщений. Он выполняет заданное каждой из PCF­команд действие и формирует сообщение­ответ с результатом ее работы.

Реализация интерфейса к командному серверу отвечает стандартной модели по прин­ципу «запрос – ответ», что означает, что сервер обрабатывает запросы из очереди и отсылает ответы, помещая их в очереди ответа, указанные приложениями­инициа­

86 Глава5

торами запросов. Очередь, из которой командный сервер извлекает запросы на обра­ботку, называется 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=swg24­000668&loc=en_US&cs=utf-8&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. Каждое приложение, получающее доступ к инфраструктуре, для обра­щения к ней должно быть подключено к менеджеру. Приложения могут получать сообщения из очередей под управлением только тех менеджеров, к которым они подключены.

Примечание. БлагодарягруппамсразделениемочередейWebSphereMQдляz/OSдопускает,чтобыоднойобщейочередьюуправлялцелыйрядменедже-ров.Подробнееобэтомсм.вразделе5.3.3«ГруппысразделениемочередейвWebSphereMQдляz/OS».

Менеджерыочередей:общеепредставлениеинастройка 87

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

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

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

5 .3 .1 . Наименование менеджеров очередейВсе менеджеры имеют свое название. Оно должно быть уникальным в инфраструкту­ре, что позволяет каждой очереди в ее пределах быть уникальным местом назначения сообщений. Название менеджера используется при установлении соединения и ука­зании местоположения очереди в составе инфраструктуры.

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

Немаловажен и выбор подходящего названия менеджера, которое может отражать характер его использования, название и местоположение машины.

При назначении имен менеджерам очередей сообщений советуем не забывать о росте инфраструктуры, в том числе появлении дополнительных менеджеров на тех же самых машинах, или слиянии нескольких инфраструктур WebSphere MQ в буду­щем.

После того как менеджер очередей создан, переименовать его невозможно. Для сме­ны имени менеджера он должен быть удален и создан повторно. Это касается и всех его элементов конфигурации.

В WebSphere MQ для z/OS название менеджера может быть не длиннее четырех сим­волов и содержать только буквы алфавита в верхнем регистре, цифры и символы из набора $ # @.

На остальных платформах название менеджера очередей сообщений может дости­гать в длину 48 символов и содержать строчные и прописные буквы латинского алфавита, цифры и следующий набор символов: . / _ %. Название менеджера чувстви-тельно к буквенному регистру, а значит, QMGR1 обозначает другой менеджер, нежели Qmgr1.

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

88 Глава5

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/OSWebSphere MQ для z/OS работает на аппаратной платформе мейнфреймов IBM

Eserver zSeries® под управлением операционной системы z/OS. В этой книге экземп­

Менеджерыочередей:общеепредставлениеинастройка 89

ляр 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.

90 Глава5

Примечание. WebSphereMQдляz/OSVersion6.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\название_менеджера

Входящее в указанные пути название_менеджера может частично не совпадать с ре­альным названием менеджера очередей сообщений. Подробнее о построении входя­

Менеджерыочередей:общеепредставлениеинастройка 91

щего в состав пути имени каталога из названия менеджера читайте в руководстве WebSphere MQ System Administration Guide, SC34­6584. Основное различие между ними состоит в том, что неалфавитные символы в названии менеджера заменяются в име­ни каталога: символ «.» меняется на «!», символ «/» на «&».

Базовая информация о настройках менеджера очередей сообщений хранится в реест­ре Windows. Она включает информацию о подходе к журнализации менеджера и на­стройках протокола коммуникации. Вносимые в эту информацию изменения не видны менеджерам, работающим в текущий момент, пока они не остановлены и не запущены снова.

Настройки менеджера в реестре Windows можно изменять с помощью WebSphere MQ Explorer. Для доступа к конфигурации менеджера щелкните правой кнопкой мыши по его значку в навигаторе и выберите пункт меню Properties.

Содержащуюся в реестре Windows информацию о настройке менеджера очередей сообщений также можно модифицировать командой WebSphere MQ amqmdain reg.

Примечание. ПрямоеизменениеинформациивреестресистемыWindowsтребуетисключительнойподготовки.ПоэтомувпроцессеконфигурированияWebSphereMQмынастоятельнорекомендуемнеприбегатькэтомуспособуредактирования.

Всю информацию о параметрах конфигурации 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.ПриустановкеWebSphereMQэтагруппасоздаетсяавтоматически.

При создании менеджера вы можете задавать параметры, определяющие начальные значения важных атрибутов конфигурации в реестре системы Windows. Часть на­строек конфигурации, касающихся процессов журнализации, после создания менед­жера не подлежит изменению. Подробнее об этом см. раздел 5.3.13 «Журнализация».

92 Глава5

Параметры, заданные при создании менеджера, имеют значения по умолчанию. Пос­ледние вместе с другой не относящейся к конкретному менеджеру информацией о настройках 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 Admin-istration Guide, SC34­6584. Основное различие между ними состоит в том, что неалфавитные символы в названии менеджера заменяются в имени каталога: сим­вол «.» меняется на «!», символ «/» на «&».

Базовая информация о настройках менеджера очередей сообщений хранится в файле, расположение в файловой системе которого приведено для каталога с данными менеджера очередей по умолчанию: /var/mqm/qmgrs/название_менеджера/qm.ini.

В нем содержится информация об организации журнализации менеджера и на­стройках протоколов коммуникации. Вносимые в эту информацию изменения не

Менеджерыочередей:общеепредставлениеинастройка 93

видны менеджерам, работающим в текущий момент, пока они не остановлены и не запущены снова.

На всех 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.ПриустановкеWebSphereMQэтагруппасоздаетсяавтоматически.

При создании менеджера вы можете задавать параметры, определяющие начальные значения важных атрибутов конфигурации в файле 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должнабытьпредваренаобязательнымостановомвсехменеджеровочередейсообщенийиподключенныхкнимприложений,которыеработаютнамашине.

94 Глава5

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. Подробнее об этом читайте в руководстве Web-Sphere MQ для iSeries V6.0 System Administration Guide, SC34­6586.

Менеджерыочередей:общеепредставлениеинастройка 95

Примечание. Длясозданияменеджерапользователь,которыйрешаетэтузадачу,долженявлятьсячленомгруппыQMQMADM.ПриустановкеWebSphereMQэтагруппасоздаетсяавтоматически.

Параметрами этой команды определяются начальные значения хранящихся в файле 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 Program-ming Guide, SC34­6595.

96 Глава5

5 .3 .6 . Объект-менеджер очередейИнформацию о настройке менеджера очередей сообщений, которую можно менять во время его работы, содержит соответствующий объект. Администрируют объект­менеджер очередей так же, как и другие объекты менеджера очередей сообщений.

При пользовании WebSphere MQ Explorer атрибуты объекта­менеджера очередей находятся в одном окне Properties с атрибутами конфигурации менеджера очередей.

5 .3 .7 . Запуск и останов менеджера очередейПравила запуска и останова менеджера очередей сообщений специфичны для всех платформ WebSphere MQ. В этом разделе мы опишем шаги, необходимые для этого на каждой платформе.

Примечание.СпоявлениемWebSphereMQV6.0вназванияиструктурупроцессов,реализующихменеджер,внесенынемалыеизменения.Этоотноситсяковсемплатформамсистемы,кромеWebSphereMQдляz/OS.Подробностисделанныхизмененийвыходятзарамкикниги.Однакоихпоявлениеможетповлиятьнаранеесозданныесценариизавершенияилиочисткименеджераочередейсообщений,атакжеконтроляактивностименеджераочередейнамаши-не.Подробнееопроцессах,являющихсячастьюменеджераочередейсообщенийWebSphereMQV6.0,читайтевследующихруководствах.

WindowsиUNIX:

WebSphereMQSystemAdministrationGuide,SC34-6584,–приложениеD«Stoppingandremovingqueuemanagersmanually»

iSeries:

WebSphereMQдляiSeriesV6.0SystemAdministrationGuide,SC34-6586,раздел«Workmanagement»

WebSphere MQ для Windows, UNIX, iSeries

Для запуска и прекращения работы менеджеров очередей сообщений пользователь, который решает эти задачи, должен являться членом группы с именем mqm. При уста­новке WebSphere MQ эта группа создается автоматически.

Чтобы запустить менеджер, используйте один из следующих приемов.

Запуск при помощи WebSphere MQ Explorer.

Щелкните правой кнопкой мыши по значку менеджера очередей в навигаторе и выберите пункт Start.

Примечание. Чтобынастроитьменеджерочередейсообщенийнаавтозапускодновременносмашиной,используйтеWebSphereMQExplorerдляWindows.Внемщелкнитеправойкнопкоймышипозначкуменеджераочередейвнавига-тореивыберитепунктProperties.ПослечегоизменитезначениеполяStartupсManualнаAutomatic.

Менеджерыочередей:общеепредставлениеинастройка 97

Запуск по команде WebSphere MQ strmqm:

Команда strmqm доступна в WebSphere MQ на платформах UNIX и Windows и описана в части 6 «WebSphere MQ control commands» руководства WebSphere MQ System Administration Guide, SC34­6584.

Примечание. ПрипользованииуправляющейкомандойWebSphereMQstrmqmнабазеплатформы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).

Работа менеджера сразу же прекращается. Используйте этот метод только в том случае, если ни первый, ни второй метод не принесли результатов. Принудитель­ный останов может иметь непредсказуемые последствия для подключенных к менеджеру очередей приложений.

98 Глава5

Если ни один из трех методов не позволил остановить менеджер, обратитесь к доку­ментации.

К разделу «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» руководства Web-Sphere 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).

Этот метод завершения менеджера принят по умолчанию. До своего останова менеджер ожидает штатного отключения всех ранее подключившихся приложе­ний. Приложения могут продолжать использовать менеджер, пока не отключатся

Менеджерыочередей:общеепредставлениеинастройка 99

от него. В процессе его использования они могут потребовать уведомить их о том, что менеджер начинает свой останов, что даст возможность определить начало завершения работы и разорвать подключение. Во избежание автоматического перезапуска менеджера регистрация его в 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­адресом или именем хоста имеется менеджер очередей сообщений, который прослушивает именно этот порт.

100 Глава5

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 требует меньше ресурсов, чем при работе внутри собственного процесса. В зависимости от схемы самой системы и наблюдаемых в ней нагрузок менеджер очередей сообщений может иметь тысячи активных одновременных подключений.

Примечание. ДовыпускаWebSphereMQV5.3формированиеканальногопуладляплатформUNIXотсутствовало.Вместонегоиспользовалсяпроцесс-слушательоперационнойсистемыinetd.WebSphereMQVersion5.3иWebSphereMQVersion6.0по-прежнемуподдерживаютиспользованиевходящеговОСслушателяinetd.ОднакооннедаетвозможностииспользоватьпреимуществапредоставляемыхWebSphereMQфункцийформированияканальногопула,посколькукаждыйиз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.

Слушатель можно настроить на автозапуск одновременно с менеджером. По этой причине рекомендуем вам отказаться от запуска слушателей вручную, сконфигури­ровав каждый менеджер так, чтобы заданный для него слушатель автоматически запускался с ним вместе.

Менеджерыочередей:общеепредставлениеинастройка 101

Примечание. ДовыпускаWebSphereMQVersion6.0слушательWebSphereMQнебылобъектомменеджераочередейсообщений.ДлясправкивWebSphereMQV5.3доступныследующиеприемызапускаслушателейсетевыхподключений.

ВWebSphereMQV5.3дляUNIX-платформслушательдолжензапускатьсяизкоманднойоболочкивручнуюприпомощиуправляющейкомандыWebSphereMQrunmqlsr.

ВWebSphereMQдляiSeriesV5.3длязапускаслушателяиспользуетсяCL-командаSTRMQMLSR.

ВWebSphereMQдляWindowsV5.3слушательможетавтоматическизапускатьсясовместносменеджеромприпомощиуправляющейкомандыWeb-SphereMQamqmdain crtlsrилимодуляоснасткиWebSphereMQServices.

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 автоматически. Однако ее требуется создать, а менеджер очередей сообщений – настроить на ее применение.

К причинам, по которым сообщение может быть не доставлено, относятся следующие: у менеджера нет очереди с приведенным названием; менеджер не знает о том, какому

102 Глава5

очередному менеджеру переслать сообщение на маршруте; в очереди уже находится предельно допустимое для нее количество сообщений.

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

Поэтойпричиненастройтеочерединедоставленныхсообщенийдлявсехбезисключенияменеджеровочередейсообщенийвинфраструктуре.

Очереди недоставленных сообщений и их настройка станут темой нашего обсужде­ния в разделе 7.4.11 «Ошибки доставки сообщений».

5 .3 .12 . Командный серверWebSphere MQ позволяет администрировать менеджеры очередей удаленно. Для упрощения такой работы на менеджере очередей сообщений может работать команд-ный сервер. Он выполняет посылаемые менеджеру команды. Речь о них шла в раз­ деле 5.2.7 «Форматы программируемых команд (PCF)».

5 .3 .13 . ЖурнализацияЖурнализация – одна из основных внутренних функций менеджера. Его журнал – это запись осуществленных менеджером очередей действий в порядке их выполнения.

Как журнальные записи (log records) регистрируются все действия над постоянными сообщениями, изменения конфигурации объектов менеджера и другие действия внутреннего характера.

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

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

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

В этом случае для повторного достижения корректного текущего состояния объектов при перезапуске менеджер пользуется журналом. Для этого он повторяет те действия,

Менеджерыочередей:общеепредставлениеинастройка 103

которые описаны записями в журнале и произошли с момента рассогласования журнала и данных самого менеджера.

Менеджер регулярно сверяет целостность данных журнала и своих собственных. Этот процесс осуществляется во время контрольных точек (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.

Суть же циклической и линейной журнализации такова.

Циклическая журнализация.

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

Линейная журнализация.

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

104 Глава5

Менеджер очередей сообщений уведомляет администратора о наиболее старых записях из журнала, требуемых для своего перезапуска. Также он сообщает адми­нистратору о самых старых записях, необходимых в целях восстановления носи­теля объектов этого менеджера.

Примечание. WebSphereMQV6.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.

Менеджерыочередей:общеепредставлениеинастройка 105

Примерами разновидностей информации, входящей в журнал ошибок менеджера очередей сообщений, являются:

информация о запуске и останове данного менеджера;

информация о входящих и исходящих подключениях данного менеджера, вклю­чая распределенные и кластерные каналы сообщений и соединения с клиентами. Сюда же относятся сведения о сбоях;

информация о попытках нарушения защиты, то есть о стремлении приложений получить доступ к объектам, обращаться к которым этим приложениям запрещено;

непредвиденные события, происходящие с менеджером.

Журналы ошибок менеджера содержатся в ряде пригодных для человеческого вос­приятия файлов, которые можно открыть в программе просмотра текстов. Для каж­дого менеджера объем такого набора файлов фиксирован и составляет по умолчанию 256 Кб. При заполнении одного файла менеджер переходит к другому, но не больше трех раз. Имена файлов журнала ошибок следующие:

AMQERR01.LOG

AMQERR02.LOG

AMQERR03.LOG

Примечание. РазмеркаждогоизжурналовошибокWebSphereMQV6.0можносконфигурировать,воспользовавшисьпараметромErrorLogSizeвнастройкахопределенногоменеджера.ТакжеWebSphereMQV6.0даетвозможностьограничитьчастотужурнализациисамыхраспространенныхсобытий,включаяустановлениесоединений.Подробнееобэтомсм.вразделе«ConfiguringWebSphereMQ»руководстваWebSphereMQSystemAdministrationGuide,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

106 Глава5

– системные журналы ошибок 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­разрядных приложений при помощи связывания.

Менеджерыочередей:общеепредставлениеинастройка 107

Приложениям, реализующим службы, это дает возможность использовать функции 64­битной адресации памяти операционной системой и оборудованием при под­ключении их к менеджерам очередей сообщений WebSphere MQ Version 6.0.

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

Примечание. Наодинаковомоборудовании64-разрядныеменеджерыWebSphereMQV6.0невсегдаболеепроизводительны,чем32-разрядныеменед-жерыWebSphereMQV5.3.ОднаковотдельныхслучаяхскоростьработыWebSphereMQV5.3ограничивает32-разряднаяадресация,чтотребуетвнима-тельноотнестиськповышениюпроизводительности.

Наплатформахс64-битнойадресациейпамятивнутренниеструктурыWebSphereMQиногдатребуютбольшересурсовпамяти.Врезультатемаксимальнаяемкостьнекоторых64-разрядныхменеджеровWebSphereMQV6.0можетбытьменьше,чем32-разрядныхменеджеровWebSphereMQV5.3наэтомжеоборудовании.Впрочем,наболеемощномсервересбо'льшимобъемомпамяти64-битныйменеджерочередейсообщенийWebSphereMQV6.0способенкболееощутимомумасштабированию.Причинойтомуявляетсято,чточастьюэтихресурсовпамяти32-разрядныеменеджерыпростоневсостояниивоспользоваться.

Подробнее о 64­разрядных платформах, которые в настоящее время поддерживает WebSphere MQ, см. на Web­странице по адресу:

http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html

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

6

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

Эта глава книги подробно описывает базовые возможности WebSphere MQ по орга­низации очередей сообщений. В ней будут приведены сведения о формируемых в составе менеджера объектах и их использовании. Мы опишем сообщения WebSphere MQ и то, как отправлять и принимать их, используя интерфейс очередей сообщений (MQI).

Отдельные детали организации MQI­интерфейса не связаны ни с одним из таких объектно­ориентированных или стандартизованных интерфейсов прикладного программирования (API), как Java Message Service (JMS), непосредственно. Однако эти API основаны на базовых возможностях MQI­интерфейса. Поэтому понимание объ­ектов, сообщений WebSphere MQ и MQI не становится бесполезным даже при обра­щении к инфраструктуре через стандартизованные API.

В этой главе мы обсудим следующие вопросы:

Интерфейс очередей сообщений

Очереди

Применение триггеров

110 Глава6

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

Поле «отчет» выступает признаком требования отчета, формируемого при обра­ботке сообщения менеджером очередей сообщений или приложением­получате­лем. Например, приложению может требоваться отчет менеджера­приемника об

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

успешной доставке сообщения или от приложения­получателя – о его успешном обслуживании. При формировании отчета приложением или менеджером в поле обратной связи помещается код с указанием причины для его построения.

Очередь ответов (ReplyToQ).

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

Менеджер очереди ответов (ReplyToQMgr).

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

Идентификатор сообщения (MsgId).

Может быть определен приложением или сгенерирован менеджером. Выдается приложению­отправителю менеджером очередей сообщений и может использо­ваться при последующей обработке.

Созданный менеджером очередей сообщений идентификатор является неповто­ряющимся во всей инфраструктуре WebSphere MQ. Однако это зависит от всех без исключения менеджеров в ее составе, имеющих уникальные в пределах первых 12 символов имена.

Корреляционный идентификатор (CorrelId).

Это поле может использоваться приложениями для связи двух сообщений или связи сообщения и приложения. Чаще всего служит для сопоставления ответа с запросом при обмене сообщениями по принципу «запрос – ответ». Приложение, которое обрабатывает запрос, копирует его идентификатор сообщения в поле корреляционного идентификатора формируемого ответа. Если же в одну очередь приходят ответы сразу на несколько сообщений­запросов или ответы на запросы нескольких приложений, то приложение сможет прочитать ответ, обратившись лишь к сообщениям с нужным корреляционным идентификатором.

Признак постоянного сообщения (Persistence).

Это поле определяет, относится ли сообщение к категории постоянных, речь о которых велась в разделе 3.4.1 «Постоянные и непостоянные сообщения». Буду­чи не заданным приложением­отправителем явно, оно наследует значение при­знака постоянных сообщений той очереди, в которой размещено.

Приоритет (Priority).

Сообщениям может назначаться приоритет от 0 до 9. При этом WebSphere MQ можно настроить так, чтобы сообщения с большим приоритетом передавались приложениям раньше тех сообщений, чей приоритет ниже.

Идентификатор набора кодовых символов (CCSID – CodedCharSetId).

CCSID задает набор символов, который отображает определенные символы в те или иные байты или наборы байтов. Для данных, именуемых строковыми и пред­ставляющих текст, WebSphere MQ может производить конверсию из одного набо­

112 Глава6

ра символов в другой так, что одни и те же символы будут представлены одними и теми же данными в сообщении. Мы говорили об этом в разделе 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):

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

Код завершения.

Может иметь одно из трех следующих значений:

– 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 «Менеджер по умолчанию».

114 Глава6

Приложение может установить соединение с менеджером только в том случае, если оно на это уполномочено. В основе авторизации приложений лежит контекст иден­тификационных данных (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, при котором те сохраняют свою доступность для других приложений. Доступно толь­ко для объектов­очередей под управлением того менеджера, к которому подклю­чено приложение.

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

Извлечение (Input). Считывание из очереди сообщений функцией MQGET, после которого сообщения не сохраняют свою доступность для других приложений. Может быть монопольным, что означает возможность открытия очереди для счи­тывания лишь одним приложением одновременно. Доступно только для объек­тов­очередей под управлением того менеджера, к которому подключено прило­жение.

Запрос (Inquire). Возврат значений атрибутов объекта функцией MQINQ.

Установка (Set). Задание значений атрибутов объекта функцией MQSET.

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

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

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

При вызове функции MQPUT ей передается структура дескриптора сообщения (MQMD). Во время работы функции менеджер заполняет дескриптор данными, возвращая их приложению в той же самой структуре.

Примечание. ЕслиоднаитажеструктураMQMDслужитдлявыполнениянесколькихвызововMQPUT,поля,которыесформировалменеджер,междувызовамидолжныбытьобнулены.Очистки,вчастности,требуетидентификаторсообщения;иначеонбудетполностьюсовпадатьувсехсообщений,размещенныхспомощьюэтойструктурыMQMD.

Для указания того, как именно выполняется обращение к MQPUT, ей также передается структура параметров размещения сообщения (MQPMO), в которой приложению воз­вращается определенная информация.

Обычно MQPMO служит для указания на то, что обращение к MQPUT должно произойти под управлением точки синхронизации. Это значит, что вся работа по размещению сообщения войдет в текущую единицу работы, а сообщение будет недоступно осталь­ным приложениям для считывания и передачи менеджеру­получателю сообщения, пока не будет произведен вызов функции MQCMIT.

6 .1 .6 . MQPUT1MQI­функция MQPUT1 вызывает MQOPEN, за ней – MQPUT и завершает свою работу вызовом MQCLOSE. Приложение же должно передать ей достаточно информации для выполнения всех трех действий.

116 Глава6

MQPUT1 – удобный и эффективный механизм вызова при постановке в очередь еди­ничного сообщения. Нередко он служит для размещения в очереди сообщения­отве­та или отчета.

6 .1 .7 . MQGETMQI­функция MQGET предназначена для считывания сообщений из очередей, открытых для просмотра или для извлечения.

На вход функции MQGET передается структура дескриптора сообщения (MQMD). В ней менеджер очередей возвращает дескриптор успешно считанного сообщения.

Для указания того, как именно выполняется обращение к MQGET, ей также передается структура параметров извлечения сообщения (MQGMO), в которой приложению возвра­щается определенная информация.

Структура MQGMO определяет, должен ли вызов функции MQGET просмотреть сооб­щения, оставив таковые доступными для других приложений, или извлечь с удалени-ем их из очереди.

Приложение могут не интересовать все сообщения очереди. Например, ему могут быть интересны только отчеты или ответы на дейтаграммы или запросы, выданные им самим. Для упрощения своей задачи приложение может указать на тот факт, что ему интересны лишь сообщения с конкретным корреляционным идентификатором, поместив этот идентификатор в структуру MQMD, передаваемую функции MQGET. При этом оно может управлять тем, производится ли сопоставление с корреляционным идентификатором из структуры MQMD, используя для этого параметры сопоставления (match options) в структуре MQGMO. Такое считывание сообщения носит название извле-чения по корреляционному идентификатору.

Используя этот же механизм, приложение может прибегнуть к извлечению по иден-тификаторам сообщений. Однако при работе с очередями, которые содержат мно­жество сообщений, такое поведение менее эффективно, чем извлечение по корреля­ционному идентификатору, и при обычных условиях, как правило, не используется. Одна из целей извлечения по идентификаторам сообщений – решение таких задач администрирования системы, как извлечение с удалением или просмотр конкретно­го сообщения.

Структура MQGMO определяет, должно ли приложение ждать появления в очереди отве­чающих его критериям сообщений, извлекая их по прибытии в течение установлен­ного периода. При этом приложение может отказаться от ожидания, ждать неопреде­ленно долгое время или до истечения заданного в миллисекундах периода ожидания. Ожидать прибытия сообщений в одну общую очередь могут сразу несколько прило­жений. В этом случае порядок извлечения сообщений из очереди не определен.

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

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

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

дет в текущую единицу работы. Сообщение останется в очереди, но будет недоступно остальным приложениям для извлечения, пока не будет произведен вызов функции MQCMIT.

Примечание.  Принаписанииприложений,которыеизвлекаютпостоянныесообщенияскритичнымидлябизнесаданнымипоклиентскимсоединениям,реко-мендуемвызыватьфункциюMQGETподуправлениемточкисинхронизации,вследзакоторойиспользоватьвызовMQCMIT.Этозащититсообщениеотпотериприсбоевлиниисвязимеждуприложениемименеджером,которыйможетпроизойтивовремяпередачименеджеромсообщенияприложениюпоклиентско-муподключению.

6 .1 .8 . MQBEGINMQI­функция MQBEGIN применяется только в том случае, если менеджер очередей сообщений настроен так, чтобы координировать глобальные единицы работы, вклю­чающие операции в системе баз данных. При вызове функции MQBEGIN приложени­ем в системе начинается новая единица работы, включающая обновления базы дан­ных, корректно сконфигурированной для участия в координируемых WebSphere MQ единицах работы, и вызовы MQPUT/MQGET, производимые под управлением точки синхронизации.

Если координация единицы работы с участием WebSphere MQ осуществляется внеш­ним менеджером транзакций, то для начала единицы работы приложению нужно обратиться к этому менеджеру.

Глобальные единицы работы мы обсуждали в разделе 4.5.5 «Глобальные единицы работы».

6 .1 .9 . MQCMIT и MQBACKMQI­функция MQCMIT предназначена для фиксации текущей единицы работы. Локальная единица работы, включающая только операции WebSphere MQ, содержит все вызовы функций MQPUT и MQGET под управлением точки синхронизации, про­изведенные с момента подключения приложения или последнего вызова MQCMIT или MQBACK. Глобальная единица работы, которая координируется WebSphere MQ и где содержатся операции в системе баз данных и WebSphere MQ, содержит все вызо­вы MQPUT и MQGET под управлением точки синхронизации с момента последнего обращения к MQBEGIN, MQCMIT или MQBACK.

MQI­функция MQBACK предназначена для отмены текущей единицы работы, кото­рую образуют те же самые операции, что в случае с функцией MQCMIT. Отмена еди­ницы работы аннулирует все операции, или производит откат. Изъятые с удалением сообщения возвращаются в очередь, а размещенные – удаляются из нее, так и не став доступными для других приложений.

118 Глава6

6 .1 .10 . MQINQ и MQSETMQI­функция 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. Подробнее каждый тип очереди мы рассмотрим ниже в этом разделе.

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

Очередь сообщений.

Реально представлять очередь, которая входит в менеджер и может содержать сооб­щения, способен лишь один тип объекта – объект «локальная очередь» (local queue).

Особый случай локальной очереди – транспортная очередь, которая служит про­межуточной очередью, объединяющей менеджеры.

В составе менеджеров локальные очереди могут быть определены явно.

Кроме того, они могут быть определены динамически – на базе объектов модель-ных очередей (model queue) посредством вызова MQOPEN с названием модельной очереди в роли параметра. Обычно определенные динамически локальные очере­ди носят название динамических (dynamic queues). Они удаляются при вызове MQCLOSE. Временные динамические очереди могут автоматически удаляться менеджером очередей сообщений и при отключении приложения.

Известный локальному менеджеру кластерный экземпляр очереди.

В большинстве случаев их называют кластерными очередями сообщений (cluster queues). Кластерная очередь – не настоящий объект­очередь под управлением локального менеджера, а локальное – по отношению к менеджеру – представление экземпляра объекта­очереди, существующего в любой точке кластера. Фактический объект­очередь может находиться под управлением локального менеджера, а может располагаться и на другом менеджере очередей в кластере. В составе менеджера с одним и тем же названием может существовать множество кластерных очередей сообщений. Подробнее кластеры менеджеров очередей и кластерные очереди сообщений мы обсудим в главе 8 «Кластеры менеджеров очередей».

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

Заметим,чтоприменениекластеровприсозданииновойинфраструктурыWebSphereMQможетустранитьмножествотребований,которыепредъявляютсякэтимтипамобъектов,азначит,упроститьихадминистрирование.Подробнееокластерахменеджеровочередейсообщенийчитайтевглаве8«Кластерыменед-жеровочередей».

6 .2 .1 . Разрешение названия очередиПри отправке сообщения из приложения местом назначения сообщения может являться очередь под управлением того же самого менеджера, к которому подключе­но приложение. Однако им может быть и другой менеджер очередей сообщений в инфраструктуре WebSphere MQ. Менеджер, к которому подключено приложение, должен знать, как направлять сообщения этому удаленному менеджеру. Больше того, в его составе должна быть очередь временного хранения сообщений, передаваемых к месту своего назначения, – транспортная очередь.

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

120 Глава6

менеджер на маршруте движения сообщения выбирает очередную целевую точку маршрута независимо от других. При этом он руководствуется своим собственным знанием инфраструктуры. Оно заключено в определенных на этом менеджере объ­ектах WebSphere MQ и может быть дополнено знаниями, полученными от других менеджеров, входящих в этот же кластер.

Процесс определения очередного пункта доставки сообщения на маршруте по пре­доставленным приложением сведениям о месте назначения сообщения называется разрешением названия очереди (queue name resolution). Он производится менедже­ром очередей сообщений при каждом получении сообщения от приложения или другого менеджера.

Разрешение названия очереди выполняется и при каждом вызове MQOPEN для открытия очереди перед размещением сообщений. При этом, используя данные из структуры MQOD, переданной при вызове MQOPEN, – название объекта и название менеджера очередей объекта, – менеджер очередей сообщений пытается восстано­вить название нужной целевой очереди и менеджера для данного сообщения.

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

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

Если при разрешении названия оказалось, что место назначения сообщения свя­зано с другим – известным текущему – менеджером, то сообщение размещается в транспортной очереди для отправки этому известному менеджеру. Данный шаг требует включения в сообщение дополнительной информации, дабы при дости­жении им удаленного менеджера название очереди могло быть снова разрешено. Эту информацию называют заголовком транспортной очереди. О том, что про­исходит с сообщением после размещения в транспортной очереди, читайте в разделе 7.4.1 «Отправка сообщений».

Графическая схема разрешения названия приведена на рис. 6.1. Все типы объектов­очередей, показанные на нем значками в прямоугольнике «Разрешение названия очереди», будут описаны нами в этой главе. Обратите внимание, что значки на рис. 6.1 полностью соответствуют тем, что служат для представления объектов каждого типа в WebSphere MQ Explorer.

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

Примечание.  Влияниевхожденияменеджеравкластернаразрешениеназванияочередимыобсудимвразделе8.1.7«Совместныйдоступкобъектам-очередямвкластерах».

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

Рис . 6 .1 . Разрешениеназванияочереди

6 .2 .2 . Объекты локальных очередей и транспортные очередиОбъекты локальных очередей – единственный тип объектов­очередей, представляю­щих реальную очередь, содержащую сообщения. Объекты локальных очередей могут описываться вручную, – о чем мы расскажем в этом разделе, или быть созданы дина­мически – в соответствии с процедурой из раздела 6.2.4 «Объекты модельных очере­дей и динамическое создание локальных очередей сообщений».

Коль скоро содержать сообщения могут только объекты локальных очередей, их применение многогранно. В этой книге объекты локальных очередей – это чаще всего локальные очереди системы, поскольку именно ими в ней и представлена реальная очередь сообщений.

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

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

122 Глава6

Рис. 6.2 показывает, как приложение размещает сообщение в локальной очереди. Здесь разрешение названия очереди буквально переводит указанное название объек-та в название локальной очереди при помощи описанного объекта локальной оче­реди системы.

Информация о получателе (заданная в MQOPEN):Название объекта: Название менеджера очередей объекта: Пусто или название локального менеджера

Сообщение

Сообщение

Разрешение названия очереди в присутствии объекта локальной очереди

Место назначения локально

Менеджер очередей сообщений

Очереди, определенные локально

Очередь Queue_Name

Объект – локальная очередь Queue_Name

Queue_Name

Рис . 6 .2 . Разрешениеназванияочередивприсутствииобъекталокальнойочереди

Транспортные очереди

Атрибут USAGE объекта локальной очереди системы может использоваться, чтобы пометить локальную очередь как транспортную очередь. Для этого атрибут USAGE локальной очереди сообщений принимают равным XMITQ.

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

Передача сообщений из транспортной очереди удаленному менеджеру производится по каналу сообщений. Каналы сообщений мы обсудим в разделе 7.4.1 «Отправка сообщений».

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

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

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

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

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

Рис. 6.3 показывает, как приложение отправляет сообщение и указывает название менеджера очередей объекта. С ним совпадает название транспортной очереди, а значит, именно в ней сообщение и будет размещено.

Рис . 6 .3 . Разрешениеназванияочередивприсутствиитранспортнойочереди

Ручное задание локальных объектов

Принадлежащий локальной очереди атрибут «тип определения» (DEFTYPE – definition type) дает возможность разделить все локальные очереди на те, которые описывались

124 Глава6

вручную, и те, что динамически сформированы из объектов модельных очередей. Атрибут «тип определения» (DEFTYPE) вручную созданных локальных очередей имеет значение PREDEFINED.

Примечание. Атрибут«типопределения»(DEFTYPE)непроводитразличиймеждулокальнымиочередями,которыеавтоматическисозданыWebSphereMQприорганизациименеджера,иочередями,которыесоздаладминистратор.

Создать локальные очереди вручную можно, используя один из перечисленных методов.

При помощи 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 «Кластеры менеджеров очередей».

Примечание. WebSphereMQнетребует,чтобыназваниюуказаннойприописанииилимодификациипсевдонимацелевойочередисоответствовалсущест-вующийобъект-очередь.Еслицелевойобъект-очередьнекорректен,попыткивызоваMQOPENилимаршрутизациисообщенийчерезэтотпсевдонимзакончатсянеудачно.

Рис. 6.4 показывает, как приложение размещает сообщение в локальной очереди через псевдоним очереди. Запрошенное приложением название объекта при разре­шении указывает на целевой объект – локальную очередь, как это и вытекает из определения псевдонима.

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

Рис . 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. Самым распространенным приме­ром ее использования является организация собственной очереди ответов для при­

126 Глава6

ложения при обмене сообщениями по принципу «запрос – ответ». Об этом шла речь в разделе 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).

Постоянная динамическая локальная очередь может содержать как постоянные, так и непостоянные сообщения. Такие очереди не удаляются менеджером очере­

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

дей сообщений автоматически. Вручную постоянную динамическую локальную очередь можно удалить следующим образом:

– вызовом 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).

Название очереди, которой управляет целевой менеджер. Может полностью совпадать с названием объекта «удаленная очередь». Данное название очереди используется при разрешении названия очереди на удаленной машине.

128 Глава6

– Название удаленного менеджера очередей сообщений (RQMNAME).

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

– Транспортная очередь (XMITQ).

Содержит название транспортной очереди, которая передает сообщения оче­редному менеджеру маршрута к месту их назначения. Если удаленный менед­жер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться.

Рис. 6.5 показывает, как приложение посылает сообщение, пользуясь локальным опи­санием очереди на удаленной машине. Название объекта, которое указано приложе­нием, – это название объекта «удаленная очередь». При разрешении названия очере­ди сообщение будет размещено в заданной в описании удаленной очереди сообще­ний транспортной очереди. К сообщению при передаче будет прикреплен заголовок транспортной очереди с атрибутами, взятыми из описания объекта «удаленная оче­редь». Ими станут удаленное имя и название удаленного менеджера очередей сообще-ний. Когда сообщение достигнет места своего назначения, информация из заголовка т р а н с п о р т н о й о ч е р е д и п о с л у ж и т д л я р а з р е ш е н и я н а з в а н и я о ч е р е д и в составе удаленного менеджера.

Рис . 6 .5 . Разрешениеназванияочередивприсутствиилокальногоопределенияудаленнойочередисообщений

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

Как псевдоним менеджера очередей сообщений.

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

– Название объекта «удаленная очередь».

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

– Удаленное имя (RNAME).

Применительно к псевдониму атрибут должен быть незаполнен.

– Название удаленного менеджера очередей сообщений (RQMNAME).

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

– Транспортная очередь (XMITQ).

Содержит название транспортной очереди, которая передает сообщения оче­редному менеджеру маршрута к месту их назначения. Если удаленный менед­жер очередей имеет то же название, что и транспортная очередь, атрибут может не заполняться. Также он может не заполняться при описании псевдо­нима для локального менеджера.

Рис. 6.6 показывает, как приложение посылает сообщение, используя псевдоним менеджера очередей сообщений. Название менеджера очередей объекта, которое указано приложением, преобразуется в другое название менеджера, для доставки которому сообщение будет размещено в транспортной очереди.

130 Глава6

Рис . 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.

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

6 .2 .6 . Атрибуты по умолчанию и контроль полномочийПри открытии очереди WebSphere MQ производит проверку прав, определяя, упол­номочена ли сущность выполнять действия, которые запросила. К обсуждению этой темы мы вернемся в разделе 11.2 «Предоставление доступа к ресурсам менеджеров очередей».

Также WebSphere MQ задает ряд значений по умолчанию для сообщений, которые впоследствии будут посланы открывшим очередь приложением. В дальнейшем при­ложение вправе заменить эти значения на свои собственные.

Такой контроль полномочий и значения по умолчанию основаны на атрибутах и разрешениях единственного объекта WebSphere MQ. Его можно считать первым сре­ди объектов WebSphere MQ, к которым производится доступ при разрешении опре­деленного приложением названия очереди.

Объект, который используется при отправлении сообщений, зависит от сочетания названий объекта и менеджера очередей объекта. Возможные комбинации показаны в табл. 6.1. В их число входят и сочетания для кластеров менеджеров очередей сооб­щений. Речь о таких кластерах пойдет в главе 8 «Кластеры менеджеров очередей».

Табл . 6 .1 . ОбъектWebSphereMQдляустановкизначенийпоумолчаниюипроверкиналичияполномочий

Название объекта Название менеджера очередей объекта

Объект WebSphere MQ для установки значений по умолчанию и проверки наличия полномочий

Название объекта – локальной, модельной, удаленной очереди или их псевдонима, опреде­ленное на локальном менеджере очередей сообщений

Пусто или назва­ние локального менеджера

Объект WebSphere MQ, имеющий задан­ное название

Любое Название удален­ного менеджера, при разрешении которого может быть установле­но название транспортной очереди

Транспортная очередь

Название очереди, сов­местно используемой тем кластером менедже­ров очередей сообще­ний, в который входит текущий менеджер

Пусто Проверка наличия полномочий произ­водится в отношении объекта

SYSTEM.CLUSTER.TRANSMIT.QUEUE

Источником значений по умолчанию является определение объекта­очереди под управлением удаленного менедже­ра. Значения по умолчанию можно уви­деть, отобразив атрибуты записи клас­терной очереди, к примеру воспользо­вавшись командой DISPLAY QCLUSTER из состава MQSC

132 Глава6

Постоянство по умолчаниюОдним из часто используемых атрибутов объектов­очередей является атрибут посто­янства по умолчанию (DEFPSIST – default persistence). Установить, будет ли сообщение постоянным, приложение может при его размещении, задав параметр вызова MQPUT. Выбрав иной подход, приложение может оставить определение постоянства сообще­ний на откуп атрибуту соответствующей очереди.

Предположим, менеджер управляет локальной очередью local.psist с атрибутом DEFPSIST(YES). Пусть им же управляется псевдоним очереди alias.nonpsist с параметра­ми DEFPSIST(NO) и TARGQ(‘local.psist’). Сообщение, размещенное в очереди после открытия local.psist, окажется постоянным. Сообщение, размещенное после откры­тия alias.nonpsist, будет непостоянным. Между тем оба сообщения будут помещены в одну очередь.

Примечание.  Приведеннаяситуациялишьпример,неявляющийсярекомен-дуемойпрактикой.НаибольшуюэффективностьWebSphereMQдемонстрируетприусловии,чтовочередисодержатсяисключительнопостоянныеилинепо-стоянныесообщения.

6 .2 .7 . Состояние и онлайновый мониторинг очередейЛокальные очереди – важнейший контролируемый менеджером ресурс, поскольку именно в них находятся все сообщения, которые он содержит.

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

Удовлетворяя эту потребность, WebSphere MQ предоставляет данные мониторинга о состоянии каждой располагающейся на менеджере локальной очереди сообщений. В совокупности эти сведения, значительно расширенные в WebSphere MQ V6.0, таковы.

Количество находящихся в очереди сообщений.

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

Дата и время последнего извлечения приложением сообщения из очереди.

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

Дата и время последнего размещения приложением сообщения в очереди.

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

Сведения о каждом соединении с менеджером открывшего очередь приложения, включая:

– название приложения, которое установило соединение;

– идентификатор процесса приложения;

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

– контекст идентификационных данных, в котором выполняется приложение;

– действия, для выполнения которых приложение открыло очередь: просмотр сообщений, извлечение, размещение или запрос;

– если соединение с менеджером является удаленным и происходит по клиент­скому подключению, то информация об указанном подключении;

– признак активности; выполняет ли приложение работу с менеджером;

Информация о производительности использующих очередь приложений. В нее в том числе, входят:

– кратко­ и долгосрочная оценка среднего времени, которое сообщение прово­дит до извлечения из очереди. дается в микросекундах, поскольку срок пребы­вания сообщения в очереди может быть очень мал;

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

Примечание. Полученнаявходеконтроляочередейинформацияопроизводи-тельностиявляетсяновшествомWebSphereMQV6.0иназываетсяинформациейонлайновогомониторинга(onlinemonitoring).ИспользуяатрибутMONQобъекта-менеджераочередейсообщений,выможетенаблюдатьзавсемиочередями,которымименеджеруправляет;используяжеатрибутMONQочереди–затребуе-мымнаборомлокальныхочередей.Подробностисм.вруководствеMonitoringWebSphereMQ,SC34-6593.ИлинажмитеклавишуF1ивыберитеразделOnlineMonitoringстраницысвойств,предварительновыделивменеджерочередейсообщенийвWebSphereMQExplorer.

Чтобы просмотреть информацию о состоянии очередей, используйте один из двух методов.

MQSC­команду DISPLAY QSTATUS.

WebSphere MQ Explorer. Обычно этот способ просмотра самый удобный:

a) щелкните по папке Queues конкретного менеджера очередей сообщений в навигаторе WebSphere MQ Explorer;

b) щелкните правой кнопкой мыши по интересующей вас локальной очереди таблицы, представленной на панели содержимого Queues;

c) выберите пункт меню Status.

6 .3 . Применение триггеровПоступающие в очереди сообщения представляют происходящие в системе события. В большинстве случаев эти сообщения требуют обработки.

Для автоматического запуска обработки менеджером очередей сообщений в WebSphere MQ предусмотрен механизм «триггеринга» (triggering). По характеру обработки ею может являться открытие канала передачи сообщений из транспорт­ной очереди удаленному менеджеру или инициирование работы экземпляра прило­

134 Глава6

жения для того, чтобы произвести действие над одним или несколькими сообщения­ми (пакетом).

С учетом назначения очереди приходящее в нее сообщение может представлять или не представлять событие, которое требует обработки. Саму очередь можно настроить на порождение триггерных событий (trigger events), соответствующих тому, для каких целей она используется.

6 .3 .1 . Порождение триггерных событийНа порождение триггерных событий очередь можно настроить различным образом.

Для каждого сообщения.

Триггерное сообщение будет порождено для каждого поступающего в очередь сообщения. Для выбора такого режима триггеринга в локальной очереди сообще­ний задайте следующие параметры:– активируйте триггеры: TRIGGER;– установите тип триггера «для каждого сообщения»: TRIGTYPE(EVERY).

Для первого сообщения.

Триггерное событие порождает первое сообщение, поступающее в очередь после того, как она опустеет. Обычно триггерное событие возникает, если для извлече­ния сообщений очередь открывается каким бы то ни было приложением. Однако если через указанный триггерный интервал приходит сообщение, а ни одно при­ложение не открыло очередь на извлечение, то возникнет новое триггерное событие. Для выбора такого режима работы триггеринга в локальной очереди сообщений задайте следующие параметры:– активируйте триггеры: TRIGGER;– установите тип триггера «для первого сообщения»: TRIGTYPE(FIRST);– установите являющийся атрибутом объекта­менеджера очередей сообщений

триггерный интервал, равный необходимому вам значению в миллисекундах: TRIGINT(5000).

Для заданной глубины.

Триггерное событие порождает то сообщение, при поступлении которого общее количество сообщений, находящихся в очереди, становится выше определенного порогового значения. Триггерное событие не возникает, если есть приложение, открывшее эту очередь для извлечения сообщений. Чтобы настроить этот меха­низм триггеринга, задайте следующие атрибуты локальной очереди:– активируйте триггеры: TRIGGER;– установите тип триггера «для заданной глубины»: TRIGTYPE(DEPTH);– установите требуемый порог глубины очереди: TRIGDPTH(10).

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

Примечание.  Длятогочтобытриггерноесобытиепроизошло,должнабытьвыполненасовокупностьусловий.Еслитриггерноесобытиеневозникает,какзапланировано,рекомендуемпоочереднопроверитьвыполнениевсехусловий,чтодаствозможностьустановитьпричинувашейпроблемы.Полностьюусловияперечисленывразделе«StartingWebSphereMQapplicationsusingtriggers»руководстваWebSphereMQApplicationProgrammingGuide,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 есть триггерные мониторы для каждой платформы. Их функ­ция – поддержка базовых возможностей выполнения приложений согласно опреде­

136 Глава6

лению 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 «Инициирование канала».

Примечание.  Несмешивайтеинициаторканаловвэтомразделесинициато-ромканаловвWebSphereMQдляz/OSизраздела5.3.10«ИнициаторканаловWebSphereMQдляz/OS».

ОткрытиеканаловсообщенийвWebSphereMQдляz/OSиWebSphereMQдляiSeriesреализуютпрограммы-слушателиканалов.

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

7

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

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

В этой главе мы обсудим следующие вопросы:

Каналы

Запуск и останов каналов

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

Распределенные каналы сообщений

Автоопределение каналов

138 Глава7

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­интерфейс клиента.

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

Клиентский 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­вызова. Контекстом может являться

140 Глава7

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

Ряд атрибутов канала должен быть согласован обоими MCA, что даст возможность найти значения, приемлемые для каждого. Примером подобного атрибута служит размер пакета, описанный в разделе 7.4.2 «Пакеты». Обычно атрибуты такого рода являются числовыми и принимают меньшее из значений, предложенных каждым из MCA.

На рис. 7.1 процесс установления канала двумя агентами MCA сведен воедино.

ы менеджера).

Рис . 7 .1 . Установлениеканала,соединяющегодваменеджераилиприложениесменеджером

7 .2 . Запуск и останов каналовЗапуск канала означает запуск агента для подключения к MCA удаленного менеджера и установление канала. Остановом канала называют прекращение коммуникации двух агентов, которые установили канал.

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

Для запуска и останова соединяющих менеджеры каналов сообщений могут исполь­зоваться команды MQSC START CHANNEL и STOP CHANNEL. Дополнительно они служат для блокировки канальных объектов и ее снятия, а значит, определяют, могут с их помо­щью запускаться каналы или нет.

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

Аналогичные функции доступны в 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 , представляющий состояние канала в целом.

142 Глава7

Примечание.  ВWebSphereMQExplorerможноотобразитьвсезаписисостояния,которыесоответствуютобъекту–распределенномуканалусообщенийиликлиентскомуканалу.Дляэтоговыделитевнавигаторепапку 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 знакам. Для упрощения администрирования название канала должно адекватно отражать его назначение.

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

Если длина названий всех менеджеров очередей сообщений в системе не превыша­ет 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 «Автоопределение каналов».

144 Глава7

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, не передают идентификатор пользователя агенту серверного подключения.

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

По этим причинам, как правило, мы советуем всем приложениям, которые под­ключаются по каналу с определенным названием, назначать общий контекст иденти­фикационных данных, для чего служит имеющийся у объекта­канала серверного подключения атрибут «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.

146 Глава7

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клиента

Выбранное приложением название менеджера очередей сообщений

Описание порядка поиска соответствующих канальных объектов клиентских подключений

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

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

Выбранное приложением название менеджера очередей сообщений

Описание порядка поиска соответствующих канальных объектов клиентских подключений

*название_менеджера

Первыйввыбранномприложени-емназваниименеджерадолженбытьсимвол«звездочка»(*)

Соответствующимисчитаютсятолькоканальныеобъектыклиентскихподключенийсназваниемменеджераочередейсообщений«название_менеджера» .Если,воспользовавшисьназваниемканалаиатрибутамиодногоизканальныхобъектовтакогорода,сменеджеромудаетсясвя-заться,соединениеуспешноформируетсянезависимооттого,какоеназваниеменеджеримеетвдействительности .Этотмеханизмудобендляобеспечениярезервногоменеджеравтомслучае,еслименеджерочередейсопределеннымназваниемнедоступендляподключения

название_менеджера Соответствующимисчитаютсятолькоканальныеобъектыклиентскихподключенийсназваниемменеджераочередейсообщений«название_менеджера» .Если,воспользовавшисьназваниемканалаиатрибутамиодногоизканальныхобъектовтакогорода,сменеджеромудаетсясвя-заться,соединениеуспешносформируетсялишьтогда,когдареальноеназваниеменеджераесть«название_менеджера»

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.

Окончаниетабл7 .1

148 Глава7

Сейчас использование 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:\ProgramFiles\IBM\WebSphereMQ\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 «Раз­решение названия очереди», менеджер размещает сообщение в транспортной очере­ди в результате разрешения названия очереди. По ходу разрешающей процедуры он добавляет в заголовок транспортной очереди сообщения достаточно информации для того, чтобы разрешение названия очереди произошло в тот момент, когда сооб­щение достигнет менеджера очередей назначения.

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

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

7 .4 .1 . Отправка сообщенийВ состав любого распределенного канала сообщений входят два MCA, а значит, и два канальных объекта – по одному для каждого менеджера. В зависимости от типа опи­санного на менеджере объекта­канала сообщений каждый агент выполняет одну из следующих ролей.

MCA – отправитель.

Открывает определенную атрибутами канального объекта транспортную очередь сообщений для монопольного извлечения. Сказанное означает, что никакие два канала не могут быть настроены так, чтобы забирать сообщения из одной транс­портной очереди. MCA­отправитель извлекает сообщения из транспортной оче­реди и посылает их агенту­партнеру.

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

MCA – получатель.

Получает сообщения от MCA­отправителя. В процессе своей работы удаляет из каждого сообщения заголовок транспортной очереди и производит чтение содержимого. Открывает указанную в заголовке транспортной очереди очередь сообщений и помещает сообщение в эту очередь. Открытие очереди и размеще­ние сообщения осуществляются с помощью стандартных вызовов MQI. Это означает, что разрешение названия очереди на менеджере аналогично тому, как если бы к нему подключилось непосредственно приложение, которое, руководс­твуясь деталями заголовка транспортной очереди, разместило бы сообщение в очереди самостоятельно. Если при разрешении названия на менеджере не удает­ся установить допустимое место назначения сообщения, сообщение доставить нельзя. Об этом мы еще скажем в разделе 7.4.11 «Ошибки доставки сообщений».

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

Название удаленной очереди.

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

Название удаленного менеджера.

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

150 Глава7

Дескриптор исходного сообщения.

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

Связь пары менеджеров очередей по каналу показана на рис. 7.2.

Рис . 7 .2 . Коммуникациядвухменеджеровочередейсообщенийсиспользованиемагентовотправителяиполучателя

7 .4 .2 . ПакетыДля надежного обеспечения однократной доставки сообщений и агент­отправитель, и агент­получатель должен иметь возможность гарантировать то, что сообщение не потеряется, не окажется отправлено дважды и будет успешно получено MCA­получа­телем.

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

С этой целью MCA­отправитель может использовать единицу работы, извлекая сооб­щения из очереди, а MCA­получатель – размещая их в очереди.

Примечание. Поумолчаниюканалысообщенийнепользуютсяединицамиработыдляпередачинепостоянныхсообщений.Этоозначает,чтосбоисвязимогутприводитькихпотере.Такоестандартноеповедениеканаламожноизменить,выбравнормальную,аневысокуюскоростьпередачинепостоянныхсообщений(NPMSPEED–nonpersistentmessagespeed)канальнымобъектомMCA-отправителяилиMCA-получателя.

Чтобы обеспечить защиту от потери или двукратной доставки сообщений при сбоях коммуникации, эти две независимые единицы работы должны быть скоординирова­ны обоими MCA. Для этого агенты должны «договориться» по сети о фиксации или откате обоими единицы работы, если связь оборвется.

Этот процесс требует дополнительного сетевого обмена, а потому обычно не произ­водится для каждого передаваемого по каналу сообщения. Отдельные пересылаемые сообщения объединяются и образуют пакет (batch), в котором все сообщения либо фиксируются в приемных очередях, либо возвращаются в транспортную очередь как одно целое.

Предельное количество содержащихся в пакете сообщений называется размером пакета (batch size). Настроить это значение позволяют одноименные атрибуты (BATCHSZ – batch size) канального объекта MCA­отправителя и MCA­получателя. Используемый размер пакета принимается равным меньшему из значений двух атри­бутов.

Иногда для заполнения пакета в транспортной очереди бывает недостаточно сооб­щений. В этом случае в ожидании новых сообщений в транспортной очереди MCA­отправитель берет короткую паузу, фиксируя уже отосланные сообщения только по ее истечении. Количество миллисекунд ожидания до фиксации пакета сообщений MCA­отправителем определяется атрибутом пакетного интервала (BATCHINT – batch interval). Его значением управляет канальный объект MCA­отправителя.

7 .4 .3 . Неоднозначные каналы и порядковые номера сообщенияЕсли сетевой обмен был нарушен при подтверждении пакета двумя агентами MCA, такой канал может превратиться в неоднозначный (indoubt). Причина этого в том, что сообщение с запросом на подтверждение было отправлено, а ответ на него не получен. Отправившему запрос агенту неизвестно, действительно ли агент­партнер принял его запрос, а связь нарушилась уже во время ответа, или же сбой случился при отправке запроса.

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

152 Глава7

Неоднозначное состояние канала представлено значением YES атрибута INDOUBT его записи состояния.

Примечание.  Подробнееонеоднозначныхканалахиручныхоперациях,которыевыможетепредпринять,есликаналперешелвнеоднозначноесостояниеинеспособенавтоматическиегоразрешить,читайтевруководствеWebSphereMQIntercommunication,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)')

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

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

154 Глава7

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­канала, если в нем определено полностью название соединения.

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

Каналы 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­получатель может попытаться разместить сообщение вновь. Количество повтор­ных попыток размещения сообщения агентом определяется атрибутом «число

156 Глава7

попыток на сообщение» (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.вWebSphereMQExplorerполезноскрыть,апотомуподобнойнастройкиобычнорекомендуетсяизбегать.

Убедитесь,чтозначениеатрибута«предельнаядлинасообщения»очерединедоставленныхсообщенийдостаточновеликоиниодносообщение,попаввочередь,небудетусечено.

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

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.

158 Глава7

Применение обработчика очереди недоставленных сообщений собственной раз­работки.

Если правил из обработчика очереди недоставленных сообщений, входящего в WebSphere MQ, не хватает для выполнения особых требований клиента, допус­кается и создание специального приложения, которое будет обслуживать сообще­ния по мере их поступления в очередь.

7 .4 .13 . Инициирование каналаПерезапуск каналов сообщений не производится WebSphere MQ автоматически, если каналы становятся неактивны по достижении интервала разъединения или при пере­запуске менеджера.

Число каналов в составе менеджера может быть велико, и ручной запуск с использова­нием MQSC или WebSphere MQ Explorer в инфраструктуре взаимосвязанных менедже­ров может оказаться неэффективным.

WebSphere MQ для платформ Windows и UNIX содержат процесс­инициатор каналов, автоматически запускающий их при поступлении сообщений в транспортные очереди.

Примечание. НесмешивайтеинициаторканаловвэтомразделекнигисинициаторомканаловWebSphereMQдляz/OS,описаннымвразделе5.3.10.

ОбязанностипозапускувWebSphereMQдляz/OSиWebSphereMQдля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 канальные объекты создавались автоматически.

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

Чтобы разрешить автоопределение каналов менеджера очередей сообщений, устано­вите атрибут «автоопределение каналов» (CHAD – channel auto­definition) объекта­менеджера в значение ENABLED.

7 .5 .1 . Автоопределение клиентских каналовЕсли приложение пытается подключиться к менеджеру очередей сообщений, исполь­зуя клиентский канал, но соответствующий объект­канал серверных подключений с требуемым названием в менеджере отсутствует, он создается автоматически.

После автоопределения канала объект­канал функционирует так, как будто создавал­ся вручную. Атрибуты канального объекта серверных подключений основаны на атрибутах автоматически формируемого менеджером очередей сообщений каналь­ного объекта серверных подключений SYSTEM.AUTO.SVRCONN.

7 .5 .2 . Автоопределение распределенных каналов сообщенийЕсли при попытке удаленного менеджера установить подключение, используя объ­ект – sender­канала или полностью заданный объект – server­канала, соответствую­щий receiver­канал или requester­канал с требуемым названием на менеджере отсутс­твует, автоматически создается receiver­канал.

После автоопределения канала объект­канал функционирует так, как будто создавал­ся вручную. Атрибуты объекта – receiver­канала основаны на атрибутах автоматиче­ски формируемого менеджером очередей сообщений объекта receiver­канала SYSTEM.AUTO.RCVR.

Кластерыменеджеровочередей 161

8

Кластеры менеджеров очередей

Эта глава дает начальное представление о кластерах менеджеров очередей и показы­вает, как, пользуясь ими, вы можете сократить объем работы по администрированию инфраструктуры WebSphere MQ и получить дополнительные возможности, позволя­ющие повысить готовность служб и сбалансировать нагрузку между несколькими экземплярами службы в составе кластера.

В этой главе мы обсудим следующие вопросы:

Обзор понятий кластеризации

Просмотр сведений о репозиториях кластеров

Работа с менеджерами очередей в кластере

Балансировка нагрузки

162 Глава8

8 .1 . Обзор понятий кластеризацииВсе менеджеры очередей в кластере располагают сведениями о том, какими ресурса­ми наделен кластер, причем ресурсы в его составе не требуют явного локального описания. Добавлять в кластер новые ресурсы, например менеджеры и очереди, которыми они управляют, вы можете динамически, автоматически делая их доступ­ными для пользования всем менеджерам очередей сообщений, которые входят в кластер.

Это дает возможность добавлять в кластер или удалять из него дополнительные ресурсы аппаратуры с учетом меняющейся нагрузки на инфраструктуру очередей сообщений WebSphere MQ.

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

Примечание.  Впроцессереализацииновойинфраструктурыкакбазудляеепостроениярекомендуетсяиспользоватькластер.

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

Изложенное в данной главе представление о кластерах кому­то покажется изначаль­но сложным для понимания. Однако эти идеи приведут нас к такой инфраструктуре менеджеров очередей сообщений, администрировать которую значительно проще, чем построенную с использованием распределенных каналов, что и показывают практические примеры из раздела 10.4 «Создание кластеров менеджеров очередей».

Увеличиваясь в масштабе, такая инфраструктура может охватить тысячи менед­жеров.

Примечание.  Вплотьдоконцаглавыпонятием«кластер»(cluster )мыбудемпользоваться,называятаккластерыменеджеровочередейсообщений.Непутайтеегоскластерамивысокойготовности–понятием,характернымнетолькодляWebSphereMQ,окотороммыговориливразделе3.6«Высокаяготовностьсистемы».

Кластерыменеджеровочередей 163

8 .1 .1 . Менеджеры очередей с полным и частичным репозиторием

Любой менеджер очередей сообщений содержит репозиторий (repository) с данными о кластерах, в которых он состоит.

Каждый менеджер внутри кластера можно настроить так, чтобы он содержал час-тичный или полный репозиторий. Суть полных и частичных репозиториев такова.

Полный репозиторий.

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

Менеджер, содержащий полный репозиторий с представлением кластера, называ­ется менеджером очередей с полным репозиторием (full repository queue manager).

Частичный репозиторий.

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

Менеджер, содержащий частичный репозиторий своего кластера, называется менеджером очередей с частичным репозиторием (partial repository queue man-ager).

Для вхождения в кластер менеджер очередей должен «знать» его полный репозито­рий. Поэтому каждый кластер обязан содержать два или более менеджера, в которых такой репозиторий будет храниться. Именно эти два менеджера очередей с полным репозиторием изначально и образуют кластер, организуя соединение между собой.

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

8 .1 .2 . Названия кластеровЛюбой кластер имеет свое название. Имена кластеров могут содержать до 48 знаков и состоять из букв верхнего, нижнего регистра и цифр, а также символов «.», «/», «_», «%».

Полезными могут оказаться короткие имена кластеров, длина которых позволит включать их в описание всех кластерных канальных объектов.

164 Глава8

8 .1 .3 . Настройка менеджера очередей с полным репозиторием

Примечание.  Этотшагрекомендуетсявыполнитьдотого,какменеджерочередейбудетподключенккластерусиспользованиемописанныхвэтомразделеобъектовкластерныхsender-иreceiver-каналовсообщений.

Для задания кластеров, полный репозиторий с информацией о которых содержит текущий менеджер, служат атрибуты объекта­менеджера «репозиторий» (REPOS – repository) и «список названий репозиториев» (REPOSNL – repository namelist).

Атрибут REPOS позволяет определить имя только одного кластера.

Атрибут REPOSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере объекта – списка имен. Определите объект­список так, чтобы он содержал перечень названий интересующих кластеров.

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

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

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

8 .1 .4 . Кластерные каналы сообщенийВся информация в кластере передается по кластерным каналам сообщений (cluster message channels). Это справедливо и для тех случаев, когда приложение отправляет сообщение во входящую в кластер очередь и когда менеджер запрашивает в полном репозитории информацию о ресурсах в составе кластера.

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

SYSTEM.CLUSTER.TRANSMIT.QUEUE

Кластерыменеджеровочередей 165

Все сообщения, адресуемые менеджерам очередей в кластере, будут размещены в этой очереди сообщений автоматически.

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

Кластерные каналы сообщений используют агенты каналов сообщений (MCA) отправления и получения и обладают теми же возможностями, что и любой распре­деленный канал. К примеру, они имеют интервалы разъединения, поддерживают пакетную обработку и записи состояния канала, могут пользоваться аутентификаци­ей SSL. Описание распределенных каналов и передачи сообщений между MCA­отпра­вителем и MCA­получателем см. в разделе 7.4 «Распределенные каналы сообщений».

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

С этой целью в WebSphere MQ введены объекты – кластерные каналы. Они могут определяться в составе менеджера для инициирования процесса подключения его к кластеру.

8 .1 .5 . Кластерные receiver-каналыОбъекты – кластерные receiver­каналы описывают атрибуты, которыми, определяя кластерные sender­каналы сообщений, адресованных текущему менеджеру, должны пользоваться все входящие в один или несколько кластеров менеджеры очередей сообщений.

Чтобы сообщить менеджерам очередей с полным репозиторием о менеджере, в со­ставе которого описан кластерный receiver­канал, он публикуется внутри кластера. Это означает отправку сведений о нем в один из полных репозиториев кластера, который передаст их остальным менеджерам очередей с полным репозиторием. Полные репозитории, в свою очередь, опубликуют это определение на менеджерах с частичным репозиторием в этом кластере, как только те запросят ресурсы, которы­ми этот менеджер управляет.

Объекты – кластерные receiver­каналы описывают название и атрибуты, которыми во время установления направленного к данному менеджеру канала от других менед­жеров пользуются как MCA­отправитель, так и MCA­получатель.

Так, в кластерном receiver­канале задан интервал разъединения кластерных каналов сообщений. Им пользуется каждый MCA­отправитель, производящий подключение к менеджеру.

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

166 Глава8

Чтобы вручную задать объекты – кластерные 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-символьномназванииканала.

Кластерыменеджеровочередей 167

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

168 Глава8

Атрибут CLUSTER позволяет определить имя только одного кластера.

Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Опре­делите объект­список так, чтобы он содержал перечень интересующих кластеров.

При описании объекта – кластерного sender­канала через него в полном репозито­рии публикуются любые объекты – кластерные receiver­каналы, что вызывает начало автоматического процесса установления членства менеджера в указанных кластерах.

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

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

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

Менеджерамочередейсчастичнымрепозиториемдостаточноодногоявногокластерногоsender-каналанезависимоотчислаимеющихсявсоставекластераменеджеровочередейсполнымрепозиторием.Описаниенаменеджереочередейсчастичнымрепозиториемболееодногоявногокластерногоsender-каналанедаетникакихпреимуществ.

8 .1 .7 . Совместный доступ к объектам-очередям в кластерахМенеджеры очередей с полным и частичным репозиторием в кластере могут пользо­ваться объектами­очередями кластера коллективно.

Это дает возможность автоматически распространять сведения об объектах­очередях по всем менеджерам очередей в кластере. Например, приложение, подключенное к одному менеджеру, может разместить сообщение в локальной очереди другого, причем сама очередь может совместно использоваться всем кластером без указания названия этого удаленного менеджера.

Кластерыменеджеровочередей 169

Совместный доступ допускают следующие типы объектов­очередей.

Объекты локальных очередей:

Чаще всего совместный доступ в кластерах организуется именно к ним. Обоб­ществление локальных очередей позволяет приложению, подключенному к лю­бому менеджеру очередей в кластере, поместить сообщение в очередь, которая используется этим менеджером совместно с другим, указав только название оче­реди во время ее открытия.

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

Однако,еслиприложениеразмещаетсообщениевочередиспроизвольнымназваниемсуказаниемконкретногоменеджера,которыйявляетсячленомкластера,сообщениедоставляетсяэтомуменеджеру.Сказанноеозначает,чтоприложениеможетпослатьответвдинамическиорганизованнуюочередьдляответов,используяназваниеочередиответовиееменеджера,указанныевде-скрипторесообщения-запроса.Названиеменеджераочередиответовавтомати-ческиподставляетсятемменеджеромочередейсообщений,ккоторомубылоподключеноприложение-инициаторзапроса.

Витогеприложениямогутпроизводитьобменсообщениямипопринципу«запрос–ответ»сослужбойнаосноверазделяемойочередивсоставекластерааналогичнотому,какеслибыэтаочередьнаходиласьподуправлениемменедже-ра,ккоторомуподключеноприложение.

Объекты очередей­псевдонимов.

Наличие в кластере очереди­псевдонима с совместным доступом позволяет менеджеру очередей сообщений обобществить в нем имеющийся в составе менеджера объект­очередь под другим именем. Локальное по отношению к менед­жеру название очереди определяется атрибутом «целевая (базовая) очередь» (TARGQ/base queue), названием же объекта очереди­псевдонима служит название, под которым очередь доступа в составе кластера.

Объекты удаленных очередей.

Совместный доступ к различным типам входящих в кластер объектов удаленных очередей, описанных в разделе 6.2.5 «Объекты удаленных очередей», дает различ­ные результаты. Типичные примеры их использования следующие.

– Локальное определение удаленной очереди.

Предоставляет входящим в кластер менеджерам возможность совместно использовать очередь сообщений, находящуюся вне кластера, то есть в составе менеджера, который не является его членом. Названием объекта удаленной очереди является название, под которым организован совместный доступ к ней внутри кластера. Название целевой очереди в составе менеджера очере­дей назначения определяется атрибутом «удаленное имя» (RNAME), название управляющего ею менеджера – атрибутом «название удаленного менеджера очередей сообщений» (RQMNAME). Название транспортной очереди менеджера, на котором описана удаленная очередь, может быть задано атрибутом «транс­

170 Глава8

портная очередь» (XMITQ) или по умолчанию принято равным названию уда­ленного менеджера.

– Псевдоним менеджера очередей сообщений.

В данном случае атрибут RNAME объекта удаленной очереди остается пустым. При этом возможны две ситуации.

• Внутри кластера менеджер очередей может выбрать альтернативное имя. Им станет название обобществленного в кластере объекта удаленной оче­реди; реальное же название менеджера будет указано в атрибуте «название удаленного менеджера очередей сообщений» (RQMNAME).

• Название менеджера вне кластера может быть известно внутри него, а транспортная очередь к этому менеджеру – задаваться в составе менеджера очередей сообщений, предоставляющего совместный доступ к определе­нию объекта удаленной очереди. Название, под которым менеджер очере­дей сообщений должен быть известен в составе кластера, – это название обобществленного в нем объекта удаленной очереди. Название менеджера очередей вне кластера определяется атрибутом RQMNAME. Название транспорт­ной очереди менеджера внутри кластера, если оно отлично от названия менеджера очередей за пределами такового, задается атрибутом XMITQ.

Примечание.  Ещеодинполезныйспособпримененияобъектовудаленныхочередейвкластере–описаниевсоставеменеджераочередейпсевдонимаспустымзначениематрибута«удаленноеимя»(RNAME)безразделенияобъектаудаленнойочередивкластере.

Такаясхемаведеткбалансировкенагрузки,создаваемойсообщениями,поступа-ющимиэтомуменеджеруочередейизвнекластераисодержащимиконкретноеназваниеменеджераочередейсообщений.

Совместно пользоваться объектами­очередями с одним названием и одного или раз­ных типов в одном кластере могут, располагая этими типами объектов­очередей, сразу несколько менеджеров. Об этом мы еще скажем в разделе 8.4 «Балансировка нагрузки».

Для задания кластеров, в которых к объекту организован совместный доступ, служат атрибуты объектов­очередей «кластер» (CLUSTER – cluster) и «список названий класте­ров» (CLUSNL – cluster namelist).

Атрибут CLUSTER позволяет определить имя только одного кластера.

Атрибут CLUSNL позволяет определить имена нескольких кластеров. Задайте в этом атрибуте название описанного на менеджере очередей объекта – списка имен. Опре­делите объект­список так, чтобы он содержал перечень интересующих кластеров.

8 .1 .8 . Идентификатор менеджера очередей (QMID)При создании каждого менеджера очередей сообщений для него строится иденти­фикатор менеджера QMID (queue manager identifier), значение которого определяют время создания и название менеджера. В этих условиях вероятность того, что два

Кластерыменеджеровочередей 171

менеджера получат одинаковые QMID, очень невелика, даже если они будут названы одинаково.

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

Если это произошло и в кластере оказалось несколько менеджеров с одинаковыми названиями, то, приступая к разрешению ситуации, изучите документацию по коман­де MQSC RESET CLUSTER ACTION(FORCEREMOVE).

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

8 .1 .9 . Подписки и публикации в кластереВ этом разделе мы коротко расскажем о том, как полные и частичные репозитории кластера поддерживают актуальную информацию, что послужит основой для пони­мания сведений, получаемых при просмотре той информации о кластере, которая в них содержится.

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

Как только к кластеру подключается менеджер с частичным репозиторием, он публи-кует информацию о себе, включая предоставленную объектом – кластерным recei­ver­каналом, и адресует ее двум полным репозиториям внутри кластера.

Организуя совместный доступ к объекту очереди внутри кластера, менеджер с час­тичным репозиторием аналогично публикует сведения об объекте двум полным репозиториям кластера.

Частичный репозиторий повторяет эти публикации каждые 27 дней, что позволяет полным репозиториям убедиться, что менеджер внутри кластера остается активным, а информация – актуальной. Также полным репозиториям адресуются любые пуб­ликации с изменениями этих совместно используемых в кластере менеджеров объектов.

Если публикация не повторяется в течение 30 дней, ее срок действия истекает, и на запрос сведений от частичных репозиториев полные репозитории перестают выда­вать ее как ответ. Однако на случай временной недоступности менеджера по некото­рой причине репозитории сохраняют ее в течение еще 60 дней. Если по окончании

172 Глава8

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

Частичный репозиторий поддерживает сведения лишь о тех менеджерах и объектах очередей кластера, которые ему интересны, в частности:

обо всех менеджерах с полным репозиторием, успешно подключившихся к клас­теру;

об объектах­очередях, входящих в кластер и одноименных объектам, обобщест­вленным менеджером очередей внутри кластера;

об объектах­очередях, входящих в кластер под именами, по адресу которых под­ключенные к менеджеру очередей приложения посылают сообщения;

о менеджерах с частичными репозиториями, под управлением которых находятся известные этому менеджеру объекты очередей.

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

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

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

Примечание.  Открываянеизвестнуювчастичномрепозиторииочередьсообщений,менеджерможетдо10секундждатьоткликаменеджераочередейсполнымрепозиторием.Еслиожиданиебезрезультатно,топриложение,котороепытаетсяпоместитьсообщениевочередь,будетневсостоянииэтосделать.Поэтойпричиневозможностьвлюбоймоментвремениустановитьсвязьхотябысоднимизполныхрепозиториевкластерачрезвычайноважна.

Подписки имеют ограниченный 30­дневный период существования, на протяжении которого частичный репозиторий автоматически получает от менеджеров с полным репозиторием обновления по подписке. По истечении 27 дней подписку требуется продлить. Однако менеджер продлевает ее только в том случае, если обращался к пуб­ликациям по подписке с того момента, как продлевал ее в прошлый раз. Иначе он не препятствует тому, чтобы срок подписки истек. Впрочем, если приложение в очеред­ной раз попытается открыть объект очереди, подписку можно инициировать вновь.

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

Кластерыменеджеровочередей 173

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

Репозиторий менеджера поддерживается входящим в менеджер очередей соответ­ствующий компонент, называемый менеджером репозитория. Он управляет подпис­ками и отсылает публикации полным репозиториям внутри кластера.

Данный механизм обеспечивает баланс между числом подписок, которые должен поддерживать полный репозиторий, и «знаниями» частичных репозиториев, позво­ляющими приложениям эффективно обращаться к объектам­очередям.

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«Подпискиипубликациивкластере».

174 Глава8

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)

Кластерыменеджеровочередей 175

Здесь 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, или быть подключенными к нему удаленно.

Примечание.  WebSphereMQExplorerнепоказываетинформациюокласте-рах,длякоторыхподключенныеизпапкиQueueManagersменеджерыочередейявляютсячастичнымирепозиториями.

Причинаэтоговтом,чтоменеджерысчастичнымрепозиториемнесодержатдостаточносведенийокластередлятого,чтобынадежноустановитьинформа-циюобовсехменеджерахочередейвнем,какбылосказановразделе8.1.9«Подпискиипубликациивкластере».

Под каждым из значков кластера в навигаторе будут отображаться две папки.

Full Repositories.

Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, кото­рые входят в кластер и содержат его полные репозитории. Значок каждого менед­жера очередей с полным репозиторием кластера расположен уровнем ниже.

Partial Repositories.

Щелкнув по этому узлу, вы увидите сводную страницу данных о менеджерах, кото­рые входят в кластер и содержат его частичные репозитории. Значок каждого менеджера очередей с частичным репозиторием кластера расположен уровнем ниже.

Папка Queue Manager Clusters в WebSphere MQ Explorer показана на рис. 8.1. Взятый как пример кластер содержит четыре менеджера, локально работающих на машине с WebSphere MQ Explorer. Два менеджера содержат полный и два – частичный репози­торий.

176 Глава8

Рис . 8 .1 . ПапкаQueueManagerClustersвWebSphereMQExplorer

Если к WebSphere MQ Explorer подключено несколько менеджеров очередей с пол­ными репозиториями одного кластера, WebSphere MQ Explorer выбирает один из них, чтобы сформировать содержимое папок кластера – Full Repositories и Partial Reposito­ries. Используемый для этого менеджер называют источником кластерной инфор-мации.

Все полные репозитории менеджеров содержат идентичную информацию, о чем упоминалось в разделе 8.1.9 «Подписки и публикации в кластере». Тем не менее, если менеджер отключается от сети, или ведущие к нему кластерные каналы блокируются, в его полном репозитории может оказаться не вся необходимая информация о менеджерах очередей кластера. В этих условиях источником кластерной информа­ции может стать другой менеджер, также содержащий полный репозиторий и под­ключенный из папки Queue Managers. Для его выбора выделите значок кластера в навигаторе и щелкните по кнопке Select на странице содержимого Cluster.

Просмотр репозитория единичного менеджера

После запроса источника кластерной информации для получения сведений о менед­жерах очередей – членах кластера на экран может быть выведена информация из частичного или полного репозитория каждого входящего в кластер менеджера.

Если в папках Full Repositories или Partial Repositories определенного кластера выбрать конкретный менеджер, откроется страница содержимого с информацией, которую данный менеджер содержит в своем репозитории.

Кластерыменеджеровочередей 177

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

Если в папке Queue Managers удаленный менеджер не показан, хранящуюся в его репозитории информацию о кластере вы все же можете просмотреть. Значок менед­жера будет изначально вам недоступен, а представленные таблицы не будут содер­жать данных. Для установления через кластер соединения с этим менеджером и вы­вода информации на экран щелкните правой кнопкой по недоступному значку менеджера в папке Partial Repositories или Full Repositories кластера в навигаторе и выберите Connect To Queue Manager.

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

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

Command server not responding within timeout period. (AMQ4032)

Отображаемая после успешного подключения к менеджеру информация на странице содержимого репозитория делится на три вкладки.

Cluster Queues.

Содержит сведения обо всех совместно используемых кластерами экземплярах объ­ектов­очередей, о которых известно менеджеру. Информация идентична той, которая выводится на экран при запуске для данного менеджера команды MQSC DISPLAY QCLUSTER.

Каждый разделяемый внутри кластера экземпляр объекта очереди называют клас-терной очередью (cluster queue). Заметим, что, как показано в разделе 8.4 «Баланси­ровка нагрузки», для упрощения балансировки нагрузки в пределах кластера обоб­ществленными среди ряда менеджеров очередей сообщений могут считаться несколько кластерных очередей с одним именем. Каждая запись о такой очереди содержит сведения о типе объекта очереди, менеджере, управляющем ею в кластере, а также о том, могут ли приложения помещать в нее сообщения или очередь заблоки­рована на запись.

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

178 Глава8

Каждой кластерной очереди в таблице отведено по строке. Столбцы таблицы пока­зывают атрибуты записи данных о такой очереди. Дважды щелкнув по самой записи, вы увидите атрибуты записи в окне свойств.

Примечание.  Менятьзначенияатрибутовобъекта,представленногозаписьюокластернойочереди,изокнасвойствнельзя.Этосправедливоидлятехслучаев,когдаменеджерподключенкWebSphereMQExplorerизпапкиQueueManagers.

Чтобыизменитьатрибуты,обязательноподключитеменеджерочередейсообще-нийкWebSphereMQизпапкиQueueManagers.ЗатемвыберитевнавигаторепапкуQueuesконкретногоменеджераидваждыщелкнитепоразделяемомувкластереобъектуочередивтаблице.

Cluster­sender channels.

Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для всех удаленных менеджеров очередей кластера. Это записи обо всех известных данному менеджеру очередей сообщений менеджерах очередей в кластере, для связи с которыми он использует кластерный sender­канал. Типы таких каналов мы обсуждали в разделе 8.1.6 «Кластерные sender­каналы».

Для каждого менеджера очередей в кластере, известного текущему менеджеру, в таблице отводится по строке. Каждой строкой таблицы представлен направлен­ный к менеджеру, работающий или способный работать кластерный sender­канал. Это – запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке. Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 «Просмотр сведений из репозитория через MQSC».

Примечание.  Менятьзначенияатрибутовлюбыхканальныхобъектов,ккоторымотносятсязаписикластерныхменеджеровочередей,изокнасвойствнельзя.Этосправедливоидлятехслучаев,когдаменеджерподключенкWebSphereMQExplorerизпапкиQueueManagers.

Обсуждаемыездесьзаписи,хотяипоказываюткластерныеsender-каналы,какправило,представляютавтоматическизаданныеканалы,созданныенаосновекластерныхreceiver-каналов,которыеописаныменеджеромочередейсообщенийприподключенииккластеру.Подробнееобэтомсм.вразделе8.1.5«Кластерныеreceiver-каналы».Вручнуюобъекты–кластерныеsender-каналысоздаютсятолькоприподключенииккластерудлясвязисполнымрепозиториемтакового.Подробностисм.вразделе8.1.6«Кластерныеsender-каналы».

Кластерыменеджеровочередей 179

Cluster­receiver channels.

Содержит ту же информацию, что экранная выдача команды MQSC DISPLAY CLUSQMGR, выполненной для локального менеджера. Обычно это всего одна запись. Она содержит ту информацию, которая была опубликована менеджером очередей сообщений при подключении к кластеру и является описанием кластерного receiver­канала. Подробности читайте в разделе 8.1.5 «Кластерные receiver­каналы».

Обычно эта таблица содержит одну строку, которая свидетельствует о публикации данным менеджером единственного объекта – кластерного receiver­канала. Это запись кластерного менеджера очередей. Она содержит детальные сведения о состоянии канала и менеджере очередей сообщений, в том числе его QMID и информацию о том, является ли он полным репозиторием кластера. Столбцы таблицы обеспечивают подробное представление, доступ к которому в окне свойств осуществляется двойным щелчком по строке. Дальнейшие сведения о записях кластерных менеджеров очередей, которые содержит данная вкладка, см. в разделе 8.2.1 «Просмотр сведений из репозитория через MQSC».

Примечание.  Менятьзначенияатрибутовканальногообъекта,ккоторомуотноситсязаписькластерногоменеджераочередей,изокнасвойствнельзя.Этосправедливоидлятехслучаев,когдаменеджерподключенкWebSphereMQExplorerизпапкиQueueManagers.

Применениекластерныхreceiver-каналовприподключенииккластерумыобсуж-даливразделе8.1.5«Кластерныеreceiver-каналы».

8 .3 . Работа с менеджерами очередей в кластереЭтот раздел главы посвящен описанию общих действий, выполняемых в ходе адми­нистрирования или создания кластера менеджеров очередей сообщений. Процедура администрирования относительно несложна, однако чтобы остальные менеджеры очередей в кластере не содержали ложную информацию о данном менеджере очере­дей сообщений, а подключение к нему в кластере возможно установить, должна пра­вильно выполняться.

8 .3 .1 . Приостановка и возобновление работы менеджера очередей в кластере

Приостановка работы менеджера очередей в кластере отлична от его удаления. В результате приостановки доставка сообщений очередям, совместный доступ к которым в кластере организует текущий менеджер, становится практически невоз­можной. Она существенно сокращает вероятность того, что контролирующий работу остальных менеджеров алгоритм балансировки нагрузки выберет доставку сообще­ний очередям текущего менеджера. Вопросы балансировки нагрузки мы обсудим в разделе 8.4 «Балансировка нагрузки».

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

После выполнения приостановки работу менеджера можно снова возобновить.

180 Глава8

Чтобы произвести приостановку или возобновление работы менеджера очередей в кластере, используйте один из следующих методов.

Для целей приостановки или возобновления работы менеджера очередей в одном кластере – команды 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, где нужно щелкнуть правой кнопкой мыши по значку менеджера очередей интересующего вас кластера.

Примечание.  Предпринимайтеэтодействиетолькопослепрочтениясоот-ветствующихразделовруководстваWebSphereMQQueueManagerClusters,SC34-6589.Особуюаккуратностьследуетпроявить,есливашаработазатрагива-етменеджерыочередейсполнымрепозиториемкластера.

8 .3 .3 . Этапы подключения менеджера очередей к кластеруОпишем в этом разделе ручные операции добавления менеджера в существующий кластер или формирования нового. Для кластеров, не использующих списки имен в определениях каналов или атрибутах репозиториев менеджеров, перечисленные здесь действия также можно осуществить при помощи мастеров WebSphere MQ Explorer.

Кластерыменеджеровочередей 181

С применением мастеров 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­адрес машины с менеджером и порт, на кото­рый настроен слушатель. Если эти шаги касаются одного из пары исходных менеджеров очередей с полным репозиторием, то речь идет о названии соедине­ния с другим менеджером очередей сообщений, который содержит – или может содержать – полный репозиторий кластера.

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

182 Глава8

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­канала на менеджере очередей с полным репозиторием.

Кластерыменеджеровочередей 183

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

6. Наконец, менеджер очередей сообщений становится членом кластера и, пользуясь атрибутами «кластер» (CLUSTER) и «список названий кластеров» (CLUSNL) объектов, может организовывать общий доступ к объектам­очередям в кластере. При этом существующие объекты­очереди могут меняться, а новые – определяться впервые.

Примечание. ДоуспешногоокончанияпроцессаподключенияккластерувэкраннойвыдачекомандDISPLAYCLUSQMGRипапкеClustersвWebSphereMQExplorerвыувидитеэлементывида:

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.

Операции, выполняемые вручную

Чтобы вручную удалить менеджер из кластера менеджеров, произведите следующую работу.

184 Глава8

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­канала объект­список так, чтобы исключить данный кластер из пе­речня.

Кластерыменеджеровочередей 185

5. Выполните команду останова канала объекта – кластерного receiver­канала, кото­рый применялся при подключении менеджера очередей к кластеру. К примеру, в MQSC используйте следующую команду:

STOP CHANNEL('TO.QmgrName’)

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

6. Если на протяжении этих этапов атрибут «кластер» или «список названий класте­ров» был очищен, а потребности в кластерном receiver­канале для повторного подключения менеджера очередей к кластеру не возникнет, объект – кластерный receiver­канал может быть удален.

7. Если послуживший для подключения кластерный sender­канал использовался для подключения менеджера очередей только к одному кластеру, на этом шаге он может быть остановлен и удален. В противном случае для удаления ссылки на кластер из определения кластерного sender­канала или списка имен, в которых она содержится, следуйте процедуре, описанной для кластерного receiver­канала.

8. Выполните команду обновления кластера, из которого удаляется менеджер. Тем самым вы гарантируете очистку информации о кластере из репозитория этого менеджера очередей.

Примечание.  Еслипокидающийкластерменеджерсодержитполныйрепози-торий,возможносуществованиеведущихкэтомуменеджеру,явноописанныхчастичнымирепозиториямикластерныхsender-каналовсообщений.Вэтомслучаеопишитенаменеджерахчастичныхрепозиториевновыеобъекты–кластерныеканалы,направленныекоставшемусяполномурепозиториюкластера,иудалитестарыйобъект–кластерныйsender-канал.Иначетакиеменеджерынесмогут,еслипотребуется,покинутькластерисновавойтивнеговбудущем.ВчислепрочихдействийвыполнитекомандуREFRESH CLUSTERспараметромREPOS(YES).

8 .4 . Балансировка нагрузкиМощнейшей из возможностей кластеров является балансировка нагрузки. Она дает возможность разместить службу в составе нескольких менеджеров очередей внутри кластера, распределяя запросы от обращающихся к ней приложений по экземплярам службы, – прозрачно для работы программ.

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

186 Глава8

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

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

Чтобы воспользоваться преимуществами балансировки нагрузки, особой настройки кластера не потребуется. Чтобы добавить в кластер экземпляр службы, подключите новый менеджер очередей, после чего откройте совместный доступ к очереди, пред­ставляющей службу, распознаваемую по имени очереди. Все менеджеры очередей внутри кластера, которые обращались – или в будущем обратятся – к названию этой очереди из кластера, автоматически получили или получат уведомление о вновь созданном экземпляре. С момента уведомления об экземпляре менеджеры могут посылать ему сообщения.

Выбор определенного экземпляра, которому будет адресовано сообщение, осуществ­ляется менеджером, обычно с частичным репозиторием, к которому подключено приложение­отправитель.

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

Чтобы получить преимущества от балансировки нагрузки, приложение не должно задавать название конкретного менеджера при открытии очереди функцией MQOPEN.

Примечание.  Еслиприоткрытииочерединазваниеменеджерауказано,товцеляхбалансировкинагрузкиможновоспользоватьсяописаннымивразделе8.1.7«Совместныйдоступкобъектам-очередямвкластерах»объектами-очередя-мисообщений.Такчастоипоступаютссообщениями,приходящимиотменедже-ровочередейизвнекластера,когдаагент-получательоткрываеточередь,пользу-ясьназваниемменеджера,заданнымвзаголовкетранспортнойочереди.

8 .4 .1 . Работа с привязкой при открытии и без фиксированной привязки

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

Нередко каждое сообщение может направляться различным экземплярам упомяну­той службы, и это не окажет отрицательного воздействия на работу программы, инициировавшей запрос. Если служба­получатель сообщений действует по модели «запрос – ответ», каждое посланное отправителем сообщение содержит явное указа­ние на то, кому конкретно служба должна ответить, и контекста в ее работе не требу­ется. Такой порядок функционирования очень эффективен с позиции балансировки

Кластерыменеджеровочередей 187

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

Однако ведущийся двумя приложениями обмен может иметь характер диалога по схеме «запрос – ответ – запрос и т. д.», которая основана на контексте, сформирован­ном предыдущими сообщениями. Взаимосвязь между ними называют сродством сообщений (message affinity). При наличии такового приложению может понадобить­ся привязка (bind) к конкретному экземпляру службы в составе кластера. Для обеспе­чения привязки приложение может явно указать одну из двух опций менеджера при открытии очереди.

Привязка при открытии.

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

Без фиксированной привязки.

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

Поведение по умолчанию определяется атрибутом «привязка по умолчанию» (DEFBIND – default bind) экземпляра очереди сообщений, входящего в состав кластера и выбранного при вызове MQOPEN . Этот атрибут задается в объекте очереди, разде­ляемом внутри кластера и расположенном на менеджере, который создал этот объект и обеспечил совместный доступ к нему из кластера.

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

8 .4 .2 . Алгоритм балансировки нагрузкиКаждый раз, когда менеджер выбирает место назначения сообщений в кластере по наз­ванию очередей, вызывается встроенный в него алгоритм балансировки нагрузки.

Упрощенно – при настройках по умолчанию и успешном установлении канала к каждому менеджеру очередей внутри кластера – балансировку нагрузки можно рас­сматривать как круговое распределение сообщений. В результате если приложение без привязки разместило 1000 сообщений, а на 10 кластерных менеджерах размеще­но 10 одноименных очередей, то приложениям на этих очередях под управлением каждого из 10 менеджеров поступит около 100 сообщений.

Впрочем, эта оценка не точна и зависит от многих факторов. В этом разделе мы только в общих чертах опишем, как работает алгоритм балансировки нагрузки и как можно его настроить, используя возможности WebSphere MQ V6.0. Подробности

188 Глава8

процесса выработки решения алгоритмом при каждом вызове такового читайте в ру­ководстве WebSphere MQ Queue Manager Clusters, SC34­6589.

8 .4 .3 . Порядковые номера мест назначения сообщенийДля выполнения кругового алгоритма балансировки менеджер очередей сообщений локально хранит порядковый номер места назначения сообщения для каждого извест­ного ему кластерного менеджера очередей.

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

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

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

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

Однако существует ряд других обстоятельств, влияющих на работу алгоритма баланси­ровки нагрузки. Обсуждению таких факторов мы и посвятим окончание этой главы.

Расположим влияющие на алгоритм факторы в том порядке, в котором их анализи­рует алгоритм. Порядковый номер места назначения сообщения окажется в этом случае лишь последним, поскольку он обеспечивает балансировку только для подхо­дящих мест назначения – «кандидатов».

Примечание.  КонтрольпорядковыхномероввовремяегоработыведетсяменеджеромочередейсообщенийWebSphereMQV6.0.Задачаменеджера–учитыватьпроисходящиеизменения,кпримерувозобновлениеработыменедже-ровочередейвнутрикластера.Сброспорядковыхномероввсехканаловбезисключенияможнопринудительнопровести,перезапустивменеджер.

8 .4 .4 . Блокировка очереди на записьЕсли обобществленная в кластере очередь блокирована на запись, информация об этом публикуется и передается всем заинтересованным в ней менеджерам очере­дей кластера.

Кластерыменеджеровочередей 189

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

Примечание. Еслисообщенияявнопередаютсяданномуменеджеру,аника-кихпрочихдоступныхэкземпляровочередейссоответствующимназваниемвкластерененаходится,сообщениядоставляютсяэтомуменеджеру.Ихобработ-койзанимается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) объекта­очереди, обобществленного внутри кластера. Алгоритмом балансировки ранг отдельных очередей принимается во внимание после анализа ранга менеджеров.

Ранжирование способно принудительно выбрать итоговое место назначения в клас­тере. Оно полезно в процессе объединения нескольких кластеров и описания соеди­няющих их маршрутов. Ранжирование полезно для описания порядка маршрутиза­

190 Глава8

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

8 .4 .7 . Приостановка менеджеров очередей в кластереЕсли входящий в кластер менеджер приостановлен, как это описано в разделе 8.3.1 «Приостановка и возобновление работы менеджера очередей в кластере», то алго­ритм балансировки нагрузки выбирает другие менеджеры, предпочитая их данному.

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

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

8 .4 .8 . Состояние каналаПредпочтение перед другими при выборе имеют экземпляры очередей менеджеров, каналы к которым уже запущены или стали естественно неактивны.

Если такие экземпляры не обнаружены, выбираются экземпляры под управлением тех менеджеров, каналы к которым находятся в процессе установления.

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

Если экземпляры очередей находятся только в составе менеджеров, каналы к кото­рым требуют перезапуска ручным способом, включая остановленные каналы, сооб­щения должны отсылаться подобным менеджерам и оставаться в транспортной оче­реди, пока ручной запуск каналов не будет произведен.

Такое поведение позволяет автоматически обходить сбои отдельных кластерных менеджеров.

8 .4 .9 . Приоритет менеджеров и очередей сообщенийВ WebSphere MQ V6.0 менеджерам очередей внутри кластера может назначаться прио­ритет, для чего задается или меняется атрибут «приоритет кластерной балансировки нагрузки» (CLWLPRTY – cluster workload priority) кластерного receiver­канала, который был использован менеджером для подключения к кластеру.

Экземплярам очередей под управлением менеджера с бо ' льшим приоритетом при выборе обычно отдается предпочтение над экземплярами очередей менеджера с меньшим приоритетом.

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

Кластерыменеджеровочередей 191

Приоритет отдельных экземпляров очередей может устанавливать атрибут «приори­тет кластерной балансировки нагрузки» (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­канала, который был использован менеджером для подключения к кластеру.

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

Для получения этого результата алгоритм увеличивает порядковые номера мест назначения всех менеджеров на значение, привязанное к их весу. Чем выше вес менед­

192 Глава8

жера, тем меньше прибавляет алгоритм к номеру, отправляя каждое сообщение. Вели­чина приращения есть частное от деления 1000 на вес определенного менеджера.

К примеру, пусть нам доступны два менеджера очередей сообщений с весами 60 и 20, а номера мест назначения одинаковы. Между очередями с одним названием под управлением этих менеджеров распределим четыре сообщения. Три из них будут адресованы менеджеру, вес которого 60, и лишь одно – менеджеру, вес которого 20. Причина этого в том, что оба номера назначения станут больше на 50:

(1000 / 60) × 3 = 50;

(1000 / 20) × 1 = 50.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 193

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

194 Глава9

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 для внесения любых изменений в производственной среде.

Примечание. ЗдесьидалееиспользуютсяименавнижнемрегистрекакоптимальныедляадминистрированиясприменениемWebSphereMQExplorer.

Следите, чтобы в командах MQSC значения атрибутов и имена объектов, содержащие символы в нижнем регистре, были заключены в одинарные кавычки. Регулярное применение кавычек – общая рекомендация при работе с MQSC, позволяющая избе­жать путаницы.

9 .1 .2 . Программы-примеры в WebSphere MQ С WebSphere MQ поставляется множество программ­примеров, как в виде исходного кода, так и в прекомпилированном, готовом к применению виде. В этой книге приво­дятся примеры на языке программирования С, использующие интерфейс очередей сообщений (MQI) для демонстрации межточечного обмена сообщениями. Имеются также аналогичные примеры на других языках программирования.

Примеры на языке Java, использующие JMS – стандартный интерфейс прикладного программирования (API), – иллюстрируют обмен сообщениями по механизму пуб­ликации­подписки. По большому счету то же верно для клиентов IBM Message Service (XMS).

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 195

Обмен сообщениями по подписке также может быть реализован при помощи соот­ветствующих команд 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.

Примечание. ЕсливыработаетесWebSphereMQнаLinux-сервере,следуйтеотдельныминструкциям,приведеннымниже.

9 .2 .1 . Установка WebSphere MQ �6 .0Подробнее об установке сервера WebSphere MQ см. в руководстве WebSphere MQ V6.0 Quick Beginnings для соответствующей платформы:

WebSphere MQ для Windows V6.0 Quick Beginnings, GC34­-64­76

WebSphere MQ для Linux V6.0 Quick Beginnings, GC34­-64­80

Установите все необходимые и дополнительные компоненты, сделайте необходимые настройки.

9 .2 .2 . Привилегии администратора WebSphere MQ Учетная запись, под которой вы входите в систему, должна иметь привилегии адми­нистратора WebSphere MQ.

В Windows: ваша учетная запись должна быть членом одной из следующих групп:

– Administrators,

– mqm.

В UNIX: ваша учетная запись должна быть членом группы

– mqm.

9 .2 .3 . Доступ к примерам WebSphere MQ Каталог с примерами WebSphere MQ должен быть в пути поиска, заданном соответст­вующей переменной окружения в ОС. При установке WebSphere MQ в Windows это делается автоматически.

196 Глава9

Примеры 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.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 197

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.

ПараметрAutostartменеджераочередейподдерживаетсятольковWindowsипозволяетавтоматическизапуститьменеджерочередейприперезагрузкекомпьютера.

7. Для остальных полей оставьте значения по умолчанию и щелкните Next, не щелкая Finish, – откроется страница Enter listener options (Step 4).

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

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вэтомокне,можнопросматриватькомандыWebSphereMQ,исполняякоторыеWebSphereMQExplorerсоздаетменеджерочередей.Приэтомпослезавершенияустановки(выводомсообщенияFinishedвглавномокне)окносостоянияследуетзакрытьвручную.

12. Завершив это упражнение, убедитесь, что в окне навигатора в папке Queue Manag­ers отображается менеджер очередей в виде значка, соответствующего останов­ленному локальному менеджеру очередей.

198 Глава9

Применение управляющих команд 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

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 199

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

ВWebSphereMQдляWindowsV5.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.

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

ПрименениеWebSphereMQExplorer(вWindows):

a) щелкнитеправойкнопкой IBM WebSphere MQвокненавигатораивыберитеProperties;

b) проверьтеипринеобходимостиотредактируйтеполеDefaultqueuemanagername.Внемдолжнобытьследующеезначение:

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

200 Глава9

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.

Теперь сеанс готов к приему ввода, дополнительное сообщение о запуске сеанса не отображается.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 201

Примечание. Еслименеджерочередейнезапустилсяилиненазначенменеджеромпоумолчанию,генерируетсяследующийвыводиотображаетсяобычноеприглашениеОС:

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 (непостоянные). Зна­

202 Глава9

чение неизменяемого атрибута 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)

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 203

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

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

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. Обратите внимание на изменение атрибута­описания объекта локальной очереди в таблице очередей.

204 Глава9

Применение команд 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, чтобы закрыть окно.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 205

Применение программы-примера для WebSphere MQ

Примечание. ПутьккаталогуспримерамипрограммдляWebSphereMQдолженбытьдобавленкпутипоискавпеременныхокруженияОС.

Выполните следующие действия.

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 AMQSPUT0 start

target queue is QUEUE1

MQOPEN ended with reason code 2085

unable to open queue for output

Sample 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.Подробнееокодахвозвратасм.вразделе«APIcompletionandreasoncodes»руководстваWebSphereMQMessages,GC34-6601.

9 .3 .7 . Просмотр сообщений, добавленных в очередь Здесь рассказывается, как осуществляется просмотр сообщений, находящихся в дан­ный момент в очереди WebSphere MQ, без их удаления. Для просмотра доступно как содержимое сообщений, так и сведения о них, хранимые в дескрипторах сообщений.

206 Глава9

Сообщения, добавляемые в очередь, являются непостоянными (nonpersistent messag-es). В поле 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.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 207

MsgType : 8

Тип 8 соответствует дейтаграммам. Запросы имеют тип 1, ответы – 2, отчеты – 4.

Persistence : 0

Значение «0» свидетельствует о том, что сообщение является непостоянным, а значе­ние «1», напротив, говорит о том, что это сообщение является постоянным.

ReplyToQ : ‘ ‘

В этом поле отображается 48­значное имя очереди ответов (reply­to queue). Если в имени меньше 48 символов, недостающие символы заменяются пробелами, распо­ложенными справа. Такие данные называются дополненными пробелами (blank- padded), они часто используются в структурах WebSphere MQ. В этом примере данное поле в дескрипторе сообщений пусто.

ReplyToQMgr : ‘host1/qm1 ‘

Это поле содержит 48­значное дополненное пробелами имя менеджера очереди ответов (reply­to queue manager), оно автоматически заполняется менеджером очере­дей при размещении сообщения.

**** Message ****

length – 20 bytes

00000000: 5265 6462 6F6F 6B20 7465 7374 206D 6573 ‘Redbook test mes’

00000010: 7361 6765 ‘sage ‘

Здесь отображается содержимое сообщения в двоичном и (справа) в текстовом пред­ставлении. Это существенно облегчает просмотр содержимого некоторых типов сообщений, особенно объемных, которые проще просматривать в двоичном пред­ставлении. Впрочем, содержимое простых тестовых сообщений из наших примеров как раз удобнее просматривать в текстовом представлении.

9 .3 .8 . Определение и использование псевдонимов локальных очередей

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

Атрибуты объекта псевдонима очереди определяют параметры по умолчанию, с кото­рыми сообщения добавляются в очередь, на которую ссылается псевдоним (его целе­вую очередь). Так, ниже показано, что если настроить для псевдонима свойство persistent, то сообщения, добавленные через этот псевдоним, будут постоянными.

Примечание. Вданномпримередлянаглядностиводнуитужеочередьдобавляютсясообщениядвухтипов:постоянныеинепостоянные.ОднаковWebSphereMQболееэффективныочередиссообщениямиодноготипа,поэтомусмешиватьпостоянныеинепостоянныесообщенияводнойочерединерекомен-дуется.

208 Глава9

Применение 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.

Примечание. Врезультатеэтогодействиябудетзаданатрибут«целеваяочередь»(targetqueue,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водинарныекавычки.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 209

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.

Примечание. Управляемоезавершение(controlledend)менеджераочередейвWebSphereMQExplorerаналогичнозавершениюкомандойendmqm ивыпол-няет«плавную»остановкусвыводомокнасостояниядоокончанияостановкименеджераочередей.

3. Дождитесь завершения остановки (см. окно состояния).

Заметьте, что теперь для менеджера очередей отображается значок остановленно­го локального менеджера очередей.

4. Перезапустите менеджер очередей, щелкнув его правой кнопкой и выбрав коман­ду Start. Дождитесь завершения запуска (см. окно состояния).

5. Изучите содержимое очереди queue1. Обратите внимание, что в ней остались лишь постоянные сообщения, добавленные ранее при помощи псевдонима очереди.

210 Глава9

Применение управляющих команд 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.

Однакотакиенастройкинеэквивалентныиспользованиюпостоянныхсообщений.WebSphereMQнерегистрируетвжурналеоперациинаднепостояннымисообще-ниямииневосстанавливаетихпослесбоевменеджераочередей.Следовательно,сообщениявочередяхклассаHighвсеравномогутбытьпотеряны.Поэтомуданные,критичныедлябизнеса,непременнодолжныбытьпомеченыкакпостоян-ные.

9 .3 .10 . Извлечение сообщений из очереди Ниже рассказывается, как извлечь сообщения из очереди WebSphere MQ, при этом извлекаемые сообщения удаляются из очереди. Любое сообщение может быть успеш­но извлечено из очереди только одним приложением. Разберем это с использовани­ем программ­примеров для WebSphere MQ.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 211

Выполните следующие действия:

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.

212 Глава9

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

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 213

Примечание. Помните:имя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) через псевдоним менеджера очередей.

214 Глава9

Примечание. Еслиуничтожитьобъектудаленнойочереди,представляющийпсевдонимменеджераочередей,невернозадатьимяменеджераочередей(оночувствительнокрегистру)либозначениеатрибутаудаленнойочередиилидопуститьошибкупривызовекомандыamqsput,вызовMQOPENзавершитсяскодом2087MQRC_UNKNOWN_REMOTE_Q_MGR.

2. Просмотрите содержимое queue1. Вы увидите, что сообщения доставлены в оче­редь queue1, обслуживаемую менеджером host1/qm1, включая сообщения, пере­данные через псевдоним host1/qm1.alias.

9 .3 .14 . Удаление менеджера очередей Ниже демонстрируется удаление менеджера очередей. Менеджер очередей удаляется вместе со всеми его очередями и сообщениями, восстановление их средствами Web­Sphere MQ невозможно. Эта операция осуществляется при помощи WebSphere MQ Explorer либо управляющей команды dltmqm.

Примечание. Командаdltmqm WebSphereMQнезапрашиваетподтвержде-ниепередудалениемменеджеровочередей,отменитьеетакженевозможно.Поэтомупользуйтесьданнойкомандойсосторожностью.

Применение 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

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 215

Примечание. Подобнокоманде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

216 Глава9

– в 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.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 217

Применение команд 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

218 Глава9

Примечание. СледитезарегистромименочередейвMQSCиWebSphereMQExplorer,атакжепараметровэтойкоманды.Привозвратенеожиданногокодазавершениявоспользуйтеськомандой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 Mes-sages.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 219

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.

220 Глава9

Применение команд 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.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 221

Применение команд 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.

222 Глава9

Выполните следующие действия.

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

«

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 223

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

Примечание. Есливыстолкнулисьструдностями,проверьтеатрибутывсехобъявленныхранееобъектов,атакжерегистрименобъектов,параметрыкоманд(включаяпараметрытриггерногомонитораWebSphereMQ).

9 .4 .11 . Создание объекта модельной очереди для динамической очереди ответов

Ниже освещается определение объекта модельной очереди для создания временных динамических очередей ответов. Динамическое создание очередей ответов выполня­

224 Глава9

ет программа 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

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 225

Программа генерирует следующий вывод:

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 . ОтображениевременныхочередейвWebSphereMQExplorer

iii. Обратите внимание на идентичность описания динамической очереди и объекта модельной очереди, на основе которого она создана.

Примечание. Временныединамическиеочереди,именакоторыхначинаютсясAMQ.MQEXPLORER,созданыWebSphereMQExplorerнаосновемодельнойочередиSYSTEM.MQEXPLORER.REPLY.MODEL.WebSphereMQExplorerиспользуетинтерфейсзапросовиответов,поддерживаемыйкоманднымисерверамименеджеровочередей.

– С помощью команд MQSC.

i. Выполните следующую команду MQSC в отношении менеджера host1/echo.hub:

DISPLAY QL('AMQ.*') DEFTYPE DESCR

ii. Заметьте, что значение атрибута «описание» (DESCR) динамической очере­ди идентично описанию объекта модельной очереди, на основе которого была создана эта очередь.

226 Глава9

3. Заметьте, что с приложением amqsreq работают так же, как с очередью, объявлен­ной вручную.

4. Обратите внимание, что после завершения приложения amqsreq временная дина­мическая очередь удаляется автоматически.

Примечание. Приложение-примерamqsreqнеподдерживаетпостоянныединамическиеочереди,посколькуононепозволяетуказатьпараметры,необхо-димыедляудаленияочередипослетого,каконабудетзакрыта.Однакоможнопоэкспериментироватьсмодельнымиочередями,объявленнымикакпостоянныединамическиеочереди(типопределения–PERMDYN),ипрограммойamqsreq.ВременныеочередиэтоготипанеобходимоудалятьвручнуюспомощьюWebSphereMQExplorerиликомандMQSC.

9 .5 . Рассылка сообщений по подписке в WebSphere MQ с помощью JMS

В этом разделе демонстрируется применение брокера публикации­подписки (publish/subscribe broker) WebSphere MQ с примерами кода для WebSphere MQ JMS (Java Message Service).

Примечание. ДляизученияэтогоразделанеобходимоустановитьпакетJavaDevelopmentKit(JDK).JDK1.4.2находитсявкаталогеPrereqsнаустановочномносителеWebSphereMQV6.0.

КаталогсисполняемымифайламиjavaиjavacизJDKнеобходимодобавитькпутиОС.

ПримеркодадляWebSphereMQJMSпотребуетсяслегкаизменить,азатемскомпилировать.ОднакознатьязыкпрограммированияJavaдляэтогонеобяза-тельно.

9 .5 .1 . Настройка среды JMSСоздайте на компьютере, на котором предполагается работать с примерами кода, каталог – в нем будут размещены все файлы и каталоги, необходимые для выполне­ния описанных ниже действий. Все команды и терминальные сеансы должны рабо­тать с этим каталогом.

Исполняющая среда Java Runtime Environment (JVM), в которой работают Java­при­ложения, ищет скомпилированные компоненты Java­приложений в каталоге class path, заданном соответствующей переменной окружения.

При установке WebSphere MQ в Windows путь к компонентам, необходимым для ис­полнения приложений WebSphere MQ JMS, автоматически добавляется к переменной пути к классам Java, а на платформах UNIX это придется сделать вручную с помощью текущей оболочки.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 227

Далее предполагается, что независимо от платформы рабочий каталог добавлен в путь к классам 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

228 Глава9

Примечание. Еслипривыполненииописанныхнижеупражненийвыстолкну-лисьсошибками,например:

Exception in thread «main» java.lang.NoClassDefFoundError

попробуйтеустранитьих,выполнивследующиедействия.НастройтепеременныеокруженияCLASSPATHвручную,напримертак.

ВUNIX(кромеAIX5L):

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

ВAIX5L:

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.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 229

Применение 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 . ОтображениесистемныхобъектоввWebSphereMQExplorer

Применение команд MQSC

Выполните следующие действия.

1. Чтобы настроить брокер публикации­подписки WebSphere MQ для запуска вместе с менеджером очередей, выполните следующую команду MQSC в отношении менеджера host1/jmspubsub:

ALTER SERVICE('SYSTEM.BROKER') CONTROL(QMGR)

2. Чтобы запустить брокер публикации­подписки, выполните следующую команду MQSC в отношении менеджера host1/jmspubsub:

START SERVICE('SYSTEM.BROKER')

230 Глава9

9 .5 .4 . Настройка менеджера очередей для работы с JMSWebSphere 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 с целью подго­товки содержимого созданного ранее каталога файловой системы.

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 231

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

232 Глава9

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» );

ОбменсообщениямисиспользованиемWebSphereMQ:практическоевведение 233

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.

Примечание. Этиклавишинеобходимонажиматьпослеполучениякаждогосообщения.

234 Глава9

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

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 235

10

Построение инфраструктуры WebSphere MQ: практическое руководство

Изучая эту главу, вы дополните локальную инфраструктуру, созданную при изучении предыдущей главы. Вы научитесь создавать клиентские подключения к менеджерам очередей и выполнять удаленное администрирование при помощи WebSphere MQ Explorer. Вы также освоите построение центрально­лучевой инфраструктуры, созда­ние кластеров менеджеров очередей; вы увидите, как это облегчает администрирова­ние и предоставляет дополнительные возможности по балансировке нагрузки. Цент­рально­лучевая инфраструктура и кластеры менеджеров очередей – связанные поня­тия, они сообща используют различные службы.

В этой главе обсуждаются следующие темы:

Настройка окружения

Подключение к менеджеру очередей в режиме клиента

Построение центрально­лучевой инфраструктуры

Создание кластеров менеджеров очередей

236 Глава10

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.

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 237

10 .2 .1 . Создание и запуск слушателя Ниже рассказывается, как создать и запустить для менеджера очередей слушатель (listener), предоставляющий возможность идентификации в сети. В WebSphere MQ 6.0 слушатели являются объектами WebSphere MQ, объявленными в менеджере очередей. Эти действия можно выполнить при помощи WebSphere MQ Explorer или команд MQSC.

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

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

Если в системе работает единственный менеджер очередей, он обычно прослушивает порт 1414 – стандартный порт WebSphere MQ. В приведенных ниже инструкциях используется произвольный диапазон портов, который вряд ли будет занят другими менеджерами очередей и сетевыми службами.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Listeners в менеджере очередей и выберите New\TCP Listener.

Примечание. ПапкаListenersнаходитсявнутрипапкиAdvancedменеджераочередей(см.деревопапоквокненавигатора).

ЕслифлажокCreate listener configured for TCP/IPнастраницеEnterlisteneroptions(Step4)мастераCreateQueueManagerбылпомечен,объект-слушательLISTENER.TCPбылсозданавтоматически.

Вэтомслучаещелкнитеправойкнопкойобъект-слушательвтаблицеивыберитеStop.Послеостановкислушателящелкнитеегоправойкнопкой,выберитекомандуDeleteиподтвердитеудаление.

2. Введите LISTENER.TCP в поле name.

3. Щелкните Next.

4. Введите в поле Description следующий текст:

TCP/IP Listener for queue manager

5. Введите 9001 в поле Port.

238 Глава10

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

Примечание. ЕсливыиспользуетеWebSphereMQExplorer,отмечайтефлажокCreate listener configured for TCP/IPнастраницеEnterlisteneroptions(Step4)мастераCreateQueueManager,чтобыпринеобходимостиавтоматическисоздаватьобъекты-слушателивместесменеджерамиочередей.

Проверьте,свободенливыбранныйпорт,передщелчкомFinish.Порт,ккоторомупривязанобъект-слушатель,можноизменитьипослесозданияменеджераочередей.Послесменыпортанепременноперезапуститеслушатель.

10 .2 .2 . Создание объекта канала серверного подключенияОбъект канала серверного подключения определяет имя и атрибуты канала для кли­ентских подключений к менеджеру очередей.

Один из ключевых атрибутов, которые можно настроить для объекта канала сервер­ного подключения, – идентификатор локального пользователя, под которым удален­

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 239

ные приложения подключаются через канал, представленный данным объектом (обычно это идентификатор пользователя 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 . Подключение с использованием переменной окружения MQSER�ER

Клиентский канальный агент (message channel agent, MCA), доступный при работе с MQI напрямую (например, из приложений, написанных на С), может быть настроен при помощи переменных окружения. Базовые атрибуты, включая имя канала и под­ключения, настраиваются при помощи переменной MQSERVER.

Приложения, использующие базовый клиентский MCA , и те, что работают с менед­жером очередей напрямую, создают с применением разных наборов библиотек WebSphere MQ. Библиотеки, применяемые в первом случае, обычно называются кли-ентскими библиотеками WebSphere MQ.

С WebSphere MQ поставляются версии базовых программ­примеров, таких как amqsput, amqsget, amqsbcg, amqsreq и amqsech, скомпилированных с использовани­

240 Глава10

ем клиентских библиотек WebSphere MQ. Для вызова этих версий добавьте латинскую букву «c» к имени нужного приложения, например: amqsputc, amqsgetc, amqsbcgc, amqsreqc или amqsechc.

Примечание. КлиентскиеMCA,предназначенныедляиспользованиясдругимиAPI,такимикакJava,JMS,.NETиXMS,настраиваютсяпо-другому.Подробнееобэтомсм.вруководствеWebSphereMQпотому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проверьтесистемныежурналыошибокWebSphereMQименеджераочередей(см.раздел5.3.15).

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 241

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:

242 Глава10

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 («работает»).

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 243

Примечание. Чтобыполучитьдополнительныесведенияоподключении,щелкнитеправойкнопкойменеджерочередей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.

244 Глава10

Примечание. ДляудаленногоадминистрированияменеджеровочередейспомощьюWebSphereMQExplorerтребуется:

объект-слушатель,привязанныйкизвестномупорту;

объектканаласерверногоподключениясизвестнымименем;

работающийкомандныйсервер;

модельнаяочередьSYSTEM.MQEXPLORER.REPLY.MODEL.

ВWindowsиUNIXменеджерыочередей,созданныеприпомощиWebSphereMQV6.0,поумолчаниюимеютработающийкомандныйсерверинужнуюмодельнуюочередь.ОднакоменеджерыочередейвWebSphereMQверсии5.3инижетребуютручнойнастройкиэтихкомпонентов;тожевернодляменеджеров,созданныхвWebSphereMQV5.3иобновленныхдоWebSphereMQV6.0.Чтобывручнуюподготовитьнужныекомпоненты,выполнитеследующиедействия.

1. ВыполнитеследующуюкомандуWebSphereMQ,чтобывручнуюзапуститькомандныйсервердляменеджераочередей:

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/HideQueueManagersвWebSphereMQExplorer

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 245

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 . ЗапускмастераAddQueueManagerдляпрямогоподключениякменеджеруочередей

В результате выбранный менеджер очередей будет добавлен к таблице Shown Queue Managers в окне Show/Hide Queue Managers.

10. Щелкните Close в окне Show/Hide Queue Managers.

246 Глава10

11. Заметьте, что теперь этот менеджер очередей доступен в папке Queue Managers, подобно локальным менеджерам очередей. Имя подключения, добавленное к име­ни этого менеджера очередей, свидетельствует о том, что он является удален­ ным, а его значок отличается от значков локальных менеджеров очередей (см. рис. 10.3).

Рис . 10 .3 . УдаленноеадминистрированиеменеджераочередейвWebSphereMQExplorer

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)

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 247

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

248 Глава10

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

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 249

Для новых менеджеров можно увеличить число в имени 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.

250 Глава10

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.

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 251

Применение команд 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.

252 Глава10

Применение 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')

Примечание. Дляуспешнойактивацииканалаваженправильныйсинтаксисатрибутов.

10 .3 .8 . Отправка тестового сообщения по каналу центральному менеджеру очередей

Ниже рассказывается, как отправить по каналу тестовое сообщение центральному менеджеру очередей. В этом примере очередь­получатель сообщения будет задана вручную в менеджере host1/echo.hub, и локально задавать дополнительные сведе­ ния о получателе не потребуется. Локальный менеджер очередей может связаться с менеджером host1/echo.hub благодаря наличию транспортной очереди с соответст­вующим именем. Этот механизм позволяет отправлять ответы через инфраструктуру WebSphere MQ заданным очередям, обслуживаемым заданным менеджером оче­редей.

1. Выполните следующую команду WebSphere MQ и введите текст сообщений, пред­назначенных для отправки очереди, обслуживаемой центральным менеджером:

amqsput queue1 host2/spoke 8208 0 host1/echo.hub

Эту команду вызывают со следующими параметрами:

– queue1 – имя очереди в host1/echo.hub;

– host2/spoke – имя менеджера очередей, к которому требуется подключиться;

– 8208 – десятичный код параметров запроса, передаваемый при вызове MQOPEN (для данного примера этот параметр не важен, он требует открыть очередь для добавления сообщений и приводит к неудаче последующие

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 253

попытки добавления сообщений если менеджер очередей находится в процес­се остановки);

– 0 – отсутствие параметров при вызове MQCLOSE (для данного примера этот параметр не важен);

– host1/echo.hub – имя менеджера очередей, заданного при вызове MQOPEN. Представляет менеджер очередей, который используется в этом примере. Вид­но, что его значение соответствует именам удаленного менеджера очередей и транспортной очереди, применяемой менеджером host2/spoke для отправки сообщений.

2. Периферийный менеджер очередей помещает сообщение в транспортную оче­редь. В результате инициатору канала менеджера очередей передается триггерное сообщение через SYSTEM.CHANNEL.INITQ. Канал стартует и начинает передачу сообщений удаленному менеджеру очередей. Удаленный MCA, созданный на ос­нове объекта receiver­канала в host1/echo.hub, передает сообщения заданной оче­реди менеджера­получателя сообщений.

Примечание. Длязаданнойочереди-получателявцентральномменеджереочередейдолженбытьобъявленобъектлокальнойочереди.Еслинеудаетсянайтисообщениявтранспортнойочередипериферийногоменеджералибовудаленнойочерединазначения,проверьтеочередьнедоставленныхсообщенийdead.lettersцентральногоменеджера.WebSphereMQExplorerотображаетзаго-ловкилюбыхсообщений,попавшихвэтуочередь.

НасторонеотправителядляпросмотрасостоянияканалавWebSphereMQExplorerиспользуетсястолбецStatusтаблицыChannelsлибоследующаякомандаMQSC:

DISPLAY CHSTATUS('to.host1/echo.hub')

Чтобывручнуюзапуститьканалнасторонеотправителя,щелкнитеканалправойкнопкойивыберитеStart.Этотакжеможносделать,исполнивследующуюкомандуMQSC:

START CHANNEL(‘to.host1/echo.hub’)

Чтобыостановитьканал,неблокируяего(тоестьнепрепятствуядальнейшемузапускуинициаторомканала),выберитепунктInactiveвраскрывающемсяспискеNewState(такможноостановитьканалвWebSphereMQExplorer).ЭтуоперациютакжеможновыполнитьприпомощиследующейкомандыMQSC:

STOP CHANNEL('to.host1/echo.hub') MODE(INACTIVE)

10 .3 .9 . Создание объекта receiver-канала для периферийного менеджера очередей

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

254 Глава10

необходимо установить связь между центральным и каждым из периферийных менед­жеров очередей.

Ниже рассказывается, как объявить объект receiver­канала, который будет использо­ваться центральным менеджером очередей для подключения к периферийному менеджеру. Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Channels менеджера очередей host2/spoke и вы­берите New\Receiver Channel.

2. Введите to.host2/spoke в поле Name.

3. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей host2/spoke:

DEFINE CHANNEL('to.host2/spoke') CHLTYPE(RCVR)

10 .3 .10 . Создание транспортной очереди для центрального менеджера очередей

Ниже описано создание транспортной очереди для центрального менеджера очере­дей host1/echo.hub, обеспечивающей временное хранилище для сообщений, предна­значенных для отправки периферийным менеджерам очередей. Кроме того, здесь рассказывается, как настроить триггер, запускающий канал (о создании объекта sender­канала см. ниже). Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Queues менеджера очередей host1/echo.hub и выберите New\Local Queue.

2. Введите host2/spoke в поле Name.

3. Щелкните Next.

4. Выберите пункт Transmission в поле Usage.

5. Введите в поле Description следующий текст:

Transmission queue for messages to host2/spoke

6. Перейдите в секцию Triggering.

7. Установите для поля Trigger значение On.

8. Убедитесь, что поле Trigger type содержит значение First.

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 255

9. Введите to.host2/spoke в поле Trigger data. Этот канал будет объявлен ниже.

10. Введите SYSTEM.CHANNEL.INITQ в поле Initiation queue.

11. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей host1/echo.

hub:

DEFINE QLOCAL('host2/spoke') USAGE(XMITQ) + TRIGGER TRIGTYPE(FIRST) +

TRIGDATA('to.host2/spoke') INITQ('SYSTEM.CHANNEL.INITQ') + DESCR('Transmission

queue for messages to host2/spoke')

10 .3 .11 . Создание объекта sender-канала для центрального менеджера очередей

Ниже описано создание объекта sender­канала, применяемого для подключения к пе­риферийному менеджеру очередей.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Channels менеджера очередей host1/echo.hub и выберите New\Sender Channel.

2. Введите to.host2/spoke в поле Name.

3. Щелкните Next.

4. Объект sender­канала будет использован для того, чтобы установить связь с пери-ферийным менеджером очередей, поэтому для поля Connection задают следующее значение:

host2.example.com(9002)

5. Введите host2/spoke в поле Transmission queue.

6. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей host1/echo.hub:

DEFINE CHANNEL('to.host2/spoke') CHLTYPE(SDR) + CONNAME('host1.example.

com(9002)’) XMITQ(‘host2/spoke’)

256 Глава10

Примечание. Наданномэтаперекомендуетсяпроверитькомандойpingканалсостороныотправителянаменеджереhost1/echo.hub,чтобыубедитьсявегоспособностипередаватьсообщения.Дляотправкисообщенийчерезканалнеобходимосоздатьтестовуюочередьвпериферийномменеджереочередей,которомубудутнаправлятьсясообщения.Соответствующиекомандыобсужда-ютсявразделе10.3.8.Изменитепараметрыкоманды,показаннойвэтомразделе,следующимобразом:

amqsput queue1 host1/echo.hub 8208 0 host2/spoke

10 .3 .12 . Локальное определение удаленной очереди К данному моменту должна быть установлена двусторонняя связь между централь­ным и периферийным менеджерами очередей. Вы также освоили отправку сообще­ний, явно адресованных очереди­получателю.

Однако, запрашивая обслуживание, приложения не должны явно указывать имя ме­неджера очередей, иначе будет невозможно изменять инфраструктуру без модифи­кации самих приложений.

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

Примечание. Объектыудаленныхочередейприменяютсядляразныхцелей;вчастности,ихчастоиспользуютвцентрально-лучевойинфраструктуре,вкоторойканалы,связывающиеменеджерыочередей,определяютсявручную.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Queues менеджера host2/spoke и выберите New\Remote Queue Definition.

2. Введите echo в поле Name.

3. Щелкните Next.

4. Введите в поле Description следующий текст:

Local definition for routing requests for the echo service

5. Введите echo в поле Remote queue. Это поле позволяет задать локальное имя для объекта локальной очереди, расположенной на удаленном менеджере. В этом примере используются идентичные имена.

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 257

6. Введите host1/echo.hub в поле Remote queue manager.

7. Оставьте поле Transmission queue пустым, поскольку имя транспортной очереди идентично имени удаленного менеджера очередей.

8. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду в отношении менеджера очередей host2/spoke:

DEFINE QREMOTE('echo') RNAME('echo') RQMNAME('host1/echo.hub') + DESCR('Local

definition for routing requests for the echo service')

10 .3 .13 . Определение очереди ответов для периферийного менеджера очередей

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

Ниже рассказывается, как создать модельную очередь для динамической генерации очереди ответов при поступлении запросов. Для этого применяют WebSphere MQ Explorer и команды MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Queues для host2/spoke и выберите New\Model Queue.

2. Введите echo.replies в поле Name.

3. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей host2/spoke:

DEFINE QMODEL(‘echo.replies’)

10 .3 .14 . Запрос службы echo с периферийного менеджера очередей

Ниже описана процедура отправки запроса приложением, подключенным к перифе­рийному менеджеру очередей; этот запрос будет обработан центральным менедже­ром очередей.

258 Глава10

Примечание. Здесьпредполагается,чтоменеджерочередейhost1/echo.hubпо-прежнемунастроендляпредоставлениядоступакработающейвнемслужбе.Такжеважноналичиеуочередиинициацииecho.initqактивноготриггерногомонитора.Желательнотакже,чтобыслужбумоглизапрашиватьилокальныеприложения,подключенныекменеджеруhost1/echo.hub(см.раздел9.4.10).

1. Выполните следующую команду WebSphere MQ:

amqsreq echo host2/spoke echo.replies

Эта команда содержит следующие параметры:

– echo – имя очереди, разрешаемое локальным менеджером очередей. Благодаря наличию локального определения удаленной очереди сообщения, адресован­ные echo, маршрутизируются менеджеру host1/echo.hub через транспортную очередь и пару открытых каналов (sender­ и receiver­каналы);

– host2/spoke – имя локального периферийного менеджера очередей, к которому подключается приложение;

– echo.replies – имя модельной очереди, открытой для динамического создания очереди ответов для приложения.

Примечание. Вкомандеamqsreqнеуказаноимяменеджераочередейhost1/echo.hub,предоставляющегодоступкслужбе.Инфраструктурасконфигурирова-надляавтоматическоймаршрутизациизапросов,осуществляемойнезаметнодлязапрашивающегоприложения.

2. Введите сообщение и нажмите Enter.

3. Не вводя сообщения, нажмите Enter.

4. Подождите 10 секунд.

5. Если все прошло нормально, вывод команды будет содержать введенное ранее сообщение:

response <текст_тестового_сообщения>

Примечание.  Есливыстолкнетесьструдностями,обратитеськразделу9.4.10.

10 .4 . Создание кластеров менеджеров очередей Как было показано в предыдущем разделе, объединение нескольких менеджеров очередей в составе центрально­лучевой инфраструктуры требует решения ряда адми­нистративных задач.

В этом разделе рассказывается о том, как применение кластеров позволяет снизить нагрузку на администраторов по добавлению менеджеров очередей к инфраструкту­ре WebSphere MQ. Это возможно благодаря тому, что каждый менеджер очередей

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 259

в составе кластера автоматически получает сведения и объединяется каналами связи с остальными менеджерами кластера.

В этом разделе используется кластер­пример с именем example.cluster.

10 .4 .1 . Создание менеджеров очередей Создайте четыре менеджера с активными слушателями.

Имена менеджеров очередей отражают их роли в составе кластера (см. табл. 10.1, в которой перечислены имена менеджеров очередей и порты, к которым привязаны их слушатели).

Табл . 10 .1 . Менеджерыочередейвсоставекластераexample .cluster

Имя Хост-имя Порт слушателя

Репозиторий Имя канала

host1/full host1 .example .com 9031 Полный clus .host1/full

host1/partial host1 .example .com 9032 Частичный clus .host1/partial

host2/full host2 .example .com 9033 Полный clus .host2/full

host2/partial host2 .example .com 9034 Частичный clus .host2/partial

Два из этих менеджеров обслуживают полные репозитории для кластера, которые содержат всю информацию о кластере, а остальные два – частичные, содержащие лишь необходимые им сведения.

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

Примечание. МынерекомендуемиспользоватьимяlocalhostилиIP-адрес127.0.0.1врабочихкластерах.Впрочем,дляданногопримераэтоимяиадресподходят,есливсеменеджерыочередейработаютнаодномкомпьютере.

Вкластерахобъектreceiver-канала,публикуемыйменеджеромочередей,рассы-лаетсяменеджерамкластера.Поэтомуимяподключения,указанноевегоопределении,должнобытьдоступнослюбойизмашин,накоторыхработаютменеджерыочередейкластера.

10 .4 .2 . Назначение менеджеров очередей с полными репозиториями Эти действия выполняются в отношении менеджеров очередей host1/full и host2/full.

Данные менеджеры очередей будут настроены так, что в них будут полные репозито­рии для кластера example.cluster.

Эти действия выполняются с использованием WebSphere MQ Explorer или команд MQSC.

260 Глава10

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой значок менеджера очередей в окне навигатора и выбе­рите Properties.

2. Перейдите в секцию Repository окна свойств менеджера очередей.

3. Выберите Full repository for a cluster.

4. Введите example.cluster в поле, которое станет доступным.

5. Щелкните OK.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей:

ALTER QMGR REPOS('example.cluster')

10 .4 .3 . Создание объектов кластерных receiver-каналов Описанные ниже действия выполняются над всеми менеджерами очередей кластера.

Объект кластерного receiver­канала, принадлежащий менеджеру очередей из класте­ра, определяет, как остальные менеджеры из этого кластера будут подключаться к данному менеджеру очередей.

В силу этих причин атрибут «подключение» данного объекта определяет хост­имя или IP­адрес, а также порт, которые должны использовать другие менеджеры очере­дей для подключения к данному менеджеру. Менеджер очередей может входить в со­ став нескольких кластеров, поэтому менеджеры очередей из разных кластеров будут подключаться к этому менеджеру, используя разные атрибуты. Для этого объект клас­терного receiver­канала настраивают для привязки к кластеру с заданным именем.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Channels данного менеджера очередей и выбе­рите New\Cluster-receiver Channel.

2. Введите «clus.», затем имя менеджера очередей в поле Name. Например, для менед­жера host1/full следует ввести:

clus.host1/full

3. Щелкните Next.

4. Введите имя подключения, которое использует данный менеджер очередей, в поле Connection. Например, для менеджера очередей host1/full введите

host1.example.com(9031)

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 261

Примечание. Проследите,чтобыдляменеджераочередей,которымуправля-ютвданномпримере,былиуказаныверныеименаканала,подключенияиномерпорта.

5. Выберите секцию Cluster.

6. Выберите Shared in cluster.

7. Введите example.cluster в поле, которое станет доступным.

8. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении менеджера очередей, который используется в данном примере. При этом замените имя host1/full именем этого менеджера, а имя host1.example.com(9031) – именем подключения, которое использу­ется данным менеджером очередей:

DEFINE CHANNEL('clus.host1/full') CHLTYPE(CLUSRCVR) + CONNAME('host1.example.

com(9031)’) CLUSTER(‘example.cluster’)

Примечание. Проследите,чтобыдляменеджераочередей,которымуправля-ютвданномпримере,былиуказаныверныеименаканала,подключенияиномерпорта.

10 .4 .4 . Создание объектов кластерных sender-каналов Описанные действия выполняются сначала над менеджерами очередей, содержащими полные репозитории данных кластера (host1/full и host2/full), а затем над менеджера­ми очередей, содержащими частичные репозитории (host1/partial и host2/partial).

Чтобы войти в кластер, менеджер очередей должен опубликовать определение своего объекта receiver­канала в одном из полных репозиториев кластера. Этот менеджер очередей разделяет данные с остальными полными репозиториями кластера. Чтобы впервые обратиться к полному репозиторию, менеджеру очередей требуются сведе­ния, необходимые для установки соединения. Они предоставляются в виде единст­венного объекта кластерного sender­канала, объявленного вручную.

Объекту кластерного sender­канала, назначенному для частичного репозитория, можно сопоставить произвольный полный репозиторий. Однако в данном примере с двумя менеджерами очередей, содержащими полные репозитории, объект кластер­ного sender­канала должен быть сопоставлен полному репозиторию другого менед­жера очередей.

Имя объекта кластерного sender­канала должно соответствовать имени объекта клас­терного receiver­канала, объявленного для удаленного полного репозитория. Это не­обходимо, чтобы менеджеры очередей кластера могли получать сведения, необходи­мые для подключения.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

262 Глава10

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Channels менеджера очередей и выберите New → Cluster-sender Channel.

2. Введите в поле Name «clus.», затем имя менеджера очередей, содержащего полный репозиторий (доступ к которому нужно получить для подключения к кластеру). Например, для менеджера очередей host1/full следует ввести «clus.» и «host2/full»:

clus.host2/full

3. Щелкните Next.

4. Введите в поле Connection имя подключения, используемого менеджером очере­дей, с которым нужно связаться для подключения к кластеру. Так, для менеджера очередей host1/full следует ввести:

host2.example.com(9033)

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

5. Перейдите в секцию Cluster.

6. Выберите Shared in cluster.

7. Введите example.cluster в поле, которое станет доступным.

8. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении данного менеджера очередей, заменив host2/full именем менеджера очередей с полным репозиторием, к которому нужно получить доступ для подключения к кластеру, а имя host2.example.com(9033) – именем подключения, используемого этим менеджером очередей:

DEFINE CHANNEL('clus.host2/full') CHLTYPE(CLUSSDR) + CONNAME('host2.example.

com(9033)’) CLUSTER(‘example.cluster’)

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

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 263

10 .4 .5 . Просмотр сведений о кластереВ результате выполнения вышеописанных действий создан кластер из четырех менеджеров очередей. Просмотр сведений о кластере с помощью WebSphere MQ Explorer и команд MQSC описан в разделе 8.2.

Если один из менеджеров очередей с полным репозиторием (работающий на локаль­ной или удаленной машине) отображается в WebSphere MQ Explorer, структуру клас­тера можно увидеть в папке Queue Manager Clusters.

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

На рис. 10.4 показана структура кластера в папке Queue Manager Clusters, отображае­мой в окне WebSphere MQ Explorer.

Рис . 10 .4 . Структуракластераexample .cluster,отображаемоговWebSphereMQExplorer

10 .4 .6 . Предоставление общего доступа к очередям кластераОписанные в этом разделе действия выполняются над всеми менеджерами очередей кластера.

264 Глава10

Ниже рассказывается, как создать в каждом из менеджеров кластера очередь с именем cluster.queue и предоставить к ней общий доступ.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой папку Queues менеджера очередей, расположенного в папке Queue Managers навигатора, и выберите New\Local Queue.

2. Введите cluster.queue в поле Name.

3. Щелкните Next.

4. Перейдите в секцию Cluster.

5. Выберите Shared in cluster.

6. Введите example.cluster в поле, которое станет доступным.

7. Щелкните Finish.

Применение команд MQSC

Выполните следующую команду MQSC в отношении данного менеджера очередей:

DEFINE QLOCAL('cluster.queue') CLUSTER('example.cluster')

10 .4 .7 . Активация балансировки нагрузки для локального экземпляра очереди

Описанные в этом разделе действия выполняются над всеми менеджерами очередей в кластере.

По умолчанию сообщения доставляются в локальную очередь (если очередь­адресат существует в менеджере очередей, к которому подключено приложение).

В WebSphere MQ V6.0 это правило можно переопределить, активировав механизм балансировки нагрузки для локального и всех остальных экземпляров общей очере­ди в кластере.

Это делается с использованием WebSphere MQ Explorer или команд MQSC.

Применение WebSphere MQ Explorer

Выполните следующие действия.

1. Щелкните правой кнопкой значок менеджера очередей в папке Queue Managers в окне навигатора и выберите Properties.

2. Выберите секцию Cluster в окне свойств менеджера очередей.

3. Измените значение поля CLWL use queue на Any.

4. Щелкните OK.

ПостроениеинфраструктурыWebSphereMQ:практическоеруководство 265

Применение команд MQSC

Выполните следующую команду MQSC в отношении данного менеджера очередей:

ALTER QMGR CLWLUSEQ(ANY)

10 .4 .8 . Балансировка нагрузки по обработке сообщений очередямиСледующие действия можно выполнить над любым менеджером очередей в кластере.

1. Подключитесь к любому менеджеру очередей и добавьте несколько сообщений. Так, в следующем примере добавляется 100 сообщений:

– Windows:

FOR /L %1 IN (1,1,100) DO echo Message%1 | amqsput cluster.queue host1/

partia

– UNIX (с оболочкой Bash или Korn):

i=0; while [ $i -lt 100 ]; do let i=i+1; echo Message$i | amqsput cluster.

queue host1/partial; done

2. Обратите внимание на текущую длину очереди. Просмотрите очередь cluster.queue в каждом из менеджеров очередей кластера (см. раздел 9.3.7).

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

10 .4 .9 . Предоставление общего доступа к службе echo в кластере Ниже рассказывается, как ввести менеджер очередей host1/echo.hub в кластер и пре­доставить всем менеджерам очередей кластера общий доступ к службе echo. Единст­венная задача администратора в этом случае – ввести в кластер менеджер очередей host1/echo.hub.

Ниже эти действия описаны более подробно (см. также разделы 10.4.3 и 10.4.4).

Выполните следующие действия.

1. Создайте объект кластерного receiver­канала со следующими параметрами:

– имя: clus.host1/echo.hub;

– имя подключения (атрибут CONNAME): host1.example.com(9001);

– кластер (атрибут CLUSTER): example.cluster.

2. Создайте объект кластерного sender­канала:

– имя: clus.host1/full;

– имя подключения (атрибут CONNAME): host1.example.com(9031);

– кластер (атрибут CLUSTER): example.cluster.

3. Измените объект локальной очереди echo, чтобы опубликовать его в кластере.

– С помощью WebSphere MQ Explorer:

266 Глава10

i. Выберите папку Queues менеджера очередей host1/echo.hub, расположен­ную в папке Queue Managers в окне навигатора, и выберите Properties.

ii. Перейдите в секцию Cluster.

iii. Выберите Shared in cluster.

iv. Введите example.cluster в поле, которое станет доступным.

v. Щелкните OK.

– С помощью команд MQSC:

ALTER QLOCAL(‘echo’) CLUSTER(‘example.cluster’)

Примечание. НезабывайтезаключатьатрибутывсоставекомандMQSCводинарныекавычки.

10 .4 .10 . Предоставление общего доступа к очереди echo в кластереЭту операцию можно выполнить путем запроса службы echo, выполнив программу­пример WebSphere MQ amqsreq с любым из менеджеров очередей кластера.

Примечание.  Предполагается,чтоменеджерочередейhost1/echo.hubнастроендляпредоставлениядоступакработающейвнемслужбеechoчерезочередьecho.Крометого,уочередиинициацииecho.initqдолженбытьактивныйтриггерныймонитор.Рекомендуетсяубедиться,чтослужбадоступналокальнымприложениям,подключеннымкменеджеруочередейhost1/echo.hub,преждечемпереходитькследующимдействиям(см.раздел9.4.10).

Выполните следующие действия.

1. Объявите модельную очередь или локальную очередь с именем echo.replies с ат­рибутами по умолчанию в менеджере очередей.

2. Выполните следующую команду, указав имя этого менеджера очередей как пара­метр:

amqsreq echo host2/partial echo.replies

3. Введите сообщение и нажмите Enter.

4. Не вводя текстa, нажмите Enter.

5. Ожидайте в течение 10 секунд.

6. Если команды завершатся успешно, выводится текст введенного ранее сооб­щения:

response <текст_тестового_сообщения>

Примечание. Есливыстолкнулисьструдностями,обратитеськразделу9.4.10.

ЗащитаинфраструктурыWebSphereMQ 267

11

Защита инфраструктуры WebSphere MQ

В этой главе вы познакомитесь с моделью защиты WebSphere MQ. Здесь также приво­дятся рекомендации, связанные с обеспечением безопасности при построении инф­раструктуры WebSphere MQ. К ним относится защита с помощью протоколов Secure Sockets Layer (SSL) и Transport Layer Security (TLS) доступа к ресурсам менеджеров очередей и связывающих их каналов, а также сетевых каналов связи для приложений. Ниже кратко рассказывается, как настроить WebSphere MQ Explorer и другие клиент­ские Java­приложения для подключения к менеджерам очередей через защищенные каналы.

В этой главе обсуждаются следующие темы:

Администрирование новой копии WebSphere MQ

Предоставление доступа к ресурсам менеджера очередей

Установка контекста идентификационных данных для клиентских приложений

Протокол Secure Sockets Layer (SSL)

WebSphere MQ internet pass­thru (IPT)

268 Глава11

11 .1 . Администрирование новой копии WebSphere MQ

Для настройки только что установленных копий WebSphere MQ, а также для создания, запуска и остановки менеджеров очередей пользователь должен войти в систему на машине, где установлен WebSphere MQ.

При этом пользователь получает возможность исполнения управляющих команд в Microsoft Windows и UNIX, команд CL на серверах IBM Eserver iSeries, а также испол­нения команд для управления подсистемами менеджеров очередей в z/OS. В этой книге такие пользователи называются администраторами.

Администраторы также обслуживают установленные копии WebSphere MQ и менед­жеры очередей. Например, они регулярно анализируют журналы ошибок менеджеров очередей, работающих на вверенной им машине, а также выполняют проверки на FFST.

Примечание. Командаrunmqsc —управляющаякомандаWebSphereMQ.ВWindows,UNIXиiSeriesтолькопользователи,авторизованныекакадминистра-торыWebSphereMQ,могутисполнятькомандыMQSC,адресованныенепосред-ственноменеджерамочередей.

Способы ограничения доступа к этим операциям в WebSphere MQ зависят от плат­формы.

Windows: доступ к управляющим командам WebSphere MQ разрешен только чле­нам групп mqm и Administrators.

UNIX: доступ к управляющим командам WebSphere MQ разрешен только членам группы mqm.

iSeries: члены группы QMQMADM обладают доступом ко всем командам WebSphere MQ CL. Подробнее об управлении доступом к отдельным командам CL в iSeries см. в разделе «Authority to administer WebSphere MQ on i5/OS» в руководстве WebSphere MQ Security, SC34­6588.

z/OS: проверка полномочий, выполняемая WebSphere MQ для z/OS, перенаправля­ется внешнему менеджеру безопасности (External Security Manager­ESM). Здесь предполагается, что его роль играет z/OS Security Server Resource Access Control Facility (RACF®). Доступ к наборам данных и командам, управляющим подсистема­ми менеджеров очередей, предоставляется посредством администрирования профилей RACF. Дополнительные сведения см. в разделе «Authority to administer WebSphere MQ on z/OS» руководства WebSphere MQ Security, SC34­6588.

11 .2 . Предоставление доступа к ресурсам менеджеров очередей

Модель защиты WebSphere MQ основана на конфигурировании профилей доступа для отдельных объектов и групп объектов WebSphere MQ.

ЗащитаинфраструктурыWebSphereMQ 269

Объекты WebSphere MQ представляют все ресурсы, принадлежащие менеджеру оче­редей и управляемые им; о некоторых из этих ресурсов рассказывается ниже. Напри­мер, объекты WebSphere MQ служат для настройки очередей в составе менеджера очередей, а также каналов, управляющих сетевым взаимодействием с данным менед­жером очередей.

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

11 .2 .1 . Object Authority Manager (OAM) В Windows, UNIX и iSeries у каждого менеджера очередей имеется компонент под названием Object Authority Manager (OAM). Он проверяет у всех сущностей, под­ключенных к менеджеру очередей и пытающихся выполнить какое­либо действие над объектами WebSphere MQ, наличие соответствующих полномочий.

Сущности различаются по идентификаторам пользователя операционной системы. У приложений, выполняющихся на той же машине, это реальный идентификатор пользования, который есть у каждого приложения (а не действующий идентифи­катор пользователя, как в UNIX). Ниже обсуждается установка контекста идентифика­ционных данных сущностей, подключающихся в режиме клиентов с удаленных сис­тем (см. раздел 11.3).

Полномочия OAM

Любому действию, которое может быть выполнено над объектом, соответствуют полномочия, которые можно предоставить либо отозвать с помощью OAM. Сущно­сти, подключенные к менеджеру очередей, могут выполнять следующие действия над объектами WebSphere MQ.

Подключение к менеджерам очередей.

Существует объект WebSphere MQ, представляющий менеджер очередей. Чтобы подключиться к менеджеру очередей, сущность прежде должна получить полно­мочия на подключение к данному объекту менеджера очередей.

Операции с интерфейсом очередей сообщений (message queue interface, MQI).

Любое действие, программно выполняемое над менеджером очередей, независи­мо от используемого API, соответствует одной или нескольким операциям MQI, например MQPUT, MQGET, MQINQ и MQSET.

Интерфейс MQI перед обращением к ресурсам требует выполнения операции MQOPEN. Чаще всего MQOPEN применяют для того, чтобы открыть очередь перед размещением и извлечением из нее сообщений.

Именно во время вызова MQOPEN компонент OAM проверяет наличие полномо­чий на выполнение операций, запрошенных при вызове MQOPEN. Каждой из воз­можных операций соответствуют полномочия, обслуживаемые OAM, а именно разрешения на извлечение (get), добавление (put), просмотр (browse), запрос (inquire) и установку (set). После вызова MQOPEN приложению разрешено выпол­нять лишь операции MQI, авторизованные во время вызова MQOPEN.

270 Глава11

Примечание. Авторизациязанимаетнекотороевремя,поэтомупослевызоваMQOPENрекомендуетсявыполнятьнесколькооперацийput/get,аневызыватьMQOPENиMQCLOSEпослекаждойоперации.ТожевернодлявызоваMQPUT1,которыйсоответствуетоперациямMQOPEN,MQPUTиMQCLOSE.

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

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

В табл. 6.1 дана сводка объектов, для которых выполняется проверка полномочий при открытии очереди для размещения сообщений.

Примечание. Чтобыполучитьполномочиядляразмещениясообщенийвлюбойизобщихочередейкластераменеджеровочередей,приложениеможетполучитьполномочиенадобавлениевотношенииочередиSYSTEM.CLUSTER.TRANSMIT.QUEUE,обслуживаемойменеджером,ккоторомуэтоприложениеподключается.Большевозможностейпоуправлениюдоступомможнополучитьследующимобразом.Определитеобъектымодельныхочередей,ватрибуте«targetqueue»(TARGQ)которыхуказаныименаобщихочередейкластера.Далееможнопредоставлятьполномочиятолькодлядобавлениясообщенийвотношенииэтихобъектовмодельныхочередей.

Выполнение действий в контексте другого пользователя.

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

Примером может быть служба, которая переносит идентификационные данные из сообщения­запроса в сообщение­ответ.

Если приложению требуется возможность выполнять эти операции, оно должно заявить об этом при вызове MQOPEN для очереди. В WebSphere MQ имеется набор полномочий, соответствующих параметрам вызова MQOPEN: altusr, passid, pas-sall, setid, setall.

ЗащитаинфраструктурыWebSphereMQ 271

Подробнее об этом см. в разделе «MQOPEN – Open object» руководства WebSphere MQ Application Programming Reference, SC34­6596.

Администрирование объектов WebSphere MQ.

Только пользователи, назначенные администраторами WebSphere MQ, могут непосредственно администрировать менеджеры очередей с использованием управляющих команд WebSphere MQ и команд CL, в том числе исполнять команды MQSC с помощью runmqsc, подробнее об этом см. в разделе 11.1.

Однако WebSphere MQ допускает администрирование менеджеров очередей другими пользователями, которые могут использовать WebSphere MQ Explorer либо переда­вать команды PCF непосредственно командному серверу менеджера очередей.

Примечание. Командныйсерверпоумолчаниюзапускаетсядляменеджеровочередей,созданныхвWebSphereMQV6.0налюбойплатформе,кромеz/OS.

Авторизация этих команд выполняется на основе идентификатора пользователя в MQMD управляющего сообщения. Этот идентификатор пользователя основан на контексте идентификационных данных приложения, сгенерировавшего сооб­щение менеджеру очередей, к которому оно подключено. Однако у приложения могут быть полномочия для размещения сообщений в контексте другого пользо­вателя.

OAM поддерживает ряд административных полномочий для тонкой настройки администрирования объектов пользователями.

– Create (crt) и delete (dlt): назначаются в отношении некоторого типа объектов, позволяют, соответственно, создавать и удалять любые объекты этого типа.

– Display (dis) и change (chg): назначаются в отношении отдельных объектов, позволяют отображать и модифицировать атрибуты объекта, для которого они назначены;

– Clear (clr), ping (ping), control (ctrl) и control­extended (ctrlx): назначаются в отношении отдельных объектов соответствующего типа; позволяют выпол­нять над объектом некоторые операции по управлению. Например, полномо­чие clear (clr) позволяет очищать очередь, control (ctrl) — запускать и оста­навливать каналы, а control­extended (ctrlx) — выполнять сброс (reset) или разрешение (resolve) для каналов.

Примечание. РядадминистративныхдействийнадменеджерамиочередейразрешентолькоадминистраторамWebSphereMQ.ДоWebSphereMQV6.0вихчисловходилизапуск,остановиразрешениеканалов.Подробнеесм.вразделе«AuthoritycheckingforPCFcommands»руководстваWebSphereMQProgrammableCommandFormatsandAdministrationInterface,SC34-6598.

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

272 Глава11

Предоставление, отзыв и отображение полномочий OAM

WebSphere MQ поддерживает ряд управляющих команд, контролирующих атрибуты индивидуальных объектов и их групп.

WebSphere MQ V6.0 также поддерживает команды PCF для программного админист­рирования полномочий. Дополнительные сведения о них см. в руководстве WebSphere MQ Programmable Command Formats and Administration Interface, SC34­6598.

Полномочия могут назначаться только пользователям и группам, определенным в локальной операционной системе.

Примечание.  ВWebSphereMQдляUNIX-платформназначениеиотзывполномочийвсегдаосуществляетсянауровнегрупппользователейОС.Чтобыназначитьилиотозватьполномочиеуотдельногопользователя,этонеобходимосделатьдляосновнойгруппыданногопользователя,анеегосамого.

Для администрирования полномочий OAM служат следующие команды Web Sphere MQ.

setmqaut — применяется для назначения и отзыва полномочий OAM для объектов WebSphere MQ на заданном менеджере очередей заданного типа с заданным име­нем. В именах параметров допускается символ «звездочка» (*), позволяющий ука­зывать группы имен; сам по себе объект менеджера очередей не требует парамет­ра, определяющего имя.

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

dspmqaut — используется для отображения полномочий, назначенных опреде­ленному пользователю или группе в отношении некоторого объекта.

dmpmqaut — применяется для тех же целей, что и dspmqaut, но предоставляет более подробные сведения. Эта команда особенно удобна, так как позволяет узнать, почему данному пользователю назначаются те или иные привилегии, отображаемые командой dspmqaut (например, в силу членства в группах).

Подробнее об этих командах см. в разделе «WebSphere MQ control commands» руко­водства WebSphere MQ System Administration Guide, SC34­6584.

ЗащитаинфраструктурыWebSphereMQ 273

11 .2 .2 . Полномочия для объектов в WebSphere MQ для z/OS Проверка полномочий для объектов WebSphere MQ для z/OS выполняется внешними по отношению к WebSphere MQ средствами — при помощи RACF.

Этот механизм описан выше, в разделе 11.2.1. В этом случае проверка полномочий основана на профилях RACF для отдельных объектов, а не на полномочиях OAM.

Это может быть индивидуальный профиль менеджера очередей либо разделяемый профиль менеджеров группы с разделением очередей (queue sharing group). Различ­ные операции над объектами WebSphere MQ, представляющими менеджеры очере­дей, требуют различных уровней доступа RACF.

Подробнее об этом см. в разделе «Setting up security» руководства WebSphere MQ для z/OS V6.0 System Setup Guide, SC34­6583.

11 .3 . Установка контекста идентификационных данных клиентских приложений

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

Однако при запуске слушателя менеджер очередей получает идентификационные данные для работы в сети. Через него возможно подключение к менеджеру очередей клиентских приложений.

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

11 .3 .1 . Процедура установки идентификационных данных в WebSphere MQ по умолчанию

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

Этот идентификатор пользователя основан на идентификаторе, под которым прило­жение работает на удаленной машине. Тот же идентификатор пользователя должен существовать на машине, на которой работает менеджер очередей, — это необходи­мо для успешного подключения. Дальнейшая проверка полномочий осуществляется в данном контексте идентификационных данных.

274 Глава11

Примечание. Приподключениикудаленномуменеджеруочередейклиент-скийMCAможетпередаватьпоканалуидентификатор,отличныйотидентифика-торанаудаленноймашине.Например,приподключениикUNIX-машинампереда-ютсяпервые12символоввнижнемрегистреидентификаторапользователя,подкоторымработаетприложение.Так,вместоидентификатораAdministratorменед-жеруочередейвUNIXпередаетсястрокаadmin.Поэтомунамашине,гдеработа-етменеджерочередей,долженсуществоватьавторизованныйидентификаторadmin,иначепопыткаподключениязакончитсянеудачно.

Учтите, что существуют также стандартные учетные записи пользователя, такие как mqm, и стандартные каналы, например SYSTEM.DEF.SVRCONN. Удаленные приложе­ния могут использовать их для подключения к менеджеру очередей, у которого есть слушатель, привязанный к доступной сети.

Сети часто защищают путем организации интрасетей и установки брандмауэров, и дополнительная защита может не потребоваться. Тем не менее WebSphere MQ под­держивает функции дополнительной защиты подключений.

11 .3 .2 . Идентификатор пользователя MCAАтрибут канала серверного подключения «идентификатор пользователя MCA» (MCAUSER) позволяет изменять процедуру назначения идентификационных данных по умолчанию, описанную выше. Все клиентские приложения, подключающиеся через канал, для которого задан этот атрибут, получают одинаковые полномочия в отношении менеджера очередей (независимо от идентификатора, под которым они работают на удаленной машине).

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

Этот метод позволяет снизить нагрузку по администрированию удаленных компью­теров, позволяя клиентским приложениям работать на другом компьютере под любым идентификатором пользователя.

Кроме того, можно ограничить доступ к ресурсам менеджера очередей, назначив соответствующий уровень доступа идентификатору пользователя MCA для канала серверного подключения. Однако в некоторых случаях требуется предоставить пол­ный доступ к машине, например для удаленного администрирования WebSphere MQ Explorer.

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

ЗащитаинфраструктурыWebSphereMQ 275

Само по себе применение идентификатора пользователя MCA не всегда гарантирует безопасность каналов связи с менеджером очередей. В этих обстоятельствах защита контекста идентификационных данных и конфиденциальности подключений осу­ществляется с использованием протоколов Secure Sockets Layer (SSL) и Transport Layer Security (TLS).

11 .4 . Secure Sockets Layer (SSL) Secure Sockets Layer (SSL) — это промышленный стандарт технологий защиты конфи­денциальных данных при передаче по публичным сетям и проверки подлинности контекста идентификационных данных.

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

Разъяснение этих понятий приводится во введении к руководству WebSphere MQ Security, SC34­6588.

11 .4 .1 . Поддержка SSL в WebSphere MQ WebSphere MQ позволяет защищать при помощи SSL любые типы каналов: распреде­ленные и кластерные каналы передачи сообщений, а также клиентские каналы.

SSL применяют для проверки подлинности удостоверений удаленных приложений и менеджеров очередей.

SSL также применяют для обеспечения конфиденциальности и целостности данных при передаче через каналы связи.

11 .4 .2 . CipherSpec Чтобы защитить канал с помощью SSL, необходимо занести строку CipherSpec в атри­бут «SSL Cipher Specification» (SSLCIPH) объекта канала.

Имя CipherSpec определяет алгоритмы шифрования и вычисления кода проверки подлинности сообщения (message authentication code, MAC), которые будут исполь­зоваться для установленного канала.

Каждому значению CipherSpec в WebSphere MQ соответствует CipherSuite других под­держивающих SSL приложений, у которых в CipherSuite используется обмен ключами по протоколу RSA.

Различные значения CipherSpecs предоставляют различные уровни безопасности и быстродействия. Подробнее об этом см. в разделе «Working with CipherSpecs» руко­водства WebSphere MQ Security, SC34­6588.

276 Глава11

Примечание. ДляканаламожетбытьзаданотолькооднозначениеCipherSpec,котороектомужедолжносоответствоватьзначениюканала-партне-ра.ПриподключенииклиентскихJava-приложенийилиWebSphereMQInternetPass-ThruзначениеCipherSpecдолжнобытьсовместимоспараметромCipherSuite,указаннымJava-клиентомилиэкземпляромWebSphereMQIPT.

11 .4 .3 . Протокол TLS Transport Layer Security (TLS) версии 1.0 — протокол, сходный с SSL 3.0, с рядом допол­нений, повышающих надежность защиты каналов связи.

В WebSphere MQ V6.0 использование протокола TLS задается некоторыми значения­ми CipherSpec, подробнее об этом см. в разделе «Transport Layer Security (TLS) concepts» руководства WebSphere MQ Security, SC34­6588.

Примечание. ВсесказанноевследующихразделахэтойглавыпроSSLверноидляTLS.

11 .4 .4 . Обязательная и необязательная SSL-аутентификация клиентов

В SSL­взаимодействии вызывающая сторона традиционно называется SSL­клиентом, а отвечающая — SSL­сервером.

Во время первоначального SSL­взаимодействия (handshake) проверяется подлинность SSL­сервера, но не SSL­клиента. Так, при подключении браузера к сайту Интернет­магазина подлинность сайта проверяется с использованием цифрового сертификата, тогда как браузеру предъявлять свой сертификат, как правило, не обязательно.

В каждой допустимой паре каналов в WebSphere MQ один из MCA играет роль SSL­клиента, а другой MCA — SSL­сервера. При этом receiver­канал и канал серверного подключения являются SSL­серверами.

Объект канала на стороне SSL­сервера можно настроить так, чтобы он запрашивал у SSL­клиента действительный сертификат либо позволял ему предъявлять сертифи­кат по желанию. Это делается при помощи атрибута «SSL Client Authentication» (SSL-CAUTH). Независимо от значения этого атрибута, если SSL­клиент предъявляет серти­фикат, последний должен быть успешно проверен SSL­сервером.

11 .4 .5 . Хранилище сертификатов менеджера очередей У каждого менеджера очередей имеется собственное хранилище сертификатов. Оно содержит персональные сертификаты и закрытые ключи, идентифицирующие дан­ный менеджер в инфраструктуре. Там же находятся открытые сертификаты всех доверяемых сущностей. Это могут быть как самоподписанные сертификаты, так и открытые сертификаты публичных центров сертификации (ЦС), выдающих серти­фикаты для нужд инфраструктуры.

ЗащитаинфраструктурыWebSphereMQ 277

Атрибут «SSL Key Repository» (SSLKEYR) объекта менеджера очередей идентифицирует хранилище ключей данного менеджера. Подробнее об этом см. в разделе «ALTER QMGR» руководства WebSphere MQ Script (MQSC) Command Reference, SC34­6597.

Менеджер очередей определяет, какой из находящихся в данном хранилище серти­фикатов ему следует использовать в качестве персонального сертификата, с помощью метки, или понятного имени сертификата. При этом метка должна быть определена в корректном формате. Подробнее см. в разделе «Setting up SSL communications» руководства WebSphere MQ Security, SC34­6588.

Примечание. Метка,илипонятноеимясертификата,идентифицируетсертификатвхранилище.Однаконепутайтеегоссоставнымименемсертифика-та.Форматметкиперсональныхсертификатовизакрытыхключей,полученныхотЦСввидеPKCS12-файлов,можетнеподдерживаться.

УтилитаIBMKeyMan(см.http://www.alphaworks.ibm.com/tech/keyman)позволяетскорректироватьметкусертификатавPKCS12-файлепередимпортомеговхранилищеключейWebSphereMQ.

11 .4 .6 . Администрирование хранилищ сертификатов WebSphere MQ

Подробно администрирование сертификатов освещается в разделе «Working with WebSphere MQ SSL support» руководства WebSphere MQ Security, SC34­6588. В число административных задач управления сертификатами входит:

создание хранилища ключей для менеджера очередей;

выпуск самоподписанных сертификатов;

создание запросов для ЦС;

получение от ЦС подписанных сертификатов;

добавление сертификата доверенного ЦС в хранилище;

импорт персонального сертификата и закрытого ключа из PKCS12­файла;

экспорт персонального сертификата и закрытого ключа в PKCS12­файл;

извлечение открытого ключа из хранилища.

Дополнительные сведения о полном наборе функций утилит командной строки IBM GSKit iKeycmd, поставляемых с WebSphere MQ для Windows и UNIX, см. в разделе «Managing keys and certificates» руководства WebSphere MQ System Administration Guide, SC34­6584.

Примечание. Незабывайтеозащитефайловойсистемыхранилищаключейменеджераочередей.Вчастности,необходимконтрольдоступак.kdb-и.sth-файлам.

278 Глава11

11 .4 .7 . Клиентские приложения WebSphere MQ Администрирование хранилища сертификатов клиентских приложений, написан­ных на C и C++, во многом сходно с таковым для менеджера очередей.

Эти хранилища имеют одинаковый формат и административный интерфейс. Пере­менная окружения MQSSLKEYR определяет расположение хранилища и используется так же, как атрибут SSLKEYR менеджера очередей. О требованиях к формату метки (понятного имени) персональных сертификатов, содержащихся в хранилищах, см. в разделах «Setting up SSL communications» и «Working with the Secure Sockets Layer (SSL) on UNIX and Windows systems» руководства WebSphere MQ Security, SC34­6588.

Чтобы настроить CipherSpec для канала при подключении к менеджеру очередей, используют таблицу определений клиентских каналов (CCDT).

Альтернативный вариант — явно указать расположение хранилища ключей и CipherSpec. Это делается путем добавления структур MQCD и MQSCO к структуре MQCNO, передаваемой при вызове MQCONNX (см. руководство WebSphere MQ Application Programming Reference, SC34­6596).

11 .4 .8 . Доступ клиентских Java-приложений к WebSphere MQ Java­приложения могут получать доступ к инфраструктуре WebSphere MQ как клиен­ты через каналы, защищенные SSL. В число этих приложений входят WebSphere MQ Explorer и приложения, исполняемые сервером приложений WebSphere.

В этих случаях клиентские MCA используют одну из реализаций Java Secure Sockets Extension (JSSE) для SSL­аутентификации у менеджера очередей, подробнее см. в раз­деле «Secure Sockets Layer (SSL) support» руководства WebSphere MQ Using Java, SC34­6591.

Примечание. ВJSSEдляхраненияключейиспользуетсяфайлформатаJavaKeyStore(JKS),отличныйотформатахранилищаключейменеджеровочередейWebSphereMQ.ОднакосWebSphereMQдляWindowsиUNIXпоставляютсяутилитыKeyMan,которыеслужатдляадминистрированияхранилищаключейвформатеJKS.ВнаборKeyManвходитутилитакоманднойстрокиgsk7cmdиgsk7ikm—инструментсграфическиминтерфейсомпользователя(graphicaluserinterface,GUI).АльтернативаKeyMan—утилитаkeytoolизстандартнойпоставкиисполняющейсредыJavaRuntimeEnvironment(JRE).

Ниже вы найдете сводку операций по настройке Java­приложений для подключения с использованием SSL и стандартной реализации JSSE.

Укажите CipherSuite, соответствующий CipherSpec в определении канала сервер­ного подключения, объявленного на сервере:

– для приложений, использующих базовый Java API, CipherSuite можно указать в атрибуте sslCipherSuite объекта MQEnvironment либо в свойстве MQC.SSL_CIPHER_SUITE_PROPERTY таблицы хеш­значений, передаваемой конструктору объ­екта MQQueueManager. Альтернативный вариант (в WebSphere MQ V6.0) —

ЗащитаинфраструктурыWebSphereMQ 279

передать конструктору объекта MQQueueManager таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification (SSLCIPH);

– для JMS­приложений CipherSuite можно указать при помощи атрибута SSLCIPHERSUITE объекта ConnectionFactory. Альтернативный вариант (в Web­Sphere MQ V6.0) – передать через атрибут CCDTURL объекта ConnectionFactory таблицу CCDT с каналом, для которого задан соответствующий атрибут SSL Cipher Specification (SSLCIPH).

Укажите расположение и пароль для JSSE KeyStore; в хранилище должен быть минимум один персональный сертификат с закрытым ключом. Метка этого сер­тификата в KeyStore не имеет значения для клиентских Java­приложений. Храни­мые в KeyStore сертификаты защищены паролем, поэтому для доступа к KeyStore необходим пароль. По умолчанию параметры для доступа к JSSE KeyStore указыва­ют с помощью следующих Java­свойств:

javax.net.ssl.keyStore

javax.net.ssl.keyStorePassword

Укажите размещение JSSE TrustStore. В TrustStore должны быть открытые сертифи­каты всех ЦС, которым доверяет Java­приложение. Обычно эти сертификаты хранятся в JKS­файле, не защищенном паролем, поэтому указывать пароль не требуется. TrustStore и KeyStore могут храниться в одном файле. По умолчанию параметры для доступа к JSSE TrustStore указывают с помощью следующих Java­свойств:

javax.net.ssl.trustStore

javax.net.ssl.trustStorePassword

11 .4 .9 . SSL и WebSphere MQ Explorer WebSphere MQ Explorer подключается к менеджерам очередей как клиентское Java­приложение.

Настроить доступ к JSSE KeyStore и TrustStore можно в секции SSL Client Certificate Stores окна WebSphere MQ Preferences (рис. 11.1).

280 Глава11

Рис . 11 .1 . НастройкадоступакKeyStoreиTrustStoreвWebSphereMQExplorer

Вручную указать CipherSuite для отдельных подключений к менеджерам очередей невозможно. Однако WebSphere MQ Explorer позволяет подключаться к менеджерам очередей с использованием CCDT.

Примечание.  Передтемкаквыполнитьследующиедействия,изучитеруководствоAPARIC47466.Чтобынайтитекструководства,насайтеподдержкиWebSphereMQ(http://www.ibm.com/software/integration/wmq/support/)выполнитепоискпокритериюIC47466.

Чтобы подключить WebSphere MQ Explorer к менеджеру очередей по каналу, защи­щенному SSL, выполните следующие действия.

1. Создайте слушатель и объект канала серверного подключения для удаленного менеджера очередей. Укажите значение атрибута «SSL Cipher Suite» (SSLCIPH) для этого объекта.

2. Создайте одноименный объект канала клиентского подключения с идентичным значением атрибута «SSL Cipher Suite» (SSLCIPH). Значение атрибута «Queue Manager Name» (QMNAME) объекта канала клиентского подключения должно в точности соответствовать имени менеджера очередей, к которому требуется подключиться (и в котором создан объект канала серверного подключения).

При этом не важно, в каком менеджере очередей создан этот объект, но файл CCDT необходимо перенести на машину, где работает WebSphere MQ Explorer, или на сетевой диск. В Windows данный файл создается менеджером очередей в каталоге

C:\Program Files\IBM\WebSphere MQ\Qmgrs\QMNAME\@ipcc\AMQCLCHL.TAB

ЗащитаинфраструктурыWebSphereMQ 281

3. Скопируйте файл CCDT в каталог, доступный WebSphere MQ Explorer.

4. Создайте JKS­файл, содержащий:

– персональный сертификат и закрытый ключ, идентифицирующий WebSphere MQ Explorer (это не обязательно, если для атрибута «SSL Client Authentication» (SSLCAUTH) канала серверного подключения задано значение OPTIONAL);

– открытые сертификаты всех ЦС, необходимых для проверки подлинности персонального сертификата менеджера очередей.

Эти операции можно выполнить с помощью команды strmqikm (в Windows) и гра­фического интерфейса IBM Key Management.

5. Откройте WebSphere MQ Explorer.

6. Выберите в меню Window\Preferences, чтобы открыть окно Preferences.

7. Выберите WebSphere MQ Explorer\SSL Client Certificate Stores.

8. Введите в поля Trusted Certificate Store и Personal Certificate Store путь к созданному JKS­файлу.

9. Щелкните Enter Password в секции Personal Certificate Store.

10. Введите пароль для JKS­файла.

11. Щелкните OK.

12. Создайте прямое подключение к менеджеру очередей с помощью мастера Add queue manager. Введите имя менеджера очередей и выберите использование таб­лицы CCDT. Укажите путь к CCDT­файлу, ранее скопированному в каталог, доступ­ный WebSphere MQ Explorer.

Примечание. ЧтобывызватьмастерAddQueueManager,щелкнитеправойкнопкойпапкуQueue ManagersивыберитеShow/Hide Queue Managers,чтобыоткрытьокноShow/HideQueueManagers.ВэтомокнещелкнитеAdd.

11 .4 .10 . Список отозванных сертификатов Иногда сертификаты бывают скомпрометированы еще до истечения срока их дейст­вия. Например, это бывает при нарушении конфиденциальности закрытого ключа, связанного с этим сертификатом. Таким сертификатам не следует доверять, даже если проверка их подписи проходит успешно.

SSL поддерживает механизм, позволяющий ЦС отзывать подписанные им сертифика­ты. Для этого служат списки отозванных сертификатов (certificate revocation list, CRL), которые проверяют менеджеры очередей WebSphere MQ с помощью протокола LDAP (Lightweight Directory Access Protocol).

Подробнее о CRL и настройке менеджеров очередей WebSphere MQ для проверки CRL см. в разделе «Working with Certificate Revocation Lists and Authority Revocation Lists» в WebSphere MQ Security, SC34­6588.

282 Глава11

11 .4 .11 . Выбор ЦСВ инфраструктуре WebSphere MQ допускается использование следующих типов сер­тификации.

Применение самоподписанных сертификатов (когда каждый сертификат подпи­сывается самостоятельно). Закрытые ключи сертификатов находятся в хранилище сертификатов менеджера очередей или клиентского приложения, которому при­надлежит сертификат. Открытый сертификат извлекается из этого хранилища и распространяется среди сущностей, доверяющих владельцу сертификата.

Такой подход требует значительных усилий по администрированию и обслужива­нию сертификатов, находящихся в хранилищах, но зато предоставляет максимум возможностей по управлению отдельными сертификатами и не требует соз­ дания ЦС.

Использование центров сертификации. WebSphere MQ поставляется с инструмен­тами, позволяющими создавать и подписывать запросы на получение сертифика­тов. В хранилище ключей, назначенном ЦС, могут выдаваться самоподписанные сертификаты, а также сертификаты для других менеджеров очередей и клиент­ских приложений. Эти операции также можно выполнить при помощи многочис­ленных инструментов от сторонних производителей.

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

Использование сторонних ЦС. Существует множество сторонних ЦС, способных выдавать сертификаты. Запросы на выдачу сертификатов генерируются хранили­щем ключей, принадлежащим сущности с подходящими параметрами. При выпус­ке сертификата также генерируется закрытый ключ, который затем остается в защищенном хранилище. Запрос сертификата отправляется ЦС, который выпус­кает и возвращает подписанный им открытый сертификат. После этого получен­ный сертификат импортируется в хранилище сертификатов и присоединяется к закрытому сертификату.

Хотя сертификаты от сторонних ЦС не бесплатны, их использование дает сущест­венные преимущества. Так, этот подход позволяет переложить на стороннюю организацию ответственность за безопасность ЦС и обеспечение доступа к CRL через сервер LDAP. Он требует минимальных усилий по администрированию сертификатов и их хранилищ.

11 .4 .12 . Проверка составного имени с помощью атрибута SSL-«Peer»

Часто требуется предоставлять различные уровни доступа разным сущностям, под­ключающимся к менеджеру очередей по сети.

Проверка безопасности в SSL устанавливает, можно ли доверять контексту идентифи­кационных данных, содержащемуся в сертификате. После установления доверитель­

ЗащитаинфраструктурыWebSphereMQ 283

ных отношений отличительное имя (distinguished name, DN), которое содержится в сертификате, может применяться для идентификации сущности, владеющей серти­фикатом. В DN может входить имя, адрес электронной почты, название компании, имя сервера, страна и другая подходящая информация.

WebSphere MQ позволяет настраивать отдельные каналы так, чтобы они принимали подключения только от сущностей с заданным DN. DN сверяется с атрибутом SSL Peer (SSLPEER) объекта канала.

Эта проверка достаточно гибкая, она позволяет сверять отдельные поля DN с фикси­рованным значением, а другие — со строками, содержащими символы обобщения. Список правил проверки см. в разделе «WebSphere MQ rules для SSLPEER values» руко­водства WebSphere MQ Security, SC34­6588.

Примером может быть настройка различных значений атрибутов SSL Peer (SSLPEER) для каналов серверных подключений, используемых администраторами для работы с WebSphere MQ Explorer, и каналов, используемых приложениями для доступа к опре­деленным очередям. Комбинируя этот прием с настройкой различных значений атрибута «MCA user identifier» (MCAUSER) для тех же каналов, удается независимо управ­лять полномочиями групп.

11 .4 .13 . Совместимость со стандартом Federal Information Processing Standard (FIPS)

В WebSphere MQ используются стандартные компоненты, применяемые в целом ряде программных продуктов IBM, обеспечивающие защиту каналов связи при помощи SSL. Это означает, что надежность защиты WebSphere MQ обеспечивается тщатель­ным тестированием и проверкой этих компонентов.

На многих платформах, поддерживаемых WebSphere MQ, эти компоненты прохо­ дят тестирование по стандартной программе, соответствующей требованиям феде­рального стандарта США на обработку информации (Federal Information Processing Standard, FIPS).

Подробнее см. в разделе «Federal Information Processing Standard (FIPS)» руководства WebSphere MQ Security, SC34­6588.

11 .5 . Websphere MQ Internet Pass-Thru (IPT) Каналы связи, соединяющие узлы инфраструктуры или поддерживающие внешние интерфейсы для взаимодействия с этой инфраструктурой, реализованы с использо­ванием различных технологий, в соответствии с различными требованиями к безопасности.

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

284 Глава11

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

Другие технологии, например преобразование сетевых адресов (network address translation, NAT), позволяют присваивать одному и тому же узлу разные адреса для взаимодействия с внутренней и внешней сетями.

Некоторые сетевые интерфейсы разрешают взаимодействие только по определен­ным протоколам, таким как протокол HTTP, применяемый для передачи Web­страниц. При этом могут действовать дополнительные защитные ограничения, например тре­бование использования защищенного протокола HTTPS, построенного на основе технологий SSL.

WebSphere MQ предоставляет программный продукт WebSphere MQ internet pass-thru (IPT), обеспечивающий гибкую маршрутизацию данных WebSphere MQ через гетеро­генные сети.

WebSphere MQ IPT поддерживает туннелирование данных WebSphere MQ через раз­личные сети, построенные на основе межсетевых протоколов TCP/IP.

WebSphere MQ IPT способен маршрутизировать клиентские подключения, распреде­ленные и кластерные каналы для передачи сообщений, включая каналы, защищенные SSL, прозрачно для WebSphere MQ.

Также можно соединять несколько экземпляров WebSphere MQ IPT для создания мос­тов WebSphere MQ, соединяющих множество узлов сети. При этом для каждого из них WebSphere MQ IPT позволяет использовать различные коммуникационные про­токолы, целевые адреса и уровни защиты. Узлы WebSphere MQ IPT способны взаимо­действовать друг с другом, а также с экземплярами WebSphere MQ, которые являются получателями данных.

WebSphere MQ IPT поддерживает SSL, позволяя подключаться к WebSphere MQ через каналы, защищенные SSL. Для этого необходимо, чтобы наборы параметров Cipher­Suite, используемые WebSphere MQ IPT, соответствовали значениям CipherSpec, кото­рые использует WebSphere MQ.

Для работы WebSphere MQ IPT не требуется сервер WebSphere MQ. WebSphere MQ IPT поставляется отдельно от WebSphere MQ в виде пакета поддержки SupportPac MS81. Подробнее о WebSphere MQ IPT см. по адресу

http://www.ibm.com/support/docview.wss?rs=203&uid=swg24­006386&loc=en_US&cs=utf8&lang=en

Устранениенеполадок 285

12

Устранение неполадок

В этой главе кратко рассказывается о диагностике и разрешении проблем с WebSphere MQ. Ниже даются подробные инструкции по разрешению наиболее распространен­ных проблем, возникающих при создании, администрировании и использовании среды WebSphere MQ. Для эффективного устранения неполадок, не описанных в информационных ресурсах, приводятся советы по подготовке сведений для обраще­ния в службу IBM Service.

В этой главе обсуждаются следующие темы:

Базовая информация, предоставляемая WebSphere MQ

Разрешение известных проблем

Общие проблемы при построении инфраструктуры

Общие проблемы при использовании инфраструктуры

Сбор сведений для обращения в службу поддержки

286 Глава12

12 .1 . Базовая информация, предоставляемая MQ Приведенные ниже источники информации помогут устранить проблемы с Web­Sphere MQ следующего рода:

неудачное завершение управляющей команды WebSphere MQ;

неудачное завершение операции WebSphere MQ Explorer;

неудачное завершение программы­примера WebSphere MQ;

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

невозможность отправки или получения сообщений приложением;

невозможность взаимодействия между менеджерами очередей;

неудачное завершение попыток программного выполнения различных действий над WebSphere MQ.

12 .1 .1 . Сообщения AMQXXXXСообщения, отображаемые администратору инфраструктуры WebSphere MQ в ответ на выполняемые им действия, а также при различных событиях, помечаются иденти­фикаторами вида AMQXXXX.

К их числу относятся сообщения об успешном и неудачном завершении действий, выполняемых в WebSphere MQ Explorer, а также управляющих команд WebSphere MQ и команд MQSC. Также выводятся сведения о работе менеджера очередей, которые заносятся в его журнал ошибок.

Идентификаторы этих сообщений состоят из подстроки AMQ и четырех цифр; допустимы идентификаторы из диапазона AMQ4000–AMQ9999.

Для любого сообщения WebSphere MQ можно получить дополнительную информа­цию (более подробное разъяснение обстоятельств генерации сообщения и рекомен­дуемые ответные действия).

Методы получения дополнительной информации следующие:

поиск идентификатора сообщения в руководстве WebSphere MQ Messages, GC34­6601;

исполнение команды mqrc с идентификатором сообщения в качестве параметра на машине с WebSphere MQ, например:

mqrc AMQ4002

12 .1 .2 . Коды причины При неудачном или неполном завершении любого программного действия над WebSphere MQ приложению возвращается код, называемый кодом причины (reason code).

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

Устранениенеполадок 287

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

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

Параметром этой команды является десятичное значение кода, либо его шестнадца­теричное представление, предваренное знаками 0x, либо имя кода. В ответ на ввод одного из представлений кода команда возвращает остальные представления.

Подробнее об отдельных кодах причины см. в руководстве WebSphere MQ Messages, GC34­6601.

Получение кодов причин при использовании MQI и объектно-ориентированных API

Коды причин возвращаются непосредственно в ответ на действия над менеджерами очередей, выполняемые при помощи MQI API и других API, основанных на объектной модели WebSphere MQ. Описание кодов причин, возвращаемых при вызове функций MQI, приведено в WebSphere MQ Application Programming Reference, SC34­6596.

Получение кодов причины при использовании стандартных API, таких как JMS

При использовании стандартных API, например JMS, коды причины WebSphere MQ не описаны в стандартах на данные API. Однако код причины WebSphere MQ может содержаться в стандартном описании сбоя, предоставляемом приложению. Напри­мер, при использовании JMS API для взаимодействия с WebSphere MQ в описании Java­исключений могут содержаться коды причины WebSphere MQ.

12 .1 .3 . Журналы ошибок менеджеров очередейЖурнал ошибок менеджера очередей — основной источник информации о работе менеджера очередей.

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

Журналы ошибок менеджера очередей предоставляют весьма полезную информацию о том, как он функционирует. Администраторам WebSphere MQ рекомендуется регу­лярно изучать журналы менеджеров очередей, подобно тому как системным адми­нистраторам рекомендуется анализировать журналы ОС.

12 .1 .4 . Системные журналы ошибок WebSphere MQНекоторые операции по взаимодействию с инфраструктурой WebSphere MQ не сво­дятся к взаимодействию с отдельными менеджерами очередей. Например, когда попытка приложения подключиться к менеджеру очередей в режиме клиента окан­чивается неудачей, с точки зрения этого приложения информация об этом сбое не связана с менеджером очередей.

288 Глава12

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

Журналы ведутся как клиентами, так и серверами WebSphere MQ.

12 .1 .5 . Расположение журналов ошибок Журналы ошибок располагаются в следующих каталогах.

В Windows:

– журналы ошибок менеджеров очередей:

C:\Program Files\IBM\WebSphere MQ\Qmgrs\Имя_менеджера_очередей\errors

– системные журналы ошибок 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\Qmgrs\@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.15.

12 .1 .6 . Технология FFST При возникновении в менеджере очередей WebSphere MQ неожиданных событий, которые могут повлиять на его работоспособность, генерируется отчет FFST (first­failure support technology).

Часть сведений из отчета FFST опытный администратор WebSphere MQ может про­читать непосредственно, остальная информация описывает состояние внутренних механизмов WebSphere MQ на момент сбоя. Эти сведения весьма полезны представи­телям службы IBM Service для диагностики сбоев WebSphere MQ.

Желательно хранить FFST­файлы в течение некоторого времени, поскольку полный набор таких файлов существенно облегчит диагностику неполадок представителям службы IBM Service. FFST­файлы создаются незадолго до проявления первых симпто­мов проблемы, и потому они могут быть полезны при анализе ее причин. FFST­отче­

Устранениенеполадок 289

ты генерируются не только при сбоях WebSphere MQ, но и при других неожиданных событиях. Регулярно проверяйте наличие FFST­файлов.

12 .1 .7 . Документация по WebSphere MQВ документации по WebSphere MQ содержится справочная информация об админист­рировании WebSphere MQ и разработке приложений, использующих инфраструктуру WebSphere MQ.

Обзор содержимого документации см. ниже в разделе «Публикации на смежные темы», а также в руководстве WebSphere MQ Bibliography and Glossary, SC34­6603.

Документация по WebSphere MQ V6.0 также доступна в виде библиотеки Information Center, поддерживающей удобный поиск (поставляется на носителе с WebSphere MQ), см. также Web­страницу:

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp

12 .2 . Устранение известных неполадок WebSphere MQ — устоявшийся программный продукт с солидным контингентом пользователей. Весьма вероятно, что проблемы, с которыми вы столкнулись при построении инфраструктуры WebSphere MQ или при попытке выполнения админи­стративных действий либо программных операций, уже возникали у других пользо­вателей.

Возможно, эта проблема устраняется модификацией WebSphere MQ посредством APAR, изменением конфигурации инфраструктуры WebSphere MQ либо кода исполь­зующего ее приложения, а также путем изменений других аппаратных и программ­ных компонентов инфраструктуры.

12 .2 .1 . Сайт поддержки WebSphere MQ Вся информация IBM по технической поддержке WebSphere MQ доступна через цент­ральный Web­сайт:

http://www.ibm.com/software/integration/wmq/support/

На этом сайте имеется документация по WebSphere MQ, база с поисковым интерфей­сом, содержащая информацию о всех ранее устраненных неполадках в WebSphere MQ, также возможна загрузка пакетов SupportPacs для WebSphere MQ и исправлений для WebSphere MQ.

12 .2 .2 . Установка исправлений и обновленийIBM регулярно выпускает пакеты исправлений для WebSphere MQ. Важно постоянно устанавливать эти пакеты на всех экземплярах WebSphere MQ в составе инфраструк­туры WebSphere MQ.

Регулярная установка исправлений даже при отсутствии соответствующих проблем защищает инфраструктуру WebSphere MQ от сбоев из­за возникновения известных неполадок.

290 Глава12

Примечание.  Любыеизмененияинфраструктурыиприложений,атакжеисправления,рекомендуетсясначалаиспытыватьвтестовойсредеилишьпотомразвертыватьвпроизводственнойсреде.ТожевернодляисправленийWebSphereMQ.

Подробнее о доступных обновлениях и исправлениях для WebSphere MQ см. на Web­странице технической поддержки WebSphere MQ.

Перед установкой исправления изучите его документ readme. В нем содержится опи­сание проблемы, которое оно устраняет, а также история неполадок, которые устра­няются исправлениями, ранее выпущенными для данной версии WebSphere MQ.

В readme также могут содержаться дополнения к документации WebSphere MQ и осо­бые сведения, которые могут касаться работы WebSphere MQ в вашей среде.

Примечание.  ОпределитьтекущуюверсиюWebSphereMQисостояниеустановленныхисправленийвWindowsиUNIXможноприпомощиуправляющейкомандыdspmqver.

КомандавозвращаетинформациювидаVersion.Release.Modification.Fixpack.

НаiSeriesдлятойжецелииспользуюткомандуCALLQMQM/DSPMQVER.

12 .2 .3 . «Молнии» При выпуске каждого обновления или важного промежуточного исправления, допол­няющего пакет исправлений, всем пользователям, зарегистрированным на сайте технической поддержки IBM, рассылаются уведомления­«молнии» (flashes). Каждому администратору WebSphere MQ рекомендуется подписаться на эти уведомления. Для этого зарегистрируйтесь на сайте технической поддержки IBM и добавьте WebSphere MQ в список продуктов на своей персональной странице.

12 .2 .4 . Поиск APAR и Technote Среди прочего доступна база знаний с решениями распространенных проблем, советами и инструкциями. Документ этой базы называется «technote» (техническая записка).

Поисковый интерфейс на сайте поддержки WebSphere MQ обеспечивает поиск в базах APAR и Technotes.

12 .2 .5 . Дополнительные источники информации В Интернете доступно множество источников сведений о WebSphere MQ, включая группы новостей, форумы и даже специализированные Web­сайты.

На Web­сайте IBM developerWorks® можно найти ссылки на множество подобных ресурсов, подробнее см. на Web­странице:

http://www.ibm.com/developerworks/websphere/community

Устранениенеполадок 291

12 .2 .6 . Модуль Healthcheck для WebSphere MQ Explorer Подключаемый модуль Healthcheck для WebSphere MQ Explorer расширяет возмож­ности WebSphere MQ Explorer. Этот модуль анализирует конфигурацию всех менед­жеров очередей, подключенных к WebSphere MQ Explorer, в поисках потенциальных проблем.

Модуль WebSphere MQ Explorer Healthcheck поставляется в составе пакета SupportPac MH01, доступного по адресу

http://www.ibm.com/support/docview.wss?rs=171&uid=swg24­010096

12 .3 . Общие проблемы при построении инфраструктуры

В этом разделе приводятся действия по диагностике и разрешению проблем, возни­кающих при наладке взаимодействия менеджеров очередей.

12 .3 .1 . Устранение неполадок распределенных каналов сообщенийДля диагностики проблем с взаимодействием менеджеров очередей через объявлен­ные вручную каналы рекомендуется выполнить следующие действия.

Проверьте, соответствуют ли имена объектов­каналов на обоих концах соедине­ния; учтите, что имена каналов чувствительны к регистру.

Убедитесь, что на обоих концах соединения в менеджере очередей нет записей состояния STOPPED для данных каналов. Такая запись свидетельствует о том, что канал отключен. Чтобы включить канал, запустите его соответствующей коман­дой, отданной объектам канала в менеджерах очередей, содержащих записи состояния STOPPED. Для просмотра всех записей состояния канала в WebSphere MQ Explorer щелкните канал правой кнопкой и выберите команду Status\Current Status.

Убедитесь в совместимости типов объекта MCA отправителя, извлекающего сооб­щения из транспортной очереди, и MCA получателя, доставляющего сообщения в очереди менеджера­адресата (см. раздел 7.4.10).

Проследите, чтобы в атрибуте «имя подключения» (CONNAME) объекта канала MCA, используемого для соединения, был указан IP­адрес или хост­имя машины, на которой работает менеджер очередей, с которым нужно наладить взаимодейст­вие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).

Убедитесь, что в атрибуте «имя подключения» (CONNAME) объекта канала MCA, используемого для соединения, указан порт, соответствующий порту слушателя менеджера очередей, с которым нужно наладить взаимодействие. Проверьте связь с этой машиной при помощи команды ОС ping (с обоих концов соединения, для любого канала из пары).

1.

2.

3.

4.

5.

292 Глава12

Выполните команду WebSphere MQ ping для проверки связи через канал. Если эта проверка окончится неудачей, проверьте журналы ошибок обоих менеджеров очередей.

Убедитесь, что в атрибуте «транспортная очередь» (XMITQ) объекта канала, опреде­ляющего MCA отправителя, указано имя объекта локальной очереди, объявленно­го в том же менеджере очередей (учтите, что имена объектов чувствительны к ре­гистру).

Убедитесь, что атрибут USAGE этого объекта локальной очереди определяет эту очередь как транспортную (имеет значение XMITQ).

Попытайтесь запустить канал вручную.

Если канал не запускается, проверьте журналы ошибок обоих менеджеров очере­дей.

Проверьте, существует ли очередь недоставленных сообщений в менеджере оче­редей, в котором работает MCA получателя. Если в транспортной очереди накап­ливаются постоянные сообщения, которые не могут быть переданы получателю из­за ошибок доставки, то в отсутствие очереди недоставленных сообщений канал переходит в состояние RETRYING, а затем – в состояние STOPPED.

Проверьте, не указана ли одна и та же транспортная очередь у двух объектов кана­ла в данном менеджере очередей.

Если для данных каналов есть запись о статусе, проверьте, не содержит ли ее атри­бут «неоднозначное состояние» (INDOUBT) значение YES.

12 .3 .2 . Устранение неполадок инициации каналов сообщенийДля диагностики проблем с инициацией распределенных каналов сообщений реко­мендуется выполнить следующие действия (предварительно убедитесь, что наладить связь через эти каналы вручную удается).

1. Убедитесь, что атрибут «управление триггером» (TRIGGER) задан для объекта локаль­ной очереди, использующейся в качестве транспортной очереди, из того же менеджера очередей, что используется объектом канала отправителя. В данном случае этот объект представляет транспортную очередь.

2. Проследите, чтобы атрибуту «тип триггера» (TRIGTYPE) транспортной очереди было присвоено значение FIRST или DEPTH.

3. Если триггер срабатывает на определенную длину очереди (DEPTH), убедитесь, что значение TRIGDPTH настроено соответствующим образом.

4. Убедитесь, что атрибуты «данные триггера» (TRIGDATA) и «процесс» (PROCESS) транс­портной очереди содержат имя объекта канала отправителя (имена объектов чувствительны к регистру).

5. Проследите, чтобы атрибуту «очередь инициации» (INITQ) транспортной очереди было присвоено значение SYSTEM.CHANNEL.INITQ.

6.

7.

8.

9.

10.

11.

12.

13.

Устранениенеполадок 293

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

6. Убедитесь, что инициатор каналов в менеджере очередей активен. В WebSphere MQ V6.0 для этого используется команда MQSC DISPLAY QMSTATUS CHINIT, альтернатив­ный вариант – щелкнуть правой кнопкой менеджер очередей в WebSphere MQ Explorer и выбрать Status.

7. Проверьте, правильно ли установлен атрибут «интервал отключения» (DISCINT) объекта канала отправителя.

8. Вручную запустите канал, чтобы передать все сообщения из транспортной очере­ди удаленному менеджеру очередей.

9. Дождитесь истечения интервала отключения канала либо остановите его вручную, установив целевой статус (STATUS) канала в INACTIVE.

10. Добавьте сообщение в очередь удаленного менеджера очередей. В результате сообщение будет добавлено в транспортную очередь, и менеджер очередей авто­матически запустит канал.

12 .3 .3 . Устранение неполадок кластерных каналов сообщений Ниже рассказывается о разрешении проблем, возникающих при добавлении менед­жера очередей к кластеру (см. раздел 8.3.3), удалении менеджера очередей из кластера (см. раздел 8.3.4). В частности, освещается устранение неполадок кластерных каналов сообщений. Чаще всего они возникают из­за неверной настройки атрибутов объек­тов кластерных sender­ и receiver­каналов.

Общий симптом таких проблем — наличие строк следующего вида в выводе команд DISPLAY CLUSQMGR либо в папке Clusters, отображаемой WebSphere MQ Explorer.

SYSTEM.TEMPQMGR.имя_хоста(порт)

Обычно они возникают из­за проблем с подключением к кластеру либо повторным подключением с помощью команды REFRESH CLUSTER с параметром REPOS(YES).

Примечание.  Обычноизменениявручнуюобъявленногообъекта кластерногоsender-канала,используемогодлясвязисполнымрепозиторием,недействуютпослевводасоответствующегоменеджераочередейвкластер.Атрибутыэтогообъектапереопределяютсязначениямипараметровавтоматическисоздаваемогообъектакластерногоsender-каналанаосновеобъектакластерногоreceiver-канала,объявленноговменеджереочередей,обслуживающегополныйрепозиторий.

Важная особенность кластера менеджеров очередей заключается в том, что каждый менеджер в его составе должен взаимодействовать с другими через подключение, имя которого указано в объекте кластерного receiver-канала, объявленного в этом менеджере очередей кластера.

Чтобы изменить имя этого подключения, удалите менеджер очередей из всех класте­ров, в которые он входит, используя объект кластерного receiver-канала, внесите

294 Глава12

изменения и верните менеджер очередей в кластер. Не рекомендуется изменять имя объекта кластерного receiver-канала, пока этот объект опубликован в кластере.

Для кластерных каналов верно многое из того, что сказано о распределенных sender­каналах. Всегда начинайте с проверки каналов между менеджерами очередей полных репозиториев кластера. Далее проверьте каналы между менеджерами очередей час­тичных и полных репозиториев кластера. Лишь убедившись в работоспособности этих каналов, переходите к проверке каналов между менеджерами очередей частич­ных репозиториев.

Для каждой пары менеджеров очередей кластера проверьте следующее:

для менеджера очередей с полным репозиторием проверьте, что атрибуты «репо­зиторий» (REPOS) или «список имен репозиториев» (REPOSNL) объекта менеджера очередей содержат верные имена кластера или объекта списка имен (namelist). Имена этих объектов чувствительны к регистру. Если используется список имен, проверьте наличие имени кластера в его атрибуте «имена» (NAMES);

убедитесь, что у обоих менеджеров очередей имеется активный слушатель;

проверьте, содержат ли атрибуты «кластер» (CLUSTER) или «список имен кластеров» (CLUSNL) объектов кластерных sender­ и receiver-каналов верные имена кластера и объекта списка имен. Если используется список имен, проверьте наличие имени кластера в его атрибуте «имена» (NAMES);

исполните MQSC­команду DISPLAY CLUSQMGR(*) на обоих менеджерах очередей. Убедитесь, что в выводе команды отсутствуют строки вида SYSTEM.TEMPQMGR.имя_хоста(порт). Их наличие свидетельствует о неудаче добавления менеджера очередей к кластеру по одной из двух причин.

– Сбой кластерного sender-канала, объявленного вручную.

Эти неполадки препятствуют подключению к менеджеру очередей, обслужи­вающему полный репозиторий. Убедитесь, что имя объекта кластерного sender-канала соответствует имени объекта кластерного receiver-канала, объяв­ленного в менеджере очередей, обслуживающем полный репозиторий. Про­верьте, пригодно ли заданное хост­имя, IP­адрес и порт для связи с менедже­ром очередей, обслуживающим полный репозиторий.

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

– Сбой кластерного receiver-канала.

Эти неполадки препятствуют подключению менеджера очередей, обслужива­ющего полный репозиторий. Проверьте имя подключения, заданного для объ­екта кластерного receiver-канала. Рекомендуется сбросить атрибуты CLUSTER и CLUSNL (записав в них пустую строку) до внесения любых изменений в имя подключения;

убедитесь в доступности хост­имени и IP­адреса, заданного в атрибуте «имя под­ключения» (CONNAME) объекта кластерного receiver-канала в обоих менеджерах оче­

Устранениенеполадок 295

редей. Для проверки связи можно использовать команду ОС ping. Проверьте также порты слушателей менеджеров очередей;

проверьте журналы ошибок обоих менеджеров очередей;

выполните команду MQSC DISPLAY CHSTATUS(*) над обоими менеджерами очере­дей. Попробуйте найти каналы, у которых статус отличается от RUNNING (например, каналы в состоянии RETRYING), а также каналы, атрибут состояния INDOUBT у которых равен «YES»;

если пара менеджеров очередей обслуживают частичные репозитории, они могут иметь доступ к менеджерам, обслуживающим полные репозитории кластера, и не иметь доступа друг к другу. Чтобы открыть доступ к удаленному частичному репо­зиторию, следует объявить на нем объект локальной очереди. Чтобы опубликовать этот объект в кластере, запишите имя кластера в его атрибут «кластер» (CLUSTER). Добавьте сообщение в эту очередь, используя программу­пример amqsput, под­ключившись к локальному частичному репозиторию. Если эта операция заверши­лась успешно, команда DISPLAY CLUSQMGR(*), отданная на локальном частичном репозитории, отображает сведения об удаленном частичном репозитории.

12 .4 . Общие проблемы с доступом к инфраструктуре В этом разделе рассказывается о диагностике и разрешении проблем, возникающих при обращении к инфраструктуре WebSphere MQ.

12 .4 .1 . Устранение сбоев подключения к менеджеру очередей Диагностику неполадок, связанных с подключением приложений к менеджерам оче­редей, рекомендуется выполнять следующим образом.

1. Убедитесь, что менеджер очередей работает, например так:

– с помощью команды dspmq (в Windows и UNIX) либо WebSphere MQ Explorer;

– с помощью команды WRKMQM (в iSeries).

2. Изучите код возврата операции подключения.

3. В случае клиентских приложений убедитесь, что у целевого менеджера очередей работает слушатель. Убедитесь в том, что для менеджера очередей указан верный транспорт (обычно TCP) и имя подключения. Если используется таблица CCDT, проверьте, верно ли указан путь к ней. Для JMS­приложений его указывают в объ­екте connection factory в каталоге, к которому обращаются через JNDI. Этот ката­лог должен быть доступен приложению.

4. Для клиентских приложений проверьте, соответствует ли имя используемого канала имени канала серверного подключения из менеджера очередей; также проверьте, включено ли автоопределение канала (channel auto­definition, CHAD) для этого менеджера очередей. В любом случае имена каналов должны совпадать (учтите: имена каналов чувствительны к регистру).

5. Проверьте правильность (вплоть до регистра) имени менеджера очередей, ука­занного приложением. Для клиентских приложений, подключающихся с исполь­зованием CCDT, проверьте правильность значения атрибута «имя менеджера оче­

296 Глава12

редей» (QMNAME) объекта клиентского подключения, объявленного в менеджере очередей, создавшем CCDT.

6. Изучите системные журналы ошибок WebSphere MQ.

7. Проанализируйте журналы ошибок менеджера очередей, чтобы определить, в ка­ком компоненте возникают сбои.

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

Примечание. Дляклиентскихприложенийрекомендуетсяопределятьатрибут«идентификаторпользователяMCA»(MCAUSER)дляобъектаканаласерверногоподключения.Врезультатеприложениебудетподключатьсясиспользованиемэтогоименипользователянезависимооттого,подкакимименемоноработаетналокальнойсистеме.Витогеприложениевсегдабудетпользоватьсявотноше-ниименеджераочередейполномочиями,назначеннымиэтомуидентификаторупользователя.

12 .4 .2 . Устранение неполадок отправки сообщений Диагностику неполадок, не позволяющих открывать очереди и размещать в них сообщения, рекомендуется выполнять следующим образом.

1. Изучите код возврата операций открытия очереди и размещения сообщений.

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

3. Убедитесь, что целевая очередь доступна менеджеру очередей, существует необ­ходимая транспортная очередь и объявлен локальный объект удаленной очереди.

4. Если целевая очередь обслуживается менеджером очередей в составе кластера, убедитесь, что ее объект опубликован в кластере удаленным менеджером очере­дей, а также в наличии у обоих менеджеров очередей связи с полным репозитори­ем кластера.

5. Проверьте правильность параметров, с которыми приложение открывает очередь, в частности убедитесь, что очередь открывается для вывода.

6. С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указанным приложением. Убеди­тесь, что учетная запись, под которой приложение пытается подключиться, обла­дает полномочиями для добавления сообщений в нужную очередь. Чтобы опреде­лить контекст приложения, можно вывести сведения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.

7. Проверьте параметры добавляемого сообщения, в частности указана ли точка синхронизации (syncpoint), определяющая включение добавления сообщения в единицу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.

Устранениенеполадок 297

8. Проверьте, что во всех очередях на пути к очереди назначения разрешен вывод.

9. Убедитесь, что значения атрибутов «максимальная длина сообщений» (MAXMSGL) локальной очереди и всех транспортных очередей, а также менеджера очередей достаточно велики.

10. Изучите журналы ошибок менеджера очередей, к которому подключено приложе­ние.

12 .4 .3 . Устранение неполадок извлечения сообщений Диагностику неполадок, не позволяющих открывать очереди и получать из них сооб­щения, рекомендуется выполнять следующим образом.

1. Изучите код возврата операций открытия очереди и извлечения сообщений.

2. Убедитесь, что в менеджере очередей, к которому подключено сообщение, сущест­вует подходящий объект локальной очереди или модельной очереди.

3. Проверьте правильность имени объекта, указанного приложением, открывающим очередь (учтите, что имена объектов чувствительны к регистру).

4. Проверьте правильность параметров, с которыми приложение открывает очередь. В частности, очередь должна открываться для ввода, ввода с монопольным досту­пом или для просмотра. С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указан­ным приложением. Убедитесь, что учетная запись, под которой приложение пытается подключиться, обладает полномочиями для извлечения сообщений из нужной очереди. Чтобы определить контекст приложения, можно вывести све­дения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.

5. Проверьте правильность параметров получения сообщений, в частности указана ли точка синхронизации, определяющая включение извлечения сообщения в еди­ницу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.

6. Убедитесь, что буфер, предоставляемый приложением, достаточно велик для при­ема сообщения (если только параметры извлечения не допускают прием усечен­ных сообщений).

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

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

298 Глава12

Примечание. Еслиполюversionвструктуре,содержащейпараметрыизвле-чениясообщений,неприсвоенозначение2или3,апараметрыпоисканеопреде-лены,идентификаторсообщенияикорреляционныйидентификатор,которыепередаютсяоперацииget,необходимосбрасыватьпослеизвлечениякаждогосообщения.

8. Убедитесь, что отправка требуемых сообщений в очередь зафиксирована. Воз­можные причины возникновения незафиксированных сообщений: приложение не зафиксировало единицу работы после размещения сообщения под управлени­ем точки синхронизации; канал связи с менеджером очередей находится в состоя­нии INDOUBT; другое приложение получило сообщение под управлением точки синхронизации, но не зафиксировало единицу работы.

Примечание.  ПроверитьналичиенезафиксированныхсообщенийвочередиможноприпомощикомандыMQSCDISPLAYQSTATUSлибощелкнувправойкнопкойочередьвWebSphereMQExplorerивыбравStatus.

9. Изучите журналы ошибок менеджера очередей, к которому подключено приложе­ние.

12 .4 .4 . Устранение общих неполадок триггеров Существует ряд правил для триггеров, исполнение которых необходимо для генера­ции триггерных сообщений в очереди инициации при поступлении сообщений в очередь, для которой происходит инициация. Подробнее см. в разделе «Starting WebSphere MQ applications using triggers» руководства WebSphere MQ Application Programming Reference, SC34­6596.

12 .4 .5 . Поиск сообщений, отправленных в инфраструктуру Менеджеры очередей поддерживают механизм под названием трассировка (trace-route), позволяющий тестировать маршруты, пролегающие сквозь инфраструктуру менеджеров очередей WebSphere MQ V6.0, которые возвращают трассировочную информацию приложению trace­route.

Trace­route использует функции отчетов об активности, поддерживаемые менед­жерами очередей WebSphere MQ V6.0. Эта функция заключается в генерации компо­нентами менеджера очередей, такими как MCA, отчетов об активности при выполне­нии любых действий над сообщениями.

Подробнее о trace­route и отчетах об активности см. в разделе «Message monitoring» руководства Monitoring WebSphere MQ, SC34­6593.

Общие методы поиска сообщений

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

Устранениенеполадок 299

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

2. Убедитесь, что у всех менеджеров очередей настроены очереди недоставленных сообщений. Проверьте эти очереди, просмотрев их.

3. Проверьте наличие в маршруте каналов с состоянием, отличным от RUNNING, либо с неопределенным состоянием (неактивных каналов).

4. Просмотрите транспортную очередь менеджера очередей, к которому приложе­ние было подключено в момент генерации сообщения, затем проверьте следую­щие транспортные очереди на потенциальном маршруте приложения (в случае кластера менеджеров очередей – SYSTEM.CLUSTER.TRANSMIT.QUEUE).

5. Убедитесь, что для всех менеджеров очередей, транспортных очередей, каналов и целевых очередей назначения указана достаточно большая максимальная длина сообщения (особенно если размер сообщения больше 4 Мб).

6. Проверьте наличие незафиксированных сообщений во всех транспортных оче­редях и целевой очереди. Если таковые обнаружатся, проверьте, нет ли каналов в состоянии INDOUBT и приложений с незафиксированными единицами работы, содержащими операции получения данных сообщений.

Маршрутизация сообщений по инфраструктуре

Сообщения могут следовать по инфраструктуре (или взаимосвязанным инфраструк­турам) сложным маршрутом. Разрешение имен очередей выполняется независимо для каждого менеджера очередей, в результате этой операции определяется следую­щий этап маршрута к точке назначения сообщения.

Первый менеджер очередей (к нему подключено приложение, отправившее сообще­ние) выполняет разрешение имени очереди по именам объекта и объекта менеджера очередей, заданным во время открытия очереди для размещения в ней сообщений.

Для следующих на маршруте сообщения менеджеров разрешение имен очередей выполняется на основе имени очереди, а также имени менеджера очередей, получен­ного предыдущим менеджером в результате разрешения имен. Эта информация передается по каналу в заголовке транспортной очереди. Агент канала­приемника (MCA) открывает нужную очередь, ориентируясь на сведения из этого заголовка, аналогично тому, как это делают приложения.

Для разрешения имен очередей все менеджеры используют объекты очередей, рас­положенных в этом менеджере, такие как локальные очереди, назначенных с помо­щью атрибутов транспортными, объекты псевдонимов очередей и удаленных очере­дей. Объекты удаленных очередей выполняют три отдельные задачи в разрешении имен: локальное описание удаленных очередей, псевдонимы менеджеров очередей и псевдонимы очередей ответов.

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

300 Глава12

12 .5 . Сбор сведений для обращения в сервисную службу

Если компоненты WebSphere MQ работают не так, как описано в документации, во время выполнения административных действий генерируются сообщения AMQXXXX и коды причин, указывающие на возникновение неполадок, а журналы менеджера очередей и системные журналы WebSphere MQ содержат сообщения об ошибках, возможно, вам придется обратиться в службу IBM Service.

Причиной этих неполадок могут быть проблемы, возникшие при построении инф­раструктуры WebSphere MQ, разработке приложений для доступа к этой инфраструк­туре, а также сбои, выявленные в ходе тестирования или эксплуатации приложения.

В этих случаях необходимо тщательно задокументировать сбой, чтобы представите­ли службы IBM Service смогли успешно устранить его.

12 .5 .1 . Составление описания проблемыНаличие технического описания, включающего сводку симптомов неполадки, сни­жает шансы неверной интерпретации собранных сведений. После обращения в службу IBM Service вам, возможно, придется работать с разными специалистами.

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

Представить четкое техническое описание проблемы для специалистов из вашей компании и службы IBM Service поможет Problem Management Record, PMR. Сводку PMR, подготовленную в электронном виде, можно передать представителям IBM, при этом вам не придется устно объяснять суть проблемы.

Подать PMR в электронном виде можно на сайте:

http://www.ibm.com/software/support/probsub.html

После подачи сведений о проблеме PMR становится основным источником сведений о ней. Представители IBM Service заносят в PMR результаты всех выполненных ими анализов.

12 .5 .2 . Описание окруженияПодробно опишите окружение, в котором возникла проблема. Непременно включите следующую информацию:

аппаратную платформу всех используемых компьютеров;

ОС на всех используемых машинах, включая установленные обновления;

номер версии WebSphere MQ;

сведения о всех установленных обновлениях и исправлениях WebSphere MQ.

Устранениенеполадок 301

12 .5 .3 . Описание использования WebSphere MQ Чрезвычайно полезной информацией является контекст, в котором возникает наблюдаемая проблема. Максимально подробно опишите, какие действия над про­граммой и в каких обстоятельствах вызывают неполадки. Чем подробнее будут пре­доставленные сведения, тем эффективнее будет диагностика проблемы. Примерное содержание описания приводится ниже.

Сколько машин, менеджеров очередей и приложений содержится в инфраструк­туре?

Подключаются ли приложения к менеджерам очередей напрямую (через связыва­ние) либо через клиентские подключения? В последнем случае идентичны ли платформа и ОС, на которых работают приложения и менеджер очередей?

На каком языке программирования написаны приложения?

Используют ли приложения MQI API непосредственно, через API, соответствую­щий объектной модели WebSphere MQ, либо через стандартный API, такой как JMS?

Работают ли приложения непосредственно в ОС либо в сервере приложений или другой исполняющей среде?

Каковы задачи приложения или административных действий, вызвавших непо­ладки? Включите в их описание максимум технической информации, включая перечень вызовов MQI, команд MQSC и управляющих команд WebSphere MQ.

12 .5 .4 . Подготовка описания сбоя для отправки в IBM Service Перечень документов, которые необходимо подготовить для описания возникших неполадок, см. в технической записке (Technote) «MustGather: Read first for all Web Sphere MQ v5.3, v5.3.1, and v6.0 products», доступной по адресу

http://www.ibm.com/support/docview.wss?rs=171&uid=swg21177923

12 .5 .5 . Воспроизведение неполадокВозникновение неполадок может быть связано с попытками выполнения определен­ных действий. В этом случае можно попробовать повторить эти действия, чтобы воспроизвести неполадки.

Если удается воспроизвести проблему в упрощенной инфраструктуре WebSphere MQ, состоящей из одного или нескольких менеджеров очередей, желательно предоста­вить IBM Service соответствующие сведения.

Впрочем, воспроизвести аномальные сбои в производственной среде, а также выяс­нить их причины порой бывает сложно, поскольку такие эксперименты негативно отразятся на ее работе. В итоге воспроизвести наблюдаемые неполадки в рабочей среде удается не всегда.

В подобных случаях весьма удобно иметь тестовую лабораторию, максимально похо­жую на производственную среду, поскольку в ней можно смоделировать возникнове­ние неполадок.

302 Глава12

В FFST и журналах ошибок WebSphere MQ можно найти подробные сведения о непо­ладках. Данные, зарегистрированные в этих источниках в момент возникновения неполадок, значительно расширяют возможности представителей IBM Service по диагностике и устранению сбоев в случаях, когда воспроизвести их не удается.

12 .5 .6 . Трассировка WebSphere MQИнфраструктура WebSphere MQ и работа с ней могут быть довольно сложными и специализированными под конкретные бизнес­требования. Моделирование непола­док на машинах IBM не всегда эффективно, поскольку они не настроены под особен­ности использования WebSphere MQ в конкретной компании.

Трассировка — мощная функция WebSphere MQ, позволяющая регистрировать все внутренние операции WebSphere MQ в файлах журналов, которые можно отправить в IBM Service для анализа.

Это позволит IBM Service тщательно проанализировать проблему без использования машины клиента и внесения изменений в его среду.

Трассировку можно запускать и останавливать, не прерывая работы менеджеров оче­редей.

Если удается воспроизвести неполадки в тестовой среде, следует запустить трасси­ровку перед выполнением действий, ведущих к возникновению проблемы, а затем остановить трассировку. Полученные трассировочные данные вместе с FFST, журна­лами ошибок менеджеров очередей и системными журналами ошибок WebSphere MQ, полученными на машинах, где возникают сбои, следует передать для анализа в службу технической поддержки IBM.

Трассировка всех действий WebSphere MQ снижает производительность инфраструк­туры WebSphere MQ, поэтому желательно использовать трассировку во время моде­лирования сбоев в тестовой среде, а не в производственной. Если такая возможность недоступна и воспроизвести неполадки можно лишь в производственной среде, воз­можно, в ней же придется активировать и трассировку.

Если установить, какое действие вызывает неполадки, не удается, трассировка работы WebSphere MQ во время их возникновения поможет представителям IBM Service в диагностике.

Трассировка в Windows

На платформе Windows запустить трассировку всех действий WebSphere MQ можно следующей командой:

strmqtrc -t detail -t all

Останавливает трассировку команда

endmqtrc

В WebSphere MQ V6.0 трассировочные файлы хранятся в каталоге C:\Program Files\IBM\WebSphere MQ\Trace, в WebSphere MQ V5.3 — в каталоге C:\Program Files\IBM\WebSphere MQ\Errors.

Устранениенеполадок 303

О настройке максимального размера трассировочных файлов см. в разделе «Problem determination» руководства WebSphere MQ Application Programming Guide, SC34­6595.

Трассировка в UNIX

На платформе UNIX запустить трассировку всех действий WebSphere MQ можно сле­дующей командой:

strmqtrc -e -t detail -t all

Трассировку отдельного менеджера очередей запускают командой вида

strmqtrc -m имя_менеджера_очередей -t detail -t all

Примечание. Привозникновениисбоеввовремязапускаменеджеровочередейилиподключенииприложениякменеджеруочередейиспользуйтепараметр-e,анеуказывайтеотдельныйменеджерочередей.

Трассировочные файлы создаются в каталоге /var/mqm/trace.

Чтобы содержимое этих файлов было понятно людям, его необходимо отформати­ровать. Для этого перейдите в каталог с трассировочными файлами и выполните команду

dspmqtrc *.TRC

О настройке размера трассировочных файлов см. в разделе «Problem determination» руководства WebSphere MQ Application Programming Guide, SC34­6595.

Трассировка WebSphere MQ для AIX 5L �5 .3

WebSphere MQ для AIX 5L V5.3 использует поддержку трассировки ОС AIX 5L. Эти функции доступны и в WebSphere MQ для AIX 5L V6.0, но рекомендуется использовать вышеописанные функции трассировки WebSphere MQ.

Настройка трассировки WebSphere MQ выполняется так:

MQS_TRACE_OPTIONS=4194303

export MQS_TRACE_OPTIONS

Запустите трассировку, используя трассировочный файл без перезаписи с макси­мальным размером 50 Мб:

trace -a -j30D,30E -o wmq_trace.trc -s -L 52428800

Примечание. Опараметрахкомандыtraceсм.вруководствеAIX5L.

Остановить трассировку можно следующей командой:

trcstop

Отформатировать отдельный трассировочный файл можно так:

trcrpt -t /usr/mqm/lib/amqtrc.fmt wmq_trace.unf > wmq_trace.fmt

304 Глава12

Трассировка в iSeries

На платформе iSeries запустить трассировку всех действий WebSphere MQ можно следующей командой:

TRCMQM TRCEARLY(*YES) SET(*ON) TRCLEVEL(*DETAIL) MAXSTG(8)

Трассировку отдельного менеджера очередей запускают командой вида

TRCMQM SET(*ON) TRCLEVEL(*DETAIL) MAXSTG(8) MQMNAME(ИМЯ_МЕНЕДЖЕРА)

Остановить трассировку можно следующей командой:

TRCMQM SET(*END)

Трассировочные файлы создаются в каталоге /QIBM/UserData/mqm/trace/ файловой системы IFS (integrated file system).

Чтобы содержимое этих файлов было понятно людям, его необходимо отформати­ровать. Для этого в оболочке QShell перейдите в каталог с трассировочными файлами и выполните команду

dspmqtrc *.TRC

О настройке максимального размера трассировочных файлов см. в разделе «Analyzing problems» руководства WebSphere MQ для iSeries V6.0 System Administration Guide, SC34­6586.

z/OS

О поддержке трассировки в WebSphere MQ для платформы z/OS см. в руководстве WebSphere MQ для z/OS V6.0 Problem Determination Guide, GC34­6600.

НовоевWebSphereMQV6 .0 305

A

Новое в WebSphere MQ �6 .0

В этом приложении содержится сводка новых функций IBM WebSphere MQ 6.0 (по сравнению с версией 5.3).

306 НовоевWebSphereMQV6 .0

WebSphere MQ Explorer WebSphere MQ Explorer – это утилита с графическим интерфейсом, предназначенная для мониторинга и администрирования инфраструктуры WebSphere MQ с рабочих станций.

WebSphere MQ Explorer поставляется с WebSphere MQ V6.0 для рабочих станций под управлением Microsoft Windows и Linux (x86), однако этот инструмент можно использовать для администрирования менеджеров очередей, функционирующих на любых платформах, а также прежних версий WebSphere MQ.

WebSphere MQ Explorer поддерживает администрирование менеджеров очередей, функционирующих в WebSphere MQ для z/OS, включая администрирование групп с разделением очередей.

Примечание.  WebSphereMQExplorerподдерживаетудаленноеадминистри-рованиетолькоменеджеровочередейWebSphereMQдляz/OSV6.0.УдаленноеадминистрированиеменеджеровочередейизпрежнихверсийWebSphereMQдляz/OSтакимспособомнеподдерживается.

WebSphere MQ Explorer может подключаться к менеджерам очередей для удаленного администрирования с помощью клиентских подключений, защищенных SSL.

Подробнее о WebSphere MQ Explorer и его базовой технологии Eclipse см. в раз­ деле 5.2.1.

Команды PCF в WebSphere MQ для z/OS �6 .0 Командный сервер менеджеров очередей WebSphere MQ для z/OS V6.0 способен обрабатывать команды PCF (programmable command format), а также команды в фор­мате MQSC, которые поддерживались командными серверами прежних версий Web­Sphere MQ для z/OS.

Помимо удаленного администрирования с помощью WebSphere MQ Explorer эти функции позволяют использовать команды PCF как единый программируемый адми­нистративный интерфейс для управления любыми менеджерами очередей в составе инфраструктуры WebSphere MQ.

64-разрядные менеджеры очередей Наиболее существенное в плане функциональности различие между WebSphere MQ V5.3 и WebSphere MQ V6.0 в AIX 5L, Solaris™ и HP­UX состоит в том, что на этих плат­формах менеджеры очередей теперь являются 64­разрядными.

Это позволяет и 32­, и 64­разрядным приложениям подключаться к таким менедже­рам очередей, используя подключения через связывание. Кроме того, 64­разрядные приложения могут подключаться к 64­разрядным ресурсам, функционирующим на этом компьютере, таким как 64­разрядные базы данных.

НовоевWebSphereMQV6 .0 307

64­разрядным менеджерам очередей также доступен бо ' льший объем памяти, чем 32­разрядным (если позволяет оборудование компьютера), 64­разрядные менеджеры очередей также лучше масштабируются.

На момент написания этой книги 64­разрядные менеджеры очередей в WebSphere MQ V6.0 поддерживались не для всех платформ.

Подробнее о поддержке 64­разрядных платформ в WebSphere MQ V6.0 см. на сайте

http://www.ibm.com/software/integration/websphere/mqplatforms/supported.html

Internet Protocol �ersion 6 (IPv6) В WebSphere MQ Version 6.0 поддерживается взаимодействие менеджеров очередей по протоколу IPv6 (в дополнение к имеющейся поддержке IPv4).

Подробнее об IPv6 и переводе имеющейся инфраструктуры WebSphere MQ на IPv6 см. в руководстве WebSphere MQ Migration Information, SC34­6604.

Изменения в поддержке SSL в Windows В WebSphere MQ для Windows V5.3 используется поддержка SSL, предоставляемая платформой Windows. На других платформах поддержку SSL обеспечивает компо­нент IBM Global Security Toolkit (GSKit).

В WebSphere MQ для Windows V6.0 компонент GSKit также может использоваться для поддержки SSL. Это обеспечивает унификацию платформ и предоставляет WebSphere MQ для Windows дополнительные функции GSKit.

О переводе менеджеров очередей и клиентских приложений WebSphere MQ, исполь­зующих SSL, а также о переносе хранилищ SSL­сертификатов из WebSphere MQ для Windows V5.3 в версию 6.0 см. в руководстве WebSphere MQ Migration Information, SC34­6604.

Усовершенствования SSL и TLS и сертификация FIPS WebSphere MQ V6.0 поддерживает защиту каналов связи по протоколам SSL и TLS, последний используется для защиты всех каналов, у которых значение атрибута «SSL Cipher Specification» (SSLCIPH) начинается с «TLS_».

Примечание.  ДоступныезначенияCipherSpecзависятотплатформы.

WebSphere V6.0 поддерживает регулярную смену статического ключа, применяемого для шифрования данных, которые передаются по каналу после согласования SSL, без остановки и перезапуска канала. Этой функцией управляет атрибут «SSL reset key count» (SSLRKEYC) объекта менеджера очередей.

Также в новой версии появилась поддержка обновления окружения SSL менеджером очередей при помощи MQSC­команды REFRESH SECURITY TYPE(SSL). Эта команда перезапускает все активные SSL­каналы и сбрасывает все кешированные SSL­данные. Ее следует исполнять после каждой смены сертификатов в хранилище ключей менед­

308 НовоевWebSphereMQV6 .0

жера очередей, а также когда требуется выполнить сброс кешированных CRL, полу­ченных от LDAP­сервера.

На платформах Windows и UNIX криптографические модули, применяемые для под­держки SSL и TLS в WebSphere MQ, сертифицированы на соответствие требованиям уровня 140­2 американского стандарта FIPS (для отдельных параметров CipherSpec).

Менеджер очередей можно настроить так, чтобы он разрешал запуск каналов только с CipherSpec, предусматривающим FIPS­совместимую защиту, при помощи атрибута «FIPS required» (SSLFIPS) объекта менеджера очередей.

Подробнее о SSL, TLS, FIPS, CipherSpecs, новых командах MQSC и атрибутах см. в руко­водстве WebSphere MQ Security, SC34­6588.

Встроенный брокер публикации-подписки В прежних версиях WebSphere MQ брокер публикации­подписки поставлялся в виде отдельного пакета SupportPac MA0C.

В WebSphere MQ V6.0 этот компонент входит в стандартную поставку и может быть настроен для автоматического запуска и остановки с менеджером очредей, см. соот­ветствующий раздел.

Теперь брокер публикации­подписки поддерживается для всех платформ, кроме WebSphere MQ для z/OS.

Примечание. Набольшинствеплатформброкерпубликации-подпискиинтегрируетсяприустановкепакетаисправленийWebSphereMQV5.3FixPack8(CSD8).

WebSphere MQ как транспорт для Web-сервисовWebSphere MQ V6.0 поддерживает использование инфраструктуры WebSphere MQ в качестве транспорта для Web­сервисов.

Усовершенствования групп с разделением очередей в z/OS В WebSphere MQ для z/OS поддерживается использование групп с разделением оче­редей для повышения доступности сообщений и служб (см. раздел 5.3.3).

WebSphere MQ для z/OS V6.0 содержит следующие улучшения в этих функциях:

поддерживаются сообщения с размером больше 63 Кб. Раньше в общие очереди не разрешалось добавлять сообщения больше 63 Кб. В WebSphere MQ для z/OS V6.0 это ограничение снято, теперь максимальный размер сообщения — 100 Мб, как и у других очередей WebSphere MQ;

Примечание. Теласообщений,размеркоторыхпревышает63Кб,хранятсявСУБДDB2,аневустройствесопряжения.

НовоевWebSphereMQV6 .0 309

отказоустойчивость в случае повреждения административной структуры в уст­ройстве сопряжения. При использовании групп с разделением очередей сбои административной структуры устройства сопряжения не вызывают остановку менеджеров очередей WebSphere MQ для z/OS V6.0 в составе группы с разделени­ем очередей. Вместо этого работа группы приостанавливается, административная структура автоматически повторно распределяется и перестраивается, и после восстановления работа продолжается.

Балансировка нагрузки в кластерах менеджеров очередей Алгоритм, который используется менеджерами очередей для маршрутизации сооб­щений и балансировки нагрузки в кластере менеджеров, существенно улучшен в WebSphere MQ V6.0.

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

В связи с этими усовершенствованиями в WebSphere MQ V6.0 введены дополнитель­ные атрибуты, которые указывают в определениях объектов кластерных receiver­каналов, публикуемых менеджером очередей в кластере, общих очередей кластера и объектов менеджера очередей.

Подробнее об алгоритме балансировки нагрузки в WebSphere MQ V6.0 см. в раз­ деле 8.4.

Администрирование подключений к менеджеру очередей В WebSphere MQ V5.3 приложения, открывшие заданную очередь, можно было иден­тифицировать при помощи MQSC­команды DISPLAY QSTATUS.

Новые функции WebSphere MQ V6.0 позволяют узнать, какие приложения подключе­ны к менеджеру очередей, способ подключения, а также вывести список очередей, открытых любым приложением. Администратор также может отключать от менедже­ра очередей любые приложения.

Эти функции доступны в окне Application Connections утилиты WebSphere MQ Explorer либо при помощи MQSC­команд DISPLAY CONN и STOP CONN.

Унифицированный метод запуска и остановки слушателей В прежних версиях WebSphere MQ для всех платформ, кроме Windows и z/OS, требо­валось запускать и останавливать слушатели при помощи управляющих команд Web­Sphere MQ либо средств ОС.

В WebSphere MQ для Windows V5.3 для создания, запуска и остановки слушателей применялась оснастка MMC «WebSphere MQ Services», также был возможен автомати­ческий запуск слушателей с менеджером очередей.

310 НовоевWebSphereMQV6 .0

В WebSphere MQ V6.0 на всех платформах, кроме z/OS, слушатели теперь можно администрировать как любые другие объекты WebSphere MQ, созданные для менед­жера очередей.

В результате все функции, ранее поддерживавшиеся только в Windows, стали доступ­ными на всех остальных платформах. Поскольку слушатели являются объектами WebSphere MQ, их администрирование унифицировано на всех платформах и осу­ществляется с помощью GUI­утилиты WebSphere MQ Explorer либо MQSC­команд DEFINE/START/STOP/DISPLAY LISTENER и DISPLAY LSSTATUS.

В Windows слушатели, созданные с помощью оснастки WebSphere MQ Services, авто­матически преобразуются в объекты WebSphere MQ при переносе в менеджер очере­дей новой версии.

Запуск и остановка произвольных служб вместе с менеджерами очередей Помимо поддержки автоматического запуска и остановки слушателя с менеджером очередей в WebSphere MQ V6.0 можно аналогичным способом запускать и останав­ливать приложения, заданные администратором (на всех платформах, кроме Web­Sphere MQ для z/OS).

Это осуществляется путем создания объектов служб (Service) WebSphere MQ, опреде­ляющих способы, а также время запуска и остановки приложений менеджером оче­редей. Также можно использовать WebSphere MQ, чтобы узнать, считает ли ОС рабо­тающим приложение, запущенное с помощью объекта Service.

Эти объекты можно администрировать с помощью GUI­утилиты WebSphere MQ Explorer либо MQSC­команд DEFINE/START/STOP/DISPLAY SERVICE и DISPLAY SVSTATUS.

У каждого менеджера очередей WebSphere MQ V6.0 имеется объект Service, автомати­чески созданный для брокера публикации­подписки WebSphere MQ. Однако по умол­чанию он не настроен для запуска с менеджером очередей. Чтобы настроить брокер для автоматического запуска с менеджером очередей, атрибуту «service control» (CONTROL) объекта Service компонента SYSTEM.BROKER следует присвоить значение «queue manager» (QMGR).

Фильтрация информации о менеджерах очередей В прежних версиях WebSphere MQ разрешалось управлять числом отображаемых объектов, добавляя к некоторым атрибутам MQSC и PCF­команд DISPLAY.

В WebSphere MQ V6.0 эта функциональность существенно расширена и дополнена поддержкой сложных фильтров (поддержка символов обобщения осталась). Теперь фильтрация базируется на именах атрибутов, операторах и значениях. Поддержива­ются операторы сравнения («больше», «меньше» и «равно»).

Например, можно использовать фильтры для отображения очередей с числом сооб­щений больше заданного или каналов с заданным состоянием, например «indoubt».

НовоевWebSphereMQV6 .0 311

Фильтрация доступна в WebSphere MQ Explorer в раскрывающемся списке Filter, рас­положенном над таблицами с объектами. WebSphere MQ Explorer позволяет сохра­нять фильтры для повторного использования. В MQSC­командах DISPLAY теперь можно использовать ключевое слово FILTER, PCF­команды отображения также поддер­живают фильтрацию.

Улучшенный мониторинг в реальном времени В WebSphere MQ V6.0 существенно усовершенствован мониторинг использования инфраструктуры WebSphere MQ, доставки и обработки сообщений в реальном вре­мени.

В состоянии очередей отображается среднее время, в течение которого сообщение ожидает обработки в очереди, а также максимальный срок хранения сообщений. Мониторинг резких изменений этих параметров позволяет заблаговременно выяв­лять проблемы с обработкой сообщений и планировать распределение ресурсов между приложениями, использующими инфраструктуру WebSphere MQ.

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

Учет использования менеджеров очередейWebSphere MQ V6.0 поддерживает генерацию сообщений отчетов со сведениями об использовании менеджеров очередей подключенными к ним приложениями. Эти сообщения генерируются в ответ на события, такие как отключение от менеджера очередей, либо периодически.

Если генерация сообщений отчета включена, эти сообщения будут записываться в формате PCF в соответствующую очередь. Для их обработки и получения сводной статистики в текстовом формате поставляется специальная программа­пример. Ее можно использовать «как есть» либо на основе ее кода написать собственное прило­жение для обработки сообщений отчета.

Подробнее об учете см. в руководстве Monitoring WebSphere MQ, SC34­6593.

Сбор статистикиПомимо вышеописанных сообщений для учета использования менеджеров очередей WebSphere MQ V6.0 способен генерировать сообщения об использовании опреде­ленных ресурсов менеджера очередей.

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

312 НовоевWebSphereMQV6 .0

Сообщения статистики делятся на три категории:

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

сообщения статистики очередей — содержат информацию об использовании определенной очереди, например число поступивших или извлеченных из оче­реди сообщений за прошедший интервал;

сообщения статистики канала — содержат сведения об использовании канала за истекший интервал, например число сообщений, переданных за это время.

Подробнее о сборе статистики см. в руководстве Monitoring WebSphere MQ, SC34­6593.

Трассировка инфраструктуры WebSphere MQ Менеджеры очередей в WebSphere MQ V6.0 способны генерировать сообщения при выполнении любого действия над особым сообщением, помеченным как трассиро­вочное (trace­route message). Трассировочные сообщения автоматически отбрасыва­ются менеджерами очередей WebSphere MQ V6.0 по прибытии в очередь назначения.

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

Эта функциональность обеспечивает трассировку маршрутов сообщений в инфра­структуре WebSphere MQ путем отправки трассировочных сообщений с последую­щим сбором сообщений со сведениями о действиях (activity messages), которые генерируют все менеджеры очередей на пути следования трассировочного сообще­ния.

WebSphere MQ V6.0 предоставляет приложение display route, которое генерирует трассировочные сообщения, помещает их в инфраструктуру WebSphere MQ, собира­ет сообщения со сведениями о действиях инфраструктуры и создает на их основе понятные человеку отчеты.

Подробнее о мониторинге активности, трассировочных сообщениях и приложении display route см. в руководстве Refer to Monitoring WebSphere MQ, SC34­6593.

Улучшения ведения журналов на распределенных платформах На всех платформах, кроме z/OS, в WebSphere MQ V6.0 в журналы менеджеров очере­дей внесены следующие усовершенствования.

1. Увеличен максимальный размер журнала. Существенно увеличен максимальный размер активной части журнала, это связано как с увеличением максимального размера одного экстента журнала, так и числа первичных и вторичных экстентов в активной части журнала. При обновлении менеджеров очередей с настроенным максимальным числом экстентов журнала размер активного журнала может быть увеличен без повторного создания менеджера очередей.

НовоевWebSphereMQV6 .0 313

2. Добавлены механизмы для упрощения администрирования линейных журналов. В прежних версиях сведения о самых старых экстентах, необходимых для переза­пуска менеджера очередей и восстановления всех объектов менеджера очередей, записывались в его журнал ошибок. В WebSphere MQ V6.0 поддерживается выбо­рочный динамический запрос о необходимых экстентах журнала с помощью GUI­утилиты WebSphere MQ Explorer либо MQSC­команд DISPLAY QMSTATUS и DISPLAY QSTATUS.

3. Добавлена команда для принудительного перехода на новый экстент журнала. В WebSphere MQ V6.0 можно продвинуть вперед текущий экстент журнала, исполь­зуемый менеджером очередей. Этот механизм позволяет создавать более актуаль­ные резервные копии журнала менеджера очередей. Он реализован в виде MQSC­команды RESET QMGR TYPE(ADVANCELOG).

4. Реализована возможность повторного применения журналов на удаленных резерв­ных менеджерах очередей. В WebSphere MQ V6.0 возможна поддержка резервных менеджеров очередей на физических удаленных машинах путем передачи и последующего воспроизведения на них журнала с основного менеджера очере­дей. Этот механизм обеспечивает восстановление после катастрофических сбоев, но не пригоден для получения точных резервных копий, поскольку синхронная репликация данных через протяженные каналы связи затруднена. Тем не менее, так можно поддерживать резервные менеджеры очередей в достаточно актуаль­ном состоянии, чтобы при необходимости оперативно задействовать их при катастрофическом отказе основного менеджера.

Динамическое конфигурирование менеджеров очередей в z/OS В WebSphere MQ для z/OS V6.0 введены расширенные функции динамического кон­фигурирования активных менеджеров очередей:

многие параметры конфигурации инициаторов каналов можно модифицировать у активных менеджеров очередей MQSC­командой ALTER QMGR (вместо установ­ки их через CSQXPARM);

теперь возможно динамическое добавление и удаление наборов страниц и буфер­ных пулов, а также отдельных буферов из буферных пулов;

поддерживается автоматическое вытесняющее расширение наборов страниц;

размер набора страниц может увеличиваться до 64 Гб, что позволяет увеличить размер очередей;

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

Шунты журналов в WebSphere MQ для z/OS «Шунтирование» журналов позволяет помещать записи об отдельных единицах работы в более позднюю часть журнала. Это сокращает объем данных журнала, кото­рый требуется прочитать при перезапуске менеджера очередей или отмене длинных незафиксированных или неоднозначных единиц работы.

Подробнее об этом см. в разделе «Managing the logs» руководства WebSphere MQ для z/OS V6.0 System Administration Guide, SC34­6585.

314 НовоевWebSphereMQV6 .0

Краткийсправочник 315

B

Краткий справочник

Это приложение содержит краткий справочник по командам WebSphere MQ, типам объектов и структурам данных, описанным в этой книге.

В приложении обсуждаются следующие темы:

Управляющие команды WebSphere MQ

Команды CL в WebSphere MQ для iSeries

Поля дескриптора сообщения WebSphere MQ (MQMD)

Интерфейс очередей сообщений (message queue interface, MQI)

Командный интерфейс WebSphere MQ Script (MQSC)

Объект менеджера очередей

Объекты слушателей

Объекты служб

Объекты списки имен

Объекты очередей

Записи кластерных очередей

Записи кластерных менеджеров очередей

Каналы и объекты каналов

Записи состояния каналов

316 Краткийсправочник

Управляющие команды WebSphere MQ Следующие управляющие команды WebSphere MQ применяются для администриро­вания менеджеров очередей в Microsoft Windows и UNIX.

dspmq – выводит список менеджеров очередей, существующих на машине, с ука­занием их состояния.

crtmqm – создает менеджер очередей.

amqmdain – запускает или останавливает менеджер очередей в Windows, конфи­гурирует WebSphere MQ в Windows.

strmqm – запускает менеджер очередей в UNIX.

endmqm – останавливает менеджер очередей.

runmqsc – интерактивная консоль для ввода команд MQSC.

runmqsc <input.txt – исполнение команд MQSC в составе сценария.

strmqcsv – запускает командный сервер для менеджера очередей.

setmqaut – настройка полномочий OAM для объектов менеджеров очередей.

dspmqaut – вывод полномочий OAM для объектов менеджеров очередей.

dmpmqaut – вывод подробной информации о полномочиях OAM, назначенных в менеджере очередей.

runmqlsr – команда WebSphere MQ V5.3 для запуска слушателя, в WebSphere MQ V6.0 используйте объекты слушателей.

mqrc – выводит описания и значения кодов причины WebSphere MQ и номера сообщений AMQXXXX.

dspmqver – выводит сведения о версии WebSphere MQ в виде «Version.Release.Modification.Fixpack»; эти параметры изменяются после установки каждого пакета обновлений.

Команды CL в WebSphere MQ для iSeries Следующие команды WebSphere MQ CL используются для администрирования менед­жеров очередей на платформе iSeries.

WRKMQM – доступ ко всем панелям команд WebSphere MQ CL.

CRTMQM – создание менеджера очередей. STRMQM – запуск менеджера очередей. ENDMQM – остановка менеджера очередей. RUNMQSC – интерактивная консоль для ввода команд MQSC. STRMQMMQSC – исполнение команд MQSC в составе сценария.

STRMQMCSVR – запуск командного сервера для менеджера очередей.

STRMQMLSR – команда WebSphere MQ V5.3 для запуска слушателя, в WebSphere MQ V6.0 используйте объекты слушателей.

CALL QMQM/DSPMQVER – выводит сведения о версии WebSphere MQ в виде «Version.Release.Modification.Fixpack»; эти параметры изменяются после установки каждого пакета обновлений.

Краткийсправочник 317

Поля дескриптора сообщения WebSphere MQ (MQMD)

Дескриптор сообщения WebSphere MQ (MQMD) имеется у каждого сообщения, пере­даваемого по инфраструктуре WebSphere MQ, и содержит следующие поля.

Message Type (MsgType) – тип сообщения (дейтаграмма, запрос, ответ или отчет).

Report (Report) – обстоятельства генерации отчета о доставке и обработке этого сообщения.

Feedback (Feedback) – причина генерации сообщения­отчета.

Reply­to queue (ReplyToQ) – имя очереди–получателя сообщений ответа на это сообщение.

Reply­to queue manager (ReplyToQMgr) – менеджер очередей, в котором находится очередь­получатель ответов. Это поле обычно автоматически заполняется WebSphere MQ.

Message identifier (MsgID) – уникальный идентификатор сообщения, автоматически создается WebSphere MQ.

Correlation identifier (CorrelID) – идентификатор, связывающий сообщения ответа и отчета с исходными запросами и дейтаграммами.

Persistence (Persistence) – указывает, является ли сообщение постоянным (сообще­ния, критические для бизнеса) или непостоянным (для сообщений­запросов).

Coded Character Set Identifier (CodedCharSetId) – определяет способ хранения сим­вольных данных в двоичной форме в сообщении.

Encoding (Encoding) – определяет способ хранения числовых данных в двоичной форме внутри сообщения. Сообщения часто содержат лишь символьные данные.

Put time (PutTime) – время поступления сообщения в очередь, в которой оно нахо­дится в настоящее время.

Put date (PutDate) – дата поступления сообщения в очередь, в которой оно нахо­дится в настоящее время.

Expiry (Expiry) – время хранения, по истечении которого инфраструктура WebSphere MQ может отбросить сообщение.

Команды Message Queue Interface (MQI)Следующие команды составляют интерфейс очередей сообщений (message queue

interface, MQI) – ключевой API WebSphere MQ.

MQCONN – подключение к менеджеру очередей.

MQCONNX – подключение к менеджеру очередей (с дополнительными парамет­рами).

MQDISC – отключение от менеджера очередей, к которому выполнено подключе­ние командой MQCONN или MQCONNX.

MQOPEN – открывает очередь с указанием действий, которые необходимо выпол­нить над этой очередью. Также может открывать другие типы объектов WebSphere MQ для запроса и установки атрибутов.

MQCLOSE – закрывает очередь или другой объект WebSphere MQ, ранее открытый командой MQOPEN.

318 Краткийсправочник

MQPUT – помещает сообщение в очередь, открытую командой MQOPEN.

MQPUT1 – команда­оболочка, объединяющая команды MQOPEN, MQPUT, и MQCLOSE.

MQGET – извлечение или просмотр сообщений в очереди, ранее открытой для чтения или просмотра командой MQOPEN.

MQCMIT – фиксирует текущую единицу работы. MQBACK – выполняет отмену (откат) текущей единицы работы. MQBEGIN – начинает обработку глобальной единицы работы при координации

WebSphere MQ и с участием внешних компонентов, таких как базы данных.

MQINQ – запрос атрибутов объекта WebSphere MQ, ранее открытого командой MQOPEN.

MQSET – установка атрибутов объекта WebSphere MQ, ранее открытого командой MQOPEN.

Командный интерфейс WebSphere MQ Script (MQSC) WebSphere MQ Script (MQSC) – это административный интерфейс для создания и администрирования объектов WebSphere MQ в составе отдельного менеджера очере­дей. Команды MQSC исполняются интерактивно либо в составе сценария.

Общий формат команд MQSC имеет следующий вид:

COMMAND OBJTYPE(‘имя.объекта') ATTR1(ЗНАЧЕНИЕ) ATTR2('значение') ATTR3

Имена и значения, заданные в нижнем регистре, а также содержащие символы, отличные от алфавитно­цифровых, необходимо заключать в одинарные кавычки.

В командах, отображающих атрибуты существующих объектов WebSphere MQ, можно использовать обобщенные имена (generic name). Обобщенное имя заканчивается звездочкой (*) и соответствует всем объектам, имена которых начинаются со строки, стоящей перед звездочкой.

Ниже перечислены наиболее востребованные команды MQSC и атрибуты объектов WebSphere MQ с указанием их сокращенных версий.

Примеры команд MQSC

Следующий пример команд MQSC демонстрирует синтаксис команд MQSC и некото­рые функции интерфейса MQSC.

Создание локальной очереди с именем в нижнем регистре:

DEFINE QLOCAL('payroll.queue') DESCR('Payroll Queue')

Замена существующей локальной очереди с ключевым словом REPLACE:

DEFINE QLOCAL(‘payroll.queue’) DESCR(‘Payroll Queue NEW’) REPLACE

Создание объекта списка имен с именами в верхнем регистре и несколькими значениями атрибута NAMES, включая значения в нижнем регистре:

DEFINE NAMELIST(CLUSTER.NAMELIST) NAMES(CLUSTER1.UCASE,'cluster2.lcase')

Вывод атрибутов локальных очередей, имена которых начинаются с «payroll.»:

DISPLAY QLOCAL('payroll.*') ALL

Краткийсправочник 319

Вывод атрибутов «current depth» (CURDEPTH) и «description» (DESCR) локальных очередей:

DISPLAY QLOCAL(*) CURDEPTH DESCR

Вывод атрибутов «current depth» (CURDEPTH) и «description» (DESCR) очередей, имена которых начинаются с «payroll.», содержащих более 10 сообщений (новин­ка WebSphere MQ V6.0):

DISPLAY QLOCAL(‘payroll.*’) CURDEPTH DESCR WHERE(CURDEPTH GT 10)

Команда MQSC, определяющая sender­канал (для ясности разбита на строки и снабжена комментарием).

Определение канала для менеджера очередей QM_REMOTE:

DEFINE CHANNEL(TO.QM_REMOTE) +

CHLTYPE(SDR) +

CONNAME('remotehost.domain.com(1414)') +

XMITQ(QM_REMOTE) +

DESCR('Channel to qmgr QM_REMOTE')

Объект менеджера очередей У каждого менеджера очередей имеется единственный представляющий его объект. Изменяя атрибуты этого объекта, можно настраивать менеджер очередей. Многие атрибуты можно настраивать, не останавливая менеджер очередей.

Команда MQSC, управляющая объектом менеджера очередей

ALTER QMGR или ALT QMGR – изменяет атрибуты объекта менеджера очередей.

Атрибуты объекта менеджера очередей

Атрибуты менеджера очередей включают следующее

Dead letter queue (DEADQ) – имя локальной очереди, созданной в этом менеджере очередей для сбора сообщений, которые не удается доставить адресату.

Queue manager identifier (QMID) – неизменяемый атрибут, уникальный идентифи­катор экземпляра менеджера очередей, отличающий его от других экземпляров менеджеров с идентичным именем в кластере.

Channel auto­definition (CHAD) – указывает, включено ли автоматическое определе­ние каналов для этого менеджера очередей.

Trigger interval (TRIGINT) – интервал генерации дополнительных триггерных собы­тий для очередей с типом триггера FIRST.

Maximum message length (MAXMSGL) – максимальная длина сообщения в любой из очередей данного менеджера.

Start command server (SCMDSERV) – указывает, следует ли автоматически запускать командный сервер для менеджера очередей.

Start channel initiator (SCHINIT) – указывает, следует ли автоматически запускать инициатор каналов вместе с менеджером очередей в Windows, UNIX и iSeries.

SSL key repository (SSLKEYR) – путь к хранилищу SSL­ключей менеджера очередей.

320 Краткийсправочник

Repository (REPOS) – имя кластера, полный репозиторий которого обслуживается этим менеджером очередей.

Repository namelist (REPOSNL) – имя объекта списка имен, содежащего имена клас­теров, полные репозитории которых обслуживаются этим менеджером очередей.

Cluster workload use queue (CLWLUSEQ) – указывает, активна ли по умолчанию балан­сировка нагрузки между удаленными экземплярами очереди, если существует локальная очередь с тем же именем.

Cluster workload recently used channel (CWMRUC) – максимальное число экземпляров очереди в кластере, участвующих в балансировке нагрузки.

Объекты слушателейСлушатели предоставляют менеджерам очередей идентификационные данные для работы в сети. Атрибуты объекта слушателя позволяют настроить слушатель, запускае­мый для менеджера очередей.

Команды MQSC для управления объектом слушателя Команды MQSC для объекта слушателя таковы. DEFINE LISTENER(NAME) TRPTYPE(TCP) или DEF LSTR(NAME) TRPTYPE(TCP) – создает

объект слушателя. ALTER LISTENER(NAME) TRPTYPE(TCP) или ALT LSTR(NAME) TRPTYPE(TCP) – изменяет

существующий объект слушателя. DELETE LISTENER(NAME) и DELETE LSTR(NAME) – удаляет существующий объект слу­

шателя. DISPLAY LISTENER(GENERIC_NAME) и DIS LSTR(GENERIC_NAME) – выводит атрибуты

существующего объекта слушателя. DISPLAY LSSTATUS(GENERIC_NAME) и DIS LSSTATUS(GENERIC_NAME) – выводит состояние

активных слушателей. START LISTENER(NAME) и STA LSTR(NAME) – запускает слушатель, связанный с объек­

том слушателя. STOP LISTENER(NAME) и STOP LSTR(NAME) – останавливает слушателя, связанного

с объектом слушателя.

Атрибуты объекта слушателя Объект слушателя поддерживает следующие атрибуты.

Port (PORT) – порт TCP/IP, который прослушивается в ожидании подключений.

Control (CONTROL) – указывает, должен ли слушатель запускаться вручную (MANUAL) или автоматически при запуске менеджера очередей (QMGR).

Объекты службОбъекты служб позволяют запускать и останавливать произвольные приложения вместе с менеджерами очередей.

Брокер публикации­подписки WebSphere MQ – одно из приложений, для запуска которого используется объект службы SYSTEM.BROKER, который создается для менеджера очередей WebSphere MQ V6.0.

Краткийсправочник 321

Команды MQSC для управления объектом службы

Команды MQSC для объекта службы таковы. DEFINE SERVICE(NAME) или DEF SERVICE(NAME) – создает объект службы. ALTER SERVICE(NAME) или ALT SERVICE(NAME) – изменяет существующий объект

службы. DELETE SERVICE(NAME) – удаляет существующий объект службы. DISPLAY SERVICE(GENERIC_NAME) или DIS SERVICE(GENERIC_NAME) – выводит атрибуты

существующего объекта службы. DISPLAY SVSTATUS(GENERIC_NAME) или DIS SVSTATUS(GENERIC_NAME) – выводит состоя­

ние работающих служб. START SERVICE(NAME) или STA SERVICE(NAME) – запускает приложение, связанное

с объектом службы. STOP SERVICE(NAME) – останавливает приложение, связанное с объектом службы.

Атрибуты объекта службы

Объект службы поддерживает следующие атрибуты.

Service type (SERVTYPE) – указывает, разрешен ли запуск только одного (SERVER) или нескольких экземпляров службы (COMMAND).

Control (CONTROL) – указывает, разрешено ли запускать службу вручную (MANUAL), запускать и останавливать ее вместе с менеджером очередей (QMGR) либо только запускать вместе с менеджером очередей (STARTONLY).

Start command (STARTCMD) – путь к исполняемому файлу, запускающему службу.

Start arguments (STARTARG) – аргументы команды запуска службы.

Stop command (STOPCMD) – путь к исполняемому файлу, останавливающему службу.

Stop arguments (STOPARG) – аргументы команды остановки службы.

Standard out (STDOUT) – файл, в который направляется стандартный вывод работа­ющей службы.

Standard error (STDERR) – файл, в который направляется стандартный поток оши­бок работающей службы.

Объекты списки имен Объекты списки имен (namelist) содержат наборы имен. Они чаще всего применяют­ся для хранения списков кластеров, которые можно занести в атрибут «cluster namelist» (CLUSNL) или «repository namelist» (REPOSNL) других объектов.

Команды MQSC для управления объектом список имен

Команды MQSC для объекта список имен таковы.

DEFINE NAMELIST(NAME) или DEF NL(NAME) – создает объект список имен.

ALTER NAMELIST(NAME) или ALT NL(NAME) – изменяет существующий объект список имен.

DELETE NAMELIST(NAME) или DELETE NL(NAME) – удаляет существующий объект список имен.

322 Краткийсправочник

DISPLAY NAMELIST(GENERIC_NAME) или DIS NL(GENERIC_NAME) – выводит атрибуты существующего объекта списка имен.

Атрибуты объекта список именОбъект список имен поддерживает следующие атрибуты.

Names (NAMES) – список имен, разделенных запятыми.

Объекты очередей

Объекты очередей представляют очереди в составе менеджера очередей и управляют маршрутизацией сообщений в очереди, обслуживаемые другими менеджерами оче­редей в инфраструктуре WebSphere MQ.

Типы объектов очередей

Существуют следующие типы объектов очередей.

Local queue (QLOCAL или QL) – локальная очередь, единственный объект, представляю­щий очередь в составе менеджера очередей, способную хранить сообщения. Может быть назначена транспортной очередью (transmission queue) для временного хранения сообщений, предназначенных для передачи другим менеджерам очередей в инфра­структуре WebSphere MQ. Сообщения, предназначенные для отправки удаленному менеджеру очередей, попадают в одноименные транспортные очереди.

Alias queue (QALIAS or QA) – объект псевдонима очереди, ссылающийся на объект очереди с другим именем (объект локальной, удаленной или кластерной очереди).

Model queue (QMODEL or QM) – объект модельной очереди, позволяющий приложени­ям динамически создавать локальные очереди и идентифицировать себя в инфра­структуре WebSphere MQ. Атрибуты объекта модельной очереди определяют атрибуты очередей, динамически создаваемых на его основе.

Remote queue (QREMOTE or QR) – объект удаленной очереди, позволяющий явно зада­вать и управлять маршрутами между менеджерами очередей; применяются в сле­дующих целях (в зависимости от атрибутов):

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

– локальное определение удаленной очереди – явно определяет маршрут через транспортную очередь к очереди с заданным именем в удаленном менеджере очередей;

– псевдоним очереди ответов – заставляет менеджер очередей во время отправ­ки сообщения заменять значения полей reply­to в его дескрипторе данными из описания этого псевдонима.

Команды MQSC для управления объектами очередей

Следующие команды поддерживаются всеми объектами очередей. Вместо QLOCAL и QL следует подставить нужный тип объекта очереди (см. выше).

Краткийсправочник 323

DEFINE QLOCAL(NAME) или DEF QL(NAME) – создает объект очереди.

ALTER QLOCAL(NAME) или ALT QL(NAME) – изменяет существующий объект очереди.

DELETE QLOCAL(NAME) или DELETE QL(NAME) – удаляет существующий объект оче­реди.

DISPLAY QLOCAL(GENERIC_NAME) или DIS QL(GENERIC_NAME) – выводит атрибуты сущест­вующих объектов очередей.

Следующая команда применяется для вывода атрибутов любых определенных локаль­но объектов очередей:

DISPLAY QUEUE(GENERIC_NAME) или DIS Q(GENERIC_NAME)

Следующая команда MQSC выводит состояние очереди (только для локальных очере­дей):

DISPLAY QSTATUS(GENERIC_NAME) или DIS QS(GENERIC_NAME)

Общие атрибуты объектов очередей

Следующие атрибуты поддерживают все типы объектов очередей.

Put (PUT) – определяет, можно ли добавлять сообщения в локальную очередь либо отправлять через нее сообщения. Установка этого атрибута в значение DISABLED для очереди в составе кластера отключает маршрутизацию сообщений к этой очереди.

Default persistence (DEFPSIST) – указывает, что сообщения, отравленные командой MQPUT через эту очередь (открытую командой MQOPEN), по умолчанию являют­ся постоянными.

Атрибуты очередей, управляющие балансировкой нагрузки в кластере

Следующие атрибуты поддерживаются всеми типами объектов очередей, кроме модельных очередей (созданные на их основе динамические очереди нельзя публи­ковать в кластерах).

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

Cluster (CLUSTER) – имя кластера, в котором опубликован этот объект очереди.

Cluster namelist (CLUSNL) – имя объекта списка имен, содержащего имена кластеров, в которых опубликован этот объект очереди.

Default bind type (DEFBIND) – тип привязки по умолчанию, используемый при открытии этой очереди. Если задано значение bind on open (OPEN), то данная оче­редь будет принимать сообщения, адресованные ей с использованием одно и того же описателя объекта (полученного от одного вызова MQOPEN), которые будут доставляться одному и тому же менеджеру очередей кластера. Если же указано значение bind not fixed (NOTFIXED), балансировка нагрузки будет осуществляться независимо для каждого сообщения.

324 Краткийсправочник

Cluster workload rank (CLWLRANK) – чем выше значение этого атрибута у экземпляра очереди в составе кластера, тем больше шансов на ее использование при баланси­ровке нагрузки, даже если обслуживающий ее менеджер очередей недоступен.

Cluster workload priority (CLWLPRTY) – чем выше значение этого атрибута у экземп­ляра очереди в составе кластера, тем больше шансов на ее использование при балансировке нагрузки, если обслуживающий ее менеджер очередей доступен.

Cluster workload use queue (CLWLUSEQ) – указывает, следует ли вовлекать в баланси­ровку нагрузки удаленные экземпляры кластерных очередей, если существует одноименная локальная очередь в данном менеджере очередей (только для локальных очередей, созданных вручную).

Атрибуты локальных очередей (включая динамические)

Следующие атрибуты поддерживаются локальными очередями (QLOCAL), в том числе модельными очередями (QMODEL), у которых они управляют параметрами динамичес­ки создаваемых очередей.

Definition type (DEFTYPE) – указывает, создана ли очередь вручную (PREDEFINED) или динамически, на основе объекта модельной очереди. Динамические очереди бывают постоянными (PERMDYN) и временными (TEMPDYN), последние не могут содер­жать постоянные сообщения, поскольку автоматически удаляются после отключе­ния приложения или завершения менеджера очередей.

Get (GET) – указывает, можно ли открыть объект этой локальной очереди для извлечения или просмотра сообщений, также применим к объектам псевдонимов локальных очередей.

Usage (USAGE) – если указано значение «transmission» (XMITQ), эта локальная очередь будет использоваться в качестве транспортной очереди для маршрутизации сооб­щений удаленным менеджерам очередей (для этого также требуется канал, обра­батывающий сообщения в транспортной очереди).

Для запуска приложений по прибытии сообщений в очередь используются триг­геры. В Windows и UNIX для транспортной очереди можно настроить триггер, автоматически запускающий канал при поступлении сообщений, предназначен­ных для пересылки. Этот процесс называется инициацией канала (channel initiation). Следующие атрибуты настраивают триггеры для очереди.

Trigger control (TRIGGER) – указывает, включен ли триггеринг для этой очереди (это необходимо для инициации каналов).

Trigger type (TRIGTYPE) – тип активного триггеринга очереди (для инициации кана­лов требуется триггер типа FIRST).

Trigger depth (TRIGDPTH) – пороговое число сообщений, по достижении которого триггер типа DEPTH генерирует событие.

Trigger data (TRIGDATA) – пользовательские данные, которые добавляются к триггер­ному сообщению (в случае инициации канала они включают имя запускаемого канала).

Initiation queue (INITQ) – очередь, в которой генерируются сообщения при сраба­тывании триггера (в случае инициации каналов это SYSTEM.CHANNEL.INITQ).

Краткийсправочник 325

Атрибуты объектов псевдонима очереди

Объекты псевдонима очереди (QALIAS) поддерживают следующие атрибуты.

Target queue (TARGQ) – целевая или базовая очередь. Имя очереди, на которую ссылается псевдоним.

Атрибуты локальных определений удаленных очередей При создании локальных определений удаленных очередей используются следую­щие атрибуты объектов удаленных очередей (QREMOTE).

Remote name (RNAME) – имя удаленной очереди.

Remote queue manager name (RQMNAME) – имя удаленного менеджера очередей, обслуживающего эту очередь.

Transmission queue (XMITQ) – имя транспортной очереди, через которую сообще­ния передаются этому удаленному менеджеру очередей (можно не указывать, если оно совпадает с именем удаленного менеджера очередей).

Атрибуты псевдонимов менеджеров очередей При создании псевдонимов менеджеров очередей используются следующие опреде­ления объектов удаленных очередей (QREMOTE).

Remote name (RNAME) – не указывают.

Remote queue manager name (RQMNAME) – имя менеджера очередей, на который ссы­лается псевдоним.

Transmission queue (XMITQ) – имя транспортной очереди, через которую сообще­ния передаются этому удаленному менеджеру очередей (можно не указывать, если оно совпадает с именем удаленного менеджера очередей, либо псевдоним ссылается на локальную очередь).

Атрибуты псевдонима очереди ответов При создании псевдонима очереди ответов используются следующие определения объектов удаленных очередей (QREMOTE).

Remote name (RNAME) – имя очереди, которое заносится в поле reply­to queue.

Remote queue manager name (RQMNAME) – имя менеджера очередей, которое зано­сится в поле reply­to queue manager.

Transmission queue (XMITQ) – не указывают.

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

Если менеджер очередей обслуживает полный репозиторий кластера, он содержит запись кластерной очереди для каждой из общих очередей кластера. Менеджер оче­редей, обслуживающий частичный репозиторий кластера, содержит записи кластер­ных очередей только для очередей, с которыми он разделяет имя опубликованной в кластере своей очереди, либо к которым подключались локальные приложения.

326 Краткийсправочник

Команды MQSC для управления записями кластерных очередей

Для управления кластерными очередями применяют следующие команды MQSC.

DISPLAY QCLUSTER(GENERIC_NAME) или DIS QC(GENERIC_NAME) – выводит атрибуты записей кластерных очередей известных менеджеру очередей.

Атрибуты записей кластерных очередей

Записи кластерных очередей поддерживают следующие атрибуты: Cluster (CLUSTER) – кластер, в котором опубликован объект очереди. Cluster queue manager (CLUSQMGR) – имя менеджера очередей в составе кластера, где

опубликован этот объект очереди. Queue manager identifier (QMID) – уникальный идентификатор менеджера очередей

в составе кластера, где опубликован этот объект очереди. Cluster queue type (CLUSQT) – тип объекта кластерной очереди.

Записи кластерных менеджеров очередей Запись кластерного менеджера очередей представляет менеджер очередей в составе кластера и указывает, как связаться с ним через кластер, в который он входит.

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

Команды MQSC для управления записями кластерных менеджеров очередей

Для управления записями кластерных менеджеров очередей служат следующие команды MQSC.

DISPLAY CLUSQMGR(GENERIC_NAME) или DIS CLUSQMGR(GENERIC_NAME) – выводит атрибуты записей кластерных менеджеров очередей, известных этому менеджеру очередей.

Атрибуты записей кластерных менеджеров очередей

Записи кластерных менеджеров очередей поддерживают следующие атрибуты. Cluster (CLUSTER) – кластер, в который входит этот менеджер очередей. Cluster queue manager (CLUSQMGR) – имя менеджера очередей. Queue manager identifier (QMID) – уникальный идентификатор менеджера очере­

дей. Queue manager type (QMTYPE) – указывает, обслуживает ли этот менеджер очередей

полный или частичный репозиторий кластера. Channel (CHANNEL) – имя канала, применяемого для взаимодействия с этим менед­

жером очередей.

Definition type (DEFTYPE) – тип канала, применяемого для взаимодействия с этим менеджером очередей.

Краткийсправочник 327

Connection name (CONNAME) – хост­имя или IP­адрес и порт для взаимодействия с этим менеджером очередей.

Status (STATUS) – текущее состояние канала, применяемого для взаимодействия с этим менеджером очередей.

Каналы и объекты каналовОбъекты каналов позволяют настраивать агенты каналов сообщений (MCA), устанав­ливающие исходящие и принимающие входящие подключения к менеджеру очере­дей через сеть.

MCA всегда работают парами, имена MCA (и, следовательно, имена объектов каналов) из пары должны совпадать. Соединение, установленное между двумя MCA, называется каналом.

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

Объекты каналов используются для подключения менеджеров очередей к кластерам.

Типы объектов каналов Менеджеры очередей поддерживают следующие типы объектов каналов.

Распределенные каналы для передачи сообщений. – Sender (SDR) – отправляет все сообщения, поступающие в заданную транспорт­

ную очередь. Партнером такого канала может быть receiver­канал или requester­канал. Всегда устанавливает подключение, также способен прини­мать запросы подключения у requester­канала.

– Receiver (RCVR) – получает сообщения и направляет их очередям. Его партнером должен быть sender­канал, никогда не устанавливает подключение сам.

– Server (SVR) – отправляет все сообщения, поступающие в заданную транспорт­ную очередь. Его партнером должен быть requester­канал. Способен принимать и устанавливать подключения (если имя подключения записано в определении канала).

– Requester (RQSTR) – получает сообщения и направляет их очередям. Партнером такого канала может быть sender­канал или server­канал. Способен принимать, устанавливать и запрашивать подключения.

Кластерные каналы для передачи сообщений. – Cluster sender (CLUSSDR) – отправляет сообщения из транспортной очереди

кластера другим менеджерам очередей кластера. Если он явно определен, выполняет первое подключение к менеджеру очередей с полным репозитори­ем кластера, чтобы войти в его состав. WebSphere MQ автоматически создает объекты кластерного sender­канала для всех менеджеров очередей в кластере. Атрибуты этого объекта основаны на объекте кластерного receiver­канала, опубликованного в кластере менеджерами очередей.

– Cluster receiver (CLUSRCVR) – определяет способ подключения любого из менед­жеров очередей заданного кластера к данному менеджеру очередей. Партне­ром этого канала может быть объект кластерного sender­канала, созданного вручную либо автоматически.

328 Краткийсправочник

Каналы MQI.

– Server connection (SVRCONN) – определяет способы подключения клиентских приложений к менеджеру очередей.

– Client connection (CLNTCONN) – отличается от остальных каналов тем, что никог­да не используется менеджером очередей напрямую. Вместо этого для такого канала добавляется запись в таблицу определений клиентских каналов (CCDT), которая затем распространяется по другим машинами и используется клиент­скими приложениями для настройки их MCA.

Команды MQSC для управления объектами каналов Для управления объектами каналов служат следующие команды MQSC.

DEFINE CHANNEL(NAME) CHLTYPE(TYPE) или DEF CHL(NAME) CHLTYPE(TYPE) – создает объект канала.

ALTER CHANNEL(NAME) CHLTYPE(TYPE) или ALT CHL(NAME) CHLTYPE(TYPE) – изменяет существующий объект канала.

DELETE CHANNEL(NAME) или DELETE CHL(NAME) – удаляет существующий объект канала.

DISPLAY CHANNEL(GENERIC_NAME) or DIS CHL(GENERIC_NAME) – выводит атрибуты существующих объектов каналов.

Атрибуты объектов каналов Объекты каналов поддерживают следующие атрибуты.

Connection name (CONNAME) – сведения о сетевом подключении к целевому менед­жеру очередей (в случае каналов, устанавливающих подключения) либо к локаль­ному менеджеру очередей (в случае кластерного receiver­канала, CLUSRCVR). Для TCP/IP­каналов используется формат имя_или_IP_адрес(номер порта).

Transmission queue (XMITQ) – в случае sender­каналов (SDR) или server­каналов (SVR) это имя транспортной очереди, из которой они получают сообщения для после­дующей пересылки.

Short retry (SHORTRTY) – в случае каналов, устанавливающих подключения, это число попыток подключения с интервалом, заданным атрибутом SHORTTMR.

Short retry timer (SHORTTMR) – время ожидания (в миллисекундах) между попытками подключения (см. атрибут SHORTRTY). Между попытками подключения канал нахо­дится в состоянии RETRYING.

Long retry (LONGRTY) – если после попыток, заданных атрибутом SHORTRTY, установить подключение не удалось, канал предпримет еще несколько попыток (их число задает этот атрибут) подключения, но уже с бо' льшим интервалом, заданным атри­бутом LONGTMR. Если ни одна из этих попыток не увенчается успехом, канал перей­дет в состояние STOPPED и его придется перезапускать вручную.

Long retry timer (LONGTMR) – время ожидания (в миллисекундах) между попытками подключения (см. атрибут LONGRTY). Между попытками подключения канал нахо­дится в состоянии RETRYING.

Message retry (MRRTY) – для receiver­канала: число попыток доставки сообщения в целевую очередь до пересылки его в очередь недоставленных сообщений.

Краткийсправочник 329

Message retry timer (MRTMR) – время ожидания (в миллисекундах) между попытками доставки сообщения.

MCA user identifier (MCAUSER) – для каналов серверных подключений (SVRCONN): назначает идентификатор пользователя, полномочия которого будут использо­ваться для проверки допустимости действий клиентов, подключающихся через этот канал.

Nonpersistent message speed (NPMSPEED) – для каналов передачи сообщений указы­вает, следует ли использовать единицы работы при пересылке непостоянных сообщений.

Batch size (BATCHSZ) – для каналов передачи сообщений указывает максимальное число сообщений, после передачи которых необходимо подтверждение доставки и фиксация единицы работы.

Batch interval (BATCHINT) – для каналов передачи сообщений указывает максималь­ное время ожидания обработки пакета до получения подтверждения доставки и фиксации единицы работы.

Disconnect interval (DISCINT) – для каналов передачи сообщений указывает время, в течение которого канал остается активным, даже если транспортная очередь пуста.

SSL cipher specification (SSLCIPH) – спецификация алгоритма шифрования для SSL или TLS, защищающего канал. Эти значения должны совпадать на обоих сторонах канала.

SSL client authentication (SSLCAUTH) – для каналов, выступающих в роли SSL­серве­ров, принимающих подключения, указывает, должен ли SSL­клиент предъявить сертификат.

SSL peer (SSLPEER) – строка с отличительными именами (distinguished names, DN), которым разрешено подключение через этот канал. Проверяется после проверки сертификата партнера.

Cluster (CLUSTER) – для кластерных каналов: имя кластера, для которого создан объект канала.

Cluster namelist (CLUSNL) – для кластерных каналов: имя объекта списка имен с именами кластеров, для которых создан объект канала.

Команды MQSC для управления каналами Следующие команды MQSC используются для ручного подключения к удаленным менеджерам очередей и управления автоматическим запуском каналов WebSphere MQ в ответ на входящие подключения от удаленных менеджеров очередей и прило­жений либо инициатором каналов.

START CHANNEL(NAME) или STA CHL(NAME) – создает канал связи с удаленным менед­жером очередей с использованием заданного объекта канала. Также запускает каналы, ранее остановленные командой STOP CHANNEL.

STOP CHANNEL(NAME) или STOP CHL(NAME) – останавливает все активные каналы с заданным именем.

По умолчанию в команде указан атрибут STATUS(STOPPED) во избежание случайного автозапуска каналов. Изменить это можно, вызвав команду с параметром STATUS(INACTIVE).

330 Краткийсправочник

Записи состояния каналовДля всех активных MCA менеджера очередей поддерживаются записи состояния канала. Такая запись также создается при отключении канала командой STOP CHANNEL либо после безуспешных попыток подключения, число которых задано атрибутом LONGRTY.

Для каналов в состоянии INACTIVE записей состояния не существует.

Некоторые атрибуты объектов каналов согласовываются между MCA­партнерами, обра­зующими канал. Результаты согласования отражаются в записях состояния канала.

Команды MQSC для управления записями состояния каналов

Следующая команда MQSC служит для управления записью состояния канала.

DISPLAY CHSTATUS(GENERIC_NAME) или DIS CHS(GENERIC_NAME) – выводит атрибуты записи состояния канала.

Атрибуты записи состояния канала

Записи состояния канала поддерживают следующие атрибуты.

STATUS – общее состояние канала: RUNNING (канал активен), RETRYING (подключение не удалось, выполняется повторная попытка подключения) или STOPPED (для отключенных каналов); остальные состояния, например BINDING или STOPPING, явля­ются временными.

INDOUBT – находится ли канал, пересылающий сообщения, в неоднозначном состо­янии. В этом состоянии канал пребывает, ожидая подтверждения получения сообщений, и остается в нем, если подтверждение не пришло до разрыва подклю­чения. При перезапуске канал автоматически выходит из этого состояния.

Remote queue manager name (RQMNAME) – для каналов, передающих сообщения: имя удаленного менеджера очередей.

Предметныйуказатель 331

#+ и ­ , значки в дереве навигации, 7620­символьное название канала, 16630­дневный период

существования, 17232­разрядная адресация, выход

за пределы, 1074­значные десятичные числа, 28764­разрядная адресация,

поддержка, 10664­разрядные клиенты, 10664­разрядное оборудование, 10664­разрядные менеджеры

очередей, 10664­разрядные приложения,

подключение, 10664­разрядная адресация, поддержка

106

А

AMQ4000 в AMQ9999, 286amqmdain qmgr end, управляющая

команда WebSphere MQ, 98amqmdain qmgr start, управляющая

команда WebSphere MQ, 97amqmdain reg, управляющая команда

WebSphere MQ, 91amqsbcg, программа­пример, 223amqsbcgc, 239amqsech, программа­пример

WebSphere MQ, 219amqsget, 239amqsgetc, 239amqsput, 239amqsputc, 239amqsreq, команда­пример WebSphere

MQ, 222amqsreqc, 239

AMQXXXX, идентификатор сообщений, 286

APAR, описания и Technote, 289API, использованные, 269API, стандартизованный 26, 27ARM, удаление регистрации, 98–99Auto cluster sender, 167Auto explicit cluster sender, 167Automatic Restart Manager (ARM), 98

B

BATCHINT, атрибут, 151BATCHSZ, атрибут, 151BATCHSZ, атрибут, 329bind not fixed, работа

без фиксированной привязки, 186bind on open, работа с привязкой, 186bindings­подключений, 106

C

CCDT, 147CCDT, место расположения, 147CCDTURL, свойство, 148CCSID, идентификатор, 111CHAD, атрибут, 159Channels, папка, 141CipherSpec, 275CipherSuite, 275CLASSPATH, переменная среды, 228CLEAR, 218CLUSNL, 166CLUSQMGR, запись, 174CLUSSDR, 167CLUSSDRA, 167CLUSSDRB, 167CLUSTER, атрибут, 166, 186CLWLPRTY, атрибут, 190

Предметный указатель

332 Предметныйуказатель

CLWLRANK, атрибут, 189CLWLUSEQ, атрибут, 189CLWLWGHT, атрибут, 191CONNAME, атрибут, 152Create Queue Manager, мастер, 93CRL, использование, 281crtmqm, управляющая команда

WebSphere MQ, 93Cryptomodule Validation Program, 308CWMRUC, атрибут, 191

D

Data, секция, 206DEFBIND, атрибут, 187DEFINE CHANNEL

CHLTYPE(CLNTCONN), 146DEFINE CHANNEL

CHLTYPE(CLUSRCVR), команда MQSC, 166

DEFINE CHANNEL CHLTYPE(CLUSSDR), команда MQSC, 167

DEFINE CHANNEL CHLTYPE(RCVR), команда MQSC, 153

DEFINE CHANNEL CHLTYPE(RQSTR), команда MQSC, 153

DEFINE CHANNEL CHLTYPE(SDR), команда MQSC, 153

DEFINE CHANNEL CHLTYPE(SVR), команда MQSC, 154

DEFINE CHANNEL CHLTYPE(SVRCONN), 144

DEFINE LISTENER, команда MQSC, 100DEFINE QALIAS, команда MQSC, 125DEFINE QLOCAL, команда MQSC, 124DEFINE QMODEL, команда MQSC, 127DEFINE QREMOTE, команда MQSC, 130DEFINE/START/STOP/DISPLAY

SERVICE, 310DEFPSIST(YES), 132DEFPSIST, атрибут, 132DEFTYPE, атрибут, 124DISCINT, атрибут, 152DISPLAY CLUSQMGR, 174DISPLAY CONN, 309DISPLAY QCLUSTER, 174DISPLAY QMSTATUS, 313DISPLAY QSTATUS, 133, 313

display route, приложение, 312DISPLAY SVSTATUS, 310dltmqm, управляющая команда

WebSphere MQ, 214Dmpmqaut, 272Dspmqaut, 272DynamicQName, 126

E

Eclipse, технология, 75EDTF CL, редактор, 94ENDMQM, команда CL, 98endmqm, управляющая команда

WebSphere MQ, 98Extended Message Service (XMS), 110Extensible Markup Language (XML), 50External Security Manager (ESM), 268

F

Federal Information Processing Standard (FIPS), 308

FFST, 105FILTER, ключевое слово, 311FIPS, совместимость с, 308Format, поле, 112

G

gsk7cmd, утилита командной строки, 278

gsk7ikm, GUI­утилита, 278

H

Hconn, 114

I

IBM developerWorks, 291IBM Global Security Toolkit (GSKit), 307IBM KeyMan, 276IBM, Web­сайт поддержки, 290IBM, информация по технической

поддержке, 289IFS, 94INDOUBT, атрибут, 152Inetd, слушатель ОС, 100

Предметныйуказатель 333

Initial Program Load (IPL), 98INITQ, 135Interactive System Productivity Facility

(ISPF), 83IPv4, 307IPv6, 307IP­адреса и порты, 152IP­адреса и хост­имена, 99

J

Java Development Kit (JDK), установка, 196

Java KeyStore (JKS), 278Java Naming and Directory Interface

(JNDI), 230Java Runtime Environment, 226Java Secure Sockets Extension

(JSSE), 278java и javac, исполняемые файлы, 226Java и JMS, клиентские MCA, 144JKS, хранилища ключей, 278JMS API, 47, 145JVM, окончание работы, 59

L

LDAP­сервер, 230Lightweight Directory Access Protocol

(LDAP), 308Linux, установка WebSphere MQ, 195LONGRTY, 142LONGTMR, 142

M

MAC, алгоритм, 275MCA, согласование и привязка, 139MCA, созданный в пуле процессов, 100MCA, созданный слушателем

WebSphere MQ, 100MCA, удаленный, 139MCA, установка канала, 139MCAUSER, атрибут, 145MODE(INACTIVE), 141MODE(STOPPED), 141MQBEGIN, MQCMIT и MQBACK, 117MQBEGIN, функция MQI, 117

MQCHLLIB и MQCHLTAB, переменные окружения, 148

MQCLOSE, 115MQCMIT, 116, 117MQCMIT и MQBACK, последний

вызов, 117MQCMIT, сбой вызова, 118MQCMIT, функция MQI, 117MQCNO, 114MQCO_DELETE, параметр, 127MQCO_DELETE_PURGE, параметр, 127MQCONN и MQCONNX, вызовы, 118MQCONN, 113MQConnectionFactory, объект, 146MQCONNX, 113MQDISC, 118MQDISC, вызов перед выходом, 118MQDISC, результат вызова, 118MQDISC, сбой вызова, 118MQEnvironment, класс, 145MQGET, 116MQGMO, 116MQI, 113MQI, передача команд через

канал, 139MQI, сообщения статистики, 312MQINQ, 115, 118Mqm, администратор, 144Mqm, группа, 91MQMD, 115MQMD, общие поля в, 110MQOD, 114MQOD, при вызове MQOPEN, 119MQOPEN, 114MQPMO, применение, 115MQPUT, 115, 269MQPUT и MQGET, 117MQPUT, вызов, 115MQPUT1, функция MQI, 116MQRC, команда WebSphere MQ, 113mqrc, 218MQRC_UNKNOWN_REMOTE_Q_MGR, 214mqs.ini, перезапись, 93mqs.ini, редактирование, 93MQSC, интерактивный сеанс, 200MQSC, команды сценариев, 193MQSC­интерфейс, сценарный, 22

334 Предметныйуказатель

MQSET, 115, 118MQSSLKEYR, переменная

окружения, 278

N

Network Address Translation (NAT), 284New Alias Queue, мастер, 125New Model Queue, мастер, 127New Remote Queue, мастер, 130New state, список, 141NPMCLASS, 210NPMSPEED, 151, 329

O

Object Authority Manager (OAM), 36

P

PAUSED, 142PCF, команды, 87PERMDYN, 126PKCS12, файл, 277PREDEFINED, 124Problem Management Record

(PMR), 300PROCESS объект, 135put date, 112put time, 112

Q

qm.ini, файл, 93QMANAGER, свойство, 146QMgrName, параметр, 146QMNAME, атрибут, 146QMQM, подсистема, 94QMQMADM, группа, 95Queue Manager Identifier (QMID), 170Queue Managers, папка, 76

R

RACF, 268Readme, файл, 290Receiver­каналы кластера, 179REFRESH CLUSTER, 185REFRESH SECURITY TYPE(SSL),

команда MQSC, 307

REFRESH SECURITY, команда MQSC, 272

ReplyToQMgr, поле, 123REPOS(YES), 185REPOS, атрибут, 164REPOSNL, атрибут, 164RESET CLUSTER ACTION

(FORCEREMOVE), команда MQSC, 171RESET CLUSTER, команда MQSC, 180RESET QMGR TYPE(ADVANCELOG),

команда MQSC, 313Resource Access Control Facility

(RACF), 268RESUME QMGR CLUSNL, 180RESUME QMGR CLUSTER, 180RETRYING, состояние, 142RNAME, атрибут, 146, 169–170RQMNAME, атрибут, 128RSA, 275root, полномочия, 273runmqlsr, управляющая команда

WebSphere MQ, 101

S

SCHINIT, параметр, 158Secure Sockets Layer (SSL), 37Sender­канал, создание объекта, 255SHORTRTY, 142SHORTTMR, 142Show/Hide Queue Managers, окно, 244Shown Queue Managers, окно, 245Simple Object Access Protocol

(SOAP), 29SSL, конфигурация, 146, 267SSLCIPH, атрибут, 307SSLFIPS, атрибут, 308SSLRKEYC, атрибут, 307START CHANNEL и STOP CHANNEL,

команды MQSC, 173START CHANNEL, 140START CHANNEL, команда MQSC, 142START CHINIT, 101START LISTENER, команда MQSC, 100STOP CHANNEL, команда MQSC, 142STOP CONN, 309STOP QMGR MODE(FORCE), 99STOP QMGR MODE(QUIESCE), 99

Предметныйуказатель 335

STOP QMGR MODE(RESTART), 99STOPPED, состояние канала, 142STRMQM, команда CL, 97strmqm, управляющая команда

WebSphere MQ, 97STRMQMLSR, команда CL, 101SupportPac MA0C, 308SupportPac MH01, 291SupportPac MS81, 284SUSPEND QMGR CLUSTER, 180SYSTEM.BROKER, 229

T

TARGQ, атрибут, 124TCP/IP, порт 1414, 99TCP/IP, порт, 144TCP/IP, хост­имя, 152TCP/IP­подключение, 236Technote, 290Topic Connection Factory (TCF),

объект, 231trace­route, 298TRIGDATA, 135TRIGTYPE(EVERY), 134TRIGTYPE(FIRST), 134

U

UNIX­платформы, 93USAGE, атрибут, 122

V

vi и emacs, 93, 199

W

Web Services Description Language (WSDL), 28

WebSphere Application Server Version 5, 28

WebSphere Application Server Version 6, 28

WebSphere MQ C++, 45, 139WebSphere MQ Explorer, 22WebSphere MQ Explorer, значок, 75WebSphere MQ Explorer, структура

окна, 76

WebSphere MQ internet pass­thru (IPT), 283, 284

WebSphere MQ Java API, 80WebSphere MQ JMS, пример, 226WebSphere MQ Script (MQSC),

сценарный интерфейс, 82WebSphere MQ Services, модули

оснастки, 75WebSphere MQ для iSeries, 81WebSphere MQ для UNIX, 81WebSphere MQ для Windows, 81WebSphere MQ для z/OS, 82WebSphere MQ как менеджер

транзакций, 57WebSphere MQ, 46WebSphere MQ, Web­страница

поддержки, 290WebSphere MQ, администраторы, 2WebSphere MQ, базовый клиент, 139WebSphere MQ, брокер публикации

и подписки, 47WebSphere MQ, взаимодействие, 99WebSphere MQ, дескриптор

сообщения (MQMD), 110WebSphere MQ, загрузка сервисных

пакетов, 289WebSphere MQ, инициатор

распределенных каналов, 136WebSphere MQ, информация

об установке, 74WebSphere MQ, клиентская

инсталляция, 52WebSphere MQ, клиентские

продукты, 52WebSphere MQ, 52WebSphere MQ, командный сервер, 52WebSphere MQ, команды CL, 94WebSphere MQ, команды публикации

и подписки, 47WebSphere MQ, компоненты, 52WebSphere MQ, конфигурация, 92, 93WebSphere MQ, координация единиц

работы, 117WebSphere MQ, лицензии

на сервер, 52WebSphere MQ, операции

и put­ get­, 54WebSphere MQ, очистка, 118

336 Предметныйуказатель

WebSphere MQ, примеры, 196WebSphere MQ, проблемы, 285WebSphere MQ,

программы­примеры, 240WebSphere MQ, разработчики

приложений, 2WebSphere MQ, ресурсы, 76WebSphere MQ, сбои подключения

приложений, 286WebSphere MQ, системные журналы

ошибок, 105WebSphere MQ, структура, 51WebSphere MQ, терминология, 118WebSphere MQ, технология, 22WebSphere MQ, трассировка, 302WebSphere MQ, установка сервера, 87WebSphere MQ, хранилище

ключей, 277Web­браузер, 26

X

XMITQ, 122

Z

z/OS, возможности платформы, 89z/OS, инициатор каналов, 101

A

Авторизация доступа к службам, 16Авторизация приложений, 114Адаптер, индивидуальный, 48Администрирование инфраструктуры

WebSphere MQ, 2Администрирование линейных

журналов, 313Администрирование связующей

структуры, 309Алгоритм балансировки нагрузки

кластеров, 1Алгоритм шифрования, 275Аппаратные платформы, 4Архивация, 313Архитектура, центрально­лучевая, 256Асинхронная коммуникация

приложений, 121

Асинхронная природа отправки и получения сообщений, 24

Асинхронное взаимодействие, 6, 10Атрибуты конфигурации, 96Атрибуты, получение значений, 115Аутентификация каждого вызова

MQI, 139Аутентификация по SSL­протоколу, 138

Б

Балансировка нагрузки, автоматическая, 33

Балансировки нагрузки, алгоритм, 179

Бизнес­логика, 4, 9Брокер публикации и подписки, 22Брокер, 8Брокер, встроенный, 70Брокеров, сеть, 70Буферизация, данных в памяти, 102Буферы между всеми узлами

системы, 6Буферы между промежуточными

узлами, 6

В

Взаимодействие через туннель, 284Взаимодействие, синхронное, 6Влияние на скорость работы, 11Влияние на службы, 17Вмешательство извне, 16Внешние интерфейсы, 4Внешний менеджер транзакций, 117Возможности по обслуживанию, 6Возобновление членства

в кластере, 180Восстановление с носителя, 103Восстановление состояния объектов,

102–103Восстановление, надежное, 18Временная динамическая локальная

очередь, 126Временные динамические

очереди, 119Временные отметки, 104Вызов MQOPEN, 118

Предметныйуказатель 337

Вызов авторизованным приложением, 10

Вызов, неудачный, 113Вызов, успешный, 113Вызов, частично завершенный, 113Выпадающий список Filter, 77Выполнение действий вручную или

автоматически, 25Выполнение действия, 4Высокодоступные функции,Высокое быстродействие, 11Выход из строя, 12

Г

Гарантии, 12Генерация триггерных

сообщений, 218Группа с разделением данных, 89Группа сообщений, логическая, 68Группировка в пакеты,Группы, автоматическое

создание, 91–93,

Д

Данные запросов, 12Данные менеджера очередей,Данные, простые символьные, 5Данные, резервное копирования или

реорганизация, 16Данные, секретные, 16Данных, количество, 18Данных, конвертация, 50Данные, целостный характер,

нарушение, 16Дата и время, хранение, 112Движение, автоматическое, 6Действие, неудачное завершение, 286Действие, неудачное завершение, 287Действия, продолжительность, 18Дейтаграмма, 63Дескриптор объекта, 114Деятельность и убытки, 16Диагностика и устранение

неполадок, 285Диапазон значений, 286Динамическая очередь, 125Динамическая очередь, временная, 67

Динамические очереди, 119Документация, исчерпывающая, 300Дополнительная балансировка

нагрузки, 162Дополнительная память, 106Дополнительные функции группы

общих очередей, 308Допустимые комбинации команд, 154Доставка сообщений, правильная, 5Доступ к существующим службам, 11Древовидное представление, 76

Е

Единая точка отказа, 17Единица работы, локальная, 117Единица работы, передача, 117

Ж

Жесткие временные рамки, 18Журнал активный, увеличение

максимального размера, 312Журнал менеджера очередей, 90,

91, 107Журнал, ведение в деталях, 104Журнал, возможность

воспроизведения записей, 313Журнал, временное добавление

наборов данных, 313Журнал, выбор механизма, 104Журнал, заполнение, 313Журнал, непрерывный, 103Журнал, переход к новому

экстенту, 313Журнал, старые записи, 104Журнал, уменьшение размера, 104Журнал, управление размером, 103Журналы ошибок менеджера

очередей, 104, 268Журналы, архивация и удаление, 103Журналы, системные, 104–105

З

Завершение обработки, полное, 6Завершение обслуживания, 11Завершение строки, 201Завершение, неполное, 113

338 Предметныйуказатель

Заданный временной интервал, 11Записи журнала, 102Запись в надежное хранилище, 102Запись образа носителя, 104Запрос в вызове MQOPEN, 114Запрос службы, 4, 11Запрос, скорость обслуживания, 12Запрос, число, 11Запросы, дополнительные, 12Запросы, успешно принятые, 11Запрошенное действие, 114Защита конфиденциальности данных

при передаче, 275Защитные технологии, помышленный

стандарт, 275Защиты, нарушение, 105Значения по умолчанию, хранение, 93

И

Идентификатор корреляции, 116Идентификатор пользователя, 97, 112,

114, 140Идентификатор сообщения, 111Извлечение сообщений, 5Издатели, множественные, 8Имена объектов, 194Имитация сущности, 16Имя подключения, 99Инициатор канала по умолчанию, 158Интенсивность, постоянная, 6Интервал времени, 6, 11Интерфейс между промежуточным

слоем и существующей службой, 11Интерфейсы администрирования,

22, 73Интерфейсы, простые, 16Информации, логический поток, 9Информации, обновление, 9Информации, перекодирование, 5Информация доступная, 286Информация о событии, 8Информация о состоянии, 7–8Информация, потеря целостности, 17Инфраструктура и службы

организации, 4Инфраструктура локальная,

расширение, 235

Инфраструктура системы, 4Инфраструктуры, базовые

компоненты, 10Использование интрасетей

и брандмауэров, 274Использование мастера Create queue

manager, 91Использование оптимизированных

механизмов, 102Использование подключений

посредством связывания, 106Использование самоподписанных

сертификатов, 282Использование сетевых

подключений, 106Использование стороннего центра

сертификации, 282История устранения неполадок, 290Исходные требования, 11Исходный отправитель сообщения, 22ИТ­инфраструктура, 4

К

Канал сообщений кластера, 100Канал сообщений,

распределенный, 100Канал, запуск инициатора, 101Канал, неоднозначный, 151Каналы в состоянии INDOUBT, 152Каналы связи, технологии защиты, 16Каналы сообщений, распределенные

и кластерные, 89Канал, статистика, 312Каналы, 22Каталог, 27Каталог данных менеджера

очередей, 90Каталог, установочный,

по умолчанию, 90Качество функционирования

системы, 18Кластер менеджеров очередей, 23,

148, 162Кластер менеджеров очередей, 33Кластер, 162Кластер, инфраструктура, 235Кластер, источник сведений о, 177Кластерные очереди сообщений, 119

Предметныйуказатель 339

Кластерный sender­канал, 167Кластерный sender­канал,

автоматический, 167Кластерный sender­канал с явным оп­

ределением, автоматический, 167Кластеры высокой готовности, 39Кластеры высокой готовности,

ПО поддержки, 40Кластеры высокой готовности,

решение, 40Кластер, подключение к, 165Кластер, приостановка членства, 180Кластер, публикация в, 165Кластер, список имен, 166Клиентский канал, 138Клиентское подключение по сети, 52Клиентское подключение,

использование, 113Клиентское подключение,

методы, 106Клиенты, 30Код причины, 110–111, 127, 232, 286Код, завершение, 112–113Команда разработчиков

приложения, 10Командный сервер, 85Коммуникационные протоколы, 91Компоненты и технологии, 4Компоненты инфраструктуры, 10Компоненты, обновление, 17Контролирующая среда, 38Контрольная точка, 103Контрольная точка, автоматическая,

103Конфигурация объектов, изменение,

102Конфигурация, сведения о, 91, 92–94Концентрация усилий по разработке,

10Коррелирование откликов, 111Криптографические модули, 308Криптография, симметричная

и асимметричная, 275

Л

Линейная журнализация, 103Линии связи различных типов,

скорости, качества, 9

Логическая группировка, 5Логический раздел (LPAR), 89

М

Максимальное число каналов, 191Малые интервалы опроса, 8Маршрут к удаленной службе, 10Масштабируемость, 11Межточечный обмен и обмен

сообщениями по принципу публикации­подписки, 43

Менеджер очередей локальный, 113, 129

Менеджер очередей по умолчанию, 94, 95

Менеджер очередей с частичным репозиторием, 163

Менеджер очередей, 22Менеджер очередей, cоздание, 196Менеджер очередей, автоматический

перезапуск, 98Менеджер очередей,

администрирование, 22Менеджер очередей, внезапная

остановка, 102Менеджер очередей, завершение, 97Менеджер очередей, запуск, 96Менеджер очередей, изменение, 79Менеджер очередей, метод

завершения по умолчанию, 97Менеджер очередей, общие задачи

конфигурирования, 193Менеджер очередей, очистка, 96Менеджер очередей, перезапуск, 104Менеджер очередей, принимающий

ответы, 110–111Менеджер очередей, принудительное

завершение, 99Менеджер очередей, создание, 197Менеджер очередей, сокращение

нагрузки, 67Менеджер очередей, типы, 111Менеджер очередей, удаленный,

подключение, 58Менеджер очередей, штатное

завершение, 103Менеджер ресурсов, 56Менеджер транзакций, 56

340 Предметныйуказатель

Менеджер, плановый перезапуск, 35Менеджеры очередей и клиенты, 99Менеджеры очередей, сбои

взаимодействия, 286Менеджеры очередей сообщений,

обновленные, 78Менеджер очередей, подсистема 268Метаданные сообщения, 49Методы, клиентское подключение,

106Минимизация влияния, 17Модель защиты, 267Модель обмена сообщениями по

принципу публикации и подписки, 7–8

Модель публикации и подписки, пример, 226

Модификация стандартизованного API, 27

Мониторинг использования, 18Мониторинг производительности, 18

Н

Набор буферов, 118Набор данных менеджера очередей,

268Набор процессов, 92Набор селекторов, 118Наборы страниц и пулы буферов, 313Навигатор, 76Нагрузка, 11Нагрузка, превышающая пропускную

способность, 12Нагрузка, чрезмерная, как временное

явление, 12Нагрузки, изменение, 12Нагрузки, прогнозирование, 11Надежность и безопасность, 11Надежность системы, 16Настроек, изменение, 16Настройка параметров отчета, 111Начальная производительность

и пропускная способность, 11Необходимость защиты, 10Неоднозначное состояние,

автоматическое разрешение, 152Неполадки, внешние симптомы, 300

Несохраняемые публикации, 72Неудачная операция в WebSphere MQ

Explorer, 286Неудачное завершение управляющей

программы в WebSphere MQ, 286Номера мест назначения сообщений,

188Нулевой интервал отключения, 152

О

Обновление базы данных, 7Обновление подписки через 27 дней,

172Обработка ошибок, упрощенный

механизм, 29Обработчик очереди недоставленных

сообщений, пользовательский обработчик, 157

Образ носителя, 104Обслуживание, плановое, 16Объединение узлов, 4Объект receiver­канала, 153Объект requester­канала, 153Объект локальной очереди, 119Объект очереди, 114Объект, определение, 90,Объект, открытый для запроса, 118Объект, открытый для установки, 118Объекты server­канала, 154Объекты менеджеров очередей, 96Объекты очередей, 53Объекты, текущее состояние, 102Однократная доставка, 13Ожидание заданных сообщений, 116Операционные системы, 4Описание объектов, 114Описатель объекта (Hobj), 114Определение каналов с помощью

MQSC, 153Определение объектов в менеджере

очередей, 118Определение терминов, 11Определение, обобщенное, 25Опрос, 7Оптимизация, очереди сообщений,

инфраструктура, 6Оптимизация, очередь, 5

Предметныйуказатель 341

Оптимизация, периоды загрузки, 6Особые типы локальных очередей,

119Останов, немедленный, 97Останов, принудительный, 97Ответ на отчет, 110–111Ответ службы, 65Отказ аппаратуры, 17Отключение, нормальное, 99Открытие объекта очереди, 114Отображение атрибутов всех

объектов, 84Отображение заданных атрибутов, 84Отображение полномочий, 272Отправка команд MQI, 110Отслеживание изменений, 7Отчет об активности, 298Отчеты в WebSphere MQ, 64Отчеты со статистикой, 41Очередей общих, использование, 89Очереди с идентичными именами, 25Очереди сообщений, 4Очереди сообщений, важные

особенности инфраструктуры, 9Очереди сообщений, формирование,

21Очереди сообщений, технология 3, 10Очередь возврата, 61Очередь недоставленных сообщений,

101Очередь недоставленных сообщений,

обработка, 157Очередь ответов, 65Очередь подписчика, выбор, 71Очередь сообщений, контекст, 17Очередь, определение и изменение

псевдонима, 124Очередь, постановка в, 17Очередь, пункт назначения, 115Очередь, экземпляр, 265Ошибки на жестком диске, 35

П

Пакет межсетевых протоколов, 284Пакет, единый, 6Пакетная обработка, 6

Пакетный запуск менеджера очередей, 94

Пакеты исправлений, 289Память, дополнительная, 106Память, объем, 306–307Пара sender­receiver, 155Параметры создания менеджера

очередей, 92Первичные менеджеры очередей, 39Передача сообщений, 5Перезапуск процесса, 102Период времени, 6, 11Планирование, 18Платформа с 64­разрядной

адресацией, 107Повреждение, 103Повреждение, катастрофическое, 18Повтор записей журнала, 102–103Повышение эффективности

разрешения имен, 285Поддержание приложений

и взаимодействие с ними, 10Подключение, успешное, 114Подписка, 8Подписка на полный репозиторий,

172Подписчики, динамический рост

и сокращение числа, 9Подсистема QMQM, запуск, 94Поле кодировки, 112Полная хронология, 288Полномочия OAM, предоставление

и отзыв, 272Получение по идентификатору

корреляции, 116Получение по идентификатору

сообщения, 116Пользователь, внешний, 19Пользователь, внутренний, 19Порог сообщений, 6Постоянная динамическая локальная

очередь, 126Потеря данных из­за сбоев связи, 117Поток операций, автоматический, 22Поток сообщений, 110Потребители информации, 8Потребление, однократное, 6Представление, десятичное, 287

342 Предметныйуказатель

Представление, шестнадцатеричное, 287

Привязка, 187Привязка сообщений, 187Прикладной интерфейс

программирования (API), 26Приложения, взаимосвязанные, 236Приложения, внезапное завершение,

58Приложения, использующие

связывание, 114Приложения, модификация, 11Приложения, перенос, 11Приложения, переносимость, 11Приложения, разработка, 10Приложения, 32­ и 64­разрядные, 306,

307Принцип «отправил – забыл», 7Проблемы при обработке системных

сбоев, 9Проблема, устранение, общие

сведения, 183Программные компоненты, 4Программа­клиент, стандартная, 58Производительность, 11, 12, 106Прокси, реализация, 11Промежуточное ПО, 4, 10Промежуточные данные, 12Промежуточные узлы, 6Пропускная способность, 11, 12Просмотр сведений из репозитория

кластера, 174Просмотр сообщения, функция, 116Просмотр текста, 105Простои плановые и неплановые,

минимизация, 16Процедурный интерфейс, 110Процесс­создатель, 95Публикации и подписки, упрощение

работы, 8Пулы каналов, 100

Р

Работа с промежуточным слоем, 10Различия в функциональности, 306Размещение сообщения запроса, 111Разрыв связи поставщика

с потребителем, 8

Разъединение, интервал, 165Расширение наборов страниц, 313Регистрация действий, 102Реестр Windows, 91Резервное копирование, стратегия, 18Репозиторий, 89Ресурсов, выделение и освобождение,

12Ресурсов, недостаточность, 16Ресурсов, предоставление, 11Ресурсоемкий процесс, 9Ресурсы, дополнительные, 11

С

Сбои из­за нарушения целостности информации, 16

Сбои отправки­получения сообщений, 286

Сбои, фатальные, 12Сбой связи, 10Сбой, внезапный, 35Сбой, определение причины, 287Сведения об отказах, 105Сводка функций, 305Связанная библиотека, 94Связанные системы и службы, 6Связующий механизм (CF), 89Связывание, 52Связь, установка, 99Сеанс, терминальный, 222Сервисные обновления, установка,

289Сертификат, доверенный, 282Сертификат, метка, 278Сетевые подключения,

использование, 106Сетевые соединения, 6Сжатая форма, 104Символическое имя, 113Символы текстовые, 111Синтаксис MQSC, 83Система, целостность, 56Система, эффективное

восстановление, 17Системы коммуникаций, 4Системы, взаимосвязанные, 5Сложность инфраструктуры, 4

Предметныйуказатель 343

Служб, высокая готовность, 16, 38Служб, доступность, 17Служба, начало и окончание работы,

11Служба, планирование,

проектирование, разработка и предоставление, 11

Служба, пропускная способность, производительность, 60

Служба, размещение, 4Служба, удаленная, 9Службы, 4Службы, единственный экземпляр, 17Службы, повышение готовности, 161

Службы, сложность, 16Слушатель и TCP/IP, 101Слушатель, настройка, 100Слушатель, создание, 100С­модули, вызов, 110«снизу­вверх», подход, 28Снижение простоев, 17События, неожиданные, 105Советы и инструкции, 290Соединение узлов, 4Соединение, быстрое, 31Создание, автоматическое, 94Сообщение, максимальная длина, 90Сообщение, невозможность доставки,

101Сообщение, неполное, 116Сообщение, превышение предельного

размера, 116Сообщение, указание корректного

места назначения, 9Сообщение­запрос, 7Сообщения, доставка, 115Сообщение, доступность, 17Сообщения, обработка, 6Сообщения, получение, 8Сообщения и очереди, 4Сообщения идентификатор, возврат,

111Сообщения идентификатор,

генерация, 111Сообщения, потребление

и обработка, 6Сообщения приоритетные, 111

Сообщения с высоким приоритетом, 6

Сообщения с низким приоритетом, 5, 111

Сообщения статистики очереди, 312Сообщение тип, 110Сообщения, восстановление, 18Сообщения, связанные

с дейтаграммами, 116Сообщения, сгруппированные,

или сегментированные, 112Состояние, текущее, 12Состояния, изменение, 12Сохранение строковых атрибутов

канала, 118Сертификат, персональный, 277Страница содержимого, 76Строковые данные, 111Структура, автоматическое выделение

и перестройка, 90Структура, определение, 110Сценарии, 96Счетчик возвратов, 61

Т

Табличное представление всех объектов, 76

Тема, 8Технологии, новые, 4Точка входа, 87Точка согласованности,

последняя 102–103Транзакция, 54Транспорт для Web­сервисов, 308Транспортная очередь, настройка, 158Транспортный слой, 29Трассировка в iSeries, 304Трассировка в UNIX, 303Трассировка в WebSphere MQ для AIX,

5L, V5.3, 303Трассировка в Windows, 302Трассировочные сообщения, 312Требования к ресурсам, 8Триггеринг, механизм, 62Триггерное сообщение, 135

344 Предметныйуказатель

У

Удаление при вызове MQCLOSE, 119Удаление, автоматическое, 119Узел, 4Узел, поврежденный, 18Узел запроса, 8Успешная доставка, 110–111Успешная обработка, 111Успешное окончание всех действий,

17Устройство сопряжения, 89Учет операций, 18

Ф

Файловые сиcтемы, 92Физическая площадка, 18Формат данных, символьных

и числовых, 10Форматирование заголовков, правила,

229Функции, переопределение, 264

Х

Хост­имя (порт), 175Хостинг в менеджере очередей, 114

Ц

Целевая очередь, 124Целевая служба, 4Центр сертификации, создание, 282Цепь структур, 112Циклическая логика, 104Циклическое ведение журнала

по умолчанию, 103Цифровая подпись, 275Цифровые сертификаты, 275

Ч

Частичный или полный репозиторий, 163

Частичный репозиторий, 163Частота регистрации в журнале, 105Число активных MCA, 100Число клиентов, 30

Числовые данные, 5Числовые целочисленные атрибуты,

118Членство в QSG, 89

Ш

Шифрование, 10Шифрование, алгоритм, 275Шлюзы доступа в инфраструктуре, 33

Э

Экземпляр очереди, 265Электронное письмо, отправка, 25Элемент данных очереди, 103