Административные команды и доступ к объектам менеджера очередей
Система очередей сообщений позволяет контролировать исполнение административных команд и доступ к объектам менеджера очередей - к самому менеджеру и очередям. WebSphereMQ имеет специализированную компоненту - менеджер безопасности, который позволяет определить и разграничить доступ к объектам. Кроме того, предоставляется документированный интерфейс для управления функциями безопасности, на основе которого возможно создать собственный менеджер безопасности.
Администрирование системы очередей
Распределенная гетерогенная система, такая как система очередей сообщений MQSeries требует особенного внимания к вопросам удаленного администрирования. WebSphereMQ в этом аспекте предоставляет ряд интерфейсов и утилит для администрирования и конфигурации, включая администрирование очередей, каналов сообщений, безопасности. Для этих целей используются команды двух типов – скриптовые и программные. Административные скриптовые команды MQSC предназначены для работы администратора в режиме командной строки или для пакетного использования текстовых файлов-скриптов. При этом утилита командной строки RUNMQSC преобразует текстовые команды в вызовы API, а затем возвращает пользователю ответные сообщения (рис.1.6).
Программный интерфейс PCF (Programmable Command Format) обеспечивает вызов административных функций непосредственно из прикладных программ. Для удаленного администрирования менеджеров очередей использует специальные командные очереди для приема/передачи административных команд-сообщений и специальные мониторы (command servers) для их исполнения.
Рис. 1.6. Административные компоненты и интерфейсы WebSphereMQ
Графические средства администрирования, в первую очередь WebSphereMQ Explorer позволяют удобно администрировать обьекты WebSphereMQ, создавать и изменять объекты и их параметры, следить за состоянием локальных и удаленных серверов. Более широкий подход предполагает включение системы очередей сообщений в корпоративную среду управления и использование общих пакетов управления системами: Tivoli Module for WebSphere Business Integration, Candle Omegamon, Command MQ (Bool&Babbage), Patrol KnowledgeModule для MQSeries (BMC).
Адресация и маршрутизация сообщений
Сервер системы очередей сообщений отправляет сообщения различным адресатам, пользуясь информацией из заголовка каждого сообщения: имя менеджера очередей для идентификации узла и имя очереди для идентификации самой очереди.
В стандартной двойной структуре имен, лежащей в основе системы маршрутизации MQSeries - WebSphere MQ, предусмотрены дополнительные правила, расширяющие возможности идентификации очередей. Кроме прямого использования полных имен очередей реализован алгоритм разрешения имен, позволяющий указывать адресатов при помощи псевдонимов очередей и определений удаленных очередей. Это дает возможность привязывать имена очередей, заложенные разработчиками приложений в процессе кодирования программы к реальной системе очередей. В частности, при изменении физической конфигурации системы администратор сети при помощи административных команд может переопределить маршрутизацию сообщения к новому местоположению очереди без изменений кода приложения.
Механизм разрешения имен системы очередей сообщений используется для организации многошаговой маршрутизации сообщений через произвольное число промежуточных менеджеров очередей.
Для обработки сообщения важным является адрес очереди ответа, то есть хранящаяся в заголовке сообщения информация о том, в какую очередь должен быть отправлен ответ на это сообщение. Имя очереди ответа используется для организации связи типа запрос- ответ, а также для организации отправки многочисленных сообщений-отчетов, информирующих о системных событиях, например, о доставке сообщения в очередь назначения или о выборке этого сообщения приложением - адресатом.
Для отслеживания и исправления ошибок у менеджера очередей имеется специальная очередь DLQ (Dead-Letter Queue) для хранения недоставленных сообщений. Чаще всего сообщения попадают в DLQ, когда очередь, указанная в заголовке сообщения, не существует или когда очередь назначения оказывается полной. Очереди недоставленных сообщений позволяют разгрузить транспортные очереди от ошибочных сообщений и освободить каналы от непрерывных повторных обработок. При попадании сообщения в очередь недоставленных сообщений в его тело вставляется специальный информационный подзаголовок, позволяющий анализировать причины попадания в DLQ. MQSeries обладает механизмом задания правил для автоматической обработки недоставленных сообщений.
Адресация по принципу публикация-подписка
Прикладные программы-публикаторы посылают свою информацию с указанием темы в виде сообщения менеджеру очередей. Другие приложения - подписчики присылают заявки на информацию по темам. Присланные публикации распределяются между подписчиками через очереди сообщений специальной программой - брокером в соответствии с темами публикаций.
Асинхронное взаимодействие
При использовании очередей сообщений, нет необходимости, чтобы взаимодействующие приложения были активны одновременно. Программа может отправить сообщение другому приложению, которое обработает его, когда сочтет нужным. Отправив сообщение, программа может не ожидать ответа, а продолжать выполнение других задач.
Безопасность приложений
Программный интерфейс MQI предоставляет приложениям средства идентификации в сообщении пользователя, приложения и платформы. Идентификационная информация содержится в заголовке сообщения, передается вместе с ним и только привилегированные приложения могут ее изменять. Приложения могут использовать эту информацию для дополнительной проверки получаемых сообщений.
Безопасность в каналах передачи сообщений
Для защиты информации передаваемой между менеджерами очередей, WebSphereMQ поддерживает возможности подключения специально разрабатываемых модулей. Например, два менеджера очередей, устанавливающих связь по каналу, могут с помощью дополнительных программ опознать друг друга. Кроме этого, сообщения, передаваемые по каналу, могут шифроваться перед передачей и расшифровываться при приеме.
Функции и модели взаимодействия системы очередей сообщений
Система очередей сообщений обеспечивает асинхронный метод взаимодействия для программ. Метод не требует установления прямой связи между интегрируемыми программами и позволяет поддерживать обмен данными в виде сообщений, независимо от аппаратной или операционной системы. При этом гарантируется, что сообщение не будет потеряно или получено дважды.
Система очередей сообщений предоставляет прикладным программам сервис для отправки и получения сообщений. Очереди представляют промежуточное место хранения сообщений, как бы специализированную базу данных со всеми механизмами, гарантирующими сохранность: журналирование, восстановление после сбоев, транзакционная обработка. При этом приложения обращаются к очередям при помощи прикладного программного интерфейса. Сообщение, предназначенное для другой программы, должно быть доставлено в очередь назначения. Сообщение может передаваться через распределенную систему серверов - менеджеров очередей. Каждый раз, получая сообщение, менеджер очередей записывает сообщение в локальную очередь, затем передает сообщения по сети другому менеджеру очередей. При этом гарантируется, что сообщение не будет потеряно или получено дважды. Программа-адресат обращается к целевой очереди и получает доступ к сообщению.
Поддержка асинхронного взаимодействия приложений при использовании очередей сообщений позволяет гибко интегрировать разнородные прикладные системы, не меняя внутренней логики их работы. Существование промежуточного звена в виде очередей сообщений позволяет вставлять промежуточную обработку передаваемой информации для решения самых различных задач: обеспечение безопасности, трансформации данных в разных форматах, динамической маршрутизации, анализа содержания передаваемых данных и так далее. Промежуточное звено позволяет применять различные топологии вычислительной среды, соединяя потоки данных для централизованной унифицированной обработки и разделяя их для функционально разнородной обработки.
Средства МОМ имеют своих предшественников в виде систем для передачи файлов типа FTP, решений типа экспорта - импорта данных с использование различных промежуточных хранителей: файлов, буферов памяти, баз данных. Находяясь долгое время в виде вспомогательных и частных средств, класс подобного программного обеспечения стал бурно развиваться и стандартизироваться в связи с выходом на первый план задач интеграции прикладных систем между собой.
Системы очередей сообщений позволяют программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения изолируются друг от друга транспортным слоем, состоящим из менеджеров очередей, берущих на себя задачи обеспечения коммуникаций. С помощью очередей сообщений (рис.1.2) могут быть реализованы как традиционные модели взаимодействия программ (клиент-сервер), так и модели, которые реализуются только при помощи сервиса сообщений.
Рис. 1.2. Взаимодействие клиент-сервер через очередь сообщений
Интеграция приложений – пути решения
Современные корпоративные системы характеризуются как сверхсложные и гетерогенные, распределенные по различным платформам. Положение большинства предприятий в настоящее время во многом определяется тем, что логика интеграции и взаимодействия систем встроена в отдельные приложения. Технология взаимодействия приложений ограничена транспортными механизмами для передачи данных. Потребности бизнеса и набирающего силу электронного бизнеса диктуют необходимость связи и интеграции этих гетерогенных систем и платформ. Современным корпорациям требуются надежные и тотально-распределенные вычислительные инфраструктуры, интегрирующее middleware, решающее задачи интеграции различных прикладных систем между собой. Появился даже специальный термин – Enterprise Application Integration (EAI) – Интеграция Приложений.
Общепринятый в мировой практике подход к интеграции заключается в уходе от создания прямых интерфейсов приложений и в использовании интеграционного связующего программного обеспечения (ПО), которое способно обеспечить выполнение всех функций, необходимых крупной корпорации. В результате становятся возможными централизация и стандартизация подхода к интеграции, что позволит предприятиям разработать интеграционную среду, которую можно будет совершенствовать и изменять в соответствии с эволюцией бизнес среды.
Для решения задач интеграции приложений существует так называемое промежуточное программное обеспечение (middleware), призванное решать проблемы взаимодействия между распределенными прикладными и системными программными компонентами. Промежуточное ПО позиционируется как системный слой между прикладными программами и операционными системами. Использование промежуточного программного обеспечение становится особенно важным когда идет речь о физически или логически (может быть даже на одной аппаратной платформе) распределенной системе.
Среди разнообразного промежуточного ПО принято выделять три базовых категории, представленных рис.1.1:
Промежуточное ПО для управления базами данных. Примерами из этой категории являются средства удаленного доступа к базам данным, компоненты или библиотеки Open Database Connectivity (ODBC) и Java Database Connectivity (JDBC). Коммуникационное промежуточное ПО обеспечивает программам обращение к другим удаленным программам, библиотеки удаленного вызова процедур (remote procedure call -RPC), средства передачи и обмена сообщениями (message-oriented middleware - MOM) и другие подобные технологии. Платформенное промежуточное ПО помогает взаимодействию компонент в рамках среды исполнения прикладной логики, такое как сервера приложений, мониторы транзакций, порталы, брокеры объектных запросов (object request broker- ORB).
Рис. 1.1. Базовые категории промежуточного программного обеспечения
Помимо базового промежуточного ПО часто выделяют специализированное интеграционное промежуточное ПО, куда относятся средства позволяющие взаимодействовать программам и системам, принципиально различным друг от друга.
Примерами таких систем могут быть интеграционные брокеры, системы управления бизнес-процессами, шлюзы и адаптеры к различным системам.
Системы очередей сообщений (MQ-Message Queuing) или чуть более общую группу систем, использующих технологию передачи сообщений (Messaging Oriented Middleware - МОМ), принято относить к категории middleware - промежуточного программного обеспечения или, более точно, к базовому коммуникационному программному обеспечению, однако часть функциональных возможностей систем очередей сообщений позволяют говорить об этом программном обеспечении как об интеграционном.
Отметим сразу ориентацию на асинхронное взаимодействие программ как на ключевое отличие систем очередей сообщений от наиболее распространенных в среде распределенных клиент-серверных решений технологий синхронного удаленного вызова процедур (RPC). Целый ряд функций, поддерживаемых системами очередей сообщений наилучшим образом, таких как гарантированная доставка информации, разнообразные модели взаимодействия программ (один к одному, многие ко многим, контекстная адресация и обработка) делают эту технологию привлекательной для ряда задач, в первую очередь интеграционных. Многие аналитики, например Gartner Group, наблюдающие современные тенденции в компьютерной индустрии, отмечают очень быстрый рост количества решений, использующих очереди сообщений в силу гибкости подобной архитектуры. На рынке присутствуют целый ряд систем очередей сообщений, каждая со своими особенностями. При этом система очередей сообщений фирмы IBM MQSeries - WebSphere MQ является, бесспорно, самой распространенной системой, занимает более 80 процентов рынка в данной категории и может считаться неофициальным стандартом и эталоном системы очередей сообщений.
В качестве примеров некоторых других известных систем очередей сообщений можно назвать: Message Queue (MSMQ) Services компании Microsoft, EntireX компании SoftWareAG, Advanced Queuing (AQ) компании Oracle, FioranoMQ компании Fiorano, SonicMQ компании Sonic Software, TIB/Rendezvous компании Tibco Software.
Каналы передачи сообщений: Как сообщения пересылаются по сети?
В распределенной среде за передачу сообщений отвечают сетевые компоненты системы очередей сообщений. В IBM WebSphere MQ используется система каналов передачи сообщений, обеспечивающая гарантированную передачу сообщений поверх разнообразных сетевых соединений. При использовании протокола гарантированной передачи WebSphere MQ MCP (Message Channel Protocol) посылаемое сообщение не будет удалено из очереди на сервере посылки до тех пор, пока это сообщение не будет полностью принято на сервере - адресате, то есть реализуется сетевая транзакция при передачи сообщений.
Рис. 1.4. Передача сообщений между системами
Каналы соединяют менеджеры очередей и позволяют осуществлять направленную посылку сообщений. В WebSphere MQ каналы являются однонаправленными и состоят из пары взаимодействующих канальных агентов (Message Channel Agent - MCA). Для двусторонней связи необходимо определить два канала. Существует несколько типов каналов. Типы каналов различаются тем, какая сторона в канале является инициатором установки связи, а какая источником сообщений. В комбинации каналов типа Sender-Receiver одна сторона Sender является инициатором связи и источником сообщений, вторая сторона Receiver только откликается на инициирующий запрос и принимает поток сообщений, в другой комбинации канал Requestor-Server, инициирующая соединение сторона Requestor принимает сообщения от стороны Server.
После установки связи из транспортной очереди в канале начинается передача сообщений. Сообщения удаляются из транспортной очереди передающего менеджера, только после подтверждения доставки сообщения другим менеджером. Использование в протоколе MCP контрольных точек позволяет концам канала синхронизировать передачу числа сообщения в случае системного или сетевого сбоя. Если линия связи недоступна, MQSeries может автоматически совершать повторные попытки передачи после восстановления связи. Протокол МСР используется при передаче сообщений поверх транспортных протоколов более низкого уровня TCP/IP, LU6.2, DECnet, NetBios, IPX/SPX.
Модель клиент/сервер
Запросы клиента передаются в виде сообщений в серверную очередь. После обработки запроса приложение-сервер, отправляет ответ в виде нового сообщения в очередь, указанную клиентом в сообщении-запросе.
Основные компоненты и особенности работы системы очередей сообщений
Основными элементами системы очередей сообщений являются:
сообщения, которые прикладные программы посылают друг другу; очереди, где хранятся сообщения; менеджеры очередей – серверные компоненты, которые управляют очередями и обработкой сообщений; каналы передачи сообщений, которые связывают менеджеры очередей между собой.
Введем следующие определения.
Сообщения (Message) представляют собой структуру данных, состоящую из заголовка сообщения (MQMessageDescriptor) и прикладных данных (рис.1.3). Заголовок содержит контрольную и адресную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда надо передавать сообщение.
В создании и изменении заголовочной информации принимают участие, как приложения - отправители, так и системные компоненты менеджера очередей. Содержание контрольной информации важно для безопасности системы передачи сообщений и поэтому для изменения и перекопированния контрольной информации в новые сообщения определяются специальные права.
Рис. 1.3. Структура сообщения
Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. WebSphereMQ поддерживает произвольные форматы данных, однако бывают системы очередей сообщений, которые разрешают только свои специальные форматы, например XML специального вида. Поскольку в распределенной среде для приложений, функционирующих под управлением различных ОС существуют различные кодовые страницы и методы представления данных, система очередей должна поддерживать методы конвертации передаваемых данных.
Очередь сообщений (Queue) - основное место хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ. Приложения имеют доступ к очередям через программный интерфейс MQI (Message Queue Interface). Для передачи критически важной информации используется "постоянные" (persistence) сообщения, которые журналируются и восстанавливаются после рестарта менеджера сообщений. Для повышения производительности системы очередей сообщений поддерживает также и "непостоянные" сообщения, которые содержатся в оперативной памяти, не журналируются и могут быть потеряны в результате системного или аппаратного сбоя.
Менеджер очередей (Queue Manager) является главным серверным компонентом и отвечает за управление очередями сообщений и прием вывозов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей поддерживают единый программный интерфейс, единую систему адресации и обмена данных через каналы, и единую систему администрирования.
Параллельная и распределенная обработка
Исполнение прикладного процесса может быть распределено между несколькими прикладными программами. Старт, координация между программами и консолидация результатов обработки на разных системах реализуются путем пересылки сообщений через очереди.
Прикладной программный интерфейс
Прикладные программы взаимодействуют с WebSphereMQ через программный интерфейс MQI (Message Queue Interface). MQI имеет единую структуру на всех платформах и основан на простой системе из десятка команд:
команда подключения к менеджеру очередей MQCONN команда открытия очереди MQOPEN команда помещения сообщения в очередь MQPUT команда выборки сообщений из очереди MQGET вспомогательные команды запроса и установки атрибутов очередей MQINQ и MQSET команды успешного завершения транзакции MQCMIT команда отката транзакции назад MQBACK команда закрытия очереди MQCLOSE команда отсоединения приложения от менеджера очередей MQDISC.
При создании приложений, обеспечивается поддержка интерфейса MQI для языков программирования: C/С++, Java, SmallTalk, Cobol, PL/1, Lotus LSX, Basic. Надо отметить, что разработка приложений для систем очередей сообщений имеет свои особенности, приведенные в последующих лекциях.
Применение системы очередей сообщений
Программное обеспечение систем очередей сообщений является одной из наиболее перспективных технологий для интеграции систем. Среди первостепенных достоинств систем очередей сообщений как решения для интеграции, можно указать простоту, надежность и универсальность данного подхода.
Достоинства архитектуры очередей сообщений позволяют использовать ее, как для задач интеграции готовых приложений, так и разработки совершенно новых систем, базирующихся на принципах обработки событий и передачи сообщений и в полной мере использующих все преимущества новых подходов. Можно указать на следующие типичные задачи интеграции систем:
Интеграция приложений в распределенной гетерогенной среде; Организация взаимодействия независимо работающих приложений или приложений, работа которых разделена во времени; Сложные распределенные и/или распараллеленные процессы обработки; Пересылка файлов, передача больших объемов данных; Синхронизация и репликация данных ; Поддержка мобильных клиентов.
Достаточно частыми являются случаи кросс-платформенной интеграции, например, серверное приложение, работающее на рабочей станции под управлением операционной системы UNIX, должно посылать данные об обновлениях базы данных и проведенных транзакциях приложению на сервер системы iSeries или мейнфрейм.
Между разными приложениями, работающими на одном мощном сервере, может быть организовано межсистемное взаимодействие, например, между подсистемами OS/390, когда другие технологии межсистемного взаимодействия оказываются более сложными.
Многие сервисные организации, в первую очередь в области финансовых услуг, используют очередь сообщений как базовый транспорт, с помощью которого они предоставляют заказчикам свои услуги. Здесь важнейшими факторами являются гарантированная доставка сообщений, многочисленность аппаратных платформ, а также открытость решения, позволяющая подключать к системе очередей сообщений собственные прикладные компоненты, а также корпоративные и отраслевые средства обеспечения безопасности.
Расширяемость системы. Важной характеристикой системы очередей сообщений является возможность расширять функциональность системы. Существование открытых интерфейсов для встраиваемых модулей (канальные и интерфейсные user exits) и документированных интерфейсов для базовых сервисных компонент позволяет подключать к менеджеру очередей дополнительные модули, готовые или написанные пользователем, и использовать их для взаимного опознания систем, кодирования сообщений, компрессии данных и других задач.
Распределенная передача сообщений
Пользовательские приложения не обязаны знать внутреннюю структуру системы очередей сообщений, где физически размещены очереди, какие коммуникации существуют между менеджерами очередей. Приложение, обращаясь к менеджеру очередей, всегда получает доступ только к локальным очередям сообщений. Когда приложение посылает сообщение в очередь, расположенную на удаленной системе, то сообщение записывается в специальную транспортную очередь (transmission queue), что обеспечивает надежное сохранение сообщения, а уже затем сообщение переправляется по каналу передачи сообщений другому менеджеру на удаленную систему.
На рис.1.4 показаны основные элементы, участвующие в передаче сообщения - от приложения к менеджеру очередей A и затем в удаленную очередь на менеджере очередей B.
Развитие IBM MQSeries - WebSphere MQ
История MQSeries как единого семейства программных продуктов начинается с 1992 года, когда IBM опубликовала спецификации для программного интерфейса Message Queue Interface (MQI). В том же 1992 году было заключено соглашение между IBM и фирмой System Strategies Inc.(SSI), которая тогда разрабатывала собственные продукты для передачи сообщений ezBRIDGE и Transact, которые были адаптированы для использования MQI.
Местом разработки MQSeries является лаборатория IBM, находящаяся в местечке Херсли (Hursley) на юго-западе Англии. Европейское происхождение технологии возможно определило техническую проработанность продукта с одной стороны, и некоторый недостаток активной рекламы для него на рынке с другой.
Первая версия MQSeries представляла собой сборный пакет из версий производства самой IBM для мейнфреймов, и продуктов System Strategies Inc.(SSI) для персональный компьютеров и UNIX платформ.
Настоящей версией MQSeries можно считать только вторую, имевшую кодовое имя Mayflower. В качестве наиболее полного и четкого документа, описывающего назначение и архитектуру классической системы очередей сообщений можно порекомендовать документ IBM MQSeries Message Queue Interface Technical Reference, который еще можно найти через Интернет на сайтах компании IBM. В этом документе определяются типы сообщений и их контрольная структура, основные объекты менеджера очередей – очереди и каналы, принципы адресация и доставки сообщений на удаленные системы, вызовы и параметры программного интерфейса MQI, механизм триггеринга, транзакционные свойства, административные интерфейсы.
С тех пор появилось много новых версий, существенно расширился круг платформ и функциональные возможности WebSphere MQ. Говоря о появлении новых версий, надо заметить, что менеджеры очередей MQSeries - WebSphere MQ даже разных версий взаимодействуют между собой и обеспечивают функционирование единой транспортной системы WebSphere MQ. При этом менеджер очередей устаревшей версии не сможет выполнить все новые функции обработки для сообщения, созданного на сервере последней версии, однако принять или переправить такое сообщение дальше, не потеряв его, менеджер старой версии безусловно может.
Менеджер очередей для целого ряда платформ поддерживается на уровне функциональности второй версии – MQSeries V2.2 для DEC OVMS VAX V2.2, DEC OVMS AXP V2.2, Tandem NSK V2.2, SINIX and DC/OSx V2.2, AT&T NCR, V2.2.
В 1997 появляется 5 версия MQSeries на новой кодовой базе Armada. В ней было ряд нововведений, в том числе:
поддержка координации транзакций между очередями сообщений и внешними реляционными базами данных, увеличение предельного размера сообщений с 4 MB до 100 MB, рассылка сообщений по списку.
В 1999 выходит следующая версия 5.1 [5], которая сопровождалась переделкой базового транспортного слоя, появлением многопоточных канальных агентов. Предельный размер очереди был увеличен до 2 GB. Для поддержки модели публикация-подписка IBM предложила специальный бесплатный брокер, который устанавливался поверх системы очередей сообщений. Существенным нововведением явился встроенный механизм интеллектуального администрирования и распределения нагрузки в системе из нескольких менеджеров сообщений – программные кластеры.
В 2000 году появилась версия системы очередей сообщений для мобильных устройств MQSeries Everyplace. Разработанная на языке Java и существенно облегченная по потребляемым ресурсам MQSeries Everyplace была предназначена для покрытия новой быстроразвивающейся области применения информационных технологий.
В 2000 году добавилось несколько новых программных интерфейсов. В MQSeries появилась поддержка JMS (Java Message Service), нового открытого стандартизированного интерфейса для передачи сообщений для программ на языке Java. Стандарт JMS разрабатывался фирмой Sun и был призван дать единый интерфейс для различных производителей систем очередей сообщений. В стандарте JMS сильно отразилось влияние MQSeries, особенно в модели взаимодействия приложений типа точка-точка. Кроме того, обобщая опыт интеграционных проектов, IBM предложило разработчикам новый программный интерфейс высокого уровня MQSeries AMI (Application Message Interface), призванный упростить разработку по сравнению со стандартным MQI. AMI позволяет использовать параметры низкого уровня MQI в сущностях сервисов и политик, удобные для разработки, настройки и администрирования.
Следующая версия 5.2 была выпущена в 2001 году. Версия имела новую кодовую базу Flotilla, была направлена на улучшения производительности, в этой версии появилась поддержка операционной системы Linux.
Главным видимым дополнением в версии 5.3 (проект Convoy) в 2002 году была встроенная поддержкой системы защиты каналов на базе технологии SSL. В этой версии появилась поддержка так называемых API exits – открытого интерфейса, позволяющего писать собственные модули дополнительной обработки, вызываемые при выполнении базовых программных вызовов. API exits являются очень мощным средством и, к счастью, избыточным для большинства стандартных задач. Кроме значительных для ряда задач в несколько раз улучшений производительности, эта версия система очередей сообщений расширила предельные ограничения на количество сообщений в одной очереди с 640 тысяч до миллиарда сообщений. В версии 5.3 произошло изменения привычного названия MQSeries на WebSphere MQ в целях маркетинга и рекламы семейства продуктов WebSphere как стратегической программной платформы для электронного бизнеса.
В настоящее время менеджеры очередей WebSphere MQ, работают на следующих основных платформах: zOs, OS/390, MVS, VSE/ESA, OS/400, OS/2, Tandem NSK, Digital OpenVMS VAX, Digital Unix, AIX, HP-UX, SunOS, Sun Solaris, Linux, SCO UNIX, UnixWare, AT&T GIS UNIX, DC/OSx, Windows XP/2000/NT, Windows 98/95. Существуют также WebSphere MQ клиенты для многочисленных платформ.
Средства безопасности в системе
Для обеспечения безопасности при использовании приложениями системы очередей сообщений необходимо знать, какое приложение послало то или иное сообщение, контролировать, кто получает данное сообщение, обеспечить идентификацию удаленных менеджеров, а также контролировать выполнение административных команд. Обычно сама по себе система очередей сообщений не является пакетом для обеспечения безопасности, и обычно ограничивается стандартными функциями защиты каналов при помощи SSL. Вместе с тем WebSphereMQ позволяет легко подсоединять внешние компоненты безопасности.
Транзакционные свойства: Как обеспечивается
Корпоративная система очередей сообщений должна обязательно включать в себя механизмы транзакций. Прикладная программа помечает часть своих получаемых и отправляемых сообщений специальной опцией - участвующие в транзакции. До выполнения приложением команды на завершение транзакции, посланные этим приложением сообщения являются фактически "невидимыми" для других приложений, а полученные приложением сообщения реально не удаляются из очередей. В случае выполнения приложением команды на откат транзакции, сообщения в очереди восстанавливаются к состоянию на начало транзакции.
WebSphereMQ обладает своим внутренним менеджером ресурсов, который кроме того поддерживает внешний XA интерфейс, и может участвовать в распределенной транзакции под управлением таких мониторов транзакций как CICS, Encina, Tuxedo. Сами по себе сервера WebSphereMQ, начиная с версии 5, могут быть координаторами распределенных транзакций с двухфазной фиксацией.
Триггерные возможности: Как активизировать программу обработки?
Асинхронный характер работы системы очередей сообщений требует специального механизма внешней активизации для старта прикладных и системных компонентов. В WebSphereMQ такой механизм - "триггеринг" привязан непосредственно к очередям сообщений. В качестве триггерных событий могут выступать, например, появление в очереди нового сообщения или энного сообщений с приоритетом выше определенного порогового значения.
Чтобы определить триггерное событие, для прикладной очереди при помощи административных команд устанавливаются опции, разрешающие триггеринг и условия триггерного события. Кроме того, администратором системы создается специальное описание обработки триггерного события. В этом описании содержится информация о приложении, которое будет вызвано при наступлении триггерного события. В случае возникновения такого события, например появления нового сообщения в очереди, менеджер очередей автоматически генерирует специальное триггерное сообщение, которое помещается в специальную очередь инициации (initiation queue). В триггерном сообщении содержатся данные о событии и вызываемом процессе. Все очереди инициации отслеживаются триггерным монитором, который читает триггерное сообщение и вызывает внешнюю программу обработки (рис.1.5).
Рис. 1.5. Обработка событий при помощи триггеринга
Триггеринг достаточно часто применяется в качестве стандартного метода автоматического старта каналов между менеджерами очередей. Для этого достаточно в качестве триггерных очередей объявить транспортные очереди, содержащие сообщения для передачи удаленному менеджеру очередей.
Запуск программы
Сообщение, посланное одной прикладной программой, может инициировать старт другого приложения. В таком случае по команде программы-монитора, приложение-адресат запускается и обрабатывает сообщение.
Менеджер очередей
Менеджер очередей – совокупность объектов WebSphere MQ (различных видов очередей, каналов, процессов, сервисов или служб). Он осуществляет контроль и управление всеми его объектами и обрабатывает поступающие запросы от прикладных программ.
Для создания любого объекта WebSphere MQ, и менеджера очередей в частности, существует два основных способа: на основе команд и графический, работающий в среде Windows. Создание объектов и работа с ними на основе команд является универсальным способом, работающим на различных платформах с одним и тем же синтаксисом этих команд. Поэтому создание менеджера очередей рассмотрим прежде всего с помощью команды crtmqm.
Итак, для платформы NT необходимо ввести в командной строке:
crtmqm /u DEAD_LETTER QM_Win2000
где:
/u или -u – опция, говорящая о том, что далее будет создана очередь недоставленных сообщений (подробнее см. лекцию 7);
DEAD_LETTER – имя очереди недоставленных сообщений;
QM_Win2000 – имя менеджера очередей.
Подробное описание утилиты runmqsc и работы с основными командами MQSC будет рассмотрено ниже. Имя менеджера очередей не является уникальным в пределах сети, но на одном компьютере не может быть двух менеджеров с одинаковым именем.
Для платформы UNIX синтаксис команды выглядит следующим образом:
crtmqm -u DEAD_LETTER QM_HP_UNIX
Данная команда, как и опция –u должна быть введена в нижнем регистре и именно со знаком "-" (-U работать не будет).
Также для успешного создания/изменения любого объекта необходимо обладать соответствующими правами. Так, например, WindowsNT пользователь, от имени которого вводится команда, должен быть членом группы mqm. Подробнее о вопросах авторизации см. в лекции 5.
Полный синтаксис команды crtmqm имеет вид:
crtmqm –c Text –d DefaultTransmissionQueue –h MaximumHandleLimit –lc(или -ll) –ld LogPath –lf LogFileSize –lp LogPrimaryFiles –ls LogSecondaryFiles –q –g ApplicationGroup –t IntervalValue –u DeadLetterQueue –x MaximumUncommittedMessages –z MQMName
Опции команды crtmqm означают следующее.
–c Text - Описание (description) или комментарий, можно ввести до 64 символов.
–d DefaultTransmissionQueue - Транспортная (transmission) очередь по умолчанию. В эту очередь будут попадать сообщения, для которых значение Transmission Queue явно не определено и это имеет свой смысл. При возникновении данной ситуации выгоднее получить сформировавшееся сообщение в DEAD_LETTER, так как имеется ряд способов извлечения или повторной отправки сообщений из DEAD_LETTER по назначению.
–h MaximumHandleLimit - Максимальное количество открытых объектов (командой MQOPEN). Значение может быть в пределах от 1 до 999 999 999, по умолчанию 256 (если не планируется работа одного приложения с более чем 256 объектами на одном менеджере, а авторы настоятельно не рекомендуют этого делать за исключением работы с distribution list, то следует оставить значение по умолчанию, т.е. 256);
–lc - Используется "круговое" логирование. При этом восстановление состояния менеджера очередей в определенный период невозможно, то есть если "упал" сервер, то сохраняются только те объекты и сообщения, которые существовали в момент "падения".
Данное значение (lc) используется по умолчанию.
–ll - Используется "линейное" логирование. При данном типе логирования возможно восстановление данных. Указав тип логирования при создании менеджера в дальнейшем нельзя его изменить.
–ld LogPath - Указывается путь, где будут создаваться файлы логирования. Для UNIX по умолчанию это var/mqm/log. Пользователь и группа mqm должны иметь соответствующие права в этом каталоге. Соответственно, при изменении пути необходимо также предоставить соответствующие права для вышеуказанных пользователей.
Для NT по умолчанию – C:\Program Files\IBM\WebSphere MQ\log
–lf LogFileSize - Размер файла логирования. Файл будет создан с размером в 4 раза большим указанного числа. Значение может быть в диапазоне между 32 и 4095 для NT, OS/2 Warp и между 64 и 16384 для UNIX. Значение по умолчанию для NT и OS/2 Warp равно 256 для UNIX – 1024.
–lp LogPrimaryFiles - Количество первичных файлов логирования. Может быть в пределах от 2 до 62. Значение по умолчанию – 3.
–ls LogSecondaryFiles - Количество вторичных файлов логирования. Может быть в пределах от 1 до 61. Значение по умолчанию – 2.
Следует соизмерять размеры файлов с возможностями операционных систем.
–q - Если указана опция –q, то созданный менеджер очередей будет создан как менеджер по умолчанию.
–g ApplicationGroup - Опция применима только для AIX, Sun-Solaris и HP-UX. Указывается имя группы, которой разрешается запускать MQI приложения, работать с файловой системой менеджера очередей.
–t IntervalValue - Определяет время интервала триггеринга очередей в миллисекундах. Значение может быть в пределах от 0 до 999 999 999 (более 11 дней). Подробнее о триггеринге см. в лекции 4.
–u DeadLetterQueue - Имя очереди недоставленных сообщений.
–x MaximumUncommittedMessages - Максимальное количество сообщений, которые могут находиться в очередях и транзакции по их отправке еще не завершились. Значение может быть в пределах от 0 до 999 999 999. По умолчанию – 10000.
–z - Запрещает появление сообщений об ошибках. Настоятельно не рекомендуется использовать данную опцию, т.к. при возникновении проблем не будет достаточной информации об ошибках
MQMName - Имя менеджера.
| Queue manager created | Менеджер очередей создан |
| Queue manager already exists | Менеджер очередей уже существует |
| Queue manager stopping | Менеджер очередей останавливается |
| Storage not available | Устройство записи недоступно |
| Queue space not available | Недоступно пространство для создания очереди |
| Unexpected error | Непредвиденная ошибка |
| Queue manager name error | Ошибочное имя менеджера очередей |
| Log location invalid | Неверное расположение лог-файла |
| Queue manager created. However, there was a problem processing the default queue manager definition in the product configuration file. The default queue manager specification may be incorrect | Менеджер очередей создан, однако имеется проблема с обработкой менеджера по умолчанию в конфигурационном файле. Описание менеджера по умолчанию может быть неверным. |
| Invalid log size | Неверный размер лог-файла. |
Возможные ошибки при создании менеджера очередей отражены в документации [7]. Этой книгой " WebSphere MQ. Messages" рекомендуется пользоваться всегда, как только будет получен код ошибки AMQxxxx.
Существует еще один важный параметр CCSID – кодовая страница менеджера. При создании менеджеров на разных серверных платформах и в разных операционных системах кодовые страницы могут отличаться. Для того чтобы исключить процедуру конвертации при передаче сообщений между менеджерами с разными кодовыми страницами рекомендуется на всех менеджерах установить одну и ту же кодовую страницу, например 1251. У WebSphere MQ существует множество таблиц перекодировки, с помощью которых осуществляется конвертация сообщений. Данные таблицы находятся в каталоге C:\Program Files\IBM\WebSphere MQ\conv\table. Если нет соответствующей таблицы перекодировки, то существует вероятность, что соединение между менеджерами очередей будет невозможно.
Просмотреть и изменить текущую кодовую страницу можно с помощью утилиты runmqsc.exe и соответствующих команд в ней, например, alter qmgr force ccsid(1251). Итак, используя простейший синтаксис :
crtmqm /u DEAD_LETTER QM_Win2000
можно создать менеджер QM_Win2000. Затем следует его активизировать (стартовать).
Для этого существует утилита strmqm:
strmqm –c –z MQMName
где:
-c - При указании этой опции менеджер стартует, пересоздает все системные объекты с параметрами по умолчанию и затем останавливается.
-z - Запрещает появление сообщений об ошибках. Использовать ее не рекомендуется.
MQMName - Имя менеджера.
Для простого старта менеджера по умолчанию достаточно набрать в командной строке:
strmqm
| Queue manager started | Менеджер очередей стартовал |
| Queue manager being created | Менеджер очередей создается |
| Queue manager running | Менеджер очередей уже работает |
| Queue manager does not exist | Менеджер очередей не существует |
| Log not available | Лог-файл не доступен |
| Queue manager stopping | Менеджер очередей останавливается |
| Storage not available | Устройство записи недоступно |
| Unexpected error | Непредвиденная ошибка |
| Queue manager name error | Ошибочное имя менеджера очередей |
| Log location invalid | Неверное расположение лог-файла |
Для остановки менеджера очередей существует утилита endmqm:
endmqm –c/-w/-i/-p –z MQMName
где:
-c - Менеджер остановится только после того, как все приложения, работающие с объектами WebSphere MQ "отсоединятся" от самих объектов, то есть ни один объект не будет "захвачен" приложениями. Причем менеджер будет ждать, пока не выполнятся все запросы (действия) приложений. При выполнении команды с этой опцией управление сразу же передается командной строке и не выдается никаких сообщений об остановке.
-w - Практически то же, что и с опцией –с, за исключением того, что пока менеджер останавливается, управление не передается командной строке, а выводится сообщение "Waiting for queue manager MQMName to end".
-i - Менеджер выполнит все текущие запросы приложений и остановится. Если в процессе остановки появятся новые запросы и необработанные транзакции, то при последующем старте менеджера произойдет откат незавершенных транзакций. Управление передается командной строке после остановки менеджера.
-p - Немедленная остановка. Менеджер остановится, не обрабатывая все текущие транзакции и запросы приложений. Остановка с данной опцией может привести к непредсказуемым результатам. Все процессы WebSphere MQ, которые не могут быть корректно остановлены в течение 30 секунд после начала работы endmqm будут отключены.
Перед остановкой менеджера необходимо остановить все приложения, работающие с WebSphere MQ, несмотря на то, что WebSphere MQ в процессе остановки менеджера будет пытаться их отключить.
| Queue manager ended | Менеджер очередей остановлен |
| Queue manager being created | Менеджер очередей создается |
| Queue manager does not exist | Менеджер очередей не существует |
| Queue manager not available | Менеджер очередей не доступен |
| Queue manager stopping | Менеджер очередей останавливается |
| Storage not available | Устройство записи недоступно |
| Unexpected error | Непредвиденная ошибка |
| Queue manager name error | Ошибочное имя менеджера очередей |
И последняя команда – удаление менеджера:
dltmqm –z MQMName
где:
-z - Запрещает появление сообщений об ошибках. Использовать ее не рекомендуется.
MQMName - Имя менеджера.
При выполнении этой команды удаляется не только менеджер, но и все его объекты. Перед удалением менеджера следует его остановить с помощью команды endmqm. Важно, чтобы в момент удаления менеджера, каталог с содержимым менеджера (для WindowsNT это - C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM_Win2000) не был никем "захвачен", иначе удалить менеджер невозможно.
| Queue manager deleted | Менеджер очередей удален |
| Queue manager being created | Менеджер очередей создается |
| Queue manager running | Менеджер очередей уже работает |
| Queue manager does not exist | Менеджер очередей не существует |
| Queue manager stopping | Менеджер очередей останавливается |
| Storage not available | Устройство записи недоступно |
| Unexpected error | Непредвиденная ошибка |
| Queue manager name error | Ошибочное имя менеджера очередей |
| Log location invalid | Неверное расположение лог-файла |
| Queue manager deleted. However, there was a problem processing the default queue manager definition in the product configuration file. The default queue manager specification may be incorrect. | Менеджер очередей удален, однако в конфигурационном файле осталось его имя, как имя менеджера по умолчанию. Описание менеджера по умолчанию может быть неверным. |
Процесс создания менеджера:
Запустить WebSphere MQ Explorer.Щелкнуть правой кнопкой мыши по "Queue Managers".Выбрать из контекстного меню пункт "New" => "Queue Manager".Заполнить появившуюся форму (рис.2.7) Create Queue Manager (Step 1).
увеличить изображение
Рис. 2.7. Создание менеджера очередей (Шаг 1)
В этой форме:
Queue Manager – имя менеджера;
Make this the default queue manager – флажок, определяющий будет ли этот менеджер менеджером по умолчанию;
Def. Transmission Queue – имя трансмиссионной очереди по умолчанию рекомендуется оставить пустым во избежание ошибок передачи данных;
Dead Letter Queue – очередь недоставленных сообщений;
Max Handle Limit – количество открытых объектов WebSphere MQ одним приложением (одна программа не сможет работать одновременно более чем с 256 очередями);
Trigger Interval – значение интервала времени, через который опрашивается состояние очереди триггерными процессами;
Max Uncommitted Msgs – максимальное количество сообщений, которые могут находится в очередях и транзакции по их отправке еще не завершились;
Нажать кнопку "Next" и заполнить форму (рис.2.8) Create Queue Manager (Step2)
увеличить изображение
Рис. 2.8. Создание менеджера очередей (Шаг 2)
В этой форме:
Use circular/linear logging - с помощью данного флажка можно выбрать тип логирования на вновь создаваемом менеджере;
Log Path – указывает путь, где будут созданы лог-файлы;
Log File Size - размер файла логирования, размер созданного файла будет в 4 раза превышать указанное число;
Log Primary Files – количество первичных файлов логирования;
Log Secondary Files – число вторичных файлов логирования.
Нажать кнопку "Next" и заполнить форму (рис.2.9) Create Queue Manager (Step3)
увеличить изображение
Рис. 2.9. Создание менеджера очередей (Шаг 3)
В этой форме:
Start Queue Manager – при установленном флажке менеджер очередей будет активизирован непосредственно сразу после создания;
Create Server Connection Channel – установка данного флажка позволит создать канал (SYSTEM.ADMIN.SVRCONN) для удаленного управления объектами менеджера через протокол TCP/IP.
Нажать кнопку "Next" и заполнить форму (рис.2.10) Create Queue Manager (Step4)
увеличить изображение
Рис. 2.10. Создание менеджера очередей (Шаг 4)
В этой форме:
Create listener configured for TCP/IP – создает listener для удаленного подключения к менеджеру;
Listen on port number – номер порта для работы listener (по умолчанию - 1414).
После нажатия на кнопку "Finish" менеджер с именем QM_Win2000 будет создан и произведен его старт. На оснастке консоли WebSphere MQ Explorer с левой стороны должно появиться имя менеджера, как это показано на рис. 2.6.
Для удаления менеджера очередей через WebSphere MQ Explorer нужно вызвать контекстное меню из имени менеджера и выполнить команду "Stop". Следует напомнить, что перед этим нужно остановить все receiver- каналы, а также все программы, помещающие или считывающие сообщения из очередей. Способ остановки можно выбрать "Immediate" (незамедлительно). После того как менеджер будет остановлен, опять же с помощью контекстного меню выполнить команду "Delete". После этого менеджер очередей будет удален вместе со всеми своими объектами, и его восстановление будет невозможно.
В заключении можно добавить, что все эти процессы не представляют особой сложности. Процесс установки WebSphere MQ на NT-платформу занимает около получаса и решающим обстоятельством является мощность или скорость дисковых ресурсов. На процесс создания менеджера после ввода всех параметров уйдет не более минуты. Время остановки менеджера зависит от количества объектов. Для примера можно сказать, что на компьютере Pentium III с тактовой частотой 700 MHz и оперативной памятью 512Mb, менеджер, содержащий 1000 очередей, останавливается меньше чем за 30 секунд.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Основные утилиты
Рассмотрим подробнее работу основных утилит WebSphere MQ.
First Steps. Главное меню утилиты First Steps представлено на рис. 2.5.
Default Configuration. Пункт меню посвящен настройкам по умолчанию. Рассматривать его не будем, так как в дальнейшем дадим подробное описание объектов WebSphere MQ и скажем о параметрах по умолчанию для каждого объекта, а также будет рассмотрен вопрос о том, как задать один раз значение по умолчанию, чтобы все объекты в дальнейшем создавались именно с этим параметром.
увеличить изображение
Рис. 2.5. Главное меню утилиты First Steps
Quick Tour. Справочная информация о WebSphere MQ, введение, инсталляция/деинсталляция, совместимость, основные утилиты, работа с компонентами WebSphere MQ: менеджеры очередей, кластеры, очереди, каналы и пр.
Postcard. Утилита, позволяющая передавать сообщения между компьютерами, на которых установлено WebSphere MQ. Нужно сразу оговориться, что применима она только для менеджеров очередей, объединенных в кластер, и существует не для промышленной эксплуатации, а скорее для проверки установки соединения. Для передачи сообщения нужно ввести своё имя, далее имя адресата и имя менеджера очередей, куда необходимо передать сообщение. Адресат может прочитать сообщение, также запустив Postcard на своем компьютере. После выхода из Postcard сообщения не сохраняются.
WebSphere MQ Explorer. Основной продукт, позволяющий создавать и модифицировать объекты WebSphere MQ. Внешний вид представлен на рис. 2.6 и являет собой оснастку (snap-in) консоли управления Microsoft.
В левой части можно видеть список менеджеров очередей, доступных для управления и их объекты. В зависимости от позиционирования курсора в левой части на различных объектах, в правой части оснастки будут отображаться списки объектов и их свойства. Кроме этого, в верхней части имеются панели управления и панели инструментов такие как: "Стандартные меню (Действие и Вид)", стандартная панель инструментов и панель инструментов WebSphere MQ. Работа со "Стандартным меню (Действие и Вид) описана во многих справочных руководствах по работе с Microsoft Windows и не представляет особого интереса. Кратко можно сказать, что используя эти меню можно добавлять или удалять различные оснастки для консоли управления и изменять ее вид. В стандартной панели инструментов имеются две кнопки представляющие интерес в части работы с объектами WebSphere MQ. Это кнопка обновления информации и кнопка экспорта списка. Информация, отображающаяся как в левой, так и в правой части WebSphere MQ Explorer статична, т.е. отображает состояние объектов в конкретный момент времени. Для получения текущего состояния объекта необходимо нажать кнопку обновления информации (Refresh). Информация будет обновляться об объекте, на котором позиционирован курсор, то есть если он установлен в левой части на "Queues", то в правой части произойдет обновление информации о состоянии всех очередей, а если курсор будет установлен на одну очередь в правой части WebSphere MQ Explorer, то информация обновится только об этой очереди. С помощью кнопки экспорта списка можно вывести всю информацию об объектах в текстовый файл. Этим удобно пользоваться для анализа состояния объектов менеджера очередей WebSphere MQ, например, легко выяснить, какие каналы используют одну и ту же трансмиссионную очередь и устранить эту "опасную настройку". Используя кнопки панели инструментов WebSphere MQ Explorer можно скрывать или отображать различные типы объектов менеджеров очередей. Например, информация о состоянии временных очередей и системных объектах не так важна и актуальна, и ее можно убрать с экрана или добавить с помощью кнопок
и
, соответственно.
В WebSphere MQ Explorer имеется возможность сортировки списка отображаемых объектов в алфавитном порядке. Для сортировки очередей по названию необходимо нажать на поле "Name". Для сортировки по типу - на поле "Queue Type", по количеству сообщений – на "Current Depth" и так далее. Повторное нажатие на данные поля приведет к рекурсивному (обратному) отображению, то есть, если повторно нажать на поле "Name", то список очередей будет построен в порядке обратном алфавитному.
С помощью WebSphere MQ Explorer можно создавать, модифицировать, удалять и управлять объектами менеджеров очередей. Вызвав контекстное меню для каждой группы или для одного объекта с помощью правой кнопки мыши, мы получим набор команд, характерных для каждого конкретного объекта. Для очередей это могут быть команды создания, изменения свойств, добавление очереди в кластер, помещения тестовых сообщений, просмотр статуса очереди или первых двухсот сообщений очереди, удаления всех сообщений из очереди и удаления самой очереди. Для каналов соответственно команды создания, удаления, модификации и остановки, инициализации и старта. Для процессов – создания, модификации и удаления. Команд на старт или остановку процессов не существует, так как процессы стартуют по определенным правилам, о которых будет сказано ниже.
Для подключения к удаленному менеджеру очередей необходимо вызвать контекстное меню из группы "Queue Managers" и выполнить пункт "Show Queue Manager...". В появившейся форме выставить флажок "Show a remote queue manager" и заполнить поля "Queue Manager Name" (имя удаленного менеджера) и "Connection Name" - IP адрес или имя компьютера с указанием в скобках номера порта для службы Listener (по умолчанию 1414). Подключение к менеджеру возможно в том случае, если пользователь обладает соответствующими правами на удаленном компьютере.
увеличить изображение
Рис. 2.6. WebSphere MQ Explorer
Подробные действия для создания и управления объектами WebSphere MQ как с помощью WebSphere MQ Explorer, так и с помощью команд MQSC (MQSeries commands) будет рассмотрено ниже.
API Exerciser. Утилита, позволяющая пошагово выполнять действия, связанные с обработкой сообщений в существующих очередях. Выполняя каждый шаг (подключение к менеджеру, открытие очереди, помещение или считывание сообщения из очереди, закрытие очереди и отключение от менеджера) вы имеете возможность видеть результаты работы той или иной команды в окне статуса, что позволяет избежать ошибок. Кроме этого имеется расширенный режим работы для формирования сообщений сложных форматов.
Help Center. Данный пункт меню вызывает справочную систему WebSphere MQ, в которой имеется глоссарий и возможность поиска информации по ключевым словам.
Установка WebSphere MQ на платформе Windows NT
Рассмотрим порядок установки WebSphere MQ на платформе WindowsNT. Процесс установки построен таким образом, что инсталляцию может выполнить пользователь, никогда ранее не работавший с данным продуктом. WebSphere MQ не является требовательным программным обеспечением (ПО) по отношению к аппаратной части компьютера. Несмотря на это, вряд ли стоит планировать серьезную работу на низко производительных системах. К примеру, для платформы Windows NT вполне достаточно компьютера на базе процессора Pentium IV c тактовой частотой не менее 1000 MHz и ОЗУ 512 Мб. Минимальные и рекомендуемые параметры приведены в Таблице 2.1.
| Процессор | Pentium 166 | Pentium IV 1700 MHz |
| Оперативная память | 60 Мб | 1024 Мб |
| Дисковая память | 90 Мб для установки ПО WebSphere MQ | Зависят от количества объектов WebSphere MQ и количества сообщений в очередях. Рекомендуется иметь свободного пространства на диске не менее 2 Гбайт. |
Приведенные цифры касаются требований самого WebSphere MQ и не учитывают потребностей операционной системы. Количество используемой оперативной памяти будет возрастать незначительно с появлением таких новых объектов как очереди, каналы, процессы, но на каждый Trigger Monitor потребуется дополнительно по 3Мбт.
На компьютере для инсталляции WebSphere MQ необходимо установить следующие программные продукты или их более поздние версии:
Microsoft Internet Explorer 4.01+SP1;Microsoft HTML Help 1.3;Microsoft MMC 1.1;Microsoft Active Directory Client Extensions;Microsoft Installer MSI 2.0;128-bit Strength Encryption;Supported JAVA Runtime Environment 1.3.
Для начала инсталляции необходимо, в зависимости от комплекта поставки, запустить файл запуска программы установки и следовать инструкциям, появляющимся на экране. После сообщений о подготовке и начале установки должно появиться меню (рис.2.1), в котором нужно последовательно выполнить пункты:
Software Prerequisites – проверка установки необходимого ПО на компьютере; Network Prerequisites – варианты работы с использованием домена или без (рекомендуется не использовать работу в домене, т.е. на вопрос об использовании специального домена ответить "No"); WebSphere MQ Installation – собственно, начало инсталляции – необходимо нажать кнопку "Launch WebSphere MQ Installer".
увеличить изображение
Рис. 2.1. Меню установки WebSphere MQ
После очередного приглашения к началу инсталляции и принятия соглашения о Лицензиях появится меню с выбором вариантов установки Typical, Compact или Custom. Выбираем Typical – наиболее простой и надежный способ установки. При этом установка будет произведена на C:\Program Files\IBM\WebSphere MQ. Возможность изменения каталога и диска установки реализована в способе Custom.
После появления информации о готовности к началу установки появится вопрос о наличии лицензии, на который необходимо ответить "Yes". После этого начнется процесс копирования файлов с инсталляционного диска на ваш компьютер, который закончится сообщением об успешной установке (рис. 2.2).
увеличить изображение
Рис. 2.2. Окончание процесса установки WebSphere MQ
После нажатия на кнопку "Finish" будет предложено сконфигурировать WebSphere MQ для работы в вашей сети или перенести существующие менеджеры очередей, оставшиеся от предыдущей версии. На вопрос об использовании домена следует ответить "No". Экранную форму с предложением об установке параметров по умолчанию рекомендуется пропустить, так как и без этого программа установки успешно завершит работу, а на создании и конфигурации объектов WebSphere MQ мы остановимся подробнее в последующих разделах. После появления последней экранной формы (рис. 2.3) и нажатия кнопки "Готово" процесс установки завершается.
увеличить изображение
Рис. 2.3. Окончание процесса установки и конфигурации WebSphere MQ
В результате установки мы получаем несколько инструментов для работы с WebSphere MQ (рис. 2.4):
First Steps – позволяет запускать различные приложения WebSphere MQ, такие как конфигурация менеджера очередей по умолчанию (Default Configuration); обзор возможностей (Quick Tour); обмен Postcard сообщениями; запуск WebSphere MQ Explorer; запуск утилиты API-Exerciser, позволяющей детально рассмотреть этапы подключения к менеджеру очередей и создания различных вариантов сообщений и запуска программы-справочника (Help Center);Help Center – справка WebSphere MQ;Prepare WebSphere MQ Wizard – утилита, позволяющая произвести инсталляцию/деинсталляцию WebSphere MQ;WebSphere MQ Explorer – утилита создания и управления объектами WebSphere MQ как на локальных, так и на удаленных менеджерах очередей; WebSphere MQ Services - утилита создания и управления сервисами WebSphere MQ.
увеличить изображение
Рис. 2.4. Основные инструменты работы с WebSphere MQ
Прежде чем перейти к описанию работы с вышеуказанными утилитами рассмотрим процесс деинсталляции WebSphere MQ. Можно отметить, что в ходе многолетней эксплуатации авторам не приходилось производить переустановку WebSphere MQ в системах промышленной эксплуатации, что говорит о высокой надежности работы. Тем не менее предлагается следующий алгоритм переустановки WebSphere MQ:
Остановить все программы, помещающие сообщения в очереди;Остановить все Receiver и Requester каналы, чтобы остановить потоки входящих сообщений;Убедиться в отсутствии в очередях сообщений, подлежащих обработке;Перевести тип запуска сервиса IBM MQSeries (предыдущая версия данного ПО называлась именно так, и не смотря на то, что устанавливается WebSphere MQ, сервис называется именно IBM MQSeries) из автоматического (Auto) в ручной (Manual);Перезагрузить компьютер;Произвести удаление программы IBM WebSphere MQ из Панели управления\Установка и удаление программ;Удалить папку C:\Program Files\IBM\WebSphere MQ.Удалить из переменных окружения ссылки на WebSphere MQ.Удалить группу mqm.
Каналы
Каналы WebSphere MQ - это объекты менеджеров очередей, позволяющие создавать коммуникации или линии связи между менеджерами очередей, по которым передаются сообщения. Каналы между серверами, содержащими менеджеры очередей всегда однонаправленные. Каналы, использующиеся при соединении типа клиент-сервер - двунаправленные. При создании линии связи между двумя менеджерами необходимо создать каналы с одинаковыми именами на каждом менеджере. Назовем каналы типа sender и server каналами-отправителями, а каналы типа receiver и requester - каналами-получателями. Соответствие пар каналов представлено в таблице 3.2.
| Sender | ==> | Receiver |
| Server | ==> | Receiver |
| Server | ==> | Requester |
| Requester | <== | Server |
| Requester | <== | Sender |
Для того, чтобы создать канал WebSphere MQ с помощью WebSphere MQ Explorer нужно вызвать контекстное меню, правой кнопкой мыши нажав на группу Channels, выполнить пункт "Создать" и выбрать соответствующий тип канала (рис. 3.6).
увеличить изображение
Рис. 3.6. Создание канала с помощью WebSphere MQ Explorer
Далее в зависимости от выбранного типа канала появится форма для заполнения свойств канала. Для sender и server каналов ее вид представлен на рис. 3.7, для receiver - на рис. 3.8, для requester - на рис. 3.9. Форма для sender-канала практически не отличается от формы для server - канала. Создание кластерных каналов подробно изложено в лекции 6.
Различные типы каналов отображаются в WebSphere MQ Explorer с помощью пиктограмм, которые приведены ниже:
 | - receiver | |
 | - requester | |
 | - sender; | |
 | - server; | |
 | - cluster receiver; | |
 | - cluster sender; | |
 | - server connection. |
Очереди
Очереди - это объекты менеджера очередей WebSphere MQ, исполняющие роль контейнера сообщений. Они служат для хранения ( в том числе информации об объектах WebSphere MQ) и передачи сообщений; активации (запуска) процесса (приложения). В зависимости от назначения очереди бывают следующих типов.
Локальные очереди. В них непосредственно находятся сообщения. Такие очереди могут быть простыми локальными, трансмиссионными, динамическими и системными.
Простая локальная очередь (local queue) создается и существует как самостоятельный объект, независящий от других объектов. В нее приложения могут помещать или забирать сообщения. Кроме того, локальная очередь может использоваться как очередь инициализации для запуска того или иного процесса.
Трансмиссионная или очередь передачи (transmission queue) создается как самостоятельный объект, но она используется с парой других объектов (Remote queue и sender/server каналом) для дальнейшей доставки сообщений в другую очередь, расположенную на другом менеджере очередей.
Динамическая очередь (dynamic queue) создается в процессе работы модельной очереди (model queue). На основе параметров модельной очереди формируется динамическая, WebSphere MQ работает с ней, а по окончании работы (помещения или извлечения сообщения) может ее удалить или оставить, а при следующем обращении к модельной очереди создать новую динамическую очередь.
Системные очереди (system queue) служат для управления командами и для хранения информации о шаблонах вновь создаваемых очередей. Их названия, как правило, начинаются с SYSTEM. Например, очередь SYSTEM.DEFAULT.LOCAL.QUEUE служит шаблоном для создания простой локальной и трансмиссионной очередей. Достаточно один раз изменить какой-нибудь параметр в этой очереди, и все остальные (локальные и трансмиссионные) будут в дальнейшем создаваться с этим параметром. Иными словами в этой очереди хранятся параметры, задаваемые по умолчанию при создании локальных и трансмиссионных очередей.
Локальная удаленная (Remote queue) очередь существует для определения параметров передачи и формирования сообщений. Несмотря на то, что сообщения не попадают в эту очередь, в программе или в приложениях, отправляющих сообщения, следует указывать именно ее. Система WebSphere MQ берет параметры из Remote queue, формирует заголовок сообщения, и помещает сообщение в соответствующую трансмиссионную очередь для дальнейшей отправки по месту назначения.
Используя псевдоочередь (alias), можно "перенаправить" помещение сообщений в ту или иную очередь.
Создать объекты менеджера очередей WebSphere MQ можно двумя способами: с помощью команд MQSC (MQSeries Commands) и с помощью WebSphere MQ Explorer. Для того чтобы создать очередь WebSphere MQ посредством WebSphere MQ Explorer нужно вызвать контекстное меню, правой кнопкой мыши нажав на группу Queues, выполнить пункт "Создать" и выбрать соответствующий тип очереди (рис.3.1)
увеличить изображение
Рис. 3.1. Создание очереди с помощью WebSphere MQ Explorer
Далее в зависимости от типа выбранной очереди появится форма для заполнения свойств очереди. Для локальной очереди ее вид представлен на рис. 3.2, для alias - на рис. 3.4, для remote - на рис. 3.5. Форма для модельной очереди практически не отличается от формы для локальной.
Различные типы очередей отображаются в WebSphere MQ Explorer с помощью пиктограмм, которые приведены ниже:
 | - локальная очередь; |
 | - локальная очередь, физически расположенная на локальном менеджере очередей и включенная в кластер; |
 | - кластерная очередь, физически расположенная на удаленном менеджере очередей и включенная в кластер; |
 | - локальная трансмиссионная очередь; |
 | - модельная очередь; |
 | - локальная удаленная очередь, физически расположенная на локальном менеджере очередей; |
 | - локальная удаленная очередь, физически расположенная на локальном менеджере очередей и включенная в кластер; |
 | - удаленная очередь, физически расположенная на удаленном менеджере очередей, включенная в кластер; |
 | - псевдоочередь; |
 | - псевдоочередь, физически расположенная на локальном менеджере очередей и включенная в кластер; |
 | - псевдоочередь, физически расположенная на удаленном менеджере очередей и включенная в кластер; |
Основные свойства каналов
Форма для создания sender и server каналов (рис. 3.7) имеет шесть закладок: General, Extended, MCA, Exits, LU 6.2, Retry и SSL.
Рис. 3.7. Форма для заполнения свойств sender - канала
Свойства локальных очередей
Форма для создания локальной очереди (рис.3.2) имеет 6 закладок: General, Extended, Cluster, Triggering, Events и Storage. В каждую закладку вводятся те или иные атрибуты или свойства очереди. Ниже при описании атрибутов будет даваться краткая информация, для каких типов очередей имеет значение тот или иной атрибут, указываться в скобках через запятую первые символы типов очередей (L - локальная, M - модельная, A - alias, Remote - удаленная, C - кластерная).
Рис. 3.2. Форма для заполнения свойств локальной очереди
После создания очереди появляется еще одна закладка Statistics, в которой содержится информация о дате, времени создания и последнего изменения свойств очереди, количестве сообщений в очереди и количестве приложений, открывших очередь для чтения и записи.
Закладка Cluster
Not shared in cluster - говорит о том, что очередь недоступна для кластера WebSphere MQ.
Shared in cluster - доступна для кластера WebSphere MQ. (L, A, R)
Shared in a list of clusters - доступна для списка кластеров WebSphere MQ. (L, A, R)
Default Bind - используется для открытия кластерной очереди.
Закладка Cluster одинакова для всех объектов, которые могут быть включены в кластер WebSphere MQ.
Закладка Events
Maximum Depth Event - разрешает (Enable) или запрещает (Disable) генерацию event-сообщения при достижении в очереди максимального количества сообщений. (L, M)
High Depth Event - разрешает (Enable) или запрещает (Disable) генерацию event-сообщения при достижении в очереди количества сообщений, указанных в атрибуте High Depth Limit. Может изменяться автоматически с Enable на Disable при превышении сообщениями в очереди значения High Depth Limit. (L, M)
High Depth Limit - количество сообщений в очереди, при котором генерируется event-сообщение. Активно только при опции Enable в атрибуте High Depth Event. Значение по умолчанию - 80. (L, M)
Low Depth Event - разрешает (Enable) или запрещает (Disable) генерацию event-сообщения при достижении в очереди количества сообщений, указанных в атрибуте Low Depth Limit. (L, M)
Low Depth Limit - количество сообщений в очереди, при котором генерируется event-сообщение. Активно только при опции Enable в атрибуте Low Depth Event. Значение по умолчанию - 20. (L, M)
Service Interval Event - тип event-сообщения. Имеет три значения High, None или Ok. High - event-сообщение генерируется в том случае, если в течение периода времени, указанного в Service Interval, не было попыток прочитать сообщения из очереди. Ok - event-сообщение генерируется, если в течение времени Service Interval была попытка прочитать сообщения в очереди. None - event-сообщения (High или Ok) не генерируются. (L, M)
Service Interval - промежуток времени в миллисекундах, в течение которого отслеживается попытка прочитать сообщения из очереди. Отсчитывается от времени помещения последнего сообщения. Значение по умолчанию - 999999999. (L, M)
Для разрешения генерации event-сообщений необходимо открыть с помощью контекстного меню свойства менеджера очередей и в закладке Events выставить значения Enable для соответствующих типов событий (рис.3.3). Генерируется еvent-сообщение в системной очереди SYSTEM.ADMIN.PERFM.EVENT. Подробнее о формате данного сообщения можно узнать из документации по WebSphere MQ [8].
Закладка Exits
Указываются channel-exit программы канального агента (MCA), написанные на языке C [8]. Под Windows обращение записывается как dllname(functionname)
где dllname определяет имя Dynamic Link Library без суффикса ".dll". Максимальная длина строки - 40 символов.
Send Exit Name - имя программы, которая выполняется, когда сообщение было забрано из трансмиссионной очереди, но процесс передачи еще не начинался;
Send Exit Data - данные, которые можно передать программе, указанной в атрибуте Send Exit Name;
Receive Exit Name - имя программы, которая выполняется, когда сообщение получено, но еще не помещено в очередь назначения;
Receive Exit Data - данные, которые можно передать программе, указанной в атрибуте Receive Exit Name;
Security Exit Name - имя программы, которая выполняется, когда в процессе установки соединения между парой каналов производится процесс идентификации. Примеры использования механизма Security Exit доступны по адресу http://www.redbooks.ibm.com/redbooks/SG245306.html, а также в программе cryptexit с http://www.mqseries.net
Security Exit Data - данные, которые можно передать программе, указанной в атрибуте Security Exit Name;
Message Exit Name - имя программы, которая выполняется, когда сообщение будет помещено в очередь. Используя данный атрибут можно указать, например, имя программы для помещения содержимого сообщения в файл. Пример данной программы приведен в лекции 11. Не поддерживается для канала server-connection.
Message Exit Data - данные, которые можно передать программе, указанной в атрибуте Message Exit Name.
Механизмы Send exit и Receive exit можно использовать как для сжатия, так и для шифрования сообщений. Сообщения, поступающие в трансмиссионную очередь перед отправкой будут сжиматься или шифроваться с помощью программы, указанной в атрибуте Send Exit Name, а после доставки на удаленный менеджер перед помещением в очередь будут приведены в исходное состояние с помощью программы, указанной в атрибуте Receive Exit Name. Следует отметить, что события Send Exit и Receive Exit возникают также при инициализации старта и остановки каналов, а также при передаче служебных контрольных сообщений.
Закладка Extended
Maximum Queue Depth - указывает на максимально допустимое количество сообщений, которые могут находиться в очереди. При превышении данного параметра сообщения, доставленные от других менеджеров, будут помещаться в очередь недоставленных сообщений DEAD_LETTER. Если же будет переполнена очередь DEAD_LETTER, то сообщения будут накапливаться в трансмиссионной очереди удаленного менеджера. В случае программного помещения сообщений, при переполнении очереди, программе, помещающей сообщения, будет выдано сообщение об ошибке. Максимальное количество сообщений в очереди на платформах AIX, HPUX, z/OS, Solaris и Windows не может превышать 999 999 999. На других платформах данный параметр не может превышать 640 000. (L, M)
Maximum Message Length - указывает максимальную длину сообщения. По умолчанию - 4194304 байт. Максимальный размер сообщения может быть 100 Мб. (L, M)
Shareability - разрешает или запрещает нескольким приложениям одновременно открывать очередь. (L, M)
Default Input Open Option - определяет в каком режиме по умолчанию (общего пользования или эксклюзивном) приложения будут открывать очередь. (L, M)
Message Delivery Sequence - определяет порядок сортировки сообщений в очереди при вызове команды MQGET. Имеет два значения FIFO и Priority. Значение FIFO говорит о том, что сообщения в очереди будут обрабатываться по принципу "первым пришел - первым ушел". Значение Priority позволяет обрабатывать сообщения по их приоритетам. (L, M)
Retention Interval - время "актуальности" очереди. Сугубо информативный постоянный атрибут, служащий для удобства администрирования. Измеряется в часах. Менеджер очередей не предпринимает никаких действий для удаления очереди, когда разность между временем создания очереди и данным значением истечет. Полезно использовать для написания программ, отслеживающих актуальность очередей, если они были созданы только на определенный период. (L, M)
Definition Type - тип создания и работы динамических очередей. Используется только для модельной очереди. Имеет значения Temporary - созданные динамические очереди удаляются вместе с сообщениями после закрытия модельной очереди, и Permanent - динамические очереди не удаляются. (L, M)
Distribution List - используется трансмиссионными очередями в процессе рассылки. Имеет два значения Enabled и Disabled. В первом случае сообщение из трансмиссионной очереди передается согласно списку рассылки. Во втором - только на один менеджер очередей. (L, M)
Batch Interval - значение интервала времени в миллисекундах, в течение которого канал ждет появления сообщений в трансмиссионной очереди прежде чем начать передачу пакета данных. Может находиться в пределах от 0 до 999 999 999. Значение по умолчанию - 0. Если оставить это значение пустым, то тогда станет актуальным атрибут Batch Size или когда трансмиссионная очередь становится пустой.
Disconnect Interval - значение интервала тайм-аут. Измеряется в секундах от времени передачи последнего сообщения. По истечении этого интервала каналы отправители переходят в нейтральное состояние, если отсутствуют сообщения в трансмиссионной очереди и значение Batch Size превышено или значение Batch Interval истекло. Значение по умолчанию - 6000.
Data Conversion - задает возможность конвертации сообщений. Имеет два значения Yes и No. Если удаленный менеджер поддерживает механизм конвертации, то сообщение будет перекодировано в кодовую страницу удаленного менеджера. Если же удаленный менеджер не поддерживает конвертацию, то данный атрибут показывает, что сообщение должно быть перекодировано в кодовую страницу удаленного менеджера перед передачей. Конвертация происходит на основе таблиц кодировки, которые располагаются в C:\Program Files\IBM\WebSphere MQ\conv\table. Если в данной папке нет соответствующей таблицы кодировки, то не удастся установить соединение между менеджерами очередей, не говоря уже о конвертации.
Закладка General
Queue Name - имя очереди. Может содержать до 48 знаков. Русские буквы не поддерживаются, как и в любых параметрах всех без исключения объектов WebSphere MQ. Изменить имя очереди нельзя.(L, M, A, R, C)
Type - тип очереди. Выставляется автоматически (Local).
Description - описание. Может содержать до 64 знаков. (L, M, A, R, C)
Put Messages - разрешение/запрещение помещения сообщений в очередь. Имеет два значения Allowed - разрешено и Inhibited - запрещено. (L, M, A, R, C)
Get Messages - разрешение/запрещение считывания сообщений из очереди. Имеет два значения Allowed - разрешено и Inhibited - запрещено. (L, M, A)
Default Priority - приоритет сообщений, помещенных в очередь. Наивысший приоритет - 0, наименьший 9. Приоритет указывает на то, в каком порядке будут обработаны или переданы сообщения, находящиеся в очереди. Первыми будут обработаны сообщения, имеющие наивысший приоритет. Значение по умолчанию - 0. Если приоритет задается программой, помещающей сообщения в очередь, то он сохраняется. (L, M, A, R, C)
Default Persistence - способ хранения сообщения. Имеет два значения Persistent и Not Persistent. Значение Persistent указывает на то, что сообщения, помещаемые в очередь, будут записаны на диск. В случае остановки менеджера очередей или его сбоя они остаются на жестком диске и после старта менеджера или устранения сбоя остаются в очереди. Значение Not Persistent указывает на то, что сообщения будут храниться в оперативной памяти. Соответственно после остановки, сбоя менеджера или компьютера восстановлению не подлежат. В первом случае можно выиграть в надежности, но проиграть в скорости обработки, во втором - наоборот.
Scope - контекст, поддерживается только для OS/400. (L, A, R)
Usage - тип локальной очереди. Имеет два значения Normal и Transmission. Первое говорит о том, что очередь будет выступать в роли простой локальной, то есть сообщения, помещенные в нее приложениями или доставленные от других менеджеров очередей, не будут никуда переданы. Их можно будет считать только программным способом. Значение Transmission указывает на то, что очередь будет трансмиссионной, и служит для передачи сообщений на другой менеджер очередей с помощью соответствующей локальной удаленной (remote) очереди и sender-канала. (L, M)
Channel Name - имя канала. Может содержать до 20 знаков. Изменить имя канала нельзя.
Type - тип очереди. Выставляется автоматически (Sender).
Description - описание. Может содержать до 64 символов.
Transmission Protocol - тип транспортного протокола. Имеет значения LU62, TCP, UDP, NETBIOS, SPX. Значение по умолчанию - TCP.
Connection Name - имя компьютера (с указанием в скобках номера порта для службы listener), с которым надо установить соединение для передачи сообщений. Может содержать 48 символов для z/OS, для других платформ - 264. Следует сказать, что можно указывать либо номер TCP, либо имя компьютера в домене. Для поддержки доменных имен необходимо установить Microsoft Active Directory Client Extensions.
Transmission Queue - имя трансмиссионной очереди, участвующей в процессе передачи сообщений.
Local Communication Address - локальный коммуникационный адрес канала. Используется в том случае, когда требуется указать особенный адрес с диапазоном (или без него) портов, к которому будет привязан канал. Применяется только для TCP протокола.
Queue Name - имя очереди. Может содержать до 48 знаков. Русские буквы не поддерживаются, как и в любых параметрах всех без исключения объектов WebSphere MQ. Изменить имя очереди нельзя.(L, M, A, R, C)
Type - тип очереди. Выставляется автоматически (Local).
Description - описание. Может содержать до 64 знаков. (L, M, A, R, C)
Put Messages - разрешение/запрещение помещения сообщений в очередь. Имеет два значения Allowed - разрешено и Inhibited - запрещено. (L, M, A, R, C)
Get Messages - разрешение/запрещение считывания сообщений из очереди. Имеет два значения Allowed - разрешено и Inhibited - запрещено. (L, M, A)
Default Priority - приоритет сообщений, помещенных в очередь. Наивысший приоритет - 0, наименьший 9. Приоритет указывает на то, в каком порядке будут обработаны или переданы сообщения, находящиеся в очереди. Первыми будут обработаны сообщения, имеющие наивысший приоритет. Значение по умолчанию - 0. Если приоритет задается программой, помещающей сообщения в очередь, то он сохраняется. (L, M, A, R, C)
Default Persistence - способ хранения сообщения. Имеет два значения Persistent и Not Persistent. Значение Persistent указывает на то, что сообщения, помещаемые в очередь, будут записаны на диск. В случае остановки менеджера очередей или его сбоя они остаются на жестком диске и после старта менеджера или устранения сбоя остаются в очереди. Значение Not Persistent указывает на то, что сообщения будут храниться в оперативной памяти. Соответственно после остановки, сбоя менеджера или компьютера восстановлению не подлежат. В первом случае можно выиграть в надежности, но проиграть в скорости обработки, во втором - наоборот.
Scope - контекст, поддерживается только для OS/400. (L, A, R)
Usage - тип локальной очереди. Имеет два значения Normal и Transmission. Первое говорит о том, что очередь будет выступать в роли простой локальной, то есть сообщения, помещенные в нее приложениями или доставленные от других менеджеров очередей, не будут никуда переданы. Их можно будет считать только программным способом. Значение Transmission указывает на то, что очередь будет трансмиссионной, и служит для передачи сообщений на другой менеджер очередей с помощью соответствующей локальной удаленной (remote) очереди и sender-канала. (L, M)
используются только на платформах
Свойства, приведенные в закладке LU 6. 2 используются только на платформах OS/2, Tandem NSK и z/OS. Особого интереса она не представляет, поэтому подробно на ней останавливаться не стоит.
Mode Name - используется для LU 6.2 соединений (OS/2, Tandem NSK и z/OS). Дает дополнительное определение параметров подключения сессии. Может содержать до 8 символов и цифр. Не используется для receiver и server connection каналов.
TP Name - имя транзакционной программы, которая должна быть запущена.
User ID - имя пользователя, которое может быть применено агентами MCA для инициализации сессии безопасности SNA. User ID не является пользователем, от имени которого будет помещено сообщение в очередь. Применяется только для sender, server, requester или server connection каналов.
Закладка MCA
MCA User ID - идентификатор пользователя, который использует MCA (Message Channel Agent) для авторизации доступа к ресурсам WebSphere MQ, включая помещение сообщений в назначенную очередь. Если данный атрибут не вводить, то будет применяться имя пользователя по умолчанию.
MCA Type - для AIX, AS/400, Windows NT, HP-UX, OS/2, и Sun Solaris может иметь значения Process и Thread. Для z/OS данный атрибут используется только для кластерного receiver-канала. При использовании типа Process, можно получить более высокую надежность (изоляция и авторизация каждого канала), но тип Thread повышает производительность.
Закладка Message Retry
Message retry count - количество попыток, совершаемое каналом, чтобы поместить сообщение в очередь прежде чем принять решение о том, что это сделать невозможно. Актуально в случае, если атрибут Message-retry exit name не заполнен.
Message retry interval - определяет минимальный интервал времени в миллисекундах, который должен пройти прежде чем канал сделает повторную попытку поместить сообщение в очередь. Может быть в пределах от 0 до 999 999 999.
Message-retry exit name - имя программы, которая может быть запущена, если с первого раза не удалось поместить сообщение в очередь. Программа может использовать в своей работе атрибут Message retry count.
Message-retry exit user data - данные, которые могут быть переданы программе, указанной в атрибуте Message-retry exit name.
Атрибуты, которые не могут быть использованы, в этих формах ввести невозможно. Так, например, для receiver - канала не имеет значения атрибут Connection Name. Это говорит о том, что существует возможность использовать один receiver - канал в паре со многими sender - каналами, расположенными на других менеджерах очередей. Такая схема работы не самая удачная, поскольку снижается контроль и управление потоками данных.
Рис. 3.8. Форма для заполнения свойств receiver - канала
Для requester - канала атрибут Connection Name является обязательным, поскольку используется в процессе установления соединения при получении запроса на подключение от удаленного менеджера. Пожалуй, это единственное существенное отличие его от receiver - канала.
Рис. 3.9. Форма для заполнения свойств receiver-канала
Закладка Retry
Short Retry Count - определяет количество попыток установления связи с каналом-партнером. Используется для sender, cluster-sender, server и cluster-receiver каналов и может быть в пределах от 0 до 999 999 999.
Short Retry Interval - определяет интервал времени в секундах, в течение которого канал будет ждать прежде чем попытаться установить соединение после неудачной попытки. Может располагаться в пределах от 0 до 999 999.
Long Retry Count - определяет дополнительное количество попыток установления связи с каналом-партнером. Используется для sender, cluster-sender, server и cluster-receiver каналов и может быть в пределах от 0 до 999 999 999.
Long Retry Interval - то же, что и Short Retry Interval, только для атрибута Long Retry Count.
Закладка SSL
Работа с механизмом защиты SSL (Security Socket Layer) подробно описана в лекции 13 (Шаг 8 - Настройка SSL свойств для каналов WebSphere MQ).
Формы для создания receiver - канала (рис. 3.8) и requester-канала (рис. 3.9) практически ничем не отличаются от форм sender и server- каналов, за исключением закладки Message Retry.
Закладка Storage
Backout Requeue Name - имя очереди, в которую можно поместить сообщение при достижении атрибутом сообщения Backout Count (счетчик откатов транзакций) значения атрибута очереди Backout Threshold. (L, M)
Backout Threshold - значение порога откатов транзакции, при котором сообщение можно поместить в очередь, указанную в атрибуте Backout Requeue Name. (L, M)
Harden Get Backout - способ хранения информации об атрибуте сообщения Backout Count. Имеет два значения Hardened и Not Hardened. В первом случае информация о Backout Count хранится на диске, во втором в памяти. Для систем OpenVMS, OS/2, OS/400, Tandem NonStop Kernel, UNIX systems, and Windows NT этот атрибут всегда Hardened, несмотря на выставленное значение. (L, M)
Атрибуты закладки Storage сугубо информативные. Менеджер очередей не предпринимает никаких действий в результате достижения или превышения значения Backout Threshold значением Backout Count. Эти атрибуты удобно использовать для написания программ в том случае, если не удается совершить транзакцию с одной очередью - тогда возможно переложить сообщение в другую.
Рис. 3.3. Разрешение генерации event-сообщений для менеджера очередей
Как говорилось выше, форма для создания модельной очереди практически ничем не отличается от простой локальной. Для создания модельной очереди имеют значения атрибуты Default Persistence и Definition Type. Свойство Definition Type может быть установлено в Temporary или Permanent. В первом случае, после открытия модельной очереди создается временная динамическая очередь, и сообщения, которые должны быть помещены в модельную очередь помещаются в созданную динамическую. После закрытия модельной очереди созданная динамическая удаляется вместе со всеми сообщениями, помещенными за сеанс работы с данной модельной очередью. Во втором случае на каждое сообщение создается своя динамическая очередь, которая не удаляется. Свойство Default Persistence для модельной очереди может быть всегда установлено в Not persistent, а в Persistent только, если свойство Definition Type - Permanent. Вышеизложенное наглядно демонстрирует таблица 3.1.
| Not persistent | Temporary | На сеанс работы с модельной очередью создается одна временная динамическая. Сообщения помещаются в нее. После закрытия модельной очереди динамическая удаляется вместе со всеми сообщениями |
| Not persistent | Permanent | На каждое сообщение, помещенное в модельную очередь создается своя динамическая. После закрытия модельной динамические очереди не удаляются, но имеют тип Not persistent. |
| Persistent | Temporary | При попытке поместить сообщение в модельную очередь будет выдаваться сообщение об ошибке с кодом 2048, которое говорит о том, что нельзя поместить persistent сообщение в динамическую временную очередь. |
| Persistent | Permanent | На каждое сообщение, помещенное в модельную очередь создается своя динамическая. После закрытия модельной очереди динамические очереди не удаляются и имеют тип Persistent. |
Рис. 3.4. Форма для заполнения свойств alias очереди
Единственным отличием закладки General для alias очереди является атрибут Base Queue Name - имя очереди, с которой действительно будет работать приложение, т.е. помещать или считывать сообщения. Как видно, у данного типа очереди нет параметров подобных максимальному количеству сообщений. При работе с данным типом очереди следует учитывать атрибуты сопоставленной Base Queue Name.(А)
Форма для создания локальной удаленной очереди (рис. 3.5) имеет 2 закладки: General и Cluster.
Рис. 3.5. Форма для заполнения свойств удаленной локальной очереди
Закладка Triggering
Trigger Control - разрешает (On) или запрещает (Off) инициацию триггерного события. (L, M)
Trigger Type - триггерное событие запускается на каждое сообщение (Every), на первое (First), по достижению определенного числа сообщений в очереди (Depth) или не запускается (None). (L, M)
Trigger Depth - указывает число сообщений в очереди, по достижению которого инициируется триггерное событие. Работает в случае, если атрибут Trigger Type выставлен в значение Depth. (L, M)
Trigger Message Priority - триггерное событие инициируется только для сообщений, имеющих данный приоритет или выше. Следует напомнить, чем ниже значение атрибута Default Priority, тем выше приоритет сообщения. (L, M)
Trigger Data - данные (строка), которые будут помещены в триггерное сообщение. С помощью этого поля можно передать данные программе, запускающейся по наступлению триггерного события. (L, M)
Initiation Queue Name - имя очереди инициализации триггерного события. (L, M)
Process Name - имя процесса WebSphere MQ, который запускается при наступлении триггерного события. (L, M)
Использование механизма триггеринга для автоматического старта каналов
Используя механизм триггеринга можно сделать так, чтобы каналы отправители, перешедшие в нейтральное состояние Inactive в результате истечения времени, указанного в атрибуте Disconnect Interval автоматически переходили в состояние Running при появлении в соответствующей трансмиссионной очереди сообщения. Для этого существует два способа: с использованием процесса и с использованием системной очереди инициализации. Рассмотрим вариант с использованием процесса.
Для каждой трансмиссионной очереди нужно создать:
очередь инициализации;процесс и в качестве атрибута процесса User Data указать имя канала отправителя, который передает данные, поступающие в эту трансмиссионную очередь;в трансмиссионной очереди установить атрибуты Trigger Control - On;Trigger Type - First;Trigger Depth - 1;Trigger Message Priority - 0;Initiation Queue Name - имя очереди инициализации созданной в п.1;Process Name - имя процесса, созданного в п.2.
Теперь рассмотрим второй способ автоматического старта канала отправителя без использования процессов. Для реализации второго способа требуется лишь установить атрибуты трансмиссионной очереди:
Trigger Control - On;Trigger Type - First;Trigger Depth - 1;Trigger Message Priority - 0;Trigger Data - имя канала отправителя, который передает данные, поступающие в эту трансмиссионную очередь;Initiation Queue Name - имя системной очереди инициализации SYSTEM.CHANNEL.INITQ.
Имя системной очереди инициализации может быть использовано в атрибуте Initiation Queue Name каждой трансмиссионной очереди.
В процессе рестарта каналов возможна ситуация, когда транзакция по передаче сообщения еще не завершилась, а канал получил команду на остановку. В таком случае при рестарте каналов сообщение может быть передано с принудительным завершением транзакции либо остаться в исходящей очереди посредством отката транзакции. Остановка канала может осуществляться как с прерыванием и принудительным завершением транзакции, так и без прерывания. Во втором случае транзакция успешно закрывается, что гарантирует отсутствие в трансмиссионной очереди сообщений с признаком незавершенной транзакции (uncommitted messages). Последующий старт канала облегчается отсутствием необходимости выполнения команды resolve channel с вариантами обработки uncommitted сообщений. Операции по рестарту каналов можно производить с помощью команд MQSC и с помощью WebSphere MQ Explorer, выполняя соответствующие пункты контекстного меню для каждого канала. Рассмотрим процедуру рестарта каналов с помощью WebSphere MQ Explorer [9].
Остановить канал отправитель, выполнив пункт Stop контекстного меню. При выполнении данного меню появится форма, изображенная на рис.4.12, имеющая следующие параметры:
Force interruption of current message batch - прерывание и принудительное завершение транзакции. Если выставить флажок в этом параметре, то становится доступным параметр Allow process/thread termination позволяющий принудительно остановить процесс передачи данных. Рекомендуется не использовать эти два параметра, чтобы перед остановкой канала обеспечить передачу сообщений, по которым транзакция была уже открыта.
New state - указывается состояние канала, в которое он будет переведен после остановки. Может иметь два значения Inactive и Stopped.
Параметры в секции Filter (Only stop channels from this remote queue manager и Only stop channels from this remote connection) используются только для z/OS.
Рис. 4.12. Остановка канала
Остановить канал получатель.Выполнить пункт контекстного меню Reset для канала получателя, выставив значение Message Sequence Number в единицу.Стартовать канал получатель при помощи контекстного меню Start.
Выполнить пункт контекстного меню Reset для канала отправителя, выставив значение Message Sequence Number в единицу (рис.4.13).
Рис. 4.13. Выравнивание счетчика сообщений
Если использовался способ остановки с прерыванием транзакции, то выполнить пункт контекстного меню Resolve и выбрать метод обработки сообщений, для которых транзакция не завершилась (рис.4.14). Commit - передать сообщения, Back out - выполнить откат транзакции.
Рис. 4.14. Метод обработки сообщений с незавершенной транзакцией
Выполнить пункт контекстного меню Ping для канала отправителя с целью проверки установления соединения с каналом получателем. Данный пункт выполнять не обязательно, если вы уверены, что связь между каналами может быть установлена.Выполнить пункт контекстного меню Start для канала отправителя.
Эту процедуру следует выполнить когда устранены все неполадки, приведшие к остановке каналов или переходу в неопределенное состояние. Если в сети существуют проблемы со связью, то канал отправитель может не перейти в состояние running и тогда всю процедуру надо будет вновь повторить сначала. Следует заметить, что WebSphere MQ гарантирует доставку сообщений, но только при правильных настройках всех объектов, участвующих в процессе передачи. Если установить тип сообщений Non Persistent, то никакими силами не удастся восстановить сообщения, например, после перезагрузки компьютера или после остановки менеджера. Материалов, приведенной в данной лекции вполне достаточно для создания и управления интерфейсами передачи и обработки данных.
Пиктограммы состояния каналов
Состояние канала отображается в WebSphere MQ Explorer пиктограммами. Одной пиктограмме может соответствовать несколько состояний канала.
 | neutral (нейтральное). Соответствует состоянию Inactive | |
 | running (стартован). Соответствует только состоянию Running. | |
 | stopped (остановлен). Соответствует состоянию Stopped. | |
 | alert (неопределенное состояние). Соответствует состояниям Binding, Requesting, Retrying, Stopping. | |
 | warning (предупреждающее состояние). Обычно возникает при появлении ошибок. |
Как правило, причиной остановки канала может быть только команда. Причин возникновения неопределенного состояния может быть несколько: разрыв связи, неправильный IP адрес в каналах отправителях или в requester, попытка стартовать канал, когда канал на другом конце остановлен или находится в неопределенном состоянии и пр. Самое главное, что нужно делать, чтобы избежать ошибок, это правильно заполнять атрибуты каналов и удаленных локальных очередей и контролировать работу каналов на обоих менеджерах. Напомним, что главным определяющим атрибутом канала отправителя является Disconnect Interval, по истечении которого канал переходит в состояние Inactive, если в соответствующей трансмиссионной очереди не будет новых сообщений. Для возобновления передачи нужно либо вручную стартовать канал, либо настроить автоматический старт.
Для создания интерфейса передачи сообщений от одного менеджера очередей к другому необходимо создать ряд объектов как на одном менеджере, так и на другом.
Предположим, нам нужно передать сообщения от одного менеджера QM_Win2000_REP, расположенного на платформе NT, имеющего IP адрес 198.32.100.26, порт для службы listener - 1415 к другому менеджеру QM_HPUX, расположенному на платформе UNIX с адресом 198.32.100.16, порт для службы listener - 1421. Подключим менеджер QM_HPUX для удаленного управления с помощью WebSphere MQ Explorer. Создадим объекты на платформе UNIX:
локальная очередь Win2000_REP_HPUX.Q - в нее будет доставляться сообщение (рис. 4.1);receiver канал Win2000_REP_HPUX.CH (рис. 4.2).
Создадим объекты на менеджере QM_Win2000_REP:
трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ (рис. 4.3);
удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ (рис. 4.4), имеющая атрибуты:
Remote Queue Name - Win2000_REP_HPUX.Q;Remote Queue Manager Name - QM_HPUX;Transmission Queue Name - Win2000_REP_HPUX_TRANS.TQ;
sender канал Win2000_REP_HPUX.CH (рис. 4.5), имеющий атрибуты: Connection Name - 198.32.100.16(1421);Transmission Queue - Win2000_REP_HPUX_TRANS.TQ;
Рис. 4.1. Локальная очередь Win2000_REP_HPUX.Q
Рис. 4.2. Receiver канал Win2000_REP_HPUX.CH
Рис. 4.3. Трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ
Рис. 4.4. Удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ
Рис. 4.5. sender канал Win2000_REP_HPUX.CH
Поместим тестовое сообщение в локальную удаленную очередь Win2000_REP_HPUX_REMOT.RQ с помощью программы amqsput.exe, входящей в пакет демонстрационных программ, введя в командной строке:
amqsput Win2000_REP_HPUX_REMOT.RQ QM_Win2000_REP
Далее вводим текст сообщения:
Тестовое сообщение от QM_Win2000_REP.
Работа программы amqsput.exe показана на рис. 4.6.
увеличить изображение
Рис. 4.6. Работа программы amqsput.exe
После нажатия клавиши "Enter" сообщение должно попасть в трансмиссионную очередь Win2000_REP_HPUX_TRANS.TQ. Оно будет находиться в ней до тех пор, пока sender канал не будет стартован. После старта канала сообщение будет доставлено в очередь Win2000_REP_HPUX.Q на менеджер QM_HPUX (рис. 4.7).
увеличить изображение
Рис. 4.7. Просмотр сообщения через Message Browser
Процессы WebSphere MQ, триггеринг и автоматический старт каналов
Как правило, после поступления сообщений в очередь назначения, они обрабатываются различными прикладными программами, например, считываются из очереди и помещаются в базу данных. WebSphere MQ имеет возможность запускать процессы, как только одно или определенное количество сообщений поступает в очередь.
Процесс WebSphere MQ это объект, содержащий информацию о прикладной программе, которая может быть выполнена на определенных условиях при использовании механизма триггеринга. Форма для создания процесса изображена на рис. 4.10.
Рис. 4.10. Форма для создания процесса WebSphere MQ
Process Definition Name - имя процесса. Уникально в пределах одного менеджера и должно отличаться от его имени. Может совпадать с именами других объектов менеджера.
Description - описание процесса.
Application Type - тип приложения. Зависит от операционной системы, на которой установлен менеджер очередей.
Application Identifier - имя выполняемой программы с указанием пути.
Environment Data - данные, которые могут быть переданы сервису Trigger Monitor.
User Data - данные, которые могут быть переданы выполняемой программе.
Для запуска процесса необходимы условия:
сообщения поступают в очередь;приоритет сообщения не ниже приоритета, указанного в атрибуте Trigger Message Priority;количество сообщений в очереди находится в соответствии с атрибутом Trigger Type;существует очередь инициализации;атрибут Trigger Control установлен в значение On;существует и стартована служба сервиса WebSphere MQ Trigger monitor, в параметрах которой указана соответствующая очередь инициализации или запущена программа runmqtrm.
Предположим, что необходимо информировать пользователя о приходе каждого сообщения в очередь FOR_USER_INF.Q. Рассмотрим шаги для реализации поставленной задачи:
Создать очередь инициализации for_user_init.
Создать файл c:\temp\trig.bat, содержащий строку
net send user1 Пришло сообщение в очередь FOR_USER_INF.Q
который будет посылать сообщения пользователю user1,
Создать процесс NET_SEND.P с атрибутами: Process Definition Name - NET_SEND.P;Application Type - Windows NT;Application Identifier - c:\temp\trig.bat.Создать локальную очередь FOR_USER_INF.Q с атрибутами Queue Name - FOR_USER_INF.Q;Trigger Control - On;Trigger Type - Every;Trigger Depth - 1;Trigger Message Priority - 0;Initiation Queue Name - for_user_init ;Process Name - NET_SEND.P.Создать службу сервиса WebSphere MQ Trigger Monitor: Запустить утилиту создания и управления сервисами WebSphere MQ;Вызвать контекстное меню, правой кнопкой мыши щелкнув по имени менеджера, выбрать пункт Create, далее Trigger Monitor;Ввести имя очереди инициализации - for_user_init;После нажатия на кнопку OK в правой части консоли WebSphere MQ Services появится созданный объект Trigger Monitor (рис. 4.11);
увеличить изображение
Рис. 4.11. Консоль WebSphere MQ Services
Выполнить старт Trigger Monitor, нажав на кнопку "Старт", расположенную на панели управления.
Поместить тестовое сообщение в очередь FOR_USER_INF.Q и убедиться, что сетевое сообщение с текстом "Пришло сообщение в очередь FOR_USER_INF.Q" отправлено пользователю user1.
Вместо создания службы сервиса WebSphere MQ Trigger Monitor можно выполнить программу runmqtrm. Синтаксис команды
runmqtrm -q for_user_init
В этом случае процесс NET_SEND.P будет выполняться только тогда, когда программа runmqtrm запущена.
Соединение типа клиент-сервер
Рассмотрим ситуацию, предполагающую наличие одного сервера с установленным менеджером очередей и множества рабочих станций, которые должны доставлять или получать сообщения от этого менеджера. Предположим, что для каждой рабочей станции на менеджере очередей создана своя локальная очередь для получения сообщений FROM_A1.Q, FROM_A2.Q и так далее в зависимости от количества станций. Также созданы локальные очереди для отправки сообщений TO_A1.Q, TO_A2.Q и так далее. В данном случае целесообразно использовать соединение типа клиент-сервер, которое не требует установки серверной части WebSphere MQ на рабочей станции. На ней можно установить только клиентскую часть, которая присутствует в комплекте поставки. Кроме этого, клиентская часть доступна по адресу в Интернет: http://www14.software.ibm.com/webapp/download/search.jsp?go=y&amp;rs=wsmqclient.
Подключение рабочей станции производится с помощью канала типа Server Connection, создаваемого на менеджере очередей. Форма для создания канала с помощью WebSphere MQ Explorer представлена на рис.4.8 и имеет закладки General, Extended, MCA, Exits и SSL. Атрибуты, вводимые в этих закладках описаны в лекции 3. Основным атрибутом является Channel Name. Кроме имени канала никакие другие атрибуты не играют роли в процессе подключения рабочей станции.
Рис. 4.8. Форма создания канала Server Connection
Кроме создания канала на менеджере очередей нужно разрешить учетной записи рабочей станции подключение к менеджеру и дать соответствующие права на очереди, с которыми рабочая станция будет работать. Предположим, что станция имеет учетную запись (имя пользователя) station1 в домене petersburg и должна работать с локальными очередями FROM_A1.Q и TO_A1.Q на менеджере QM_Win2000 с IP адресом 198.32.100.26 через канал CHANNEL_BY_A1. Тогда на сервере нужно выполнить команды авторизации
SETMQAUT -m QM_Win2000 -t qmgr -p station1@petersburg +connect SETMQAUT -m QM_Win2000 -n FROM_A1.Q -t queue -p station1@petersburg +all SETMQAUT -m QM_Win2000 -n TO_A1.Q -t queue -p station1@petersburg +all
Первая команда дает права пользователю с учетной записью station1@petersburg на подключение к менеджеру QM_Win2000, вторая и третья разрешают производить все операции с очередями FROM_A1.Q и TO_A1.Q соответственно. Просмотреть права данной учетной записи можно с помощью команд
DSPMQAUT -m QM_Win2000 -t qmgr -p station1@petersburg DSPMQAUT -m QM_Win2000 -n FROM_A1.Q -t queue -p station1@petersburg DSPMQAUT -m QM_Win2000 -n TO_A1.Q -t queue -p station1@petersburg
На этом действия по созданию соединения клиент-сервер на сервере завершаются. На рабочей станции необходимо создать системную переменную с именем MQSERVER как показано на рис.4.9.
Рис. 4.9. Параметры переменной MQSERVER
Теперь с рабочей станции можно послать сообщение в очередь FROM_A1.Q на удаленный менеджер QM_Win2000 с помощью программы amqsputc.exe, входящей в комплект поставки в качестве примера:
amqsputc FROM_A1.Q <text_message.txt
где text_message.txt - файл, содержащий текст сообщения.
Считать сообщения из очереди можно с помощью программы amqsgetc.exe:
amqsgetc TO_A1.Q
при условии, что в этой очереди они есть.
Вполне вероятно, что рабочие станции в своей работе могут использовать только одну очередь для отправки и получения сообщений. В этом случае необходимо создать такую программу, которая позволяла бы корректно разбирать и отправлять сообщения в зависимости от имен рабочих станций и/или других параметров.
Состояние каналов. Создание интерфейсов передачи сообщений
Как говорилось в предыдущей лекции, сообщения передаются с помощью каналов, с одинаковыми именами, расположенными как на одном, так и на другом менеджере. Для управления процессом старта каналов существует специальная служба, которая называется Channel initiator. На платформе Windows NT она запускается автоматически при старте менеджера с помощью WebSphere MQ Explorer. На других платформах она запускается с помощью команды runmqchi (на AS/400 - strmqmchi). На менеджере, отправляющем сообщение, должен быть создан канал отправитель, на менеджере получателе, соответственно, получатель. Рассмотрим подробнее работу пар каналов.
Sender => Receiver
Наиболее распространенная пара. Sender канал инициирует соединение с receiver каналом, затем передает сообщения.
Server => Receiver
В данном случае server канал выполняет роль sender канала. Пара имеет право на существование, но лучше использовать связку Sender => Receiver.
Server => Requester
В этой паре requester канал инициирует соединение, затем server канал начинает передачу данных.
Sender => Requester
Requester канал инициирует соединение в случае разрыва с sender каналом. Sender канал в свою очередь инициирует соединение с requester каналом, и только после этого начинается процесс передачи.
Каналы могут находиться в следующих состояниях.
Initialising - WebSphere MQ делает попытку произвести старт канала.
Starting - канал начал процесс старта и ждет установки соединения (активации слота).
Binding - после активации слота идет попытка установления соединения и передача данных инициации между каналами.
Requesting - requester канал ждет ответа от sender канала.
Running - состояние при котором либо идет передача данных, либо канал отправитель ждет сообщений из трансмиссионной очереди. Единственное состояние каналов отправителей, при котором возможна передача данных.
Paused - канал ожидает истечения времени, указанного в атрибуте Message retry interval.
Stopping - канал переходит в это промежуточное состояние в процессе остановки канала командой MQSC stop channel, либо при возникновении какой-либо ошибки.
Retrying - ожидание очередной попытки старта канала с помощью Channel initiator.
Stopped - канал остановлен. Стартовать его можно либо с помощью WebSphere MQ Explorer либо с помощью команды MQSC start channel. Ниже мы приведем подробную инструкцию для старта каналов.
Inactive - состояние канала, говорящее о том, что либо он никогда не был стартован, либо истекло время, указанное в атрибуте Disconnect Interval для канала отправителя. Для канала получателя это нормальное состояние, так как он переходит в состояние Running при инициации связи со стороны канала отправителя.
Авторизация и доступ к объектам
В предыдущей лекции были рассмотрены примеры создания интерфейсов передачи данных без учета вопросов авторизации и доступа. WebSphere MQ имеет свой механизм предоставления прав доступа и аутентификации пользователя [10]. Ограничения по доступу могут быть на уровне удаленного управления менеджером очередей и на уровне доступа к определенным объектам. Основной командой, предоставляющей права доступа к объектам, является команда setmqaut. Синтаксис команды следующий:
setmqaut -m QMgrName -n Profile -t ObjectType -s ServiceComponent -remove -p PrincipalName [-g GroupName] MQI authorizations [Administration authorizations] [Generic authorizations]
-m QmgrName - имя менеджера очередей.
-n Profile - имя объекта менеджера, к которому применяется команда. В имени могут использоваться символы групповой замены (?, *, **). Например, если необходимо произвести авторизацию ко всем очередям, начинающимся на PAY, то опция Profile будет выглядеть
-n PAY*
-t ObjectType - тип объекта менеджера. Может иметь значения q или queue для очередей, prcs или process для процессов, nl или namelist для списков кластеров, authinfo для использования механизма SSL.
-s ServiceComponent - имя установленного сервиса авторизации, с помощью которого будут произведены изменения прав доступа. Параметр не является обязательным.
-remove - лишает прав доступа к объектам, указанным перед ним.
-p PrincipalName или -g GroupName - имя пользователя или группы, для которой производится изменение прав доступа к объектам. Для платформы Windows возможно указание доменной учетной записи в формате userid@domain.
Рассмотрим опции авторизации: MQI authorizations, Administration authorizations и Generic authorizations. Перед данными опциями должны указываться символы "+" или "-", разрешающие или запрещающие соответствующие действия.
MQI authorizations - опции команды для авторизации MQI. Может принимать значения:
altusr - дает возможность использовать имя другой учетной записи для функций MQOPEN и MQPUT1;browse - разрешает просмотр сообщений в очереди функцией MQGET, если очередь открыта на просмотр с опцией BROWSE;connect - разрешает подключение к менеджеру очередей;get - разрешает считывание сообщение из очереди;inq - разрешает считывание значения атрибутов очереди;put - разрешает помещать сообщения в очередь;set - разрешает изменять атрибуты очереди.
Administration authorizations - опции команды для авторизации на выполнение действий. Может принимать значения:
chg - изменение атрибутов объекта;clr - удаление сообщений из очереди (доступно только для PCF команд);crt - создание объектов;dsp - просмотр атрибутов объекта
Generic authorizations - опции авторизации для групповых операций. Может принимать значения:
all - предоставляет все права на объект;alladm - предоставляет все административные права на объект;allmqi - предоставляет возможность MQI вызова на объект;none - создает в своем механизме аутентификации запись для профиля пользователя не предоставляя ему никаких прав;
Опции команды setmqaut применяются не ко всем объектам менеджера очередей. В таблице 5.1. указано соответствие между опциями и объектами.
| all | + | + | + | + | + |
| alladm | + | + | + | + | + |
| allmqi | + | + | + | + | + |
| none | + | + | + | + | + |
| altusr | - | - | + | - | - |
| browse | + | - | - | - | - |
| chg | + | + | + | + | + |
| clr | + | - | - | - | - |
| connect | - | - | + | - | - |
| crt | + | + | + | + | + |
| dlt | + | + | + | + | + |
| dsp | + | + | + | + | + |
| get | + | - | - | - | - |
| put | + | - | - | - | - |
| inq | + | + | + | + | + |
| set | + | - | - | - | - |
setmqaut -m QM_Win2000 -n Win2000_HPUX.? -t queue -p test1 +browse
Запрет на считывание сообщение из очередей, начинающихся на Vip, имеющим в имени символ "." и заканчивающиеся любыми допустимыми символами за исключением символов "_" и "."
setmqaut -m QM_Win2000 -n Vip*.* -t queue -p test1 -get
Право на просмотр атрибутов и удаление очередей, начинающихся на Win2000_HPUX. и имеющим после точки два символа, причем левый символ может быть любым
setmqaut -m QM_Win2000 -n Win2000_HPUX.?Q -t queue -p test1 +dlt +dsp
Предоставление всех прав на очередь A1
setmqaut -m QM_Win2000 -n A1 -t queue -p test1 +all
Предоставление всех прав на очереди, состоящие из двух символов, имеющие любой первый символ и второй символ "2"
setmqaut -m QM_Win2000 -n ?2 -t queue -p test1 +all
Предоставление всех прав на очереди, оканчивающиеся на .CQ и не имеющие перед символом "." символов "_" и "."
setmqaut -m QM_Win2000 -n **.CQ -t queue -p test1 +all
Предоставление прав на считывание сообщений из очередей, начинающихся на NO, имеющих в имени символ "." и оканчивающихся на Q
setmqaut -m QM_Win2000 -n NO*.Q -t queue -p test1 +get
Предоставление прав на помещение, просмотр и удаление сообщений в очереди DEAD_LETTER
setmqaut -m QM_Win2000 -n DEAD_LETTER -t queue -p test1 +put +browse +get
Удаление прав на помещение сообщений в очередь A1
setmqaut -m QM_Win2000 -n A1 -t queue -p test1 -put
С помощью команды setmqaut нельзя предоставлять доступ к объектам кластера, которые физически расположены на удаленных менеджерах.
Коды возврата команды setmqaut указаны в таблице 5.2.
| 0 | Successful operation | Ошибок нет |
| 36 | Invalid arguments supplied | Содержится неправильный аргумент |
| 40 | Queue manager not available | Менеджер очередей недоступен |
| 49 | Queue manager stopping | Менеджер очередей остановлен |
| 69 | Storage not available | Невозможно сохранить изменения |
| 71 | Unexpected error | Непредвиденная ошибка |
| 72 | Queue manager name error | Ошибка в имени менеджера |
| 133 | Unknown object name | Неизвестное имя объекта |
| 145 | Unexpected object name | Непредвиденное имя объекта |
| 146 | Object name missing | Отсутствует имя объекта |
| 147 | Object type missing | Отсутствует тип объекта |
| 148 | Invalid object type | Неправильный тип объекта |
| 149 | Entity name missing | Отсутствует имя объекта |
| 150 | Authorization specification missing | Отсутствует опция авторизации |
| 151 | Invalid authorization specification | Неправильная опция авторизации |
Просмотреть права учетной записи (пользователя) к объекту на локальном менеджере можно с помощью команды dspmqaut. Синтаксис команды
dspmqaut -m QMgrName -n ObjectName -t ObjectType -s ServiceComponent -p PrincipalName [-g GroupName]
-m QmgrName - имя менеджера очередей.
-n ObjectName - имя объекта менеджера, к которому применяется команда.
-t ObjectType - тип объекта менеджера. Может иметь значения q или queue для очередей, prcs или process для процессов, nl или namelist для списков кластеров, authinfo для использования механизма SSL.
-s ServiceComponent - имя установленного сервиса авторизации, с помощью которого будет произведен просмотр прав доступа. Параметр не является обязательным.
-p PrincipalName или -g GroupName - имя пользователя или группы, для которой производится просмотр прав доступа к объектам. Для платформы Windows возможно указание доменной учетной записи в формате userid@domain.
Опции команды dspmqaut также доступны не для всех объектов менеджера очередей. В таблице 5.3. указано соответствие между опциями и объектами.
| all | + | + | + | + | + |
| alladm | + | + | + | + | + |
| allmqi | + | + | + | + | + |
| altusr | - | - | + | - | - |
| browse | + | - | - | - | - |
| chg | + | + | + | + | + |
| clr | + | - | - | - | - |
| connect | - | - | + | - | - |
| crt | + | + | + | + | + |
| dlt | + | + | + | + | + |
| dsp | + | + | + | + | + |
| get | + | - | - | - | - |
| inq | + | + | + | + | + |
| put | + | - | - | - | - |
| set | + | + | + | - | + |
C:\>dspmqaut -m QM_Win2000 -t q -n A -p test1 Entity test1 has the following authorizations for object A: (К данному объекту учетная запись test1 не имеет авторизации, так как не было соответствующей команды setmqaut)
C:\>dspmqaut -m QM_Win2000 -t q -n Win2000_HPUX.Q -p test1 Entity test1 has the following authorizations for object Win2000_HPUX.Q:
browse
(setmqaut -m QM_Win2000 -n Win2000_HPUX.? -t queue -p test1 +browse)
C:\>dspmqaut -m QM_Win2000 -t q -n Win2000_HPUX.TQ - p test1 Entity test1 has the following authorizations for object Win2000_HPUX.TQ:
dlt dsp
(setmqaut -m QM_Win2000 -n Win2000_HPUX.?Q -t queue -p test1 +dlt +dsp)
C:\>dspmqaut -m QM_Win2000 -t q -n Win2000_HPUX.RQ -p test1 Entity test1 has the following authorizations for object Win2000_HPUX.RQ:
dlt dsp
(setmqaut -m QM_Win2000 -n Win2000_HPUX.?Q -t queue -p test1 +dlt +dsp)
C:\>dspmqaut -m QM_Win2000 -t q -n A1 -p test1 Entity test1 has the following authorizations for object A1:
get browse inq set dlt chg dsp passid passall setid setall clr
(setmqaut -m QM_Win2000 -n A1 -t queue -p test1 +all setmqaut -m QM_Win2000 -n A1 -t queue -p test1 -put )
C:\>dspmqaut -m QM_Win2000 -t q -n A2 -p test1 Entity test1 has the following authorizations for object A2:
get browse put inq set dlt chg dsp passid passall setid setall clr
(setmqaut -m QM_Win2000 -n ?2 -t queue -p test1 +all)
C:\>dspmqaut -m QM_Win2000 -t q -n HPUX.CQ -p test1 Entity test1 has the following authorizations for object HPUX.CQ:
get browse put inq set dlt chg dsp passid passall setid setall clr
(setmqaut -m QM_Win2000 -n **.CQ -t queue -p test1 +all)
C:\>dspmqaut -m QM_Win2000 -t q -n NOTEPAD.Q -p test1 Entity test1 has the following authorizations for object NOTEPAD.Q:
get
(setmqaut -m QM_Win2000 -n NO*.Q -t queue -p test1 +get)
C:\>dspmqaut -m QM_Win2000 -t q -n WIN2000_HPUX2.TQ -p test1 Entity test1 has the following authorizations for object WIN2000_HPUX2.TQ:
put
(setmqaut -m QM_Win2000 -n WIN*.* -t queue -p test1 +put)
C:\>dspmqaut -m QM_Win2000 -t q -n WIN2000HPUX3.TQ -p test1 Entity test1 has the following authorizations for object WIN2000HPUX3.TQ:
put
(setmqaut -m QM_Win2000 -n WIN*.* -t queue -p test1 +put)
C:\>dspmqaut -m QM_Win2000 -t q -n WIN2000hpux4.tq -p test1 Entity test1 has the following authorizations for object WIN2000hpux4.tq:
put
(setmqaut -m QM_Win2000 -n WIN*.* -t queue -p test1 +put)
C:\>dspmqaut -m QM_Win2000 -t q -n Vip2000.CQ - p test1 Entity test1 has the following authorizations for object Win2000.CQ:
browse put inq set dlt chg dsp passid passall setid setall clr
(setmqaut -m QM_Win2000 -n **.CQ -t queue -p test1 +all setmqaut -m QM_Win2000 -n Vip*.* -t queue -p test1 -get)
C:\>dspmqaut -m QM_Win2000 -t q -n DEAD_LETTER -p test1 Entity test1 has the following authorizations for object DEAD_LETTER:
get browse put
(setmqaut -m QM_Win2000 -n DEAD_LETTER -t queue -p test1 +put +browse +get )
Отметим, что к выполнению команды setmqaut, содержащей символы групповой замены следует относиться с осторожностью и всегда проверять результат выполнения командой dspmqaut.
Командный процессор MQSC. Основные команды
Как говорилось в предыдущих лекциях, управлять объектами WebSphere MQ можно как с помощью команд, так и с помощью WebSphere MQ Explorer. Работа и возможности, предоставляемые WebSphere MQ Explorer были рассмотрены в предыдущих лекциях. Теперь рассмотрим работу команд MQSC (MQSeries Commands). Команды WebSphere MQ разделяются на внешние и внутренние. Внешние команды представляют собой программы, откомпилированные под конкретную платформу. Некоторые из внешних команд и их назначение представлены в таблице 5.4.
| amqmcert | Управление сертификатами для использования механизма SSL |
| amqmdain | Создание WebSphere MQ services (только для платформыWindows) |
| crtmqcvx | Конвертация С кода в структуру WebSphere MQ |
| crtmqm | Создание локального менеджера очередей |
| dltmqm | Удаление локального менеджера очередей |
| dmpmqaut | Удаление (dump) авторизации к объекту |
| dmpmqlog | Преобразование лог-файлов менеджера в "читаемый" вид |
| dspmq | Просмотр состояния менеджера очередей |
| dspmqaut | Просмотр прав доступа к объектам |
| dspmqcap | Просмотр количества процессоров |
| dspmqcsv | Просмотр состояния командного сервера |
| dspmqfls | Вывод файловой структуры объектов |
| dspmqtrc | Вывод трассировки в файл (только для HP-UX, Linux, и Solaris) |
| dspmqtrn | Просмотр незавершенных транзакций |
| endmqcsv | Остановка командного сервера |
| endmqlsr | Остановка службы listener |
| endmqm | Остановка менеджера |
| endmqtrc | Остановка режима трассировки (кроме AIX платформы) |
| rcdmqimg | Запись состояния объектов в файл |
| rcrmqobj | Восстановление состояния объектов из файла |
| rsvmqtrn | Управление незавершенными транзакциями |
| runmqchi | Запуск службы channel initiator |
| runmqchl | Старт sender или requester каналов |
| runmqdlq | Восстановление сообщений из очереди недоставленных сообщений |
| runmqlsr | Запуск службы listener |
| runmqsc | Запуск командного процессора внутренних команд MQSC |
| runmqtmc | Запуск trigger monitor для клиентской части (только для AIX платформы) |
| runmqtrm | Запуск trigger monitor |
| setmqaut | Предоставление прав доступа к объектам |
| setmqcap | Установка количества процессоров |
| strmqcsv | Запуск командного сервера |
| strmqm | Запуск менеджера очередей |
| strmqtrc | Запуск режима трассировки |
Из таблицы 5. 4 выделим команду runmqsc, которая является своего рода командным процессором для выполнения внутренних MQSC команд, позволяющих управлять объектами как локального, так и удаленного менеджера. Синтаксис команды:
runmqsc -e / -v /-w QmgrName
где:
-e - исключение вывода результата выполнения команд в отчет. Полезно для использования при вводе команд в интерактивном режиме.
-v - проверка синтаксиса команд без их выполнения. Если далее указана опция -w, то она игнорируется.
-w - время в секундах, в течение которого от удаленного менеджера должен прийти положительный ответ на подключение. С помощью данной опции возможно управление объектами удаленного менеджера. Если время истекло, то появится следующее сообщение:
AMQ8416: MQSC timed out waiting for a response from the command server.
QmgrName - имя менеджера очередей. Имя менеджера, являющегося менеджером по умолчанию указывать не обязательно.
Кроме непосредственного ввода внутренних команд из командной строки данная команда позволяет выполнять командный файл, содержащий различные сценарии создания и управления объектами. В таком случае синтаксис будет выглядеть
runmqsc QmgrName < create_obj.txt
где:
create_obj.txt - файл, содержащий внутренние команды MQSC.
Внутренние команды могут состоять из нескольких операторов. На первом месте стоит оператор, указывающий действие. На втором месте указывается тип объекта, к которому применяется первый оператор. Типы объектов указываются следующими операторами:
CHANNEL - канал;CHSTATUS - состояние канала;CLUSQMGR - информация о кластерных каналах менеджера;PROCESS - процесс;NAMELIST - список кластеров;QALIAS - очередь ALIAS;QCLUSTER - кластерная очередь;QLOCAL - локальная очередь;QMGR - менеджер;QMODEL - модельная очередь;QREMOTE - локальная удаленная очередь.
Основные операторы, которые, как правило, стоят на первом месте внутренней команды.
ALTER - изменение свойств объекта; CLEAR - удаление сообщений из очереди; DEFINE - создание объекта; DELETE - удаление объекта; DISPLAY - вывод информации об объекте; END - выход из командного процессора runmqsc; PING - проверка соединения; REFRESH - обновление информации; RESET - RESET CLUSTER - выводит менеджер очередей из кластера WebSphere MQ;RESET CHANNEL - сбрасывает счетчики сообщений у канала;
RESOLVE - управление сообщениями с признаком незавершенной транзакции; RESUME - оповещение кластера WebSphere MQ о том, что менеджер очередей снова включен в данный кластер; START - оператор старта; STOP - оператор останова; SUSPEND - временное исключение менеджера из кластера WebSphere MQ;
Подробный синтаксис команд можно узнать из документации [11].
Пример создания интерфейсов передачи данных в обе стороны между двумя менеджерами QM_Win2000 и QM_HPUX с адресами 198.32.100.26 и 198.32.100.16(1421), причем на менеджере QM_HPUX канал отправитель должен переходить в состояние running как только в соответствующей трансмиссионной очереди появляется сообщение. Для этого создаются объекты на менеджере QM_Win2000:
HPUX_Win2000.Q - локальная очередь, в которую будут приходить сообщения от менеджера QM_HPUX;HPUX_Win2000.CH - канал получатель;Win2000_HPUX.TQ - трансмиссионная очередь передачи;Win2000_HPUX.RQ - локальная удаленная очередь;Win2000_HPUX.CH - канал отправитель.
При создании объектов с помощью команды DEFINE следует учитывать, что если имя объекта не "берется" в символы "'", то объект будет создан с именем, содержащим только заглавные буквы. То же относится и к другим командам.
Набор команд для создания объектов выглядит следующим образом.
DEFINE QLOCAL ('HPUX_Win2000.Q')
DEFINE CHANNEL ('HPUX_Win2000.CH') CHLTYPE(RCVR)
DEFINE QLOCAL ('Win2000_HPUX.TQ') USAGE(XMITQ)
DEFINE QREMOTE ('Win2000_HPUX.RQ') XMITQ('Win2000_HPUX.TQ') + RNAME('Win2000_HPUX.Q') RQMNAME('QM_HPUX')
DEFINE CHANNEL ('Win2000_HPUX.CH') CHLTYPE(SDR) + CONNAME('198.32.100.16(1421)') DISCINT(999999) + XMITQ('Win2000_HPUX.TQ')
Создадим объекты на менеджере QM_HPUX:
Win2000_HPUX.Q - локальная очередь, в которую будут приходить сообщения от менеджера QM_Win2000;Win2000_HPUX.CH - канал получатель;HPUX _Win2000.TQ - трансмиссионная очередь передачи;HPUX _Win2000.RQ - локальная удаленная очередь;HPUX _Win2000.CH - канал отправитель.
Команды для создания этих объектов будут выглядеть следующим образом.
DEFINE QLOCAL ('Win2000_HPUX.Q')
DEFINE CHANNEL ('Win2000_HPUX.CH') CHLTYPE(RCVR)
DEFINE QREMOTE ('HPUX_Win2000.RQ') + XMITQ('HPUX_Win2000.TQ') + RNAME('HPUX_Win2000.Q') + RQMNAME('QM_Win2000')
DEFINE QLOCAL ('HPUX_Win2000.TQ') + USAGE(XMITQ) + TRIGGER + TRIGTYPE(FIRST) + TRIGDPTH(1) + TRIGDATA('HPUX_Win2000.CH') + INITQ('SYSTEM.CHANNEL.INITQ')
DEFINE CHANNEL ('HPUX_Win2000.CH') CHLTYPE(SDR) + CONNAME('172.25.4.150') + DISCINT(999999) + XMITQ('HPUX_Win2000.TQ')
Эти команды можно поместить в два текстовых файла, а затем, выполнив команду runmqsc на каждом менеджере с указанием соответствующего файла, можно получить готовый интерфейс для передачи данных между двумя платформами: UNIX и Windows. Кроме этого, используя команды рестарта каналов, можно управлять их состоянием.
DEFINE QLOCAL ('Win2000_HPUX.Q')
DEFINE CHANNEL ('Win2000_HPUX.CH') CHLTYPE(RCVR)
DEFINE QREMOTE ('HPUX_Win2000.RQ') + XMITQ('HPUX_Win2000.TQ') + RNAME('HPUX_Win2000.Q') + RQMNAME('QM_Win2000')
DEFINE QLOCAL ('HPUX_Win2000.TQ') + USAGE(XMITQ) + TRIGGER + TRIGTYPE(FIRST) + TRIGDPTH(1) + TRIGDATA('HPUX_Win2000.CH') + INITQ('SYSTEM.CHANNEL.INITQ')
DEFINE CHANNEL ('HPUX_Win2000.CH') CHLTYPE(SDR) + CONNAME('172.25.4.150') + DISCINT(999999) + XMITQ('HPUX_Win2000.TQ')
Эти команды можно поместить в два текстовых файла, а затем, выполнив команду runmqsc на каждом менеджере с указанием соответствующего файла, можно получить готовый интерфейс для передачи данных между двумя платформами: UNIX и Windows. Кроме этого, используя команды рестарта каналов, можно управлять их состоянием.
| © 2003-2007 INTUIT.ru. Все права защищены. |
Настройка служб WebSphere MQ под Windows
WebSphere MQ в своей работе оперирует как своими внутренними данными, так и данными на уровне операционных систем. Так, например, в процессе первичной установки создается группа mqm. Все пользователи, входящие в эту группу имеют все права на все объекты WebSphere MQ. То есть для полного управления менеджером очередей достаточно того, чтобы учетная запись была включена либо в группу mqm либо в группу администраторов.
В среде Windows часто встречается случай, когда прикладная программа должна выполняться под нужной учетной записью (пользователем). В процессе установки WebSphere MQ на платформе Windows кроме группы mqm создается пользователь с учетной записью MUSR_MQADMIN под именем которого выполняются все процессы и все прикладные программы, указанные в атрибуте Application Identifier соответствующего процесса. Если удалить и создать вновь данную учетную запись, то WebSphere MQ работать не будет. Рассмотрим процедуру, позволяющую запускать сервис IBM MQSeries под другой учетной записью.
Установить тип запуска для IBM MQSeries Service в Manual.Перегрузить компьютер.Запустить dcomcnfg, и настроить форму, как показано на рис.5.1.
Рис. 5.1. Форма настройки dcomcnfg
В закладке Security добавить пользователя mquser@alfa.moscow.net для параметров: Use custom access permissions (Allow access);Use custom launch permissions (Allow access);Use custom configuration permission (Full Control).
Установить тип запуска для MQSeries в Automatic.Перегрузить компьютер.Убедиться, что сервис IBM MQSeries (рис.5.2) стартовал от имени mquser@alfa.moscow.net.
Рис. 5.2. Старт сервиса IBM MQSeries под учетной записью mquser@alfa.moscow.net
Далее можно создавать службы сервиса WebSphere MQ Trigger Monitor (см. лекцию 4). Создать данные службы можно также с помощью команды amqmdain, синтаксис которой имеет вид:
amqmdain crttrm QmgrName InitQueue
где:
QmgrName - имя менеджера очередей,
InitQueue - имя очереди инициализации
После выполнения данной команды следует убедиться в появлении в MQSeries Services нового Trigger Monitor с нужной очередью инициализации (см. рис.4.11).
Управлять объектами удаленного менеджера можно с помощью WebSphere MQ Explorer и с помощью команды runmqsc. Для удаленного управления менеджером очередей необходимо:
Создать трансмиссионные очереди на менеджере, с которого производится управление и на удаленном менеджере;Создать и стартовать каналы в обе стороны между менеджерами;Выполнить команду runmqsc -w TimeOut RemoteQmqrName где: TimeOut - время в секундах, в течение которого от удаленного менеджера должен прийти положительный ответ на подключение. Если время истекло, то появится следующее сообщение
AMQ8416: MQSC timed out waiting for a response from the command server. RemoteQmqrName - имя удаленного менеджера.
Далее с помощью команд MQSC можно управлять объектами удаленного менеджера.
